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

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

7章 優れた仕様書の記述

仕様書の3つの目的

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

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

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

4種類のドキュメント

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

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

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

機能仕様 vs 技術仕様

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

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

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

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

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

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

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

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

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

仕様書の完成

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

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

懸案事項に対する疑問

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

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

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

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

6章 アイデアを得た後にすること

アイデアのマネジメント

アイデアを適切にマネジメントするには，決断力を発揮するだけではなく，その決断が突然のものとならないよう地ならしをしておく必要があると述べています．作業の性質や注力すべき点の変化は，｢照明の調光スイッチ｣を使うように，徐々に行われるべきということです．

図のように，問題空間において拡散と収束という作業の性質が，ある時点で変わるということを前もってメンバーに提示しておくべきだということです．

ところが，実際にはこのようなきれいな菱形になることは少なく，下図のように仕様書完成予定日の時点では完全に収束しないのは，経験上よくわかります．

本書ではその理由として以下をあげています．

• 新たな情報が利用可能になる
• エンジニアの計画が明らかになると，作業の大まかな見積りが変更になる
• 複数の問題を解決するために導入した複数の解決策によって，作業内容に矛盾が生じる
• 変更によって連鎖反応が引き起こされる
• 創造的な作業には勢いがある

アイデアマネジメントにおける6のチェックポイント

そこで，アイデアをマネジメントする最善の方法として，設計前に6つのチェックポイント(マイルストーン)を明確化しておきなさいと述べています．

1. ビジョンとコンセプトの証明
2. アイデア分類/一覧の作成
3. 3つの設計選択肢
4. 2つの設計選択肢
5. 1の設計
6. 仕様書作成

重要なのは，チェックポイントがプロセスの制御のためだけにあるのではないことです．チームが共有できる指針をもてるようになり，何らかの変更が発生した場合でも，今起こっていることとその理由を議論できる枠組みをもてるようになるのです．

この枠組みを”イメージ”としてメンバー間で共有することは，本当に重要だと思います．あえて，ここでこの図を書いたのも，そういう意図があるからです．こういった簡単なイメージを提示(ホワイトボードでも可)して，｢今僕らはココにいるんだよね，来週にはココにいるべきだよね｣と図を指すだけで，チームにとって大きな効果があります．

アイデアのまとめ方

多くのアイデアが出された後でそれを検証する際に，アフィニティダイアグラム(川喜田二郎氏が考案したKJ法で使用するダイアグラム)を使うことを薦めています．簡単に説明すると，それぞれのアイデアをポストイットに書き，それをホワイトボードに全て貼り，グループに分類していくやりかたです．

こういった，みんなの意見をまとめていく際に，図やホワイトボードは強力な武器になります．実例が豊富な｢板書屋 ファシリテーション・グラフィック｣というサイトはとても参考になります．

(板書屋 ファシリテーション・グラフィックより)

また『ファシリテーション・グラフィック―議論を「見える化」する技法 (ファシリテーション・スキルズ)』という本に多くのテクニックが紹介されており，非常にオススメです．

参考文献

• 思考を構造化するためのさまざまなツール http://www.ms.lt/ms/projects/toolkinds/organize.html
• ｢コンピュータは，むずかしすぎて使えない｣