第15章：論理的思考を活かしたリーダーシップ
この章で作れる成果物
この章を読み終えると、次の成果物を作れる状態を目指します。
- team operating brief: チームでAIを使う目的、対象業務、成果物、情報分類、承認範囲を定義する運用メモ。
- AI use boundary card: AIに任せる作業、任せない判断、入力禁止情報、確認者を明確にするカード。
- responsibility / approval matrix: 作成者、レビュー担当、承認者、相談先、最終責任者を成果物別に整理する責任分界表。
- prompt / template asset register: プロンプト、出力テンプレート、評価観点、利用条件、保守担当を管理する資産台帳。
- review workflow board: AI利用成果物のレビュー状態、未解決論点、承認待ち、再利用可否を可視化するボード。
- output quality gate rubric: チーム共通の受け入れ基準、根拠確認、リスク確認、承認条件を定義するルーブリック。
- team decision / escalation memo: チームで判断できること、上位者へ上げること、保留理由を分ける意思決定メモ。
- knowledge reuse backlog: 再利用できる型、改善候補、不要になったテンプレートを管理するバックログ。
- team coaching plan: メンバーのAI協働スキル、レビュー観点、論理的説明力を育成する計画。
- operating metrics review note: 利用量ではなく、手戻り、レビュー指摘、承認遅延、再利用率など運用品質を振り返るメモ。
第14章では、個人の日常業務をメール、チャット、報告、相談、マルチモーダル資料確認として成果物化しました。本章では、その実践をチーム運用へ広げます。リーダーシップを「強い個人の判断」ではなく、チームが同じ基準で依頼し、レビューし、承認し、学習できる運用設計として扱います。
AI利用が個人任せになると、同じ業務でも入力情報、プロンプト、出力形式、レビュー観点、承認者がばらつきます。その結果、品質の揺れ、責任の不明確さ、情報分類の漏れ、再利用できない個人メモが増えます。本章では、テンプレートとプロンプト資産、レビュー、責任分界、学習サイクルを一体で設計します。
本章とAI活用の標準業務フロー
本章は、AI活用の標準業務フロー（1枚） のうち、主に次の工程に対応します。
- 1. タスク定義: team operating brief で、チームとしてAIを使う業務、目的、成果物、対象外を定義する。
- 2. 情報分類: AI use boundary card で、入力可否、匿名化、社内AI限定、AI利用不可を明示する。
- 3. 文脈設計: prompt / template asset register に、使う前提、読み手、業務文脈、禁止事項を残す。
- 4. 出力仕様: 出力テンプレート、review workflow board、output quality gate rubric で成果物の型と合格基準をそろえる。
- 5. 手段選択: AI、手作業、レビュー会、承認フロー、専門部門相談を使い分ける。
- 6. 生成: チームが承認したプロンプトやテンプレートを使い、ドラフト、要約、比較表、論点整理を作る。
- 7. 評価: CARE+、章固有基準、責任分界、根拠確認、リスク確認で成果物を点検する。
- 8. ファクトチェック: 出所、更新日、参照資料、判断根拠、未確認事項をレビュー対象に含める。
- 9. 編集・承認: responsibility / approval matrix に沿って、対外共有、顧客回答、意思決定、人事・法務・セキュリティ論点を人間が承認する。
- 10. ログ化・再利用: prompt / template asset register、knowledge reuse backlog、operating metrics review note に学習内容を残す。
チーム運用では、「AIで作れたか」よりも、「誰が、どの基準で、何を確認し、どこまで責任を持つか」が重要です。
15.1 この章で扱う業務課題
チームでAIを使うときの典型的な問題は、技術不足だけではありません。多くは、運用ルール、責任分界、レビュー観点、資産管理の不足から生じます。
- 個人ごとに使うプロンプトが異なり、成果物の品質が安定しない。
- 便利なテンプレートがチャットや個人メモに埋もれ、更新日や利用条件が分からない。
- AIの出力を誰がレビューし、誰が承認するのか曖昧なまま対外共有してしまう。
- 情報分類をチームで共有しておらず、顧客情報、個人情報、契約条件、画面キャプチャを誤って入力する。
- レビューが表現の好みや経験則に偏り、受け入れ基準や根拠確認が残らない。
- AI活用の成果を「利用回数」だけで見て、手戻り、リスク低減、再利用性を評価しない。
- 失敗事例が個人の注意で終わり、チームのテンプレートやレビュー観点に反映されない。
- リーダーがすべてを承認しようとして、判断の遅延やボトルネックが生じる。
本章では、チームのAI利用を「運用システム」として設計します。対象は、テンプレート、プロンプト、レビュー、責任分界、学習、改善です。
15.2 team operating brief
15.2.1 チーム単位で入口をそろえる
team operating brief は、チームとしてAIをどの業務に、どの条件で使うかを定義する入口メモです。個別のプロンプトより前に、チームの目的、対象業務、成果物、情報分類、承認範囲をそろえます。
【team operating brief】
チーム名:
対象期間:
運用責任者:
対象業務: 調査 / 要約 / 報告 / 提案 / 議事録 / 顧客回答 / 社内FAQ / その他
AI利用の目的:
期待する成果物:
対象外業務:
主な読み手 / 利用者:
扱う情報分類: 公開 / 社内限定 / 顧客情報 / 個人情報 / 契約情報 / 機密 / AI利用不可
利用できるAI環境: 外部AI / 社内AI / 承認済みツール / AI利用不可
承認が必要な成果物:
レビュー担当:
最終承認者:
ログ化先:
再利用できる範囲:
禁止事項:
未確定事項:
次回見直し日:
このメモは、詳細な規程ではありません。チームが日々の判断で迷ったときに戻る「運用の前提」です。社内ポリシー、契約、法務、セキュリティ、個人情報保護に関わる判断は、チーム内の独自解釈で確定せず、所管部門に確認します。
15.2.2 対象外を明示する
AI利用を広げるほど、対象外を明示することが重要です。対象外がない運用は、便利さを理由に判断責任までAIへ寄せてしまいます。
【対象外の例】
- 人事評価、処遇、採用可否など、個人に重大な影響を与える最終判断
- 顧客への正式回答、契約条件、価格条件、法的見解の確定
- 未承認の機密情報、個人情報、認証情報、内部 URL、画面キャプチャの外部AI入力
- 出所不明の情報を根拠にした対外説明
- 社内規程や顧客契約と矛盾するテンプレートの利用
対象外は、AIを使わないという意味だけではありません。AIで下書きや論点整理はできても、最終判断や承認は人間が担う、という責任境界を示します。
15.3 AI use boundary card
15.3.1 AIに任せる範囲と任せない範囲を分ける
AI use boundary card は、チームがAIに任せる作業、任せない判断、入力禁止情報、確認者を明確にするカードです。第9章のリスク・ガバナンスの考え方を、チームの日常運用へ落とし込みます。
【AI use boundary card】
業務名:
AIに任せること:
AIに任せないこと:
入力してよい情報:
入力してはいけない情報:
匿名化 / 抽象化の条件:
利用できる環境:
出力後に人間が確認すること:
承認が必要な場合:
相談先: 法務 / セキュリティ / 情報システム / 人事 / 顧客責任者 / その他
ログ化する内容:
15.3.2 判断例
| 場面 | AIに任せる範囲 | 人間が担う範囲 | 主な確認点 |
|---|---|---|---|
| 社内会議メモ | 論点整理、要約、未決事項の抽出 | 決定事項の確定、参加者への共有可否 | 発言者、機密、決定と保留の区別 |
| 顧客向け提案 | 構成案、FAQ案、表現のたたき台 | 価格、契約条件、導入可否、対外共有承認 | 顧客契約、法務確認、根拠資料 |
| 調査メモ | 公開情報の整理、比較表、要確認点抽出 | 出所の選定、採用可否、意思決定 | 出所、更新日、適用範囲、反証 |
| 採用・評価 | 面談質問案、評価観点の整理 | 採用可否、処遇、個人評価 | 公平性、社内規程、法務・人事確認 |
| 画面キャプチャ確認 | マスク漏れ候補の洗い出し | 共有可否、削除・加工の判断 | 個人名、内部 URL、ID、顧客名 |
この表は汎用例です。実務では、自社の社内規程、契約、地域の法令、顧客要件に従って具体化してください。規制やガイドラインは変わるため、最新の一次情報と社内の所管部門の判断を確認します。
15.4 responsibility / approval matrix
15.4.1 成果物ごとに責任を分ける
AI利用の責任分界は、「AIを使った人が全部見る」では不足します。成果物の種類ごとに、作成者、レビュー担当、承認者、相談先、最終責任者を明確にします。
【responsibility / approval matrix】
成果物:
作成者:
AI利用者:
一次レビュー担当:
専門レビュー担当: 法務 / セキュリティ / 情報システム / 人事 / 経理 / その他
承認者:
最終責任者:
承認が必要な条件:
承認不要で共有できる条件:
エスカレーション条件:
証跡 / ログ化先:
15.4.2 例: 顧客向けFAQの責任分界
| 成果物 | 作成者 | レビュー担当 | 承認者 | 相談先 | ログ化先 |
|---|---|---|---|---|---|
| 社内向けFAQ案 | 担当者 | チームリーダー | チームリーダー | 情報システム | prompt / template asset register |
| 顧客向けFAQドラフト | 担当者 | 営業責任者 | 顧客責任者 | 法務、セキュリティ | review workflow board |
| 価格・契約条件回答 | 営業担当 | 営業責任者 | 権限者 | 法務、経理 | decision / escalation memo |
| 画面キャプチャ付き説明 | 担当者 | 情報システム | 顧客責任者 | セキュリティ | multimodal input inventory |
責任分界は、責任を押し付けるためではなく、迷ったときに止める場所を明確にするためのものです。誰も止める権限を持たない運用は、速く見えても後で手戻りやリスクを増やします。
15.5 prompt / template asset register
15.5.1 プロンプトを個人メモから資産へ変える
便利なプロンプトやテンプレートは、チャット履歴や個人メモに残るだけではチーム資産になりません。prompt / template asset register に、目的、利用条件、入力制約、出力形式、レビュー観点、保守担当を残します。
【prompt / template asset register】
資産 ID:
名称:
種別: プロンプト / 出力テンプレート / 評価ルーブリック / チェックリスト / サンプル
対象業務:
利用目的:
想定読み手:
入力できる情報分類:
入力禁止情報:
前提条件:
プロンプト本文 / テンプレート本文:
期待する出力形式:
受け入れ基準:
利用できるAI環境:
レビュー担当:
承認者:
最終更新日:
保守担当:
変更履歴:
廃止条件:
15.5.2 資産登録時の確認観点
| 観点 | 確認質問 |
|---|---|
| 目的 | 何の成果物を作るための型か。読み手と意思決定点は明確か。 |
| 入力 | 入力してよい情報と禁止情報が分かれているか。匿名化条件はあるか。 |
| 出力 | 出力形式、必須項目、未確認事項の書き方が明確か。 |
| 評価 | CARE+、根拠確認、リスク確認、章固有基準が入っているか。 |
| 承認 | いつ誰がレビューし、どの条件で承認が必要か。 |
| 保守 | 更新日、保守担当、廃止条件、変更履歴があるか。 |
テンプレート資産は、増やすだけでは運用品質は上がりません。使われない資産、古い前提の資産、責任者不明の資産は、むしろ誤用の原因になります。
15.5.3 良い資産名を付ける
資産名は、用途と成果物が分かる名前にします。
悪い例:
- いい感じの提案プロンプト
- 便利メモ
- 顧客向け文面
良い例:
- proposal skeleton for initial customer discovery
- customer FAQ draft with evidence check
- meeting decision log template
- risk review checklist for external sharing
名称が具体的であれば、検索、棚卸し、レビュー、教育がしやすくなります。
15.6 review workflow board
15.6.1 レビュー状態を見える化する
review workflow board は、AI利用成果物の状態を見える化するボードです。レビューは、完成直前に文章を直す作業ではなく、情報分類、根拠、リスク、承認を確認する運用です。
【review workflow board】
案件 / 成果物:
作成者:
使用した資産 ID:
情報分類:
AI利用環境:
現在の状態: 作成中 / 一次レビュー中 / 専門レビュー中 / 承認待ち / 共有済み / 差し戻し / 廃止
未解決論点:
根拠確認の状態:
リスク確認の状態:
承認者:
期限:
次アクション:
ログ化先:
再利用可否:
15.6.2 差し戻しを学習へ変える
差し戻しは、個人の失敗として終わらせず、テンプレートやレビュー観点の改善に変えます。
| 差し戻し理由 | 個別対応 | チーム資産への反映 |
|---|---|---|
| 根拠の出所が不明 | source / evidence extraction table を追記する | テンプレートに出所欄を必須化する |
| 承認者が不明 | responsibility / approval matrix を確認する | 顧客向け成果物の承認条件を更新する |
| 情報分類が誤っている | AI use boundary card を修正する | 入力禁止情報の例を追加する |
| 読み手が動けない | task brief と出力仕様を再定義する | 出力テンプレートに次アクション欄を追加する |
| 法務・セキュリティ論点が未確認 | 専門部門に相談する | エスカレーション条件を更新する |
レビューで見つかった問題は、次に同じ問題を起こさないための資産です。
15.7 output quality gate rubric
15.7.1 合格基準を先に決める
output quality gate rubric は、AI利用成果物を共有または承認する前の合格基準です。チームで共通化することで、レビューのばらつきを減らします。
【output quality gate rubric】
成果物名:
読み手:
利用場面:
合格条件:
1. 目的と読み手が明確である
2. 事実、解釈、仮説、推奨、要確認が分かれている
3. 根拠の出所、更新日、適用範囲が示されている
4. 情報分類とAI入力可否が確認されている
5. 重要なリスク、反証、代替案が記載されている
6. 承認者、期限、次アクションが明確である
7. 再利用可能な部分と固有情報が分かれている
差し戻し条件:
承認者:
証跡:
15.7.2 CARE+をチームレビューへ拡張する
第6章で扱ったCAREは、チーム運用では次のように拡張します。
| 観点 | チームレビューで見ること |
|---|---|
| Correctness | 事実、出所、更新日、数値、固有名詞、引用の正確性 |
| Appropriateness | 読み手、情報分類、権限、社内規程、顧客契約への適合 |
| Relevance | 意思決定点、業務目的、利用場面への関連性 |
| Effectiveness | 読み手が次に動けるか、手戻りを減らせるか |
| Evidence | 根拠、反証、限界、未確認事項の明示 |
| Risk | 法務、セキュリティ、プライバシー、知財、評判、運用負荷 |
| Approval | 誰が確認し、誰が承認し、どこに証跡を残すか |
重要なのは、レビュー観点を成果物ごとに使い分けることです。社内メモ、顧客向け資料、人事関連文書、契約条件回答では、必要な承認とリスク確認が異なります。
15.8 team decision / escalation memo
15.8.1 チームで決めることと上げることを分ける
AI利用の現場では、すぐ使ってよいか、誰に確認すべきかで迷う場面があります。team decision / escalation memo は、チームで判断できること、上位者や専門部門へ上げること、保留理由を分けるメモです。
【team decision / escalation memo】
論点:
背景:
関係する成果物:
情報分類:
チームで判断できる範囲:
エスカレーションが必要な範囲:
選択肢:
推奨案:
根拠:
リスク:
保留事項:
相談先:
承認期限:
決定内容:
ログ化先:
15.8.2 エスカレーション条件の例
【エスカレーション条件】
- 顧客契約、価格、法的見解、セキュリティ例外に関わる
- 個人情報、人事評価、採用、処遇に関わる
- 外部公開、プレス、営業資料、顧客向け正式回答に関わる
- AI出力の根拠が不十分だが、意思決定への影響が大きい
- 社内ポリシーと現場ニーズが衝突している
- 既存テンプレートの利用条件から外れる
エスカレーションは、責任回避ではありません。チームが判断してよい範囲を守り、意思決定の品質と説明責任を確保するための仕組みです。
15.9 knowledge reuse backlog
15.9.1 再利用候補を管理する
AI活用で得た学習は、次の業務で再利用できる形にして初めてチームの力になります。knowledge reuse backlog は、再利用できる型、改善候補、不要になったテンプレートを管理するバックログです。
【knowledge reuse backlog】
項目 ID:
種別: 新規テンプレート / 改善 / 廃止 / 教育 / 注意喚起
発見元: レビュー / 差し戻し / 成功例 / 失敗例 / 問い合わせ / 監査
内容:
対象資産 ID:
期待効果:
リスク:
担当者:
期限:
状態: 未着手 / 対応中 / レビュー中 / 反映済み / 保留 / 廃止
反映先:
次回確認日:
15.9.2 成功例と失敗例を同じ形式で残す
成功例だけを共有すると、再現条件が抜けます。失敗例だけを共有すると、注意喚起で終わります。両方を同じ形式で残します。
| 項目 | 成功例で残すこと | 失敗例で残すこと |
|---|---|---|
| 状況 | どの業務、読み手、制約で使ったか | どの前提が抜けていたか |
| 資産 | 使ったプロンプト、テンプレート、レビュー観点 | 誤用した資産、足りなかった観点 |
| 結果 | 手戻りが減った理由、承認が速くなった理由 | 差し戻し、リスク、承認遅延の原因 |
| 再利用 | どの条件なら再利用できるか | どの条件では使ってはいけないか |
| 改善 | 追加すべき項目 | 修正すべき項目、廃止すべき項目 |
この蓄積が、チーム固有の実務知になります。
15.10 team coaching plan
15.10.1 個人のスキル差を運用で補う
AI協働の品質は、個人の文章力やプロンプト力だけで決まりません。チームの標準、レビュー、育成機会、相談しやすさで大きく変わります。team coaching plan は、メンバーのAI協働スキル、レビュー観点、論理的説明力を育成する計画です。
【team coaching plan】
対象者 / 対象チーム:
育成目的:
現在の課題:
伸ばすスキル: task brief / 情報分類 / プロンプト設計 / 出力評価 / 根拠確認 / レビュー / 承認判断
利用する教材 / 資産:
実務課題:
レビュー方法:
フィードバック頻度:
相談先:
評価観点:
次回見直し日:
15.10.2 育成を点数化だけにしない
育成で避けたいのは、スキルを単純な点数で序列化することです。実務で見るべきなのは、成果物の改善、レビュー観点の習得、判断できないことを適切に相談できることです。
【観察する行動】
- task brief で目的、読み手、判断点、制約を書ける
- 情報分類に迷ったとき、入力せずに確認できる
- AI出力を事実、解釈、仮説、推奨、要確認に分けて読める
- 根拠の出所、更新日、適用範囲を確認できる
- レビュー指摘を個人の防御ではなく、成果物とテンプレートの改善へつなげられる
- 判断権限を越える論点をエスカレーションできる
チームリーダーの役割は、すべての成果物を自分で直すことではありません。メンバーが同じ基準で考え、必要なときに止め、再利用できる形で改善できるようにすることです。
15.11 operating metrics review note
15.11.1 利用回数だけで評価しない
AI活用の運用品質は、利用回数や生成文字数だけでは判断できません。operating metrics review note では、手戻り、レビュー指摘、承認遅延、再利用、リスク検知などを振り返ります。数値はチーム内の改善用であり、単純な比較や個人評価に使う場合は慎重に扱います。
【operating metrics review note】
対象期間:
対象業務:
確認した成果物:
主な利用資産:
良かった点:
手戻りの原因:
レビュー指摘の傾向:
承認が遅れた理由:
リスクを検知できた例:
再利用できた資産:
廃止 / 更新が必要な資産:
次の改善アクション:
担当者:
次回確認日:
15.11.2 見るべき指標の例
| 指標 | 見る理由 | 注意点 |
|---|---|---|
| 差し戻し件数と理由 | テンプレートやレビュー観点の不足を見つける | 件数だけで個人評価しない |
| 承認待ち時間 | 責任分界や承認者設定の詰まりを見つける | 急がせるだけでは品質が下がる |
| 再利用された資産 | 価値のあるテンプレートを見つける | 古い資産の惰性利用に注意する |
| 情報分類の指摘 | 入力前確認の教育ポイントを見つける | 重大リスクは件数より内容を重視する |
| 根拠不備の指摘 | evidence matrix や出所確認の改善につなげる | 出所確認が重すぎる場合は粒度を見直す |
| エスカレーション件数 | 判断境界の曖昧さを見つける | 上げること自体を悪い指標にしない |
指標は、チームを監視するためではなく、運用を改善するために使います。
15.12 よくある失敗
失敗1: プロンプトだけを共有して運用を共有しない
プロンプト本文だけを共有しても、前提、入力禁止情報、出力形式、レビュー観点、承認条件がなければ誤用されます。prompt / template asset register に利用条件を残します。
失敗2: 承認者が曖昧なまま対外共有する
AIが自然な文章を作っても、対外共有の責任は消えません。responsibility / approval matrix で、顧客向け、社外向け、人事・法務・セキュリティ関連の承認条件を明確にします。
失敗3: レビューが文章の好みになる
「分かりやすい」「もっと丁寧に」だけでは、品質が再現しません。output quality gate rubric で、目的、根拠、リスク、承認、次アクションを確認します。
失敗4: 成功テンプレートを無条件に横展開する
ある案件でうまくいったテンプレートが、別の情報分類、読み手、契約条件でも安全とは限りません。利用条件、対象外、廃止条件を明示します。
失敗5: エスカレーションを遅れや弱さと見なす
判断権限を越える論点を早めに上げることは、運用品質を守る行動です。team decision / escalation memo で、上げる条件をあらかじめ決めます。
15.13 人間が最終判断すべき点
チーム運用でAIを使うほど、最後に人間が確認すべき点を明確にします。
- チームとしてAIを使う目的、対象業務、対象外が明確か。
- 情報分類、入力可否、匿名化、AI利用環境を守っているか。
- プロンプトやテンプレートの利用条件、更新日、保守担当が明確か。
- 成果物の作成者、レビュー担当、承認者、最終責任者が明確か。
- AI出力の事実、解釈、仮説、推奨、要確認が分かれているか。
- 根拠、出所、更新日、適用範囲、反証、未確認事項を確認したか。
- 法務、セキュリティ、プライバシー、知財、人事、契約に関わる論点を適切に相談したか。
- レビュー指摘を、個人対応だけでなくチーム資産の改善へ反映したか。
- 指標が監視や単純な序列化ではなく、運用改善に使われているか。
- 再利用する場合、固有情報、顧客情報、個人情報、古い前提を除外しているか。
章末演習
演習15-1：team operating brief を作る
あなたのチームでAIを使う業務を1つ選び、team operating brief を作ってください。対象業務、対象外、情報分類、利用できるAI環境、承認が必要な成果物を明示してください。
演習15-2：AI use boundary card と responsibility / approval matrix を作る
顧客向け資料、社内FAQ、議事録、採用・評価関連メモのいずれかを選び、AI use boundary card と responsibility / approval matrix を作ってください。AIに任せる範囲、人間が承認する範囲、エスカレーション条件を分けてください。
演習15-3：prompt / template asset register を登録する
あなたがよく使うプロンプトまたはテンプレートを1つ選び、prompt / template asset register に登録してください。入力禁止情報、出力形式、受け入れ基準、保守担当、廃止条件を含めてください。
演習15-4：review workflow board と output quality gate rubric を設計する
AIで作った成果物を1つ想定し、review workflow board と output quality gate rubric を作ってください。レビュー状態、未解決論点、根拠確認、承認条件、差し戻し条件を定義してください。
演習15-5：knowledge reuse backlog と operating metrics review note を作る
最近のレビュー指摘、成功例、失敗例を1つ選び、knowledge reuse backlog に登録してください。さらに、operating metrics review note で次回見直す指標と改善アクションを整理してください。
理解度チェック
□ team operating brief で、チームのAI利用目的、対象業務、対象外、承認範囲を定義できる □ AI use boundary card で、AIに任せる作業、任せない判断、入力禁止情報、確認者を整理できる □ responsibility / approval matrix で、作成者、レビュー担当、承認者、最終責任者を成果物別に分けられる □ prompt / template asset register で、プロンプトやテンプレートを利用条件付きのチーム資産として管理できる □ review workflow board で、AI利用成果物の状態、未解決論点、承認待ち、再利用可否を可視化できる □ output quality gate rubric で、根拠、リスク、承認、再利用条件を含む合格基準を作れる □ team decision / escalation memo で、チーム判断と上位者・専門部門への相談を分けられる □ knowledge reuse backlog で、レビュー指摘や成功例をテンプレート改善へつなげられる □ team coaching plan で、AI協働スキルと論理的レビュー力を育成できる □ operating metrics review note で、利用回数ではなく運用品質を振り返れる
章末の要点
- チーム運用では、AIの便利さよりも、目的、情報分類、レビュー、承認、再利用の設計が重要です。
- team operating brief は、チームとしてAIを使う業務、対象外、成果物、承認範囲を定義します。
- AI use boundary card は、AIに任せる作業と人間が担う判断を分けます。
- responsibility / approval matrix は、成果物ごとの作成者、レビュー担当、承認者、最終責任者を明確にします。
- prompt / template asset register は、プロンプトとテンプレートを、利用条件と保守担当付きの資産にします。
- review workflow board と output quality gate rubric は、レビュー状態と合格基準をそろえます。
- team decision / escalation memo は、チーム判断と専門部門・上位者判断を分けます。
- knowledge reuse backlog は、差し戻しや成功例をチーム資産の改善へつなげます。
- team coaching plan と operating metrics review note は、個人の努力ではなく運用として学習を継続するための仕組みです。
次章への橋渡し
第15章では、個人のAI活用をチーム運用へ広げ、テンプレート資産、プロンプト資産、レビュー、責任分界、学習サイクルを扱いました。次の第16章では、これらの運用設計を、KPI、評価、導入計画、変更管理を伴うプロジェクト推進へ接続します。
- 前章: 第14章：日常業務での実践
- 次章: 第16章：プロジェクト管理と問題解決
- リライト方針: 2026年版リライト契約と分割計画