スクラムマスターとしての2025年ふりかえり

2025年は私にとって大きい決断の年だったかもしれません。2025年の年末ということもあり、ふりかえってみようと思います。

SaaSでのAgile(Scrum)

今までは事業会社の内製プロダクトにおけるスクラムだったり、サービス提供が主であるプロダクトのスクラムという限られた状況下でスクラムを実践していました。

正確には2024年にSaaSにjoinしたので2025年のふりかえりとしては少し時期がズレますが、SaaSでのAgileは内製プロダクトにはない、独特の「切実さ」がある中でスプリントを回していく必要があります。

逆に、「顧客価値」がより一倍感じやすいという性質があります。自分たちが作っているプロダクトを通して、解決した顧客の課題分だけMRR,ARRという形で返ってきます。(厳密にはCSのサポート等もありますが…。)

これはSaaSというビジネスモデルの面白さであるとも言えます。SalesからCS, Devが一体となってプロダクトを作り、より多くかつ、より重大な顧客の課題(ペイン)を解決していくという行いが自然に行われていくのですから。

DualTrackAgile…?

これも知ったのは正確には2024年ではありますが、2025年にも関係する内容であるため、触れます。

今までは愚直にスクラムというものについて理解をし、情報を収集していたことからいわゆる企画段階のものに対するアプローチ……つまりDualTrackAgileにおける「Discovery」というプロセス段階についての理解がありませんでした。

INSPIREDで触れられていたように、アジャイルコーチは「Delivery(※Discoveryの後に行うもの)」に対して特化しすぎているため、デリバリーコーチと呼ぶべきだ、とあったように私自身もDeliveryに対する理解は高くあったものの、その前段への理解は乏しかった面があります。

このDelivery部分への理解を高めるのも重要ですが、前段のDiscovery部分への理解が高くないとある程度規模が大きくなるにつれ、どんどんビジネスから離れていってしまう可能性が高くなります。つまり、伝統的な開発スタイルへと戻っていってしまう可能性があったり組織として分断された状態(分業化)が促進されてしまい、どんどんチームとしての効果性は下っていってしまうのです。

DualTrackAgileという概念レベルのものを知ることができたため、より大きな規模でのスクラムへ対応できる「きっかけ」ができたように感じています。あくまでも「きっかけ」です。

とりあえず「体験してみる」という点で実際にやっている中に入ってみて、実感としてどんな感想が残るのかを探っていました。

理解せずになぞることによる痛み

「世間で広まっている通説 = 正しい」わけではない

人はよく理解もせず、世間的に大多数が言っていることを鵜呑みにしてしまう傾向があります。(情報判断としては妥当ですが)

たとえば、ダニング＝クルーガー効果です。この名前を聞くだけで「ああ、あの最初はめっちゃ理解したつもりになったけど、その後に全然理解してなかった…」と思い浮かぶやつです。

実際にこれは「ダニング=クルーガー効果」ではありません。本来の「ダニング=クルーガー効果」は

• 能力が低い人ほど、自己評価が高い
• 能力が高い人ほど、自己評価が低い

といったメタ認知について触れるような内容です。

世間的に形成されているイメージは、「ガートナーのハイプサイクル」を説明資料にし、より共感を呼びやすい形に歪められている「ダニング=クルーガー効果」です。

このように、通説を疑い、自分で理解しにいかなければ、いつか痛い目を見ます。それが今年でもありました。

DualTrackAgileの１人歩き

DualTrackAgileというのは超絶簡単に言えば、「Discovery」と「Delivery」の2つのプロセス工程があるよね、というものです。

ただこれくらいの説明で「わかった」という風に理解したつもりになってしまうと、大変痛い目に会います。

たとえば、DualTrackAgileにおいて「DiscoveryとDeliveryで2つのチームに分ける」というのはアンチパターンだとLeanUXでは語られています。理由としては、このチームが2つに分かれてしまうことで各プロセスは早くなるかもしれないが、簡単に言うと「企画するチーム」と「実装するチーム」で2つに分かれてしまうため、分業構造になってしまいます。

そうすると「実装チーム」は「企画するチーム」が考えたソリューションの大枠を破らないように仕様を決めていき実装を進めることになります。そこに顧客理解は必要ではなく、非機能要件として何を満たす必要があるのかだとか、仕様として何ができていればよいのかを知ることが重要になるため、「顧客課題」について考える時間や触れる時間が減っていき、どんどん顧客から心が離れていってしまいます。

ほかにも、n-1スプリントでデータの収集とデザインの決定をし、nスプリント実装していくという1スプリント時差を作るアプローチを取るパターンもあります。

これはLeanUXでは「スタッガード・スプリント」「スプリントゼロ」と呼ばれるアプローチで、ウォーターフォールからアジャイルのプロセスに移行する時には有効ではあるが、プロセス自体としては「ミニウォーターフォール」であると言われるくらい移行期に用いられるものでアジャイル開発を完全に受け入れられていない状態を指しています。

つまり、私の冒頭の文で「こういうものなんだ!」と理解してしまい、流用をしてしまうと、組織の分業化による分断を生んでしまう可能性があります。

※ちなみに最近はDualTrackAgileよりもContinuous Discoveryらしいです。継続的な発見

そもそもどこから生まれている概念?

私も深くは理解していませんが、「UserStoryMapping」が元になっているものだと考えられます。(LeanUXの参考文献や時系列を見ると)

この書籍は「ユーザーストーリーマッピング」という手法について深く書かれているイメージがあると思いますが、それは前半だけで後半にはがっつりとプロダクト開発について書かれており、そこで定義されているのは「Opportunity」「Discovery」「Delivery」というプロセスについてです。

**そしてこのプロセスを踏む大前提的な目的は、「チームの共通理解を築く」ためです。**この大前提の目的を知っているだけで、DiscoveryとDeliveryのチームを分けることが目的に反しているかどうかが判断できます。

今回は深くは語りませんが、このように「大元になっている場所」つまり原典を漁ることで、本来の目的から逸れた風化状態を避けることができます。

そして、そもそも「この概念は本当にこういう目的?」と感じるのはペイン(痛み)を感じた時です。

再三言いますが、今年はそういう経験が多かった年でした。

そして対話へ

この痛みが多い中、一番トピックとして気になるようになったのは「対話(dialogue)」です。

「対話」と聞くと対面で話すくらいのニュアンスのように感じますが、より深い意味合いがあり、ざっくりと表現すると「評価判断を脇に置いて話し合うこと」というニュアンスです。

結局のところ、どんな課題があっても「対話」が必要だということを感じてからは「対話」に対して関心を強く持つようになりました。

専任スクラムマスターとしての迷いと意味付け

転機があり、6月から専任スクラムマスターとして働く機会が訪れました。

チャンスがきたら絶対に逃すな、という価値観を持っているのでその機会を受けました。

構造的問題による専任スクラムマスターの無力さ

最初私がジョインした時は職能型チームの構造になっていて、職能型チームに放り込まれ、なおかつ両手を越えるくらいの人数がいる状況で、スクラムマスターとしてのアクションが取りづらすぎることを理解しました。

オンボーディング期間というのもありますが、実際そのチーム状態でチームに対してアクションを行えた記憶がありません。それくらい何も手を出せない状態でした。

そもそも同じことをしていないので集ることに意味がない、集まる機会がなければ変革の機会もほとんどないし、望まれていない。そんな状況が構造的に生まれていました。

幸いマネージャーの方が1on1を通して、この状態に対するペインを各メンバーから吸い上げられていたので私が採用されたわけですが、本来であれば相当変革の機会が生まれにくい環境だったかのように感じます。

こういう状況でできるアプローチとしては、とりあえず会議体の観察を行いつつ、そもそもの構造部分へとアプローチを行うことです。

チーム構造が機能不全を起こしているのは明らかなので、先輩スクラムマスターの人と機能横断型チームへの移行提案を絵を書き一緒に持っていくことを行いました。

私はまだ入社して間もないため、理想像の絵を書き、それを先輩スクラムマスターに理解してもらいつつ、提案の場では頼る…くらいしかできなかったのですが、柔軟な組織のためサクっと機能横断かつスモールな体制へと変化しました。(デザイナーとエンジニア数人のチームでしたが、ファーストステップのスモールチームとしては十分でした)

PO役割不在による課題は色々発生する中、スクラムにゼロから立ち向っていくチーム体制としては十全なものだったかと思います。

チームの自律性の高さによる戸惑い

チームメンバーの自律性が高く、スクラムへの受け入れマインドも高かったせいか、スムーズに進み、スクラムマスターとして自分はどこに介入するほうが良り効果が高いのか迷った時期があります。

スプリントレトロスペクティブはある程度型ができるまでは自分が持ちつつ、それ以外の進め方はそこまで口を出さなくても進む状態でした。

同時にスクラムガイドの輪読会を開催し、チームで足並みを揃えてスクラムに対して理解度を高めていくことで、自分達で判断や内省できる状態になっていました。

スクラムマスターとして、何をすべきなのか……戸惑っている時期もありました。

プロセスオーナーとしての振る舞う

ただ、その戸惑いは「ヒト(チーム)に対して働きかけて効果性を高める」という点に固執しすぎているからだと内省を通じ、理解をしました。

そこで別の視点として、プロセスオーナーとしての振る舞いをしてみようと考えました。実際にチームが辿るプロセスなのでチームに対して働きかけていると言われればそうですが、プロセスに対して働きかけ、プロセスのオーナーとしてプロセス自体に対して強く責任を持つような振る舞いを行い、プロダクト開発プロセス自体の効果を高めることに集中しました。

その結果組織で微妙に分断されているものを1つに統合する動きをしたり、よりプロセスが効果的になるようにチームにインプットを行っていくという動きを行えたため、結果的にはプラスだったのではないかなと感じています。(Notion/JiraからLinearへ一本統合は後々響いてくるレバレッジの大きい取り組みだったと思っています)

プロセスサポーターとしての振る舞い

今年はプロセスオーナーとして、組織レベルのプロセスの大枠を決めていくことに注力する機会が多くなりました。反面、ヒトやチームという部分に働きかけるスキルは、磨かれる機会が少なかったように感じています。

今後プロセスをサポートする役割として、チームがプロセスを改善していけるようにサポートしていく振る舞いが必要になっていき、ここで前述した「対話」というスキルが価値を発揮してくると思っています。

これは2026年のトピックでもあります。

よりビジネスとしての完成度を高める

プロセスとして整ってきたとはいえ、まだ完成度は30%くらいだと感じています。

実際にビジネスとして評価されるかと聞かれるとそうではありません。実際にアウトプットが重視される組織になった途端、私は解雇されるでしょう。

そんな状況でいつまでもいるわけにはいません。実際に自分達のプロセスがどのような価値を発揮しているのかという点で私やチームが語れるようになっていなければいけません。

そして、自分たち自身も常にその状態をウォッチし、健康診断として活用していかなければ気づかないうちに腐敗していた、なんて状況になっていきます。

ここも2026年に取り組むトピックとして、計測とビジネスの関係性をより強固に、わかりやすくしていく必要があると思っています。

プロセスにかける時間が多い一年だった

ふりかえりを書いてみて感じるのは、プロセスに対してどれだけ自分が頭を割いていたかがわかる、ということです。

どのセクションでも、どの部分でプロセスについて話しています。プロセスへの理解度が低い自分からプロセスへの理解を高めるためにプロセスへ関心を寄せていて、よりプロセスの成熟度を高めるために尽力しています。

ヒト部分へのアプローチも大切で自分は好きですが、プロセスを考えるのも同じくらい大切で好きなんだなということを実感した一年でもありました。また、プロセスの方に関心をずっと割き続けられるような組織、ということにも感謝しかありません。

2026年はより、スクラムマスターとしての言語化やチームのアクティビティの詳細へ立ち行っていく必要があり、時にはコーチングなどでヒトへ働きかける必要も出てくると思います。

また、来年も成長していける機会がたくさんありそうな予感がしています。