ソフトウェア開発に関心がある方向け。管理人はどちらかというと上流工程のお仕事が多いので、上流工程に関する話題となります。
また以下の内容は、管理人の経験が多いウォータフォールモデルにおけるソフトウェア開発に関するものです。
そしてウォータフォールモデルの開発の実例は星の数ほどあり、教本も多数出ているためモデルや開発に関する基礎的なお話は割愛します。
どちらかというと、携わる工程において「やってきてよかった、こうすればよかった」というような泥臭い内容をメインにしたいと思います。
注意点として開発内容の詳細は守秘義務にかかわるのでフェイクを混ぜ込んだり、あいまいにしているところがありますので、ご注意ください。
各工程において配属されたときに即戦力となるにはどうすればいいか
ソフトウェア開発へ参加するタイミング
開発メンバに選ばれるときに、対象となるソフトウェアの開発工程が常にゼロからとは限りません。言い換えると、ウォータフォールモデルの各工程のうち、要件定義（ゼロ）から携わることもあれば、テスト・検証工程から携わることもあります。こういったタイミングは自身で決めることは難しく、まず選ぶことができません。そのため、どの工程に投入されてもよいように、各工程における「やってきてよかった、こうすればよかった」と感じた管理人の経験を記載します。
各工程について
今回の説明はウィキペディアを参考に、ウォータフォールモデルの工程を定義します。なぜこんなことをするかというと、個々人、会社により工程を表す言葉が異なることが多々あるからです。複数社が関わる開発を経験したことがある方は、覚えがあるのではないでしょうか。
- 要求定義（要求仕様）
- 外部設計（概要設計）
- 内部設計（詳細設計）
- 開発（プログラミング）
- テスト（ソフトウェア）
- 運用（システム）
要求定義
お客さんが何を実現したいのか、実現するための要素が足りているか、把握に努めることを徹底する。まずはこれに尽きるかと思います。
要求定義だけでも相当な経験（黒歴史も含む）がありますが、最も重要なことは上記です。そして往々にしてこの要求を正確に理解できていないことが後工程の火種になります。
隅々まで要求内容を把握することは不可能だという反論もあります。巨大なプロジェクトや開発案件であるほど難しくなります。至極当然なことです。それでもこの工程で失敗するとウォータフォールモデルの開発の特性上、修正することが困難となるため、品質を高く仕上げる必要があります。
ではどうするか。いきなりお客さんの要求の詳細を把握する必要はありません。まずが概要を把握することから始めることが重要です。そのために自分なりの「お客さんの実現したい業務フロー」の絵をノートなどに描き出してください。そしてお客さんや同僚に絵や理解した内容を説明し認識を合わせていってください。お客さんの要求に対する理解が見違えるほど進みます。仕事ができない人を見ていると、これらの認識合わせもせず理解が進んでいないまま仕事を進めている傾向があります。要求定義でこのような進め方をすると致命的となるのでやめましょう。
自分からお客さんの要求に対して質問することも有効です。こういったフローはないのかとか、このフローは不要ではないか、などです。こういった質問とお客さんからの回答を重ねることで、お客さんが本当に重視しているポイント、実現したいポイントや思わぬ漏れを発見することができます。そしてこういった質疑内容はあとから参照できるように必ず文書として記録しましょう。検索しやすい形式にしておくとより良いです。検索しやすい形とは、ファイル分割せずにwikiなどにまとめておくことです。泥臭い話ですが、「ああいった、いやこうだった」という水掛け論を抑止する効果があります。
概要が見えてきたら詳細へ落とし込んでいきます。詳細に落とし込む際もお客さんや同僚との認識合わせ、質問を行います。経験豊富な上司にレビューしてもらうことも重要です。把握が進んできたら絵を図として精度を高めていきます。図にする際は同じものを表すときは資料全体を通して同じ表現を心がけます。すなわち、同じ意味を表すなら同じ図形で同じ色で描画します。要求定義の資料は、ウォータフォールモデルの開発の骨組みです。法律の体系でいえば、憲法のような大本です。しっかり意識して作成する必要があります。
あとがき
長くなったので、いったん切ります。要求定義もまだまだ奥が深く、書きたいこともたくさんです。しかし、まずこれをやっておいたほうが良いという内容に限定してみました。参考になれば幸いです。次は外部設計に関して考えてみたいと思います。
