チームにAIを導入したのに、上がってくる資料が的外れ。そんな経験がある上司は、まずツールや部下の視座や素養を疑う前に、自分が部下に渡しているコンテキストを疑ってみてほしいです。
ぼくの結論は「部下のAIアウトプットの品質は、上司が部下に渡すコンテキスト・ハーネス・プロセスの設計品質で決まる」というものです。AIのせいでも、部下のスキルや視座や素養のせいでもありません。
コンテキストがズレると、アウトプットはすべてズレる
「ガーベッジイン・ガーベッジアウト」という言葉があります。ビジネスや情報処理の世界で昔から使われてきた原則で、粗末なインプットからは粗末なアウトプットしか生まれないというものです。AIが広まったいま、この原則はそのまま対AIでも成立します。
構想フェーズなのに「技術選定資料」が上がってくる
例えば、こんな場面があります。まだ方向性すら決まっていない、超初期の構想フェーズにいる。それなのに、技術的なhowの選択肢を比較した資料が上がってきてしまう。
「なぜこんな資料を？」と思うかもしれませんが、部下の立場から見れば、渡されたコンテキストに従って動いただけです。問題は、今がどのフェーズなのかという情報が渡されていなかったことにあります。
コンテキスト管理は、対AIだけの話ではない
AIへの粗末なインプットが粗末なアウトプットを生むように、部下への不正確なコンテキストは、部下のAIから不正確なアウトプットを引き出します。上司がガーベッジを渡せば、部下がどれだけ丁寧にAIを使っても、結果はガーベッジです。
初期提案書が「永遠のコンテキスト」になっていないか
コンテキスト管理の概念が浸透していないとき、現場でよく起きる病理があります。プロジェクト開始時に作った提案書をマークダウン化したもの。それをそのままAIへのコンテキストとして渡し続けることです。
コンテキストは生き物。プロジェクトと一緒に更新され続けるもの
プロジェクトは動いています。クライアントとの議論も進んでいます。「この人は何をどう使うのか」が焦点になる週もあれば、「そもそもこの取り組みの目的は何か」に立ち返る週もあります。フェーズが変われば、立てるべき問いの粒度もまったく変わります。
ところが、AIに渡すコンテキストは初期提案書のまま。部下がAIを使って作る資料は、「プロジェクト開始時点の前提」に基づいたものになります。これがコンテキストの腐敗です。
最新の議事録がAIに渡されなければ、前回の議論が次回に接続されません。お客さんから「また同じ話をしている」「議論が先に進んでいない」と感じられるのは、この腐敗が原因です。
知っているのに、オペレーションに落ちていない
「コンテキストが大事」という概念を知識として持っている人は増えました。でも、それを実務の動作に落とせているかは別の話です。
議事録をAIに取らせる。でも、その議事録を次の会議のインプットとして使うところまでは手が回らない。概念の理解と、オペレーションへの実装の間にある溝を埋めるのも、上司の設計の仕事です。
この「知っているのに動けない」現象がなぜ起きるのか、チーム変革の現場から見えてきた抵抗の構造についてはこちらの記事で詳しく書きました。
上司の仕事と、部下の仕事を分ける
コンテキスト管理には二つの層があります。ここを整理することが、ハーネス設計の起点になります。
上司がやること：全体の現在地掌握と伝達
プロジェクト全体を俯瞰できるのは上司です。今がどのフェーズで、前回から何が変わって、次に何を解決しなければならないか。これを言語化して部下に渡すのは、上司の仕事です。
ぼくは内部会議の冒頭に全体状況をシェアする時間を設けています。発言ベースですが、テキストで記録を残す形にも移行したいと感じています。口頭で渡した文脈は揮発するからです。
部下がやること：末端の詳細をAIに渡し続けること
一方、実際の作業現場で起きていること——末端の会議での議論、クライアントの発言のニュアンス、作業の細かな痕跡——をAIに渡し続けるのは、部下の仕事です。
ここが重要な点です。調べる・資料を作る・まとめる、といった「実務」はAIが代替できる領域になっていきます。最新のコンテキストをAIに渡し、その結果をもとに何を判断するかを考える——これが人間に残る仕事です。実務しか担えない部下がいるとすれば、正直に言えば、その役割はAIに代替されていくべきでしょう。
部下をAIと見立てて、ハーネスを設計する
ここで視点をひっくり返してみます。部下を「優秀なAI」と見立てたとき、上司に求められる役割は何でしょうか。
AIに良いアウトプットを引き出したいなら、良いコンテキストを渡す必要があります。これは部下に対しても同じです。「今どのフェーズにいて、何の解決を目指しているか」を鮮明に定義し、部下が迷わず高精度なアウトプットを出せる動作環境を整える。これがリーダーに求められる新しい設計の形だと思っています。
具体的に、上司が設計・管理すべきものは次の3つです。
- コンテキスト：今どのフェーズで、何の解決を目指しているか
- ハーネス：部下が高精度なアウトプットを出せる動作環境
- プロセス：いつ・どのタイミングで何を渡すかの流れ（更新タイミングはここに含まれる）
この3つが揃っていない状態で「AIを活用しなさい」と言うのは、粗末なプロンプトで良いアウトプットを期待するのと同じです。
ただし、部下の自律性を否定するものではない
「それは部下が自分でコンテキストを取りに行くべきでは？」という反論は理解できます。理想的にはそうあるべきです。
とはいえ、コンテキスト管理のリテラシーはまだ多くの組織で浸透しきっていません。概念として理解していても、実務の動作に落とすところで止まっているケースがほとんどです。
まず上司がハーネスを整えて、その中で動く経験を積ませる。そのプラクティスが平準化されてはじめて、「どう問いを立てるか」という次のレベルの話ができます。ロールモデルとして「こういう仕事の仕方はいいんだ」と思ってもらえる状態をつくることが、もっとも早い道だとぼくは思っています。
この考えが当てはまらないのは、メンバーのリテラシーがすでに高く、自律的にコンテキストを更新できているチームです。そういうチームでは、上司は「問いの立て方の視座」という次の問題に集中できる段階にあります。
まとめ
部下のAIアウトプットの質は、上司が部下に渡すコンテキスト・ハーネス・プロセスの設計品質で決まります。プロジェクト開始時の提案書を渡しっぱなしにしていたら、部下のAIは常に「過去の前提」に向けた資料を作り続けます。
上司がやるべきことは3つです。 コンテキスト（今どのフェーズで何を解決しているか）を言語化して渡す。部下が動くハーネスを設計する。それをいつ・どう更新するかのプロセスを組む。
AIの時代に人間がやるべき仕事は、「実務（手を動かして資料を作ること）」から「判断するための文脈を設計・更新すること」に移っています。この変化をぼく自身がどう受け止め、仕事のやり方を変えてきたかはこちらの記事にも書いています。上司として、まず一つ「コンテキストを渡す設計」を入れてみることをおすすめします。
ここまで読んでいただきありがとうございました。
コメント