ラボ型開発は人月調達ではない
「3名のラボを作ったのに、半年たっても結局、日本側PMが全部巻き取っている」
ラボ型開発でよくある失敗です。
開発者はいる。
毎月の費用も払っている。
タスクも振っている。
それなのに、なぜか楽にならない。
仕様確認は日本側に戻ってくる。
レビューも日本側で詰まる。
優先順位の判断も日本側で止まる。
結局、外部チームは指示待ちになり、日本側PMだけが忙しくなる。
この状態になると、経営者や責任者はこう考えます。
「やはりオフショアは難しい」
「ラボ型はうちには合わない」
「海外チームに任せるのは無理だった」
しかし、本当の原因は別にあります。
多くの場合、失敗したのはラボ型開発そのものではありません。
ラボ型開発を人月調達として使ったことです。
「とりあえず、開発者を2〜3名確保したい」
ラボ型開発の相談で、よく聞く言葉です。
気持ちは分かります。
社内では採用できない。
国内ベンダーは高い。
既存メンバーは保守で手一杯。
新しい開発テーマはあるのに、動かせる人がいない。
だから、外部に開発リソースを持ちたい。
しかし、この発想のままラボ型開発を始めると、たいてい失敗します。
理由は単純です。
人を増やしても、開発力が増えるとは限らないからです。
仕様を決める人がいない。
優先順位を判断する人がいない。
レビューする人がいない。
業務背景を伝える人がいない。
この状態で外部エンジニアを増やしても、増えるのは開発力ではありません。
増えるのは、指示待ちと手戻りです。
目次
ラボ型開発で本当に買っているもの
ラボ型開発というと、エンジニアを月単位で確保する契約だと思われがちです。
もちろん、契約上はそう見えます。
しかし、実際に価値が出るのは「人を確保した瞬間」ではありません。
価値が出るのは、そのチームが自社の業務、システム、品質基準、判断基準を理解し始めてからです。
つまり、ラボ型開発で本当に買っているのは、人月ではありません。
学習曲線です。
最初は説明が必要です。
最初はレビューも多くなります。
最初は認識違いも起きます。
それでも、同じチームと継続して改善していくことで、少しずつ前提が揃っていきます。
「あの機能は以前も触った」
「この画面は業務上重要」
「この処理は影響範囲が広い」
「この会社では、この粒度で報告すべき」
こうした知識がチームに蓄積されることで、ようやく外部チームが戦力になります。
ラボ型開発の価値は、安く人を借りることではありません。
自社のことを理解した外部チームを育てられることです。
失敗する会社は、最初から「完成品のチーム」を求める
ラボ型開発で失敗する会社には、共通点があります。
最初から、完成されたチームを期待していることです。
依頼したその日から、
すぐに仕様を理解し、
すぐに動き、
すぐに品質高く作り、
すぐに日本側の暗黙知まで読み取ってくれる。
そんなことは起きません。
国内の新入社員や中途社員でも、会社の業務を理解するには時間がかかります。
それなのに、海外の外部チームには、最初から即戦力以上の動きを期待してしまう。
これはかなり都合のいい期待です。
ラボ型開発は、完成品を買う契約ではありません。
育てる前提で使う契約です。
「丸投げできる」と思った瞬間に失敗する
ラボ型開発で一番危険なのは、丸投げです。
「開発チームを確保したので、あとは任せれば進む」
そう考えると、ほぼ間違いなく詰まります。
なぜなら、開発で詰まるのは、コードを書く部分だけではないからです。
実際に詰まるのは、もっと手前です。
何を優先するのか。
なぜその機能が必要なのか。
どこまで品質を求めるのか。
何をもって完了とするのか。
既存仕様と違った場合、どちらを正とするのか。
ここを判断するのは、外部チームではありません。
自社側です。
この判断を放棄したまま外部チームを増やしても、開発は進みません。
むしろ、質問が増え、確認が増え、手戻りが増えます。
ラボ型開発は、日本側の仕事をなくすものではありません。
日本側の仕事を「作業」から「判断」に変えるものです。
育たないラボに共通すること
うまくいかないラボ型開発には、だいたい次のような特徴があります。
- タスクだけ渡して、背景を共有しない
- 質問への回答が遅い
- レビュー担当が決まっていない
- 優先順位が毎回変わる
- 完了基準が曖昧
- チームを頻繁に入れ替える
- 失敗を振り返らない
- 「言わなくても分かるはず」と考える
これでは、チームは育ちません。
単発の作業者として使われ続けるだけです。
逆に、育つラボには共通点があります。
- なぜ作るのかを共有している
- 小さく任せて、結果を振り返っている
- レビューの基準がある
- 判断者が明確
- ドキュメントやナレッジを残している
- 同じチームに継続して任せている
- 開発側から提案できる余地がある
この差は大きいです。
同じ人数でも、半年後の成果はまったく変わります。
ラボ型開発は、第二開発部門を作る感覚に近い
ラボ型開発をうまく使う企業は、外部チームを単なる外注先として扱いません。
自社の第二開発部門に近い存在として扱います。
もちろん、完全な内製チームとは違います。
雇用関係も違えば、距離もあります。
文化も違います。
言語の壁もあります。
それでも、継続的に成果を出すには、外注先ではなくチームとして扱う必要があります。
チームとして扱うとは、甘やかすことではありません。
期待値を明確にする。
必要な情報を渡す。
品質基準を共有する。
レビューする。
改善点を伝える。
良い動きは継続させる。
この積み重ねによって、外部チームは徐々に戦力になります。
ラボ型開発で成果を出す会社は、最初から楽をしようとしていません。
最初にきちんと関与し、後から楽になる構造を作っています。
AI時代でも、チームを育てる価値はなくならない
AIによって、コード生成、テスト作成、ドキュメント作成、影響範囲調査は以前より速くなりました。
これは、ラボ型開発にも大きな影響があります。
特に、既存システムの保守や継続開発では、AIを使うことで次のような作業を効率化できます。
- ソースコードの構造理解
- 処理内容の説明
- 影響範囲の調査補助
- テストケース作成
- ドキュメント作成補助
- コードレビュー支援
ただし、AIがあるからチームが不要になるわけではありません。
むしろ逆です。
AIを使って出てきた情報をどう判断するか。
業務上の影響をどう見るか。
どこまで本番に反映してよいか。
どの品質基準でレビューするか。
ここには、人間の判断が必要です。
AI時代のラボ型開発で重要なのは、単に安い開発者を集めることではありません。
AIを使いながら、業務を理解し、判断できるチームを育てることです。
スマラボが考えるラボ型開発
スマラボでは、ラボ型開発を「安い外注先を確保する方法」とは考えていません。
継続的に改善を進めるための外部開発チームを作る取り組みだと考えています。
そのため、重視しているのは次の3つです。
1. 日本側PM・SEによる並走
海外チームにそのまま要件を投げるのではなく、日本側で業務理解、要件整理、品質確認、コミュニケーションを支援します。
単なる通訳ではなく、業務と開発の間に立ち、チームが正しく動けるように支援する役割が必要です。
2. 小さく始める
最初から大きな体制を作るのではなく、コード調査、ドキュメント整備、小規模改修、テスト作成など、リスクの低い領域から始めます。
小さく始めることで、品質・スピード・コミュニケーションを確認しながら、段階的に任せる範囲を広げることができます。
3. 継続開発チームとして育てる
単発の開発で終わらせるのではなく、保守・追加開発・品質改善を継続的に進められる体制づくりを重視しています。
最初は小さな作業から始まっても、業務理解が深まれば、任せられる範囲は広がります。
まとめ：人を借りるのではなく、チームを育てる
ラボ型開発は、人月を安く買うための仕組みではありません。
自社の開発力を外部に拡張するための仕組みです。
そのためには、外部チームを単なる作業者として扱うのではなく、継続的に学習し、改善できるチームとして育てる必要があります。
重要なのは、次の点です。
- 人を増やしても、開発力が増えるとは限らない
- ラボ型開発で価値が出るのは、チームに知識が蓄積されてから
- 丸投げではなく、日本側の判断とレビューが必要
- 小さく始めて、段階的に任せる範囲を広げる
- AIはチームの立ち上がりを助けるが、判断までは代替しない
ラボ型開発は、安い外注ではありません。
育てるチームです。
この前提を持てる企業ほど、ラボ型開発を単なるコスト削減ではなく、継続的な開発力として活用できます。