VUCAという言葉が出てから随分経ったかと思いますが、変化の激しい現代社会は新しいことに常に挑戦していかないと勝ち残ることが厳しい社会です。

当然、同じことを繰り返しているだけでは市場での競争相手に負けて「ジリ貧」状態に陥ってしまいます。事業が長く成立することはありません。

そこでたくさんの人がスタートアップを始めたり、多くの企業では新規事業や新規サービスの開発に取り組んでいますが、そうしたプロジェクト的（有期性・独自性）な試みというのは必ずしも成功率は高くありません。

特にＩＴ業界のＢ２Ｂ型のソフトウェア開発などはすべて「プロジェクト」という単位で活動することになりますが、その成功率は決して高いものではありません。

ある調査では３割程度とも言っていますし、別の調査では６割と謳っているところもあります。しかしこれらはアンケート調査によるものでしかありませんし、企業の全てがバカ正直に答えてくれているとも限りません。ここに出てくる数字は所詮氷山の一角でしかないのです。もっと高いかも知れませんし、もっとずっと低いのかもしれません。それにプロジェクトの規模や難易度、対業界などの違いによっても変化するものでしょうから、一概に信用できるものではありません。

ただわかっていることは、そんな背景があるとわかったうえで、それでも表に出てくる数字は３割～６割と、お世辞にも高い数字とは言えない成功率であるということです。

実際、プロジェクトの現場でも多くの失敗を見聞きします。
その失敗の原因はどこにあるのでしょうか？

ある調査では、失敗の原因はこのように報告されています。プロジェクト経験の多い方は思わず納得してしまうのではないでしょうか。

確かに失敗するプロジェクトを見ていると、上からのあるいはお客さまからの鶴の一声でやることが決まって「なんとなく」予算と納期が決まって、具体的なことがなかなか決まらずにヌルっとプロジェクトが始まって、ああでもないこうでもないとやっているうちに時間が過ぎてリソースを食い潰していく…というケースが非常によく見かけます。

これが結果的に、不完全な要件定義やリソースの不足、関係者の協力不足や非現実的な期待などに繋がってしまうとわかっているはずなのに、です。

しかも、その多くは「自分のせいじゃない」と言い合っているだけで他責しかしようとしないため、いつまで経っても自分の足元を改善しようと言う働きが発生しません。なんて不毛なことなのでしょう…。既存のやり方を変えなければ、今後も状況が好転することは絶対にありません。

逆に、成功率の高いプロジェクトマネージャーを見ていると、

• 「決めなければいけないこと」をできるだけ早めに決めにいっている

• 計画通りにならないことを言い訳にするのではなく、計画通りに進めるために最大限の努力をしている

ことがわかります。
たとえば

　「仕様が決まってない」

１年に何度も耳にする言い訳ですが、同じ状況におかれても成功率の高いプロジェクトマネージャーはそれをそのまま他責にして終わりません。

仕様が決まっていない、要求や要件が決まっていないのであれば

　スケジュールを確認し
　いつまで待てるのか算出し
　決めるためには何が必要なのかを整理し、
　さっさと決める（または決めてもらう期限を決める）

という動きを即座に実施します。それでも決められないのなら、決められない人を担当から外すしかありません。明らかにプロジェクトのなかで割り当てられている役割に対して力量が足りていないのですから仕方ありません。

それをしないのは面倒だからなのか、それともマネジメントリテラシーが低いからなのかはわかりませんが、必要な情報さえそろえば決定はさほど苦労しないのですからさっさと情報を揃えてしまえばいいだけです。

ただ口を開けて待っているだけで、誰かがエサを与えてくれるまでギャーギャーわめき散らす状態を当たり前だと思うようなものは決してマネジメントとは呼びません。

つまり、プロジェクトの早いうちに「不確実性を早く潰していく」のが成功のカギになるのです。その際に重要なのはやはり「計画」です。

「失敗しない計画」は何が違う？

どんなプロジェクトでも企画段階で予算獲得のために計画を立てると思いますが、計画は

　「理由や背景（why）」を元に大きく分けて「何を（what）実現するか」

の目的・目標計画と、それを

　「誰が（who）どこで（where）どのように（how）いつまでに（when）実現するか」

の実行計画という二通りのものを作成する必要があります。

多くのプロジェクトでは「何を実現するか」という目的・目標の計画には時間が割かれている一方で、「誰がどこでどのようにいつまでに実現するか」という実行計画がおろそかになっているために失敗するのです。

実際、これまで見てきた多くのプロジェクト計画書は何かのテンプレートをそのまま引用しただけの形骸化したものが多く、具体性が伴っていて客観的に見ても実現性を感じるようなものは数年に１度しか見かけません。

確かに商談や予算承認のために分厚い資料を作って盛大なプレゼンテーションをやるとひと仕事終わった気持ちになるのは理解できますが、それはスタートラインに立ったに過ぎません。

当たり前の話ですが、プロジェクトは

　最後まで求められる品質や予算、納期を守ってキッチリ終わること

が大事です。

そこで「やはり計画は大事だ」と事前に精密な実行計画を立てるケースがありますが、そもそもプロジェクトというのは新しいことに挑戦して価値を生み出すという試みなので、ルーチンワークと違って事前に完璧な実行計画を作ることはできません。

たとえば、新宿の雑踏や東京駅の地下街を入り口から目的地まで「どの方向に何歩歩いて何度ターンしてまた別の方向に何歩歩く」などとルートを事前に精密に計画するのはほとんど不可能なのと同じことです。仮に可能だとしても、その事前計画にはかかる労力と時間の多さに反してほとんど意味がないでしょう。

また「何を実現するか」という目的の部分も、実際のところは始めてみないと分からないことも多かったりします。

たとえば、あるシステムを作るときに手を動かして技術の深掘りをしてみないと実現可能性やかかる工数が判断できなかったり、連携する他のシステムの仕様が固まらないと決められない部分があったりするのは当然のことです。

　プロジェクト計画は不確実性が少ないほうが理想的ですが、
　実施前に詰められる部分というのは限られているのが現実

なのです。

つまり、プロジェクト計画は目的・目標計画と実行計画は相互に影響し合うもので、プロジェクトの進行に応じて常に精度を高めるためにメンテナンスしていく必要があります。

言い換えるなら、失敗しないプロジェクト計画は常に鮮度が保たれている（常に最新の状況にあわせて最適化されている）のです。

計画鮮度を保つために様々な調整や努力をしているのを見て

　「なんで計画を変えたんだ」
　「いちいち変えるの面倒くさいんだよね」

などと言う人がいたらその人はプロジェクトマネージャー失格です。

ステークホルダーに影響を及ぼすマイルストーンまでを容易に変更するわけにいかないのは確かですが、本質的に求められているのは『プロジェクトを成功させる』ことであって『計画を変更しないこと』ではありません。

どうやって計画鮮度を保つか？

ここで問題になるのは計画情報の共有と更新の手軽さです。

ExcelやPowerpointで作成された重厚な資料は更新性とリアルタイム共有の要素が弱く、メールで送ったり社内ファイルサーバーなどに置いておいても見る人はほとんどおらず、あっという間に形骸化して「死んだ計画」になってしまいます。

いえ、仮にExcelやPowerpointで作成したとしても、そもそもプロジェクトマネージャー自身が利用頻度を下げているのでは形骸化するのも当然です。私ならことあるごとに用いますし、会話の中で引用します。毎日言うでしょうし、使うでしょう。

プロジェクトの規模が小さければそれでもなんとかなりますが、規模が大きくなればなるほど形骸化するのも早くなります。過去見てきた中では作成して数日後にはもう役に立たない資料になっていた…なんてシーンもありました。

たとえば、途中参画したプロジェクトで全体像を把握するために社内ファイルサーバーを漁ったら、入り組んだフォルダ構成の奥にプロジェクト計画書を見つけて、それに目を通してみると最終更新日は１年前で、さらに更新した人はもう退職していた…なんてことは息の長いプロジェクトではよくあることです。

そうでなくても、自分で作ったプロジェクト計画書をどこに格納したのか忘れてしまっているプロジェクトマネージャー…なんてのは後を絶ちません。

これではプロジェクトが失敗するのも頷けます。

これを防ぐためのひとつの方法は、最近浸透し始めたクラウド型ファイル共有サービスを使ってファイルを参照しやすくかつ編集しやすくしておくことですが、目的・目標計画の方はそれで間に合っても、頻繁に更新する必要がある実行計画の方はExcelなどではやはり効率が上がりません。

特に日々変化の激しいプロジェクトでは、昨日の作業や状況を計画に反映して関係者に共有するのに丸一日かかる、なんてこともあります。こうなるとメンバーが見ている情報は「昨日の最新情報」になってしまうので、計画の鮮度を保つことが難しくなります。プロジェクトマネージャーが忙しくなると、これもやはりすぐに形骸化してしまいます。

そこで実行計画の部分は更新しやすいRedmineやBacklogなどのタスク管理ツールを導入することになりますが、そうすると目的・目標計画と情報が分離してしまうことになるので、今度は情報の二重（多重）管理問題が発生してしまいます。

ITリテラシーや好みの差によって、

　ある人はファイル共有サービスばかりを使い
　ある人はタスク管理ツールしか見ない

というような状況が発生するのです。この問題はツールやプロジェクト関係者が増えれば増えるほど弊害が大きくなります。プロジェクトの計画の鮮度を保つには、これらの問題に対処しなければなりません。

計画鮮度を保つだけではプロジェクトは乗りこなせない

PDCAの「CA」をサポートし、状況をモニタリングするだけをプロジェクトマネジメントというのであれば、計画鮮度を高めるだけで済むのかもしれません。

ですが、プロジェクトマネジメントの神髄は

　実現可能性の高い「計画」力と
　計画を実現するための「コントロール」力

にあります。そのコントロールをしやすくするためにモニタリングが必要というだけであって、コントロール力がそもそも無い人にはモニタリングツールやサービスがあっても豚に真珠でしかありません。

 仮に状況が刻一刻と変化していくなかで、常に最新の情報をキャッチして、その結果、計画鮮度を向上させて続けたとしても、状況が前に進まない限りいつまで経ってもプロジェクトは成功しません。いえそれ以前に成功も失敗も無く、いつまで経っても終わらなくなってしまいます。

本当に大切なのは計画をどんどん更新していくことではなく、想定した通りに進行できるだけの計画と、その計画（皮算用）を実際に実現できるだけのコントロールです。片方だけあっても意味はありません。両方揃って初めてプロジェクトは前に進みます。

コントロールする力…とは、どのような状況に対しても摩擦なく計画通りに進行するための引き出しの多さ、講じる手段の多さと言ってもいいでしょう。もちろん、それをメンバーが実現できなければ意味がありませんので、絵に描いた餅にならないレベルの再現性の高い手段でなければなりません。

そのことだけは忘れないようにしたいですね。