エンジニアを雇うか、技術パートナーを入れるか:両方の経路をどう積算するか

トレーディングターミナルの構想があり、予算があり、エンジニアリングチームはいない。次に来る問いは、ほとんどの場合、価格の比較として立てられる。エンジニアを雇うといくらか、どこかの会社に作らせて引き渡してもらうといくらか。

その立て方は判断を隠してしまう。どちらの経路も、行き着く先は動くコードである。違うのは、使えるバージョンが最初にいつ存在するか、一年後に誰がそのシステムを分かっているか、要となる人が抜けたときに何が起きるか、そして仕事が止まったときに何が手元にあるかだ。

どちらの経路もコードを生む。違うのは知識がどこにあるかだ

トレーディングターミナルは一つのシステムではない。マーケットデータの経路、注文発注の経路、pre-trade リスクチェック、取引所やブローカーへの接続、ポジションと口座の状態、板が動くあいだ描き直し続ける画面、そして引け後にそのすべてを照合するバックオフィスである。

採用するとき、あなたはそのシステムを買っているのではない。それを生む組織を作っている。仕組みについての知識はゼロから始まり、雇った人たちの頭の中に溜まっていく。その人たちが留まるあいだは資産であり、留まらなければ、それがそのままリスクの全部になる。

パートナーと契約するとき、あなたが買っているのは、すでによそに存在するシステムと決定の履歴である。知識は高い位置から始まり、初日は社外にある。それが社内に移るかどうかは契約の条項と日々の進め方の問題であって、放っておいて起きることではない。

ここでいうシステムの知識が何を指すのかを、具体的にしておくとよい。それはソースコードではないからだ:

• なぜその採番方式なのか、そして単純な方式なら通してしまう障害のうち、どれを弾くのか
• 接続層がどの取引所の癖を回避しているか、そしてその回避策がどの障害から生まれたか
• リスクチェックを走らせる順序と、そのうちの一つが時間内に答えないときにシステムが何をするか
• マーケットデータのフィードにギャップが出て、取引時間中に板を作り直さねばならないときのリカバリ手順
• どのテストが実際に支えていて、どれが見かけ上のカバレッジにすぎないか
• 相場が荒れた朝のデプロイ経路がどうなっているか、そして誰が実行してよいか

そのどれも、放っておいてリポジトリに入ることはない。それは人の中にある。書かせる手順がない限りそのままであり、その人が自社の従業員でもパートナーのエンジニアでも同じだ。

最初に使えるバージョンは、最初のコミットの前に決まっている

採用の経路の前には、予算では取り除けない待ち行列がある。技術的に説明できる募集要項を書き、トレーディングのエンジニアが希少な市場で候補を探し、社内の誰もまだ評価できないスキルを面接し、退職予告期間を待ち、そして最初のしばらくは、新しいチームがアーキテクチャを作るのではなく議論するのを眺めて過ごす。

パートナーの経路は、候補探しではなくスコープから始まる。時間の差はそこから来る。取り除けないのは、あなたにしかできない仕事だ。そのターミナルが何のためのものか、どの銘柄とどの取引所が先に重要か、最初の利用者は誰かを決めること。

そして日程の一部はどちらの経路にも属さない。次の項目は、誰がコードを書いていようと自分のペースで進む:

• ブローカーや取引所への加入手続きと、その裏にある書類仕事
• 取引所のテスト環境での適合性テスト。時間枠を決めるのは取引所であって、あなたではない
• マーケットデータのライセンス。何を表示してよいか、誰に再配信してよいかを決める
• 時刻同期、監査証跡、そして規制当局が求める記録の保持
• 最初の利用者が、新しいシステムに本物の注文を流す気になること
• あなた自身のプロダクト上の判断、とくに互いに矛盾する二つ

だから正直な比較は、二つの納期の競争ではない。自分では動かせないものを仕事の前にどれだけ少なく置く経路か、そして自分で動かせる部分をどちらが早く始められるか、という問いである。

要となる人が抜けたとき、それぞれの経路はどうなるか

同じ問いを両方の経路にぶつける。マーケットデータのハンドラを書いたエンジニアが月曜に働けなくなったら、火曜に何が起きるか。そしてその次の四半期に何が起きるか。

自分で雇った小さなチームでは、答えはたいてい一人の名前に懸かっている。初期のチームは構造上、知識を集中させる。ある一人がホットパスを持ち、別の一人が接続を持ち、ロードマップは残っている人に合わせて静かに組み直される。パートナーの場合は、そこでコードを読んだエンジニアが一人より多いかどうか、そしてそれが契約に書かれているかどうかに懸かる。

どちらの体制も、それ自体では安全ではない。あなたの案件に一人しかエンジニアを置いていないパートナーは、二人の社内チームと同じように脆い。守り方はどちらも同じだ。後から復元するのではなく、生まれている最中に知識を書き残すことである。

• サブシステムごとの設計ノート。何をするか、何を意図的にしないか、何が壊すかを書く
• 検討した代替案まで含めた決定記録。それが説明するコードの隣、リポジトリの中に置く
• 記録したセッションを再生するテスト。障害は議論の対象ではなく、そのまま再現される
• 重要な経路それぞれに、変更をマージしたことのある人が最低二人 ― これは文書の規則ではなく人員配置の規則である
• 実際に起きたすべての障害についてのランブック。起きたその週に書かれたもの
• オンコールのエンジニアなら誰でも実行できるデプロイとロールバックの経路。パスワードのために誰かを起こす必要はない

引き継ぎは最後のメールではなく、受け入れテスト付きの成果物である

引き継ぎという言葉は、まるで違う二つの出来事を指す。一つはファイルの受け渡し。もう一つは、作った人たちなしで続けていける能力の受け渡しであり、金を払う価値があるのは後者だけである。

後者は、一つひとつに受け入れテストを付けた成果物の一覧として、スコープに書き込む。妥当な一覧はこうなる:

• 最終状態のアーカイブではなく、履歴を丸ごと備えたリポジトリ ― 理由は履歴の中にある
• 新しいエンジニアが、書かれた手順どおりにクリーンなマシンで再現できるビルド。文書化されていないローカル設定は無し
• コードとして記述されたインフラ。そこから作られる環境と、環境どうしの違いも合わせて
• 秘密情報はあなたが保持する。ローテーション手順は、書かれているだけでなく、最低一度は実行されていること
• デプロイとロールバックのランブック。パートナーは黙って見ているだけで、実行はあなたの側が行う
• 監視、アラートの閾値、そしてアラートごとに一行 ― それが何を意味し、何をすべきか
• 外部接続ごとのプロトコルとメッセージの仕様。使うフィールドと、無視するフィールドの両方を含める
• テスト一式と、わざと落として見せる実演。何を捕まえるテストなのかが分かる
• あなたのエンジニアが変更を書き、パートナーはレビューだけをする、期間を明示した区間

一度も予行演習していない引き継ぎは、成果物ではなく計画である。最後の請求書の後ではなく、開発の途中で演習する。やり方は単純だ。システムを書いた側が黙って見ている前で、あなたのエンジニアが変更をデプロイし、ロールバックする。

所有権は引き継ぎとは別の問題であり、最後に判明するものではなく、着手前に契約で決着させるものである。私たち自身の答えは一文であり、どの文書のどの版でも短くしない。

二つの答えのあいだに三つの形態がある

この問いはたいてい二択で立てられる ― チームを雇うか、丸ごと誰かに渡すか。実際には、ほとんどの開発はその両極のあいだにあり、システムが成熟するにつれて位置を動かしてよい。

三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。私たち自身の側はそう説明している。三つの違いは請求書ではない ― 計画を持つのは誰か、優先順位を持つのは誰か、結果に責任を負うのは誰か、である。

• フルデリバリー。計画も順序も結果もパートナーが持ち、あなたはプロダクトの判断と受け入れを持つ。スコープを定義でき、まだ管理するチームがない最初のバージョンに合う
• 専任チーム。バックログも優先順位もあなたのもので、相手の人員はあなたのプロダクトだけに就く。固定した計画が許すよりスコープが速く動く段階に合う
• あなたのチームに入るエンジニア。プロセスもコードレビューもあなたのもので、間違いの代償が高い経路 ― 注文経路、取引所への接続、リカバリ手順 ― に相手の専門家が就く
• この三つは排他的な選択肢ではなく段階である。フルデリバリーで始まり、システムを書いているあいだにあなたが雇ったチームの中に、二人のエンジニアが入る形で終わることもある

最後の点が、もとの問いのほとんどを解いてしまう。パートナー経路のいちばん強い形は、最初から自社チームを前提に組む。すでに存在するシステムに対して採用でき、面接は候補者がこれから保守するコードに基づき、新しく入った人が最初に読むのは空のリポジトリではなく決定記録になる。

請求書に現れない部分も含めて、両方の経路を積算する

この判断で最も役に立たない数字が単価の比較である。二つの経路は違う単位で請求してくるからだ。両方のリストを並べ、正直に費用を出す。

採用の経路が請求してくるもの:

• 採用にかかる時間、そして採用の失敗が遅れて分かる専門職の市場で、一人の採用を誤ったときの費用
• 雇用にかかる費用、機材、ライセンス、そして開発環境が何かを生む前から必要になるマーケットデータの購読料
• マネジメントの手間 ― 誰かがチームを回す必要があり、初めのうち、その誰かはたいていあなたである
• 最初のアーキテクチャ判断を二度行うこと。一度は間違える。あなたの案件でドメインを学ぶチームには、通常の代価である
• 開発が終わっても残る人員。構築に合わせた規模のチームは、保守が必要とする規模より大きい
• 今四半期のロードマップが定まっていようといまいと続く、恒常的な義務

パートナーの経路が請求してくるもの:

• 自前ではフルタイムで仕事を与えきれない専門家 ― たとえばセッション層のプロトコルをデバッグしたことのあるエンジニア ― を含んだ単価
• 組織の境界をまたぐ調整。これは実際の仕事であり、立ち話ではなく書かれた仕様で支払われる
• 引き継ぎが未検証のままである限り続く依存
• 再利用可能なコンポーネントが、誰も書き残していないやり方で構造を支えているという危険。所有権の条項に署名前に目を通すべき理由が、これである
• 仕様を書く手間。パートナーの正確さは、渡した判断の正確さを超えない

次に出口を積算する。どちらの経路にも出口があるからだ。採用の経路は、自分で作ったチームを縮めることで終わり、知識はその頭の中に入ったまま出ていく。パートナーの経路は、予行演習をした引き継ぎか、しなかった引き継ぎで終わる。この二つの終わり方の隔たりが、その経路のリスクである。

何かに署名する前に、両方の選択肢を一つの問いに通す。これが金曜に止まったとして、月曜に手元に残っているものは何か。答えは成果物で出す ― リポジトリ、再現可能な環境、ドキュメント、そしてそれらからシステムを再構築できる人。意図は人の退出に耐えないが、成果物は耐えるからだ。

amBrain が公に裏付けられること:私たちは2019年からアルメニア・エレバンでソフトウェアを作り、ホットパスは Rust で書いてきた。トレーディングターミナル Spectre Trade を構築し、私たちが構築したミニ取引所は MOEX のコロケーションで本番稼働している。自分のターミナルのために採用とパートナーを天秤にかけているなら、上の引き継ぎリストを最初の話し合いに持ち込み、向かいに座る相手に ― 私たちを含めて ― 一行ずつ答えてもらってほしい。