最強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は開発・実装時のトラブル時に、どのような対応をしているのでしょうか。
その答えは「進捗を数字で可視化し、データに基づいて原因を探って」います。
この「業務の定量化と分析力」は、開発・実装管理において最も重要な視点です。そのため、日々の進捗を数字で具体的に報告できる仕組みを整えることが欠かせません。この仕組みをしっかり設計すれば、問題の所在を正確に把握できる定量データが得られるからです。
これにより、トラブルが発生した際にも、「誰が」「どのタスクで」つまずいているのか、原因が個人の得意・不得意にあるのか、それとも設計書自体の煩雑さにあるのか、といった点を容易かつ正確に特定できるようになります。
業務の定量化を行う際に、最低限押さえておきたいポイントは以下の三つです。
タスクの進捗は「完了／対応中」といった大まかな区分ではなく、細かい項目に分けて数字で報告。
例：一日に何件処理できたか、一つのタスクにかかった作業時間、完了タスク内で発生した不具合件数 など。
例：ステータスは、未着手、作業中、レビュー中、レビュー反映完了、テスト中、テスト完了、完了に分ける
タスクは機能別・担当者別・カテゴリ別に分類し、遅延や不具合が集中する箇所を可視化・特定できるようにする。
Excelのピボットテーブルなどを使いこなし、バグ発生件数や処理速度の傾向を分析できるようにする。
私の場合、各エンジニアの日報や作業ログをすべてプロジェクト管理ツールに集約して管理しています（ツールはExcelでも構いませんし、チケット管理ツール、ソースコード管理ツールなんでも構いません）。
「誰が、何の機能を、どのくらいの工数で処理したか」を日単位で記録。以下はかなりシンプルにした例ですが、日々の業務を定量化したイメージです。
| カテゴリ | 担当者 | 作業件数 | 不具合件数 | 累計作業時間 |
|---|---|---|---|---|
| 検索機能 | Aさん | 15件 | 5件 | 40時間 |
| 検索機能 | Bさん | 20件 | 2件 | 30時間 |
| データ登録機能 | Aさん | 25件 | 1件 | 20時間 |
| データ登録機能 | Cさん | 18件 | 0件 | 22時間 |
このデータを見れば、「Aさんは検索機能の実装は遅いが、データ登録の実装は早い」といった適性が見えてきます。さらに、このデータを週次で集計することで、Aさんの得意分野がより明確になってくるはずです。
このように一人ひとりの業務内容や遂行力を定量データに基づいて分析すれば、プロジェクトの進捗に合わせて、チームの再編成やタスク分配の変更を効果的に行えるようになります。その結果、適材適所に人員を配置でき、チーム全体の生産性を底上げすることにもつながります。
また、これらの変更は数値に裏付けされた判断として説明できるため、全メンバーが高い納得感を持って作業に取り組めるようになります。これも、業務を定量化する大きなメリットです。
さらに、プログラミング作業に限らず、設定反映、レビュー、動作確認といった周辺作業も「仕事の単位」として数値化することをおすすめします。
過去にあった事例では、私が参画する前は、「不具合修正中という一つのステータスで作業集計していた項目」を「不具合調査、プログラム修正、再テスト、とステータスを分けて作業集計する」ようにしました。
すると不具合調査に極端に時間がかかっていることが分かり、担当者ごとに行っていた調査作業を、特定のチームに集約し、プログラム修正、再テストを各担当者に作業割当することで作業工数を削減しつつ、品質を向上させました。
このように業務を細分化し、一つひとつを数字で管理することで、さまざまな角度からの分析が可能になり、現場の実態を正しく把握できるようになります。
では、実際に現場でトラブルが発生した際に、定量データに基づいてどのような流れで原因分析と対策を行うのか。具体的な方法を紹介します。
【例】スケジュールが遅れている場合
以下の手順で定量データを分析し、改善策を講じます。
【原因特定】
エンジニア一人ひとりのタスク遂行率を分析し、スケジュール遅延の具体的な要因を探る。
・一つのタスクあたりの平均作業時間
・一日の作業件数
・不具合発生率
これらのデータから、各エンジニアの能力や得意・不得意分野を見極め、担当タスクが適切かどうか、もしくは個人の能力以上の負担になっていないかを考察。
【改善策】
例えば、チーム内に十人のエンジニアがいて能力や得意分野にばらつきがある場合、それぞれの不得意を補完できるようなペアリングを実施。
例：一人あたり一日１０本のノルマを、ペアで２０本に変更することで、得意分野を分担し合い、ノルマを安定して達成できるようになる。
もしくは、個人の得意・不得意に応じてタスクを再分配し、得意分野に集中できる環境を整える。その結果、一人あたりの作業速度が向上し、不具合発生率も低減することが期待できる。
【原因特定】
バグ報告や質問ログを集計し、一部の設計箇所に遅れやエラーが集中していないか確認。明らかにトラブルが特定箇所に集中している場合は、その部分の設計書の記載が煩雑になっていないかを精査する。
あわせて、クライアントから急な要求変更が発生していないかもチェック。バグの原因が「クライアントと開発側の認識のずれ」なのか、それとも「設計書の理解困難」によるものなのかを見極める。
【改善策】
設計書の不備が明らかな場合は、設計書のリライトや指示内容の明確化を依頼。同時に、クライアントと開発の認識がきちんと一致しているかを、改めて確認。
私が担当するプロジェクトでは、半年〜一年規模の案件の場合、開発・実装管理のための進捗確認ミーティングを週一回の頻度で実施します。そこでPMからスケジュール遅延やエラー発生といったトラブル報告があった場合、前述した「原因特定」と「改善策」をセットで議論するようにしているのです。
PMOとしてトラブルに迅速に対応し、プロジェクトを安定的に進めていくためには、定期的な定量データの分析と振り返りが欠かせません。
優秀PMOの条件はシンプルです。
●業務を徹底的に定量化する
●数字を分析して原因を特定する
●根拠ある改善策を提案する
特に開発・実装の管理で求められるのは、徹底的な業務の定量化と高い分析力。必要な情報を的確に収集し、定量データを多角的に分析できる能力は必須といえます。
そして、分析から得た数字をもとに状況を把握し、冷静に原因を特定しながら、柔軟にリソース配分を最適化していく。定量化と分析を武器に、開発・実装の管理を徹底し、プロジェクト遂行の道筋を立てていく。それこそが、優秀なPMOの姿なのです。
つい根性論に乗っかりたくなる気持ちもわかります。ですが、冷静に状況を把握し、ときには現場の報告を疑い「嫌われ役」になれるかどうかも、実は優秀PMOとダメPMOの境目だと私は感じています。
開発や実装時のトラブル改善に課題をお持ちの方は、ぜひ今回ご紹介したポイントを意識してみていただければと思います。
『DX時代の最強PMOになる方法』
著：甲州潤
▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい
【目次】
第1章 一番稼げるIT人材は誰か
第2章 これからはPMOが1プロジェクトに1人必要
第3章 SEとPMOの仕事は何が違うか
第4章 稼ぐPMOになる７つのステップ
第5章 優秀なPMOとダメなPMOの見抜き方
第6章 PMOが最低限押さえておきたいシステム知識とスキル
第7章 システムは言われた通りに作ってはいけない
第8章 どんな時代でも生き残れる実力をつけよう
>>>詳細はこちら
タグ
