プロジェクト計画書の作り方｜WBSの作成
細かい話をする前に、ざっと要点だけをまとめておきます。
チーム一丸となって1つの目標を達成しようと思った時、あらかじめ計画を立てて計画通りに進行するためには、計画自体が実現性のある精緻なものでなければなりません。
ちなみに私の我流な感覚では、
「７割精緻に、３割は打算で」
くらいを１つの基準にしています。計画は「精度の高い行動指針」であっても「完璧な未来予測図」にはなりえません。都度見直しが発生するものですし、そもそも計画を立てる際に
・すべての仕様が確定していて変更されることは決して無い
・メンバーの誰もが予測通りに行動するとは限らない
と言ったことも加味しておく必要があります。その意味で、「どうしても詳細化できないもの」や「確度の低い予測しかできないもの」というのは出てきます。その際に、
『これを計画と呼んでいいのか？』
のジャッジを、私はおよそ７割が納得できる根拠を伴っているかどうか…で決めています。10割なんて求めません。
さて。
PMBOKでも策定されていますが、「計画」の段階でやっておくべきことは様々です。PMBOKでは10の知識エリアにわけて様々なことを検討し、明確にし、具体的な手段を講じてメンバーに周知しておく必要がある…と言われています。
ではどのようなポイントを押さえて計画すればいいのでしょうか。
プロジェクトで時間やお金と言ったリソースを使うからには、効率的で無駄なくプロジェクトを進めなければなりません。
そのためには段取りが重要であり、プロジェクト計画書を実際の作業を始める前にしっかりとシナリオを作り込み、完成させておかなければなりません。
ただし、ある程度まで進まなければ細かいところを決めきれない場合、次のどちらかの計画方法を選択します。
①全体の大枠計画を作成しておき、
詳細な計画は作業が進んでから都度作成する。
②プロジェクトを複数に分割して順次実施することとし、
各プロジェクトの開始前に計画書を作成する。
みなさんが選択したくなるのは、前者かもしれません。
しかし、前者は工程が後ろに進めば進むほどキツくなっていくこともわかっているはずです。なぜなら、チームのどこかで必ずと言ってもいいほど学生症候群のような症状や、パーキンソンの第一法則のような症状が出てしまい、リミットギリギリまで時間を使い切ってしまうでしょうから。前半に緩く進めると必ず後半にキツい締め上げが来ます。その時点で大抵計画性がない進め方をしているということになるのですが、計画を立てることに苦手意識を持っている人はどうしても前者を選択しがちです。
後者を選択する人のために「プロジェクト計画書」の基本要素について簡単に説明しておきます。
基本要素として押さえておくべき点には以下のようなものがあり、それぞれのポイントに沿って内容を検討しなければなりません。
目的
「なぜ、それが必要なのか」を明確にすること。それを自社の売上や利益と言った観点ではなく、
「プロジェクトが生まれる要因」
お客さまがなぜ自社に仕事を持ち込んだのか、何をすることがプロジェクトへの要求事項か、そこからわかるようになってきます。目的こそがお客さまの要求事項の本質となります。
そして注意すべきは『目的と手段を混同しない』こと。
この１点です。目的が果たされないとプロジェクトを実施する意味がないので、ここを履き違えるとこの後に続く
『目標』
を見誤ってしまいます。目的は「なぜ達成させるのか？（Why）」、目標は「なにを達成するのか？（What）」を問われていると思ってください。最終的には、 目的が達成されたことが判断できるよう具体的なゴールを定義することになりますが、このゴールこそが「目標」となるわけです。
目的というと、概要説明とか「はじめに」の説明文という位置づけと勘違いしているマネージャーも多いのですが、ここを正しく理解していないプロジェクトはその後の活動方針や明確な進め方のなかで「自分はこうする」という主観的な視点ばかりで、顧客が満足する進め方になっていないことがよくあります。
前回の話を引用するならば、「なんとなく」「毎年恒例だから」遠足に行こうと言っていて、その遠足自体の目的がどんどん曖昧になっているイメージだと思ってください。
そもそも遠足は
「校外の豊かな自然や文化にふれる体験を通して、
学校における学習内容を充実発展させる」
ことを目的としています。この目的を踏み外した学校や教育では、
・とにかく子供ウケする内容にしがち
・トラブルや社会的評価ばかり気にする内容にしがち
・事前確認するのが楽しみなところを選ぶ
といったまったくお門違いなテーマを設定してしまうかもしれません。目的を履き違えるとは、それくらいヤバいことなのです。
スコープ
これは絶対に必要な情報の１つです。仕事一つひとつが契約によって成り立つ以上、
・どこからどこまでが契約の範疇なのか（業務範囲）
・どこからどこまでが責任の範疇なのか（役割・責任範囲）
・何を納めればいいのか（成果物範囲）
が定められていなければスケジュールも決められませんし、スケジュールやそこに割く人員が決まらなければ当然対価も決まりません。そう、そもそも契約自体が成り立たないのです。
範囲がグレーな部分については、プロジェクトの“範囲外”となるものが何かを書くことで明確化しましょう。なにも記載は「範囲内」のことだけしか書いてはならないわけではありません。すべてを明らかにできない場合は「絶対のここはスコープの対象外だ」と言えるものを列挙しておきましょう。
案外、人というのは自分にとって「得」となるものをすべて列挙するのは難しく、自分にとって「損」となるものについては非常に敏感で、正確に把握していたりするものです。
とにかくハッキリしているのは
スコープが明確にできないなら「請負」で契約してはならない。
です。最低でも成果報酬型の「準委任」か、必要な成果物すらもあやふやになるなら履行割合型の「準委任」としておくべきです（アジャイルなんかは個人的に履行割合型かな…？と思ってます。だって、機能数も機能ごとの複雑度もさっぱりわからないんですから、期間内に必要な成果物が完成するかどうかもわからないので（それだけ検討等に工数かけてるのに）、成果報酬型では真っ当な検収は行えない気がしています）。
作業リスト
わかりやすく作業リストといいましたが、要するに「WBS（Work Breakdown Structure）」です。
「プロジェクト」という非常におおざっぱで一括りにされた仕事をある程度まで分解し、構造化、リスト化したものです。これがなければ
①作業の抜け漏れが検証できません
②スケジュールの精度が上がりません
③作業間の繋がりがわかりません
④繋がりがわからなければ、どんな成果物が必要になるかがわかりません
このようなイメージが出来上がらない限り、「どうやってゴール（目標）に到達するのか」を具体化することは決してできないでしょう。
作業を階層的に分解していくには、まず最終成果物を分解し、各成果物を生み出すための「検討／準備→実施→チェック／承認→公開」という作業手順でさらに分解します。
ポイントは「最終成果物」。
この定義と、そこから逆算的に分解していくことが大事です。
マネージャーであれば「プロジェクト」の最終成果物から検討することになりますが、メンバーであれば自らに求められている担当部分の最終成果物でもいいわけですしね。一人ひとり異なってきます。
ただ、どんな単位で検討するとしても、「まず最終成果物から」というのは変わりません。目標を見誤らないという意味でも絶対です。
これをしないのは闇鍋に似ています。
「鍋」という目標でありながら最終成果物である「鍋」であることを無視し、とにかく「おもしろい」ものを集めようとしますよね。最終成果物から考えていれば、おもしろくはないかも知れませんが美味しい鍋が食べられたかもしれません。
スケジュール
「QCD」という言葉がありますが、この言葉が示すように
Ｑ：品質（Quality）
Ｃ：コスト（Cost）
Ｄ：期限（Delivery）
というのはどんな仕事であっても必ず存在します。プロジェクトであればなおさらです。
期限までに目標を達成する必要があるからこそ「プロジェクト」が発足されるわけですから、その期限内に達成できるスケジュールを検討しないことにははじまりません。
闇雲に始めても誰も安心はしないし、信用もしてくれないのですから。
体制
そしてここも重要です。
プロジェクトにはそれぞれ難易度があります。上記の図にあるように「独自性」が伴うため、ある専門性を求められる要求に対して素人／アマチュア／プロでは全然効率が違います。場合によっては一歩も動けない…という人も出てくるでしょう。
スケジュールというのは
その通りに進められる「力量を持つ人材」と
その通りに進められる「環境の整備（段取り）」
がないと絵に描いた餅でしかありません。
そのためにも「プロジェクトを推進する体制」をしっかりと検討するのはとても重要なマネージャーの仕事となります。
と言っても、一般に一介のプロジェクトマネージャーには人事権はなく、メンバーの選定をすることもできないことが多いと思います。おそらくはラインの管理職がその時その時の空き要員の状況を見ながらメンバーを決めていることでしょう（無能な管理職であればだいたいテキトーなんです、ここが。そのせいでトラブル増加数が増えるとわかっているのに）。
当たり前ですが、すべてのメンバーをプロフェッショナルでそろえる…というのは現実的ではありません。企業であれば毎年新人を採用していたり、なかには未経験の中途を採用することだってあるでしょう。
そうした社員も養っていかなくてはなりませんから、バランスを考慮して１～２割ほど未熟なメンバーを加えることになります。
これを負担と考えてはいけません。
仮にそれを考えることを許されるとしたら、みなさんが新人だった頃から未熟ではなくプロやベテランと同じくらいのパフォーマンスを出せていた…という場合だけです。
誰でも未熟な時期はありました。そのことを棚上げして、今の自分の実力だけに驕って「全員がプロじゃないと嫌だ」「若年層の面倒なんてみたくない」なんてほざくのは、そもそも技術的要素以外が未熟である証拠です。マネージャーを担う資格も怪しいと言わざるをえません。
体制を整え、必要なスキルに満たない要員に対してはＯＪＴのプランを考えたり、一人ひとりの生産性を考慮してスケジュールの組み直しを検討することになります。
この時、気を付けなくてはならないのが『業務配分』です。
日本の場合、時間精算で給与が支払われている企業がほとんどですので、同じ待遇の人の仕事量に差をつけると、メンバーのエンゲージメントはあっという間に落ちます。
たとえば単価70万の人が２人いたとして、その２人の作業のボリュームや難易度に大きな偏りがあった場合、それは適切な業務配分とは言えません。
そもそも生産性１つ取っても、大きな差があるなら待遇面から見直すべきなのですが、企業としても管理職としてもまともに評価できる人なんてごくわずかですから、どうしても不平等が発生しやすいんですよね。
その割に、多くのマネージャー、多くの管理職は「できる人に多くの仕事を割り振る」傾向が強く現れます。会社からの要求に対して答えるために、人の育成をする負担を抱えることよりも、「できる人に押し付ける」方が圧倒的に楽だからです。
その結果、組織マネジメントがどんどんザルになっていくことや、有能な社員のエンゲージメントが離れていくことになっても、どうしても止めようとしません。
この点だけは本当に気を付けないと、マジでロクでもないマネージャー、ロクでもない上司にしかなれなくなってしまうので気を付けてください。企業自体の評価制度が未熟であれば、それでもとにかく目先の組織目標を達成していれば評価され、部下を潰しても自分だけは昇格していくかもしれません。ですが、そのぬるま湯に浸かりきってしまうと「つぶしが利かない」人材となって、他企業では一切"使えない"人材となり下がってしまっていることでしょう。
そうなりたくなければ
①１～２割の人的負債は許容したうえでスケジュールを立てる
②一人ひとりの配分に公平性を欠かない
③育成や教育も視野に入れたマネジメントを心掛ける
を前提として体制を考えられるようになりましょう。ここは企業貢献というより「他人の人生」にも大きく影響を与える部分でもありますので、個人的にはマネージャーの資質の中でも最も重要な要素の１つだと考えています。
そのうえで
・指揮命令系統が明確になるよう体制図を書く
・役割分担／責任／権限を明確化する
・絶対に嘘にしない
ようにしてください。
特に体制図は、人と人を線で結ぶことになりますが、この線が報連相を中心としたコミュニケーションパスとなります。最後の「絶対に嘘にしない」と書いているのは、体制図を無視して
「マネージャーがいるのに、勝手に指示を出す管理職」
「リーダーがいるのに、勝手に別のリーダーに相談に行くメンバー」
といったことを簡単に起こしてしまって形骸化させるケースが後を絶たないからです。これをやってしまうと情報が必ず錯綜します。そしてそれを整理するために無駄な会議体が増えることになります。
まとめ
とかく「必要なこと」というのは、言われてみれば常識的な内容ばかりです。わかりやすく言えば
「最初に決めておいてくれないと、どうすればいいかわかんない」
ことを決めておきましょう…と言っているだけなのです。
だから、プロジェクト計画書を作成できないマネージャーというのは、残念ながらマネージャーではありません。肩書きがそうだというだけで、マネジメントできるだけの情報を揃えないまま、なんとなくその地位にいるだけの人…となってしまいます。
もちろん、企業やチームによって書き方は違うでしょう。
書き方が違えば『読み方』も違ってくるので、参画するメンバーや関係者は書き方によって読み方を変えなければなりませんし、その読み方を関係者全員に正しく伝える必要も出てくると思います。
たとえば、「体制」というと体制図だけ書いて終わり…というプロジェクトも珍しくありません。その多くは「なぜ図を書くのか」「その図から何が読み取れるのか」を正しく説明することもできないマネージャーばかりでしょう。
ですが、体制図上に引かれた関連線１本とっても、
情報の連携先がどこにあるのか
自ら情報を連携する必要がない相手は誰か
自ら情報を連携する必要がない相手に連携してくれるのは誰か
そういったコミュニケーション上の責任を負うのは誰か
等も読み取れるようになっています。逆に、そこに関連線が引かれていないのに、「自分が楽するために」代わりに指示を出してコミュニケーションを取らせたり、かかわりのない会議体に無理やり参加させるようになってくると、そのプロジェクトは危険視しておいた方がいいでしょう。
体制もまともにコントロールできない人が牛耳っている可能性を持っているかもしれないのですから。
スケジュールも「毎週のようにリスケする…」プロジェクトなんてのもザラです。
「１週間前にオンスケでした。」
「３日経ったら１日遅れ。」
「５日経ったら２日遅れ。」
「１週間後、リスケしたのでオンスケに戻りました。」
なんてことしかできないマネージャーは一度マネジメントを勉強し直した方がいいかもしれません。チーム内部のスケジュールであればともかく、たとえば企業に報告しているスケジュールであれば企業の信頼を裏切り、顧客に報告しているスケジュールであれば顧客の信頼を裏切りになりかねない行為だからです。稀に単発で起きる程度というのであればまだしも、頻発するようであればそれは
・そもそもが絵に描いた餅で、その程度のスケジューリングしかできない
・監視コントロールの戦術が甘く、スケジュール通りに推進できない
のどちらかなわけですから、マネージャーとして相当に未熟であるのは間違いありません。もしここでメンバーのせい、顧客のせいにするようなら、ますますマネジメントするにはあまりにも力量が不足していたことが明らかになるだけです。
そう言う人たちを正しく導く、あるいはうまく躱してコントロールするからこそのマネジメントなわけですから（よほど悪意がある相手であった場合は別）。
さて。
プロジェクト計画書にはまだ他にいくつか記載するべきことがありますが、長くなってしまったのでまずはいったんここまでにしておきたいと思います。
続きはまた今度。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。