スクラム開発を外注するときのおすすめ役割分担｜PO・SMをどちらが持つか

アジャイル開発、特にスクラムを外部のパートナー企業に依頼する際、最も多くの企業が頭を悩ませるのが「誰がどの役割を担うか」という問題です。「開発はプロに任せたいが、プロダクトの方向性は自社でコントロールしたい」「しかし、自社にスクラムの経験者がいない」というジレンマは、多くの新規事業現場で発生しています。

結論から申し上げれば、「プロダクトオーナー（PO）は自社、スクラムマスター（SM）は外注（またはプロの伴走）」という構成が、最も成功率が高い黄金比です。なぜなら、事業の「価値」を定義できるのは、その事業の責任を持つあなた自身しかいないからです。

本記事では、スクラムガイドの原則に基づきつつ、日本国内の外注実務に即した「現実的な役割分担」と、具体的な運用ツール、セキュリティ上の注意点までを徹底解説します。

1. スクラムの基本3役割と「外注時」の現実的な境界線

スクラムガイドでは、チームを「プロダクトオーナー」「スクラムマスター」「開発者」の3つの役割で定義しています。外注という形態をとる場合、これらの境界線が曖昧になりがちです。

1.1 プロダクトオーナー（PO）の責務と外注の可否

POの主な責任は「プロダクトの価値を最大化すること」です。具体的には、プロダクトバックログ（開発項目のリスト）の優先順位を決定し、何を「作らないか」を決める権限を持ちます。

外注の可否： 原則として外注すべきではありません。
外部ベンダーにPOを丸投げすると、ベンダー側は「自社の利益（工数を増やすこと）」と「プロダクトの価値（最小の工数で最大の成果を出すこと）」の板挟みになり、利益相反が発生しやすくなります。たとえ専門知識が不足していても、意思決定の最終権限は自社が持つべきです。

1.2 スクラムマスター（SM）の責務と外注のメリット

SMは、スクラムのフレームワークが正しく機能するよう支援する「サーバントリーダー」です。チームの障害を取り除き、円滑なコミュニケーションを促進します。

外注の可否： 外注（または外部コンサル）の活用を強く推奨します。
スクラム未経験の自社担当者がSMを兼務すると、既存の社内政治や上下関係を持ち込んでしまい、スクラム本来の柔軟性が失われるケースが多いからです。外部のプロがSMを担うことで、客観的な視点からチームのボトルネックを指摘できます。

1.3 開発チーム（Developers）の構成

設計、実装、テストを担う実務部隊です。外注の場合、ここがベンダー側のエンジニアで構成されます。重要なのは、開発チームが「言われたことをやるだけ」の作業員にならないよう、POが常に「なぜこれを作るのか」という背景を共有し続けることです。

2. POとSMの配置パターン別：メリット・デメリット比較

プロジェクトの状況に応じて、いくつかの構成パターンが考えられます。それぞれの特性を理解し、自社の体制に合ったものを選定しましょう。

もし自社のリソース不足でパターンCを選ばざるを得ない場合でも、少なくとも「プロダクトの最終承認権」だけは自社に残すよう、契約・運用設計を行う必要があります。これは、社内の基幹システムを刷新するような大規模DXプロジェクトでも同様です。

例えば、経理部門のDXにおいて freee会計導入マニュアル｜旧ソフト移行ガイド で解説しているような、業務プロセスの抜本的な見直しが伴う場合、外部ベンダーだけでは「現場の使い勝手」を判断しきれないためです。

3. 失敗しないための「役割分担表」とツール選定

スクラムを外注する際、口頭の約束だけで進めると必ず「言った・言わない」のトラブルが発生します。実務に入る前に、タスク管理ツール上での権限と役割を明確にしましょう。

3.1 意思決定と実務のRACIマトリクス

RACI（レイシー）とは、実行責任者（Responsible）、説明責任者（Accountable）、協議先（Consulted）、報告先（Informed）を定義するフレームワークです。

• プロダクトバックログの優先順位： A=自社PO、R=自社PO / 外注SM
• 実装内容の確定（Acceptance Criteria）： A=自社PO、R=外注開発チーム
• 開発プロセスの改善： A=外注SM、R=チーム全員

3.2 スクラム運営に必須のツール比較

スクラム開発では、透明性を確保するために共通のタスク管理ツールが不可欠です。以下は、多くの現場で導入されているツールの特徴です。

特に、SaaSを複数組み合わせて構築するモダンな開発環境では、アカウント管理の不備がセキュリティリスクに直結します。開発を外注する際は、SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ で紹介しているような、ID管理の仕組みを検討しておくべきです。

4. 【実務手順】外注スクラムを立ち上げる5ステップ

契約締結後、スムーズにスプリントを開始するための手順を解説します。

Step 1：インセプションデッキの作成

「なぜこのプロダクトを作るのか」「我々はどこを目指しているのか」というビジョンをチーム全員で共有します。外注ベンダーが単なる「下請け」ではなく「パートナー」として機能するための最重要工程です。

Step 2：バックログの優先順位付けと定義

PO（自社）が、ビジネスインパクトの大きい順に機能を並べ替えます。この際、各項目の「完了定義（DoD）」をベンダーと合意しておくことで、納品後の「思っていたのと違う」を防げます。

Step 3：コミュニケーションパスの確立

SlackやMicrosoft Teamsで、以下のチャンネルを作成します。

• #project-announcement: 重要な決定事項のみ流す場所
• #dev-technical: エンジニア同士の技術的なやり取り
• #ask-po: 開発チームからPOへの仕様確認

Step 4：権限管理とセキュリティ設定

外部パートナーにGitHubのソースコードやAWS環境のアクセス権を付与する際は、必ず「最小権限の原則」を守ります。また、開発環境にはダミーデータを使用し、本番の顧客情報にはアクセスさせない設計が必須です。

顧客データを活用したマーケティング基盤の構築など、機密性の高い情報を扱う場合は、WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ にあるような、セキュアなデータ設計を先行して行う必要があります。

Step 5：スプリント0（環境構築とルール合意）

最初からフルスピードで開発を始めるのではなく、最初の1〜2週間は「開発環境の構築」や「デプロイフローの確認」に充てます。ここで外注チームの「実力」と「癖」を把握し、必要なら役割分担を微調整します。

5. 外注スクラムでよくあるトラブルと対処法

よくあるエラー：POが忙しすぎて要件が決まらない

対処法： POの時間をブロックするか、POをサポートする「プロダクトオーナー代理（POA）」を自社内に配置します。意思決定はPOが行いますが、バックログの整理やドキュメント化をPOAがサポートすることで停滞を防げます。

よくあるエラー：SMがただの進捗報告係になっている

対処法： 外部SMに対して、「チームの生産性向上」をKPIに設定します。デイリースクラムが単なる報告会になっていないか、レトロスペクティブ（ふり返り）で具体的な改善アクションが出ているかをチェックしてください。

よくあるエラー：開発チームが仕様通りにしか作らない

対処法： 開発チームにビジネスサイドの定例（ユーザーインタビューの録画視聴など）に参加してもらい、「誰のどんな課題を解決しているか」を肌で感じてもらう機会を作ります。スクラムの醍醐味は、エンジニアからの「こうした方が使いやすいのでは？」という提案にあります。

まとめ：事業価値を最大化する「伴走型」の役割分担を目指して

スクラム開発を外注する際、最も避けるべきは「役割の丸投げ」です。特にプロダクトオーナー（PO）は、事業の魂を握る役割であり、自社が責任を持って担うことが、最終的なプロダクトの品質を左右します。

一方で、スクラムマスター（SM）や開発チームにはプロの知見を借り、透明性の高いツール運用と適切な権限管理を行うことで、外部パートナーを「強力なエンジン」として活用することが可能になります。

本ガイドで示した構成をベースに、まずは小規模なスプリントから開始し、チームの成熟度に合わせて役割の重なりを調整していってください。成功への近道は、ドキュメントに頼り切るウォーターフォール的な思考を捨て、対話と改善を繰り返すスクラムの原則に、自ら深く飛び込むことです。