ウォーターフォールはこう使え（その5）

　ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。

* * *

ドキュメント＝契約書

　なぜドキュメント化が嫌われるのか?

　SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから（結果、後から手直しが多発する）だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日本語に書き直さなければならないか、疑問に思うだろう。

　本当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。本来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。

　これを理解しないまま、ドキュメント排斥を追求すると、思わぬところで足をすくわれる。例えばトラブル。巨大システムもjob sequenceひとつ間違えただけで全面停止になることがある。アナタのアウトプットが起因でトラブルが発生した場合、誰が守ってくれるのか?

　じっさいそういう場面に出くわせば分かるが、誰もアナタの仕事の正当性を保証してくれない…ていうかできない。イザとなったら自分の身は自分で守らないと。そのときの命綱がドキュメントだといえば、少しは怖がってもらえるだろうか。

　「ドキュメント要りませ～ん、開発現場に顧客が同席しているから」

　「動くプログラムから仕様書を自動的に作るから問題ありません」

なんて、どこの研究室の話ですか? あるいはどこの実験「だけの」プロジェクト? とツッコミたくなる。

　顧客はごく少人数で、サービス開始後も同じ開発者が傍らですぐ控えております、なら分かるが、そんなわけない。"顧客"の背後に控えているおおぜいのオペレータの視線を感じたことがないか。目の前の"顧客"を口頭と目視で納得させればOKだなんて、ムシがよすぎやしないか。

　あるいは、ソースから生成した日本語として体を成していないクソ資料を全部読んで理解して、かつ「承認」してくれる顧客がいるならともかく、そんな人間すらいない…ってか「ソースコードが仕様書です」と本気でいう奴はソースから生成したドキュメントを読んだことがあるのか? と問いたい。自分が書いたやつだけでなく、"全部"だ。あれは開発や保守で大づかみに理解したりするために使うんだよおぉぉ。

　ドキュメントを軽視した結果、土壇場になって「オレはそんなこと言ってない、証拠を見せてみろ」と手のひらを返されたことが一度でもあるならば、おいそれと↑のようなセリフは吐けない。ドキュメントとは契約書なのだから。

* * *

ドキュメント＝チーム間の橋渡し

　顧客とベンダとの契約書になるだけではない。チーム内、チーム間の橋渡しの役割もある。アナタが書いたドキュメントは、ひょっとして一度も日の目を見ることがないかもしれないが、必要なときは是が非でも必要となる。

　デスマの火消しに投入されたことはあるだろうか。ウォーターフォールを採用したプロジェクトが燃えている場合、最初に渡されるのが莫大な仕様書（あるいはその残骸）だ。古文書を読み解くが如く、そいつに喰らいつくのが最初の仕事。んで、プログラム動作との Fit/Gap を見つけるのが次の仕事。

　このドキュメント（のあるべき姿）と、目の前で燃えているコード（もしくはテストシステム）の差に対し、3つの切り口がある。

• コードをなんとかして、仕様書どおりに動かす
  
• 仕様書を書き換えて、コードの振る舞いどおりに直す
  
• 動かないところの仕様書を切り離す（段階的にリリースする）
  

　んで、優先度が高い順に財布とカレンダーをにらめっこしながら、コードを書くのかドキュメントを直すのか、あるいは仕切りなおしさせてもらうのか、を選び取るわけだ。

　一方、ドキュメントをちゃんと作っていないプロジェクトが燃えた場合、最悪のことが起こる。

　即ち、「何が本当か分かりません」だ。ソースなのか仕様なのか、誰が本当のことを知っていて（決断できて）、誰がそれを知るべきなのかがぐちゃぐちゃになる。どのチームに影響が出るか分からないから、ミーティングは全員参加、全員周知になる。ソースの修正による影響も特定できないため、全員周知となる。ペアプロじゃなくって全員で同じコードをプログラミングしているようなもんだ。

　いまだに「ソースコードが仕様書です」を胸張って言うプログラマを見かけるたびに、マイクロソフト・ジョーク「それは仕様です」を思い出してこっそり笑わせてもらっている。