内製化の理想と現実 ─ なぜビジネスと開発のワンチームが必要なのか

西森：レッドハットの西森と申します。オープンイノベーションラボというサービスにおいて、アジャイルコーチやPOコーチという役割を担っています。前職でデザイナーだったこともあり、デザイン関連のご支援もさせていただいています。

レッドハットは1993年にアメリカで設立された企業で、現在は35カ国に約1万9,000人の社員を擁しています。ミッションは「オープンソースの技術と文化でお客様のイノベーションをご支援すること」です。Linux以外にもOpenShiftやAnsibleなどのサービスを提供していますが、技術だけでなく「ビジネスの成功」をゴールに置いた時、プロダクトの作り方や組織文化の変革、ビジネスの勝ち方も知る必要があります。そこをサポートしているのが、2018年から提供しているオープンイノベーションラボです。

我々が重要なキーワードとして捉えているのが「ビジネスアジリティ」です。お客様が何を求めているのかというアウトカムを見つけ、それをいち早く市場に投入し、その結果を知るスピード──このループを回していくことが、変化の激しい時代には非常に重要だと考えています。そのためには開発のやり方だけでなく、技術、プロセス、組織と人、そして戦略の部分まで一貫してサポートしていく必要があります。実際に東京海上さんをはじめ、日立建機さん、楽天カードさん、AGCさんなどにご活用いただいています。

内製化を目指す背景としてよく見られるのが、親会社（ビジネスサイド）がシステム子会社に発注し、さらにパートナー企業に再委託するという多重構造です。この構造では、システム子会社に開発者として入社してもコードを書く機会がなく、発注を伴うためビジネス側から開発への依頼のスピードが遅くなります。中長期的に見ると技術や知見が自社に溜まらず、外部依存から脱却できません。

本来やりたいことは、ビジネスと開発がワンチームになって内製開発を推進する姿です。ちゃんとやっていけば、自社にノウハウも貯まりますし、優秀な人材も確保できますし、発注の手間も省略できます。

しかし、内製開発チームを作ってアジャイルに取り組み始めても、だんだんと成果が見えにくくなるケースがあります。我々もたまに途中から入らせていただくのですが、ヒアリングをすると「これはアジャイルなのか」「なんちゃってアジャイルをやっている」「実際やっていることはウォーターフォールです」とおっしゃるお客様が多くいらっしゃいます。



内製化が進まない要因としては、経営層やマネージャーの後押しがない、出島としてチームを作ったが会社の仕組みが変わっていない、そしてチーム自身の開発プロセスが形骸化しているといった問題が挙げられます。ここでいう「形骸化」とは、ルールや制度、会議、組織などが本来持つ目的や意義を失い、形だけが残って実際には機能していない状態のことです。単に形式を守ることが目的化し、中身の伴わない実質的な効果が期待できない状況を指します。今日はこの中でも、チーム内部の形骸化の部分にフォーカスしてお話ししていきたいと思います。

なお、本セッションではスクラムという開発フレームワークが中心的な話題になります。スクラムとは、複雑な問題に対応するための軽量なフレームワークで、スクラムマスター・プロダクトオーナー（PO）・開発者の3つの役割と、スプリントプランニング・デイリースクラム・スプリントレビュー・レトロスペクティブの4つのイベントで構成されています。1〜4週間のスプリントと呼ばれる短い期間で開発と検証を繰り返し、変化に素早く適応しながら価値を届けるのが特徴です。

6つのケーススタディに見るアジャイルの形骸化

ここからは6つのケースを皆さんにご紹介します。皆さんに当てはまる形骸化の事例がいくつあるか、心の中でカウントしながら聞いていただければと思います。

ケース1：役割の形骸化

スクラムには、スクラムマスター・開発者・PO（プロダクトオーナー）の3つの役割があります。スクラムマスターの本来の責務は、自己管理型で機能横断型のチームを作るためのコーチングや障害の除去、サーバントリーダーシップの発揮です。しかし現場では、進捗の監視役（PM化）、開発チームの長としてPOと交渉する代表者、要件定義の担当者、あるいはタイムキーパーや議事録係といった「事務局」になっているケースが見られます。

開発者に関しても、本来は自分たちで計画と管理を行い、品質を作り込み、専門性を発揮する存在ですが、スクラムマスターやPOからの指示を待つ姿勢になっていたり、「完了＝コーディング終了」と解釈してテストや品質保証を他の工程に丸投げしたりする例があります。

POのことを「PO様」と呼ぶチームに去年初めて遭遇しました。親会社とシステム子会社の上下関係がそのまま持ち込まれているのですが、スクラムでは本来、全員が対等な関係でやっていくのが前提です。

ケース2：イベントの形骸化

スクラムのイベント（スプリントプランニング、デイリースクラム、スプリントレビュー、レトロスペクティブ）もそれぞれ形骸化しがちです。プランニングでは開発者だけで集まりPOを巻き込まない。デイリースクラムは本来15分間の「作戦会議」ですが、スクラムマスターへの日次進捗報告会になってしまう。

レビューはそもそも実施されないか、承認会議化している。振り返りは精神論の「気をつけます」で終始してしまう──こうした状況がよく見られます。

ケース3：サイクルの形骸化

サイクルの面では、スプリントを回していても実態はウォーターフォール化し、要件定義・実装・試験スプリントを順番に実施しているだけというケースがあります。本来であればスプリントごとに「動作するソフトウェア」をデリバリーし、即座に提供するのがスクラムの価値のインクリメントです。

しかし形骸化した現場では、リリースは半年後の「ビッグバンリリース」で、最後までリスクが潜在し長期間価値が届かない状態です。2週間の実績ベースで次の見通しが立てられるはずが、硬直した確約と遅延の常態化に陥っています。

ケース4：品質の形骸化

「ドキュメントを書かなくていい」「とりあえず動けばいい」「デザインは後回し」というアジャイルへの誤ったイメージが先行し、品質が伴わないケースも見られます。これは「アジャイル＝倍速開発」という誤解から来ています。「ドキュメントを書かない分、工数半分でできる」と短納期を強要される武器になってしまったり、口頭ベースの曖昧な指示で進めた結果「言ったことと違う」と揉める原因を作ったりしています。

アジャイルの本来の強みは高速な学習サイクルと対話による合意形成、そして価値検証のための高品質なアウトプットです。しかしそのイメージとは裏腹に「スピード優先で品質は二の次」という解釈が広がっており、品質をおろそかにして技術的負債を増やし、結果的に「計画が立てられない」状態に陥っています。

ケース5：メトリクスの形骸化

メトリクスについては、本来はキャパシティ計画のための予測ツールであるベロシティを、チームを評価・管理するための「生産性指標」として誤用してしまうケースがあります。数値の低下を「努力不足」と見なしたり、詰問やベンダー選定の判断材料として悪用したりする「サボり監視の道具」になっています。

また、基準が異なる他チームとポイントを並べて比較する無意味なチーム間比較や、ストーリーポイントを人日に換算して1ポイント＝2時間のように固定する工数換算による管理も見られ、相対見積もりの意味が失われています。

ケース6：大規模アジャイルの形骸化

大規模アジャイルでは、本来は複数チーム間の依存関係を最小化し、スクラムオブスクラム等で事前に調整する必要がある規模なのに、単独チーム用のスクラムをただ並列で走らせているだけというケースが見られます。その結果、他チーム待ちの常態化や、スプリント内での統合を先送りにして最後にまとめて動かないことが発覚する「恐怖の結合テスト期間」が生じます。人数増に伴い調整会議や承認フローが乱立し、組織の重さで俊敏性が死滅してしまうのです。

形骸化のメカニズム ─ 根本原因は「Whyの不在」

勘違いしないでいただきたいのは、皆さん思いを持って真剣に取り組んでいるということです。サボろうとか悪さをしようという人はいません。やり方がわからないから、違った方向に進んでしまうのです。



今お話しした6つのケースは、多分根本原因は一緒だと思っています。突き詰めると「やり方が会社と合わないから」ではないでしょうか。立場的にPOを巻き込めなかった、どうしても納期があるのでお作法に構っていられない、会社の仕組みやルールがウォーターフォールから進化していない──こうした事情からやり方をカスタマイズせざるを得ず、その結果「これって続ける意味があるのか」「形だけしかやっていないのではないか」と形骸化が生まれます。

ただし、スクラム自体はカスタマイズを前提に設計されたフレームワークです。スクラムガイドの冒頭にも「フレームワークは意図的に不完全なものであり、様々なプロセス、技法、手法を使用できる」と明記されています。カスタマイズ自体は悪いことではありません。

問題は、Howレベルの実践にとどまっていることです。やり方だけを真似してみたものの、「なぜそれをやるのか」「本来達成したかった目的は何か」が置き去りにされたまま進んでしまう。Whyや本質の理解がない中でのカスタマイズが、形骸化していく第一歩なのです。

スクラムの本質 ─ 透明性・検査・適応の三本柱

スクラムの本質は何でしょうか。これは多分いろいろな考え方がありますが、スクラムガイドの冒頭にこのように書いてあります。



スクラムガイドには「スクラムは現在のマネジメント環境、作業環境の相対的な有効性を可視化する。それにより改善が可能になる」と書かれています。スクラムを導入して結果を出そうとすると、今のマネジメント体制やものを作っていく環境が本当にこのままでいいのかがつまびらかになります。隠されていた不都合なところもわかってくる。そうするともっといい形にしなければならないということで改善をする結果、アジリティの高い状態ができていく。これがスクラムの本来やりたかったことや効果なのではないかと思っています。

スクラムの4つのイベントが機能するのは、経験主義の三本柱である「透明性」「検査」「適応」を実現しているからです。スクラムの全てのイベントや作法は、突き詰めればこの三本柱に行き着きます。

ちょっと余談ではありますが、このスクラムを構成する大事な考え方としてリーン思考があります。リーン思考はトヨタ生産方式をスタートとする考え方で、その本質は「顧客に価値を届けるためのリードタイムを短くし、スムーズにタスクを流すこと」にあります。レトロスペクティブもまさにその一環であり、自分たちの働き方を見直して、顧客に価値を届けるためのリードタイムを短くする重要なイベントであることがわかるわけです。

レトロスペクティブに見る「形骸化する振り返り」と改善の具体例

一つ例をご説明したいと思います。レトロスペクティブの本質はどこにあるのでしょうか。レトロスペクティブの「Why」は、自分たちの働き方をより良くすること、パフォーマンスを上げること、そしてチームとして知識をつけることであり、「組織学習」です。また、レトロスペクティブの「What」は、自分たちの働き方の検査と適応であり、Howとして心理的安全性の確保やKPT・Good/Mottoなどのフレームワークがあります。

しかし、よくある形骸化パターンでは、いきなり全ての項目を書き出して一人ずつ発表する形式に陥り、「なんとかリリースに間に合った」「次からは気をつける」「コミュニケーションを密にしよう」といった精神論で終わってしまいます。これは、3つの問題を引き起こしてしまいます。フロー（価値の流れ）を見ていないこと、「検査」ではなく「個人の反省会」になっていること、そしてアクションがバックログに積まれず毎週同じProblemがループし続けることです。

たとえば「テスト漏れが起きたので次からダブルチェックしよう」──よくありますよね。しかしこれは意識レベルの話で、仕組みとしてどう防ぐかの問いになっていません。「コミュニケーションを密にしよう」も同様で、もう一段階深掘りして「着手前に必ず15分のペア設計タイムを設ける」のように具体的なアクションに落とし込むことが重要です。



じゃあ理想のレトロスペクティブはどうなのかという話ですが、こういう進め方はどうでしょうか。ステップ1として場の設定で話しやすい状況を作り、ステップ2でデータを収集するワークを行い、ステップ3でKeepとProblemを出し、ステップ4でTryを決定、そしてステップ5としてレトロ自体の振り返りまで実施する。いきなりKPTに入るのではなく、データの収集フェーズを設けることで、感覚ではなくファクトに基づいた議論が可能になります。

人材育成 ─ Whyを理解したスクラムマスターの育成が出発点

気合いや根性だけでは「形骸化の引力」には逆らえません。人材育成とデータ活用、この2つを組み合わせて形骸化を止めていきましょう。



アジャイルの成功の1丁目1番地は、私は人材育成だと思っています。もちろんいろいろな要素はありますが、やはり最後は人であり、その人の想いです。ちゃんと人材を育成するということをやっていかないと、最後は立ち行かなくなってしまうというのが私の経験上あります。見よう見まねの実践からスタートすること自体はすごくいいことですが、それで止まってしまうとHowレベルの実践にとどまってしまいます。スクラムマスターやアジャイルコーチがHowレベルであれば、その先の開発者やPOがWhyレベルまで理解することは難しいため、まずは旗振り役がプロから学ぶことが重要です。

たとえば「リーンソフトウェア開発の原則」の一つに「決定をできるだけ遅らせる」というものがあります。スピード感を持ってやっているアジャイルにおいて逆のことを言っているように感じますが、なぜこの原則があるのかを説明できるコーチが近くにいると、本物の学びになります。体感とは異なる知見に触れられるのも、プロから学ぶ価値です。

開発者やPOへのトレーニングでは、「スクラムとは？」という話で終わらせず、3つの要素を盛り込むことが効果的です。まず「自分たちはどんな姿を目指すのか」（アジリティを高める、価値を提供する）を議論し、次に「価値を素早く提供するにはどうすればいいか」としてリーンやフロー効率、待ち行列理論の考え方を伝え、最後にWhyを踏まえた上で「不確実性の高い状況で変化に強いやり方としてスクラムがある」と紹介する流れです。最初は結構難しかったりもするのですが、最終的な理解度はまったく違います。



少し話を変えます。スクラムマスターの正しい姿とはどのようなものでしょうか。よくある間違いとして、単なる進捗管理者（PM）やファシリテーター、ルールを押し付けるだけの「アジャイル警察」になってしまうケースがあります。本来のスクラムマスターは、スクラムの実践に責任を持ち、チーム内外のスクラムの伝道師であり、原則を胸に秘めつつ泥臭いビジネス感覚を持ち合わせた変革のリーダーです。

形骸化のトリガーは「イレギュラー（想定外の事態）」です。炎上、急な仕様変更、経営者からの鶴の一声──スクラムガイドにはこれらへの対処法は書いてありません。伴走者がいないと、無意識に従来のウォーターフォールのやり方に戻ってしまいます。Whyを熟知したスクラムマスターがいれば、「今は緊急避難として許容するが、次はどう正しいレールに戻すか」をナビゲートできます。

データ活用 ─ アジャイルメトリクスでチームの現在地を客観視する

もう一つ、データ活用のお話をさせていただきます。やはり感覚だけではアジャイルな状態は維持できないのではないかと思っています。今のチームの立ち位置はいい状態なのか、悪い状態なのか。感覚ではわかっていても、それだけでは経営陣やチームメンバーに伝わりません。

感覚で「形骸化している」「変えなきゃいけない」と叫んでも、ピンとこないので振り向いてもらえないという瞬間があると思います。いくら理論で話しても伝わるのは限定的です。そこでアジャイルメトリクスの活用が必要になります。



アジャイル開発の核心は「顧客に価値を迅速かつ継続的に届けること」であり、指標はその状態になっているかを明らかにするものです。アジャイルで開発しているつもりでも、実際には価値提供の速度や品質が向上していないということがあり得ます。そうならないように指標を見ましょうということです。

具体的には、ユーザー価値、価値提供のスピード、価値の品質、価値提供の継続性、プロダクトの安定稼働という5つの観点で指標を設定していくのがよいと考えています。



品質の指標例としては、テストカバレッジ、自動テスト比率、テストケース成功率、欠陥密度（Defect Density）、重大欠陥率（Critical Defects）、初期品質（First Pass Yield）などがあります。これらを定量・定性の両面で組み合わせ、ダッシュボードで可視化することで、主観的な意見ではなく客観的にチームの透明性を高めていくことができます。

定量指標だけでなく定性アプローチも重要です。こうしたクライテリアを用いて自分たちの行動がどうなのかを評価する取り組みも行っていくことが可能です。

こうした定量・定性の指標を組み合わせて、先ほどの5つのジャンル──ユーザー価値、スピード、品質、継続性、安定稼働──で必要なものを組み合わせていけば、チームに必要な指標が見えてきます。実際にダッシュボードを使って可視化することで、主観ではなく客観的にチームの透明性を高めていくことができます。

人材育成とデータ活用という2つのアプローチで、形骸化を乗り越えていきましょう。

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

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

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