プレイングマネージャー型のEMをしています、鈴木（@szk3）です。
今回は、私たちのサービスチームが新規プロダクト開発を始めるにあたって「スクラムを導入しなかった」経験について共有します。
このタイトルだけを見ると、スクラムに対して否定的な印象を持たれるかもしれません。しかし、これはスクラムへのアンチテーゼではありません。むしろ、スクラムの価値をリスペクトし、その実践に真摯に向き合いたいからこそ行った慎重な決断でした。実際、新規プロダクト開発の開始とほぼ同時期に認定スクラムマスター資格も取得し、スクラムについての理解を深めていく中で、この決断の意義をより一層実感しています。
新規プロダクトの開発において、アジャイル開発を取り入れることは当然の選択肢として考えられます。むしろ、アジャイル開発の実践にスクラムのフレームワークを使うことは、実質上のスタンダードとなっていると感じます。しかし、「アジャイル」＝「スクラム」という図式は、必ずしも全てのチームにとってベストな選択とは限りません。私たちは、チームの状況や成熟度を考慮し、より柔軟なアプローチを模索することにしました。
この記事では、その決断に至るまでの思考プロセス、実際に採用した開発手法、そして現在進行形で試行錯誤している私たちの取り組みについて共有します。特に、「アジャイルの本質を見失わずに、チームに合った開発スタイルを作り上げる」というアプローチについて、具体的な実践例を交えながらお伝えできればと思います。
結果整合的アジャイルという考え方
まず最初に、「結果整合的アジャイル」は造語です。
これは、アジャイルソフトウェア開発宣言の価値観（個人と対話、動くソフトウェア、顧客との協調、変化への対応）を基盤としながら、チームの状況に応じて柔軟に開発プロセスを調整し、結果としてアジャイルな開発を実践し、価値創造を実現していく考え方を意図しています。
なぜ「結果整合的」なのか
「結果整合的」という言葉は、プロセスと結果の関係性を表現しています。私たちの開発プロセスは、必ずしも常にアジャイルの理想的な状態ではありません。スクラムなどのフレームワークに従わず独自の試行錯誤を行う中で、時には混乱が生じたり、うまく価値を生み出せない時期もあります。
しかし、最終的にアジャイルが目指す価値を実現できていれば、それは「結果として整合している」状態だと考えています。つまり、完璧なプロセスを目指すのではなく、価値の実現という結果への整合性を重視する考え方です。
サービスチームのメンバーは、アジャイルやスクラムに対する理解度や経験値に個人差があるのが現実です。また、チームの規模や製品の性質・ビジネスの要件によっても、最適な開発プロセスは変わってきます。
「結果整合的アジャイル」では、特定の手法やフレームワークに固執せず、以下の点を重視します：
- チームメンバー一人ひとりの得意分野や開発スタイルを活かす
- プロダクトの開発フェーズに応じてプラクティスを取捨選択する
- ビジネスニーズの変化に合わせてプロセスを進化させる
アジャイル開発には、以下の図のように様々なプラクティスやアプローチが存在します。私たちは、これらを「選択可能なオプション」として捉え、チームの状況に応じて柔軟に取り入れていくことにしました。
アジャイルな開発プロセスづくりをアジャイルに行う
私たちの アプローチ では、開発プロセス自体もアジャイルな方法で改善していきます。
具体的には：
- 観察: チームの働き方や課題を継続的に観察
- 実験: スクラムやXPなどの優れた手法からエッセンスを抽出し試行
- 検証: 効果を測定し、チームへの適合度を評価
- 適応: 効果的な要素は維持し、そうでないものは改善または破棄
この繰り返しにより、チームに最適な開発プロセスを段階的に構築していきます。
目指す状態と得られる効果
このアプローチにより、以下のような状態を目指します：
- チームメンバーが無理なくアジャイルな開発を実践できている
- プロダクトの価値が継続的に向上している
- 開発プロセスが組織やプロダクトの成長に合わせて進化している
特に、従来の「アジャイルを実践するためのフレームワークを導入する」際に陥りがちな、フレームワークの形式やイベント自体が目的化してしまうリスクを避けつつ、導入時の心理的ハードルを下げることができます。
最初から「うまくやろう」としていないので、チームは「○○をやらねば」というプレッシャーから解放され、本来の目的であるプロダクトの価値提供とチームの持続的な成長に集中できます。
新規プロダクト開発 開始時の決断
新規プロダクト開発と直面したジレンマ
私は以前から様々な開発現場でスクラムに則ったアジャイル開発を経験してきました。しかし、その多くは表面的な理解のまま進めていたため、本質的な価値を実感できずにいました。そんな中、新規ビジネスの立ち上げという機会を得て、プレイングマネージャー型のEMとしてプロダクト開発に参画することになりました。
当初の私の頭の中には、「不確実性の高い開発プロセスにはスクラムを使ったアジャイル開発が適している」という選択肢しかありませんでした。
一方で、自身やチームメンバーのスクラムに対する理解度や、まだ組成間もないチームの関係性や状態を考えると、以下のようなジレンマを抱えていました：
- スクラムを「正しく」実践するには、チーム全体の深い理解が必要
- しかし、プロダクト開発は待ってくれない
- かといって、経験を積まなければスクラムは上手くならない
- そもそも、メンバーのほとんどが一緒に仕事するのが初めてでお互いのことをよく知らない
観察からはじめた理由
このジレンマを前に、私は「まずはチームメンバーを観察する」という選択をしました。
この決断の背景には、以下のような考えがありました：
本質的な目的の再確認
- サービスチームのミッションは「プロダクトを通じてお客様の課題を解決し、価値を提供すること」
- 開発手法の選択は、このミッションを達成するための手段でしかない
チームの現状把握の重要性
- まだチームメンバーとの関係性が浅い段階で、理想的な開発プロセスを描くのは難しい
- 各メンバーの得意分野や好みを知ることが、効果的なチーム作りの第一歩
観察で得た気づき
サービスチームの観察を通じて、以下のような発見がありました：
- メンバーそれぞれが異なる開発体験を持っており、好むワークスタイルも様々
- ペアプログラミングに積極的なメンバーもいれば、個人作業を好むメンバーもいる
- プロダクト開発のスキルや理解度にも個人差がある
- 初期開発スコープのプロダクトは、実装の観点でいうと不確実性が低そう
これらの気づきから、画一的なスクラムの導入よりも、サービスチームの特性に合わせた柔軟なアプローチが必要だと感じました。
決断：初手、スクラムを全面採用しない選択
最終的に、私たちは以下の理由からスクラムの全面採用を見送ることにしました：
- チームの多様性を活かしたほうが、より高いパフォーマンスを発揮できる
- スクラムやXPに代表されるフレームワークの形式に縛られず、アジャイルの本質を追求したほうが、現状のチームには合っている
- 段階的に開発プロセスを改善していくほうが、チームの成長に寄り添える
この決断は、スクラムを否定するものではありません。むしろ、アジャイルソフトウェア開発宣言に則ろうとした結果です。
実際、私たちの現在の開発スタイルには、スプリントやデイリースタンドアップなど、スクラムの優れたプラクティスやイベントを数多く取り入れています。
ただし、それらは形式的な採用ではなく、チームの文脈に合わせて柔軟にアレンジしています。
私たちが選んだアプローチ
結果整合的アジャイルを実践するにあたり、まずスクラムやXPの各プラクティスやイベントを評価し、チームの状況に合わせて採用するものを選択しました。
また、明示的に「スクラムを採用してはいない」という宣言をチームで共有することで、チームが必要以上に型の遵守に縛られたり、あるいはそのための議論が発生したりするような状況を避けることができました。
ここでは、採用を見送ったものと採用したもの（の一部）、そしてその理由について説明します。
採用を見送ったプラクティス
1. ベロシティ
XPをルーツにするベロシティはチームの開発速度を可視化する強力なプラクティスとして、多くのアジャイル開発で活用されています。しかし、以下の理由から導入を見送りました：
- 正確な測定には経験とスキルが必要
- 測定の基準設定や見積もりの精度向上に時間がかかる
- プロジェクト初期での導入はチームに不必要な負荷をかけるリスクがある
また、実際の開発現場では、ベロシティが「チームの外部への報告のための指標」として扱われがちです。これは、チャールズ・グッドハートが提唱した「管理のために用いられる測定はすべて信頼できない」という法則に陥るリスクがあります。つまり、測定値自体が目的化し、本来の価値を見失う可能性があるのです。
代わりに、私たちは「スプリントゴールで決めたインクリメントが確実に出せているか」を重要な指標としています。
インクリメントとは、検証可能な価値の集合体を指します。つまり、実際に動作する製品の一部であり、直接確認できる具体的な成果物です。これは実際に価値を提供できる状態まで作り込まれたものを意味します。
ベロシティの代わりにインクリメントの有無で判断する方が、以下の利点を得ることができると考えました：
- チームの成功体験を直接的に可視化できる
- 「動くものを届ける」というアジャイルの価値に直結している
- 見積もりやポイント計算の複雑さに煩わされることなく、成果を評価できる
将来的にはチームの成熟度や人数に応じてベロシティの導入も検討するかもしれませんが、現状はインクリメントの確実な提供を通じて、チームの健全性を確認できています。
2. 専任のスクラムマスター
スクラムマスターの責務である「プロダクト開発における不確実性のコントロール」と「チームの成長支援」は、チームにとって必要不可欠です。
私たちは専任のスクラムマスターを置きませんでした（専任を置けるほど人材的な余裕がなかったとも言えます）。
スクラムマスターには以下のような重要な役割があります：
- チームの障壁を取り除く
- プロセスを改善する
- スクラムの価値と実践を促進する
- 組織の他部門との調整を行う
私たちはこれらの責務を一人に集中させるのではなく、各メンバーの専門性を活かしながらチーム全体で分担することにしました：
- EM
- スプリントイベントの設計・進行
- 他チームとの技術的な調整
- 開発プロセスの設計・改善・実行
- PdM
- 対外的な調整
- プロダクトに関する障壁除去
- デザイナー
- UX/UI・ブランディング観点での他部門調整
このような役割分散により、以下の利点を得ています：
- チーム全体でアジャイル開発を実践できる
- 各メンバーの専門性を活かした課題解決が可能
- 特定の個人への依存を避けられる
3. バーンダウンチャート
バーンダウンチャートは、スプリントの進捗を可視化する一般的なツールです。しかし、以下の理由から導入を見送りました：
- 効果的な運用には、タスクの粒度を揃えた見積もりと、日次での確実な進捗更新が必要となり、初期段階のチームには負担が大きい
- チームが小規模なため、日々の会話で進捗状況が十分に共有できている
- プロジェクト初期では、作業の見積もりの精度が低くなりがちである
私たちは、GitHub Projectsを使ってスプリントバックログを管理しています。
実際の開発では、スプリントゴールは固定しつつも、その達成に向けた具体的なIssueやタスクは、検査と適応のサイクルを回す中で柔軟に追加・削除・分割を行っています。
このような状況では、バーンダウンチャートでポイントの推移を追跡することはあまり意味を持ちません。むしろ、バーンダウンチャートを採用しないことで得られる利点として：
- スプリントの途中でも柔軟にスコープを調整できる
- チームはスプリントゴールやインクリメントを目標にしつつ、気兼ねなくタスクを変更できる
- より今やるべきことに集中できる
という効果が得られています。
現状の運用方法で十分にチームの状況を把握でき、かつ柔軟な対応が可能になっているため、今後もバーンダウンチャートの導入は考えていません。
採用したプラクティス
1. デイリースタンドアップ
私たちは朝30分程度の同期的なミーティングを、プロジェクトの不確実性に対処する重要な場として位置付けています。特に、スプリントゴール達成に影響を与えうる不確実性を早期に発見し、対応するための装置として機能させています。
そのため、デイリースタンドアップでは目的を明確に絞り、以下の3つのみを行っています：
- チームメンバーのスケジュール（カレンダー）確認
- ブロック予定の可視化
- 予定の急な変更の共有
- スプリントバックログの検査・適応
- 進捗の確認
- ブロッカーの特定
- 直近の課題・話題の同期
- 前日までにSlackに投稿された課題のトリアージと、チームに共有したい話題の確認
- その場での意思決定、もしくはボールの所在確認
デイリースタンドアップでは、対話を重視するために厳密なタイムボックスで運用せず、その日の課題に応じて柔軟に時間を調整しています。
通常、課題や話題が少ない時は15分以内に終わることがほとんどですが、不確実性につながる事案が見つかった場合は、十分な議論の時間を確保します。（とはいえ60分以内には必ず終わらせます）
シンプルにこの3つに絞ることで、スプリントゴールやインクリメントに影響を与えうる不確実性を、できるだけ早い段階で検知し対応することが可能になっています。
2. ペアプロ/モブプロ
XPからのプラクティスとして、サービス開発初期においてペアプログラミングを積極的に活用しました。その目的は、単なる教育的なものではありません。プロダクトの初期実装における重要な意思決定を、対話しながら実際のコードを書くことで一緒に行えるという点が大きな利点でした。ペアプロ/モブプロに一定の時間的なコストがかかることは承知の上で、将来の内部品質を考えればすぐに元を取れると算段しており、実際にその後の開発スピードとコードの質に大きく良い影響がありました。
具体的に得られた効果は：
- コードの書き方やファイル配置の判断基準を、チームで形成
- 手を動かしながら「なぜこの実装なのか」という思考を共有できる
- レビューコストの大幅な削減（実装時に同時レビューができている）
- チーム全体での認知形成の促進
特に初期フェーズでは、「このコードはどこに書くべきか」「なぜそこに書くのか」といった判断を、実際のコードを書きながら行えることで、より具体的で実践的な議論が可能になりました。これにより、プロダクトの実装における重要な指針を効率的に確立できましたし、結果としてサービスチームメンバーが早期に自走できる状態を作ることにも成功しました。
現在は一定の型ができたため頻度は下がっていますが、新メンバーの参画時や、アーキテクチャの大きな変更を行う際などに効果的に活用していきたいと考えています。
3. インクリメントレビュー/スプリントレトロスペクティブ
開発プロセスにおいて、私たちが最も重視しているのが「インクリメント」（動く成果物）です。そのため、インクリメントレビューは開発サイクルの中で最も重要なイベントの一つとして位置づけています。
さらに、このレビューの効果を最大限に引き出すため、私たちはインクリメントレビューの直後にスプリントレトロスペクティブを行うようにしています。成果物を確認した直後は、チームの達成感や課題感が最も鮮明な状態です。この感情が生きているうちに振り返りを行うことで、より本質的で深い気づきを得ることができています。
まず、インクリメントレビューについて説明します。スプリントでの「動くものを届ける」というコミットメントを非常に重視しており、このレビューは単なる進捗確認の場ではなく、チームの成功を確認・称賛する重要な場として位置づけています。そのため、インクリメントの元になるスプリントゴールは以下の点を意識して設定しています：
- スプリント内で確実に完了できる範囲に限定
- 具体的な成果物（動くもの）が見えるように設定
- チーム全員が達成をイメージできる粒度に調整
インクリメントレビューは、FigJamでサービスチーム全体で同期的に行っており、以下のようなテンプレを元にスプリントゴールを確認しながらインクリメントを確認していきます。
私たちのやり方は、スプリントゴール、スプリントバックログ、インクリメント、スプリントゴールに直結しないインクリメントの4つを可視化して、インクリメントとして評価する動作を確認してきます。
続いて、スプリントレトロスペクティブはインクリメントレビューの熱が冷めないうちに実施します。私たちは一般的なKPTではなく、タイムラインを用いたアプローチを採用しています。こちらは、3種類の付箋で出来事を可視化します：
- 事実（いつ、何が起こったか）
- よかったこと（続けたい/伸ばしたいこと）
- モヤモヤ（課題や改善したいこと）
こちらもインクリメントレビュー同様にテンプレがあり、曜日のタイムラインとその上部にリリースなどのインクリメントに代表される生み出した価値を置いていきます。あとは、それぞれの付箋を使ってサービスチームメンバー全員で時間を取って記述していきます。
この2つのイベントを連続して行うことで、チームの持続的な改善サイクルを意図的に作り出しています：
- 成果の確認から振り返りまでの一連の流れでモメンタムを生み出せる
- チームの感情が生きた状態で次のアクションを考えられる
- 達成感や課題感を直接的に次のスプリントの改善に活かせる
このように、チーム全体で「スプリントの成功（や失敗）」を実感し、その実感を次のスプリントへのモチベーションへと繋げていくサイクルを確立しています。
まとめ
私たちのサービスチームは、「スクラムをそのまま導入する」という一般的なアプローチではなく、「結果整合的アジャイル」という形を目指し開発プロセスを構築してきました。
本来、スクラムのイベントやプラクティスを初手から変更することは推奨されません。それは、十分な経験と理解がないまま行う改変が、スクラムから得られる本質的な価値を損なうリスクを伴うからです。
しかし、私たちは以下の理由から、プロダクト開発とチームの自律性に対するオーナーシップを持ってこの選択を行いました：
- サービスチームの成熟度に応じた段階的な改善が、より確実な成果につながる
- プラクティスの形式よりも、サービスチームの実情に合わせた価値の実現を優先すべき
- サービスチーム自身による試行錯誤が、より強い当事者意識を生む
これらの結果整合的アジャイルの取り組みを通じて、私たちは「正しい方法を目指す」のではなく「サービスチームに合った方法を見つける」ことの重要性を学びました。
その過程で、チームメンバーの主体性が高まり、各々の専門性や個性を活かした役割分担が自然に確立されていっている実感があります。
ただし、私たちのチームでワークした方法が、他のチームでも同様に機能する保証はありません。
これは、チームが置かれている現実に向き合い、持続可能な改善を目指した私たちなりの1つの解だからです。
結果整合的アジャイルの本質は、「アジャイル開発を実現するプロセスそのものを、アジャイルに作り上げていく」ことにあります。
今後も形式や方法論に囚われすぎることなく、サービスチームとプロダクトの持続的な成長を支える開発プロセスを追求していきたいと考えています。
最後に
今月末（2025/02/27）の EMConf JP 2025 に「プレイングマネージャーは本当に悪なのか？」というタイトルで登壇させていただきます。
ぜひぜひ、みなさま会場でお会いしましょう。
