プロジェクトのスコーピングとプランニングを1日で行なう方法

プロジェクトプラン作成支援サービス  

• 著者 Fergus O’Connell
• 　　 ETP 会長兼CEO

(翻訳：コラボプロジェクト・サービス)

はじめに

このガイドの概要

どんなに大きなプロジェクトであっても、1日でスコーピングとプランニングをすることは可能です。信じられないかもしれませんが、私は何度もそれを行っています。実際、私の会社であるETPの売上げのかなりの部分はこのサービスが占めているのです。
このガイドと付随するテンプレートを用いれば、あなたにもそれが可能です。

このガイドの構成

最初のセクションでは、これを行う理由と利点について述べています。また、このアプローチについて概要を説明します。それは映画制作に似ています。映画制作は、3つのフェーズに分けられます。

• プリプロダクション（試作）
• プロダクション（制作）
• ポストプロダクション（編集）

1日で行うプロジェクトのスコーピングとプランニングも3つのフェーズに分かれます。

• 準備
• セッション
• 完成

本ガイドでは、それぞれについてひとつずつのセクションをあてています。最後に、スコーピングとプランニングセッションの実例をご紹介します。
ガイドの最後にある参考情報セクションには、より詳細な情報源を挙げています。

1 プロジェクトのスコーピングとプランニングを1日で行なう方法

1.1 理由

1日でプロジェクトのスコーピングとプランニングを行わないとしたら、他にどんな手段があるでしょうか。それは次のようになるでしょう。

1. 誰かが、ニーズや要件、解決する必要がある問題などを認識する
2. それに基づいて、誰かが調べまわり、提案書やビジネスケース、仕様書などを書く
3. それはステークホルダー（利害関係者、プロジェクトによって影響を受ける人々）によって検討され、その結果がドキュメントの作成者にフィードバックされる
4. ドキュメントの更新に加え、さまざまな問題を解決するための電子メールのやりとり、電話、情報の要求や会議がひんぱんに行われる
5. 項目3と4が何度も繰り返され、ついに…
6. 何をするかについての合意に達する
7. その後、誰かが計画立案を受け持つ
8. その誰かは周囲に聞いて回りながら計画を作成する
9. その計画はステークホルダーの何人かあるいは全員によってレビューされ、その結果がドキュメントの作成者にフィードバックされる
10. 計画に修正が加えられ、大抵の場合さらにメールや電話、情報の要求や会議が行われる。これはステークホルダーの希望とプロジェクトチームの考えにギャップがある場合に顕著になる。
11. 項目9と10が何度も繰り返され、ついに…
12. 計画についての合意に達する

このプロセスは数週間、数ヶ月、あるいはそれ以上かかることがあります。
この一連のできごとに代わるものとして、プロジェクトのスコーピングとプランニングを1日で行うことができるのです。この考えに関心をもつ方は、次をお読みください。

1.2 他の人の意見

「Developing Products in Half the Time」 [1]の中で、著者のSmithとReinertsenは、プロジェクトの始まりを「ファジー・フロントエンド」と呼んでいます。二人はこれを、「時間は替えがきかないリソース」と表現しています。潜在的な開発期間のひと月が浪費された場合、それを取り戻すことはできず、ひと月の遅れは一定額のコストとなります。開発者としての私たちのゴールは、このコストより低コストでサイクルタイムを獲得する機会を見つけることです。そういった機会は、開発プロセスを通じて大小さまざまな形で現れます。その中で一箇所だけ、サイクルタイムを減らすことができる、我々が「機会の特売場」と呼んでいる場所があります。その場所こそが、製品を世に出すまでの時間を大幅に短縮するための最もコストの安い機会として常に経験されるところです。開発におけるこの段階を、開発プログラムのファジー・フロントエンドと呼びます。機会が認識される時から開発プロジェクトが本格的に始まるまでの間のファジーなゾーンがそれです。

ファジー・フロントエンドが製品を世に出すまでの時間の改善を最大化する部分であれば、プロジェクトのスコーピングとプランニングを1日で行うことでその機会を最もよい形で活かせるようになります。

プロジェクトは本来的に、ひんぱんに開始と停止を繰り返します。何かをやった後に待機、たとえばレビューや承認を待ったり、他の人からの意見をもらったりする必要があります。これが最も発生するのがファジー・フロントエンドです。自分が何らかの貢献ができると誰しも考え、承認をしたがり、そういったことを求められなければ無視されたような気になるものです。同時に、プロジェクトは本格的に立ち上がっていないため、常に緊急で差し迫ったものごとが数多くあります。そういったものごとが重なった結果、要件が把握され、確定され、そして承認されるまでの間はストレスの多い期間となります。こういったことを、プロジェクトのスコーピングとプランニングセッションと呼ぶ非常に効果的なイベントに圧縮することで、すべて回避することができます。

1.3 利点

このアプローチの利点は次のとおりです。

• プロジェクトが1日で立ち上がる。その日の終わりにはプロジェクトが動き出します。これ以上素早く、費用をかけずにプロジェクトを始める方法はありません。
• プロジェクトの目的と要件が明確になり、そしてそれらに対してのステークホルダーの合意と賛同が得られる。
• 正確な見積りに基づいたコミットメントが得られる。
• プロジェクトがどのように展開していくかがはっきりと見える。
• プロジェクトを立ち上げることができる。

1.4 手法

この手法を使いこなすためには、重要な点が2つあります。まず、この日の終わりにはスコープ定義書とプロジェクト計画書という2つの成果物を完成させるという目的意識をもつこと、そしてもう1点は、この2つの成果を達成するために1日をできるだけうまく使うことです。

セッションは次のような形で進みます。

1. 1日で行うスコーピングとプランニングセッションに出席すべき人々を把握します。
2. 1日のセッションの前に準備の時間が必要です。出席者は、上述の2種類の文書に対するインプットを用意してくることが必要です。
3. 1日のセッションで、あなたはファシリテーターとして働き、さらにもうひとり、スクライブ（書記）が必要です。このセッションの最中にも参加者からのインプットを取得し、文書に入れていきます。
4. 2つの文書が完成する完成フェーズが最後にきます。この作業は、清書や整形といった作業よりは若干作業量があります。

1.5 ファシリテーターとスクライブ

だれでもこのやり方でプロジェクトのスコーピングとプランニングができるでしょうか。この問いの答えはこうなります。もしあなたがプロジェクトを遂行することができるのであれば、その種のセッションのファシリテーターになれます。スクライブについては、PCを使った記録ができれば十分です。

2 準備

2.1 参加者のために必要なもの

[4] プロジェクトのスコープについて発言できる人全員を認識します。 その中には必ずしも組織図の上の方に名前が載っていないけれども、その人のひと言ですべてが変わってしまうような力を持っている人も含めておく必要があります。

[5] 全員が集合できる日を見つけます。早く集まれるほど、プロジェクトが早く動き出すということを皆に認識させましょう。彼らに対し、プロジェクトのスコーピングとプランニングを1日で行うこと、そして、これによってプロジェクトの完成が早くなることを説明します。さらに、プロジェクトを早く終わらせるためには彼らにも準備が必要だということを説明します。

[6] 準備と1日のセッションの間に、次の2つの文書を作っておきます。(a) プロジェクトのスコープ記述書と、(b) プロジェクトの計画書です。サンプルとして、Template Scope document.docと、Template Plan.mppを用意してあります。

[7] 参加者に対し、次の文章と共にブリーフィングノートを配布します。[Briefing note.doc]

• スコーピングとプランニング・セッションのためのブリーフィングノート
• セッションの目的は、次の通りです。
• (a) このプロジェクトが達成しようとすること、ゴール、を確かめる。
• (b) このゴールに到達するための計画を作る。
• 参加者それぞれが行うべき、このことに対する準備は次の通りです。
• (a) プロジェクトのゴールを文章にする。
• (b) このゴールに到達するための計画を用意する。
• この準備には半日もかからないでしょう。一定の時間をとり、その中でできるレベルで行ってください。
• (a) ゴール
• そのためには、次のような質問で自問自答してみてください。(1時間以内で終えるようにしてください。)
  • プロジェクトが終わったことをどうやって知るだろうか。
  • ものごとはどのようになるだろうか。会社あるいは自分の所属する部署はどのように変わるだろうか。
  • このプロジェクトで影響を受けるのは誰だろう、どのグループだろうか（ステークホルダー）。
  • それらの個人あるいはグループにおいて、プロジェクトが成功するとはどういうことだろうか。
  • それら複数の見方は整合しているだろうか。もし対立あるいは矛盾しているようであれば、妥協点は見いだせるだろうか。
• (b) 計画
• これを行うには、次の操作を行います。(最初の3項目には2-3時間以内の時間を、残りの2項目には1時間を超えない時間をかけてください。)
  • ゴールのうちであなたの担当部分を達成するために行うべきジョブをすべて列挙します。
  • ジョブ相互（あるいは他のプロジェクトやグループ）の依存関係をマークする。
  • ジョブそれぞれにどれくらいの工数がかかるかを推定し、それによってプロジェクト全体を推定する。
  • 仕事を担当する人々を見定める。
  • 勘案する前提事項や未解決の課題を文書化する。

[8] 結果を届ける締切日を伝えます。この締切は1日のセッションの1日か2日前に設定し、2つの文書の初回ドラフト版をまとめる時間を確保します。
[9] 戻ってきた書類を用いて、2つの文書をまとめ、1日のセッションの出発点とします。
[10] 書類が一部しかあるいは全然戻ってこない場合でもあわてないでください。それでもこの1日はなんとかなります。

2.2 あなたにとって必要なもの

[1] 1日のセッションで利用する部屋を押さえます。 次のような基準を満たすところが望ましいと言えます。

• オフサイトであること
• 窓が多く、明るいところ（非常に重要）
• 換気/空調がよいこと
• 紙などを貼れる壁がある
• 電話がないこと
• 各人にとって快適な椅子と机
• 軽い飲食ができること 部屋の外で 軽食

[2] さらに必要なもの

• フリップチャート
• マーカー（赤、緑、青、黒）
• 液晶プロジェクターとスクリーン
• オフィス系アプリケーションを備えたPC
• プリンタ

[3] 1日のセッションが近づいてきたら、メールを配信し [Sample memo to participants.doc] さらに情報、たとえば議題などを届けます。

9時から5時までの一日の議題は次の通りです。

• 09:00 - 10:45 第一部：プロジェクトのゴールを定める
  • - プロジェクトにおいて最も可能性の高い結果は何か
• 11:00 - 13:00 第二部：計画策定
• 13:00 – 13:45 昼食
• 13:45 - 15:00 第二部：引き続き計画策定
• 15:15 - 16:15 第三部：計画に対するリスク分析を実施
  • - プロジェクトが暗礁に乗り上げる原因となるのは何か、その発生の機会を最小化するには何をすべきか
• 16:00 – 17:00 第四部：計画から次の行動を決定する

3 セッション

3.1 はじめに

[1] 歓迎の意を示した後、自己紹介と自分の役割の説明 - このセッションの進行を担当し、すべてをスケジュール通りに進めることを話す。スクライブの紹介と役割の説明。これからの活動を記録し、本日の終わりに計画ができているようにすることがスクライブの役目。

[2] 本日の議題を再確認する。

• 09:00 - 10:45 第一部：プロジェクトのゴールを定める
  • - プロジェクトにおいて最良の結果とは何か
• 11:00 - 13:00 第二部：計画策定
• 13:00 – 13:45 昼食
• 13:45 - 15:00 第二部：引き続き計画策定
• 15:15 - 16:15 第三部：計画に対するリスク分析を実施
  • - プロジェクトが暗礁に乗り上げる原因となるのは何か、その発生の機会を最小化するには何をすべきか
• 16:00 – 17:00 第四部：計画から次の行動を決定する

3.2 第一部 09:00 – 10:45 プロジェクトのゴール

[3] 第一部では2つのことを行います。最初に、このプロジェクトの終結時点で何が形になっているかを明らかにします。二番目に、プロジェクトのステークホルダーとそのウィンコンディションを把握します。ステークホルダーとは、このプロジェクトで影響（良きにつけ悪しきにつけ）を受ける人です。それぞれのステークホルダーは、いわゆる「ウィンコンディション」を持っています。ウィンコンディションは、その特定のステークホルダーにとってプロジェクトが成功したと認識されるものごとです。

[4] プロジェクトが終結する時のことについて約30分、そしてステークホルダーのウィンコンディションの明確化に約1時間を費やします。第一部は全体で1時間45分ですので、残りの15分はバッファとして使います。

[5] プロジェクトのゴールを定める作業の出発点には2種類が考えられます。準備段階に情報が得られていれば、スコープ記述書のドラフトがまとめられているはずで、その場合はこのドラフトをスクリーンに映しながら始めます。何も戻ってきていなければ、出発点は白紙のスコープ記述書ということになります。Template Scope document.doc

[6] 出発点がどちらであれ、この時点で参加者に対して次のような質問を投げかけます。「プロジェクトが終わったことをどのようにして知るのか」 「プロジェクトの終わりはどこに設定されるか」 スクライブはこれらをスコープ記述書に加えます。

[7] 参加者の答えを繰り返します – これこれが起きて、これとこれが起きた時点でプロジェクトは終結するということですね? これらがすべて起きた場合、プロジェクトは成功したと言えるのですね? これらの会話から生じる詳細も追加しておきます。

[8] 参加者の答えを繰り返し続けます – ということは、これとこれが完了したら、プロジェクトは終結するということですね – 全員がイエスと言うまで続けます。これには30分から45分を要するでしょう。 (注: この段階で合意が得られなければ、セッションは中止しなければならないかもしれません。しかし、今までの私の経験ではそんなことは起きたことはありません。)

[9] ここまで完了したら、ステークホルダーである参加者にそれを書き取ってもらいます。準備段階で情報が入手できている場合もそうでない場合もあります。

[10] その後、ステークホルダー達に自分たちのウィンコンディションを書いてもらい、スクライブはそれを記録します。

[11] いったん出し終わったら、それを繰り返して彼らに聞いてもらいます。ここまでの議論で、プロジェクトの終わりにはここに挙げたような、ステークホルダーにとってのウィンコンディションが達成されているはずですね。全員が合意したら完了です。もし、合意が得られない場合、到達点を変えるかウィンコンディションを修正するかしなければなりません。

[12] プロジェクトの終わりとして選んだ時点において、ステークホルダーのウィンコンディションがすべて達成されるだろうということに全員の納得が得られるまでこれを続けます。

[13] この段階で、「プロジェクトが終わったことは何で知るのか」ということと、ステークホルダーのウィンコンディションのペアが、プロジェクトのスコープとなります。別な言い方をすると、プロジェクトが終結する時として選んだ時点にはステークホルダーのウィンコンディションがすべて達成されているはずだということになります。

[14] ここでのポイントは、時間の許す限りこのセッションをしっかり行うということです。ここでいくつかのコツを挙げておきます。

• このセッションの中で行う、「プロジェクトが終わったことは何で知るのか」についての議論では、30分程度をかけてこれを終わらせます。
• その後、ステークホルダーのリストを10分程度で書き上げます。
• 残りの1時間は主にウィンコンディションを考え出すのに使えます。ステークホルダーの人数によって、全員の思いを考える時間が多少異なります。ステークホルダーが10人だとすると、一人当たり約5分かけてウィンコンディションを考えることができます。ステークホルダーが30人いる場合、実際そういうケースもあります– それぞれに1、2分しかかけられません。
• 最後に、第一部が終わったので休憩に入ります。

[15] これらすべての作業が終わった時点で、参加者には休憩をとってもらいます。スクライブと共に、すべてを記録できているかどうか確認します。スクライブが書き上げたものは、ゴールの定義とプロジェクトのスコープになっているはずです。この、プロジェクトスコープ記述書は、プロジェクトのゴールを規定したものとして独立した文書として扱えます。あるいは、プロジェクト憲章などにまとめることもできます。

3.3 第二部 10:45 – 15:00 プロジェクト計画

[16] 計画を記述する際には、MS Projectなどのツールを使うとよいでしょう。 (タスクにはアウトライン形式で番号をつけてください。) この段階でも、参加者から情報を受けとっていれば計画の大枠が既にできているかもしれません。そうでなければ、最初から書き始めます。 (その場合には、次のテンプレートをご利用くださいTemplate Plan.mpp)。

[17] 画面上の出発点を指し示します。そこで、参加者に対し、プロジェクトの大くくりのフェイズについて問いかけます。

[18] 計画に取り組むための時間は3時間半です。大くくりのフェイズの数を基に、それぞれのフェイズに対してどれくらいの時間を割いてどの程度詳細に考えるかを考えてください。たとえば、6つのフェイズがあれば、それぞれには30分の時間をかけられます。もしもっと数が多い、たとえば10のフェイズがあれば、それぞれに15分しかかけられなくなります。

[19] 各フェイズに費やせる時間がわかったら、その時間の半分を使ってそのフェイズの詳細を考えてください。そして、残りの時間で列挙したジョブそれぞれの所要時間を推定してください。

[20] 大くくりのフェイズの最初にとりかかり、詳細なタスクを考えていきます。 テンプレートTemplate Plan.mppにあるように、大くくりのフェイズを、必要不可欠なサブフェイズと、あるとよいサブフェイズに分けると便利かもしれません。

[21] まず、最初のフェーズまたはサブフェーズについて、その中の具体的なジョブの先頭を明らかにします。ジョブはできるだけ具体的にあいまいなところがないように記述します。たとえば、「要件の収集」と書くのではなく、「チャーリーがIT部門と2日間会議を行い、彼の要求事項を伝える。」というように書きます。もしタスクにあいまいさが残るようであれば、より詳細を調査しなければなりません。

[22] 大くくりのフェイズそれぞれに設定した時間を意識して作業してください（[18]と[19]を参照)。その時間内には詳細度が一定のレベルにとどまるかもしれませんが、それはそれで構いません。

[23] 同様な詳細度でそのフェイズ全体について[21]を実施します。この作業は設定した時間内つまり各フェイズに割り当てた時間の半分を超えないようにします。

[24] 各フェイズに割り当てた時間の残り半分で、ジョブに名前をつけ、所要時間の推定値を記入します。

[25] その際、想定を置く必要がある場合があります。たとえば、テストの回数や修正フェイズの回数がわからない場合、なんらかの想定を入れた上で詳細を組み立てていきます。そのことには何の問題もありません。

[26] スケジュールを守るために次のようにしても構いません。

1. できるだけ昼食の前に3分の2程度を終わらせるようにし、昼食はひとつのフェイズが終わってからにしてください。
2. それぞれの大くくりのフェイズに割り当てた時間を目安にしながら、時間通りに進めるようにしてください。特定のフェイズで時間が足りなくなった場合には、とにかく残りを想定し、次の不フェイズに移ります。
3. これはとても重要です。ものごとにとらわれずぎないように。ジョブの並びを作っているのであって、ジョブそれ自身ではありません。ジョブの並びに関係しないことは、別の場所で議論します。

[27] 大くくりのフェイズすべてに対しこの作業が終わったら、基本計画ができあがったことになります。

[28] 休憩の前にあと2つのことを行ないます。ひとつは、計画にコンティンジェンシーを入れることです。プロジェクトの終わりの日に何日か追加の日を入れます。これは、プロジェクト遂行中に発生する予期しないできごとに対処するためです。なにか目安が必要であれば、プロジェクト全体の期間の15%を追加するのがよいでしょう。たとえば、7ヶ月のプロジェクトであれば、コンティンジェンシーとしてあとひと月を追加します。

[29] もうひとつの作業は、プロジェクトに必要なプロジェクト管理の工数を見積もることで、それを「プロジェクト管理」というひとつのジョブとして計画に入れておきます。この推定値としては、プロジェクト全体の工数の1割が妥当です。例を挙げてみましょう。

• 4人の人がプロジェクトに10週間、フルタイムで関わるとしましょう。
• 総工数 = 4人 x 10週 = 40人週 = 200人日
• その10% = 20人日
• 10週に渡ってこれを展開すると、このプロジェクトは平均して、週に2日のプロジェクト管理を要することになります。

3.4 第三部 15:15 – 16:15 プロジェクトのリスク分析

[30] ここでは、プロジェクトのリスク分析を行います。例の中にある表を使用します。[Risk Analysis template.xls

[31] プロジェクトのリスクを把握します – プロジェクトに悪影響を与えるものごとです。表の左端の列にそれを記入します。

[32] それらが起こる可能性の高低で分類します。1から3で分類します。1 = 起こりそうもない、3 = 起こる可能性が高い、2 = その中間、と考えます。

[33] リスクが現実になった時の影響度を分類します。これも同様に1から3で分類します。1 = それほど大きな影響はない、3 = 多大な影響がある、2 = その中間、と考えます。

[34] 可能性と影響度をかけ合わせます。先のExcelシートではその計算を自動で行います。

[35] 重大性が高い項目（6あるいは9）に対しては、それらのリスクを緩和するための行動を把握しておきます。

[36] それらの行動を計画に組み入れ、他のジョブと同様に扱います。

[37] この作業は1時間以内に行えるでしょう。リスク分析の例を挙げておきます。

リスク分析

	リスク	発生の可能性	影響度	L x I	行動
1	会社の役員による 管理が不十分	2	3	6	パフォーマンスをレビューする 教育 品質管理 •経営陣の強化
2	人員不足	3	3	9	一般例から目標値を定める 1月に増員する 既存スタッフのダンスカードを精査する
3	スタッフが病気になる	2	3	6	代替要員の備え 新規要員に対する健康診断 現状の問題を直す
4	経験不足	2	3	6	教育と能力開発 適切かつタイムリーな評価
5	作業場所が手狭になる	1	1	1	拡張用施設を探す
6	競合	1	2	2	競合を観察し続ける
7	売上げが立たない – 予測が正しくない	2	3	6	週次の監視と変更管理 財務報告と管理報告
8	スタッフの退社	1	3	3	待遇や福利厚生が業界水準であるよう努める モラルを監視する
9	顧客離れ	1	3	3	CRMプログラムを刷新する 離れてしまった顧客を調査する
10	非現実的なゴール	2	3	6	変更管理
11	データセキュリティ	3	3	9	12月7日にそのための会議を招集
12	ブランドの疲弊	2	2	4	企画部門が対処し、対策を立てる
13	キャッシュフロー	2	3	6	そのまま続行する
14	市場の変化	1	3	3	企画部門が注視する
15	不況の到来	1	3	3	緊縮行動をとる – 無駄や不必要な支出を無くす
16	新しい市場が経営を混乱させる	1	3	3	計画に従って進める

3.5 第四部 16:15 – 17:00 次のアクション

[38] 新しく作成された計画に関し、セッションの参加者に次のアクションを割り当てます。別法として、次のように言うのでもよいでしょう。「計画をご覧いただき、来週にやるべきことは何か考えてください。 来週の同じ日に再び集合し、それらの事が実行されたかどうか確認しましょう。」 もしそうする場合には、次の会議の日程を決めた上で、予定を繰り上げて終わりにしても構いません。 (実際、ここに挙げたスケジュールには多少のコンティンジェンシーが会議の終わり頃に入っているのです。しかし、このプロセスがうまくいくためには、このような中間的なマイルストーンを自らの手で定めることが重要です。)

[39] これで完了です。

4 完成

[40] その日の終わりに、スコープ記述書と計画書を参加者に配布することができます。しかし、この2つの文書について、多少見栄えを整える必要があるかもしれません。スクライブは翌日にまずそれを行い、その後参加者に配布します。しかし、参加者をそれを待つことなく、1日のセッションの終わりからドラフト版を使用してプロジェクトに関する各自の作業に取りかかることができます。

参考情報

[1] Smith, Preston G. and Reinertsen, Donald G., Developing Products in Half the Time, New York: Wiley, 1998

[2] Boehm, Barry W. and Ross, Rony, “Theory-W Software Project Management: Principles and Examples”, IEEE Transactions on Software Engineering, Vol. 15, No.7, July 1989, pp.902-916.

© Fergus O’Connell 2006