アート・オブ・プロジェクトマネジメント(7)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

7章 優れた仕様書の記述

仕様書の3つの目的

• 正しいものの構築を保証する
• プロジェクトの計画フェーズを締めくくるマイルストーンを提供する
• プロジェクトの過程で踏み込んだレビューや各個人からのフィードバックを可能にする

上記の3つは，プロジェクトにおいて，つまりPMという立場からみた仕様書の目的です．一方，現場，つまりプログラマという立場からみた仕様書はというと，以下の文に集約されていると思います．

何らかのドキュメントによって，チームが抱える本当の問題を解決でき，開発プロセスを加速させ，品質の高い成果物を生み出せる可能性を高めることができる(そしてチームを混乱させることなく改訂できる)のであれば，そのドキュメントは有益なものと言えるはずです．

4種類のドキュメント

• 要求仕様 ： 作業によって達成されるべきすべての要求と責任の概要を記述したもの
• 機能仕様 ： 顧客視点から見た特定のシナリオやシナリオ群における振る舞いや機能を記述したもの
• 技術仕様 ： 機能仕様を満足するために必要となるエンジニアリングアプローチを記述したもの
• 作業項目一覧 ： WBSと同様のもの

大規模チームにおいて，PMや設計者は機能仕様に責任を持つべきであり，プログラマは技術仕様に責任を持つことになります．それぞれの仕様書の書き手は，チームメンバーが双方の仕様に目を通した際に，書き手同士が互いのことをよく理解し，頻繁に意思疎通を行っていたと信じられるようなものを作る必要があります．

僕の経験した多くのプロジェクトでは，そもそも機能仕様と技術仕様といった定義がされておらず成果物の分担が曖昧で，当然責任の所在が曖昧になり，混乱を招くケースがありました．プログラマはコード以外には興味を持たないといった傾向もあり，問題をさらにこじらせていました．本書も指摘しているように，PMは各仕様書の責任者を明確にし，しっかりマネジメントすべきだと実感します．

機能仕様 vs 技術仕様

機能仕様と技術仕様を1つのドキュメントにまとめることは可能ですが，たいていの場合，それらは明確に分割された別々のセクションに記述する必要があります．つまり，顧客側からみたシステムの振る舞いとプログラマからみたオブジェクトの振る舞いを1つにまとめて書いてしまうと，”美しく高度に洗練されたゴミ”となってしまうと書かれています．

優れた仕様書はシンプルである

仕様書をうまく記述するには，

大切なものことであったとしても，それが本質的でなければ説明を割愛し，読み手の準備ができた時点でその説明に戻る．

といったスキルが必要だとし，複雑さは多くの場合，記述のまずさや，三流の思考に対する逃げ口上となっているとも指摘しています．

正しいものごとが起こるようにする

仕様書によって，「ものごとが期待通りに進めば，この作業が終わる頃には本仕様書で解説されているものを得ることができる｣といった一連の意向が定義されます．そして仕様書の目的は，メンバー全員にこういった意向を伝達するということになります．ここでいうメンバーとは，エンジニアも含め｢テスター｣｢品質保証担当者｣｢マーケティング担当者｣｢ドキュメント担当者｣｢技術サポート担当者｣｢会計マネージャ｣などを指しています．

そして，メンバーが仕様書を読んだ後で，次の質問をするよう薦めています．

最善の作業を行う上で必要なことがすべて得られましたか？

仕様書の完成

チームの設計プロセスがどんなにうまくいっていても，仕様書作成中には，常に未解決の懸案事項がつきまといます．そしてこういった懸案事項を早期に認識するよう，PMは懸案事項の洗い出しとレビューを行っていく必要があるのです．逆に，これらをうまくマネジメントできれば，こういった懸案事項を解決する方法についての見積もりを行うことで，スケジュールのギャップを埋めることができる場合もあると説明しています．

スケジュールのギャップを埋めるとは，設計に関する懸案事項が未解決のまま残っていたとしても，仕様書をレビューし，スケジュール通りに完成したことにできる，ということを意味しています．そして，ギャップを埋めるために，各懸案事項に対して以下の疑問を考察するのがよいと述べています．

懸案事項に対する疑問

• どの選択肢を選んだとしても，実行しなければならないという作業項目はあるのでしょうか？
• この懸案事項は，PMや設計者によって解決可能でしょうか？
• 検討中の懸案事項を解決するための設計選択肢として，どういったものが考えられるのでしょうか？
• 考えられる設計選択肢のうち，最もコストがかかるのはどれでしょうか？
• これは主要な，すなわち核となるコンポーネントなのでしょうか？プログラマは，いつこれを実装しなければならないのでしょうか？その設計を遅らせ，実装フェーズにおいて行うことはできるでしょうか？これは，他のコンポーネントに依存されているものでしょうか？
• この懸案事項を独立させたり，絞り込んだり，分割したり，削除することはできるでしょうか？

また，マネージャはこういったことを行って初めて，残っている懸案事項の複雑さを完全に理解できるようになると指摘しています．