この記事はスタンバイ Advent Calendar 2022の24日目の記事です。
私がスタンバイのPdMとして（最初はPOとして）活動してから11月でちょうど4年が経過しました。
さまざまな課題がありながらも、その都度やり方を変え組織を変えて邁進してきた結果、今では追っていた主要KPIは3.5倍へと成長を遂げました。
当時を振り返りながら、PdMとして（POとして）プロダクト開発を進める上で学んだことを共有したいと思います。
2018：Scrumへの挑戦
私がスタンバイに参画した当時、Scrumを本格的に導入し従来のピラミッド型組織での開発から脱却を図ろうとしているタイミングでした。
当時の開発組織規模は現在の約3分の１。Scrumチーム数は３チームで、それぞれにMGR、Leaderは配置せずにフラットなチーム構成。
全てエンジニアで構成されており（FE及びBEの混合チーム）、PO及びScrumMasterは特定のScrumチームに所属することはせずに、全てのチーム共通で配置（全てScrumチームに関わる立場として配置）しました。
また、Scrumは知識を得るのは容易（さほど難しくない）だが、習得するのはすごく難しいと言われていたため、当時は外注でコンサルを雇ってアドバイスを受けながら進め主体性を大事にしながら開発を進められる体制を目指しました。
ただこれにより発生したことは、約１ヶ月の開発停止。
「決め方を決める会議」のように、ピラミッド型組織では明確になっていた意思決定者が曖昧になったことで、どのように、いつ、誰が決めるのかがまず誰も分からなくなる問題が発生しました。
誰もが同じ立場（役職等なくフラットな関係）であるため、意見が食い違った場合に議論は平行線となり決定までに毎回かなりの時間を要するという状況に陥ってしまったことで、開発どころではない状況になってしまったのです。
また、ピラミッド型組織の動きに慣れているメンバーが多いことで、自ら発信する、議論して決めることに慣れておらず、いっこうに物事が決まらない、進まない状況にフラストレーションを溜めるメンバーも多く、結果としてコンディションも悪い方向に向かってしまいました。
そのような状況から退職者も徐々に出始め、誰も状況を打破することができず議論しても「Scrumをやめるか／意志を持って継続するか」ばかりで結論がでないまま時ばかりが過ぎていったのを良く覚えています。
このように、私がスタンバイに参画した2018年当時は、開発どころではない組織環境でPOといっても何もできずに右往左往するしかない状況で課題しか存在しない状態でした。
2019~2020：LeSS（Large-Scale Scrum）への挑戦
そんな状況を踏まえて、2019年、2020年はLeSSに体制を変えて開発を進めてきました。
とにかく、いっこうに進まない開発を前進させるにはどうすべきか？既存の枠組み（Scrum体制）の中で解決するにはどうすべきかをひたすら模索していました。
そこで当時まず始めたのがArea制の導入です。
当時、全てのドメインを全てのエンジニアが受け持つ進め方であったため、Sprintごとに（当時は1週間Sprint）やる領域が変わっていくため知識もスキルも身に付き辛く開発に必要以上に時間が掛かっている問題がありました。
Scrumという既存の枠組みを維持した上で上記の問題を解決するにはどうすべきが考えたところ、シンプルにArea（開発領域）を分けて開発を進めることのが良いと考えたのです。
新たに、PO（私）の他にArea POを設置し、領域ごとにバックログを作成し開発を進めることで開発のスピードアップを狙ったのですが、今度は結果として
・ プロダクト全体で考えている優先度（POが考えている優先度）と各Area POで考えている優先度が噛み合わず全体最適化が図れない
という問題が新たに浮上しました。
狙い通り、Areaを絞ったことでスキルや知識の蓄積が進み開発スピードは向上したものの、全体として優先されるべき開発タスクにリソースがうまく配分されないことで、結果として優先度の高い開発タスクの進捗は悪くなってしまったのです。
個々の開発スピードで見ると確かに改善しているが、全体で見ると優先したいことが進まない。
これでは、本当に求めていた開発スピードの向上が図れたのかどうか分かりません。
また、相変わらず議論に時間を要するため、何事も決めるまでに時間を要するのは変わリませんでした。
この結果を受けて、次に試みたのがLeSS（Large-Scale Scrum）への挑戦です。
とは言っても、単に以前やっていたScrumのやり方はそのままに、規模を大きくしただけなので、そこまで大きな変化は加えていません。
全体としてPO、SMを配置するのは変わらず、その下の Area PO設置は廃止しました。
開発優先度は全体として管理するバックログに一本化しそこから各 ScrumチームのSprintバックログに落とし込むことで開発を1週間Sprintで進めていきました。
単に規模を大きく、その上で2018年当時のやり方に戻したため、また同じような問題が発生することを懸念しましたが、Area制にしたことで一定のスキル、知識がそれぞれのScrumチームに溜まってきていたことでScrumチームに特色が出始めており、このタイミングであれば以前のような問題（毎週やることが変わることでスピードが出にくい）は発生しないと判断しました。
変更点を挙げるとすると、新たにOverall Refinement（プロダクトチーム全体でのリファインメント）、Overall Retrospective（プロダクトチーム全体でのレトロスペクティブ）をイベント設定し、週次で全体の開発方針、優先度や各チケットを受け持つチームのアサインに認識のズレが出ないようにし、またやりながら生じた課題を全体で解決できるようにしたくらいになります。
この変更によって、Area制にしたことで発生していた全体最適化の問題は解決し、またArea制で溜まったスキル、知識を活かせるようになったことで以前よりも開発スピードを落とさずに開発プロセスを回せるようになりました。
相変わらずScrumを導入する前提条件は変えず、それでもなんとか目の前の課題を解決しながら前進してきたことで着実に前進が見え始めてきましたが、それでもまだ問題は残っており、それが、
・ レビューが適切に機能しておらず、ステークホルダーから見て開発をうまく進んでいるのかどうか判断しにくい
・ 意思決定者不在は変わらず相変わらず議論に時間を要し開発スピードが出にくい
・ 新たなドメインの開発に着手する場合、Area制で培ったスキル、知識は意味をなさず、結果としてどのチームにも新ドメインの知識、スキルが溜まりにくい
の３点です。
解決した問題はあれど、それでもまだまだ問題は山積している状況で、前進はしているがやりにくい、モヤモヤする状況であったことを良く覚えています。
以上の状況の中、振り返ってみると学んだことは以下の２点です。
1. プロダクト開発を進める中で、大枠抑えておくべき点は「全体最適の担保」「知識・スキルの蓄積」「レビュー・意思決定者の可視化」の３点
2. 諦めずに解くべき問題を議論し前に進むことができれば着実に前進はする。すぐ変更するのではなくて何が改善して何が問題として残っているのかを見極めてNAを決めるのが大事。またそれ以上に胆力を持って逃げずに取り組み続けるのが何よりも大事
2018年からずっと問題に感じ、なんとかしようとしてきたことはシンプルに「開発スピードの向上」だったと感じています。
そしてそれは、プロダクト全体として優先すべきことは何か？ということを明らかにした上で適切にリソースを振り分けることと、実際に各チーム／個人が開発するに当たって知識やスキルを付けていくことで実装スピードを早めるということであったのかなと思います。
問題に向き合い施策を実践してきたことで何が良くて何がダメだったのかを把握することができましたし一定の成果を上げることはできたと感じていますが、まだ着手できていない問題としては意思決定スピードの向上であり、この3点が上手く噛み合った組織体制、プロセスを作ることができれば一定の開発スピードを伴ったプロダクト開発ができるのではないかと考えています。
また、これはある意味根性論にはなりますが、問題が大きく解決が難しくとも諦めずに取り組み続ければ着実に前進はするものだと感じることができたのは個人的に大きな成果でした。
一度決めたことを一定期間やりきってみて、その結果を都度評価、議論して取り組めたので何が良くて何がダメだったのか実体験を通じて学ぶことができましたし、逃げずにやり切れたことで胆力をかなり鍛えることができました。
問題解決には、小手先の理論やテクニックでなく、何よりも胆力が大事であると感じることができ、これはどの環境、組織でも必須なのではと思っています。
2021~現在：Scrum原理主義からの脱却と開発プロセスの最適化
今までの三年間の経験から、２０２１年は「レビュー、意思決定者の可視化」の要素を取り入れた形で新たな体制に変更し開発を進めました。
中でも、最も大きな変化が、Scrum原理主義からの脱却です。
今までは前提としてScrumの推進があったことでかなりバイアスがかかってましたが、改めてなぜScrumをやるのか？に立ち返り課題を1から整理し直し、その上で現状最善であると考えられる体制にシフトしました。
これは、これまでScrumを前提として頑張ってきたものの、レビュー・意思決定の可視化についてはフラットな環境を一度リセットして考えなければ難しそう、というのが大きな理由です。
そこで新たに始まったのが「ドメインごとにグループを組成し、新たにグループマネージャー及びPO、テックリードを配置した上で責務を明確にする」という体制です。
2019年に実践したArea制をグループと呼称を変更し、フラットな環境ではなく役職を設けて管理できるようにしました。
またドメインを固定したグループになっているため、スキル・知識も蓄積でき、全体で定めたロードマップ、バックログに対して各グループのやるべき開発タスクや目標を設定し、それを前提に各グループのPOがグループ内でタスク消化するように変更したことで全体最適化についても担保。
加えて、週次で進捗のレビューを行うイベントを設けることで開発が上手く進んでいるのかを可視化し、ズレていれば方向修正できるように計らいました。
その上で、今まで実践した中でScrumの良いところは取り入れるという形です。
この結果、全体で考えている戦略とのギャップがなくなり、かつ意思決定プロセスが明確になったことで議論や意思決定に何日、何週間も時間を要することは無くなりました。
また時が経つにつれて知識、スキルがグループに蓄積し現場の開発スピードも向上したことで、さらにプロダクト開発が前進、当初狙った通りの結果を得ることができるようになりました。
冒頭で記載した通り、主要KPIは約3.5倍まで拡大し（費やした期間を踏まえると物足りない数字ではありますが）、着実に数値として結果が出始めています。
特にここ最近の数字の伸びは大きく、軌道に乗ってきた感触を得られたことは大きな成果だと感じます。
私がこの改善と結果により学んだことは以下の２つです。
１. 原理原則に囚われず Issueドリヴンであるべき。「役職者を設けずフラットな環境」等、現状の組織状況を鑑みて厳しければ最初からやらずに、まずは顕在化している課題のうち改善できそうな部分からScrumの導入を進め、最終的に自己組織化（フラットな環境）を目指すなど少しずつ登っていくのが良さそう
２.意思決定者はステークホルダーにする等、明確にした上で適切な頻度、場所（イベント）でレビューを行えるプロセスを導入すべき（いずれ自己組織化してきたタイミングで権限移譲していくべき）
まず１つ目は、書籍に書いていることやコーチが発した言葉をそのまま受け取って進めない、ということ。
書籍ではこう言っているから正しい、誰かがこう話しているのだから正しい、というように、原理原則に引っ張られてしまうとそれを忠実に守ろうとすることのみに意識が寄ってしまいます。
とりあえずそれを実現するためのHowばかりがフォーカスされ、実は最も意識すべきWhyが抜け落ちてしまい、いつの間にかScrumをやることが目的になってしまいます。
事業スピードを向上させる=>そのためにはメンバーのスキル、知識、成長が必要=>そのためにはまずはここが課題、というように、Whyを分解し本来見据えていた目的を達成するために本質的な課題を特定しながら徐々に山を登っていくことが重要だと感じます。
当時も、Scrumを正しくやることばかりに意識が向いてしまい、Scrum Guideに書いていることが全て正しいのでそうすべき、という感じでなぜやるのかも考えずに突き進んでしまったことで、組織が空中分解し開発がストップ、逆にスピードが落ちて事業が成り立たなくなりました。
ですが、一度考えをリセットしScrum原理主義からの脱却を図ったことで状況を好転させることができました。
大事なのは現状の可視化と問題・課題の設定で、その上で課題解決確率の高い打ち手を出すために書籍やコーチの話を聞く（参考にする）、という順序でなければ物事は進まないのだなと経験を通じて学びました。
そして２点目。
意思決定者の明確化と意思決定者によるレビュー機会、プロセスの設計は物事を決めて前に進める上では非常に重要だと感じます。
Scrum原理に則って進めていた当時、実際これができていないことで意見が食い違った場合に収拾がつかず、開発を前に進められないことが多々ありました。
組織課題によってはいきなりフラットな環境を導入することもあるかとは思いますが、その場合においても議論が紛糾したら最終的にPOが決定するなど、今までの経験を通じて意思決定者とレビュー機会の創出は必ず必要だと考えています。
まとめ
今までの経緯より、私が学んだことを改めてまとめると以下のような感じです。
1. 原理原則に囚われずIssueドリヴンであるべきだよね
2. プロダクト開発で、抑えておくべきは「全体最適の担保」「知識・スキルの蓄積」「レビュー・意思決定者の可視化」
3. 胆力ってめちゃくちゃ大事
特に１は一見当たり前のように見えるんですが、意外とできていないケースって多いと思ってます。
背景（どうして今そんなことしているの？）、背景踏まえて現状の課題ってどの辺だろう？ってところを理解せず、深ぼらずに進めてしまうことで原理原則（この本に書いてあることが正しいのでこの通りにやるべき）を当て込もうとする動きってかなり多いと思っており、最も意識すべきことだと感じています。
あとは３も。
キツイと逃げたくなるんですが、やっぱりやり切ることで経験と学びに繋がり自分の財産になると思うのであらゆることに重要な力だなと改めて思いました。
以上、これまで四年間のプロダクト開発の歴史から学んだことです。
同じような問題を抱えている組織も多いと思うので、何かの参考になれば嬉しいです！