AIでPMO業務を再設計してみよう
本文の状態
日本語全文を表示中
詳細モードで約11分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
LayerX Tech Blog
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
こんにちは、LayerX の Ai Workforce 事業部で PMO をしている kurosawa です！
この記事では PMO 業務に AI を取り入れる際にどの業務から始めるとよいのか、逆にどこを後回しにすべきなのか、そして LayerX で実際にどのような取り組みをしているのかを紹介します。
Ai Workforce は、企業内のデータや文書を活用し、AI エージェントで多様な業務を継続的に自動化するエンタープライズ向けプラットフォームです。
我々の事業部では大手法人のお客様向けに Ai Workforce の導入支援も含めたトータルなソリューションをご提供しております。
PMO とは？
はて、PMO とはなんぞや？と思う方もいらっしゃるかもしれませんので、PMO について少しご説明いたします。
正式名称は「Project Management Office」で、PMBOK*の定義によると「プロジェクトに関連するガバナンスのプロセスを標準化し、資源、方法論、ツール、技法の共有を促進するマネジメント構造」だそうですが、ちょっと何言っているかよくわかりませんよね。
プロジェクトを進めていると、こんなことがよく起こりませんか？
「スケジュールが少しずつ遅れている」
「誰が何を担当しているのか分からない」
「会議は多いのに、なかなか話が前に進まない」
「問題が起きているけれど、誰も全体を把握できていない」
簡単に言うと、こうしたプロジェクトの“ごちゃごちゃ”を整理し、スムーズに進めるために活躍するのが PMO です。
- *Project Management Body of Knowledge、プロジェクトマネジメントに関する世界最大規模の非営利団体であるプロジェクトマネジメント協会（PMI）が発行しているプロジェクトマネジメントに関するガイドライン
プロダクトマネージャーと何が違うの？
プロダクトマネージャーとすこし名前が似ていて若干混同してしまう方もいるかもしれませんが、プロダクトマネージャーは、商品やサービスを「どのようなものにするか」を考える役割です。ユーザーが何を求めているのか、市場にどのような課題があるのかを調べながら、プロダクトの方向性や優先順位を決めていきます。
PMO は「それを実現するための取り組みが、きちんと進んでいるか」を支える人になります。
PMO をアサインすれば解決するの？
PMO が重要なのはなんとなくわかったけど、アサインすれば課題は本当に解決するのか？という疑問も残ります。
それなりの数の PMO をアサインすると当然コストもかかります。実際にプロジェクトにおける管理費は大きな負担になっており、開発費の 10〜20％程度は管理費と言われています。特に金融系のような大規模・高品質が求められる案件では 20% を超えることもあります。
プロジェクトの規模と複雑性が増せば、プロジェクトのルールや情報の可視化、コミュニケーションの円滑化などのプロジェクトの土台づくりがより重要になり、多くの PMO 要員が必要となります。一方で PMO の業務には日々の議事録の作成や進捗管理のための定型的なコミュニケーションなどの膨大な量の事務作業も含まれています。表面的な作業量が大きいからと言って問題を十分に絞り込めていない状態で PMO の数だけ増やしても、新加入したメンバーが目的が不明瞭なまま事務作業をこなすだけ、なんてことになりかねません。そうは言っても業務が回らないよ！という声が聞こえてきそうですが、そんな時こそ・・・。
そんな時こそ AI で改善だ！
こうした事務業務は、生成 AI（Generative AI）で効率化できます。会議内容から議事録や ToDo を作成したり、プロジェクト管理ツールの情報から報告書のドラフトを作ったり、過去の資料から必要な情報を探したりすることが可能です。もちろん、重要な判断や承認まで AI に任せるべきではありません。大切なのは、人を増やす前に、手作業を減らすことです。まずは議事録や報告書作成など、負担の大きい業務から AI を活用することで、PMO コストの削減と、プロジェクト管理のスピード向上を同時に狙えます。
とは言え何から始めれば良いかわからん！と思う方もいらっしゃると思います。
そんな時は、たとえば下記のような手をつけやすいところから始めてみましょう。
- 個人レベルの業務改善
各種ドキュメントや各チームへの督促メールなどの文面のドラフト作成
- LLM（大規模言語モデル）との壁打ちによる多面的なプロジェクトリスクの洗い出し
- 各開発チームの課題や障害に関する情報収集
- 既存の手動プロセスの中に AI による自動化されたステップを一部だけ差し込む
チャットツールやメールなど単一のソースから変更管理や障害管理のチケットを自動起票
- 既存のドキュメントに対する関係者からのフィードバックの自動取り込み
- WBS（作業を洗い出して構造化した管理表）などのドキュメントから報告資料への内容の転記
一方で上記のような基本的なプロセス改善で止まってしまうと、AI による効率化の恩恵も限定的になってしまいます。生成 AI による個人やチームの業務改善になれてきたら、複数のソースから情報収集し高度で複雑なアウトプットを生成するような意思決定支援やリスク分析・管理、予算の策定・管理などの領域に拡大していくのが重要なのかと思います。
逆に後回しにすべきは、そもそもデータが不足している領域での作業、そして機密事項・お客様のデータに深く触れるプロセスです。
少し古い資料ですが、PMI からプロジェクトマネジメント領域における AI 導入に関するレポートが発行されています。
*会員（無料）でないとダウンロードできませんが・・・*
このように効果を確認しながら段階的に導入すれば、リスクを抑えつつ PMO コストの削減を狙えます。大切なのは、いきなり全自動にするのではなく Quick Win から始めて段階的にユースケースを拡大していくことです。重要な点は「AI ツールを入れること」ではなく、今まで手動で行なっていた PMO 業務を AI と分担できるように、PMO 業務そのものを再設計することだと思っています。
事例の紹介
弊社ではありがたいことに柔軟に各種 LLM の利用を認められており、全従業員が気軽に（予算の範囲内であれば！）AI を利用できる環境になっています。特定のモデルやベンダーに縛られず、用途に応じて最適なものを選べるため、「とりあえず試してみる」という心理的なハードルが低く、エンジニアに限らず幅広い職種で AI が利用されています。
さらに社内向けに MCP サーバー（Model Context Protocol：AI と社内システムを安全につなぐ仕組み）が設置されているため、ビジネス職も含めた全メンバーがセキュアなシステム間連携を利用できます。アクセス権限や認証情報を個々人がバラバラに管理することなく、統制の効いた共通基盤の上で各種ツールを横断的に扱える点は、属人化やシャドー IT 化を防ぐうえでも大きな意味を持っています。
そこで PMO 関連業務の具体的な改善事例をいくつかご紹介させていただきます。
チケットの自動起票ツール
各種情報を参照しながら手動で起票していたチケットをチャットツールでの会話内容に基づいて自動起票するツールです。
導入前は基本的にチャット上での会話を要約してチケットにコピペするだけなのですが、これが地味にきつい。テストが佳境に入っているときは不具合のチケットが大量に出てくるのでひたすらチケットを起票するのですが、忙しいときは 1 日中チケットを作成していることもありました。
導入後は、チャットから読み取れる情報を記入した状態のドラフトを作成してくれるので、多少手直しすれば起票作業は一瞬で終わります。体感で 10 分の 1 くらいに感じますがおそらく実際の時間を計測しても大きな乖離はないかと思っています。PMO をしていて非常に助かったツールの一つです。実はこのツールはエンジニアが作成してくれたのですが（偉そうに言っておきながら・・・）、コーディングエージェントを利用すれば非エンジニアでも十分開発できます。
進捗や課題のサマリの自動生成
PMO をしていると毎日、進捗や課題について各担当者にヒアリングしないといけません。このアクション自体は重要ではあるものの、作業自体が煩雑でさらに各担当者の時間をとってしまうという負の側面があります。
担当者に聞く代わりに担当者のチャットの会話履歴や Github 上での行動履歴の情報を収集し、WBS タスクと紐づけることにより個々のタスクの進捗状況や課題の解消状況を把握しようとしました。が、複数のソースから情報を収集し、定性的なサマリを作成するところまでは上手く行きましたが、それをもとに WBS や課題のステータスを更新するには精度が足りませんでした。
最終的には 1 つの汎用的な仕組みだけでは精度が出なかったため、情報ソースの特性（会話ベースか、システムログベースか）に応じてアプローチを分け、ユースケースごとに組み合わせて使う形に落ち着きました。
（まだまだ半手動な部分も多いですが）これまで人手で情報をかき集めていた定例の報告や状況把握といった作業が圧縮され、より本質的な判断や議論に時間を使えるようになってきました。
時には失敗もあるよね・・・
一方で、すべてが順調だったわけではありません・・・。各種システム・ドキュメントから未決事項やタスクを抽出し、インボックスのように仕掛かり中のタスク一覧の作成を試みたところ、抽出されたタスク一覧があまりに長くなりすぎて、かえって認知コストが増大してしまうという失敗もありました。網羅性と一覧性はしばしばトレードオフの関係にあり、ただ情報を集めれば役に立つわけではない、という超当たり前の学びを改めて得ることになりました。（そもそもタスクが多いということなのかもしれませんが・・・）現在は、重要度や緊急度による優先順位付け、重複・ノイズの除去、要約の粒度の調整などを通じて、重要なタスクだけ一覧化できる状態を目指して試行錯誤を続けています。
今後の展望としては、現在の半自動化からさらに一歩進めて、人の確認を挟みつつもエージェントが一連のワークフローを能動的に進める領域を広げていくことです！また、うまくいった施策を個人の工夫に留めず、組織に還元していくことも重要だと思っています。失敗も含めて知見を積み重ねながら、AI を個人の便利ツール止まりにするのではなく、日々の働き方に根づいた当たり前のインフラへと変貌させるには、自分自身が主体的に AI を育てていくという気概が必要なのかなと思っています。
求む！
LayerX では一緒に働いてくれる方を募集しています！
興味のある方はお気軽にカジュアル面談に応募ください。
原文を表示
こんにちは、LayerXのAi Workforce事業部でPMOをしているkurosawaです！
この記事ではPMO業務にAIを取り入れる際にどの業務から始めるとよいのか、逆にどこを後回しにすべきなのか、そしてLayerXで実際にどのような取り組みをしているのかを紹介します。
Ai Workforceは、企業内のデータや文書を活用し、AIエージェントで多様な業務を継続的に自動化するエンタープライズ向けプラットフォームです。
我々の事業部では大手法人のお客様向けにAi Workforceの導入支援も含めたトータルなソリューションをご提供しております。
PMOとは？
はて、PMOとはなんぞや？と思う方もいらっしゃるかもしれませんので、PMOについて少しご説明いたします。
正式名称は「Project Management Office」で、PMBOK*の定義によると「プロジェクトに関連するガバナンスのプロセスを標準化し、資源、方法論、ツール、技法の共有を促進するマネジメント構造」だそうですが、ちょっと何言っているかよくわかりませんよね。
プロジェクトを進めていると、こんなことがよく起こりませんか？
「スケジュールが少しずつ遅れている」
「誰が何を担当しているのか分からない」
「会議は多いのに、なかなか話が前に進まない」
「問題が起きているけれど、誰も全体を把握できていない」
簡単に言うと、こうしたプロジェクトの“ごちゃごちゃ”を整理し、スムーズに進めるために活躍するのがPMOです。
- *Project Management Body of Knowledge、プロジェクトマネジメントに関する世界最大規模の非営利団体であるプロジェクトマネジメント協会（PMI）が発行しているプロジェクトマネジメントに関するガイドライン
プロダクトマネージャーと何が違うの？
プロダクトマネージャーとすこし名前が似ていて若干混同してしまう方もいるかもしれませんが、プロダクトマネージャーは、商品やサービスを「どのようなものにするか」を考える役割です。ユーザーが何を求めているのか、市場にどのような課題があるのかを調べながら、プロダクトの方向性や優先順位を決めていきます。
PMOは「それを実現するための取り組みが、きちんと進んでいるか」を支える人になります。
PMOをアサインすれば解決するの？
PMOが重要なのは何となくわかったけど、アサインすれば課題は本当に解決するのか？という疑問も残ります。
それなりの数のPMOをアサインすると当然コストもかかります。実際にプロジェクトにおける管理費は大きな負担になっており、開発費の10〜20％程度は管理費と言われています。特に金融系のような大規模・高品質が求められる案件では20%を超えることもあります。
プロジェクトの規模と複雑性が増せば、プロジェクトのルールや情報の可視化、コミュニケーションの円滑化などのプロジェクトの土台づくりがより重要になり、多くのPMO要員が必要となります。一方でPMOの業務には日々の議事録の作成や進捗管理のための定型的なコミュニケーションなどの膨大な量の事務作業も含まれています。表面的な作業量が大きいからと言って問題を十分に絞り込めていない状態でPMOの数だけ増やしても、新加入したメンバーが目的が不明瞭なまま事務作業をこなすだけ、なんてことになりかねません。そうは言っても業務が回らないよ！という声が聞こえてきそうですが、そんな時こそ・・・。
そんな時こそAIで改善だ！
こうした事務業務は、生成AIで効率化できます。会議内容から議事録やToDoを作成したり、プロジェクト管理ツールの情報から報告書のドラフトを作ったり、過去の資料から必要な情報を探したりすることが可能です。もちろん、重要な判断や承認までAIに任せるべきではありません。大切なのは、人を増やす前に、手作業を減らすことです。まずは議事録や報告書作成など、負担の大きい業務からAIを活用することで、PMOコストの削減と、プロジェクト管理のスピード向上を同時に狙えます。
とは言え何から始めれば良いかわからん！と思う方もいらっしゃると思います。
そんな時は、たとえば下記のような手をつけやすいところから始めてみましょう。
- 個人レベルの業務改善
各種ドキュメントや各チームへの督促メールなどの文面のドラフト作成
- LLMとの壁打ちによる多面的なプロジェクトリスクの洗い出し
- 各開発チームの課題や障害に関する情報収集
- 既存の手動プロセスの中にAIによる自動化されたステップを一部だけ差し込む
チャットツールやメールなど単一のソースから変更管理や障害管理のチケットを自動起票
- 既存のドキュメントに対する関係者からのフィードバックの自動取り込み
- WBS（作業を洗い出して構造化した管理表）などのドキュメントから報告資料への内容の転記
一方で上記のような基本的なプロセス改善で止まってしまうと、AIによる効率化の恩恵も限定的になってしまいます。生成AIによる個人やチームの業務改善になれてきたら、複数のソースから情報収集し高度で複雑なアウトプットを生成するような意思決定支援やリスク分析・管理、予算の策定・管理などの領域に拡大していくのが重要なのかと思います。
逆に後回しにすべきは、そもそもデータが不足している領域での作業、そして機密事項・お客様のデータに深く触れるプロセスです。
少し古い資料ですが、PMIからプロジェクトマネジメント領域におけるAI導入に関するレポートが発行されています。
*会員（無料）でないとダウンロードできませんが・・・*
このように効果を確認しながら段階的に導入すれば、リスクを抑えつつPMOコストの削減を狙えます。大切なのは、いきなり全自動にするのではなくQuick Winから始めて段階的にユースケースを拡大していくことです。重要な点は「AIツールを入れること」ではなく、今まで手動で行なっていたPMO業務をAIと分担できるように、PMO業務そのものを再設計することだと思っています。
事例の紹介
弊社ではありがたいことに柔軟に各種LLMの利用を認められており、全従業員が気軽に（予算の範囲内であれば！）AIを利用できる環境になっています。特定のモデルやベンダーに縛られず、用途に応じて最適なものを選べるため、「とりあえず試してみる」という心理的なハードルが低く、エンジニアに限らず幅広い職種でAIが利用されています。
さらに社内向けにMCPサーバー（Model Context Protocol：AIと社内システムを安全につなぐ仕組み）が設置されているため、ビジネス職も含めた全メンバーがセキュアなシステム間連携を利用できます。アクセス権限や認証情報を個々人がバラバラに管理することなく、統制の効いた共通基盤の上で各種ツールを横断的に扱える点は、属人化やシャドーIT化を防ぐうえでも大きな意味を持っています。
そこでPMO関連業務の具体的な改善事例をいくつかご紹介させていただきます。
チケットの自動起票ツール
各種情報を参照しながら手動で起票していたチケットをチャットツールでの会話内容に基づいて自動起票するツールです。
導入前は基本的にチャット上での会話を要約してチケットにコピペするだけなのですが、これが地味にきつい。テストが佳境に入っているときは不具合のチケットが大量に出てくるのでひたすらチケットを起票するのですが、忙しいときは1日中チケットを作成していることもありました。
導入後は、チャットから読み取れる情報を記入した状態のドラフトを作成してくれるので、多少手直しすれば起票作業は一瞬で終わります。体感で10分の1くらいに感じますがおそらく実際の時間を計測しても大きな乖離はないかと思っています。PMOをしていて非常に助かったツールの一つです。実はこのツールはエンジニアが作成してくれたのですが（偉そうに言っておきながら・・・）、コーディングエージェントを利用すれば非エンジニアでも十分開発できます。
進捗や課題のサマリの自動生成
PMOをしていると毎日、進捗や課題について各担当者にヒアリングしないといけません。このアクション自体は重要ではあるものの、作業自体が煩雑でさらに各担当者の時間をとってしまうという負の側面があります。
担当者に聞く代わりに担当者のチャットの会話履歴やGithub上での行動履歴の情報を収集し、WBSタスクと紐づけることにより個々のタスクの進捗状況や課題の解消状況を把握しようとしました。が、複数のソースから情報を収集し、定性的なサマリを作成するところまでは上手く行きましたが、それをもとにWBSや課題のステータスを更新するには精度が足りませんでした。
最終的には1つの汎用的な仕組みだけでは精度が出なかったため、情報ソースの特性（会話ベースか、システムログベースか）に応じてアプローチを分け、ユースケースごとに組み合わせて使う形に落ち着きました。
（まだまだ半手動な部分も多いですが）これまで人手で情報をかき集めていた定例の報告や状況把握といった作業が圧縮され、より本質的な判断や議論に時間を使えるようになってきました。
時には失敗もあるよね・・・
一方で、すべてが順調だったわけではありません・・・。各種システム・ドキュメントから未決事項やタスクを抽出し、インボックスのように仕掛かり中のタスク一覧の作成を試みたところ、抽出されたタスク一覧があまりに長くなりすぎて、かえって認知コストが増大してしまうという失敗もありました。網羅性と一覧性はしばしばトレードオフの関係にあり、ただ情報を集めれば役に立つわけではない、という超当たり前の学びを改めて得ることになりました。（そもそもタスクが多いということなのかもしれませんが・・・）現在は、重要度や緊急度による優先順位付け、重複・ノイズの除去、要約の粒度の調整などを通じて、重要なタスクだけ一覧化できる状態を目指して試行錯誤を続けています。
今後の展望としては、現在の半自動化からさらに一歩進めて、人の確認を挟みつつもエージェントが一連のワークフローを能動的に進める領域を広げていくことです！また、うまくいった施策を個人の工夫に留めず、組織に還元していくことも重要だと思っています。失敗も含めて知見を積み重ねながら、AIを個人の便利ツール止まりにするのではなく、日々の働き方に根づいた当たり前のインフラへと変貌させるには、自分自身が主体的にAIを育てていくという気概が必要なのかなと思っています。
求む！
LayerXでは一緒に働いてくれる方を募集しています！
興味のある方はお気軽にカジュアル面談に応募ください。
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み