解くべき問題を探すには、優れた質問を探すのだ | アート・オブ・プロジェクトマネジメント

前章で、スケジュールについての理解は深まりました。次はこのプロジェクトでどのような問題をどうやって解決するのか決めなければいけません。つまり計画フェーズです。本章では「計画」を、いわゆる要件定義と設計をセットにしたものとして扱っているようです。どうやって計画を立てれば良いのでしょうか？

自分の受託開発での仕事の流れを思い返すと、作成する要求定義ドキュメントの定義について顧客との間で取り決めが交わされていました。でもあのドキュメントの定義ってどんな基準で作られたのでしょうか。雛形があるとしたらそれはどんなロジックで決められたものなのでしょうか。

ソフトウェア計画の因数分解

ソフトウェア計画は、大きく2つの項目にわけられる、と本著は言っています。それは、

何を行う必要があるのか？(要求の洗い出し)
どうやってそれを行うのか？(設計)

の2つです。そしてこれら2つの作業の内容は、組織のスタイルとプロジェクトの規模によって変化します。組織のスタイルについては、要求事項・設計内容・技術的チャレンジ・予算への決定権の持ち主が誰かによって必要な作業内容や合意を取るべき人が変わることを言います。また規模については、1人プロジェクトなら本当に大切なことだけをドキュメントにまとめておけば十分かもしれません。一方、『人月の神話』のブルックス先生が論じたような新しいPCの開発なら、すべてをドキュメント化するくらいの勢いでないと1人1人が何をすべきか全くわからなくなってしまいそうです。

上記のことを踏まえたうえで、本著では計画フェーズの成果物として以下のドキュメントを作成することを提供してくれています。勿論各プロジェクトによって変更すればいいのですが。

市場要求ドキュメント
ビジョンのドキュメント
仕様書
WBS

市場要求ドキュメントはビジネス機会についての文書、ビジョンはプロジェクトがなにを達成すべきなのかや大きなレベルでの要求などが定義された文書、仕様書はビジョンを実現するためにもう少し細かい部分について、各部分がなにを実現すべきなのか定義したドキュメント、そして最後にWBSは、仕様を満たすための作業の予定をチームメンバー全員が決められるようにするためのドキュメントです。

計画の3つの視点

上記でまとめたものには、ビジネスとしての観点とエンジニアリングとしての観点が両方入っています。本著はこれら2つの視点を、大抵のプロジェクトにおいて相反するものであると述べていますが、同時にこれらの視点が競合することは計画フェーズの失敗のもっとも基本的なシグナルであるとも述べています。計画フェーズでチームは、すべての視点に立つメンバーが貢献できるような計画を立てるべきなのです。

ではチームがどのような状態であれば、正しい計画を立てられているといえるのでしょうか？ Scott氏は、それぞれの視点についてのある質問に答えられるかどうかを試金石とできると述べます。

ビジネス視点でみた計画

エンジニアから見て営業さんやビジネスサイドは、時たま特定の顧客の要望を丸投げする人に見えたりすることもあるかもしれません。しかしビジネスサイドの彼らが自分たちの組織の損益計算書を増益で終わらせる努力をしてくれるから、みんながお給料をもらえていることには、チーム全員が自覚的であるべきです。

チームがビジネス視点で計画を立てられているかを測るためには、以下のような質問が有効です(本の中にはもっとたくさんの質問が載っています)。

顧客のニーズはなにか？
コストと、それに対して見込める利益はどれくらいか？
いかにして競合他社を出し抜くのか？

技術視点でみた計画

技術的に優れている結果顧客のニーズを満たす商品であれば最高ですが、単に技術的に優れただけの商品では売れません。エンジニアリングに携わるメンバーは、自分の仕事への審美眼を持つことは素敵なのですが、それだけに傾倒してはいけません。顧客のニーズを満たすものを、最高の方法で実現するための計画になっているかは、以下のような質問で確かめられます。

このコンポーネントはどのようなインターフェースを持つのか？
このシステムはどれくらいのセキュリティレベル、可用性やパフォーマンスを担保するのか？
ある仕組みを実現するためには、どのような技術的な選択肢が考えられるのか？

顧客視点でみた計画

Scott氏は、この視点がソフトウェア計画で最も重要であり、最もないがしろにされがちであると言います。プロジェクトマネージャは顧客視点での計画立案に長けたメンバーを採用し適切な権限を与えるべきです。彼らは以下のような質問に答えてくれるでしょう。

実際のところ、我々の顧客はどのような作業を行っているのか？
どんな不満を感じているのか？
ユーザーになんと話せば、このプロジェクトの真価を分かってもらえるのか？

プロジェクトマネージャは3つの視点を操る者

プロジェクトマネージャは、ソフトウェア計画を構成する3つの視点を知ったうえで、それを適切にコントロールしなければいけません。プロジェクトマネージャは、チームメンバーに各視点の共通点と相違点を理解してもらうことで、我々が時に「カネにならないが技術的に優れたアイデア」や「ビジネス的に最高だが技術的には実現不可能なアイデア」が出てき得るという事実を共有することができます。

また、3つの視点の政治的なパワーにも気を配る必要があります。人数比は当然大切ですがそれだけではなく、各メンバーの声の大きさにも気を配り、ある視点だけが強力になりすぎることを抑制しなければいけません。

優れた計画のためには、優れた疑問を探すこと

ソフトウェア計画の3つの視点についての話でもそうだったように、優れたプロジェクト計画には優れた質問が不可欠です。計画を立てるときには、3つの視点からの質問を自分たちのプロジェクトに合わせてピックアップして回答していくとよいでしょう。しかし実際に疑問として使用するときにはもっと広い視点での疑問が必要です。本著に書いてある疑問のごく一部を例として挙げておきます。

議論の時に想定される顧客層は誰なのか？
我々は解決したい問題に対して十分な技術力や知識を持っているのか？
競合他社はこの問題に対して何を行っているのか？彼らの戦略はなにか？

勿論、良いソフトウェア計画手法があるならば、一方で悪い手法もあります。たとえば「このパージョンは前バージョンで省いた機能を入れるだけのものだ」など。どんなに時間がなくてもこのようなパターンにハマってはいけません。

実際の計画の進め方

計画は少数のエキスパートで行うべきです。人数が増えるほど創造性と生産性が下がってしまいます。選出されなかったメンバーは自尊心が傷つくでしょうが、だからといって議論のメンバーを増やすよりは個別に彼らを癒やした方が良いです。

計画フェーズの成果物しての各種ドキュメントは、互いに相関しあいながらブラッシュアップされていきます。しかし、抽象度に開きのある2つのドキュメントの修正はコストがかかるので、抽象度近いもの同士でフィードバックを行うべきです。

計画の手段として顧客調査を行う場合がありますが、様々な方法があるので適切なものを選択してください。

計画作業の成果として書き出される要求は、叙述的なシナリオになるはずです。ユースケース駆動開発に関する書籍がこのフェーズを助けてくれるでしょう。