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

　プロジェクトマネジメントという概念がＩＴ現場に普及して久しいですが、まだまだプロジェクトがうまくいかないケースを多く見受けます。

　近年プロジェクトの成功には、超上流工程における企画内容の適正、およびステークホルダーの合意有無が大きく関わると言われています。確かにその面は、大変重要な要素であると思います。しかし、仮に企画がきちんと出来ていたとしても、プロジェクトの実行時におけるマネジメントの不作から、迷走することも多々あります。

　最近、某大手製造系企業におけるシステム統合プロジェクトに関し、マネジメントのご相談をいただいた事例がよくありがちなケースだと思いましたので、今回のブログはそのことをテーマにお伝えします。

　そのプロジェクトは、ある企業の事業統合に伴い発足しました。事業統合の場合、よくあるのが旧部門間の覇権争いです。当該プロジェクトにおいても、その事実はあるようです。ただ、表面的な争いは無く、微妙な空気感ながらも、淡々と仕様は決まっている状況だそうです。

　ところが、プロジェクトにおけるある機能ブロックの部分が遅延し、その対策に苦慮されているプロジェクトの発注者側のＩＳ部門の方から、開発を委託している某ベンダーのプロジェクト立て直しについて相談したいとのことでした。

　当初ご相談のお話をいただいた際に、私が現場で起こっているのではないかと想定したことは次のとおりです。

・旧部門間の覇権争いが理由で、仕様が決まらない。
・体制上の役割分担は一見明確だが、事業統合であるがゆえに船頭が多い。よって最終的な意思決定は下されず、なんとなく決まったような決まらないような状態でプロジェクトは進んでいる。
・システム統合時には、現行システムの有識者が不可欠。しかし、現行システムに詳しい要員は現行システムの運用・保守で忙しく、プロジェクトにアサインできないことから設計が進んでいない。
・現行システムの有識者が不足している中で設計を進めるため、仕様レビューの多くをユーザーに委ねている。しかし、ユーザーも全体像を掴んでいるわけではなく、また現業を行いながらプロジェクトに参画している。よって、システム側から期待されるような仕様レビューを行うことが出来ない。
・事実として起こっているプロジェクトの遅延に対し、ユーザー側は「システム側の力量不足」と捉え、一方でシステム側は「ユーザー側のプロジェクト参画度合いが低いことがボトルネック」と捉えており、お互いに不信感を抱いている。
・そのためプロジェクト全体的に人間関係は良好ではなく、プロジェクトに参画している各担当者のモチベーションは低く、単に仕事をこなすかのごとく取り組んでいる。
・その結果、プロジェクトが進捗しないのは『相手の所為だ！』と心の中で思いながら各人ストレスを貯めているため、プロジェクト内の雰囲気は悪く、モチベーションも低い。

　実際にお客様先を訪問し、ヒアリングしたところ、統合プロジェクトでよくある「旧部門間の覇権争い」による仕様検討が進まないという課題はありませんでした。
　また、現行システムの有識者がプロジェクトに参画していないことによるプロジェクト遅延も、顕著な課題としては表面化していませんでした。実際、十分な人数では無いながらも、現行の業務・システムに精通した有識者をプロジェクトにアサイン出来ているとのことです。

　ということで、ヒアリング前に想定していたことは、プロジェクト遅延のクリティカルな課題ではありませんでした。

　では、何がクリティカルな課題であったのか？

　それは、開発を請負っている某ベンダーのマネジメント力不足にありました。

　某ベンダーは、数百人のメンバーを抱えてプロジェクトを推進しており、複数のチームに分かれてプロジェクトを運営しています。

　通常、メンバーを数百人も抱えている場合は、プロジェクトを横断的にマネジメントするためのプロジェクト内ＰＭＯを設置し、プロジェクトマネジャーと各チーム間のコントロールを行います。コントロールをする際に重要なポイントは、マネジメントと開発のやり方を明確にし、そのやり方に沿って適正に運用出来ているか否かのＰＤＣＡを回せているかです。特にプロジェクトの迷走を防ぐためには、マネジメントとして次の観点が大変重要です。

・リスクの予防策は、効果的にプロジェクトに効いているのか？
・問題の予兆を捉え、その対策が後手後手にならないよう、マネジメントは出来ているのか？
・ステークホルダー間の人間関係が良好になるよう、適時・的確な報連相が行われているのか？
・プロジェクトの目的からずれないよう、マネジメント出来ているのか？　もし、目的に見直しが必要な場合は、プロジェクトの変更管理が出来ているか？

　今回の事例では、某ベンダーのプロジェクトマネジャーは、各チームからの報告の真偽を現場に確認することもなく、「とりまとめ」をするだけのマネジメントを行っているようです。

　そのような状況になっている理由の１つに、数百人もメンバーを抱えているにもかかわらず、マネジャーを補佐するＰＭＯを設置していません。また、各チームにおいても、チームリーダーをマネジメント面で補佐する人は置いていません。
　よって、マネジャーおよび各リーダーは、週次の進捗報告会向けの資料作りに追われています。資料作りのみ行っているゆえに、リスクや問題の予兆を捉えるといった対策が講じられないため、日々課題が顕在化し、発注者側のＩＳ部門やユーザーからクレームが発生。そのため報告書作成とクレーム対応に追われ、毎日ＡＭ２～３時まで働くような状態が恒常化。その結果、体力的に疲弊し、マネジャーや各リーダーのモチベーションが低下という、負のスパイラルに陥っているようです。

　プロジェクトマネジメントには奇策は無く、当たり前のことを当たり前に実行し続けられるか否かに掛かっています。
　よって今回の場合は、某ベンダーのプロジェクトマネジャーや各チームリーダーが、報告書作成のための時間から極力解放されるようにするためのＰＭＯをまず設置し、時間的なゆとりを確保することが先決です。そして捻出出来た時間を使って、リスクの予防策や問題の予兆を捉えるために行動することにより、プロジェクトがマネジメントされている状態に戻すことが重要だと感じ、ご相談いただいたお客様にもお話しました。

　でも、このようなことは今回の事例が特別ではなく、よくあることです。しかし、マネジメント出来ていないことが、プロジェクトの成否に大きく影響することの重要性を改めて認識出来た事例でした。