ベンダーが知見を持ち帰るたび、JTCの開発力は細っていく

ベンダーは成果物を納品する。でも判断は納品されない。

成果物と判断、一体何が違うかお分かりだろうか。

外注先から成果物が納品される。画面は動く。APIもつながる。設計書もある。テスト結果も添付されている。レビュー会では、予定通り完了しましたと説明される。会議室の空気は、ひとまず終わった案件として次へ流れていく。

でも、そのプロジェクトで一番価値があったものは、本当に納品されたのか。

私は以前、ベンチャー企業に勤めていたとき、大手企業からの受託開発に開発者として入っていた。社長と話しながら、プロジェクトの進め方や顧客との距離感も見ていた。そこで強く覚えているのは、成果物の裏側にある知見の扱いだ。

顧客に渡すものは渡す。契約範囲のソースコード、設計書、説明資料、テスト結果、利用手順。そこは当然やる。だが、プロジェクトを通じて得た知識のすべてを、顧客へ同じ濃度で渡すわけではなかった。プロジェクト範囲外にも使える調査結果、設計上の勘所、業務理解、詰まりやすい論点、別案件に転用できるパターン。そういうものは、自社の知見として残そうとしていた。

平たく言えば、顧客より自分たちのほうが詳しい状態を保つ。そうすることで、次の相談が来る。次の発注につながる。契約交渉でも優位に立てる。これはきれいごとの話では済まない。受託開発を商売として続けるなら、かなり自然な戦略だ。

今はJTCの側にいる。すると、あのときベンダー側から見えていた景色が、別の角度で見える。

外注先が資料を整えてくれる。仕様の抜けを拾ってくれる。設計案を出してくれる。受入条件まで補ってくれる。テスト観点も出してくれる。会議ではとても助かる。上司への説明もしやすい。プロジェクトは前に進んでいるように見える。

ただ、そのたびに思う。

この知見は、社内に残っているのか。

JTCは外注を使う。人が足りない。スキルが足りない。開発を速めたい。品質を安定させたい。説明としては分かる。外部の力が必要な場面もある。専門性の高い領域を、外から借りる判断も現実的だ。

だが、外注先に実装だけでなく、仕様、設計、受入条件、テスト観点、場合によってはプロダクト判断まで寄せ始めると、社内に残るものが急に薄くなる。

社員は忙しい。PRを見る。資料を読む。仕様の質問に答える。受入をする。課題管理表を更新する。進捗を上司に説明する。外注先との定例に出る。チャットも途切れない。だから、開発に深く関わっている感じはある。

でも、忙しさは開発力の蓄積と同じ意味を持たない。

社員が強くなるのは、成果物を確認した瞬間だけでは足りない。なぜその設計を選んだのか。どの案を捨てたのか。どの制約を重く見たのか。どの品質基準を守ったのか。どの運用リスクを先に潰したのか。次に似た案件が来たとき、どこから調べればいいのか。

この判断過程を自分の言葉で説明できるようになって、ようやく知見が社内に残る。

JTCがやりがちなのは、成果物レビューで安心することだ。画面が動くか。仕様通りか。テストは通ったか。期限に間に合うか。納品物は揃っているか。もちろん必要だ。だが、それだけでは知見の移転は起きにくい。

成果物は納品された。でも判断は納品されていない。

ここを見ないまま外注を続けると、社内にはプロジェクトの履歴だけが増える。どの案件をやったか。どのベンダーに頼んだか。どの会議で承認したか。どの資料を受け取ったか。記録は残る。だが、次の判断に使える濃い知識が残っているかは別の問題だ。

ベンダー側から見ると、この差は商売になる。

顧客が自力で判断できない領域を持っている。だから次の相談が来る。顧客が調査の勘所を持っていない。だから次の技術選定も任される。顧客が設計判断の理由を握っていない。だから改修時にも声がかかる。顧客が品質基準を自分で引けない。だからテスト観点も依頼される。

知識差は、継続発注の燃料になる。

だから、ベンダーを責めても浅い。ベンダーは自社の競争力を作っている。顧客に価値を出しながら、自社にも知見を残す。受託会社としては自然な動きだ。むしろ、それを読めていない発注側のほうが甘い。

JTC側が持つべき問いは、外注先は良心的かどうかだけでは足りない。プロジェクトを通じて、社内に何が残る設計になっているか。ここを問う必要がある。

たとえば、設計書を受け取るだけで終わらせると弱い。設計判断メモが要る。なぜA案を採り、B案を捨てたのか。性能、保守性、運用、セキュリティ、開発期間、将来拡張性のどれを重く見たのか。外注先の説明を聞くだけで終わらせず、社内の開発者が自分の言葉で再説明できる状態まで持っていく。

受入条件も同じだ。外注先がきれいに書いてくれると助かる。だが、どこまでできたら価値があるかを外注先に寄せすぎると、POは発注窓口に近づく。顧客価値の線引きは社内で握る必要がある。外注先に草案を作ってもらっても、最後にその条件をプロダクトの文脈で説明するのは社内の仕事だ。

テスト観点も同じだ。テスト一覧をもらって満足していると、品質基準は外へ寄る。異常系をどこまで見るか。どのログが運用に必要か。どの失敗をユーザーにどう見せるか。どの自動テストをDoneに含めるか。ここを社内の基準として持てないと、外注先が変わるたびに品質の手触りが揺れる。

外注を使うなら、納品物の一覧より先に、知見の回収設計を作るべきだ。

これは大げさな話ではない。スプリントレビューの中でできる。なぜその実装にしたかを聞く。代替案を聞く。捨てた案を聞く。次に似た開発をする場合の注意点を聞く。運用で詰まりそうな箇所を聞く。調査で見つけた副産物を聞く。

ただし、聞くだけでは足りない。

社内側が書き直す必要がある。外注先の説明を、社内の設計判断ログに落とす。チームのDoDに反映する。次回のリファインメントで使う。運用手順に組み込む。似た案件のテンプレートにする。PRレビュー観点に変換する。

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

この工程をやらない会社では、社員はレビュー係になる。外注先から来たものを読む。指摘する。承認する。上司に説明する。たしかに必要な仕事だ。だが、それだけを続けると、社員はプロダクトを作る人から、成果物を検収する人へ近づいていく。

社員がレビュー係になった会社では、内製化という言葉だけが社内に残る。

内製化という言葉も、JTCではよく軽くなる。社員が外注先を管理していれば内製に近いと扱われる。社員が受入をしていれば社内で見ていると言われる。社員がPRにコメントしていれば技術を握っているように見える。

でも、本当に握っているかは、予定外のことが起きたときに分かる。

障害が起きた。性能が出ない。顧客が想定と違う使い方をした。外注先の担当者が変わった。仕様変更が入った。リリース後に問い合わせが増えた。こういう場面で、社内が判断できるか。外へ聞かないと進まないか。差はそこに出る。

外注で進んだプロダクトと、社内が強くなったプロダクトは、平時には同じように見える。

画面は増える。チケットは閉じる。報告資料も埋まる。リリースもできる。だから経営層からは差が見えにくい。だが、予想外の変化が来た瞬間に差が出る。社内に知見が残っている会社は、多少遅れても自分たちで判断できる。残っていない会社は、また外部に確認する。

そして、また発注する。

このループが続くと、JTCの社員は忙しいまま強くならない。会議は増える。レビューも増える。確認も増える。外注先との調整も増える。だが、顧客理解、設計判断、品質基準、運用知識、技術選定の勘所が社内に太く残らない。

この状態は、開発者としてかなり焦る。

仕事はある。むしろ多い。だが、市場価値が太っている感覚が薄い。自分でプロダクトを前に進める経験が積めていない。自分で設計の芯を握る場面が少ない。外注先の成果物に詳しくなっているだけで、自分たちのプロダクトに詳しくなっているとは言い切れない。

ここに気づいた開発者は、たぶん現場で少し面倒な人になる。

設計の理由を聞く。受入条件の根拠を聞く。テスト観点を社内基準へ落とそうとする。外注先の調査結果をナレッジとして残そうとする。PRレビューで、動くかどうかだけで終わらせない。スプリントレビューで、何を学んだかを聞く。

上司から見ると重い。外注先から見てもやりにくい。だが、その重さが社内の開発力を守る。

本当にまずいのは、誰も聞かなくなることだ。外注先が作る。社員が確認する。上司が報告する。チケットが閉じる。次の案件へ行く。全員が忙しく、誰も立ち止まらない。

そのまま数年経つと、会社にはプロジェクトの管理者が残る。だが、プロダクトを自分たちで変え続ける人が少なくなる。

JTCが外注を使うなら、契約や開発プロセスの中に知見移転を埋め込む必要がある。納品物に、判断ログを含める。レビュー会で、代替案と採用理由を説明してもらう。スプリントの終わりに、成果物だけでなく得た知見を社内側が記録する。外注先が作った資料をそのまま保存するだけで終わらせず、社内の言葉へ翻訳する。

さらに、知見移転を外注先の善意に任せない。契約、DoD、レビュー観点、受入条件に入れる。成果物の納品と同じくらい、判断過程の移転を扱う。プロジェクトの最後にまとめてやると、だいたい薄くなる。スプリントごとに回収したほうがいい。

ここまでやって、ようやく外注を使っても社員が強くなる可能性が出る。

外注先に何を渡すかより先に、社内に何を残すかを決める。

これを決めない会社は、成果物を買っているようで、知見を外へ預け続けている。外注先は強くなる。別案件でも使える知見が増える。提案の精度も上がる。顧客業務にも詳しくなる。一方で、JTC側は成果物を受け取り、調整とレビューに追われ、また次の案件で外部の力を必要とする。

この関係を分かったうえで使うならいい。

でも、分かっていないまま外注を便利に使うと、社員は忙しいのに強くならない。プロジェクトは進む。画面も増える。会議資料も整う。けれど、社内に判断できる人が増えない。

ベンダーが知見を持ち帰るのは、ある意味で当たり前だ。商売だからだ。だからこそ、JTC側はもっと貪欲に知見を取りに行く必要がある。成果物の検収だけで満足している場合ではない。判断を取りに行く。失敗の理由を取りに行く。調査の副産物を取りに行く。次の案件で使える勘所を取りに行く。

それをやらない会社の開発者は、今日も忙しい。
外注先から上がってきた資料を読み、コメントを書き、会議で説明する。

でも、その忙しさの中で、自分たちの会社に何が残っているのか。

そこを見ない外注活用は、かなり高くつく。