新人エンジニア向け：ウォータフォール型プロジェクト管理の考え方
エンジニアになったばかりの頃、「ウォータフォール型って聞いたことはあるけど、正直ピンとこない」という人は多いと思います。
アジャイルが流行っている今、「古いやり方」と言われることもありますが、たかはし主任の現場でも普通に使われています。特に基幹システムやネットワークの構築ではウォータフォールが基本です。
ウォータフォール型の基本はシンプルで、
要件定義 → 設計 → 構築 → 試験 → 導入 → 運用
を上から順番に進めていく、という考え方です。
これ、実は特別なことではなく、普段の生活でも似たようなことをやっています。
要件定義：何を作るか決める（夕食を決める）
要件定義は「何を作るのか」「何を求められているのか」を決める工程です。
夕食づくりで言えば、
「今日は何を作る？」
「何人分？」
「子どもいるから辛いのはなし」
「19時には食べたい」
みたいな話をするところです。
ここをあいまいにしたまま進むと、
「量が足りない」「思ってたのと違う」「そもそもカレーのつもりだったの？」
という事故が起きます。
システム開発でも同じで、要件定義が甘いと、後の工程が全部しんどくなります。
お客様が用意する「調達仕様書」や「要件定義書」はお客様が必要としているモノを言語化したものですが、お客様もその道のプロでない場合があり、たとえば表現が曖昧であったり、人によって解釈に差があったりなど、要件の認識齟齬が「必ず」起きます。
その認識齟齬をなくすためにプロジェクト開始時にお客様と要件を明確に定義することがとても大切です。目指すべき方向を間違えて進み続けてしまうと、時間がたてばたつほど修正する範囲が広くなり、かかる時間やコストも膨大になります。
新人のうちは特に、「仕様が決まってない状態で作り始める怖さ」を覚えておいてほしいです。
設計：どうやって作るか考える（段取りを決める）
設計は「どう作るか」を決める工程です。
夕食なら、
・どんな材料を使うか
・どの順番で調理するか
・同時にできる作業は何か
を考えますよね。
設計は地味ですが、ここを雑にすると後で必ずツケが回ってきます。
現場でよくある「設計すっ飛ばして実装した結果、後から全部直す羽目になる」やつです。
構築：実際に作る（料理する）
構築はいわゆる実装フェーズ。コードを書いたり、環境を作ったりします。
レシピ（設計）通りに作っているつもりでも、
「思ったより時間かかるな」とか「ここやりづらいな」というズレは出ます。
それでも、この段階では勝手にメニューを変えないのがポイントです。
試験：ちゃんとできてるか確認（味見）
試験は味見です。
・ちゃんと火は通っているか
・味はおかしくないか
・想定通り動くか
ここで問題を見つけて直すのが理想です。
本番でバグが出るのは、「味見をサボった料理をそのまま出す」のと同じです。
導入：実際に使う（食卓に出す）
導入は、ユーザーに実際に使ってもらう段階です。
食卓に出した瞬間に、
「ちょっと味濃いね」
「思ってたのと違う」
という声が出ることもあります。
ここで初めて見えることも多いので、ある程度は仕方ないです。
運用：使いながら改善する（次回に活かす）
システムは作って終わりではありません。
・問い合わせ対応
・小さな改善
・次のバージョンへの反映
夕食でも「次はもう少し薄味にしよう」と学びますよね。
それと同じです。
要件変更と手戻り：夕食づくりで考える
ウォータフォール型でよく話題になるのが、要件変更による手戻りです。
途中で要件が変わるとどうなるか
たとえば、
「今日はカレー。中辛で、ご飯で食べる」
と決めて、買い物もして、もう煮込み始めているとします。
そこで家族から、
「やっぱり甘口がいい」
「ナンのほうがよくない？」
と言われたらどうでしょう。
要件変更を受け入れるメリット
・食べる人の満足度が上がる
・完成後に不満が出るリスクを減らせる
最終的に喜んでもらえるなら、変更する価値はあります。
要件変更を受け入れるデメリット
・すでにやった作業が無駄になる
・時間もコストも増える
中辛を甘口に戻すのはまだ何とかなりますが、
ナンに変更するなら、そもそも買い物からやり直しです。
大事なのは「影響を説明できること」
ウォータフォール型では、変更を完全に拒否するわけではありません。
大事なのは、
「今この変更をすると、どこまで戻る必要があるか」
「いつまでに終わらせたいかに影響が出るか」
をちゃんと説明できることです。
これは新人のうちから意識しておくと、かなり評価されます。
まとめ
ウォータフォール型は、
・最初にしっかり考える
・順番を守る
・後になればなるほど変更コストは上がる
という、とても現実的な考え方です。
派手さはありませんが、大きな失敗を防ぐための型でもあります。
まずは「各工程が何のためにあるのか」を意識しながら、目の前の作業をやってみてください。
それだけで、プロジェクトの見え方が一段変わってくるはずです。