writing by Osamu Hirayama *このコラムはiPM naviで配信しています ITパートナーから見積りが提示された場合に、鵜呑みにしてはいけません。 PMならば、チェックポイントを持って確認しましょう。 工数が多すぎる、少なすぎる、それには様々な理由があります。 いずれも始める前からプロジェクトのリスクであることを忘れないでください。
監修：MASA 2004年に大手コンサルファームBにジョイン。大手事業会社をクライアントに持ち、クライアント社内で活用する品質マネジメント基準・開発プロセス基準の策定に従事。また、PMOとしてクライアントのプロジェクト推進及び品質維持に貢献しプロジェクトを成功に導いた。
2016年に大手コンサルファームMにジョイン。
大手エネルギーインフラ会社のガバナンス部門にて、大規模システム開発プロジェクトのマネジメント品質管理に従事。PMOとしてプロジェクト運営における問題点の可視化とプロジェクトマネージャおよび上位層への改善提案によりプロジェクトを成功に導いた。
こんにちは、プロコンサルの平山 理です。
iPM PREMIUMで運営しているオンラインサロンでは、プロコンサルが企業さまのPMへ個別のレクチャーやプロジェクトの後方支援を行なっています。 その活動を通じて、プロジェクトを成功に導くために活用した大手コンサルファームならではの特別なノウハウやメソッドをコラムにしています。 今回のコラムは、社内情報システム部に異動になったばかりのPM未経験者の方からのご相談となります。
Osamu Hirayamaのキャリア 2001年に大手コンサルファームBにジョイン。 ITコンサルタントとして複数のシステム開発プロジェクトのPM・PMOに従事。 2016年よりSIerの取締役として、BtoC向けスマートフォンアプリ開発サービスのビジネススケールに貢献。 2019年にITコンサルファームを設立。大手金融会社の新規事業のIT担当として、脳機能を定期的に測定することにより、認知機能の変化を把握するシステムの開発を担当し自社ビジネスを拡大。
目次
PMからのご相談
■相談者 社内情報システム部に異動になったばかりのPM未経験者 ■相談内容 わたしは、今の会社に新卒で入社して10年勤務しています。 このたび、社内情報システム部に異動になりPMに任命されたPM未経験者です。 ①社内システムが陳腐化したことにより、システムを作り直すことになりました（新たな要件を盛り込んだ新システム） ②弊社では、開発メンバーがいないため長年お付き合いしているITパートナーに作業を依頼することになりました。 ③先日、ITパートナーから見積りの提示があり、上司へ稟議依頼したところ、 ④上司から「この見積りは、君自身が腹に落ちていて、わたしに稟議を依頼しているのか？まさか鵜呑みにしていないだろうな？まずは説明をしてくれ」と少々呆れられたコメントをもらいました。 ⑤わたし自身、システム開発の業務が初めてであることから、見積り内容を確認する術がありません。 ⑥複数のITパートナーへ見積りを依頼していては、プロジェクト開始が遅延してしまいます。 ⑦提示のあった見積りが正しいのか確認する方法はあるでしょうか？ ■相談のポイント ①相談者は、ITプロジェクト業務が初めてである。 ②見積りは、長年付き合いのあるITパートナー1社だけである。 ③複数のITパートナーへ見積り依頼する時間がない。 ④相談者は、見積りの正確さを確認する方法がわからない。
こんな時は、こうしてみれば良いですよ！
このように前提条件を整理しました。
・開発スコープをITパートナーへ提示している。
・ITパートナーの見積りは、故意に不要な工数を盛り込んでいない。
ITプロジェクトの経験が長ければ、見積りの勘所もわかるものです。
しかし、初めてPMをやる人（またはIT未経験者）では、難しいものです。
PM初心者が、確認すべきポイントは限られてしまうものです。 アプローチしていきましょう！ *このアプローチはDX時代に適応したリスキリングしているPMの方にも実用的に使えます。
アプローチ1
社内有識者に工数算出を依頼し、算出された工数の根拠を教えてもらう。
アプローチ2
社内有識者とITパートナーの見積りを付き合わせて、差分を確認する。
※差分は当然であると受け止める。
アプローチ3
大きく乖離がある範囲については、ITパートナーが考慮しているプロジェクトの前提条件、制約条件、想定リスクであると認識して原因の仮説を立てる。
【例えば】
・仕様変更や追加等が発生した場合に備えて、リスク工数を加算している。
・匿名希望さんが、初めてのPM業務であるためITパートナーがプロジェクト推進をリードすることを考慮した工数が加算されている。
アプローチ4
有識者を交えて、ITパートナーとプロジェクトの前提条件、制約条件、想定リスクを確認・共有する。
👍 アプローチ4を上手に行うには
PM初心者の方であれば、プロジェクトにおける前提条件・制約条件をどのように決めていくかを知ることで、アプローチ4を行う手助けになります。こちらのコラムが参考になります↓
アプローチ5
双方でプロジェクトを円滑に進めるための体制を検討する。
まとめ
今回のご相談は、人事異動により情報システム部に配属になり、いきなりPMを任されたという、少々辛い立場の方でした。 このような方にプロジェクトマネージャを担当させるのであれば、部内できちんとサポート体制を準備すべき案件です。 しかし、どの企業も人手不足は否めないので、このような乱暴なケースに、当てはまり方もいるかと思います。 見積りを作るのも難しければ、ましてや他人（今回はITパートナー）の見積もりであれば、尚更ではないでしょうか... もし、あなたが今回の相談者の方と同じ立場であれば、有識者の力を借りて、これらの仮説を考えておくだけでも、ITパートナーの見積もりの意図を理解できると思います。 ・プロジェクトの前提条件や制約条件 ・想定されるリスクの原因 最後まで読んでいただき有難う御座いました。
わたしのコラムで、あなたのお役に立てれば幸いです。
炎上プロジェクトの火消し役が多かったことから、炎上させないマネジメント、問題プロジェクトの解決方法、こんなようなコラムを配信していこうと思ってます。
ぜひ今後とも応援を宜しくお願いします。
*Back Numberはこちらです↓
