プロジェクト計画書の作り方｜体制図を作る
今も毎月、数件のプロジェクト計画書をチェックしていますが、体制図が作成されていない計画書も珍しくありません。
つまり、
体制図なんて意味がない
と思っている人がまだまだ多いということなのかもしれません。
しかし、それは間違いです。
厳密には「誰と誰が…」とバイネームで線が引かれているだけの体制図は確かに意味がありません。体制図で最も重要視すべきはそこではないからです。
体制図を作る目的は、
プロジェクトに参加するメンバーとそれぞれの役割、
そしてメンバー間の指揮命令系統を定義すること
にあります。
そもそも、この目的を理解しないままでただただ「作れ」と言われたから作りました的なニュアンスで進めると、体制図どころかプロジェクト計画書自体が意味のないものとなってしまうでしょう。
「そんなの教えられなければわかるわけがない」と言う人も出てきそうですが、物事にはすべてにおいて因果関係や相関関係があることを考えれば、せめて
「何か必要があるから作れと言われているのだろうけれども、
なぜこれが必要となってくるのだろう」
と思いを馳せても良いのではないでしょうか。
ほとんどの方は普段の仕事の中で自身の役割や、上司や部下、同僚との指揮命令系統が決まっています。
しかし、プロジェクトは課や部と言う組織とは別に独自性をもって新たなチャレンジ活動を求められているものであり、普段の定常的な仕事とは別に新たなプロジェクト体制を構築する必要があるのです。
従って、プロジェクトの体制がしっかりと明確化されてないと、必要な指示や報告がうっかり伝わらなかったり、意思決定に時間がかかったりして作業ミスや効率低下の原因になってしまいかねません。
一般的な体制図の書き方
プロジェクトの体制図だからと言って会社の組織図と書き方は変わりません。
それでは、プロジェクト体制図の例を見てみましょう。
この例は、山田さんがプロジェクトをマネジメントし、そのもとでメンバーが2つのチームに分かれて作業を進めるというプロジェクトの体制図です。
あまり馴染みがないのは “プロジェクトスポンサー”という役割でしょうか。
会社などの組織の中でプロジェクトを進めるような場合には、ほとんどの場合このようにプロジェクトスポンサーという役割がプロジェクトマネージャーの上に必要となります（“プロジェクトオーナー”や、“プロジェクト責任者”などといった呼び方をする場合もあります）。
これは、組織の中でプロジェクトを実行することを承認する（組織に所属するメンバーや組織のお金など、いわゆる経営資源をプロジェクトに投入することを判断する）役割を持ったメンバーのことです。
たとえば、自社の経営資源をコントロールできる役員や部長などの役職に就いている社員がこの役割を担うことになります。簡単に言えば「決裁者」と考えてください。
多くの企業で規模ごとに決裁権が変わっているのではないでしょうか。
たとえば
1000万未満であれば課長
3000万未満であれば部長
5000万未満であれば本部長
1億未満であれば担当役員
それ以上ならば社長稟議
…といった具合です。通常、係長職や主任職には、勝手に決済して良い権限はないことが多いと思います。そして、この体制図によってチームやメンバー構成の他に次のような指揮命令系統が表されていることを確認してください。
原則、これらの線以外に勝手に飛び越えて指揮命令／報告連絡する資格はだれにもありません。体制図を見て上下関係があると勘違いして、上位にある人がこの指揮命令の線を無視してしまうことがありますが、それが一番組織的な活動を阻害しているのだということは注意しておいたほうがいいでしょう。
このように、プロジェクトの体制図ではメンバーは
「誰の指示に従えば良いのか」
「誰に報告すれば良いのか」
という関係線も定義されているのです。
特にプロジェクトの体制図では「箱と箱が線で結ばれていない」「複数の線が箱から同じ方向に出ている」など、指揮命令系統が曖昧になってしまうことがないように注意しましょう。
もし、そうなっていた場合、必ずプロジェクトに歪みが生じ、下手をすればトラブルを招くことになります。
大事なのは「誰」が担うかではなく…
ここまでなんとなーく読んでいた方は「そんなのわかってるよ」と考えてらっしゃるかもしれません。そう感じるように書いてきました。
ですが、体制図を作ることを求めるプロジェクトマネジメント要素…すなわちリソースマネジメントにおいては、「体制図を作ること」や「誰をアサインするか」を求めてはいません。リソースマネジメントにおいて重要なのは
何の役割が必要なのか
その役割を担うためにどのような力量が必要なのか
その役割が何人必要なのか
を定義、構成することです。
その力量を持ってさえいれば「誰」でもかまいません。オブジェクト指向的に考えてみてください。interface定義上、同じ条件を満たせば誰でもいいのです。それをプロジェクトを完遂するために必要な数分揃えることが重要なポイントとなります。
サッカーや野球などチームスポーツでも同じですよね。
GP（ゴールキーパー）という役割があり、GPにはGPならではの求められる資質というものがあります。DF（ディフェンダー）にもFW（フォワード）にもそれぞれ資質というものがあります。サッカー経験者なら誰でもできるというものではありません。
野球でも同じです。
肩の弱い人がピッチャーやキャッチャー、あるいは外野に向いているでしょうか？
瞬時の適切な判断能力の低い子に守備範囲の広いショートは任せられるでしょうか？
まず「役割」ありき。
次に「役割に求められる力量」ありき。
最後に「必要数」を揃える。
逆に言うと、これら３点を満たしているかどうかもわからないまま「アイツを追加しよう」「この子ならできる」「これだけいればやれるだろう」などと感覚的に指定しているのはプロジェクトマネジメントとは呼びません。
前回説明した『作業リスト』、そしてその延長線上にある『スケジュール表』には何が書かれていたか覚えていますか？
そう
「誰が、どの作業を、いつからいつまで実施するのか」
が書かれていたはずです。このスケジュール表と体制図があれば、プロジェクトの各メンバーの役割は大体決まったことになります。
ですが、実はプロジェクトではスケジュール表に書いた作業以外にもやることがあります。
たとえば「作業中に何か問題が起こった場合に対策を立てて実施する」などといった、あらかじめ計画できないような作業のことです。そのようなことを誰が責任を持って実施するのか、これらの資料ではまだ十分に明確化できていません。作業リストやスケジュール表は「最も理想的な形で進んだ場合…」の内容しか記述できません。最初からリスクを想定した内容とはなっていないのです。ですから、作業リストやスケジュール表だけでは絵に描いた餅（形骸化）になりやすく、いざというときに対処できず炎上しやすくなったりするわけです。
これを未然に防ぐためには、作業リストやスケジュール表にないリスク分を想定しなければなりません。ですが、実際には起きてみないと規模や影響度の度合いもわからないものを見積ることもできません。
そこで、重要なのが“役割定義”を明確にすることです。
作業リストやスケジュール表には載せられない領域についての
「役割（＋権限＋責任）」
をさらにしっかりと明文化することが有効になります。
そうすることで、明文化できない作業や状況に対しても右往左往することはグッと減ることになります。
「イマイチ誰がどのような立場なのか曖昧だな…」
と感じたら、次のような役割分担表を作成してみてください。
特にプロジェクトの活動に慣れていないメンバーや新しく一緒に活動するメンバーが多いプロジェクトの場合には、ここまで役割を明らかにしておくことがミスや効率低下を防ぐことに繋がります。こうすることでそれぞれの役割を与えられた人たちに責任感が宿ります。
もし、こうした表を書くのも読むのも少ししんどい…と思うようなら、RACIチャートを作ってみてもいいでしょう。
RACIチャートとは「Responsible」「Accountable」「Consulted」「Informed」の頭文字を合わせた言葉で、それぞれの役割を表にまとめたものです。 具体的にはプロジェクトチーム内において誰がどのような役割で関わるのかを示し、役割や責任を明確にします。
役割をすべて洗い出すのはちょっと面倒ですが、こうした表であれば一度作ってしまえばどのプロジェクトでも再利用性が高いものとなりますのでやってみて損はないと思いますし、なにより読む負担はグッと下がりますよね。
そして、もしも役割を与えられているにもかかわらず、その役割に見合った責任意識が薄い人がいるようであればその人は重要な役割を任せてはならないということになります。なぜなら「責任を負う」という社会人として、あるいは組織人として至極真っ当な職責を放棄するということを意味するからです。
これは能力の問題ではありません、責任意識の問題です。
プロジェクトとしても、企業としても明確な評価軸として活用できることでしょう。
このように、役割分担を明確化することで「誰がやるべきか」「誰がやってないのか」を認識や意識ではなく、ルールや責任によって判別することを可能にすることが体制や役割を定めることの目的となります。
体制図上、末端の作業担当者であればまだしも、決定や指示を行うべき役割を担うものがその責務を果たさなければそこから先の活動においてメンバーは行動することができず停滞を余儀なくされてしまいます。
指示するべき役割の人が必要な決定や指示をしてくれないというのは、わかりやすく言えば、
「お客さまが仕様を提示してくれなければ、
モノを作ることができない」
と言っているのと同じ状態を生み出すということです。
ここ数年で私が見てきたトラブルプロジェクトでは、その殆どがこれと同じ理由で発生しています（もちろんただの御用聞きではなく、ソフトウェア開発のプロであるならば受動的に指示や決定を待つだけではなく、提案や督促、交渉等に対して主体的であるべきなのですが）。
少なくとも「体制を決め、役割と責任（および権限）を決定する」ことにはそれ相応の意味・目的があり、しっかりと共有・徹底することで相応の効果があがるものだということを知っておきましょう。
組織マネジメントにおいてもそうですが、どのような事業、業務、ミッションであれ体制や役割（責任）を明確にせず、適当に進めようとするような人とは絶対に一緒に仕事をしないほうがいいと思います。必ずする必要のない苦労を強いられることになります。
案外難しいリソースマネジメント
ここまではプロジェクトマネジメントとして必要な作業となりますが、このリソースマネジメントがなかなかに難しいのは、
組織マネジメントと有機的に連動しにくい
点にあるのではないでしょうか。
役割定義や力量定義ができたところで、そのプロジェクトチームに実際の「人」を充てるのは上長…いわゆる開発側企業の管理職層になることでしょう。プロジェクトマネージャーに人を選定、アサインする権限や決裁権はない…ということのほうが多いと思います。
こうした力量定義に対し、組織の
「どれだけ環境を整えてあげられるか」
という支援体制がプロジェクトの成否を決めることも少なくありません。
事実、トラブルプロジェクトの多くは
リソースの力量不足（メンバーアサイン時の責任放棄）
プロジェクトに対する開発側企業の善管注意義務違反
が根本的な原因ということは少なくありません。「もっとメンバーアサイン時に力量の適したメンバーを調整してあげていれば…」「プロジェクトマネージャーからのエスカレーションをもっとちゃんと聞いてやっていれば…」後々になってそういう反省をする上司ってとても多いんです。何度も聞くので、本当に反省しているのかどうかはわかりませんが…。
要求する力量に満たない人への対処
しかし企業（上司）も常に希望される力量のメンバーを用意できるわけではありません。それは必ずしも企業（上司）に全責任があるとは言えないのが実情です。
売上や利益のことを考えると人を遊ばせておくことはできませんので、稼働率100%となるよう常に何かしらのプロジェクトやミッションを与えているからです。
そうなると、プロジェクト発足時点で手の空いているメンバーの中からしか選定することができません。もちろん外部発注によって委託、委任等をおこなうという手もあるのですが、そうした場合は力量定義が全く機能しなくなることのほうが多いのではないかと思います。
結果、プロジェクトを完遂するために必要最低限求められる力量を有していないメンバーであってもとにかく必要数分揃える…という現実的な問題にぶつかってしまうプロジェクトも多いことでしょう。
そこで、プロジェクトマネージャーには先に述べた「役割」「力量」「必要数」の３点定義のほかにもう１つリスクマネジメントの一環として検討しておくべきことが求められます。それが
力量に満たないメンバーへの対処
を計画に組み込むことです。
作業リストやスケジュールにあらかじめ組み込めればそれが一番ですが、そうでなかった場合でもリスクヘッジとしてプロジェクト発足直後や各工程開始直後には多少の教育・育成などの余剰を組み込めるようにしておくといいでしょう。
私がプロジェクトマネージャーをやっていた頃は、
ありとあらゆる不明点に対してフォローする
毎月初に半日ほどの説明会の場を開く（参加は自由）
メンバー増加時には都度説明会を開く
ガイドラインやマニュアルは都度作成する
ほぼ毎日定時ごろにはメルマガと称して以下のことを周知
その日一日のプロジェクト状況
課題や問題のピックアップと解決方法
ちょっとした作業のTIPS
その日質問のあった内容に対する回答の共有
等、こまめにやってました。それでも中には非協力的なメンバーもいて、一部では上手くいかなかったりすることもあるので、やりすぎるくらいがちょうどよかったりします。
また、体制上で支援メンバーを用意しておくのも有効です。
特に、構成管理や問題解決管理については通常の作業負担をやや減らしたうえで、先任者（正・副２名ほど）用意しておくとよいでしょう。作業リストやスケジュールに記載されないような微々たる業務であっても、案外個々人任せにしてしまうと先に述べた力量の細かい差によって不具合や問題を起こしてしまう人が出てきます。
できるだけ誰もが同じこと行うような共通作業などは一元化しておいたほうがいいのです。プロジェクトマネージャーの力量が低い場合、安易に「みんなで」とか「ＡさんとＢさんで協力し合って」というような指示を出してしまったりしますが、基本的に複数人指定を行う場合は
責任感も併せて分散する
というリスクがあることを忘れないようにしましょう。「みんなで」といえば「誰かがやってくれるはず…」とお見合いをして誰もやっていなかった…となってしまっていたり、「ＡさんとＢさんで協力し合って」といえば立場の微細な差でどちらか一方に丸投げしてしまって他方がなにもしなかった…なんてことは珍しくありません。むしろ協力的・有機的に機能することは稀です。
体制を考え、人に役割を設定する際には必ず個々人に責任意識が芽生えるようにしなければなりません。
これは組織マネジメントでも同様です。
偉い立場になればなるほど、大きなミッションを抱えることになりますがその成否に対する責任は偉い立場に就いている人自身が持つもので、実作業を部下に委任するにしても部下は実行責任を負うにすぎません。成否の責任はあくまで委任する側が持たなければなりません。
このことをわかっていないから「丸投げ」が横行し、成否に対する責任意識を持たないがために状況のモニタリングすら怠って、問題が起きてしまってから「おい、どーなってんだ！」と怒鳴りこむような人が後を絶たないのです。
役割と責任と権限
は常に三位一体です。役割と責任だけを押し付けて権限までは手放さない…というのはまかり通りません。そんなことをすれば役割と責任しか押し付けられなかった人は、権限を制約されてしまって活動範囲が狭まり、失敗しやすくなるのは当然です。
その他
役割定義と体制図、そして作業リスト／スケジュール表。
基本的に、これだけあればすべてのプロジェクトタスクが網羅できている…という勘違いは捨てましょう。案外、これらだけでは絶対に網羅できない隠れたタスクは存在します。しますし、しかもかなりスケジュールを圧迫するものが隠れています。
そのお話は次回したいと思います。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。