DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

＜　前回　｜　目次　｜　次回　＞

今回は「世の中のプロジェクトの典型的な失敗パターン」をご紹介したいと思います。

私自身、これまでに数多くのプロジェクトを見てきましたが、うまく行っていないプロジェクトにはやはり共通したパターンがあります。
これまでのおさらいも兼ねて、皆さんのプロジェクトにも同じようなパターンが見られないか、代表的なパターンと比較しながらチェックしてみてはいかがでしょう。

「プロジェクトのゴール」が曖昧

まずはコレ。
「何のために行うのか」、「何が実現されれば良いのか」が曖昧なままにプロジェクトが進められるパターンです。

このパターンでは、プロジェクトに多くの影響が現れることになります。例えば、ゴールがないと最短ルートが見えずに非効率となりますし、プロジェクトのスコープを追加したいなどという要請があった場合の判断が難しいため、プロジェクト範囲拡大の要因となります。もっと言えば、プロジェクトの成功度合い（求められる価値をプロジェクトで生み出せたのか）を正確に評価することもできませんし、メンバーにとってもプロジェクトで働くことの意味が薄れ、主体性や意欲の低下にも繋がります。

このパターンの厄介なところは、ゴールが明確化されていないことと、プロジェクトが上手くいかないことの因果関係が見えにくいことです。ボディブローによって徐々に蓄積されたダメージが様々な問題の事象となって少しずつ顕在化してくるようなものです。

しかし、逆に考えると、「ゴールさえしっかりしていれば、プロジェクトに強固な軸を作ることができる」、ということでもあります。

あなたは今進めているプロジェクトについて、「生みだすべき価値とその達成条件」を明快・簡潔に説明できますか？
それはつまりプロジェクトの本質を考えることであり、それなりに時間も労力を要することではありますが、後々必ず効いてくるはずなのです。

段取りが大雑把、または検証が不十分

次は、作業項目やスケジュールなどの段取りをあらかじめ十分に考えていないパターンです。
プロジェクトには「やってみないと分からないから、走りながら考える」という部分もあって、最初から100%精密な計画を立てられるわけではありません。
しかし、単に「まだまだ時間はあるし、追々考えればいいや」と言うノリで段取りをしっかりと練り上げないままにプロジェクトを進め、後からペース配分を間違えていることに気付き青ざめることになる、というのが良くある失敗パターンです。
時間は戻せません。プロジェクト終盤になって取り返しがつかなくなって初めて1日の重みを思い知らされる前に、プロジェクトの段取りを可能な限り早い段階で精緻に組み立てておくことが重要です。もし段取りを考えた結果、「期間的に相当難しいな・・・」と青ざめても、それが分かるのが早いほど有効な対策を講じることが可能になるのです。

過小な見積もり

プロジェクトにおいて「作業量」を正確に見積もることは非常に難しいことです。
3日で終わると想定していた作業が実際には5日かかった、などということは頻繁にありますよね。これが積み重なることによって失敗するパターンです。
逆に、見積もりが“過大”というパターンもあり、こちらもプロジェクトの投資対効果が下がって失敗に繋がりますが、やはり見積もりが過小であるパターンの方がかなり多いと思います。

良くあるのが、見積もりの段階において間接的な作業の時間を考慮していないケースです。例えば、屋台のカウンターを設計する作業。単に設計図を書くだけではなく、関係する部品の設計者との調整やイスとのバランスの検討、作業の進捗状況についてプロジェクトマネジャーに報告する、設計した内容を上司に確認して修正するなど、調整や報告、確認などの付随する作業が必要になります。これらを考慮しておくことが過小な見積もりを防ぎます。

また、プロジェクトスポンサー（お金の出し手）からの圧力によって、コストの圧縮を余儀なくされることもあります。この圧力に対して「根性でがんばるぞ！」と言って単純に見積もりを削減して予定コストを下げると、確実に失敗に繋がります（ある程度は頑張れても、限界はありますし長続きはしません）。

かといってその要求を突っぱねることも、余程の理不尽でない限りは決して得策とは言えません。
いろいろ検討の余地はあるはずです。プロジェクトのスコープを縮小する、既存の資産や製品を使う、目標とする品質レベルを見直すなど、交換条件を出しながら「バランスをどこに置くか」の交渉によって調整することが最適な解決方法です。

諦めの境地に入って工夫しない

プロジェクトは多くの制約のもとで実行されるものです。制約とは、プロジェクトからは変更することができない条件のことです。
失敗パターンとして多いのは、この制約（に見えるもの）を疑うことなく、そして工夫もなく諦めの境地で受け入れてしまうことにより、「失敗すべくして失敗する」というものです。

制約として思い込んでいるだけで、実は制約ではなかったという条件も結構あるものなのです。例えば、プロジェクトのスポンサーから○円以上は出せないと言われた時、それが本当に制約になるのか一度考えてみるべきです。
例えば、そのスポンサーにプロジェクトで得られる成果の大きさを説明して、予算を追加することはできませんか？
例えば、プロジェクトの成果を他社にも提供することでスポンサーを増やし、予算を追加することはできませんか？
例えば、年度ごとの分割支払いや成果報酬型など、契約方法の変更によって一時的な予算枠に縛られないプロジェクトにできませんか？

まずは、制約が本当に制約なのか。様々な視点から検討してみましょう。

また、それが制約だとした場合、その制約の中で実現できる進め方・方法を考えなければなりません。先程の見積もりが良い例ですが、制約が多い中で目標を実現する方法を工夫して見つけ出す（または、最後に本当に不可能だと見極めたらプロジェクトをハナからやらない決断を下す）ことがプロジェクトマネジャーの大きな役割です。大切なのは、「発想を柔軟にして諦めずに工夫する」ことです。

希薄なコミュニケーション

この失敗パターンは、コミュニケーションが薄く、メンバー間の協調が十分に行われていないプロジェクトです。

まず、プロジェクトのメンバーがコミュニケーションにおいて主体性を発揮していないケースです。
例えば、メンバーであるAさんがたまたま同じプロジェクトのBさんの作成した成果物に問題があるのではないかと、疑問を持ったとします。このAさんがBさん（または上位のメンバーやプロジェクトマネジャー）に疑問を投げかけて確認するかどうか。ちょっとしたことですが、このことは実に重要です。

不思議に思われる方もいらっしゃるかも知れませんが、プロジェクトが厳しい状況になると、ついつい自分の責任範囲を優先しがちになるものです。メンバーが「忙しいし自分の責任ではないから、まぁいっか。多分確認しなくても大丈夫だろう・・・」というモードになると、問題を早期に見つけることができず、その連続によってついには取り返しのつかない状況に陥ってしまうことが良くあります。

これに対処するためは、まずはプロジェクトマネジャーの雰囲気作りが欠かせません。
当然、プロジェクトマネジャー自身が自分の責任に線引きしていたり、素直でなかったりするとプロジェクト全体がそのような考え方になってしまいます。

プロジェクト全体が有機的に動けるよう、プロジェクトマネジャー自身が率直なコミュニケーションを心掛け、プロジェクトに良い協調関係を作り出すことが求められるのです。

今回はプロジェクトの典型的な失敗パターンを見てきましたが、簡単に言えば「ステークホルダーと会話し、突き詰めて考え、先を見越して工夫すること」ができるかどうか。そのどこかの要素が欠如することによって失敗パターンが生み出されているのではないでしょうか。

次回もお楽しみに！

＜　前回　｜　目次　｜　次回　＞