【部下.md】プロンプトエンジニアリングのマネジメントへの応用
要約（TL;DR）
- 近年、生成AIに明確な指示を与えるための「プロンプトエンジニアリング」が発展している
- 一方、人への指示は「資料まとめて」「いい感じにやって」など、曖昧なものが多い
- このギャップを埋める仕組みが「人間用プロンプト」としての《部下.md》である
- 導入効果：
1. タスクの再現性向上
2. 手戻りの減少
3. 質問対応の削減
4. 自律的な業務遂行（権限委譲）の加速 - 「毎回細かく書けない」という意見には、初期に《部下.md》を定義しておき、以後はテンプレート＋差分運用で対応可能
- 文書化のポイント：PREP構造、入出力の明示、合格基準（DoR／DoD）、連絡方法、エスカレーション基準など
想定読者と目的
- 対象：チームに業務を依頼する立場（マネージャー、リーダー、テックリード、PMなど）
- 目的：依頼者が不在でも業務が意図通りに進むようにするための共通理解の仕組みを作ること
生成AIと人間への指示の差
最近の生成AIは「プロンプト（指示文）」次第で成果が大きく変わります。
人間も同じで、指示が曖昧ならアウトプットもバラつき、確認の往復が発生します。
「レポート作成」の依頼例
AIへの依頼：
目的：障害Aの再発防止策をまとめた1ページ資料
対象読者：非エンジニアの部長
制約条件：600字以内、見出し3つ、結論を冒頭に、図1枚
出力形式：Markdown
評価基準：原因と対策、効果の一貫性、専門用語には注釈を付けること
納期：本日17:00まで
人への依頼：
「先週の障害、資料にまとめておいて」
結果はどうなるでしょうか？
AIへの依頼は前提・制約・評価基準が明示されているので、成果物は一定レベルに収まりやすい。
一方、人への依頼は「誰向け？ どのくらいのボリューム？ 何を重視？」が不明確。
結果として、以下のようなやり取りが発生します。
- 「何文字くらいにすればいいですか？」
- 「図は必要ですか？」
- 「技術的な詳細は書いたほうがいいですか？」
- 「納期はいつですか？」
つまり、依頼が曖昧だと「二度手間・三度手間」が必然的に発生するのです。
人間にこそ「プロンプト」が必要
多くの人はAIに対しては細かく条件を指定するのに、部下やメンバーには「適当にやっておいて」と言ってしまいがちです。
しかし、人間はAIよりも条件解釈に幅があり、バックグラウンドや前提知識も人それぞれ。
だからこそ、人間にこそ業務遂行に必要な前提情報を明示する仕組みが必要なのです。
その解決策が、《部下.md》という「人間用プロンプト」です。
これは単なるマニュアルではなく、依頼をスムーズに進めるための“業務実行の共通言語”になります。
《部下.md》の主な利点
-
再現性の向上
DoR（開始条件）とDoD（完了基準）を明文化することで、アウトプットの品質が安定する。 -
判断基準の共有
優先順位や判断の基準が共有され、自律的な意思決定が可能になる。 -
コミュニケーションコストの削減
連絡手段・報告頻度・返信スピードを事前に明示することで、確認の手間が減る。
《部下.md》のテンプレート例
# 部下.md
## 1. 業務の目的と範囲
- 目的：チームとして重視する価値観（例：スピード重視、顧客影響優先など）
- 対象タスク：週次レポート、機能追加、障害調査、見積もり
- 非対象：経営判断、法務判断など
## 2. 役割と意思決定権限（RACI）
- 管理者の決定権限：業務の優先順位、スコープの確定、外部向けの発信
- 担当者の決定権限：手段の選定、設計の詳細、スコープ内での裁量
- 事前承認が必要な変更：予算超過、スケジュール変更、品質基準の見直し
- RACI区分：タスクごとにR（実行責任）／A（最終責任）／C（要相談）／I（情報共有）を明示
## 3. 連絡プロトコル
- 使用チャネル：Slackの特定チャンネル、Issue、Pull Requestコメント等
- 報告頻度：毎日16:30に進捗・課題・翌日の予定を簡潔に報告（3行以内）
- 返信の目安：通常時30分以内、緊急時10分以内
## 4. タスク着手条件（DoR）
- 必須情報：目的、対象読者、制約条件、入力情報の場所、出力形式、合格基準、期限
## 5. 合格基準（DoD）
* 内容の正確性、形式の一貫性、定められたレビュー観点の網羅
* 手戻りは0.5回以下、期限厳守
## 6. 成果物形式
* 例：レポート＝Markdown／600〜800字／図表1枚／見出し3つ
* 例：分析結果＝Jupyter Notebook、README、CSV等
## 7. 業務別手順例（レシピ）
* レポート作成：TL;DR→本文（結論→理由→具体）→次のアクション
* 障害調査：再現→原因仮説→検証→恒久対応、証拠ログを添付
* 実装タスク：Issue作成→設計→PR→レビュー→デプロイ
## 8. レビューと承認
* PRは200行以内を原則、目的と範囲をタイトルに明記
* チェック項目：正確性、影響範囲、命名、ログ、例外処理、可観測性
* 承認基準：テスト成功、警告なし、説明が十分であること
## 9. リスク対応とエスカレーション
* 即対応が必要なリスク：顧客情報、安全、法的な問題
* 想定外：1時間以上の詰まり、3日以上の遅延は事前報告
* リリース直前の仕様変更：原則24時間前以降は不可（緊急除く）
## 10. 自律レベル（Autonomy Ladder）
* レベル1：事前相談が必須（契約関連、外部との調整など）
* レベル2：方針だけ相談
* レベル3：事後報告のみで対応可（既存ルール内での軽微な調整）
運用方法
- 《部下.md》には基本情報（目的・ルール・形式）を明文化し、都度の業務依頼では「差分」だけを伝える運用とする
- 差分の指示例：
従来：「資料まとめておいて」
変更後：「営業部長向けのレポート、納期は木曜12時。図は不要。」
- 進捗共有は簡潔に（3行ルール）：
\#status 2025-08-26
進捗：〇〇を完了
課題：データ取得に時間がかかっている
明日：検証フェーズに移行予定
想定される反論と対応方針
「毎回そんなに細かく指示できない」
→ 初回に《部下.md》を作成すれば、以後はテンプレート＋差分だけで済む
「状況は毎回異なる」
→ 異なるのはあくまで個別の差分であり、基本ルールは共通化可能
「文書を更新するのが面倒」
→ 毎週1行の更新だけでも効果がある。大幅な見直しは四半期に一度で十分
結論
業務をスムーズに進めるには、「口頭の曖昧な指示」から「再現性のある業務定義」へ移行することが必要です。
AIにプロンプトを丁寧に書くのと同じように、人に対しても 目的・形式・評価基準を文書化して共有すべきです。
《部下.md》は、そのためのシンプルで強力な仕組みです。
Discussion