「アート・オブ・プロジェクトマネジメント」読書感想文（その6）
■仕様書など書く必要がないと信じているプログラマ
第7章「優れた仕様書の記述」は、こんな一文から始まる―― 「私は昔、仕様書など書く必要がないと信じているプログラマと議論したことがあります」―― 議論の顛末は予想通り。おそらく、このblogを読んでいる全員がこの話をしたことがあるに違いない。各人がどういう結論を持っていようとも、本章から新たな気づきが得られるはずだ。
なぜなら、「優れた仕様書とは何か?」について徹底的に考え・実践してきたことが記されているから。目の前の仕事にとって仕様書が必須/邪魔の話をしているのではなく、もっと本質的なことが書いてある。コードから仕様書を生成するツールとか、仕様書を書く上でのテクニック集といったものは、無い。根っこの部分「そもそもプロジェクトにおける仕様書の目的は?」とか「仕様書によってできること/できないことは何か?」について非常に明解に応えている。
では、プロジェクトにおける仕様書の目的は何か?
- 正しいものの構築を保証する
- プロジェクトの計画フェーズを締めくくるマイルストーンを提供する
- プロジェクトの過程で踏み込んだレビューや各個人からのフィードバックを可能にする
「それなら○○で代替できるじゃねぇか?」というツッコミは可能だ。しかし、著者は続けてこう記している―― こういったことは非常に重要であり、仕様書作成以外のプロセスでその全てを同時に実現することは難しいのです。私が仕様書作成を指示している最大の理由はここにあります ――（太字化は、わたし）
■何をもって「正しい」とするのか（わたしの場合）
仕様書をどのように考えているかは、各人の仕様書にまつわる思い出したくも無い経験に基づくだろう。わたしの場合は1.だ。曖昧な資料で質問はのらりくらりとかわし、イザとなれば独自解釈でねじ曲げてくるオレオレ仕様に泣かされた黒歴史があった。
その結果、仕様をフリーハンドにさせてはいけないという理由で、仕様書を重視している。ただし、カンペキに精緻なものである必要はなく（そんな時間はない）、軽重をつけている。どこに重点をおくか? それは、「正しい」ものを保証させる必要があるもの。後々「正しさ」が議論されるようなところ。
例えば、状態遷移、インタフェース（システムの境界）、ロール（の定義）、業務エラーの定義（エラーの場合の業務フロー）あたりが、後々「言った/言わない」「正しい/正しくない」で戦いになっている。画面の紙芝居なんかよりも、このあたりをエビデンス化しておかないと泣きをみる。
また、仕様書として含めるかどうかは立場によるが、性能保証、品質保証関連は、名前はともあれ必ず書き起こしている。そのパフォーマンスを何をもって保証しているのか? にかかわるところは、よくちゃぶ台返されるから。大切なのは、ちゃぶ台を返したんだよ、という事実を見える化すること。エビデンスがないと、ひっくり返される「ちゃぶ台」が存在しないことになる → つまり、インパクトがでかいにも関わらず顧客のフリーハンドになるからだ。
■仕様書について犯す最大の過ち
それはレビューとフィードバック。仕様書について誤った考え方が間違ったレビュー・フィードバックの場を提供し、結果うんこ仕様書を量産することになる。
レビューの場が読書会になったり、誰かの独演会（お伺い会?）となったりするのは、ひとえにPMの責任だろう。少なくとも事前に一読を要求することで、通して読めば分かるような質問としてきたり、重箱の隅をつつくような事態にはならない。つまり、最初の数ページに時間をかけすぎて、後は駆け足になるようなこともなくなるはずだ。
どれぐらい公的な場にするかは企業風土によるが、どこまでフィードバックを得るべきかはPMがどれぐらい準備しておくかによる。著者はこうも述べている―― 「優れた仕様書は、シンプルです。仕様書とは本来、コミュニケーションの一形態なのです」
さて、冒頭の仕様書不要論をぶったプログラマと本書の著者が至った結論は次の通り。
ん、わたしも同意。問題はドキュメントにあるのではなく、ドキュメントありきにするプロセスにある。
| 固定リンク
コメント