Step 2: ジョブのリストを作る
ステップ2は計画作りです。言うまでもなくプロジェクトマネジメントの中核的部分で、SPMではここを非常に重要視しており、十分に時間をかけて詳細に行ないます。ステップ1のゴールの可視化がプロジェクト全体の重要な基礎であり、PSIの配点が20点と他のステップよりも大きな点数を与えられていたのと同様に、ステップ2の計画作りもPSIの配点は20点です。
SPMにおける理想的な計画とは、プロジェクト遂行段階で実際に行なわれること、起きることが、計画に沿って起きることで、"reality follows plan"という言い方をします。別な言い方をすれば、SPMでの計画とは、飛行機が目の前に見える視界を頼らずに飛ぶ計器飛行に例えて、計画を飛行機の計器に見立ててそれでプロジェクトを遂行します。したがって、計画の正確性を求めます。
計画作りの基本的考え方
それでは具体的に事例を使いながら計画を立てていきますが、まずSPMでの計画作りに特徴的な2つの事項を知ってください。ひとつは、プロジェクト計画を最初の一歩から一歩ずつ考えていくということ、もうひとつは事前にわかっている制約を考えずに始めるということです。プロジェクト計画では、制約を考えながら、まず大枠で、あるいはフェーズ分けをして、全体像を描き、次第に詳細化していくのが一般的なやり方でしょうから、それとは違う意識で取り組む必要があります。
一歩ずつ未来を予測する
まずデイワンに何をするか、から始めます。ものの考え方には、マクロから始めて次第にミクロに進む流れと、最初からミクロに考えて最終的に大きなものができた時にマクロが把握できる流れがあります。これをうまく使い分けていく必要がありますが、SPMでは基本的に一歩ずつ進んでいくミクロなアプローチをとります。
その方が面倒ですが、うまくいくというのがSPMの考え方ですが、始めるとすぐわかるメリットを挙げておきましょう。プロジェクト全体を考えながら計画を作ると、どうしても細部は後回しになってしまいます。大きなプロジェクトであればあるほどそうです。その結果どうなるかというと、それぞれのタスクを実行する段になって始めて細部を考えるということになります。するとどうなるか。タスクの詳細を直前に考えるわけですからその時にいろいろとわかってきます。やるべきことや作業量、さらにはそのことをクライアントが賛成するかどうかといったことが。SPMはプロジェクトの開始時点から一歩ずつ細かく考えていくので、先のことはどうあれ開始時点からの一定期間、ひと月ほどの間はかなり詳細に考えることができます。ずっと先のことはよくわからなくても、あるいは一歩ずつ考えるのが途中で面倒になってやめてしまっても、少なくとも明日や来週やるべきことは具体的になっています。そこに希望や期待は入る余地がありません。何らかの想定をすることはもちろんありますが、それは明示されますので、クライアントも後でびっくりということがありません。
制約条件は脇に退けて考える
ここで言う制約条件とは、SPMでBaggageと呼ぶもので、ゴールを達成するために必要なやるべきことの列とは無関係に与えられるものです。たとえば、年度末までに完成させること、とか、予算とか要員の数などです。SPMでは計画を作る時にこれらの要素を考えながら作るのではなく、計画ができあがった後に考えます。もし年度末に終わらない計画ができたとすれば、その時点でどうやったら年度末に終わらせることができるかを考えます。なぜそうするのかを簡単に言うと、制約を考えながら計画を作るとどうしても、未来予測ではなく、つじつま合わせに労力を注いでしまうからです。
さて、解説が長くなりました。シロの犬小屋を作る計画に移りましょう。
計画を作る - (今回使用するツール：iMindMapのプロジェクトマネジメントモード)
計画作りの第一歩は、やるべきこと(ジョブ、タスク、アクション)を全部書き出すことです。ここで必要なのは、What (何をやるかという行動)、How long (どれくらいかかるか)、Dependency (依存関係)の3つです。Who (誰がやるか)はここでは考えません。これはステップ4で行ないます。
使うツールは、書き出す時にストレスにならないものであれば何でも構いません。紙に3列の縦棒を書いたものでも十分です。書いていく途中で、後戻りしたり、間に追加したりする場面が必ずありますし、依存関係の矢印を書いていくにつれてごちゃごちゃしていきますが、最終的にはコンピュータ上のツールで整えることになります。そのアウトプットがこのステップ2の成果物となります。
今回はやるべきことをストレスなく自由に発想するという点を重視して、それにふさわしいツールとしてマインドマップを使ってみましょう。マインドマップは、テーマを中心に置いてそこから発想する事項を外側に枝のように伸ばした線の上に書いていく手法（したがって中心のテーマをセントラルアイデア、周囲に書かれるものをブランチと呼びます）です。英国のトニー・ブザン()という方が考え出した手法で、コンピュータ上でこれを描く為のツールが多数作られています。今回は本家とでも言うべき、Buzan's iMindMap(R)を使います。
iMindMapには、入力モードのひとつとしてプロジェクトマネジメントモードというものがあり、これで入力していくとマインドマップのブランチがプロジェクトのタスクとしてチャート(ガントチャート)化されます。
What's next?
SPMでやるべきことすなわちジョブを列挙していく作業の基本は、"What's next?"と問いかけ続けていくということです(最初だけは"What happens first?"となります)。さて、シロが伯父さんの車で我が家に来る9月25日に先立つ9月4日。「犬小屋プロジェクト」のキックオフとなる家族会議が開かれています。
段取りのための家族会議
(父): 「浦和の伯父さんのところで生まれた柴犬を譲ってもらう話だけど、伯父さんが25日に連れてきてくれることになったよ。」
(姉): 「今から楽しみだわ」
(母): 「どんな餌をあげればいいのかしら。それより先に名前を決めなきゃ。」
(あなた): 「シロに決定したじゃないか、先週。もう忘れたの？」
(母): 「そうだったかしら。最近どうかしてるわねえ。」
(姉): 「シロの寝床というか、犬小屋を作らなきゃ。」
(父): 「よし。お金は父さんが出すから、段取りを考えてくれ。この間言ってたやつ、ピーエムとかいうのでできるんだろ？」
(あなた): 「PM、プロジェクトマネジメントだよ。段取りの前に目標をきちんと決めないといけないんだ。ゴールとも言う。」
(姉): 「そんなのわかりきってるじゃない。」
(あなた): 「（素人はこれだから）」
(姉): 「何か言った？」
(あなた): 「いやいや。ゴールはちゃんと考えてあるんだ。大事だからね。それは、”柴犬のシロが快適に住める小屋を作るプロジェクト”、というんだ。」
(姉): 「だからわかりきってるって・・・」
(あなた): 「何か言った？」
(姉): 「なんにも。」（と言いながらお茶を飲む）
(あなた): 「じゃあこれから段取り、つまりゴールを達成するまでにやるべきことを皆で考えていくよ。私は犬を飼ったことはないし、浦和の伯父さんちの犬小屋を見たこともないからイメージもわかない。父さんみたいに大工仕事が好きでもないし。だからみんなでアイデアを出し合おう。私がまとめていくから。」
(一同): 「了解」
(あなた): 「真ん中にゴールステートメントを書いてと、それじゃいくよ。まず最初に何をする？」
(父): 「そうだな、まず小屋の設計をする。」
(あなた): 「（ちょっと飛び過ぎだな）小屋の設計に必要な要素は？」
(父): 「大きさ。そうだ、柴犬ってどれくらい大きくなるんだ？」
(母): 「伯父さんのところの犬たちがそうよ。」
(あなた): 「わかった。伯父さんに柴犬の成犬の大きさを聞く。これが最初の仕事だ。どれくらいかかるかな。」
(姉): 「電話すればすむことじゃない。3分。」
(あなた): 「了解。余裕をみて0.5dayと。」
(あなた): 「What's next? 次は？」
(姉): 「偉そうに。中身の大きさが決まったら入れ物の大きさでしょ。次は。中で動けるようにある程度大きめがいいわね。」
(あなた): 「小屋の大きさを決める、と。これは0.5dayでいいね。What's next? 」
(父): 「設計図を書く。俺がやるよ。」
(あなた): 「xxxを作るというような成果物を作るというジョブはたいてい複数の段階を経てできあがるものだから、その中身をひとつずつ確認しておいた方がいいんだ。特にその成果物を始めてつくるような場合はね。」
(父): 「（会社の会議だと成果物を列挙して終わるんだが、息子はまどろっこしいやり方するなあ）犬小屋だから設計図というほどでもないが、庭先に置くんだから見た目も重要だな。」
(姉): 「デザインは私が描くわよ。2日ちょうだい。」
(母): 「まことちゃんハウスみたいにしないでよ。」
(あなた): 「デザインを考える。2days。そして、デザインを合意する。1day。」
(母): 「どこに置こうかしら。」
(あなた): 「それも必要だね。置き場所を決める。1day。そして置き場所を合意する。1day。」
(父): 「ここまで決まったら設計図が書けるな。図面を引くという意味で。」
(あなた): 「はい。それじゃよろしく。どれくらいかかる？」
(父): 「そうだなあ。仕事があるから帰ってからしかできないけど、連続してやれたとして、まあ1日じっくりやりたいな。こういう答えでいいのか？」
(あなた): 「はい。飲んで帰ってきてやるとも思えないんで、努力目標を言われるより実際にかかる時間を知っている方が計画の変更ができるから。」
(父): 「なるほど。それが今風なのか。俺なんか会社で、理屈じゃなくやる気を見せろっていつも怒っているが。」
(あなた): 「やる気は大事ですよ。もちろん。でも、計画はそれを入れて作っちゃいけないんだ。やる気は計画を実行する時にお願いします。」
(あなた): 「ここでひとつの区切りだね。設計図には庭に置いたスケッチもつけてもらうとして、できあがったところでみんなで合意することにしよう。これを、”ウィンコンディションをチェックする”と言います。」
(一同): 「了解」
計画の作成
というような会議を1時間ほど続け、やるべきことがおおむね出そろいました。今回のiMindMapを使った場合、入力した内容は次の図のようなカラフルなものになります。
ステップ2 (ジョブのリスト)のタスク入力
会議ではやるべきことを"What's next?"で順に挙げていきました。この時にプロジェクトマネージャは、間にもれがないように気を配ります。もし先へ進みすぎるようなジョブがでたら、すぐに戻ります。
具体的な行動ではなく、複数の行動を要約したものが出た場合も同じです。所要時間はジョブが出揃ってから考えるのではなく、ひとつずつ決めていきます。やってみなければわからないものもできる限りの予測をします。板を切るというジョブを1日としましたが、これは少し大雑把すぎました。前提条件を置きながらもう少し予測の根拠がわかるように考えた方が後で調整がし易いですし、同じようなジョブが出てきたときにこの経験が活かせます。
たとえば、電動のこぎりを使う、板を長手方向に切断することは屋根と壁の端しかない、曲線は入り口の部分しかなく、そこは電動ジグソーを使う、複雑な接合はしない、という前提条件を考えると、大半の切断は板を短く切るだけなので、板取り図面の寸法通りに墨を入れ（切る場所にしるしをつけ）るのに2時間、板の切断に2時間半、曲線部分に1時間、ペーパーがけに1時間、後片付けに1時間の計7.5時間となります。こうしておけば、前提条件が変わったり新たな事実がわかった時には、それに応じた予測の修正ができるようになります。
この段階で考えるべき3点目の要素、依存関係はとても重要です。これは、それぞれのジョブの内容がある程度わかれば予測はつく場合が多く、もしわからなくてもこのような会議の場であれば、誰かの知恵を借りることができますし、そのジョブを実際に担当する人がいればその本人に聞くのが一番です。それぞれのジョブに依存関係がないと、それをいつ始めればよいかがわからないので、担当者が同じ複数のジョブを直列に並べてしまいがちです。たとえば、依存関係のないA, B, Cという3つのモジュール設計を同じ人が担当するとわかっている（あるいは勝手に想定する）と、3つの設計作業が並列にできるかどうかを考えずにA, B, Cの順に並べてしまうわけです。一度そのような計画ができてしまうと、依存関係があろうがなかろうがその順番を前提にものごとが運ぶようになり、変化への対応や調整ができなくなってしまいます。SPMではそのようなジョブの開始時期や終了時期はステップ4で担当者の予定を考えながら行ないます。
ガントチャート
iMindMapのプロジェクトマネジメントモードで入力した計画は次のようなガントチャートになります。すべてのジョブに依存関係(先行タスク)が定めてあるので、きれいに並んでいます。ただし、これはまだ計画としては完成していません。
ステップ2 (ジョブのリスト)のガントチャート
だれがやるかはまだ決まっていないので、すべてのジョブが担当者の都合とは無関係に並んでいます。一応、推定の所要時間が入っていますので、こうやって並べてしまうと、すべてのジョブの担当者が決められた日にそのジョブだけに専念することになっています。もしその日に他の仕事があったらどうなるでしょう。所要時間の推定によほどの水増しがない限り、遅れがでます。すると、後続タスクも当然遅れます。
一般のプロジェクトで、計画に対して実際の進捗がすぐに遅延する理由がここにあります。残業や徹夜ばかりになるのもそうです。所要時間を予測する時には、それだけに専念したらどれくらいかかるかという基準で予測をし、遂行時には専念できないのですから。
また、別のケースもあります。計画時に所要時間ではなく、いつまでに終わらせるかを決めているケースです。この場合はプロジェクトの状況がもっと悪くなります。当然、担当者の他の仕事など他の要因を考えながら終了時点を決めているでしょうが、そのことはガントチャートには現れてこないのでガントチャートが努力目標でしかなくなり、遂行段階でのプロジェクトマネージャの仕事は「催促」になってしまいます。
プロジェクトにはコミュニケーションが大切だとよく言いますが、プロジェクトマネージャが印刷したガントチャートを片手に担当者に向かって、期日どおりに終わるかどうかを尋ねている場面では、上手に催促するというためのコミュニケーションになっていることが多く、だからこそ大切だと思う、つまり難しくなっていることが多いのです。
ということで、ここではまだ計画はできあがっていません。ステップ4を過ぎ、ステップ5までが終わらないと完成したことになりません。そこへ進む前に別の話題をステップ3として見ていきましょう。ステップ4で考える資源、つまり人の問題の大切な一部、すなわちプロジェクトマネージャ本人のことです。
ステップ2のPSI
次のステップに行く前に、ステップ2のPSIを算出しておきましょう。ステップ2も20点満点で採点します。ステップ2の質問リストは3種類(WBS、ガントチャート、マイルストーン)に分かれています。順に見ていきながら採点してみましょう。
WBS：プロジェクトのためのジョブはすべて列挙され、それらは作業量の見積りと仮定/前提を含み、全体の作業量の10-15%のプロジェクトマネジメントジョブを含んでいるか。
やるべきことはもれなく把握できているでしょうか。今回の例はシンプルなので概ね出ているでしょうが、ステップ1で作ったDMMの中の「機能」-「快適」マトリクスにある寒くなく暑くなくという部分は大丈夫でしょうか。デザインや設計といったジョブにその検討が含まれていて「ウィンコンディションをチェックする(全体デザイン)」のところでチェックされるのでしょうが、もう少し具体的にしておいてもいいかなと思います。たとえば、「風向きと小屋内の空気の流れを検討する」といったようなジョブを入れておくとよいでしょう。
作業量の見積りは前述のような考え方で実施しますが、その際に使った前提などは忘れないようガントチャートツール(今回の場合はiMindMap)のタスクのメモ欄にきちんと書いておきましょう。所要時間の推定はラフですが、具体的で妥当な推定をした上で0.5日とまるめることは問題ありません。ただし、単位は統一しておくべきです。つまり、1日を何時間とするのかということです。通常は、1日=7.5時間くらいでしょう。
ジョブの所要時間の中で一箇所、経過時間が紛れ込んでいます。お姉さんがデザインに2日ほしいと言ったところです。2日あればできるだろうという決め方は現実によく行なわれますが、SPMでの計画作り（プロジェクトプランニングプロセスと言います）では、誰かがこのような推定をしたら、プロジェクトマネージャはすかさず、「2日かかるとどうしてわかるの？」と聞きます。経過時間で答えたような場合は特にです。そのようなつっこみに、お姉さんは次のような推定をしたようです。「デザインは、ラフスケッチを10種類作り(ひとつ10分として100分＝＞2時間)、その中からよいものを3種類選び(15分)、その3種類は彩色する(15分 x 3)。所要時間の合計は、3時間。1日にそこまでできるかどうかわからないから、余裕を考えて2日とした。」これくらいまで具体的な想定ができれいれば、それをメモに入れておき、所要時間を2日としても特に問題ないでしょう。後で何か不測の事態が起きた時にこれを思い出せればいろいろな対処ができそうです。
最後の点はつい忘れがちです。今回もそれを忘れています。ステップ4以降で全体の作業量をさらに考えていくのですが、プロジェクトマネジメント自体の作業量もきちんと計上しておかなければなりません。遂行段階では後でご紹介するようにいろいろなやるべきことがあります。プロジェクト期間全体に渡って全体作業量の10-15%を入れておきましょう。今回の事例では、全体作業量が21.5日ですので2-3日分となり、工期が23日とすると（まだ確定していませんが）、毎日だいたい1時間はプロジェクトマネジメント業務をする必要があるということになります。これをきちんとガントチャートに表現し、プロジェクト遂行時にこれも含めて状況を確認しましょう。
こうして見ていくといくつかまだ足りない点があるので、ここは8点中3点としておきます。
ガントチャート：タスクの時間的流れが図示されていて、主要なフェーズが示され、各フェーズ/ジョブの作業量と相互関係が示されているか。
iMindMapのガントチャートは細かな記述ができないのですが、それでもご覧いただいたようなガントチャートができますので、この点に関してはまあまあ合格と言えそうです。6点中5点あげておきましょう。
マイルストーン：マイルストーンが設定されているか、そこではプロジェクトレビューが計画されているか。
マイルストーンとは、プロジェクトの途中に設けられる中間到達地点です。それは地点であって作業ではないので、所要時間は設定されず、通常のジョブやタスクとは違った表記がなされます。今回の例では、◆で示された「シロの到着」がそれです。
実際には他にもマイルストーンと言えるところがあります。「ウィンコンディションをチェックする」と書いた4箇所の点がそれです。ここのチェックを通過しなければ手戻りが発生することになります。チェック自体は作業ですが、その直後にマイルストーンを書いておいた方が良さそうです。6点中4.5点とします。
評価
採点結果を見てみましょう。3+5+4.5=12.5点となりました。20点満点で12.5点。上の解説でどこが足りないかわかるでしょう。
ステップ2でのポイントは、やるべき作業がもれなく想定作業工数付きで列挙され、それらの関係（全体から眺めたフェーズと、前後の依存関係）が示されることです。
