新卒で会社に入って言葉の定義も教えてもらえず、クラスタによって用語や概念が全く違っていて混乱した人も多いと思う。僕もそうだったのでちょっと整理していきたい。このあたり、PMBOKだの難しい本を長々と読んだりしても*1どうせ役に立たないので僕の考え方を手短に書いておこうと思う。
個人的にはV字モデルというやつはどうもよく分からんし、考えれば考えるほどやりにくいのであんまり好きじゃない。また、そもそも大前提なのだけどウォーターフォールは人間を機械だと思って統計の対象にするので、チームの規模が大きくないと（すくなくとも50人以上が関わる）個々人のばらつきが予測を壊してしまうので大規模開発（笑）が前提だ。
要求定義
そのソフトウェアやシステムで「やりたいこと」を定義する。
要件定義
そのソフトウェアやシステムの開発で検証可能な形でゴールを設定する。また、複数ある要件に矛盾があってはいけない。BIとかいったりする。もしも受発注があるなら、これが終わらないと見積りなんてできない。
基本設計
BDとかいったりする。◯◯機能とかいうのを並べるだけだと思いがちだが、実際にやるべき作業は問題を分割することだ。要件を複数の問題にブレークダウンすることによって分業したり、検討しやすくしたりするためだ。ここで出来上がるのが基本設計書で、開発を通じてのバイブルになる。
ここでのコツは適切な粒度にすること、分割された他の機能のことは知らんと言ってはいけない、実装の骨組みをほとんど決めてしまうこと、くらいかな。
詳細設計
基本設計で分割された問題に従って、ほとんど決めてしまったシーケンスやフローチャートを書き下す。このときあんまり考えてたらダメ。ただの作業なので、なるべくツールを使って効率化すべきなのだがDoxygenはわりと痛い目を見てきたのでアノ手のツールは使わない方がよい。
製造、ユニットテスト
このへんはみなさん得意ですよね、僕は苦手だけど。別にここでTDDってやつをやってもいいと思う。
この工程で出るバグは記録を残しておくとあとで役に立つ。
試験１
ぼくのところではDB1と呼んでたりした。基本設計のときに問題を分割したが、その個々の問題をちゃんと解けているか（各◯◯機能が正しく動いているか）をここで確認する。ここでテストをある程度書いてしまっておくと便利だと思う。
責任者はこの工程から、出てくるバグを全て理解しておかなければならない。
試験２
こっちはDB2だけど、まあシステムとしてトータルで動いているかを確認する。具体的には、要件定義のときに設定したゴールを達成できているかをテストする。わりと人力じゃないとツラいことが多いけど、ここで長安試験（エージング試験）とかをやったりする。
ここでセグフォとかRace Condition系の問題が出ると結構難しくて楽しい。
検収
まあどうせ短い期間しか用意できないので、形式的なものになりがちなのは避けられない。発注側の人がいるなら、発注側の人は最初から開発側と密接にやり取りをしておくべき。どうせ検収の試験で分かるのはわずかなことだけなので。また、受注側の人がいるなら、折をみてきちんと説明しておこう（発注側の信頼を勝ち取っておけば検収は大抵うまくいく）。
振り返り、メトリクス
まあソフトウェア工学いろいろあるので勉強してみるといいんじゃないかな。集計してみるとわりと面白いし失敗したとき上司にうまく説明できると思う。
うまく進めるコツは
- ドキュメントに間違いが見つかったら容赦なく修正する
- 各工程の終了条件を予め決めておくこと（バグ0とか仕様書が出来上がっているとか）。まあ決めておいても、場合によっては一部だけ他の工程に進むとかやってしまってもOK（斜め線表とか言ったりしてた）
- 各工程で常にメトリクスを監視して、スケジュールが遅れそうな要因を早めに潰してしまうこと
- スケジュールが遅れそうな場合、要件を削る（ここ重要、削るのは機能ではなく要件）
- 要件を削れなそうなら容赦なくスケジュールを伸ばす（追加要員は、たとえば50%稼働でプロジェクトに入っていたひとを100%にするとかはアリだがそうじゃないなら意味がない）。ただし伸ばし方は「工程が進むに従って判明した情報をもとに、正しい見積もりをやり直す」
- 上流工程でも重要なポイントなら容赦なく実装の議論をする
くらいだろうか。ちなみに個人的には「仕様書」という言葉はインターフェース定義にしか使ってはいけないと思っていて（◯◯仕様書とか見たら眉に唾をつけるべし）、理由はまあいろいろあるんだけど仕様という言葉が何を意味するかを一度じっくり考えてみないと理解できないのでここでは書かないことにしとく。
*1:読んだことない
