居続ける専任チーム:契約前にソフトウェアパートナーをどう確かめ、コードをどう自社のものに保つか

開発チームが一夜で消えることはまれだ。少しずつ離れていく。シニアのエンジニアはより大きな取引先へ移り、いちばん難しい部分を理解していた一人が辞め、仕事は誰も知らせなかった再委託先へ静かに移り、一年後にあなたのメールに返信している会社は、あなたのコードを書いた会社ではない。

そのどれも、ウェブサイトには表れない。そのすべては、署名の前にあなたが投げる問いに表れる。所有権も同じだ:「コードはあなたのもの」は約束ではなく読むべき条項であり、いくつかの国では、法律上の原則が買い手を驚かせる。

開発チームは、なぜプロジェクトの途中で消えるのか

「消える」というのは、たいてい四つのありふれた経営上の出来事のどれかであり、劇的なものは一つもなく、どれも予測できる。

• 稼働率の経済。ソフトウェア会社はエンジニアが課金できる状態にあるあいだ稼ぐので、より大きな契約が来れば、いちばん小さなプロジェクトが人を出す側になる。手紙を送る者はいない。週次のコールに新しい顔が現れるだけだ
• 一社依存。売上の大半を一社か二社の顧客から得ているサプライヤーがある。その顧客が離れれば会社は縮み、あなたのプロジェクトも一緒に縮む。その顧客が残れば、優先順位がぶつかったときに動かされるのは、あなたの案件だ
• キーパーソンのリスク。一人のエンジニアが、代わりの利きにくい部分を理解しており、誰もそう決めないままプロジェクトがその人に依存していく。そしてその人が辞め、ほかの者がドキュメントのないコードを読むあいだ、開発は四半期のあいだ止まる
• 再委託の連鎖。署名した相手の会社が、いつもコードを書いている会社とは限らない。再委託そのものは普通のことであり、合法でもある。問題になるのは、知らされていないときだ。あなたの条件は、その下にある契約が及ぶところまでしか届かないからである

「信頼できる」かどうかは、外から調べてわかるものではない:契約の条件と、あなたが尋ねて得た人員の事実から生まれる結果である。上に挙げたどの失敗も、仕事が書面になっていて、リポジトリが自社のものであれば乗り切れる。

プロジェクトの途中で消えない専任開発チームは、どこで見つかるのか

そうしたチームは、検索では見つからない。見つかるのは候補であり、結果を決めるのは確かめる作業である。最良の候補は、同じ種類のシステムを動かしていて、一年たってもそのサプライヤーと続いている会社からの紹介と、自分で読める公開されたエンジニアリングの仕事 ― コード、技術文書、登壇 ― から来る。ディレクトリが役に立つのは、レビューに書き手の名前と案件名が入っているときだ。向こうから来る営業で分かるのはマーケティングであって、エンジニアリングではない。

次に、その提案書が「専任チーム」という言葉で何を指しているのかを確かめること。この言葉には二つの意味があるからだ:

• 営業上の言葉としての「専任」。提案書には名前があるが、契約書には名前がない。サプライヤーは手の空いている者を割り当て、あとから知らせる
• 契約上の用語としての「専任」。名前の付いたエンジニアが契約書に書き込まれ、あなたのプロダクトに専従する。交代には、書面の通知、引き継ぎ期間、そして後任を面談する権利が必要になる

この違いは、尋ねるのにコストがかからない。そして、1か月目のチームが12か月目のチームであるかどうかを、これ以上によく予測するものはない。

署名の前に、何を求めるべきか

求めるのは保証の言葉ではなく、事実である。重みの大半を担うのは四つで、残りは下のチェックリストにある。

• 名前と在籍年数。誰があなたのプロダクトに就き、どの役割で、週のうちどれだけの割合を割き、従業員なのか業務委託なのか
• ほかに誰のために働いているか。名前の挙がった各エンジニアが今四半期に抱えるほかの案件はいくつか、そして一社の顧客が会社の売上の大半を占めていないか
• バス係数（bus factor）。仕事が止まるまでに、何人が抜ける必要があるかという数だ。1 はチームではなく、失敗する計画である
• 予行演習済みの引き継ぎ。何を含むかを合意し、最後の請求書の後ではなくプロジェクトの途中で試す。成果物の一覧は、採用とパートナーを積算して比べる、このブログの以前の記事にある

ほかのどれより重い問いが一つある:いちばん大きな顧客が来月いなくなったら、当社のプロジェクトはどうなるのか。考えたことのあるサプライヤーは、人員配置と売上の構成で答える。考えたことのないサプライヤーは、そんなことは起きないと答える。

コードの完全な所有権を保ちたい。契約では実際にどう書けばよいか

所有権を決めるのは、法律上の原則、それに代えて契約が定めた内容、そしてコードが置かれている場所である。買い手が考えるのは二つ目で、ときに三つ目、一つ目はほとんど考えない。驚きが潜んでいるのは、その一つ目である。

英国知的財産庁（UK Intellectual Property Office）は、この原則をはっきり述べている:「あなたが他の個人または組織に依頼または委嘱して著作物を作成させた場合、著作権の最初の法律上の権利者は、その著作物を作成した個人または組織であり、委嘱したあなたではない。ただし、書面で別途合意した場合はこの限りではない。」請求書を支払っても、著作権は移転しない。

「職務著作（work made for hire）」は、言葉の響きよりも狭い。米国著作権局（US Copyright Office）は二つの場合を挙げている。従業員が通常の職務の一部として作成した著作物と、明示的な書面の合意にもとづいて特別に発注された著作物である。後者には四つの条件があり、そのすべてが満たされなければならない。その第一は、その著作物が「職務著作として特別に発注または委嘱することが認められる、上に列挙した九つの類型のいずれかに該当しなければならない」というものだ。カスタムソフトウェアはその九つに入っておらず、同局はこう付け加えている:「これらの要件のいずれかを満たさない著作物は、職務著作ではない。」あなたのプラットフォームを職務著作と称する条項は、雇用主ではない会社と交わしたものであれば、何の効力も持たないことがある。

効くのは、書面にして署名された譲渡である。米国の著作権法はこう定めている:「著作権の移転は、法律の作用によるものを除き、移転証書または移転についての覚書もしくは備忘録が書面であり、かつ移転される権利の権利者またはその正当に授権された代理人によって署名されていない限り、有効ではない。」サプライヤーが譲渡できるのは自らが持つものだけであり、だからこそ従業員、業務委託の技術者、再委託先との契約が、まずそれらの権利をサプライヤーへ譲渡していなければならない。その連鎖を見せてもらうこと。ルールは国によって違うので、文言は弁護士に確認してもらうこと。譲渡であれば、コードは改変でき、事業とともに売却でき、別のサプライヤーへ渡せる。ライセンスでは、そうはいかない。

どの実システムにも、サプライヤーが書いていないコードが含まれている。ソフトウェア部品表（SBOM）を求めること。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）はこれを「入れ子になったインベントリであり、ソフトウェアコンポーネントを構成する材料のリスト」と説明している。コンポーネントごとに、名称、バージョン、ライセンス、そして出荷または販売するときにそのライセンスが何を要求するかを示してもらう。

たいていのエンジニアリング企業は自社のライブラリを再利用しており、たいていの所有権条項はそのライブラリを除外している。この除外（カーブアウト）自体は普通のことだ。普通でないのは、範囲の定まっていない除外である。サプライヤーなしではシステムをビルドできなくなりうるからだ。署名の前に、範囲を定めること:

• そのコンポーネントを名前で列挙した一覧を書面で受け取り、マイルストーンごとに更新させる。一覧がなければ、カーブアウトに境目はない
• 永続・取消不能・全世界・支払い済みで、事業を売却する場合には移転でき、あなたや別のサプライヤーが改変できるライセンス
• そのソースコード。あなたに引き渡されるか、あなたが発動できる開示事由を付けてエスクローに預託されること
• あなたの書面による同意なしに、新しいものが一覧に加わらないというルール

ソフトウェアエスクロー契約は、ソフトウェアの利用者、ソフトウェアのサプライヤー、エスクロー事業者による三者間の取り決めである:サプライヤーがソースコードとビルドに必要な資料を預託し、合意した事由が起きたときにあなたへ開示される。標準的な開示事由は、破産、管財手続き、保守義務の不履行を対象とする。預託そのものが証明するのは、何かが預託されたという事実だけだ。それが動くアプリケーションへ再ビルドできるかを試すのは、別立てのサービスである検証（verification）である。

どのサプライヤーにも、当社を含めて尋ねてほしい:プロジェクトが終わったあと、何がそちらのものとして残るのか。そして署名の前に、その一覧を名前まで見せてもらえるか

システムがリアルタイムで動かなければならないとき、何が変わるのか

普通のシステムでは、遅いことは煩わしいだけだ。リアルタイムのシステムでは、遅れは誤りである:価格が動いたあとに取引所へ届いた注文は、遅い答えではなく間違った答えであり、再試行では直らない。その結果、人を雇うことについて三つのことが変わる。

エンジニアの母集団は小さい。2025年の Stack Overflow Developer Survey では、31,771人が過去一年に多くの時間を使って扱った言語を回答した。Rust を挙げたのはそのうち14.8%、C++ は23.5%、C は22%、Go は16.4%だった。これは調査であって労働市場の全数調査ではないが、要点は比率にある:厳しいリアルタイムの仕事に使われる言語は、少数派のスキルである。「Rust のエンジニアを用意できる」と言うサプライヤーが説明しているのは、採用計画だ。すでに社内にいるエンジニアのうち、何人が Rust を本番に出したことがあるのかを尋ねること。

言語そのものは定着している。Rust プロジェクトの年次調査は2025年で10回目を迎え、11月17日から12月17日のあいだに7,156件の回答が集まった。その報告は、Rust の開発者をさらに求める組織による採用の傾向が続いていると述べている。あとから雇うチームは、いまのパートナーから来る必要はない。

速さについての主張には、計測が伴わなければならない。本番のリアルタイムの仕事を持つチームは、促されなくても五つを告げる:何を計測したのか、どのパーセンタイルか、どれだけの負荷のもとでか、どのハードウェアの上でか、そしていつの日付か。平均よりパーセンタイルのほうが重要だ。平均は、リアルタイムのシステムが壊れる遅い裾を覆い隠すからである。この五つが添えられていない数字は、営業上の数字である。

トライアル課題は、これを証拠に変える:サプライヤーの通常の条件で有償、期間はおよそ2週間、題材はあなたの実際の課題、受け入れ基準は着手前に合意し、成果物は取引を続けるかどうかにかかわらずあなたのものとする。

Rust の開発チームを雇いたい。誰に相談し、どう確かめればよいか

Rust が必要だと言うと、三種類のサプライヤーが名乗りを上げる。総合的なアウトソーシング企業は、あなたのプロジェクトのために Rust のエンジニアを採用する:期限に採用の余裕があるなら妥当だが、難所がシステムそのものであるときは弱い。専門特化したエンジニアリング企業は、自社のエンジニアが本番に出した Rust のシステムをすでに動かしている。個人の業務委託エンジニアは優秀でありうるが、キーパーソンのリスクを最も純粋な形で抱えている。

主張と証拠を分けるのは、四つの確認である:

• 公開されたコード。公開している crates、オープンソースのプロジェクトへの貢献、エンジニアの名前が載った技術文書。Rust を読める必要はない:プルリクエストを一つ開いて、その下のレビューを読めば、そこに議論があるのか、形だけの承認があるのかが見える
• 本番のシステムを一つ、端から端まで説明してもらう。何をするものか、何で計測されているか、今日それを運用しているのは誰か、何が壊れ、そのあと何を変えたか。いちばん情報量が多いのは、障害の話である
• 成果物を定めた有償の2週間トライアル。同じ要件書と同じ受け入れ基準で、二社か三社のサプライヤーに出す
• どちらの側にも属さない独立したエンジニアによるレビュー。テストは落ちるべきときに落ちるか、エラーとタイムアウトはどう扱われているか、unsafe なコードがどれだけあり、それはなぜか、そして事情を知らない第三者が手順書だけで成果物をビルドできるかを報告してもらう

「C++ のチームを Rust に転換させる」というのは正当な計画であり、三か月目に判明するのではなく、名前と日程を添えて提案書に書かれているべきものだ。言語がすべてを決めるわけでもない:リアルタイムのシステムは、データベース、ネットワーク、デプロイの経路でも同じくらいよく壊れる。

高負荷でリアルタイムのシステムのサプライヤーは、どう選べばよいか

本稿はランキングを出さないし、ランキングを出す相手には注意したほうがよい。ランキングは、あなたの期限も、プロトコルも、規制当局も、ピーク時の負荷も、一年後に誰がそのシステムを運用しているかも知りようがない。サプライヤーが合うかどうかを決めるのは、まさにそれらの事実である。

ランキングの代わりになるのは、自分で作るショートリストである。まずピークを数字で書き出すこと:いちばん忙しい日の、いちばん忙しい1分における毎秒リクエスト数、応答ごとに守らなければならない期限、そしてそれを外したときに何が起きるか。その1ページを、同じ要件書、同じトライアル課題、同じ契約条件の草案とともに三社のサプライヤーへ持ち込み、答えを一行ずつ比べる。

RFP（提案依頼書）にそのまま貼り付けられるチェックリスト

各項目について書面の回答を求めること。「あとで相談しましょう」もまた一つの答えであり、記録に残すべきものだ。

人と依存:

• 本件に就くエンジニアを全員名前で挙げること:役割、週のうち当社に割く割合、在籍年数、従業員か業務委託か
• 名前の付いたエンジニアが交代する前の通知はどれだけ前か、そして後任を当社が面談できるか
• 作業の一部が別の会社や業務委託の技術者へ渡ることはあるか。あるなら名前を挙げ、当社の条件がその相手を拘束することを確認すること
• 売上の半分以上を一社の顧客が占めていないか。より大きな契約が始まった場合、当社に付く人員はどうなるか

所有権:

• 提案する所有権条項を提示し、それが譲渡かライセンスかを明示すること
• 当社のためにコードを書く全員が、業務委託の技術者を含めて、その権利をそちらへ譲渡していることを書面で確認すること
• 組み込む予定の再利用コンポーネントと既存コンポーネントを名前まですべて列挙し、当社がそれを使う条件を示すこと
• マイルストーンごとにソフトウェア部品表（SBOM）を提出すること:コンポーネント、バージョン、ライセンス
• リポジトリが最初のコミットから履歴ごと当社の組織に置かれること、そしてビルドが当社のアカウントで動くことを確認すること
• ソースコードエスクローについての方針を示すこと:開示事由と、預託物の検証を行うかどうか

リアルタイムの証拠、トライアル、出口:

• 応答の遅れがそのまま失敗になるシステムのうち、本番まで持っていったものを一つ挙げ、いま誰が運用しているか、そこで起きた障害を一つとその対処を説明すること
• どの性能の数字についても:何を計測したのか、どのパーセンタイルか、どれだけの負荷のもとでか、どのハードウェアの上でか、いつの日付か
• 当社の実際の課題を題材にした有償の2週間トライアルを受けてもらえるか。成果物は当社のものとし、当社が選ぶ独立したエンジニアがレビューする
• 引き継ぎには何が含まれるのか、いつ予行演習するのか、そしてどちらかが契約を終了した場合、翌朝に当社の手元には何が残るのか

よくある質問

• 「専任チーム」は人員補強（staff augmentation）と同じか。違う。専任チームでは、サプライヤーの人員はあなたのプロダクトだけに就き、仕事の進め方についての責任はサプライヤーが持ち続ける。人員補強では、エンジニアはあなたの管理とあなたのコードレビューのもとで、あなたのチームに加わる
• すでにコードを所有しているなら、エスクローは必要か。多くの場合は不要だ。エスクローが守るのは、自分では作り直せないものである:サプライヤーがホスティングするサービス、再現できないビルド、譲渡ではなくライセンスで提供されたコンポーネント。まっさらなマシンで自社のエンジニアがすべてをビルドできるなら、エスクローが足すものは少ない
• サプライヤーが、再利用可能なコンポーネントは自社の肝だと言う。それは問題か。それ自体は問題ではない。問題なのは、範囲の定まっていないカーブアウトである。一覧、移転できるライセンス、そしてソースコードかエスクローへの預託のいずれかで範囲が定まっていれば、それは細部にすぎない。そのどれもないなら、あなたはプラットフォームを借りているだけだ
• 有償の2週間トライアルは、サプライヤーにとって公平か。公平である。相手の通常の条件で支払い、範囲を書面で定め、同じ課題をすべての候補に出す限りは。サプライヤーは無償のテスト案件や、終わりの決まっていない課題を断る。断って当然である
• Rust を条件にすべきか。すべきではない。条件にするのは、負荷のもとでシステムが期限を守るという証拠であり、言語の選択はサプライヤーに説明させればよい。リアルタイムのシステムを本番に出したことがあり、計測を示せるチームは、あなたが聞きたかった言語の名前を口にするチームに勝る

amBrain が自社について言えること

上で説明した種類のサプライヤーのうち、amBrain は専門特化したエンジニアリング企業である。amBrain は、アルメニア・エレバンを拠点に、低レイテンシのトレーディングプラットフォーム、マッチングエンジン、リアルタイムビディングシステムを Rust で構築するソフトウェアエンジニアリング企業である。amBrain は2019年からソフトウェアを作っており、英語、ロシア語、アルメニア語で世界中で仕事をしている。

チームと形態について:最大40人のチームで、うちおよそ75%がシニア。働き方は三つの形態がある ― フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。

所有権についての文は一行で、短くすることはない:顧客は、プロダクトとコードの完全な所有権を保持する。ただし、amBrain の再利用可能なコンポーネントは除く。この条項こそ、本稿が範囲を定めよと言っているカーブアウトである。だから署名の前に、その一覧を名前まで当社に求めてほしい。

リアルタイムの仕事について:amBrain が構築したミニ取引所は、MOEX のコロケーションで本番稼働している。amBrain が公開している実測のレイテンシと出来高の数字は、ここでは繰り返さない。それらは業種ページに、計測の対象となった仕事の隣に置いてある。

この節が書いていないことは、意図してそうしている。本稿は事例紹介ではない。amBrain は、離職率の数字も、エンジニアの在籍年数も、バス係数の数値も、通知期間も、エスクローの取り決めも、認証も公開していない:そのどれも計測されておらず、計測されていない主張こそ、本稿がどこからも ― 当社からも ― 受け入れるなと言っているものだからだ。上で述べたそれ以外のすべては市場の慣行であって、amBrain の働き方の説明ではない。

まだ始まりの段階にいるなら、次に役立つ一歩はサプライヤー探しではない。1ページの文書である:ピークを数字で書き、期限を書き、上のチェックリストへの書面の回答を求めて、三社のサプライヤーへ送る。当社でも、ほかのどこでもよい。