2025年10月3日・4日、アジャイルコミュニティの祭典「スクラム祭り」が開催されました。
SHIFTからは、製造ソリューションサービス部 PMの髙橋直規が「定期的な価値提供だけじゃない スクラムが導くチームの共創化」というタイトルで登壇しました。
ウォーターフォール開発に長年携わってきた経験から、スクラムの中心にあるのは「定期的なプロダクト機能のリリース」と捉えていたという髙橋。しかし、あるアジャイルコーチとの対話をきっかけに、気づきを得たといいます。
本レポートでは、高橋が「スクラムは共創するチームへと成長を促す仕組みである」と認識を転換し、その本質的な価値に気づき、実践するまでの変遷を追います。
-
製造ソリューションサービス部 髙橋 直規
エンジニアやPM、サービスマネージャー（※）として、さまざまなシステム開発案件などに携わった後、アジャイルを専門的に扱うために、3社目として2023年3月SHIFTに入社。現在は、SHIFTの「アジャイル」にまつわるさまざまな案件に入り、プロジェクトマネジメントから実務となるエンジニアリングまで、幅広い領域でアジャイルサービスの浸透／普及に従事している。
（※）複数案件を管理し、滞りなくサービス提供ができるよう責任を担う立場。
目次
スクラムの価値＝定期的なプロダクト機能のリリースにある、という当初の認識
VUCAの時代と呼ばれる現代において、数ヶ月や数年単位の長期計画を前提とする伝統的なウォーターフォール開発では、計画時にほしかったものが完成するころには不要になっている、という事態が起こりがちなのはみなさんも周知のとおりです。
一方、スクラムでは計画からリリースまでのサイクルを短く区切り、スプリントと呼ばれる単位で開発を繰り返します。そのため、市場の変化やユーザーからのフィードバックに柔軟に対応することが可能です。
「スクラムの価値とは、この短いリリースサイクルによって、不確実性の高い時代の要求にプロダクトを追随させられることにある」。私は当初、スクラムの価値をこのように定義していました。
言い換えると、「プロダクトに求められる要求が事前に固まっていて、市場の変化による影響も少ないのであれば、スクラム開発を選択する必要はないのではないか」と考えていたのです。
そのような場合は、従来のウォーターフォール開発、あるいはそれを小さく繰り返すミニウォーターフォールで対応できる。
プロダクトの特性、つまり要求の変動性が高いか低いかによって、開発プロセスは適切に選択すべきだ。これが、当時の私がたどり着いた1つの答えでした。
「入力・プロセス・出力」の構造で整理する、スクラムの本質的価値
考えを改めるきっかけになったのは、日々の業務における、アジャイルコーチとのやりとりでした。そのアジャイルコーチが、Slack上で一本の記事を共有してくれました。
それは、著名なアジャイルコーチである吉羽 龍太郎 氏による『実は相性が悪い「開発生産性」と「アジャイル」』という記事でした。
その記事には、「物的生産性を高めたいなら、ウォーターフォール方式で決まった機能を決まったように開発すればよくて、アジャイルをとり入れる必要はないと思います」という一文がありました。
これを読んで、私は自身の考えが裏づけられたように感じました。当時、私が担当していたプロダクトは事業計画によってバックログがほぼ固まっており、機能を実現することが優先されていました。
そんな状況で、私は「スクラムの主目的が、不確実性が高い機能の実現に対する定期的な検証である場合、やるべきことが明瞭でブレが少ない場合は、ウォーターフォール開発でよいのではないか」と発言しました。
それに対し、当時同じプロダクトを担当していたアジャイルコーチは「最近は、プロダクトもしくはアウトカム（価値・成果）だけではなく、スクラムチームも含めて考えると頭の整理がしやすいと思っています」と返してきました。
プロダクトやアウトカムにスクラムチーム自身も含めるという考え方は、当時の私にはないもので、大きな気づきだったのを覚えています。
その後、そのアジャイルコーチの言葉をヒントに、私はスクラムの構造を改めて整理しなおしました。物事を「入力・プロセス・出力」の構造で捉えてみたのです。
出力が「スクラム開発によって生み出されるプロダクト機能」、プロセスが「プロダクト機能を生み出すための、スクラムという枠組み」であるなら、入力は「スクラムチーム」。
これまでの私は、「プロセス」と「出力」にしか意識が向いていませんでした。
スクラムが短いサイクルでリリースを繰り返すのは、単にプロダクトを市場に追随させるためだけではありません。
リリースしたプロダクトから得られるフィードバックは、プロダクトだけでなく、それをつくり出した「スクラムチーム」自身にも還流されます。
つまり、スクラムの真の価値とは、不確実性に対応することに加え、プロダクトを成長させるチームそのものを醸成することにあるということです。
たとえ要求が決まっていたとしても、プロダクトを持続的に成長させていくためには、それを支えるチームの成長が不可欠です。
スクラムは、プロダクト開発の経験をチームの成長につなげ、その成長したチームがさらによいプロダクトを生み出す、という好循環をつくり出す仕組みだったのです。
スクラムガイドを“チーム視点”で再解釈し、実践を繰り返す
これを理解してから、私はスクラムガイドを改めて読み返し、その理論を実践しました。
スクラムガイドには、スクラムを支える5つの価値基準（確約・集中・公開・尊敬・勇気）が定義されています。私はこれらを、プロダクトではなく「チーム」の視点で以下のように捉え直しました。
3.チーム開発での実践
スクラムの5つの価値基準
確約：共通のゴールに対するお互いのサポートを確約
集中：個人個人ではなくチームとしてスプリント作業に集中
公開：心理的安全性をもとに作業や課題の公開を実現
尊敬：お互いに能力のある独立した個人として尊敬(原文まま)
勇気：立場や役割を越えて正しいこと、困難な問題に取り組む勇気
また3本の柱（透明性・検査・適応）についても捉えなおしました。
透明性：作業の進捗だけでなく、「作業を実行する人と、その作業を受けとる人」の関係性にも透明性をもたせることが重要である。
検査：作成物や進捗状況の健全性だけでなく、スクラムチームの健全性に対する検査も重要である。
適応：プロセスやプロダクトに求められる要求に、スクラムチーム自身も適応させていく重要性がある。
この再解釈をもとに、チームではさまざまなアクションをとってきました。
●常時ハドル（公開、集中、透明性）
チームの心理的安全性を高め、コミュニケーションを活性化させるためにSlack上につねに開かれているハドルを設け、誰かが困っていたり、作業が詰まったりした際に、すぐに相談できる環境を整えました。
これによって、個人の問題をチーム全体で解決する文化を育み、チームとしての推進力を高めることにつながりました。
●バグバッシュ（尊敬、勇気、確約、検査）
スプリントレビュー時に、完成した機能をチーム全員で実際にさわる会を実施。
これにより、リリース前にプロダクトの品質に対する全員の合意を形成するだけでなく、開発者やプロダクトオーナーといった役割を超えて、機能の使われ方について互いに学び合う機会を創出しました。
●仕様共有（集中、公開、適応）
知識の属人化を防ぎ、チーム全体のシステム理解度を向上させるための仕様共有ミーティングを随時開催しました。
仕様策定した結果や設計内容をチームの共有財産とすることで、チームとしてのシステム理解へと昇華させることができました。
●ふりかえりの目的の見直し（公開、尊敬、勇気、透明性、検査、適応）
それまでのふりかえりは、出てきた課題に対して解像度が十分でないまま解決策を考えることに終始しがちでした。
しかし、チームで「なぜふりかえりを行うのか」を深く議論した結果、「個々人が抱える課題感を、まずチームのものとして共有し、認知を合わせることが重要だ」という結論に至りました。
これにより、ふりかえりは「解決策を考える場」から「チームで課題に対する認知を醸成する場」へと変わりました。
たとえその場で完璧な解決策がみつからなくても、チーム全体で課題に向き合いつづける土壌が育まれたのです。
こうしたスクラムの価値基準と3本柱に根差した実践を繰り返すことで、プロダクトもチームも着実に成長していきました。
スクラムは、“機能”だけではなく、共創するチームへと成長させる仕組みである、というのが今回の登壇で私が伝えたかったことのまとめになります。
この記事を読んだあなたも、「私のチームは、スクラムというプロセスを通じて、プロダクトとともに成長できているのか」ということを、ぜひ一度考えてみてください。
（※本記事の内容および対象者の所属は、イベント開催当時のものです）
