こんにちは、ヨクトでシステム開発をしている者です。今日は会社の宣伝……というより、現場でいろいろな契約形態のプロジェクトを回してきた一エンジニアとして、「ラボ型開発って実際どうなの？」を正直に書いてみます。良いところだけでなく、デメリットや向き・不向きもぶっちゃけます。
その前にちょっとだけ自慢を。ヨクトは設立当初（コロナ前）から、ラボ型開発を業界に提案してきました。今でこそ「ラボ型」「ニアショア」という言葉をよく聞きますが、当時はまだ請負がほとんど。「準委任で専任チームを持つ」という形を早くから実践してきた分、おいしいところも、しんどいところも、それなりに見てきたつもりです。
そもそも「請負」と「ラボ型（準委任）」って何が違う？
ラボ型の話に入る前に、契約形態の整理から。システム開発の契約は、ざっくり請負契約と準委任契約の2つに大別できます。ラボ型開発は、このうち準委任をベースにした進め方です。
| 請負契約 | ラボ型（準委任契約） | |
|---|---|---|
| 約束するもの | 成果物の完成 | 一定期間の業務遂行（専任チームの確保） |
| 料金の考え方 | 成果物に対して固定金額 | 人月など工数ベース（月額） |
| 仕様変更 | 苦手（追加見積もりに） | 得意（その都度組み替えられる） |
| 完成責任 | ベンダーが負う | 負わない（善管注意義務） |
| 必要な前提 | 仕様が固まっていること | 発注側も一緒に進める体制 |
ものすごく雑にまとめると、請負は「決めたものを、決めた金額で作りきる」。ラボ型は「優秀な開発チームに、好きな要件を投げまくって、一緒に創っていく」イメージ。この“一緒に創る楽しさ”こそ、ラボのいちばんの醍醐味だと思っています。
進め方の特徴と、ぶっちゃけ注意点
請負の進み方
最初に仕様をきっちり固めて、あとはベンダーが完成まで持っていきます。発注側は要所のレビューが中心で、予算と納期が読みやすいのが最大の安心ポイント。
ただし――途中で「やっぱりここ変えたい」が出ると、途端にしんどくなります。追加見積もり・スケジュール調整でピリピリしがち。仕様変更が多い案件だと、正直あまり幸せになれません。
ラボ型の進み方
専任チームを一定期間確保して、優先度の高いものから順に作っていきます。週次などで状況を共有し、「来週はこっちを優先で」が普通に通るのが気持ちいいところ。動くものを見ながら方向を微調整できる、アジャイル的な進め方です。
「ラボ型って発注側の負担が大きいのでは？」とよく聞かれます。でも、ここがヨクトの一番の特徴で、「次に何をすべきか」を一緒に考えていきます。だから発注側がすべてを引っ張る必要はありません。言われたものをただ作るだけの他社やオフショアのラボとは、正直ここが大きく違うところ。気軽に相談できる開発チームが社内に増える、くらいの感覚で大丈夫です。
メリット・デメリットを正直に
ラボ型のメリット
- 仕様変更・優先度変更に強い。要件がガチガチに固まっていなくても始められる
- 同じチームが継続するのでナレッジが溜まる（毎回ゼロから説明しなくていい）
- コミュニケーションが密で、意思決定が速い
- 必要な期間・工数だけ確保できる
ラボ型のデメリット（ここ大事）
- 進む方向は発注側と一緒に決めていく（とはいえ“次の一手”はヨクトから提案するので、二人三脚で進められます）
- 契約上「完成」を約束しないので、進め方しだいで結果が変わる
……と、デメリットも正直に書きましたが、要は「一緒に走る相手として信頼できるか」が肝。ここは私たちも襟を正して取り組んでいます。
で、結局どっちを選べばいいの？
| こんなときは… | 向いている契約 |
|---|---|
| 仕様が明確・スコープ固定。 | 請負 |
| 成果物責任がどうしても必要。予算追加もOK！ | 請負 |
| 要件がまだ流動的／作りながら決めたい | ラボ型 |
| 継続的に改善・追加していきたい（新規事業・自社プロダクト） | ラボ型 |
| 長く付き合える開発チームが欲しい | ラボ型 |
| PoC・試作で、まず動かして仮説を確かめたい | ラボ型 |
……と、きれいに表にしてはみたものの。正直なところ、現場でずっと感じているのはこういうことです。「要件はもう固まっている」と思っている案件ほど、実は油断できない。システムって、形のない“頭の中の想像”を相手にする仕事なんですよね。だから発注の時点で細部まで決めきるのは、現実にはかなり難しい。図や仕様書の上では合意できていても、いざ動くものに触ると「あれ、ここ思ってたのと違う」が、ほぼ必ず出てきます。これは誰が悪いわけでもなく、無形のものを扱う以上ある意味当たり前のことだったりします。
なので、たとえ固まっているように見える案件でも、序盤は動くものを見ながら確かめられる進め方にしておくと、後半の「言った・言わない」や手戻りがぐっと減ります。とくに PoC（試作して仮説を検証する）のような“まだ答えが分からない”フェーズは、作り切る前提よりも、試しながら確かめられる進め方のほうが圧倒的に噛み合います。
実例で見る「おいしい話」と「しんどい話」
ここまで一般論を書いてきましたが、やっぱり具体例が一番イメージしやすいですよね。守秘の都合でぼかしていますが、私たちが見てきた“あるある”を、ラボ・請負それぞれ「うまくいった例／しんどかった例」として正直に挙げてみます。
ラボ型のケース
😊 うまくいった例
開発の途中で「Webで作っていたけど、やっぱりスマホアプリにしたい」という大きな方針転換が発生。ラボ型だったので慌てず柔軟に作り直し、結果として現場の利用者の満足度がとても高いものに仕上がりました。余談ですが、担当してくださったクライアントのご担当者さんがその後社内で昇進されたと聞いて、こちらまで嬉しくなりました。
😥 しんどかった例
リリース直前に、キーマンだったクライアントのご担当者さんが退社。引き継いだ新しい方の方針がそれまでと大きく異なり、方向性の再調整に苦労しました。（これはラボに限らず起こり得ますが、“決める人”が変わるとインパクトが大きい、という教訓です。）
正直なところ、別の案件ではこちらのメンバーとご担当者さんの相性がいまひとつで、途中でチーム側の担当を変更したこともあります。唯一のケースではありますが、二人三脚で走るラボ型だからこそ、“人と人の相性”も大事だと痛感した出来事でした。
請負のケース
😊 うまくいった例
発注元にシステムの知見が高いご担当者がいて、整理された美しいRFP（提案依頼書）が用意されていたケース。途中の要件変更も「ここを足すなら、ここは削る」とトレードオフで冷静に判断してくださり、スムーズにリリース。現場の満足度も高い、理想的な請負でした。
😥 しんどかった例
これぞ“あるある”。要件定義の段階で追加したい機能が止まらず、何を入れて何を見送るかの取捨選択に時間がかかり……結果として開発期間も予算も大幅にオーバー。固定価格の請負だっただけに、調整が苦しい展開になりました。
こうして並べてみると、見えてくることがあります。――急がば回れ、なんですよね。あくまでケースバイケースが大前提ですが、個人的な実感として、最終的な完成度も高く、トータルで見ると安く収まることが多いのはラボ型のほうだったりします。「あとから変えられる」前提で進めるぶん、大きな手戻りやムダな作り込みが減るからだと思います。
個人的おすすめ：1つの案件で「契約を分ける」
ここがいちばん伝えたいところ。実は1つのプロジェクトの中で、フェーズごとに契約形態を分けるのがかなり有効です。
たとえば――要件定義やPoCフェーズは準委任（ラボ型）で、一緒に「何を作るか」を探りながら固める。仕様がしっかり見えてきたら、その先の開発フェーズは請負に切り替えて金額と納期を確定させる。こうすると、「要件が曖昧なまま請負で見積もって、あとで揉める」という典型的な失敗をかなり避けられます。
「要件定義は準委任、開発は請負」という分け方は、経済産業省やIPAのモデル契約でも示されている考え方です。ふわっとした段階を無理に固定価格で縛らないのがコツ。
もちろん「最初から最後までラボ型で並走」も、改善が続くプロダクトには最適です。大事なのは“契約形態ありき”で決めないこと。プロジェクトの状態に合わせて柔軟に組むのが、結局いちばん上手くいきます。
まとめ
ラボ型は万能ではないし、請負がダメなわけでもありません。プロジェクトの「不確実さ」と「変化のしやすさ」に合わせて選ぶのが正解です。とはいえ――形のないものを作る以上、最初から最後まで完璧に固めきれる案件は、思っているより少ないのも本音のところ。だからこそ、迷ったら「まず確かめながら進める」余地を残しておくと、たいてい上手くいきます。ヨクトはコロナ前からラボ型開発を提案してきた経験があるからこそ、「ここは請負、ここはラボ」といった現実的な組み方まで含めてご提案できます。契約形態で迷ったら、気軽に相談してもらえたら嬉しいです。