仕事の質はコンテキストで変わる。それはAI時代でも変わらなかった
目次
自分たちの組織では、AI時代への変化に適応していくことも兼ねて、1年ほど前から、プロジェクトマネージャーという専門職をなくしました。エンジニアを含めた全員が直接顧客と話し、プロジェクトを進行する。プロジェクトマネジメントを特定の役割ではなく、全員がケイパビリティとして持つことを目指しています。
その中で、チームのふりかえりに、こんな声が出るようになりました。
「話すのが得意ではない」「会話の瞬発力がない」
なんとなく、それは違う気がしていました。そして会議に同席する機会が増えるにつれて、その正体が少しずつ分かってきました。
会議のファシリテーターが、アジェンダ通りに会議を進めようとします。アジェンダ通りに進めること自体は、できています。でも、少しでも脇道にそれて議論が始まったり、相手がアジェンダの項目を深掘る質問をしてきた瞬間に、対応できなくなってしまう。相手に何を伝えるか、相手に何を話してもらうかではなく、常に「自分たちが伝えたいことを伝える」だけになっている。
アジェンダに書いてあることしか、その場にないのです。
もちろん、想定外の問いに対しては、問い返す、いったん保留する、場に返すといったファシリテーションの技術もあります。ただ、自分が見た場では、その技術を使う以前に、議論を広げるための判断材料そのものがありませんでした。これは、話す力や瞬発力の問題ではない。足りていないのは、言葉ではなく、その裏に積まれているもののほうです。
いま思えば、これはプロジェクトマネージャーをなくしたときに、自分が想像できていなかったことでもありました。役割をなくしても、その役割が担っていたコンテキストの収集や接続までは、自動的に全員へ分散しないのです。
念のため書いておくと、これを他人事として書くつもりはありません。形だけのアジェンダなら、自分も過去にたくさん作ってきました。
ソースコードでも、同じことが起きる
最近、似た光景をコードでも見ました。
あるプロジェクトで、開発は順調に進んでいるように見えていました。機能はできていくし、デモも動く。形の上では、プロジェクトは進んでいます。
そこに、実運用の経験者が参画して、問いを重ねはじめました。
- 「このURL、直接たたかれたらどうなりますか？」
- 「同じようなイレギュラーパターンの要件が増えていったら、どうなりますか？」
- 「今のUIの流れで、ユーザーは待ってくれますか？」
- 「障害が起きたとき、どうやって原因を追いますか？」
答えに詰まる場面が、続きました。
ハッピーパスと、そのまわりにある一般的な異常系は、ちゃんと作られていました。埋まっていなかったのは、その外側です。 想定外の使い方をする人、要件の増え方、画面の前で待つユーザー、障害対応をする未来の自分たち。
この問いを並べてみると、実運用経験者が見ているものの正体が分かります。システムの保守運用の視点だけではないのです。つくった機能が、その会社のどんな業務の中で、誰に、どう使われるのかまで想像している。 コンテキストは、システムの中だけに積むものではありませんでした。
そして、この問いは不足を暴くだけではありませんでした。たとえば「今のUIの流れで、ユーザーは待ってくれますか？」には、その場で誰も答えられませんでした。そこで顧客に確認してみると、意外な答えが返ってきました。待つこと自体は、問題ではない。それよりも、迷わないことと、結果の精度が高いことのほうが大事だと。この一往復で、「いま待っている」ことが伝わるUIに変わり、処理の流れも変わりました。問いに答えようとした動きが、チームに新しいコンテキストを連れてきたのです。問いは、コンテキストの不足を確かめるだけでなく、新しいコンテキストを作る。
アジェンダ通りにしか進められない会議と、ハッピーパスのまわりしか埋まっていないコード。この2つは、同じ問題の別のあらわれだと思っています。目の前の問題解決以上の内容が、そこに込められていないのです。
コンテキストとは何か
AI時代になって、「コンテキスト」という言葉を毎日のように使うようになりました。この記事でもこの言葉を借りて、アウトプットが生まれるまでに積まれたものを指すことにします。なぜ作るのか。どんな制約があるのか。何を検討して、何を捨てたのか。ここまでどんな経緯があって、この先どうしたいのか。
コンテキストは、人によって見ている範囲と時間軸が違います。自分のタスクだけを見ている人と、チームやプロダクト、その先の顧客まで見ている人。今日の実装だけを見ている人と、これまでの経緯や、この先の運用・変化まで見ている人。
先ほどの実運用経験者の問いが鋭かったのは、この範囲と時間軸が広かったからです。経験そのものをコンテキストと呼びたいわけではありません。経験が増やすのは、どの情報を集め、どの「こういう場合は？」を立てるべきかという視点のほうです。その視点があるから、目の前のプロジェクトから短時間で厚いコンテキストを積める。
この差は、仕事の質の差の一因として、これまでも暗黙的に存在していました。それがAI時代に入り、プロンプトをはじめとするAIへのインプットとして、言語化され始めた。コンテキストという言葉が毎日使われるようになったのは、そういうことなのだと思います。
同じ形でも、積まれているものが違う
アウトプットには、同じ形をしていても2種類あります。
最短距離で積み上げただけのアウトプットと、思考と試行の量を積み上げ、その量が質に転化したアウトプットです。
ここでいう「量」は、資料の厚さやトークンの多さではありません。目的、制約、例外、時間軸について、どれだけの分岐をたどったかです。検討して捨てた案の数、置いた仮説の数、「こういう場合は？」と自問した回数。それらはアウトプットの表面には現れませんが、確実にそこに積まれています。
そして、AIによって劇的に安くなったのは、主に前者です。AIでゼロに近づいたのは、初稿を形にするコスト。検証や判断もAIに手伝ってもらえるようにはなりましたが、何が正しいかを決めて、その結果に責任を負うコストは、人の側に残っています。
だからこそ、差が際立つようになったのだと思います。
形は、誰でも一瞬で作れる。積まれたコンテキストの差が、アウトカムの差になって残る。
AIへの渡し方に、積んできたものが現れる
具体的な例を出します。AIに会議のアジェンダを作らせる場面です。
薄い渡し方は、こうです。アジェンダのテンプレートと前回のアジェンダを渡して、「今回の会議のアジェンダを書いて」。
これで、それらしいアジェンダは出てきます。形は完璧です。でも、このプロンプトには、プロジェクトがいまどんな状況なのかも、参加者がどんな人たちなのかも、ここまでにどんな議論や意思決定がなされてきたのかも、今回の会議でどこにたどり着きたいのかも、何もありません。
AIは、それを推測するのみです。
厚い渡し方は、それらのコンテキストを渡した上で生成し、出てきたものにさらに壁打ちを重ねて洗練させます。出てくるアジェンダは、どちらも同じ「形」をしています。でも、会議が始まれば差は隠せません。脇道の質問が来た瞬間に、答えられなくなる。冒頭の光景です。
最近、この薄い渡し方をよく見かけるようになりました。賢いモデルが推論でそれらしく埋めてくれるので、形の上では成立してしまうからです。
もうひとつ、AIに渡そうと言葉にする過程には、副産物があります。言葉に詰まった瞬間、自分の理解の穴が見えるのです。言語化できないことと、持っていないことは同じではありません。それでも、渡せなかった分は反映されにくく、AIの推測に置き換わっていきます。
作者が適当にプロンプトを入れて、賢いモデルがすごい推論をしてポンッと出てきたアウトプットなのか。作者に蓄積されたコンテキストをもとに生成され、壁打ちで洗練されたアウトプットなのか。
見た目では、区別がつきません。
形としてのアウトプットは、ゴールではない
積まれていないものは、遅かれ早かれ露呈します。会議なら、脇道の質問ひとつで。コードなら、実運用の問いや、変化や負荷が来たときに。
ただし、露呈するまで待てばよい、という話ではありません。セキュリティや障害のように、壊れてからでは遅いものがあります。レビューやテスト、そして実運用経験者のあの問いは、露呈を安全なうちに前倒しするための仕組みです。
つまり、会議でもソフトウェアでも、形としてのアウトプットはゴールにならないのです。アジェンダを作ることがゴールなら、薄い渡し方で十分です。でも、会議で相手と合意に至ることがゴールなら、足りない。コードが動くことがゴールなら十分です。でも、運用に耐えて価値を出し続けることがゴールなら、足りない。
アウトプットの形が簡単に手に入る時代になったからこそ、ゴールはその先にあるという当たり前のことが、むしろ見えやすくなったと思っています。
コンテキストは、どう積まれるのか
では、どう積んでいけばいいのか。
先に断っておくと、コンテキストを積むとは、着手前に考え尽くすことではありません。複雑な仕事には、実際に動かしてはじめて得られるコンテキストがあります。小さく試して、現実から返ってきた情報で前提を更新する。そこまで含めて「積む」です。
もうひとつ、うまくいかなかった方法も書いておきます。コンテキストが不十分なアウトプットに、フィードバックをする。指摘した部分は、直ります。でも、同じ構造をした別の部分は直っていない。そして次のアウトプットでも、また似たようなフィードバックを繰り返すことになる。これを何度も経験しました。心当たりのある人も多いのではないでしょうか。レビューする側にも、される側にも。
考えてみれば当然です。アウトプットは、結果にすぎないからです。 アウトプットへの修正指示は、結果を直せても、過程には届きません。理由や前提を問い直すレビューであれば、過程への入口にはなります。ただ、少なくとも自分が試してきたなかでは、判断が生まれる瞬間ごと見えるペアワークやモブワークが、いちばん解像度の高い方法でした。
一緒に働いていると、同じ仕事でも、アウトプットへのたどり着き方や、AIへのコンテキストの渡し方が、人によってまるで違うことが見えます。前提を確認してから始める人、いきなり作り始める人。捨てた案を言葉にする人、しない人。AIに経緯ごと渡す人、指示だけ渡す人。一人で仕事をしているとアウトプットしか見えませんが、一緒に働くと過程が見える。そして、複数の視点がぶつかることで、コンテキストは移るだけでなく、新しく生まれもします。このあたりは AI時代のモブプログラミングFAQ にも書いたので、興味があればどうぞ。
冒頭のふりかえりの声に戻ります。必要なのは、話すのが得意になることではないと思っています。会話の瞬発力に見えるものの正体の多くは、その場で考える速さではなく、事前に積まれているコンテキストの量だからです。
脇道の質問に答えられる人は、頭の回転が速いのではありません。その脇道を、すでに一度歩いたことがあるのです。 初めての脇道に出たら、その場で少し歩いてみればいい。その歩き方もまた、これまで積んできたものの中にあります。
おわりに
AIの「コンテキスト」という言葉は、新しい概念ではなく、仕事の本質の再発見だったのだと思います。積まれたものの差は、AIが登場する前からずっとありました。形を作るコストが下がったことで、その差が隠せなくなっただけです。
形だけのアウトプットを量産する働き方と、コンテキストを積みながらアウトプットする働き方。自分はどちらを選びたいか。ちょっと立ち止まって、自分のアウトプットに問いかけてみてください。
「こういう場合は、どうなる？」
その問いに答えられる分だけ、そこにはコンテキストが積まれています。