ラボ型開発で発注企業側に必要な役割とは？丸投げを防ぐ社内体制の作り方

ラボ型開発では、一定期間、自社専属の外部開発チームを確保します。仕様変更や優先順位の入れ替えに対応しやすく、継続的な開発や保守に適した手法です。

一方、「専属チームを契約すれば、自社の負担がなくなる」と考えて導入すると、期待した成果が得られないことがあります。

外部チームは、事業上の優先順位や社内事情を自動的に判断できません。発注企業側で意思決定が止まれば、エンジニアが確保されていても開発は進みません。依頼内容が曖昧なままでは、手戻りや確認も増えます。

ラボ型開発を成功させるには、開発会社側の人数やスキルだけでなく、発注企業側の体制を設計することが重要です。

本記事では、発注企業側に必要な5つの役割と、複数の役割を少人数で運営する方法を解説します。

ラボ型開発は業務の丸投げではない

受託開発では、事前に決めた要件や成果物に基づいて開発を依頼するのが一般的です。これに対し、ラボ型開発では一定期間チームを確保し、その期間内で開発する内容や優先順位を調整します。

柔軟性が高い一方、発注企業側には継続的な判断が必要です。

• 次に何を開発するか
• どの課題を優先するか
• 仕様変更を認めるか
• 成果物を受け入れてよいか
• 品質や速度をどう改善するか

これらを委託先へ任せきると、開発会社は判断材料を持たないまま作業することになります。結果として、細かな指示を待つだけのチームになったり、事業の意図と異なるものを作ったりします。

「外部の開発会社」ではなく「第二の開発チーム」として活用するには、自社側にもチームを動かす役割が必要です。

役割1：事業責任者・プロダクトオーナー

最初に必要なのは、何をなぜ作るのかを決める役割です。

事業責任者やプロダクトオーナーは、顧客や利用部門の要望をそのまま開発チームへ流すのではなく、事業への効果を踏まえて優先順位を決定します。

主な責任は次のとおりです。

• 開発の目的を示す
• 要望の優先順位を決める
• 予算や期限に関する判断を行う
• 仕様変更の事業上の妥当性を判断する
• 完成した機能が目的を満たしているか確認する

この役割が曖昧だと、複数部門から異なる依頼が届き、外部チームが混乱します。会議の参加者が多くても、最終決定者がいなければ開発は進みません。

役割2：業務知識の提供者

開発対象の業務を理解し、現場のルールや例外を説明する役割も必要です。

仕様書に基本的な処理が書かれていても、実際の業務には、特定顧客だけに適用する条件、繁忙期の運用、障害時の代替手順など、多くの例外があります。

業務知識の提供者は、次のような質問に答えます。

• 現在はどのような手順で処理しているか
• なぜそのルールが必要なのか
• 例外時には誰が何を判断するか
• 変更によって影響を受ける部門はどこか
• テストで確認すべき実際の利用パターンは何か

業務知識を一人に依存させると、その担当者が忙しいだけで開発が止まります。主担当と副担当を決め、質問と回答を記録として残す運用が有効です。

役割3：開発窓口・プロジェクト推進担当

日々の連絡やタスク管理を担う窓口も必要です。

発注企業側の窓口は、すべての技術的な答えを持つ必要はありません。重要なのは、質問を適切な担当者へつなぎ、回答期限を管理し、優先順位がぶれないようにすることです。

主な業務には次のものがあります。

• バックログや依頼内容の整理
• 外部チームからの質問の振り分け
• 会議の設定と決定事項の記録
• 社内レビューの進捗管理
• リスクや遅延のエスカレーション
• 次回開発項目の準備

窓口が複数いる場合は、誰の指示を正式なものとするか決めます。チャットで異なる指示が出ると、手戻りの原因になります。

役割4：技術判断・アーキテクチャ責任者

既存システムとの接続、セキュリティ、性能、運用方法など、技術的な判断を行う役割です。

社内に高度な技術者が常駐している必要はありません。ただし、外部チームから提示された選択肢を確認し、自社の制約に合うか判断する責任は必要です。

• 使用技術や構成の承認
• 社内標準・セキュリティ基準との整合確認
• 既存システムへの影響判断
• 技術的負債を許容するかの判断
• 障害や重大な品質問題への対応方針

この役割を社内で確保できない場合は、日本側のディレクターやPM、外部の技術責任者による支援を体制に含めます。ただし、最終的なリスク受容は発注企業側で行います。

役割5：レビュー・受入責任者

成果物が要件や業務目的を満たしているか確認し、本番反映を承認する役割です。

開発会社がテストを実施していても、業務として正しいかを最終判断できるのは発注企業です。開発完了後に初めて確認すると、大きな手戻りにつながります。

そこで、開発開始前に次の内容を決めます。

• 何をもって完了とするか
• 誰がレビューするか
• 何営業日以内に回答するか
• どの環境で受入テストを行うか
• 不具合と仕様変更をどう区別するか
• 本番リリースを誰が承認するか

受入責任者の予定を開発計画に組み込むことで、「開発は終わったのに社内確認で止まっている」という状態を防げます。

5人を用意する必要はない

5つの役割を紹介しましたが、それぞれに専任者を置く必要はありません。小規模なプロジェクトでは、一人が複数の役割を兼務できます。

たとえば、次のような構成です。

• 事業責任者：優先順位と予算の判断
• 社内PM：業務知識の整理、窓口、受入管理を兼務
• 日本側ディレクター：技術判断と開発チーム管理を支援
• ベトナム開発チーム：設計、実装、テスト、調査を担当

重要なのは人数ではなく、5つの責任に空白がないことです。体制図に担当者名を書き、兼務している役割を確認すると、抜け漏れを見つけやすくなります。

発注側の負担が集中しているときの対処法

ラボ型開発を始めた後、社内担当者だけが忙しくなるケースがあります。外部チームからの質問、レビュー、社内調整が一人に集中するためです。

この場合、単純に外部エンジニアを増やしても改善しません。待機する人数が増えるだけです。

まず、質問を次のように分類します。

1. 業務上の判断が必要な質問
2. 過去の仕様を確認する質問
3. 技術的な選択に関する質問
4. 作業手順や環境に関する質問

繰り返し発生する質問は、判断基準やFAQとして記録します。技術的な質問は日本側ディレクターが一次対応し、事業判断だけを社内責任者へ集約する方法もあります。

外部チームが経験を積み、過去の判断を参照できるようになれば、確認の回数は徐々に減ります。

会議体は目的別に分ける

すべての話題を一つの定例会議で扱うと、参加者が増え、意思決定が遅くなります。会議は目的別に設計します。

会議を増やすことが目的ではありません。誰が、何を、いつ決めるかを明確にすることが目的です。

導入前に確認したいチェック項目

ラボ型開発を始める前に、次の項目を確認してください。

• 開発の優先順位を決める人がいる
• 業務上の質問へ回答できる人がいる
• 外部チームとの正式な窓口が決まっている
• 技術的な判断方法が決まっている
• レビューと受入の担当者・期限が決まっている
• 決定事項を記録する場所が決まっている
• 問題発生時のエスカレーション先が決まっている

不足する役割がある場合は、開発会社へ相談する段階で共有します。日本側PMやディレクターを含めた体制を提案してもらうことで、実装者だけを確保するより現実的な計画になります。

まとめ

ラボ型開発は、外部に業務を丸投げする契約ではありません。外部チームを継続的な戦力にするには、発注企業側にも次の役割が必要です。

一人が複数の役割を兼務しても問題ありません。ただし、担当者が決まっていない責任を残さないことが重要です。