AIをシニアPMに見立てたら、ちょっと一緒に仕事したくない人だった

前回の記事（監視基盤の技術選定の話）で、CloudWatch Synthetics + Jenkinsのハイブリッド構成という方針に落ち着きました。

監視基盤の技術選定、最初の直感が3回ひっくり返った話

外形監視SaaSから始まった技術選定が、TCO試算、PMレビュー、AWSサービスの再調査を経て3回判断が変わった。選定プロセスの記録として、何を調べ、何に気づき、どう判断したかを残す。

Tech

開発ラボ

今回は、その後のプロジェクト計画書の整備作業です。Claude Codeで進めながら、2回、想定外の展開がありました。

地道な整備作業

技術選定が終わって、計画書（project-plan.md）の整理に入りました。

やることはシンプルです。詳細なタスクブレイクダウンが本体に混在していたのを別ファイルに切り出す、TCO比較表を見直す、フェーズ定義の重複を解消する……。要は「読みやすくする」作業です。どれも地味で、でも必要な仕事です。

途中でふと気になって、Claude Codeに聞いてみました。

TCOってなんの略ですか？書いてありましたっけ？

…自分が使った略語の意味を自分で確認しているあたり、なんとも言えない感じですが。「セクション2.6に書いてあります。総保有コスト（TCO）として初出時に説明されています。」ちゃんと書いてありました。

続いて「Phase 1とかPhase 2とかが文章の中で唐突に出てくる」という問題に気づきました。フェーズの定義はセクション4の後半に書いてあるのに、セクション2〜3の段階でもう「Phase 2では〜」という記述が出てくる。初めて読む人には前提がない。

対処はシンプルで、セクション1の末尾にフェーズ構成の一覧を先出しする形で追加しました。「Phase Nが出てきたら上の表に戻れる」という共通言語を置いておくだけです。書いているときは気づきにくい。読み返すと一発でわかる、典型的なやつです。

最初の想定外：「できない」とわかったことで、スッキリした

計画書の表示層まわりを整理していたとき、確認しておきたいことがありました。

目的として「Claudeのステータスページ（status.anthropic.com）のようなページを作りたい」というイメージがあった。外形監視の実行はCloudWatch Syntheticsに決まっていたけれど、そのデータをどう"見せるか"がまだ曖昧なまま計画書に書かれていた。

CloudWatch Dashboardを使う選択肢は検討に上がっていたので、改めて問いを立てました。

Claudeのステータスページのようなダッシュボードを作りたいのですが、CloudWatch Dashboardだけで実現できますか？

返ってきた答えは「できない」でした。

CloudWatch Dashboardは「エンジニアがメトリクスを見て判断するための運用画面」であって、「サービスが正常かどうかを誰でも一目で確認できる公開ページ」ではない。そもそも用途が違うツールでした。

この時点でCloudWatch Dashboardは選択肢から外れ、表示層はJenkinsで独自HTMLを生成するという方向に確定しました。

「できない」とはっきりわかったことで、むしろスッキリしました。曖昧なまま計画書に書いていた部分が固まった瞬間です。

2つ目の想定外：AIが詰めすぎた

計画書がひとまず形になったところで、セルフレビューのつもりでAIにシニアPMの役割を与えて全体を見てもらいました。

返ってきた指摘が8つ。重要度「高」「中」「低」のラベルつきで、一覧表になって出てきました。

体制（誰がやるか、引き継ぎ方針）の記述がない           → 重要度：高
ステータスページの要件（公開範囲・対象者）が未定義      → 重要度：高
SNS → Teams の通知経路が具体化されていない              → 重要度：中
TCO比較にハイブリッド案がない                           → 重要度：中
Phase 0 の Go/No-Go 基準が本文にない                    → 重要度：中
過去の障害事例があれば説得力が増す                      → 重要度：中
「最後に」の語順が不自然                                → 重要度：低
比較表にハイブリッド列がない                            → 重要度：低

読んで、思ったことをそのまま返しました。

あなたの言いたいことはわかるが、まだプロジェクトを進めるかどうかの意思決定を仰ぐ段階なのに、完璧な計画を求め過ぎじゃないですか？

AIは「おっしゃる通りです」と言って、指摘を再分類してきました。今対応すべきものは語順の修正とTCO比較のクロスリファレンス追記だけ。体制、要件定義、通知経路、Go/No-Go基準はPhase 0を進めながら詰めればいい。

対処したのは2点だけでした。

コミットして、完了です。

最後にひとこと、AIに伝えました。

うん、これで十分です。もし、実際の現場であなたが上司だとして、先程のように完璧な計画を要求されたら、ちょっと仕事したくないです。
反省します。計画書のレビューで「あるべき論」を並べるのは簡単ですが、それが現場の行動を止めてしまったら本末転倒です。

「あるべき論」を8点並べること自体は間違っていない。それぞれの指摘は正しい観点を突いています。でもそれを、「Phase 0の着手承認を得ること」が目的の計画書に全部ぶつけてくる。これは、目的と手段がずれています。

ただ、正直思うのです。実際の人間のシニアPMなら、たぶんここまでやってこない。

「これ、承認取りにいく資料だよね？」って文脈を先に確認するか、8点並べる前に「今どのフェーズで何を判断してもらうための計画書なの？」と問い返してくれると思う。状況を読んで、今必要な指摘に絞ってくれる。

AIにはそれがまだできない。「正確さ」と「網羅性」は高いけれど、「このタイミングで何を言うべきか」という状況判断が弱い。だから8点、全部出てくる。

今回は「ちょっと一緒に仕事したくない」で済みましたが、毎回これをやられたら本当に消耗する気がします。そしてそれが実際の上司だったら、と想像すると……まあ、しんどいですよね。

AIとのやりとりで感じる違和感の正体って、こういうところにあるのかもしれません。正しいことを言っているのに、なぜかしんどい。それは「状況を読んでもらえていない」という感覚だったりします。

エンジニアがドキュメントを作るとき、同じ罠にはまることがあります。「完璧なドキュメント」を目指して、今のフェーズに必要十分な情報で止めることができない。AIが外からそれをやってみせてくれたことで、かえってはっきり見えました。

今のフェーズに必要なのは何か。そこを問い直すこと。

今どこにいるか

計画書は完成し、Phase 0の着手承認フェーズに入っています。

Phase 0では、CloudWatch Syntheticsで1サービス分のCanaryを実際に動かします。そこで「Canary 1本の開発にかかる実時間」「JenkinsからCloudWatch APIでデータを取得する実装難度」「SNS → Teamsの通知経路」が明らかになります。

今の工数概算は±40〜50%の精度ですが、Phase 0完了時点で±15〜20%まで絞れる見込みです。

実際に触ってみた記録は、また別の記事にまとめます。

参考：監視基盤とAWS運用を学ぶ

監視設計の考え方やAWS運用の基礎を体系的に学びたい場合は、以下の書籍が参考になります。