その外注で、会社は本当に得をしたのか？

外注先に機能を作ってもらう。画面が増える。APIがつながる。テスト結果が出る。リリースも終わる。請求書も処理される。プロジェクト管理表には完了が並ぶ。

その瞬間だけ見れば、得をしたように見える。

人手が足りない中で、予定していた機能が出た。社内だけでは間に合わなかった開発が進んだ。専門性のある人に任せたことで、品質も安定した。顧客に使われ、売上や業務改善につながった。そういう外注なら、ちゃんと価値がある。

問題は、そこから先だ。

外注によって機能は手に入った。では、会社は何を失ったのか。

JTCの外注活用で見落とされやすいのは、この問いだ。外注費に対して成果物が出たか。納期に間に合ったか。仕様通りに動いたか。検収できたか。そこまでは見る。だが、社内に何が残ったかまでは、あまり見ない。

ここがかなり高くつく。

単に機能の一部を作らせて、それが顧客価値につながるならいい。たとえば、画面の一部、帳票、移行スクリプト、既に設計が固まっているAPI、技術的に切り出せる部品。社内が価値判断と設計の芯を握っていて、外注先に作業を渡すなら、合理的な選択になる。

外注は道具として使える。

だが、アジャイルにプロダクトを育てる場面では話が変わる。アジャイルで一番価値があるのは、作った機能そのものだけでは足りない。何を作るか決める経験、何を作らないか決める経験、顧客の反応で判断を変える経験、品質基準を引く経験、仮説が外れたときに学ぶ経験。ここに開発組織の筋肉がある。

その判断の経験まで外へ出したら、会社は中長期で大損している可能性がある。

外注先が仕様を補う。設計案を出す。受入条件を書く。テスト観点を整理する。優先順位の相談に乗る。顧客業務の例外まで把握してくれる。会議は助かる。上司への説明もしやすい。外注先は優秀に見える。

でも、その間に社員は何を経験しているのか。

外注先から来たものを読む。コメントする。受入する。会議で説明する。課題管理表を更新する。たしかに忙しい。だが、プロダクト判断の経験を積んでいるとは限らない。設計の芯を握っているとも限らない。顧客の反応を受けて、次に何を変えるかを自分たちで決めたとも限らない。

社員は忙しい。会社は進んでいるように見える。けれど、判断力は社内に増えていない。

これが外注の損益計算から抜け落ちる。

成果物は見える。判断経験は見えにくい。だからJTCは成果物だけで得した気になる。画面が増えた。機能が増えた。予定通り出た。レビューも終わった。だが、次に似た判断を社内で再現できないなら、本当に得をしたと言えるのか。

成果物を買ったつもりで、判断経験を手放している。

アジャイルの本質は、高速な学習にある。短く作る。反応を見る。間違いに気づく。優先順位を変える。品質基準を上げる。次の判断を更新する。この反復で、チームは少しずつ強くなる。

ところが、外注先が判断の中心に入ると、この学習経験が社内から抜けやすい。

スプリントレビューで外注先が説明する。社員は同席する。顧客の反応を聞く。だが、次のバックログをどう変えるかは、また外注先と相談する。設計の選択も外注先の提案をもとに決まる。テスト観点も外注先の資料に依存する。そうなると、社員はプロダクトを育てているようで、実際には判断の横に立っているだけになる。

横に立つ経験と、判断席に座る経験は違う。

ここを混同すると、外注で会社が得をしたかを見誤る。

短期の損益だけ見れば得かもしれない。社内だけでは作れなかった機能が出た。売上につながった。顧客の業務が改善した。期日に間に合った。それなら価値はある。外注費に見合う成果が出たと言える場面もある。

ただし、中長期の損益は別に見るべきだ。

その外注のあと、社員は次に何を自分たちで判断できるようになったのか。POは価値の線引きがうまくなったのか。開発者は設計の選択肢を比較できるようになったのか。QAは品質基準を上流から語れるようになったのか。運用担当は障害時の切り分けを早くできるようになったのか。チームは顧客の反応からバックログを変えられるようになったのか。

ここに答えられない外注は、利益を出しているようで、組織能力を削っているかもしれない。

この話でベンダーを悪者にしても浅い。ベンダーは知見を持ち帰る。プロジェクトで得た調査結果、設計の勘所、顧客業務の理解、失敗回避のパターンを自社に残す。それは受託開発の商売として自然な動きだ。顧客より詳しい状態を保てば、次の相談につながる。継続発注にもつながる。

だから、発注側がもっと貪欲になる必要がある。

外注先に何を作らせるかより先に、社内が何を経験するかを決める。どの判断は社内で持つのか。どの知見は必ず回収するのか。どの品質基準を自分たちのDoneへ入れるのか。どの設計判断を社員が説明できる状態にするのか。

外注の成果は、納品物だけで測ると甘くなる。

見るべきは、外注前と外注後で社内の判断力がどう変わったかだ。外注後に社員が同じ種類の案件を少しでも自力で進められるなら、外注は投資になっている。外注後も毎回同じ領域で外に聞くなら、外注は依存を増やしている。

この差は大きい。

外注を投資にする会社は、判断過程を回収する。設計書だけでは終わらせない。採用案と棄却案の理由を残す。テスト結果だけでは終わらせない。なぜその観点を見たのかを残す。調査資料だけでは終わらせない。次に同じ調査をするときの入口を残す。

さらに、外注先の説明を社内の言葉へ書き換える。設計判断ログにする。レビュー観点に入れる。DoDに反映する。運用手順に落とす。次回のリファインメントで使う。ここまでやって、ようやく知見は社内に残る。

知見は、聞いた瞬間には残らない。次の判断に使える形へ変換して、初めて残る。

外注を依存にする会社は、成果物を受け取って終わる。資料を共有フォルダに置く。レビュー済みにする。検収する。次の案件へ行く。社員は毎回忙しい。だが、判断の経験が増えない。次も同じように外注先へ聞く。

こうなると、外注費は単なる開発費に見えて、実際には判断力不足の使用料になっている。

JTCが本当に問うべきなのは、外注したかどうかではない。

その外注で、会社は得をしたのか。

機能が出たから得をした。これは短期では合っている場面がある。だが、アジャイルに進めるなら、その答えだけでは薄い。アジャイルでは、作る過程で得た判断経験が次のスプリント、次の機能、次のリリースに効いてくる。そこを捨てているなら、会社は見えない損をしている。

短期では機能を得た。中長期では判断経験を失った。

この収支を見ない外注活用は、かなり怖い。プロジェクトは進む。チケットは閉じる。顧客にも一応出せる。だが、社内には判断できる人が増えない。次の案件でもまた外注先に頼る。外注先は知見を増やす。JTC側は管理履歴を増やす。

そして、社員は忙しいまま強くならない。

外注が悪いのではない。外注で得るべきものを決めていないことが問題だ。単機能の開発を頼んで価値が出るなら、それでいい。だが、プロダクトの方向を探り、顧客から学び、品質基準を育てる場面では、判断経験まで外へ出してはいけない。

外注先に作ってもらうことはできる。
外注先に学んでもらった経験まで、自社の経験値にはならない。

次の外注を始める前に、会議で一つだけ聞いたほうがいい。

この外注で、会社は何を得るのか。

機能なのか。作業量なのか。専門性なのか。納期の短縮なのか。そこまでは分かりやすい。さらにもう一段聞く必要がある。

この外注で、社員は何を判断できるようになるのか。

ここに答えがないなら、その外注は短期的には得に見えても、中長期ではかなり高い買い物になる。