最強PMOこと、甲州潤が教える！
嫌われる優秀なPMO VS 好かれるダメPMOプロジェクトのスムーズな進行を進め、成功に導くのがPMOの役割ですが、開発現場からは「ただの御用聞き係でしょ？」「進行管理などの事務作業をしている人」と思われていることも......。ではPMOの本来あるべき姿はどのようなものなのでしょうか？ 本連載では、『DX時代の最強PMOになる方法』の著者であり、PMOとして多くのIT利活用や経営相談をこなす甲州潤さんが「嫌われる優秀なPMO」と「好かれるダメPMO」で対比しながら、優秀なPMOの価値観やマインド、行動を伝えていきます！
あなたの現場でも、こんな状況はありませんか？
●実装が予定より遅れて、気付けばスケジュールが破綻寸前
●バグが山積みで、直しても直しても終わらない
●クライアントとの認識がずれて、成果物がなかなかOKにならない
そんなとき、
「残業や増員で乗り切りましょう！」と根性論で対応するのが典型的なダメPMO。一方で、優秀なPMOは最初の一手から違います。
今回は、私が現場で経験してきたトラブル例と、優秀PMOが実践する「数字に基づく原因分析と改善方法」を紹介します。
株式会社office Root（オフィスルート）
代表取締役社長
甲州 潤（こうしゅうじゅん）
国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』（ビジネス教育出版社）
目次
一つ目は、日々のタスク遂行が計画した通りに達成しないケースです。例えば「一日100本実装予定だったのに、終わってみれば80本しか進んでいない」という状況は、現場でよく起こるトラブルです。
ここで考えられる主な原因は二つあります。
・エンジニア起因：設計書の理解不足で手戻りが多発
・設計者起因：設計書自体が煩雑で不明確
スケジュール通りに進まない場合は、まずこの二つの視点から原因を探っていく必要があります。
作ったプログラムが動作しない、あるいは動作はするが期待通りではない。いわゆる「バグ」と呼ばれるトラブルです。
エンジニアによるプログラミングミスの可能性もありますが、「クライアントと開発側の認識がずれている」ケースもあります。
よくあるパターンは主に二つあります。
・仕様変更が開発側に正しく伝わっていない
開発・実装中にクライアントから仕様変更のリクエストが入り、それがうまく開発側まで伝達されなかったことによって、アウトプットに対する両者の期待値がずれてしまっているパターンです。これはシステム的なバグではなく、コミュニケーションエラーです。
・ドキュメント化が不十分で期待値が合わない
上記の要因に連動しますが、クライアントの要求と開発側が実装すべき内容の認識を正しくすり合わせ、その結果は、設計書や仕様書としてドキュメントにまとめておくことは必須です。
スケジュールの遅延とプログラムの不具合（バグ・期待ハズレの動作）が同時に発生するという最悪と言えるパターンです。この場合、エンジニアのスキル不足や、設計不備、クライアントとの認識齟齬など、さまざまな要因が混在したトラブルとなっている可能性が高いので、一つひとつを紐解きながら、丁寧に原因を追求していく必要があります。
当然複数の原因があるので、対策も複数の対策が必要です。
よく、発生した問題に対して、1つの対策しか実施しないケースを見かけますが、改善効果が弱いケースが多いです。複数の対策を実施して一気に解決することが重要です。
前述のような開発・実装時のトラブルが発生した際、ダメPMOは「人的パワーで解決できるだろう」と思い込みがちです。
私の経験を振り返ると、トラブルが起きた際、現場からすぐにアラートが上がることはあまりありません。むしろ「残業して頑張ればできます！」「週末の稼働でカバーできるので、もう少し待ってください」と、トラブルが大した問題ではないかのような報告を受けることの方が多いのです。
ダメPMOは、この言葉を信じて「分かりました、頑張りましょう！」と共感してしまいます。これは定性データ（感覚的な情報）を鵜呑みにしている状態です。
結果として……
・1週目：大丈夫だろうと悠長に構える
・2週目：残業でカバーできると信じ続ける
・3週目：稼働時間や人員追加での解決に頼る
ダメPMOの最大の問題点は、トラブルの原因特定に努める姿勢がないことです。その結果、頑張っても成果が出ないという悪循環に陥ります。
では、優秀なPMOは開発・実装時のトラブル時に、どのような対応をしているのでしょうか。
その答えは「進捗を数字で可視化し、データに基づいて原因を探って」います。
この「業務の定量化と分析力」は、開発・実装管理において最も重要な視点です。そのため、日々の進捗を数字で具体的に報告できる仕組みを整えることが欠かせません。この仕組みをしっかり設計すれば、問題の所在を正確に把握できる定量データが得られるからです。
これにより、トラブルが発生した際にも、「誰が」「どのタスクで」つまずいているのか、原因が個人の得意・不得意にあるのか、それとも設計書自体の煩雑さにあるのか、といった点を容易かつ正確に特定できるようになります。
業務の定量化を行う際に、最低限押さえておきたいポイントは以下の三つです。
ITエンジニア向けスカウト転職サービス
に登録すると続きをお読みいただけます。会員登録後、画面が自動で更新されます。
『DX時代の最強PMOになる方法』
著：甲州潤
▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい
【目次】
第1章 一番稼げるIT人材は誰か
第2章 これからはPMOが1プロジェクトに1人必要
第3章 SEとPMOの仕事は何が違うか
第4章 稼ぐPMOになる７つのステップ
第5章 優秀なPMOとダメなPMOの見抜き方
第6章 PMOが最低限押さえておきたいシステム知識とスキル
第7章 システムは言われた通りに作ってはいけない
第8章 どんな時代でも生き残れる実力をつけよう
>>>詳細はこちら
タグ
