2017/04/10 16:59:12

ソフトウェア開発業務の実際

タイトル：「ホントは厳しいソフトウェア開発の実務」

第１章 ソフトウェア開発業界に入る

１．１　厳しいの？ソフト業界

　あちらこちらに、ソフトウェアがある時代だ。パソコンや携帯電話、家電や自動車など、あるいは、社会インフラにも、ソフトウェアは、なくてはならないものになってしまった。ソフトウェア開発／販売は、人気の産業となり、日ごろオンラインゲームなどで遊んでいる少年も、将来はソフトウェア技術者になりたいという人は多いだろう。しかし、ソフトウェア開発の実務は厳しい、とよく聞く。頭脳労働の最たるものであり、デスクワークなのに過酷な労働環境、と言われて久しい。学校を出たばかりの知的な若者が、様々な夢をいだいて業界に押し寄せて来る。果たして現実のソフトウェア開発は、どのようなものだろうか？夢と現実のギャップにたじろぐ前に、適切なアドバイスをしたいと考える。

１．２　おかしい、バグだらけの研修プログラム？しかし「原理」はどうか？

　ビギナー研修でよくあることだが、おそらく二度と使うことも無いような初心者用プログラムを学ぶことがある。よく見ると細かいバグがあったりする。最新の研究成果には、ほど遠く、必要性も感じられないロジックにうんざりだ。しかし、その感覚や感性は「原理」をよく理解した上でのことだろうか？研修ロジックには、そのままでは実務に適さなくても、歴史的な論理が秘められていることがある。陳腐化した技術だと侮っていると、思わぬ墓穴を掘ることになる。よく言われることだが「古きを訪ねて新しきを知る」である。これは、ソフト業界でも同じだ。基本が大切だ。基本をおろそかにして、まるで定期テストを乗り切るような態度では、落ちこぼれることになる。どのような技術研修でも「原理」などに注目しよう。

１．３　見よう見まねでは危うい。基本と原理が大切だ。

　はじめは誰でも、訳が分からず戸惑うのもだ。これは仕方がないことだ。しかし、なるべく早い段階で原理を理解するようにしよう。先輩から依頼されたことについて、原理はどうなっているのか？ひそかに理解しながら進めることが好ましい。よく「中身は知らなくていいから、手順通りにやってくれ」と頼まれる。これは仕事だ、やむを得ず。だが、いつまでも知らないと、同輩と差がついてくる。任された仕事は、どのような仕事でも動作原理や「何がどうなるのか？」といった結果を推理することが必要だ。しかし、馬鹿正直に質問攻めでは嫌われる。まずは、自分で考え、先輩やベテランが暇そうなときに質問してみよう。職場では先達を立てることが大切だ。後輩というのは、仕事は、出来すぎても出来なくても嫌われる。良好な人間関係のために適度な会話／コミュニケーションを心がけることだ。

１．４　職場での質問のコツ

　たまに意図不明な、誘導尋問のような質問をする人がいるが、良くない。質問の意味を明確にした上で、相手が忙しくないときに質問する。そもそも、文章も会話も無しに仕事は成立しない。与えられた課題の目的を理解して、わからないことは質問すべき。ほとんどの先輩や上司は質問を待っている。「え！待ってるの？」と驚く人もいるかもしれないが、そういうものなのだ。上司になればわかる。渡した仕事で、一方通行の文章と会話で仕事が出来上がることは珍しい。会話を待っている上役に丁寧に質問しよう。

１．５　出来なくてもあわてない、落ち着いて行動しよう

　任された仕事でつまずくことは、よくある。そもそも、トラブルのないことは無いだろう。しかし、どのようなトラブルでも落ち着いて判断することが大切だ。職場で自分だけが落ちこぼれるような錯覚がある。しかし、慣れるまでは、皆、苦しいのだ。キミだけではない。自分の作業を、なるべく客観的に見て、落ち着いて進めることだ。遅れていても他人の足を引かず、的確に質問すれば、解決方法がひらめくことがある。仕事を渡してくれた先輩や上司に適度な質問をどうぞ。しつこくならないように。そして、どうしても出来なければ、素直にお詫びすることだ。ほとんどの場合、一言のお詫びで済む。まれに課題の方が間違っていたということがある。それでも興奮せず、騒がず、大人げある態度で乗り切ることだ。職場では、自分に厳しく、他人に寛容な人物の評価が高くなる。自分の過ちは素直に認め、他人のあら探しはしないようにしよう。これは職場の常識だ。

１．６　全体を見て自分の役割を判断しよう

　職場では、よく１人で踊る人がいる。出来ても出来なくても大声で騒ぎ、いつも目立っている。職場が明るくなって良いという意見もあるが、いつもいつもトラブルを大声で騒ぎ立てるというのは考えものだ。全体の作業で自分の役割を理解して、自分自身を客観的に見ることが必要だ。そうすれば「できなくても大したことはない」ということがわかるし、代替手段も思い浮かぶ。丁寧に提案すればよい。しかし、改善案は、出来ずに提案よりは、無駄と思える作業でも、出来たタイミングで提案することが良い。職場は、机とパソコンから成るのではなく、「人」で出来ている。社会人としての常識が必要だ。自分の役割をしっかり理解した上で業務に当たろう。

１．７　やはり遅刻は嫌われる、職場には早めに出かけよう

　与えられた仕事がうまくいかず遅刻する人がいる。ほとんどの職場では、そのような人に優しい。しかし、仕事を渡した先輩や上司は、実は心配しているのだ。とくに、初めて部下を持った新米上司は、やきもきしているに違いない。仕事が遅れているときほど、早めに出社して質問などを練っておくことが好ましい。いかにも苦しいというような態度で、遅刻を繰り返すことは避けるべきだ。SOSは早めに。「遅刻すれば、わかってくれる」は、あまりに甘い。そのような態度では退職に追い込まれる。気を付けよう。

１．８　いいところを見せようとして失敗。その時は？

　高学歴、あるいは、有名専門学校で高度なロジックをこなした人は、ちやほやされる人が多い。入社早々、エースのように扱われ、実際、期待に応えたりする。すると、だんだん油断が出てくる。高度なロジックを褒められて舞い上がるのだ。その褒め言葉は、お世辞だ。そして嫌味だったりする。油断するな。

　よくあることだが、他人が理解できず、自分だけがわかるロジックで自慢げな人がいる。ソースコードについて教えてもらいたい人は丁寧に頭を下げてくる。その丁寧な態度で気づかない。ほとんどの場合、実は「嫌われている」のだ。それが理解できるだろうか？簡単なことだ、自分が逆の立場ならどうか？さらには、複雑なロジックでバグがあったりすると大変だ。「ロジックは明解でわかりやすいものが、吉／good」なのだ。複雑なロジックで、いいとこを見せようとしてはならない。絶対にダメだ。気を付けよう。もし、失敗したら、その時、・・・素直にお詫びすべきだ。あっさりと。そして、関係者と一緒に解析するのだ。

１．９　この程度のロジックなら誰でもできる、と言われたら、悔しいか？

　悔しいだろうか？「そりゃ悔しいだろ」という方は、ソフト業界の人ではないだろう。複雑なロジックで失敗して会社や他人に迷惑をかけた経験のある人なら、怒らないし悔しくない。むしろ、ほっとする。それでいいのだ。複雑なロジックになってしまい、仕様も満たせない上、動作しない、というのは恐ろしい事なのだ。作った本人ですら理解できない状態で10000行も書き直しということになれば、ほんとに社は倒産するかもしれない。大変なことだ。長いプログラムでも「誰でもできる、わかる」と言われれば、ありがたい。それで助かる。このことを理解していただきたい。業務の初心者の皆さん、「誰でもできる、わかる」がいいのだ。高度なロジックを、わかりやすく実装できることが、よろしいのだ。それが、昨今のプロが目指すところであり、多くのソフトウェア技術者にとっての理想である。それを早く理解してもらいたい(しかし、あまりに解析しやすいソースコードはセキュリティ上の問題はある)。

１．１０　プログラムがわからないＳＥって、どうなのか？

　好ましくない、あっさりと。すまない。何か気の利いた文言を期待していた人もいるかもしれないが・・・。今からでも遅くない。ＳＥとして上級ＰＧと相談したり、一般ＰＧを率いるのに、ある程度の知識や素養は必要だ。また、部下であるＰＧの立場や苦しさが理解できないといけない。プログラミングの実務経験が全く無くて、それらのことが理解できるだろうか？どこかの設計会社の口車に乗り、プログラムとかロジックとか、全く学ばなかったという人、意欲があれば、できるのだ。学ぶのだ。なんでもいいから有名言語を自分でいじってみよう。簡単なプログラムを書いてみよう。プログラムの本質は「入力 → 処理 → 出力」である。それを理解しながら作ってみてください。

１．１１　テスターって何するの？

　いわゆるシステムのテスティングだ。テストだ。納品前に動作を確認して、要求仕様を満たしているかどうかテストする。テスト仕様書に基づき、入力値を与え、仕様どおりにデータが蓄積され、入力に応じた画面、帳票など、正しい結果が出力されるかどうか、チェックする。システムの目的や機能がわかっていないとテストはできない。最近は、かけ出しＳＥ(システムエンジニア)の仕事になっていることが多い。結合テスト(全体テスト)前の、個々のプログラムの動作確認は、単体テストと呼ばれ、それぞれのプログラマの仕事だ。

2017/04/10 16:59:12

ソフトウェア開発業務の実際

タイトル：「ホントは厳しいソフトウェア開発の実務」

第１章 ソフトウェア開発業界に入る

１．１　厳しいの？ソフト業界

　あちらこちらに、ソフトウェアがある時代だ。パソコンや携帯電話、家電や自動車など、あるいは、社会インフラにも、ソフトウェアは、なくてはならないものになってしまった。ソフトウェア開発／販売は、人気の産業となり、日ごろオンラインゲームなどで遊んでいる少年も、将来はソフトウェア技術者になりたいという人は多いだろう。しかし、ソフトウェア開発の実務は厳しい、とよく聞く。頭脳労働の最たるものであり、デスクワークなのに過酷な労働環境、と言われて久しい。学校を出たばかりの知的な若者が、様々な夢をいだいて業界に押し寄せて来る。果たして現実のソフトウェア開発は、どのようなものだろうか？夢と現実のギャップにたじろぐ前に、適切なアドバイスをしたいと考える。

１．２　おかしい、バグだらけの研修プログラム？しかし「原理」はどうか？

　ビギナー研修でよくあることだが、おそらく二度と使うことも無いような初心者用プログラムを学ぶことがある。よく見ると細かいバグがあったりする。最新の研究成果には、ほど遠く、必要性も感じられないロジックにうんざりだ。しかし、その感覚や感性は「原理」をよく理解した上でのことだろうか？研修ロジックには、そのままでは実務に適さなくても、歴史的な論理が秘められていることがある。陳腐化した技術だと侮っていると、思わぬ墓穴を掘ることになる。よく言われることだが「古きを訪ねて新しきを知る」である。これは、ソフト業界でも同じだ。基本が大切だ。基本をおろそかにして、まるで定期テストを乗り切るような態度では、落ちこぼれることになる。どのような技術研修でも「原理」などに注目しよう。

１．３　見よう見まねでは危うい。基本と原理が大切だ。

　はじめは誰でも、訳が分からず戸惑うのもだ。これは仕方がないことだ。しかし、なるべく早い段階で原理を理解するようにしよう。先輩から依頼されたことについて、原理はどうなっているのか？ひそかに理解しながら進めることが好ましい。よく「中身は知らなくていいから、手順通りにやってくれ」と頼まれる。これは仕事だ、やむを得ず。だが、いつまでも知らないと、同輩と差がついてくる。任された仕事は、どのような仕事でも動作原理や「何がどうなるのか？」といった結果を推理することが必要だ。しかし、馬鹿正直に質問攻めでは嫌われる。まずは、自分で考え、先輩やベテランが暇そうなときに質問してみよう。職場では先達を立てることが大切だ。後輩というのは、仕事は、出来すぎても出来なくても嫌われる。良好な人間関係のために適度な会話／コミュニケーションを心がけることだ。

１．４　職場での質問のコツ

　たまに意図不明な、誘導尋問のような質問をする人がいるが、良くない。質問の意味を明確にした上で、相手が忙しくないときに質問する。そもそも、文章も会話も無しに仕事は成立しない。与えられた課題の目的を理解して、わからないことは質問すべき。ほとんどの先輩や上司は質問を待っている。「え！待ってるの？」と驚く人もいるかもしれないが、そういうものなのだ。上司になればわかる。渡した仕事で、一方通行の文章と会話で仕事が出来上がることは珍しい。会話を待っている上役に丁寧に質問しよう。

１．５　出来なくてもあわてない、落ち着いて行動しよう

　任された仕事でつまずくことは、よくある。そもそも、トラブルのないことは無いだろう。しかし、どのようなトラブルでも落ち着いて判断することが大切だ。職場で自分だけが落ちこぼれるような錯覚がある。しかし、慣れるまでは、皆、苦しいのだ。キミだけではない。自分の作業を、なるべく客観的に見て、落ち着いて進めることだ。遅れていても他人の足を引かず、的確に質問すれば、解決方法がひらめくことがある。仕事を渡してくれた先輩や上司に適度な質問をどうぞ。しつこくならないように。そして、どうしても出来なければ、素直にお詫びすることだ。ほとんどの場合、一言のお詫びで済む。まれに課題の方が間違っていたということがある。それでも興奮せず、騒がず、大人げある態度で乗り切ることだ。職場では、自分に厳しく、他人に寛容な人物の評価が高くなる。自分の過ちは素直に認め、他人のあら探しはしないようにしよう。これは職場の常識だ。

１．６　全体を見て自分の役割を判断しよう

　職場では、よく１人で踊る人がいる。出来ても出来なくても大声で騒ぎ、いつも目立っている。職場が明るくなって良いという意見もあるが、いつもいつもトラブルを大声で騒ぎ立てるというのは考えものだ。全体の作業で自分の役割を理解して、自分自身を客観的に見ることが必要だ。そうすれば「できなくても大したことはない」ということがわかるし、代替手段も思い浮かぶ。丁寧に提案すればよい。しかし、改善案は、出来ずに提案よりは、無駄と思える作業でも、出来たタイミングで提案することが良い。職場は、机とパソコンから成るのではなく、「人」で出来ている。社会人としての常識が必要だ。自分の役割をしっかり理解した上で業務に当たろう。

１．７　やはり遅刻は嫌われる、職場には早めに出かけよう

　与えられた仕事がうまくいかず遅刻する人がいる。ほとんどの職場では、そのような人に優しい。しかし、仕事を渡した先輩や上司は、実は心配しているのだ。とくに、初めて部下を持った新米上司は、やきもきしているに違いない。仕事が遅れているときほど、早めに出社して質問などを練っておくことが好ましい。いかにも苦しいというような態度で、遅刻を繰り返すことは避けるべきだ。SOSは早めに。「遅刻すれば、わかってくれる」は、あまりに甘い。そのような態度では退職に追い込まれる。気を付けよう。

１．８　いいところを見せようとして失敗。その時は？

　高学歴、あるいは、有名専門学校で高度なロジックをこなした人は、ちやほやされる人が多い。入社早々、エースのように扱われ、実際、期待に応えたりする。すると、だんだん油断が出てくる。高度なロジックを褒められて舞い上がるのだ。その褒め言葉は、お世辞だ。そして嫌味だったりする。油断するな。

　よくあることだが、他人が理解できず、自分だけがわかるロジックで自慢げな人がいる。ソースコードについて教えてもらいたい人は丁寧に頭を下げてくる。その丁寧な態度で気づかない。ほとんどの場合、実は「嫌われている」のだ。それが理解できるだろうか？簡単なことだ、自分が逆の立場ならどうか？さらには、複雑なロジックでバグがあったりすると大変だ。「ロジックは明解でわかりやすいものが、吉／good」なのだ。複雑なロジックで、いいとこを見せようとしてはならない。絶対にダメだ。気を付けよう。もし、失敗したら、その時、・・・素直にお詫びすべきだ。あっさりと。そして、関係者と一緒に解析するのだ。

１．９　この程度のロジックなら誰でもできる、と言われたら、悔しいか？

　悔しいだろうか？「そりゃ悔しいだろ」という方は、ソフト業界の人ではないだろう。複雑なロジックで失敗して会社や他人に迷惑をかけた経験のある人なら、怒らないし悔しくない。むしろ、ほっとする。それでいいのだ。複雑なロジックになってしまい、仕様も満たせない上、動作しない、というのは恐ろしい事なのだ。作った本人ですら理解できない状態で10000行も書き直しということになれば、ほんとに社は倒産するかもしれない。大変なことだ。長いプログラムでも「誰でもできる、わかる」と言われれば、ありがたい。それで助かる。このことを理解していただきたい。業務の初心者の皆さん、「誰でもできる、わかる」がいいのだ。高度なロジックを、わかりやすく実装できることが、よろしいのだ。それが、昨今のプロが目指すところであり、多くのソフトウェア技術者にとっての理想である。それを早く理解してもらいたい(しかし、あまりに解析しやすいソースコードはセキュリティ上の問題はある)。

１．１０　プログラムがわからないＳＥって、どうなのか？

　好ましくない、あっさりと。すまない。何か気の利いた文言を期待していた人もいるかもしれないが・・・。今からでも遅くない。ＳＥとして上級ＰＧと相談したり、一般ＰＧを率いるのに、ある程度の知識や素養は必要だ。また、部下であるＰＧの立場や苦しさが理解できないといけない。プログラミングの実務経験が全く無くて、それらのことが理解できるだろうか？どこかの設計会社の口車に乗り、プログラムとかロジックとか、全く学ばなかったという人、意欲があれば、できるのだ。学ぶのだ。なんでもいいから有名言語を自分でいじってみよう。簡単なプログラムを書いてみよう。プログラムの本質は「入力 → 処理 → 出力」である。それを理解しながら作ってみてください。

１．１１　テスターって何するの？

　いわゆるシステムのテスティングだ。テストだ。納品前に動作を確認して、要求仕様を満たしているかどうかテストする。テスト仕様書に基づき、入力値を与え、仕様どおりにデータが蓄積され、入力に応じた画面、帳票など、正しい結果が出力されるかどうか、チェックする。システムの目的や機能がわかっていないとテストはできない。最近は、かけ出しＳＥ(システムエンジニア)の仕事になっていることが多い。結合テスト(全体テスト)前の、個々のプログラムの動作確認は、単体テストと呼ばれ、それぞれのプログラマの仕事だ。

２章 ソフトウェア開発の実際

２．１　業務用ソフトウェアシステムの開発の流れ

　ここでは、要求仕様のまとめから、納品までを理解してみる。営業さんなどがシステムの開発案件を持ってくる。要求仕様のまとめが始まる。ＳＥは、顧客の業務を理解して、あるいは、客先で業務を調べながら、顧客と打ち合わせの上、要求仕様をまとめて文書にする。要求仕様の大半が機能ということになる。次に、仕様に応じた基本設計だ。求められる機能に基づき、端末の画面入出力、プリンタでの帳票(一覧表が多い)、これらの入出力のためのデータベースのテーブル(レコード)設計を行う。その設計は、基本設計書として紙やパソコンファイルにまとめられる。これらの成果物からプログラムの詳細設計が行われる。これは、上級プログラマ／ＰＧの仕事だ。また、用いるプログラム言語や、サーバ／クライアント装置、データベースなどの基本インフラが確定する。それぞれのサブシステムの仕様に基づき、上級ＰＧがプログラムのひな型を作成する。それを修正する形でプログラミングが行われる。ほとんどの場合、ＳＥと上級ＰＧの指導により、一般のＰＧが作業する。プログラムができると単体テストが繰り返され、それらが結合されて全体のテストが行われる。いわゆる結合テストだ。テストの結果が満足できるものであると、客先に配置され現場テストになる。ここで合格すれば納品だ。

　・

　・

　・

　図？．業務用ソフトウェアシステムの開発の流れ

２．？　一般的な業務用システムって何があるの？

　何か商売をしている会社のシステムなら、次のようなものがある。社員管理、給与計算、顧客管理、在庫管理、仕入れ管理、原価計算、製造管理、販売管理、売上集計、税務管理、経営情報、Web広報／広告などが一般的だ。これらは、相互に関連して動く、主に、蓄積されるデータで連動している。最近では、データの大半は、ＲＤＢ、つまり、リレーショナルデータベースに蓄えられる。これらの業務は、どの会社でも似通っており、規格化されたパッケージソフトもある。

２．？　要求仕様のまとめと基本設計

　いわゆるリーダーＳＥ(システムエンジニア)が仕様をまとめる。つまり「要求仕様」だ。ユーザー／顧客の業務を分析して理解した上で、ユーザーがほしいシステムの目的、全体像、機能を、文章／表／図にまとめる。客先に常駐して業務を調べながらヒアリングすることが多い。また、費用／コストを見積る。さらに、それらをわかりやすい説明資料にしてプレゼンテーションを行い、提案する。営業としての側面がある。会話が苦手では不利になる。交渉術も必要だ。

　購入／導入／調達が決まると、いよいよ基本設計だ。基本設計では、システムの目的を細分化した上でサブシステムに分け、入出力画面設計、帳票定義、それに合わせたデータベース設計などを行う。ほとんどの場合、出力結果が大事であり、そのための入力だ。これらは、複数のＳＥが投入され、それぞれのＳＥが中心となる個別のチームで行う。業務の調査や設計の打ち合わせも、さらに細かくなる。顧客の業務に精通することが大切だ。

　また、共通機能を規格化して横断的に展開することが必要であり、ＳＥ間のチームワークも要る。リーダーＳＥは、上級ＰＧと相談して、実現可能な仕掛けやロジックをにらみながら、システムの目的が果たせるよう基本設計を行っていく。

　さらに、ＰＧの仕事ぶりや、プログラムで可能なことを理解する。実現できない仕組みを提案してはトラブルになる。また、工数／費用がわからないのでは、見積りも難しい。顧客やＰＧとの交渉能力が期待される。プログラムや言語がわからないＳＥでは交渉能力が疑われる。気を付けよう。

２．？　システムの目的とは？

　ユーザーがほしいシステムの目的を定義する。それらが不明確だと機能が散漫になり、何がしたいのか理解できないようなシステムになる確率がある。システムの目的を明確にする必要があるのだ。定義が不明確で欲張りなユーザーだと、いたずらに機能が増え、システム本来の目的からはずれてしまうこともある。気を付けよう。ユーザーにとって自分が任されたシステムは面子もあり高機能を望みがちだ。便利な機能はコストが掛かるものだ(技術力の問題でもあるが)。システムの目的と適用範囲を文章と図で明確にしておけば、このようなトラブルも防げる。しっかりと定義しよう。

２．？　ユーザーの業務って、すぐにわかるの？

　わからない。ユーザーと言っても、いろんな人がいる。システム担当者は多弁な人が多いが、実際の業務を知る人は様々だ。そもそも、システムができたら、お払い箱になるかもしれない人がいる。そのような方々は口が重い。また、嫌われる。できたら人員整理されるかもしれないのだ。当然だ(このような仕事は断った方がいいのだが・・・)。　人を大切にしない企業は大変だ。整理解雇のためにシステムを作ってくれ、というところもある。そのような仕事は断るべきだ。

　話は元に戻るが、まともなユーザーから業務のノウハウを聞き出すことは簡単ではない。まずは、予備知識が要る。現場のベテランの話を聞くのも、予備知識があるのと無いのとでは、大きな結果の違いになる。忙しいときに、不勉強で誠実でない者に応えるてくれる人はいない。自宅や会社で、まじめに予備知識に取り組むべきだ。そのためには、ある程度、個人の時間を費やすことも必要だ。

　また、システムの目的と有効性を現場の人に理解していただく。整理解雇のためのものではない、ということを。「このシステムができれば、現在の限られた人数で生産性が２～３倍になる」とか。誰も辞めなくていいですよ、とか。当然、だましてはいけない。また、システムの目的と適用範囲がしっかりしていれば、ＳＥもだまされずに済む。人を活かした上で、システムを導入した会社が発展するよう努めるのだ。それが、正当なＳＥのまともな仕事である。

２．？　要求仕様のまとめ方

　システムと一口に言っても、いろいろな形態がある。集計結果の情報を閲覧して経営判断に役立てるものや、給与振り込みシステムと連動した給与情報作成システム、あるいは、何かの生産装置を動かすための製造命令を作成するシステムなど、様々だ。確定したシステムの目的に従い、ユーザーが何をしたいのか？を理解する。プログラムの本質は、「入力→処理→出力」だが、どのような出力がほしいのか？そのための入力情報は何で、どのように処理すれば良いのか？このような事柄をにらみながら、要求をまとめる。これらが、要求仕様となる。

　具体的には、業務を理解した上で、現場サイドでベテラン社員などにヒアリングを行い、目的に従ったリクエスト／要求を書いていく。メモするのだ。自分の言葉で書くのだ。そのためのノートや筆記用具が必要だ。最近は、メモを元にパソコンやスマートフォンで文書ファイルを起こすのだろう。たかがメモとあなどるなかれ、一言でシステムは生き死にする。必要な事柄を漏れなく記述するように。この「漏れなく」がとても大切になることがある。そのために常に要点を整理しておくことが必要だ。事前の予備知識の勉強と、漏れの無い要求の獲得。しかも、システムの目的に合致しているか判断する。要求仕様の獲得は丁寧に行おう。また、システム固有の便利な機能は、提案という形でまとめる。ユーザーは知らないことが多いが、ベテラン端末要員なら、逆に指摘されることはある。

　また、いくら業務を理解しても、十分に要求が出ないこともある。「とにかく業務ができるようにしてくれ」だとか、「発注を受けたい」だとか、それ以上、具体的な要求がないことがある。システムが何かということを知らないのだ。仕方がない。このようなことも珍しくない。

　そして、要求仕様のレビュー(点検と見直し)はとても大事だ。客先レビューにて要求仕様が確定する。顧客の承認を取り付けることで仕様が確定するのだ。それらは、システムの見積もり／価格に直結する。客が求める仕様が欠落したりすると大問題になる。基本設計が終わったあとで仕様抜けが発覚したりすると設計が根本的にやり直しという事態もあり得る。気を付けよう。また、逆に余計な機能があると価格が高くなる。何度も確認を求めることだ。社内の規則に従い、レビューと承認を重ねよう。

２．？　システム開発の実務

　ここからは、実際に開発を行うイメージで進めてみる。たとえば、一般の業務用システムで、日々の経営に必要な業務管理システムを想定してみる。何か物販商売をしている会社なら、販売管理などが、システムの軸になる。これを考えてみよう。ある会社の販売業務を理解しなければならない。販売とは、大体、何か物品やサービスを売って儲けることだ。顧客からの注文を記録して入金を促す。在庫を確認し、なければ、仕入れ、あるいは、製造する。そして、入金や在庫など、条件が揃ったら、それらを発送／配達する。顧客に物品やサービスが届いて完了したとき、その一連の「受注ー販売業務」が完了するというわけだ。これらをシステム化する。それぞれの段階では、パソコン端末などで状況やデータが確認できることが必要だ。最近では、インターネットと連動するスマートフォンなども、端末として使えるだろう。そして、業務担当者が進行を指示できるようにすべきだ。原則、条件が揃わなければ、先に進めないようなシステムになる。

　ポイントは、入金の有無と在庫だ。ＳＥは、それぞれの端末画面や入力条件、その進行管理をにらみながら、必要な情報と機能をヒアリングで確定していく。仕事ができなような情報漏れがあってはならない。受注伝票には、受注番号、受注日時、顧客名称、商品／サービス名、単価や合計数、合計金額、納期限などが必要だ。これらが抜けていると伝票として機能せず、販売できないことになる。業務の詳細が理解できないと必要な情報が抜けてしまう。ベテランには「わかっていない」と言われる。

　ＳＥは、通常、顧客業務の専門家ではないので、とにかく、勉強させてもらい、必要な情報を発見して揃えるしかない。中には、小難しい計算式がからむものもある。なぜだか、わからないが「これを使ってくれ」と頼まれる。断ることもできないのだ。実は、こっそりと、原理を理解しておくことが好ましい。しかし、業務上の秘密であったりする。要領よく取り組もう。

　大体、販売管理であれば、入力画面で必要な情報を入力して、簡単な四則演算による集計、そして、画面とＲＤＢへのデータ出力ということになる。また、それぞれの伝票の印刷、発行がある。

　通常、システム導入までは、業務は、すべて手作業で行われている。システムが信頼されなければ、これらの手作業はなかなか変更されない。中には「使えないシステム」のレッテルを張られ、部屋の片隅に捨て置かれたりする。厳しいのだ。特に入出金がからむのものは厳しい。気を付けよう。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

２．？ 販売管理システムの要求仕様とシステムの目的

　ここでは、ユーザーは、機械メーカーで、ＪＩＳに従った規格品や特注品の設計、製造、販売を手掛けているとしておこう。１０００人程度の規模で、多数の下請け会社があるという想定だ。この会社における販売管理システムの業務を理解する。　特に、ＪＩＳ規格品の大量生産、販売部門を考える。まず、電話やＦＡＸ、電子メールなどで、顧客や営業さんから受注部門に注文が来る。その注文を端末画面から入力して受注となる。在庫を確認して、入金や、その契約を確認して発送だ。在庫が無ければ、仕入れ、製造要請となる。この程度でいいだろう。まずは、要求仕様だ。現場は、係長としてベテランで寡黙なおじさんと、入社して５年以内の若手営業社員、そして、新入社員や、パートのおばさんが居るということにする。

　正当ＳＥとしては、誰に要求仕様を確認するか？・・・答えは、現場のすべての人だ。「あれ、まずは係長じゃないの？」との反応はあるだろう。それは、当然だ。まず、現場の上長に相談する。しかし、それだけでは足りないことが多い。上長は細かい実務を離れて久しく、責任を負ってはいるが、実際の業務はパートのおばさんに任せているとか・・・。そんなことが多い。上長からは、２０年前の実務の話しか聞けないとか、綿密に打ち合わせたつもりが、現在の業務は違うとか？スマートフォンって何だ？というような話になる。実務は現役に話を聞かねばならない。これは、鉄則である。どのような仕事でも、毎日、努力している人は尊いのだ。少々、脱線したが。話を元に戻す。ところで、現場の皆さんに伺ったところ、次のような要求メモになった。どうだろうか？表？に示す。

　「要求仕様のメモ」

　・とにかく、業務ができるようにしてくれ。つまらんパソコン操作はいらない。

　　＞ユーザーＩＦは簡単にすべきだ。

　・受注だ。注文情報が欠けないようにしてくれ。特に、単価と数量を間違えないように。

　　＞受注情報が軸でいいだろう。たぶん、そうだ。

　・顧客を簡単に選べるようにしてくれ。コード表による入力だと、アルバイターが間違える。

　　＞ポップアップにするか、別画面に遷移するか？

　・発送指示のとき、在庫が確認できるように。

　・発送指示のとき、入金の有無が確認できるように。

　　＞月末締めの入金見込みのステータスが要るな。

　・伝票を印刷してくれ。起こすのが大変なんだ。知ってるか？

　　＞何か特別な項目があるのだろうか？

　・画面で商品を選べるようにしてくれ。以前のシステムは登録が無かった。

　　＞登録漏れか？よくわからない

　・客先への納品を確認して記録できるようにしてくれ。

　表？　現場での要求仕様のメモ

　これらのメモを検討すると、雑多な要求で、間違いもあったりする。実務がよくわからん人だと嘘や誇張もある。メモの内容から真実の情報を抽出して、適切に方向づけないといけない。現場の業務がわからないと情報の吟味ができないのだ。どうだろうか？これから、次のような要求仕様となる。表？に示す。これは、客先レビューで確定前といったところだ。この程度では、仕様は確定しない。ユーザーレビューで倍ぐらいに膨らむこともある。仕様や設計の打ち合わせは効率よく行いたいが、１度や２度では決まらないものなのだ。業務がわからないところは、ある程度、推理して書くしかない。たたき台を用意することだ。何もわからず、たたき台の文章も無いとなると仕事にならない。現在でも、はじめて、システム導入するということは、よくある。皆が手探りで作ろうとする。多少、間違っていても、足りなくても良いので、皆が、手がかりにできるような文章がほしいのだ。普通の人々は、ゼロから意見することより、何かを修正する、批判するという動作の方がしやすいのだ。しかし、方向性を間違えてはならない。そこがＳＥの腕の見せ所だ。実は、経験がものを言う。しかし、無いのだ。皆、はじめは、そうなのだ。だから、頑張る。一生懸命、取り組むのだ。

　・システム：販売管理システムの受注・発送管理

　　・目的として、間違いのない適正な受注情報の管理と円滑な業務の進行

　　・適用範囲は、販売品の受注記録から配達完了確認までとする。

　・客先からの注文を記録して受注を確定する。

　　・必要な情報は、受注番号、受注日時、顧客名称、商品／サービス名、単価や合計数、合計金額、納品期限など。

　　　＞実際の伝票があれば拝見する。

　　・単価と数量のチェックを厳格に行う。数値の丸め、切り捨てなども確認する。

　　　＞１円以下の単価設定があるか？あるいは、１円桁の切り捨てとか。

　・ユーザーＩＦは、誰でも操作できるような、わかりやすいものにする。

　　・顧客が簡単に選べるようにする。

　　・商品が簡単に選べるようにする。

　・発送指示が出せること。

　　・発送指示のとき、在庫が確認できるように。

　　・発送指示のとき、入金の有無が確認できるように。

　　　・「入金見込みのステータス」について相談。手形決済など。

　・伝票が印刷、発行できること。

　　＞再発行について確認

　・客先への納品を確認して入力できる。その情報を適切に管理できる。

　※検索機能の実装を確認する。

　表？　ユーザーレビュー前の要求仕様のまとめ(たたき台)

　次に、ユーザーレビューで修正された要求仕様を示す。再度の打ち合わせにより仕様決めが進んでいることがわかる。このように、仕様決めや調整が進んでいくのだ。

　・システム：販売管理システムの受注・発送管理

　　・目的として、適正な受注情報の管理と円滑な業務の進行。

　　・適用範囲は、販売品の受注入力から配達完了確認までとする。

　・ログイン機能

　　・業務担当者ごとに、ログインＩＤを設ける。

　　　・機能へのアクセスを制限する

　　　・操作ログを記録する。

　・客先からの注文を入力して受注を確定する。また、修正／削除など管理できる。

　　・必要な情報は、受注番号、受注日時、顧客名称、商品／サービス名、単価や合計数、合計金額、納期限など。

　　　＞実際の伝票があれば拝見する。

　　　＞発送していない受注情報の期限の扱い。

　　　＞納品完了情報の扱い。保管期限など。

　　・単価と数量のチェックを厳格に行う。数値の丸め、切り捨てなども確認する。

　　　・警告メッセージやダイアログが表示されること。

　　　＞１円以下の単価設定があるか？あるいは、１円桁の切り捨てとか。

　　・ユーザーＩＦは、誰でも操作できるような、わかりやすいものにする。

　　　・顧客が簡単に選べるようにする。

　　　・商品が簡単に選べるようにする。

　・受注情報が、すばやく検索できること。

　　・受注を確認したいとき。

　　・受注情報を修正、削除するとき。

　　・発送指示のとき。

　　・納品完了確認のとき。

　・発送指示が出せること。

　　・発送指示のとき、在庫が確認できるように。

　　・発送指示のとき、入金の有無が確認できるように。

　　　・「入金見込みのステータス」について相談。手形決済など。

　・客先への納品を確認して、情報を登録できる。その情報を適切に管理できる。

　　＞受注情報に「納品完了」ステータスを記録。

　・伝票が印刷、発行できること。

　　・受注伝票が発行できる。

　　・発送指示書が発行できる。

　　・配達先ラベルが印刷できる。

　　・納品書が発行できる。

　　・納品先顧客に記入してもらう受領書を発行できる。

　　＞現在、請求書、領収書はどこで発行しているか？

　　＞再発行について確認

　　＞それぞれの機能での入力権限の設定機能はどうするか？

　－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

　表？　１回目ユーザーレビュー後の要求仕様のまとめ

２．？ 販売管理システムの機能と画面構成

　まず、業務の流れを考え、確定した仕様から、必要な機能と画面を決めていく。顧客からの注文を入力するので、注文を入力する画面があるだろう。出来上がった受注情報に対して、入金確認、在庫確認を行い、発送指示を行う。ここで、受注入力と、発送指示は同じ画面でよいかどうかを考える。同じでよいだろうか？そもそも受注を確定させる処理と、発送指示では、業務が異なる。確か担当者が別だった。発送指示のときに、勝手に受注情報を変更されても困る。やはり、別にするか？このように機能や画面構成を考えていくのだ。これらの設計の勘案には、システムの常識と「業務知識」だ。両方がわかっていないと設計はできない。通常、全うな開発会社なら、ＰＧとしてシステムの常識を覚え、そして、ＳＥとして顧客業務に取り組み、これらのノウハウを身に着ける。どちらのことも、理解すべきなのだ。

　ここでは、受注担当者と発送担当者が別で、別画面の構成にしてみる。受注入力では、顧客や商品、数量などを確定させ、受注情報を作成して次の処理に送る。また、受注伝票を発行するということにする。

　要求仕様が確定したとして、最初の機能の発案としては、大体、次表のようになる。表？に示す。これらは、業務の詳細により、様々に変化する。たとえば、これらの機能が１つの画面にまとまっていることもある。画面の割り付けは、１つの例として「検索 ＞ 一覧 ＞ 詳細」というパタンが多い。また、現場の規模を含む商慣習により、細かい仕様が異なる。機能として疑問があり、すぐに結論がでないときは、課題としておく。

　当然、各機能の連動や進行管理も、それぞれの現場で異なる。あまりに固い連動だと、実際の商売とマッチせず、システムとして嫌われることになる。たとえば、上得意の客の都合で入金が遅れるとき、恩返しに商品を先を出したいということはあり得る。そんなときに、「システムの都合で無理」となると、ユーザーは、客の信頼を失うことになる。やはり、システムが嫌われる。

　「機能の検討と設計の一例」

　・ログイン機能

　　・業務担当者ごとに、ログインＩＤを設ける。

　　　・機能へのアクセスを制限する

　　　・操作ログを記録する。

　・受注(注文入力)機能

　　・機能：

　　　・受注情報検索。

　　　・既に入力された受注情報を参照する。

　　　　・販売状態を参照できる。

　　　　　・仕入れ／製造待ち、発送待ち、発送済、配達中、配達済み。

　　　　・伝票が未発行なら、受注伝票が発行できる。

　　　　　※再発行をどうするか？

　　　・既に入力された受注情報を修正する(取り消しを含む)。

　　　・注文情報を新規入力する。

　　　　・データ：受注番号、受注日時、顧客名称、商品／サービス名、単価や合計数、合計金額、納期限

　　　　・在庫の有無を表示する。

        　　・無ければ、仕入れ、あるいは、製造を要請する。

　　　　・予定納期を表示する。

　　　　・受注確定で、受注番号を採番。受注日時も確定。

　　　　　・受注伝票が発行できる。

　　　　※受注情報の二度入力にどのように対応するか？

　　　　　・検索で類似情報を確認してもらい、無ければ新規作成していただく。

　・発送指示機能

　　・機能：

　　　・受注情報検索して、受注情報に対して発送を指示する。

　　　　・在庫を確認する。

　　　　　・無ければ、仕入れ、あるいは、製造を要請する。

　　　　・入金を確認する。

　　　　　・入金が無いとき、どうするか？

　　　　　　・上得意の信頼できる客であれば発送できるようにするか？

　　　　　　　・顧客管理との連動が発生する。

　　　　・納品書を発行する。

　　　・発送担当者のとき、受注入力は、機能しないこと。メニューで非活性になる。

　・納品完了確認機能

　　・機能：

　　　・受注情報検索して、受注情報を表示。

　　　　・客先へのお届けを確認する。

　　　　　・客先への届けは、電話確認、電子メール、その他の方法と連動。

　　　　　・受注情報に対して納品完了を入力

　　　　・販売状態を表示。

　　　　　・仕入れ／製造待ち、発送待ち、発送済、配達中、配達済み。

　表？　販売管理の機能の検討と設計の例

　－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

　「画面構成の検討の一例」

　・受注入力画面

　　・受注情報検索

　　　・受注情報参照

　　　　・受注情報修正

　　　　・受注情報削除

　　・受注情報新規作成画面

　・発送指示画面

　　・受注情報検索

　　　・発送指示入力

　・納品完了確認画面

　　・受注情報検索

　　　・配達完了確認

　　　　・配達完了入力

　表？　販売管理の画面構成の検討の例

２．？　具体的な画面のデザインと構成、画面遷移

　ここでは、具体的な画面のデザインと構成、画面間の移動(画面遷移)を検討する。階層メニューを基本として、なるべく単一機能で、画面を構成するとなると、たとえば、次のようになる。これらは、ある程度、１つにまとめられたり、メニューが省略されたりすることになるが、誤操作、誤入力を防ぐことが大事だ。工数や仕様書の削減が目的で、そのあたりが犠牲になるというのは、おかしい。多少、面倒でも、わかりやすく。オペレータが混乱しないような画面構成が好ましい。

　-------------------------------------

　販売管理 ＞ 受注・発送業務メニュー

　　１．受注入力

　　２．発送指示

　　３．納品確認

　-------------------------------------

　-------------------------------------

　販売管理 ＞ 受注・発送業務 ＞ 受注入力メニュー　

　　１．受注情報を検索 

　　２．受注情報を新規作成

　-------------------------------------

　------------------------------------------------------------------

　販売管理 ＞ 受注・発送業務 ＞ 受注入力メニュー　

　　１．受注情報を検索 

　　　受注番号 [           ]

　　　受注日時 [    　   ][▼]年 [   ][▼]月 [   ][▼]日 ～ [ 　     ][▼]年 [   ][▼]月 [   ][▼]日 

　　　顧客名称 [                                                            ]

　　　製品名称 [                                                            ]

　　　　　　　 [                                                            ]

　　　　　　　 [                                                            ]

　　　納期　　 [    　   ][▼]年 [   ][▼]月 [   ][▼]日 

　　　　　　　　　　　　　　　　　                                        　[検索]　[メニューに戻る]

　------------------------------------------------------------------

２．？　データベースのテーブル設計

３．？　詳細設計の実務

４．？　デバッグとテスト

５．？　客先への納品と保守点検

６章 歴史ある技術を学ぶ

あとがき

//////////////////////////////////////////////////////////////////