内製化が止まる原因は技術ではなく「決め方」にある

内村：本日はスクラム未経験チームから始める内製開発と題しまして、私が携わった内製化プロジェクトで「内製化が止まる瞬間」をどう紐解いたかについてお話しさせていただきます。私はWebとインフラの現場を18年やってきまして、今はサーバーワークスでプロジェクトマネージャー、スクラムマスターとしてお客様の内製化の立ち上げをご支援しています。弊社サーバーワークスはAWS専業のクラウドインテグレーター企業で、お客様の構築と移行、運用まで幅広くご支援しています。2000年に創業し、今年で27年目になります。

私がさまざまなお客様をご支援する中で分かってきたのは、内製開発が止まってしまうのは技術よりも「決め方」が原因だということです。今回のプロジェクトではアジャイル開発のフレームワークとしてスクラムを採用しました。要件が不確定なエンタープライズ企業のプロダクト開発においても、有効に機能しやすいと考えています。本セッションでは、スクラムそのものの解説ではなく、意思決定と合意を前に進める「進め方」としてスクラムをどう活用したかに焦点を当てました。

最初に今日のキーワードをお伝えします。「スクラムマスターは答えを出す人ではなく、答えが出る条件を整える人」です。この視点で3つの実例を交えながら、内製開発を前に進めるためのアイデアを皆様とシェアしたいと思います。

生成AIを含むAIの登場で「作る」は速くなりました。これからもこのスピードは確実にもっと速くなっていくでしょう。だからこそ、ビジネスに必要なのは「決める」と「育てる」の2つです。この2つがこれからの事業の競争力になると考えています。



今日お持ち帰りいただきたいのは、内製開発へのシフトを止めがちな「3つの渋滞」を、どのタイミングでどう解消したのかという具体策です。

スクラム未経験チームが直面した「3つの渋滞」

内製化が詰まる瞬間とは、技術の難しさよりも「決める」の渋滞の方が圧倒的に多いということが分かりました。決まらない状態が続くと、チームが止まるだけではなく、チームのモチベーションも低下していきます。ここでいうチームとは開発者だけではなく、プロダクトオーナー（以降PO）、すなわちお客様も含めた全員のことです。

私が現場で何度も見た渋滞は3つあります。1つ目は「役割の曖昧さ」です。誰が決めるのかが決まっていない状態のことで、開発の方向性も曖昧になり、お互いがお見合い状態になってチームが止まってしまいます。2つ目は「品質基準の揺れ」です。何をもって完成とするのか、認識が揃っていない状態です。主観は属人化を生み、属人化は品質を曖昧にしていきます。開発者側で問題ないと判断した内容が、必ずしもお客様の受け入れ条件を満たすとは限りません。3つ目は「意思決定の遅さ」です。判断するための材料が揃わずに決められない状態のことです。判断材料が揃わないままの意思決定は、納得感のあるビジネス判断になりにくくなります。



だからこそ、プロジェクトの入り口に近いほど、すなわち立ち上げ期ほど、スクラムのイベントを回すよりも先に「決め方と合意の仕組み」を設計することを優先しました。

今回のケースでは、エンタープライズ企業のBtoB Webプロダクト開発がテーマとなります。お客様も含め、開発者はスクラム開発がほぼゼロの未経験状態でスタートしました。チーム体制はPO1名、開発者5名程度、スクラムマスターは内村が務めました。1スプリントのタイムボックスは2週間を採用しています。今回のプロジェクトでは、1カ月では間延びしやすく、1週間では運用負荷が高くなりやすいと判断し、2週間を採用しました。タスク管理にはBacklog、コード管理にはGitHubを使用しています。



このチームにはスクラムの難易度を上げる要素が揃っていました。ステークホルダーが多い、企業固有の用語や文化がある、エンタープライズ企業特有のセキュリティや監査の意識も高い。だからこそ、立ち上げ期ほど設計が効くと確信しました。

このまま何も設計せずに始めてしまえば、スプリント1回目から期待通りに回らないことは明らかです。スプリントレビューが単なる定期報告会になったり、レトロスペクティブがプレッシャーの強い反省会になったり、チケットが作業メモになったり。そして何よりも「決めたいことが決まらない」という状況に陥ることが想像できました。さらに、発注者対受注者という悪い意味での緊張感が生まれる現場も想像に難くありません。

設計1：ワーキングアグリーメントで「役割の曖昧さ」を解消する

1つ目の渋滞「役割の曖昧さ」に対する設計がワーキングアグリーメントです。ワーキングアグリーメントとは、チームの行動指針を明文化、すなわち文書化して、継続的に見直す仕組みのことです。ポイントは、最初から完璧なルールを作るのではなく、困った時に戻れる場所を作るということです。しかもPOも含めてチーム全員で合意を得ること。これを一番最初に行いました。



特にプロジェクトの立ち上げ期は暗黙知が多いことが予想されます。暗黙知が多いと人間は衝突しやすくなり、タックマンモデルでいう動乱期に突入していきます。動乱期が長くなるほどプロジェクト全体の生産性は低下し、成功は遠のきます。だからこそ、暗黙知をできるだけ文書化して、全員で更新できる状態にしました。役割の曖昧さは判断が滞る形で表れます。これを回避するためにも、目に見える文書を全員の合意のもとで作り、ブロッカーを早く露出させ、改善を実験して回し始めることが重要です。

では、いつ合意を得るのか。それはものを作るスプリント1ではなく、もっと前の段階です。私はこれを「スプリント0」と呼んでいます。

このワーキングアグリーメントで特に効いた条文は2つです。1つ目が「作業ブロッカーは早めにスクラムマスターに共有すること」。2つ目が「振り返りの改善を試みてみること」。この2つが効いたのは、スクラムの価値基準、特に「尊敬」と「公開」につながるからです。お互いに言っていい空気がなければブロッカーを見つけることはできません。試していい空気がなければ改善は動きません。

ここで冒頭のキーワードにつながります。私はスクラムマスターとして答えを出していません。ブロッカーが出て改善が回るという条件、すなわち土台を整えたのです。この土台がワーキングアグリーメントという文書と、チーム全員の合意という土壌になります。

設計2：DoDで「品質基準の揺れ」を止める

ワーキングアグリーメントという土台ができたからこそ、次の設計が効くようになります。DoDは、成果物のDoneの品質条件をチームで揃えるものです。エンタープライズ企業のBtoBプロダクト開発では品質基準が揺れやすいため、立ち上げ期ほど最小の合意が効くという設計をしました。

今回のスクラム開発では、以下の5項目をDoDとして設定しました。要件を満たしている、コードレビューが承認されている、単体テストが実行されている、IaCの成果物はGitHubに反映されている、ドキュメントがMarkdownでBacklog WikiもしくはGitHubに格納されている。



たった5項目ですが、これが現実的にはかなり効きました。特にドキュメントをMarkdownで残すという項目が、後からの意思決定の判断材料になっていきます。ポイントは最小状態で合意すること。ガチガチに固めてしまうと身動きが取れなくなり、後からの更新の可能性を自ら奪ってしまいます。

DoDがないと、レビューでDoneかどうかの判断基準が主観に寄り、議論が揺れて手戻りが増えます。逆にDoDがあると、レビューや議論が定義、すなわち基準に戻ります。揉めてもDoDに戻るだけで論点が揃う。結果はシンプルにDoneか否か、この2択です。

さらに、DoDがあると「自ら育てる」という効果も生まれます。基準があるからこそ、揉めた事実を材料にしてDoDをアップデートしていくことができるのです。DoDは監査用の書類ではなく、対話の成果物です。

設計3：意思決定の可視化で「決まらない」を前に進める

可視化というと進捗を見える化するイメージがあるかと思いますが、私がやったのは進捗ではなく「意思決定の可視化」です。ポイントは3つ。優先度、未決事項、リスク・ブロッカー。特に未決事項は「誰が・いつまでに・判断材料は何か」をセットにして見える化します。私はこれを「未決リスト」と呼んで運用しました。



未決リストは議事メモではありません。決定待ちのものを判断材料付きで並べる表です。決定者、期限、判断材料が揃うと、未決が「決められる形」になります。未決リストにはもう一つ重要な効果があります。自社固有の用語やルール、判断基準を意思決定として仕様に刻み込むツールにもなり、これがそのまま事業の核になっていくのです。このプロジェクトでは3つの未決事項を例にご紹介します。



1つ目は「画面内の表示項目名」。お客様は名称に「分類ID」のようにIDをつけたいと言われましたが、開発者はIDという名前は一意キーのように見え、将来の仕様が縛られるとして反対しました。私がやったのは、PO側にはその名称にしたい理由と背景の資料を揃えてもらい、開発者側にはなぜ反対するのか不安を一行で説明してもらうこと。それぞれの意見を一つのテーブルに出し、お客様の文化を守りつつ将来の発展性も加味した落としどころの名前をチームで考えてもらいました。対立しているときは、実は論点がバラバラなことが多い。だから論点を一つのテーブルに並べて議論するのが有効です。

2つ目は「SSO（シングルサインオン）の実装」です。SSOとは会社のログイン基盤であるIdP（アイデンティティプロバイダー）と接続して、社内アカウントのまま新しいシステムにログインできるようにするものです。しかしIdPを管理する部署の協力が必要であり、その部署のレスポンスが遅い。このまま仕様を詰め続けると開発が待ち状態になってしまう状況でした。私は意思決定の対象を切り替えました。仕様を決めきるのではなく、開発順序を先に決定するようチームを誘導したのです。依存部署が必要な前提を未決リストに載せ、チームには「後半でやる」という合意を得ました。スクラム開発のスプリントプランニングで開発順序を変え、先にできる機能は先にやり、外部依存のある機能は後に回す。これはアジャイル開発のフレームワークとしてスクラムを採用したからこそ享受できたメリットです。

3つ目は「環境ごとのAWSアカウント分離」です。本番・開発・検証環境のアカウントを分けるかどうかという議論で、開発者はアカウントを分けたいが、POは「なぜ？」と腹落ちしない。たとえば「転ぶ可能性があるのでプロテクターを買いましょう」と言われても、すぐには判断しにくいでしょう。「可能性がある」という表現は、相対的な程度が分からないと判断できないのです。そこで私は、回避したい課題を「発生確率」と「回避策」の2つに分解しました。たとえば「誤って本番を触ってしまう可能性がある」なら、それがどのくらい起きそうか、どう避けるべきかをセットで出してもらいました。さらに回避策を「本番と開発をまたぐような基本設計にはしない」「必要な通信は環境の中で閉じる」といった設計原則に落とし込み、メリット・デメリットを更新して改めて合意を得ました。不確実性を分解して比較できる表にすることで、POも「分ける」が腹落ちしたのです。



この3つの事例に共通しているのは、私は答えを出したのではなく、未決を「決められる形」に変えたということです。パターンは大きく3つあります。1つ目は用語の対立です。名称の正しさを議論すると必ず揉めるので、代わりに「なぜその言葉が文化として定着しているのか」を判断材料として可視化することで合意できます。つまり、言葉を決めるのではなく「決められる理由」を揃えるのです。2つ目は仕様で止まりそうなときです。意思決定の対象を仕様から「開発順序」に切り替えることで、止まらずに進みます。3つ目は不確実性です。「可能性がある」という言葉を放置すると永遠に決まらないので、「発生確率」と「回避策」に分解して腹落ちする形に変えます。これらをまとめると、やはり今日のキーワードにたどり着きます。スクラムマスターは答えを出す人ではなく、答えが出る条件を整える人です。

スプリント0から始める導入ロードマップ

この3つの設計を「いつ入れるのか」が重要です。成果物ができる前、すなわちスプリント1の前の「スプリント0」に置くことです。



スプリント0ではまずワーキングアグリーメントの雛形を作ります。最初は雛形で構いません。チームと合意してください。狙うのは完璧なルールではなく、困った時に戻れるガードレールを最速で作ることです。同時にDoDも最小セット、たとえば5項目でスタートします。網羅は不要です。完璧は禁止です。

スプリント1に入ると、スプリント0で合意した内容で必ず揉めます。しかし、この揉めることが実は目的です。私はそれを「宝」と呼んでいます。揉めた事実が判断材料となり、ワーキングアグリーメントとDoDを更新できるのです。ここで1回更新してください。この順番にすることで、DoDが監査用書類ではなく対話の成果物になります。

スプリント2以降では、未決リストを定着させていきます。コツは「誰が・いつまでに・判断材料は何か」を1行で書くことです。ここまで来ると、スクラムイベントを回すたびにチームの意思決定が回り始めます。スクラムにおける「タイムボックス」は時間枠ですが、私はこれを「意思決定枠」と呼んでいます。話すだけの会議ではなく、「決まる会議」になっていくのです。ここまでをスプリント2でやっていけば、あとは気合ではなく形で前に進めることができます。

立ち上げ期ほどイベントを回すよりも先に、決め方と合意を設計した方が内製化は止まりにくいのです。

明日から試せる3つの具体策

最後に、明日から試せる具体策を3つお持ち帰りください。

1つ目、ワーキングアグリーメントを1枚にして、スプリントごとに更新する。最小限気をつけたいのは、連絡手段と緊急時の対応、ドキュメントの置き場、スクラムイベントの開催日時、判断に迷った時に立ち戻る原則の4点です。運用ルールとして「スプリント1で必ず1回見直す」と決めてください。これにより、ワーキングアグリーメントが聖域ではなくチームのよりどころになります。落とし穴は文章を増やしすぎること。A4 1枚を超えた瞬間に誰も読まなくなります。完璧を目指すとそこで止まるので、最初はライトな運用ガードレールで十分です。

2つ目、DoDは5項目だけでまず合意する。完璧は禁止です。最初から網羅すると、DoDが監査のチェックリストになり、更新できずに前に進めなくなります。最小セットで始めて「後から足す条件」もあわせて決めておきましょう。たとえば、事故が1回起きたら追加するというルールです。揉めた事実を材料にして、DoDを育ててください。DoDは品質を担保するだけでなく、迷いを減らして意思決定を速くする効果もあります。

3つ目、未決リストを作り、「誰が・いつまでに・判断材料は何か」を1行で書く。列は「未決事項／意思決定者／期限／判断材料／依存先／ネクストアクション」とし、置き場所は誰でも閲覧できる場所が最適です。更新タイミングはデイリースクラムの前かスプリントプランニングの開始時。ビルドが始まった後は情報収集の時間になるので、スプリントが始まる前に更新を済ませましょう。1行で書けない未決は分解してプロダクトバックログアイテムに落としてください。この未決リストはプロダクトバックログアイテムとの親和性が高く、リファインメントに直結します。未決リストは「決める会議」を増やす道具ではなく、「決まる条件」を揃える道具です。



内製化を止めるのは「役割の曖昧さ」「品質基準の揺れ」「意思決定の遅さ」です。これに対して効いたのは立ち上げ期の設計でした。ワーキングアグリーメント、DoD、意思決定の可視化（未決リスト）の3つです。

内製開発の本質を一言で言うなれば、「自社固有の用語、ルール、判断基準を合意と品質で積み上げていく力」です。気合ではなく、形で前に進めていく。この中にもスクラムマスターとしてプロジェクトに従事されている方がいらっしゃるかと思います。数々の困難に立ち向かっている皆さんを尊敬しています。スクラムマスターは答えを出す人ではなく、答えが出る条件を整える人です。ぜひチームの皆さんが答えにたどり着けるようにご尽力ください。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
内製開発Summit 2026
※動画の視聴にはFindyへのログインが必要です。