生きた計画にする条件
変化の激しい現代は、新しいことに常に挑戦していかないと勝ち残ることが厳しい社会となっています。当然ながら、時代の変化にあわせて自らを変化させようとせず、延々と同じことを繰り返しているだけでは、競争相手に負けて「ジリ貧」状態に陥ってしまうことでしょう。
そこで、そうならないためにもたくさんの人がスタートアップを始めたり、多くの企業では新規事業や新規サービスの開発に取り組んでいますが、そうしたプロジェクト的な試みというのは必ずしも成功率は高くありません。
2018年の日経コンピュータの「ＩＴプロジェクト実態調査 2018」では、システム開発プロジェクトの成功率は
52.8%
と言われていますが、
2021年度のＩＴ企業の数は実に43,006社です。もちろん日経コンピュータのアンケートがこのすべてに対して行われているわけではありません。これはあくまで一部の企業に対するアンケートの結果でしかありませんし、アンケートに答えた企業にとってもすべてのプロジェクトを対象にしてはいませんのであくまで目安程度にしかなりません。
実際、プロジェクトの現場ではもっと多くの失敗を見聞きします。
ＩＴ企業の上層部というとどうしても「赤字か、黒字か」でしか成功を判断できません。そういう生き物です。品質やスケジュールなどは報告として受け取ることがあっても、
「で、採算とれんの？」
程度にしか考えません。結果的に採算が取れさえすればプロジェクトの成否にはとんと無頓着です。だから黒字で終了したならすべて「成功」としか見てません。
しかし、いえだからこそ本当の意味での失敗に目を向けることができず、またそうした考え方（報告）を管理職にも要求するために、管理職としてもいずれは感覚がマヒしてしまって致命的な失敗となるまでモニタリングが行き届かなくなってしまうことにいい加減気付いたほうがいいんですけどなかなか難しいようです。
そうしたせいで優秀な人材の流動性が高まっているということも、気づいていないのかもしれませんね。
経営の本質を『ビジネスの連続性を支える活動』とするのであれば、経営者が本当に注視すべきは結果としての収益ではなく、安定して収益を出せるプロセスの構築にこそあるはずです。そう考えたとき、プロジェクトの成功と呼べるか否かはやはりＱＣＤすべての基準を満たすことであるといえるでしょう。
Ｑ：品質（製品やサービス、業務、マネジメント、コミュニケーション等）
Ｃ：コスト
Ｄ：期限
のいずれか１つでも基準を満たせなければ失敗と考えてください（本来ならここに従業員満足度も含めたいところですが…）。
では、その失敗の原因はどこにあるのでしょうか？
プロジェクト経験の多い方は「あるある！」と思わず納得してしまうリストではないでしょうか。確かに失敗するプロジェクトを見ていると、
上からの鶴の一声でやることが決まって、「なんとなく」予算と納期が決まって、具体的なことがなかなか決まらずにヌルっとプロジェクトが始まって、ああでもないこうでもないとやっているうちに時間が過ぎてリソースを食い潰していく。
というケースが非常によくあります。これが結果的に不完全な要件定義やリソースの不足、関係者の協力不足や非現実的な期待などに繋がっています。
逆に、成功率の高いプロジェクトリーダーを見ていると、
「決めなければいけないこと」をできるだけ早めに決めにいく
傾向が強いことがわかります。つまり、プロジェクトの早いうちに「不確実性を早く潰していく」のが成功のカギになるのです。
実際、私もマネージャーをやっていた頃は、
①決まっていることと決まっていないことを整理する
②決まっていることは計画する
③決まっていないことは、いつまでに決めるかを決める（計画する）
④期日までに決まらなかった場合を想定して、仮決めする内容も決めておく
(「決まらなかったら、暫定ですがこれで行きますからね？」と念押ししておく)
⑤でも後で変わることも想定して、決まっていることとは疎結合な進め方にしておく
と、ここまですべて準備します。
計画時点でここまで予測していなければ、いざ不測の事態が起きた時に対応が後手に回ります。常に、すべてが自分の"想定の範囲内"となるようにしておくことが重要なのです。
その際に重要なのはやはり「計画」です。
PMBOK、PMBOKと言葉だけが先行してしまっていますが、おそらくは未だに多くのプロジェクトリーダー、プロジェクトマネージャーが、
「余計な負担が増えただけ」
「なんでこんなことしないといけないんだ」
「そんなもの無くても、"俺は"失敗しない」
と思っている人もいるでしょう。実際、優秀な人がマネジメントをしていれば、無理にPMBOKという仕組みに従う必要もなく成功することもできるでしょう。計画の重要性も、有効性も、その便利さも、理解が伴わなければわかるはずもありません。
ここでは、「計画は必ず立てるものだ」という前提のもとに
「失敗しない計画」は何が違うのか？
を説明しておきたいと思います。これが理解できていないと、ただ闇雲に計画したところで成功はしませんし、それこそ「ただの負担」にしかならないからです。
どんなプロジェクトでも、営業や企画の段階から予算獲得のために計画を立てると思いますが、計画は「理由や背景（why）」を元に、大きく分けて
「何を（what）実現するか」
の目的・目標計画と、それを
「誰が（who）」
「どこで（where）」
「どのように（how）」
「いつまでに（when）実現するか」
の実行計画という二通りのものを作成する必要があります。
多くのプロジェクトでは「何を実現するか」という目的・目標の計画には時間が割かれている一方で、「誰がどこでどのようにいつまでに実現するか」という実行計画が蔑ろになっているために失敗率が上昇しています。
確かに商談や予算承認のために分厚い資料を作って盛大なプレゼンテーションをやると、ひと仕事終わった気持ちになるのは理解できますが、それはスタートラインに立ったに過ぎません。
当たり前の話ですが、
プロジェクトは最後まで求められる品質や予算、納期を守ってキッチリ終わること
が大事です。そこで「やはり計画は大事だ」と事前に精密な実行計画を立てるケースがありますが、そもそもプロジェクトというのは新しいことに挑戦して価値を生み出すという試みなので、ルーチンワークと違って事前に完璧な実行計画を作ることはできません。
たとえば、新宿の雑踏や東京駅の地下街を入り口から目的地まで「どの方向に何歩歩いて何度ターンしてまた別の方向に何歩歩く」などとルートを事前に精密に計画するのはほとんど不可能なのと同じことです。仮に可能だとしても、その事前計画にはかかる労力と時間の多さに反してほとんど意味がないでしょう。
また、「何を実現するか」という目的の部分も、実際のところは始めてみないと分からないことも多かったりします。
たとえば、あるシステムを作るときに手を動かして技術の深掘りをしてみないと実現可能性やかかる工数が判断できなかったり、連携する他のシステムの仕様が固まらないと決められない部分があったりするのは通常のことです。
プロジェクト計画は不確実性が少ないほうが理想的だが、
実施前に詰められる部分というのは限られているのが現実
なのです。プロジェクト計画は目的・目標計画と実行計画は相互に影響し合うもので、プロジェクトの進行に応じて常に精度を高めるためにメンテナンスしていく必要があります。言い換えると、失敗しないプロジェクト計画は常に『鮮度』が保たれているのです。
ここで問題になるのは『計画』と言う情報の"共有"と"更新の手軽さ"です。
ExcelやPowerpointで作成された重厚な資料は更新性とリアルタイム共有の要素が弱く、メールで送ったり社内ファイルサーバーなどに置いても見る人はほとんどおらず、あっという間に形骸化して「死んだ計画」になってしまうプロジェクトは案外多いのではないかと思います。
たとえば、途中参画したプロジェクトで全体像を把握するために社内ファイルサーバーを漁ったら、入り組んだフォルダ構成の奥にプロジェクト計画書を見つけてそれに目を通してみると最終更新日は１年以上前で、さらに更新した人はもう退職していた…なんてことは息の長いプロジェクトではよくあることです。
これを防ぐためのひとつの方法は、最近浸透し始めたクラウド型ファイル共有サービスを使って、ファイルを参照しやすくかつ編集しやすくしておくことですが、目的・目標計画の方はそれで間に合っても、頻繁に更新する必要がある実行計画の方はExcelなどではやはり効率が上がりません。
特に日々変化の激しいプロジェクトでは、昨日の作業や状況を計画に反映して関係者に共有するのに丸一日かかる、なんてこともあります。そうするとメンバーが見ている情報は「昨日の最新情報」になってしまうので、計画の鮮度を保つことが難しくなります。
プロジェクトマネージャーが忙しくなると、これもやはりすぐに形骸化してしまいます。
そこで実行計画の部分は更新しやすいタスク管理ツールを導入することになりますが、そうすると目的・目標計画と情報が分離してしまうことになるので、今度はツールの二重（多重）管理問題が発生してしまいます。
ＩＴリテラシーや好みの差によって、
ある人はファイル共有サービスばかりを使い
ある人はタスク管理ツールしか見ない
というような状況が発生するのです。
この問題はツールやプロジェクト関係者が増えれば増えるほど弊害が大きくなります。
プロジェクトの計画の鮮度を保つには、これらの問題に対処しなければなりません。
Redmine はそう言った問題を解決する１つの回答だと思いますが、初期構築も含めややマネージャーの負担が重く、管理も煩雑化する可能性があります。
クラウド型サービスでは、きちんとしたプロジェクト管理であれば InnoPM やBrabio!。規模が小さく、タスク管理で十分なら Trello や Backlog、Wrike、Jooto などでもいいでしょう。
アジャイル向けには、Jira が有名です。
さすがに、今どき「えー、クラウドって大丈夫なの？」みたいな漠然とした不安を持っている人は少ないと思います（いるとしたらかなりご年配だけ？）。とはいえ、インフラやソフトウェア自身は強固なセキュリティ対策が行われていますが、もちろん
・運用上の課題
・契約上の課題
・法務上の課題
・保守上の課題
などもあるので当然手放しに使っていいものではありませんが、必要に応じて最適化を図り、マネジメントにおいて余計な負担とならないための施策を検討するのは、プロジェクトマネジメントを担うものとして必須の取組みとなります。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。