writing by えのき *このコラムはiPM naviで配信しています。
経験の浅いプロジェクトマネージャーは、過去の自分の体験をもとにプロジェクトを計画すると思います。 大抵の人は、設計や開発行為などの下流工程からキャリアをスタートしているのでは？ その場合、どうしても受注者側の目線で、プロジェクトの体制を考えてしまいがちです。 しかし、上流工程から請け負うプロジェクトのPMは、目線を切り替えて企業の担当者と充分調整し、ユーザー側の体制構築にまで目を配ってあげることで、プロジェクトの成功率をあげることができるでしょう。 面倒臭いですね・・・ そうなんです！とても面倒臭いんです。 でも・・・プロジェクトマネージャって、そんなもんです。 その面倒臭い調整を行うことで、ユーザーとのコミュニケーション機会も増えユーザーのプロジェクトに対する理解度が上がったり、信頼関係が深まることが、プロジェクトにとって良い結果をもたらすことなんです。
監修：プロコンサル MIRIO 2003年に大手コンサルファームBにジョイン。 PMとして多くの炎上プロジェクトで火消し役として活躍。 2008年に大手事業会社のコンサル企業にジョイン。 同社のグループ会社のシステム全般における企画・提案・マネジメントに従事。 2013年にSIer・製造メーカの代表取締役に就任し、大手コンサルファームや大手事業系DX企業で培ったDXコンサルティングやプロジェクトマネジメンの経験とノウハウを活かして、ICTコンサルティング分野へ進出しビジネスを拡大する。
システムを設計構築するためには、当然それ相応の体制を持って、臨まなければなりませんね。 今回は、そんなプロジェクトの体制について考えていきたいと思います。
あなたは、プログラマーやエンジニアとして数年のキャリアを積んできました。 詳細設計以降の設計や、プログラミングには、充分に実績があり、上司やユーザーからの評価も得てきました。 そんな、あなたは満を持して上流工程からのプロジェクトマネジメントを行うプロジェクトマネージャーになったとしましょう。 RFIやRFP、それらに対するユーザーへのヒアリングも終わりタスクの洗い出しも完了しました。 タスクが見えたので、いよいよ体制を考えていかなければいけません。
エンジニア出身の経験の浅いプロジェクトマネージャーが、プロジェクト体制を考える上で犯しがちなミス
あなたは、計画したタスクを元に、社内（場合によっては協力会社も含む）で、各工程の要求に応じてスキルや必要なリソースの見積もりを行ない、人員のアサインを行ないました。 晴れて、プロジェクトはキックオフして、要件定義工程や基本設計工程を進めていくことになりました・・・ しかし、プロジェクトが進めるにつれ、進捗が思うように進まなくなってきました。 各チームのリーダーに、『なぜ進捗が遅れているのか！』を詳しく聞いてみると・・・ こんな答えがかえってきました。 『ユーザーのタスクが遅れているから』 『要件のヒアリングをしたいが、担当ユーザーの時間が取れないから』 『ユーザーのドキュメントレビューが遅れていて、なかなか前に進まないから』 『ユーザーヒアリングやレビューが完了したものが、ユーザー内で意見が割れてひっくり返されているから』 各チームリーダーからは口々にこのような回答が返ってきました。 このような状況では、プロジェクトのリスケジュールは避けられない状況です。 営業担当やお互いの会社の上層部を巻き込んだトラブルに発展し、炎上してしまいました。。。 いったい何が敗因だったのでしょうか？
システム開発ベンダーや、コンサル会社への丸投げプロジェクトでは絶対に成功しないと言ってもいい
今回のシステム開発は、ユーザー企業と開発を担当する会社の間で請負契約になっています。
ユーザー企業側は、請負契約であることを盾にして、責任をシステム開発企業に求めてきます。
費用を相応に払っているんだから、あとはお任せでシステムが出来上がると考えているようです。
システム開発に関するリテラシーの高い企業であれば、こんなことは起きないだろう、と思うかもしれませんが、意外にこのようなケースは結構ありがちです。 今回は、プロジェクト計画で開発のタスクを過去の経験から洗い出して、開発リソースの見積もりやアサインも、しっかり行なってきました。 しかし、ユーザー企業側の担当者のタスクに対するボリュームや必要な条件を、きちんと明記していませんでした。 このため、ユーザー企業側担当者は、アサインしてはいたものの工数が不足したり、適任ではない担当者がアサインされたりしていたのです。 このようなことが原因で、先ほどのような問題が発生していたのです。
よくありがちなパターン
よくありがちなのは、このような2つのパターンなんですね。 1.ユーザー側担当者は適任者だが、工数が充分に確保されていない ユーザー企業側の担当者は、業務やこれから作るシステムに対しての知見を充分に持っているが、システム開発に掛けられる時間を、充分に確保してもらえていない、というパターンです。 例えば、ユーザー企業側の担当者は、システムの重要性を理解しているが、業務に熟知したエース級のメンバーをアサインしてくれましたが、エース級であるがゆえに、現行業務が、その人に集中しているため充分にシステム開発プロジェクトに携わる時間を使えない状態が、このパターンに該当します。 2.ユーザー側担当者がそもそも適任者ではない ユーザーは,、企業側の担当者が業務に詳しくなく、また決定権もないようなパターンです。 例えば、システム開発に対する重要性の理解度が低いような場合に、このような人がアサインされてしまうことがあります。 これは、非常に多いケースとして覚えておいてくださいね。 システム開発をするといっても、ユーザー企業にとっては通常の業務があります。 そちらを優先することにより、システム開発にはアサインされるメンバーが窓際の社員だったり、新人だったりになってしまうケースです。 このような担当者では、ヒアリングをしても即回答ができなかったり、知見が浅かったりすることによって、正しくない内容でプロジェクトが進んでしまい、プロジェクトの終盤（テスト工程）で、ユーザー要件がひっくり返されることになりがちです。 ２つのパターンが発生するのは、ユーザー企業側のアサインミスだと言えばそれまでです。 しかし、あなたはシステム開発を任されたプロジェクトマネージャーです。 責任論で、ユーザー企業と争っても仕方がありませんよね。 プロジェクトを上手くまとめ上げげなければ、ユーザー満足度も下がってしまいます。 今後の開発や運用、強いては今後の受注が出来るはずだった案件を失ってしまうかもしれません。
ユーザー企業側にはシステム開発プロジェクトの担当として、「適任者」を選任し、「十分なリソース」を確保してもらう
開発プロジェクトの期間中、ユーザー企業側の担当者は、開発担当者からのヒアリングへの対応や各種ドキュメントのレビュー、受け入れテストの実施...etc...山のようにタスクがあります。 その期間、ユーザー企業側の担当者は、通常業務はできないと思ってください。 開発担当者からのヒアリングへの対応や各種ドキュメントのレビュー、受け入れテストの実施など山のようにあることがあります。 そのため、プロジェクト計画段階で、PJ計画書にはユーザーが行うべきタスクの詳細を記載してください。 そして、ユーザーに理解してもらえるように調整してください。 それには、企業側の担当者の具体的な工数を計画段階で明示することです。 そうはいっても計画段階では、難しいことなので、 ヒアリングやレビューに関する会議体がどのくらいなの頻度で実施され、QAに必要とされる見込みの所要期間を記載しておくだけでいいんですね。 これで、ユーザーにとっては、片手間ではプロジェクトはできないことが、かなりイメージしやすくなります。 また、これらはプロジェクトキックオフまでの計画段階で、充分にユーザー企業の経営層や現場とネゴシエーションしておく必要がります。 キックオフでいきなり説明や依頼するのはNGです。 （私はプロジェクト計画書の作成が間に合わず、キックオフの場でこれをやってしまい、その場でobjectionを頂いてしまい何とも言えない空気に。。。。キックオフなのにキックオフできなかったことがあります😭）
如何だったでしょうか？ 上流工程から請け負うプロジェクトのPMは、目線を切り替えてユーザーが企業の担当者と充分調整し、ユーザー側の体制構築にまで目を配ってあげることで、プロジェクトの成功率をあげることができるでしょう。 とても面倒臭いですよね？ しかし、PMであれば、面倒臭い調整を行うことで、ユーザーとのコミュニケーション機会も増えユーザーのプロジェクトに対する理解度が上がったり、信頼関係が深まることが、プロジェクトにとって良い結果をもたらすものです。 今回のコラムが、あなたのプロジェクトマネジメンの参考になれば幸いです。
最後まで読んでくれて有難う御座いました。
Comments