ラボ型開発は人月調達ではない｜失敗する会社の共通点

「3名のラボを作ったのに、半年たっても結局、日本側PMが全部巻き取っている」

ラボ型開発でよくある失敗です。

開発者はいる。毎月の費用も払っている。タスクも振っている。それなのに、なぜか楽にならない。

仕様確認は日本側に戻ってくる。レビューも日本側で詰まる。優先順位の判断も日本側で止まる。結局、外部チームは指示待ちになり、日本側PMだけが忙しくなる。

この状態になると、経営者や責任者はこう考えます。

「やはりオフショアは難しい」
「ラボ型はうちには合わない」
「海外チームに任せるのは無理だった」

しかし、本当の原因は別にあります。多くの場合、失敗したのはラボ型開発そのものではありません。

ラボ型開発を人月調達として使ったことが、失敗の本質です。

「とりあえず、開発者を2〜3名確保したい」

ラボ型開発の相談で、よく聞く言葉です。気持ちは分かります。

社内では採用できない。国内ベンダーは高い。既存メンバーは保守で手一杯。新しい開発テーマはあるのに、動かせる人がいない。だから、外部に開発リソースを持ちたい。

しかし、この発想のままラボ型開発を始めると、たいてい失敗します。理由は単純です。

人を増やしても、開発力が増えるとは限らないからです。

仕様を決める人がいない。優先順位を判断する人がいない。レビューする人がいない。業務背景を伝える人がいない。この状態で外部エンジニアを増やしても、増えるのは開発力ではありません。増えるのは、指示待ちと手戻りです。

ラボ型開発で本当に買っているもの

ラボ型開発というと、エンジニアを月単位で確保する契約だと思われがちです。もちろん、契約上はそう見えます。しかし、実際に価値が出るのは「人を確保した瞬間」ではありません。

価値が出るのは、そのチームが自社の業務、システム、品質基準、判断基準を理解し始めてからです。つまり、ラボ型開発で本当に買っているのは、人月ではありません。

学習曲線を買っているのです。

最初は説明が必要です。最初はレビューも多くなります。最初は認識違いも起きます。それでも、同じチームと継続して改善していくことで、少しずつ前提が揃っていきます。

「あの機能は以前も触った」
「この画面は業務上重要」
「この処理は影響範囲が広い」
「この会社では、この粒度で報告すべき」

こうした知識がチームに蓄積されることで、ようやく外部チームが戦力になります。ラボ型開発の価値は、安く人を借りることではありません。

自社のことを理解した外部チームを育てられることにあります。

失敗する会社は、最初から「完成品のチーム」を求める

ラボ型開発で失敗する会社には、共通点があります。最初から、完成されたチームを期待していることです。

依頼したその日から、すぐに仕様を理解し、すぐに動き、すぐに品質高く作り、すぐに日本側の暗黙知まで読み取ってくれる。

そんなことは起きません。国内の新入社員や中途社員でも、会社の業務を理解するには時間がかかります。それなのに、海外の外部チームには、最初から即戦力以上の動きを期待してしまう。これはかなり都合のいい期待です。

ラボ型開発は、完成品を買う契約ではありません。育てる前提で使う契約です。

「丸投げできる」と思った瞬間に失敗する

ラボ型開発で一番危険なのは、丸投げです。

「開発チームを確保したので、あとは任せれば進む」

そう考えると、ほぼ間違いなく詰まります。なぜなら、開発で詰まるのは、コードを書く部分だけではないからです。実際に詰まるのは、もっと手前です。

• 何を優先するのか
• なぜその機能が必要なのか
• どこまで品質を求めるのか
• 何をもって完了とするのか
• 既存仕様と違った場合、どちらを正とするのか

ここを判断するのは、外部チームではありません。自社側です。この判断を放棄したまま外部チームを増やしても、開発は進みません。むしろ、質問が増え、確認が増え、手戻りが増えます。

ラボ型開発は、日本側の仕事を「作業」から「判断」に変えるものです。

育たないラボに共通すること

うまくいかないラボ型開発には、だいたい次のような特徴があります。逆に、育つラボにも共通点があります。

この差は大きいです。同じ人数でも、半年後の成果はまったく変わります。

ラボ型開発は、第二開発部門を作る感覚に近い

ラボ型開発をうまく使う企業は、外部チームを単なる外注先として扱いません。自社の第二開発部門に近い存在として扱います。

もちろん、完全な内製チームとは違います。雇用関係も違えば、距離もあります。文化も違います。言語の壁もあります。それでも、継続的に成果を出すには、外注先ではなくチームとして扱う必要があります。

チームとして扱うとは、甘やかすことではありません。期待値を明確にする。必要な情報を渡す。品質基準を共有する。レビューする。改善点を伝える。良い動きは継続させる。

この積み重ねによって、外部チームは徐々に戦力になります。ラボ型開発で成果を出す会社は、最初から楽をしようとしていません。最初にきちんと関与し、後から楽になる構造を作っています。

AI時代でも、チームを育てる価値はなくならない

AIによって、コード生成、テスト作成、ドキュメント作成、影響範囲調査は以前より速くなりました。これは、ラボ型開発にも大きな影響があります。

特に、既存システムの保守や継続開発では、AIを使うことで次のような作業を効率化できます。

• ソースコードの構造理解
• 処理内容の説明
• 影響範囲の調査補助
• テストケース作成
• ドキュメント作成補助
• コードレビュー支援

ただし、AIがあるからチームが不要になるわけではありません。むしろ逆です。

• AIを使って出てきた情報をどう判断するか
• 業務上の影響をどう見るか
• どこまで本番に反映してよいか
• どの品質基準でレビューするか

ここには、人間の判断が必要です。AI時代のラボ型開発で重要なのは、単に安い開発者を集めることではありません。AIを使いながら、業務を理解し、判断できるチームを育てることです。

スマラボが考えるラボ型開発

スマラボでは、ラボ型開発を「安い外注先を確保する方法」とは考えていません。継続的に改善を進めるための外部開発チームを作る取り組みだと考えています。そのため、重視しているのは次の3つです。

まとめ：人を借りるのではなく、チームを育てる

ラボ型開発は、人月を安く買うための仕組みではありません。自社の開発力を外部に拡張するための仕組みです。

そのためには、外部チームを単なる作業者として扱うのではなく、継続的に学習し、改善できるチームとして育てる必要があります。重要なのは、次の点です。

ラボ型開発は、安い外注ではありません。育てるチームです。

この前提を持てる企業ほど、ラボ型開発を単なるコスト削減ではなく、継続的な開発力として活用できます。