AIに進捗確認を任せようとしたら、自分が進捗を見るようになった話 [DeNA インフラ SRE]

はじめに

IT基盤部第一グループの大田です。

私はインフラエンジニアとして日々の運用を担当する一方で、ここ一年ほどはチームの長期施策の進捗管理にも関わるようになりました。自分が直接担当する施策について、複数の関係者と調整しながら課題を前に進めることには慣れていましたが、そうではない案件について、PM(プロジェクトマネージャー）として間接的に完了まで見届ける仕事にはまだ不慣れでした。

そこで私は、PM業務、その中でも特に進捗確認の部分をAIで楽にできないかと考えました。複数のプロジェクトが並行して進んでいると、どの施策が順調で、どこにテコ入れのフォローが必要なのかなどを把握し続けることが手間になります。AIが個々のプロジェクトの状況を整理してくれれば、その負担も減るのではないかと考えました。

ただし、この記事は「こうすればPM業務をAIで自動化できる」という成功談ではありません。実際に試して分かったのは、AIにただ目の前の処理を任せるだけでは、仕組み全体が理想通りに動くとは限らないということでした。AIが正しく判断するには、その手前で必要な情報が入力され、最新の状態に更新され続けている必要があります。

この記事では、PM業務の進捗確認を例に、AIで業務を自動化しようとしたときには、AIに任せる処理だけでなく、その前後を含めた業務全体の流れを理解して設計をする必要があるという話をします。

背景: AIに任せたかった進捗確認

当時の私は、インフラチームで進む長期施策をいくつか見ていました。例えば、データベースのバージョンアップ、サーバーOSの更新、セキュリティ対応、新機能に合わせたインフラ構成の変更・追加などです。どれも一日二日で終わるものではなく、複数の施策が並行して進んでいました。

それぞれの施策では、主担当のメンバーが実作業を進めます。PMは、その作業が途中で止まっていないか、予定から大きくずれていないか、進め方が変な方向に向かっていないかを確認します。問題がありそうなら、状況を確認し、必要に応じて計画や進め方を調整します。

このPM業務は、大きく分けると、定義、計画、進捗確認の三つに分けられます。

定義フェーズでは、プロジェクトの背景、ゴール、スコープを整理します。なぜこの施策をやるのか、何を達成したいのか、どこまでを対象にするのかをそろえます。

計画フェーズでは、定義フェーズで決めたゴールを達成するために必要な作業を洗い出します。そのうえで、それらを扱いやすい単位のタスクに分解し、いつまでに何を進めるかを決めます。

進捗確認フェーズでは、計画した内容に沿って実際の作業が進んでいるかを見ます。予定どおりに進んでいれば、そのまま進めます。遅れや詰まりがありそうなら、担当者に確認し、必要に応じて計画や優先度を見直します。

この三つの中で、私が特にAIに任せたかったのは進捗確認でした。定義や計画はプロジェクトの初期に行いますが、進捗確認はプロジェクトが終わるまで続きます。長期施策では、この確認が数か月から一年ほど続くこともあります。

進捗確認の際に活用するのがタスク管理ツールです。私たちの場合はJiraを使っています。Jiraには、各タスクの担当者、期限、ステータス、状況の詳細などが入っています。担当者は日々の作業状況をJiraに更新し、PMはそれをみて、計画どおりに進んでいるかを確認します。

私が AI に任せようと思ったのは、この Jira の確認作業でした。Jira の情報を読み取り、計画と実績のずれを拾い、遅れているタスクや、詰まっていそうな箇所を整理して、それを PM（プロジェクトマネージャー）向けのサマリーレポートにする構想をしました。

したがって AI を入れたあとの流れは、次のような形になります。

AI が私の代わりに Jira を見て、状況を先に整理します。私はそのサマリーを読んで、確認や調整が必要な箇所を把握します。そうすれば、最初から Jira を細かく見に行かなくても、AI がまとめたサマリーから状況をつかめます。

実践：Jira のサマリーレポートを作る試み

そのために、私は Jira の情報をもとに日次レポートを作成する仕組みを用意しました。

仕組みとしては、まずスクリプトが Jira API（Application Programming Interface）からタスク情報を取得し、期限超過、遅延、ブロッカー、担当者ごとのタスク数などを抽出します。その結果を AI が読み、レポートを作成します。

レポート例

※Slack に貼り付ける運用を想定して、レポートはテキスト形式になっていた

PORTFOLIO REPORT: 2026-05-27

━━ SUMMARY ━━━━━━━━━━━━━━━━

• Active: 3 projects (Healthy: 1 / At Risk: 1 / Critical: 1)

全体として、OS（オペレーティングシステム）更新対応に遅れが出ている。特に一部サーバーの移行手順確認が未完了のまま期限が近づいており、対象範囲の絞り込みか実施時期の見直しが必要。

MySQL バージョンアップは検証環境での確認が進んでおり、現時点では順調。

TLS（Transport Layer Security）証明書更新は影響範囲の確認待ちで、一部サービス担当者への確認が必要。

━━ PROJECTS ━━━━━━━━━━━━━━━━

• MySQL 8.0 バージョンアップ ✅ On Track

• Summary

• 検証環境での接続確認と主要クエリの動作確認が完了。

• 本番適用まで 21 日 / 期限まで 45 日 → 余裕あり

• 前回から 3 件完了

• Next Actions

• バッチ処理の動作確認を完了する

• 本番切り替え手順のレビュー日程を決める

• TLS 証明書更新対応 ⚠️ At Risk

• Summary

• 更新対象の洗い出しは完了したが、一部サービスで影響範囲の確認待ち。

• 完了まで 14 日 / 期限まで 18 日 → 余裕は少ない

• 前回から変化なし（サービス担当者確認待ち）

• Issues

• 証明書更新対象の確認待ち (3 日停滞, @山田)

→ 対象サービスの担当者に確認が必要

• Blockers

• 一部サービスの利用状況が未確認

→ 未使用であれば対象から除外、利用中であれば更新手順に追加

• サーバー OS EOL 対応 🔴 Critical

• Summary

• 移行対象サーバーの一部で、移行手順と影響確認が未完了。

• 完了まで 32 日 / 期限まで 10 日 → 22 日不足、対象範囲か期限の見直しが必要

• 前回から 1 件完了

• Issues

• 移行手順レビュー (7 日超過, @田中)

→ 対象サーバーを絞って先にレビューする必要あり

• 影響範囲確認 (5 日超過, @田中)

→ 利用サービスの棚卸しが未完了

• Decision Required

• 今期中に全台対応するか、優先度の高いサーバーに絞るか判断が必要

━━ MEMBER WORKLOAD ━━━━━━━━━━━━━

• @田中：8 tasks (3 overdue, 37.5%) 🔴

• サーバー OS EOL 対応：移行手順レビュー (7 日超過)

• サーバー OS EOL 対応：影響範囲確認 (5 日超過)

• MySQL 8.0 バージョンアップ：本番切り替え手順作成 (2 日超過)

• @山田：5 tasks (1 overdue, 20.0%) ⚠️

• TLS 証明書更新対応：対象サービス確認 (3 日停滞)

• @佐藤：6 tasks (0 overdue, 0%) ✅

このようなレポートがあれば、PM は Jira を最初から細かく見に行かなくても、注意すべきプロジェクトや担当者を把握できます。どのタスクが遅れているのか、どこで判断が必要なのかも一覧できます。

この形だけ見ると、進捗確認の負担はかなり減らせそうに見えました。しかし実際に運用しようとすると、このレポートには大きな前提があることがわかりました。

結果：レポートを運用してどうなったか

見落としていた前提

はじめのうちは、このレポートの仕組みを導入することで、どのプロジェクトが危ないのか、どのタスクを優先して見るべきかがパッと分かりやすくなりました。私はこれを毎日定期実行し、朝に進捗を見る運用にしました。

しかし、1 週間ほど続けてみると、毎日出力されるレポートの内容がほとんど変わっていないことに気づきました。昨日も遅れていると表示されていたタスクが、今日も同じように遅れていると表示され、「あれ？これは昨日担当のメンバーに確認してすでに手を打ったはずなんだけどな..?」という現象が起こりました。話は単純で、Jira の更新が漏れていたのでした。実際には作業が進んでいたり、すでに完了していたりしても、常にそれが Jira のステータスやコメントに反映されているとは限らないのです。

Jira が更新されていなければ、AI は古い情報をきれいに要約するだけです。実際には作業が進んでいても、担当者がステータスを更新していなければ、レポート上ではそのタスクは遅れたまま残ります。期限を過ぎたタスクが並んでいても、それが本当に遅れているのか、単に Jira の更新が漏れているだけなのかは、AI には判断できません。AI がどれだけ自然な文章でまとめることができても、元データが古ければ、古い状況を読みやすく言い換えているだけになります。

つまり、問題は「Jira ← AI」の部分ではなく、その手前の「担当者 → Jira」にありました。あるいは、「Jira を確認する手間」という問題が片付いた後に、ボトルネックが「Jira を更新し続ける」という箇所に移動したとも言えるかもしれません。私は AI が Jira を読んで状況を整理する仕組みを作ることに注力していました。しかしこれが理想的に実現するためには、AI が読む前に、担当者の進捗が Jira へ正しく入力・更新され続けているという前提があったのです。

私自身が生の進捗状況を追うようになった

Jira の情報が古いと AI レポートも使えないと分かってから、私はレポートを見る前に、元になっている Jira や担当者が残す日々の Slack メモの動向をこれまで以上に見たり、あるいは直接細かく担当者と話をすることが増えました。期限を過ぎているタスクがあれば、それが本当に遅れているのか、それとも単に更新されていないだけなのかを担当者に確認します。完了しているならステータスを変えてもらい、まだ作業中なら今の状況を書いてもらう。予定が変わっているなら、期限やコメントも更新してもらう。AI に正しいレポートを出してもらうためには、まず Jira に現実を反映させる必要があったからです。

当初、これはレポート作成をうまく機能させるための下準備でした。つまり、進捗を見る仕事を AI にやってもらうために、その前提となるデータを整えていたつもりでした。

しかし、それをやるうちに、もはやレポートが不要になってしまっていることに気がつきました。どのタスクが止まっているのか。どの担当者に確認が必要なのか。予定と実績にどれくらい差があるのか。そうしたことを、AI レポートを読む前に自分で確認するようにした結果、頭の中にそれぞれのプロジェクトの状況が入ってしまい、もうレポートを読む必要がなくなってしまったのです。

これは、ルンバのような掃除ロボットを家で使うときの話に少し似ています。掃除ロボットに働いてもらうには、ロボットの動線を確保するために、床に物を置かないようにしたり、ケーブルを片づけたりする必要があります。これは本来「ロボットに掃除してもらうための準備」としてやっていることです。しかしその習慣が身につくと、ロボットが掃除する前から、部屋はある程度きれいな状態に保たれるようになります。

今回もそれに近いことが起きていました。私は AI に進捗確認を任せるために、Jira を整え、担当者に確認し、更新漏れを減らそうとしていました。けれど、その準備を続けること自体が、私に進捗を見る習慣を身につけさせていました。AI に任せようとしたことで、逆に自分が進捗を見るようになっていたのです。

振り返り：進捗確認は Jira を見るだけではなかった

この経験から、私は進捗確認という仕事を少し狭く捉えていたことに気づきました。最初の私は、進捗確認を「Jira を見ること」だと思っていました。Jira に並んでいるタスクを見て、期限を過ぎているものや止まっているものを見つける。したがって、それを AI に読ませれば、進捗確認のかなりの部分を任せられると考えていました。

しかし実際には、進捗確認は Jira を見ることではなく、「現実の作業状況を実際に把握すること」そのもので、Jira はそのための手段の一つにすぎません。だからこそ、Jira の情報が古ければ、それをいくら AI に読ませても、現実の進捗を確認したことにはなりません。

Jira を進捗確認の情報源として使うには、そこに現実の状況が反映されている必要があります。タスクが終わっているなら完了になっている。着手が遅れているなら、その理由や見通しが書かれている。ブロックされているなら、その状態が分かるようになっている。そうした状態が保たれていて初めて、Jira は進捗確認に使える情報源になります。

おわりに

何かを AI に任せようとするときは、AI に任せたい処理単体を見るのではなく、その処理を支える情報がどこから来て、誰がどう更新し続けるのかまで合わせて見る必要がある。今回の試みで私はそのことに気づきました。また、当初思ったような自動化は実現できなかった一方で、この試みを通じて、結果的には私は当初不慣れだった進捗確認の習慣を図らずも手に入れることができました。この話が、PM 業務に取り組み始めた方や、広く AI による業務自動化を試みている方にとって、何らかの役立つヒントになれば幸いです。