Tech Memo

1. はじめに：AIにチケットを「丸投げ」する現場の悲劇

AI利用の恩恵で、課題のチケット（Issue）を書くのが随分と楽になり、エラーログや断片的なメモを適当にプロンプトへ投げるだけで、背景から解決策まで見事に構造化された「それっぽい課題チケット」が出来上がる。
しかし、ちょっと立ち止まって考えてみたい。その「完璧に見えるチケット」で、本当に迷いなく動けているだろうか？
最近少しゾッとする光景を目にすることがある。それは、AIにチケット作成を丸投げした結果、 課題のオーナー（起票者）自身が「このチケットの本当のゴール」を自分の言葉で説明できない という事態だ。

AIは優秀ゆえに、与えられたわずかな文脈から「過剰に完璧な解決策」を提示してしまいがちだ。本来なら「まずは0から1の検証だけサクッとやろう」で済むはずの課題が、AIの提案をそのまま鵜呑みにしたせいで「0から10の重厚長大な課題」に変貌してしまう。結果、どこに向かっているのか分からないまま、課題全体が盛大に迷走していく。

「AIに書かせる（丸投げ）」と「AIを使って書く（共創）」の間には大きな違いがあると思う。今回は、そんなAI時代の「課題の解像度」との向き合い方について、SREの現場からノートを綴ってみたい。

2. 解像度とは「情報量」ではなく、「ゴールを握れているか」だ

そもそもSREの領域や、複雑に絡み合ったシステムの運用において、私たちは基本的に「暗闇の中で手探り」をしています。最初から正解が分かっていることなんて、まずあり得ません。
だからこそ、解像度の高いチケットというのは「文字数が多くて、手順が隅々まで書かれているチケット」のことではない。暗闇の中でも、 「何を計測して、どんな状態になればこの課題はクリア（完了）と言えるのか」という成功基準（Success Criteria）を、自分自身が腹の底から理解している状態 のことだ。

この「完了定義（DoD）」を定義するプロセスこそが、解像度を磨く作業そのものだと言えます。本質を捉えていない情報は、どれだけ美しく構造化されていても、現場を混乱させるただの「ノイズ」にしかなりません。
ノイズだらけのチケットと、解像度が高いチケット。この2つを分ける決定的な違いは、課題の担当者が「AIが書いた文章の違和感に気づき、自らの手で完了条件を修正できるか」という一点に尽きる気がします。その中でAIがどれだけ賢くなっても、ゴールの定義という最後の砦まで明け渡してはいけないのです。

3. 思考の逃げ道を塞ぐ「3つの型」

どんな組織やシステムに身を置いても通用する、私が使い分け、磨き続けてきた3つの「型（テンプレート）」がある。テンプレートを埋める作業は、決して面倒な事務作業ではない。「自分は本当に課題の本質を理解しているか？」を自分自身に問いかけるための、大切なプロセスなのだ。

① 計画課題（Epic）：本質を射抜くための「Why/What/How」

これは前任であった元上司から受け継ぎ、今でも自分の「思考のベースライン」として使い続けている、いわば秘伝のタレのような重厚なフォーマットだ。私のチームはカンバン方式を採用しているが、このフォーマットはロードマップに乗るような 「巨大な計画課題（Epic）」にのみ適用している 。 実際のフォーマットの骨組みはこうだ。

# [Epic] タイトル

## 1. Problem Statement / 解決すべき課題（Why）
- なにが問題か
- どこで・いつ・どの程度発生しているか
- 問題による影響はどの程度か

## 2. なにをしたいか / 達成したい状況・KPI（What）
- （ここに記述）

## 3. 必要な機能 / 解決するための仮説（How）
- （ここに記述）

## 4. Success Criteria / 成功基準
- 主要な計測基準（Primary Metric）
- 副次的な基準（Secondary Metric）
- 補完する基準（Consequential Metric）

## 5. スコープ
- 要件 / Future work / スコープ外

この型の良いところは、「表面的な理解では絶対に埋められない」という点にある。いつ、どこで、どの程度発生していて、どれだけの影響があるのかを定量的に書き、「今回はやらないこと（スコープ外）」まで明確に切り分ける。
この過酷なテンプレートを埋め切った先に、チームは強力な武器を手にする。ひとつは「揺るぎない優先度判断」だ。影響範囲とスコープが定量化されているため、「今本当にこれをやるべきか？」の判断がブレない。
もうひとつは「確実な効果計測」だ。リリースして満足するのではなく、事前に定義したSuccess Criteriaを元に「で、実際にメトリクスはどう動いたのか？」を真っ直ぐに振り返ることができる。

② 運用課題（Task）：速度を殺さないための「引き算の解像度」

では、巨大なエピックから分解された日々のタスクや、突発的なトイル（運用作業）も同じように書くのか？それは効率的ではない。局地戦において、重厚なフォーマットは運用サイクルを淀ませるだけの足枷になる。
だからこそ、日々のカンバンで回す運用課題のフォーマットは、極限まで「引き算」をしている。

# [Task] タイトル

- 概要：
- 完了定義：
- 実施内容：
  - [ ] 
- 参考：

なぜここまで削ぎ落としたのか。運用課題において最も優先されるべきは「速度」だからだ。日々のタスクにおいて、立派な背景（Why）を時間をかけてひねり出すのは、それ自体が新たなトイルになってしまう。無駄な項目をすべて削ぎ落とし、たった1点、「完了定義（期待値）」を考えることだけにエネルギーを集中させる。
「要するに、どうなればこのタスクは完了と言えるのか？」を明確に握れていれば、タスクは最速で片付いていく。情報を書き足すことだけが解像度ではない。不必要な情報を削ぎ落とし、絶対にブレてはいけないゴールの1点だけを気にする。

③ 検証課題（PoC/Investigation）：ゴールの「曖昧さ」を殺す型

「計画」とも「運用」とも毛色が違う、第3の厄介な課題がある。それが新しいツールの導入検討や、未知のバグ調査といった「検証（PoC）」だ。 現場でよくある失敗パターンに、「検証と言いながら、気づけば実装までまとめてやろうとしている」というものがある。「とりあえず試してみます」と走り出した結果、どこまでやれば終わりなのかが曖昧になり、調査も実装も中途半端なまま沼にハマるのだ。 この沼を回避するために、検証専用のフォーマットでは以下の項目を強制している。

# [PoC/Investigation] タイトル

## 1. 検証項目と期待値
| 検証内容 | 期待する結果 | 確認方法 |
| :--- | :--- | :--- |
| | | |

## 2. 完了定義（DoD）
- [ ] 全検証項目の確認が完了し、結果が記録されていること
- [ ] 総合判定（合格 / 条件付合格 / 不合格）が決定していること
- [ ] **次のアクション（Next Action）が明確になり、合意が取れていること**

検証の本質は、何かを作ることではない。 「次の意思決定（Goか、No-Goか）を下すための材料を揃えること」 が本質なのだ。だからこそ、手を動かす前に「どういう結果が出たら期待通りとするか」を書き、単にレポートを書いて終わりではなく、「で、次どうするの？」をチームで合意するまでを完了条件として縛り付けている。曖昧さを殺し、決断を下すための型なのだ。

4. 解像度を阻害する「本当の罠」

ここまで3つの型を紹介してきましたが、実は「AIが解像度を下げている」というのは正確ではないと考えています。AIが普及する以前から、チームの中には「そもそも課題をうまく言語化できない」という課題は存在していました。
AI時代になって起きたのは、彼らが書けるようになったことではなく、 AIが適当なプロンプトから「それっぽい立派な文章」を生成することで、課題設定スキルの欠如がごまかせるようになってしまった ということです。

もう一つの罠は、マネジメント側の「親切心」です。リーダーが詳細な課題をきっちり書き上げ、メンバーにタスクを割り振るスタイルは一見効率的ですが、メンバーから「自ら問いを立て、ゴールを定義する」成長の機会を奪い、エンジニアをただの「作業者」に変えてしまいかねません。
自分でログを追い、システムを観察して「何をもって成功とするか」を定義した課題でなければ、本当の当事者意識は宿らないのだと感じています。

5. AIは「良き壁打ち相手」であり、代筆者ではない

決してAIを使うなと言っているわけではありません。むしろ使い倒すべきですが、大切なのは 「AIを代筆者（Ghostwriter）ではなく、良きパートナー（Sparring Partner）に据える」 というスタンスです。

真の共創（壁打ち）とは、AIの出力に対して人間が「本当にそうか？」「この完了定義で抜け漏れはないか？」と隅々まで疑い、徹底的に詰めていくプロセスのことです。AIが生成した「それっぽい答え」を単なる 叩き台 とし、現場の人間だけが気づける 違和感 をぶつけ、容赦のない 検証 を繰り返す。
この緊張感のある対話を経て初めて、チケットは「単なる作業手順書」から「チームを正しい方向へ導く羅針盤」へと昇華するはずです。

AIは有能な壁打ち相手にはなるが、あなたの現場の責任を引き受けてくれる代筆者ではない。

6. おわりに：ポータブルな資産としての「エンジニアの誠実さ」

どのような環境の変化があろうとも、この「3つの型」と「課題と向き合うスタンス」は、どの組織・どのシステムに行っても通用するポータブルな資産になる。
テンプレートを埋めることは、面倒な手続きではない。「自分は本当に課題の本質を理解しているか？」「ゴールをチームに説明できるか？」という、エンジニアとしての誠実さの証明なのだと思う。

AIが秒速で答えを出力してくれる時代だからこそ、人間は「解像度」という名のオーナーシップを、現場の泥臭い実践の中で磨き続けることが重要である。