契約もAIも乾きを潤さない: エンジニアリングに必要なのは「検索力」ではなく「文脈への参加」だ

速く答えを出せるのに、なぜ仕事は空虚になるのか

高単価の業務委託エンジニアを迎え、Claude Codeのような開発支援ツールを導入し、Tavilyのような検索手段まで使えるようにする。それでも、チームの成果が思ったほど伸びないことがある。

この現象は、一見すると奇妙です。人を増やし、知識へのアクセスを増やし、コードを書く速度まで上げている。それなのに、プロジェクトには手応えが生まれない。会議では進捗が報告され、画面上ではプルリクエストがマージされているのに、誰も「この仕事は前に進んでいる」と感じられない。

ここには、現代のソフトウェア開発が見落としがちな問題があります。成果を生むのは、能力や情報の量だけではない。何に責任を持ち、どの文脈に参加し、結果を誰と引き受けるのかという関係性であるという問題です。

契約期間の終わりが明確な関係は、合理的です。必要な期間だけ専門性を借りられます。AI開発ツールも合理的です。わからないことを検索し、実装案を生成し、調査時間を短縮できます。しかし、合理性はそれ自体では共同性になりません。速く答えを得ることと、重要な問いを選び、その答えの結果まで引き受けることは別の能力です。

情報へのアクセスが速くなっても、仕事への参加が深くなるとは限らない。

この違いを理解しないまま、人やツールを追加すると、チームは「高性能なのに乾いている」状態になります。

エンジニアリングには二種類の仕事がある

開発の仕事を、単純に「コードを書くこと」と捉えると、外部人材やAIツールの価値を過大評価しやすくなります。実際には、エンジニアリングには少なくとも二種類の仕事があります。

一つ目は、局所的な問題を解く仕事です。エラーの原因を調べる、APIの使い方を確認する、テストを書く、既存コードをリファクタリングする。これらは、入力と出力を比較的明確に定義できます。検索やコード生成は、こうした仕事に非常に強い。Tavilyのような検索手段を組み合わせれば、公式ドキュメントや実装例を探す速度は上がります。Claude Codeのような支援環境を使えば、調査から編集、検証までの往復も短くできます。

二つ目は、何を解くべきかを決める仕事です。顧客が本当に困っていることは何か。この機能は売上に効くのか、それとも単なる要望対応なのか。技術的な負債を今返すべきか、あえて後回しにするべきか。障害を防ぐために複雑な仕組みを導入する価値があるのか。これらは検索結果から直接取り出せません。

検索は「既に言語化された問い」に答えます。しかし、プロダクトの現場で価値を分けるのは、問いの前にある判断です。検索能力が高い人でも、間違った問題を正確に解いてしまうことがある。AIはその傾向をさらに強めます。曖昧な依頼から、整ったコードを驚くほど速く作れるからです。

ここで重要なのは、AIや外部人材を否定することではありません。彼らが得意なのは、問題解決の速度を高めることです。苦手なのは、その問題が組織にとってどれほど重要かを、長期的な文脈の中で判断することです。

例えば、決済画面の表示速度が遅いという課題があったとします。外部の専門家は、プロファイリングを行い、キャッシュを追加し、数値を改善できるかもしれません。AIも関連する実装パターンを検索し、変更案を作れるでしょう。

しかし、その改善によって決済失敗率が上がったらどうでしょうか。あるいは、速度を改善するために監視が難しくなり、半年後の障害対応コストが増えたらどうでしょうか。さらに、実は離脱の主因が速度ではなく、料金体系のわかりにくさだったらどうでしょうか。

局所的な解決能力は高くても、システム全体の結果に対する責任がなければ、最適化は簡単に手段の目的化へ変わります。

「乾いた関係」の正体は、忠誠心ではなく文脈の不足である

外部のエンジニアに忠誠心がないから問題だ、と考えるのは少し粗い見方です。人は雇用されていても、必ずしも組織に忠誠を感じるわけではありません。逆に、契約関係であっても、プロジェクトの目的に深くコミットする人はいます。

本質は忠誠心という感情だけではありません。より正確には、判断に必要な文脈を持ち、判断の結果を継続的に観測できるかどうかです。

短期契約の仕事では、成果物の納品が評価の中心になりやすい。すると、本人が最適化する対象は「納期までに完成させること」になります。組織が本当に必要としているのは「完成後も使われ、利益や信頼や学習につながること」なのに、評価される範囲がそこまで届いていないのです。

この構造はAIにも似ています。AIに「認証機能を追加して」と頼めば、実装は返ってくるかもしれません。しかし、その機能が誰の不安を減らすのか、既存ユーザーの利用を妨げないか、運用担当者が管理できるかまでは、依頼文に書かれていない限り見えにくい。

つまり、外部人材とAIの共通点は、冷たいことではありません。与えられた境界の内側では高い性能を発揮するが、境界そのものを更新する責任は自動的には持たないことです。

ここから、開発組織を考えるための便利なモデルが得られます。仕事の価値は、次の四つの要素の積で決まると考えてみます。

価値 = 技術能力 × 文脈理解 × 所有感 × フィードバックの継続性

どれか一つがゼロなら、全体もほぼゼロになります。技術能力が高くても、文脈理解がなければ、不要なものを高品質に作るだけです。所有感があっても、結果を観測できなければ、思い込みに基づく改善になります。継続的なフィードバックがあっても、実装能力がなければ変化を起こせません。

外部人材は技術能力を補い、AIは調査と実装の速度を補います。しかし、残りの要素を組織側が設計しなければ、掛け算の値は伸びません。

AI時代に最も重要なスキルは、検索ではなく「文脈を渡す力」になる

開発支援ツールを使いこなす人は、単にコマンドを知っている人ではありません。検索の仕方やコード生成の指示に加えて、何をどこまで伝えるべきかを理解しています。

AIに良い仕事をさせるためには、少なくとも次の情報が必要です。

1. このシステムは誰のために存在するのか
2. 今回の変更で、どの指標を改善したいのか
3. 絶対に壊してはいけないものは何か
4. 過去にどのような判断をし、なぜそうしたのか
5. 実装後に、成功と失敗をどう観測するのか

これはプロンプトの技巧というより、組織の記憶を構造化する作業です。AIが賢くなるほど、曖昧な依頼を補完する力も高まります。その結果、チームが文脈を持っていない場合でも、もっともらしい成果物が出てしまう。これが危険なのです。

人間だけで開発していた時代は、実装が遅かったため、途中で議論が起きました。調査に時間がかかり、コードを書く前に複数の人が問題を考え、暗黙の前提が表に出ることも多かった。AIによって実装が速くなると、その摩擦が消えます。摩擦が消えることは効率化ですが、同時に、判断の検査機会が失われることでもあります。

したがって、AI活用の成熟度は「どれだけ速くコードを生成できるか」では測れません。どれだけ明確な文脈を与え、どれだけ早く現実からフィードバックを受け、必要なら問いそのものを修正できるかで測るべきです。

実務では、プロジェクトのリポジトリに次のような短い文書を置くだけでも効果があります。

• プロダクトの目的と、現在の最重要課題
• 重要な制約と、過去に採用しなかった案
• 変更してはいけない契約やデータ構造
• 監視すべき指標と、異常時の対応方針
• 技術的判断の履歴と、その判断が変わる条件

これらはAIのためだけの資料ではありません。新しく参加する外部エンジニアのためでもあり、半年後の自分たちのためでもあります。文脈が文書化されていれば、契約関係でも参加の深さを高められます。

人とAIを「手足」ではなく、責任の輪の中に置く

外部エンジニアやAIを有効に使うために必要なのは、彼らを無理に仲間扱いすることでも、逆に完全な作業者として扱うことでもありません。必要なのは、誰が意思決定し、誰が結果を観測し、誰が次の問いを更新するのかを明確にすることです。

例えば、外部エンジニアに「検索機能を実装してください」と依頼するだけでは、責任の範囲が狭すぎます。代わりに、「検索から購入までの離脱率を改善したい。現状の検索利用率は何パーセントで、購入者と非購入者にどの差があるかを確認し、二週間で最小の検証案を出してほしい」と伝える。

この依頼では、実装は手段になります。調査、仮説、指標、検証期間が含まれているため、担当者はコードの完成ではなく、学習の獲得に責任を持てます。AIを使う場合も同じです。まず仮説と制約を渡し、検索や実装を任せ、最後に人間が結果を確認するのではなく、観測設計まで含めて一つの仕事にします。

ここで有効なのが、責任の輪という考え方です。仕事を次の五段階に分けます。

1. 問いを定義する
2. 情報を集める
3. 解決案を作る
4. 現実に適用する
5. 結果を観測し、問いを更新する

AIや外部人材に、二番目から四番目を任せることはできます。しかし、一番目と五番目を組織が放棄すると、開発は作業の連続になります。特に五番目のフィードバックが欠けると、誰も自分の判断が現実にどう影響したかを知りません。そこで、仕事は乾きます。

反対に、契約期間が限られていても、担当者が顧客の反応や指標の変化を見られ、判断の余地を与えられ、結果を次の改善に反映できるなら、関係はかなり濃くなります。長期雇用はコミットメントを生みやすい条件ではありますが、十分条件ではありません。参加の設計が、関係の深さを決めるのです。

明日から変えられる、乾かない開発の設計

Key Takeaways

• 依頼を成果物ではなく、検証可能な仮説として書く

  • 「画面を作る」ではなく、「初回利用者の登録完了率を上げるため、最小の変更を試す」と定義する。

• AIや外部人材に渡す前に、文脈を五行で整理する

  • 目的、対象ユーザー、成功指標、制約、失敗時の影響を明記する。長い資料より、判断に効く短い文脈が有効です。

• 実装の完了ではなく、フィードバックの取得を完了条件にする

  • マージや納品をゴールにせず、利用データ、顧客反応、障害の有無を確認するところまでを仕事に含める。

• 過去の判断を検索可能にする

  • 技術選定や仕様変更の理由を記録する。Tavilyのような検索手段やAI支援は、情報が存在して初めて組織の記憶を活用できます。

• 人には判断の余地を、AIには探索の余地を与える

  • 人間を単なる承認者にせず、問いと優先順位を担わせる。AIは実装の代行者ではなく、調査と試行の速度を高める道具として使う。

開発組織が本当に必要としているのは、もっと高価な人材でも、もっと賢いツールでもない場合があります。必要なのは、仕事の始点と終点を広げることです。始点を「指示された作業」から「解くべき問題」へ広げ、終点を「納品」から「現実から学ぶこと」へ広げる。

その広がりがあれば、契約は単なる手切れの良い境界ではなくなります。AIへの指示も、単なる命令文ではなくなります。どちらも、同じ目的に向かう責任の輪の中へ組み込まれるからです。

最後に、私たちは「誰がコードを書いたか」という問いに慣れすぎています。しかし、AIと外部人材が当たり前になるほど、この問いの重要性は下がります。代わりに問うべきなのは、「誰が問題を定義し、どの文脈で判断し、結果から何を学んだか」です。

コードは、検索できます。実装案も、生成できます。けれど、何を大切にするか、どの失敗を受け入れ、どの結果を自分たちの問題として引き受けるかは、誰かが責任を持って設計しなければなりません。

乾きを潤すのは、関係の長さでも、ツールの賢さでもない。結果が次の問いへ戻ってくる、責任と学習の循環である。