準委任・請負・人員補強：発注モデルの選び方

稟議と契約締結のあいだのどこかで、必ずこの問いが出ます。Time & Material（準委任）で買うのか、請負（固定価格）で買うのか、それとも単にエンジニアを増員してもらうのか。実際にはこの判断が、調達部門の習慣、前回のプログラムの踏襲、あるいは比較表でいちばん安く見える行、のいずれかで決まってしまうことが多い。三つとも理由としては不適切です。

この記事は、一年後にその選択を説明する立場の人に向けたものです。三つのモデル、それらを本当に分けているもの、それぞれが正解になる条件、そしてそれぞれが失敗する固有のかたちを扱います。成果物ベースの支払いと時間ベースの支払いという、より狭い論点については別記事で掘り下げています（Output-based vs Time & Material、/ja/insights/output-based-vs-time-material）。

三つのモデルを「誰が何を背負うか」で定義する

営業上の呼び名はほぼ入れ替え可能です。契約はそうではありません。どのモデルも同じ四つの問いに答えているだけです。スコープが動いたときそのコストを誰が吸収するのか、次に何を作るかを誰が決めるのか、日々の作業で人を誰がマネジメントするのか、そして契約上の「成功」が何を指すのか。

Time & Material（準委任）

あなたが管理するバックログに対して、稼働時間で課金されるエンジニアリング能力を買います。スコープはあなたのものであり、学びに応じて動いてよい。ベンダーが約束するのは要員の質、稼働、そして働き方であって、固定日程における固定内容ではありません。ドリフトのリスクは発注側にあり、成功は「実際に何がリリースされたか」で測られます。

請負・固定価格（ターンキー型デリバリーとして売られることも多い）

あらかじめ合意した価格で、定義された成果を買います。ベンダーは内容・品質水準・納期にコミットし、署名済みスコープの内側のドリフトリスクを負い、そのリスクを金額に織り込み、変更管理プロセスで自らを守ります。受入基準と裁定は発注側に残ります。ターンキー型はその最も強い形で、手法、チーム構成、デリバリーチェーン全体をベンダーが所有します。

スタッフオーグメンテーション（人員補強）

指名された個人があなたのチームに入り、あなたの管理ラインにレポートします。ベンダーが約束するのは人、交代、そして事務手続きです。作業を指揮するのはあなたであり、バックログ、技術判断、品質基準もあなたのものです。ドリフトのリスクは全面的に発注側にあり、成功は社内採用と同じ基準で測られます。

最初に解いておくべき誤解があります。Time & Material はスタッフオーグメンテーションではありません。両者は時間で課金するという点だけを共有しています。うまく運用された T&M は、自前のリードと自前の開発プラクティス、そしてデリバリーに対する集団的な責任を持ったチームを提供します。スタッフオーグメンテーションが提供するのは個人であり、プラクティスを供給するのは発注側です。後者を売りながら前者の価格を付けるベンダーは存在します。

価格は最初に見るべき基準ではない

人日単価と請負の総額を比べるのは、比較できないもの同士を比べる行為です。請負価格にはリスクプレミアムが含まれます。ベンダーは確実性を売っており、自ら吸収する不確実性に値付けしなければならないからです。スコープが安定していればこのプレミアムは小さく、本物の予見可能性が買えます。スコープが不確実なら大きくなり、可能性は二つに一つです。ベンダーが正直に値付けしていて、最初の方針転換で壊れる確実性に高い金額を払っているか、値付けが甘く、別の通貨で支払うことになるか。誰が実際にアサインされるか、どんな品質が出てくるか、途中での再交渉。

スタッフオーグメンテーションは単価では最も安く見え、実際に安いことが多い。比較表に決して現れないのは、それが発注側に移すマネジメント負荷です。オンボーディング、レビュー、技術的な方向づけ、パフォーマンス管理、そして結果に対する責任。管理ラインにその余力があるなら、節約は本物です。なければ、すでに手一杯のマネージャーに二つ目の職務を買ったことになります。したがって本当の問いは価格ではなく、次の二つです。

基準その一：スコープの不確実性を正直に測る

有効なテストは「仕様書があるか」ではありません。仕様書は誰にでもあります。テストは、受入基準を今日書けるか、そしてそれが半年後にも正しいと認められるか、です。次のいずれかが当てはまるなら、スコープは本当に不確実です。

• 次に何を作るかが、初回リリース後に実ユーザーから学ぶ内容に依存している。
• 重要な上流システムがドキュメント化されていない、または何も約束していない第三者が保有している。
• 業務ルールや規制要件が、作業開始後もまだ決まりつつある。
• 実現可能性の検証そのものが、買おうとしているものの一部である。
• 関係者がまだすべき議論をしておらず、仕様書がそれを覆い隠している。

不確実なスコープと請負の組み合わせは、変更申請の製造装置になります。変更管理を連発するベンダーは非協力的なのではなく、その契約下で唯一合理的な行動をとっているだけです。安定したスコープと Time & Material はその鏡像で、必要のない柔軟性に金を払い、ほぼ無償で得られたはずの予見可能性を手放すことになります。

基準その二：発注側の運営・ピロティング能力

二つ目の変数は発注側にあり、買い手はここを飛ばします。どのモデルも発注側の組織に固有の要求を突きつけます。その要求を満たせないモデルは、ベンダーの質にかかわらず期待を下回ります。

• Time & Material には、実際の裁定権限を持ち毎週稼働できるプロダクトオーナー、誰かが実際に守らせる完了の定義、そして「やめる」と言う意思が要る。
• 請負には、精密に仕様化してその後動かさない能力、受入を真剣に運用する担当者、非公式な依頼を変更管理の外に流さない規律、そして自社側の依存関係を自分で握っていることが要る。
• スタッフオーグメンテーションには、自社の人間ではない要員をオンボードし、レビューし、コーチする管理上の余力、wiki ページ上ではなく実務として存在する技術標準、そして結果を引き受ける社内の当事者が要る。

この二つの基準を掛け合わせれば、多くの判断は自動的に決まります。安定したスコープ×弱い運営能力は請負を指します。動くスコープ×強い運営能力は Time & Material を指します。すでにうまく回っているチームの限定的な穴はスタッフオーグメンテーションを指します。動くスコープ×弱い運営能力が危険な象限です。自前のデリバリーリーダーシップを伴うチームを買うか、契約前に運営の問題を直すか、どちらかにしてください。

請負：正解になるとき、罠になるとき

請負が最も力を発揮するのは、輪郭がはっきりした仕事です。目標状態が判明している移行、ドキュメント化された API に対する連携、内容が外部から規定される規制対応の成果物。ベンダーはリスクを正確に値付けでき、全員が納期を前提に計画できます。

罠になるのは、署名時点でスコープが曖昧だったのに双方がそうでないふりをした場合です。壊れ方は静かです。レポートは緑のまま、会話は「プロダクトに何が必要か」から「数か月前に書かれた一文が何を意味していたか」へ滑っていきます。監視すべき兆候。

• 変更申請が、実際に納品されたスコープより速く増えている。
• 議論が「これはユーザーにとって正しいか」から「これはスコープ内か」に移っている。
• ベンダーの最も強いメンバーが静かに案件から外れていく。
• 受入がテストではなく交渉になっている。
• 正規のルートが遅すぎるため、自社チームが非公式な依頼で契約を迂回している。

Time & Material：正解になるとき、罠になるとき

Time & Material が最も力を発揮するのは、生きているプロダクトです。継続的なディスカバリー、並び替わる優先順位、文脈を蓄積できるだけの期間とどまるチーム。現実と戦うのではなく現実に追随し、方針転換のたびに契約上の通行料を払わずに済みます。

罠になるのは、運営の規律がないときです。誰も嘘をついておらず、仕事は本当に行われており、どの一週間を切り取っても間違って見えません。欠けているのは「これが今できる最も価値の高いことなのか」と問わせる力です。案件は双方にとって心地よい年金のような状態へ漂い、その漂流は累積でしか見えません。監視すべき兆候。

• 今四半期にチームが何を達成しようとしているのかを、一文で言えない。
• ロードマップが、チームがすでにやっていることの説明になっている。
• 案件の要員数が一方向にしか動かない。
• 使わなかった稼働を返した最後の機会を、誰も思い出せない。
• 定例会が意思決定ではなく活動報告のレビューになっている。
• ベンダーから「このタスクはやる価値がない」と言われたことが一度もない。

スタッフオーグメンテーション：正解になるとき、罠になるとき

スタッフオーグメンテーションが最も力を発揮するのは、すでにうまく回っているチームに限定的な穴があるときです。負荷のピーク、ある一つのフェーズに必要な希少スキル、実需に対して遅れている採用パイプライン。プラクティスも標準も責任もすでに存在し、動いている機械に手を足すだけです。

第一の罠は、一時的なものが構造化することです。ピークがベースラインになり、更新が議論されなくなり、恒久的な人員を一時的な契約で抱え、もはや行使していない柔軟性に対して柔軟性プレミアムを払い続けることになります。

第二の罠はあまり語られず、より大きな損害をもたらします。知識移転が逆流するのです。実際に手を動かしているのは外部エンジニアなので、システムの深い運用知識は彼らに蓄積されます。一方で自社の常勤メンバーは調整とチケット整形へ流れていきます。契約が終われば知識も一緒に出ていく。だからこそ契約は終わりません。監視すべき兆候。

• 重要なコンポーネントを理解しているのが、外部の一人だけになっている。
• 自社の常勤エンジニアが、作るより調整に時間を使っている。
• 更新が自動的に行われ、中身が問い直されない。
• 「その人が来月抜けたらどうなるか」への正直な答えが、全員を居心地悪くさせる。
• 外部要員がオンコールを担っているのに、アーキテクチャの意思決定の外にいる。

以上はこのモデルへの反論ではありません。どの能力を恒久的に自社で所有し、どの能力なら借りてよいのかを事前に決め、その線を守るべきだという主張です。

契約前にベンダーへ聞くべきこと

一般的なデューデリジェンスは一般的な答えしか生みません。実際にベンダー間の差が出るのは次の問いです。

請負・ターンキー型

• この価格は何を含み、明示的に含まないものを三つ挙げてください。
• 変更の値付けは誰が、どんな基準で、どれくらいの速さで行いますか。
• 当社側の依存関係が遅延した場合、御社のコミットメントはどうなりますか。
• この提案書を書いた人はデリバリーチームに入りますか。

Time & Material

• このチームを率いるのは誰で、その人は当社に「ノー」と言えますか。
• 作業実績をどう報告し、水増しがあった場合どう検知できますか。
• チームが予定より早く終わったとき、御社は何をしますか。
• どんなときに「これはやめるべきだ」と当社に言いますか。

スタッフオーグメンテーション

• パフォーマンス管理はどちらが行い、難しい会話は誰がしますか。
• 交代のコミットメントは実際に何をカバーしますか。
• 要員が抜けるときの引き継ぎプロトコルは何ですか。
• その人を当社で恒久的に雇用したい場合、どう進みますか。

ハイブリッドと、途中でのモデル変更

実際のプログラムが純粋な単一モデルであることは稀です。請負での要件定義フェーズのあとに Time & Material で構築するやり方は、動くスコープ問題への最も信頼できる回答です。着手前にスコープが判明していたふりを誰もしなくて済むからです。Time & Material のコアチームに請負のサテライトを組み合わせる形も機能しますが、サテライトがコアチームの未決定事項に依存し始めた時点で崩れます。上限付きの Time & Material は、内容を凍結せずに財務へ数字を示せますが、上限に近づいたときに実際にスコープを削る覚悟がある場合に限ります。

切り替えるべき瞬間は、関係がぎくしゃくしたときではなく、前提となる変数が変わったときです。ディスカバリーを経て安定したスコープは、次のブロックから請負に移してよい。探索的だったと判明した請負は、変更申請で押し切るのではなく、いったん止めて組み直すべきです。そしてモデル変更は請求形式の変更ではなく、ガバナンスの出来事です。ベースラインを引き直し、誰が何を決めるのかを言い直し、何を報告するのかを見直す。請求書のフォーマットだけを変えても、何も変わりません。

次の定例で使える意思決定フレーム

四つの問いを、この順番で。順番が重要なのは、それぞれが選択肢を消していくからです。

1. 受入基準を今日書けるか。そしてそれは半年後も正しいか。イエスなら請負は選択肢に残る。ノーなら、財務の好みにかかわらず外す。
2. 実際の権限を持ち、毎週使えるプロダクトオーナーがいるか。いなければまずそこを直す。運営されない Time & Material は三つの中で最も高くつく。
3. 自社の人間ではない要員をオンボードし、レビューし、コーチする余力が、エンジニアリング管理側にあるか。なければ、指揮できない個人を買うことになる。
4. これは長期的に自社で所有すべき能力か、借りてよい能力か。前者は決して借りない。

四つすべてを複数のモデルが生き残るなら、選択は本当に開かれています。価格、立ち上げの速さ、あるいはどのベンダーをより信頼できるかで決めてください。どれも生き残らないなら、問題は契約モデルではありません。そのプログラムはまだ買える状態にない、ということです。署名の前にそう言えることには、署名の後に言うよりはるかに大きな価値があります。

Abbeal は三つとも提供しています。だからこそこの記事は、どれか一つを正解として終わりません。どれもきわめてうまく機能し、どれもひどく失敗します。そして失敗はモデルそのものからはめったに生まれません。スコープの現実、あるいは発注側の実際の運営能力に逆らってモデルを選んだときに生まれます。