3年で10倍に拡大したスタートアップで考え続けた、アジャイル開発をスケールするために大事な5つのこと
atama plusでスクラムマスターをしている河口です。
2018年7月に、当時社員数が15、16人だったatama plusにジョインしました。2021年12月現在で社員数は170人になり、10倍以上に成長する過程をatama plusで過ごしました。
入社後8ヶ月間はカスタマーサクセスをしていましたが、2019年からはプロダクトオーナーとして小さなチームで開発をしていました。仲間が増えていく中で、開発組織のスケール方法に会社として向き合い始めたタイミングの2020年1月、1人目のスクラムマスターとなり現在約2年が経とうとしています。
スクラムマスターとしての約2年間、開発組織のいろいろな課題に取り組んできました。振り返っても反省と学びの連続です笑
今回は、そんなぼくがatama plusの開発組織を拡大する中で学んだ5つのポイントをnoteに書きたいと思います。
急拡大するスタートアップで、開発体制をどうしていくか悩んでいる方の参考になれば幸いです。
【ポイント①】職種（職能）と責務を分けて考える
メンバーが増えていくほど、役割分担を細かくしていく必要があります。「役割分担」というとシンプルに聞こえますが、どう役割分担するかでメンバーの動きは変わっていきます。この役割分担を整理するときに、「職種（職能）」と「責務」の話がごっちゃになりがちです。
特にアジャイル開発のような職能横断型のプロダクトチームを拡大するのに、「職種（職能）」と「責務」を混同したまま開発体制を検討すると、過度な役割分担を生み出してしまいます。
そのため、まずは「職種（職能）」と「責務」をしっかりと区別して検討していくことが重要です。ちなみに僕の中での整理は下記になります。
職種（職能）
「職種（職能）」とは、UXデザイナーやエンジニア、QA、プロダクトマネージャーといった、専門性を表すものになります。もう少しわかりやすく言うと、「あなたの職業はなんですか？」という質問に対するアンサーです。各職種（職能）はその専門性を発揮することが期待されています。
※プロダクトマネージャーは職種と捉える文脈と責務と捉える文脈がありますが、ここでは職種という整理で記載しています。
責務
一方で「責務」とは、組織体制上の立ち位置ごとに求められる責任範囲のことを指します。例えばスクラムというフレームワークにおいては、プロダクトオーナー、開発者、スクラムマスターなどは職種（職能）ではなく、責務を指します。
他にマネージャーも責務の1つだと思います。マネージャーがどういう責務を求められるかは組織によって異なるという観点からも、職種ではなく責務の1つと捉えた方が良いと思います。もちろん責務を果たすために必要なスキルが何かという話はありますが、それは組織体制上の位置づけによって異なります。
他にもスクラムチームでのプロダクトオーナーを例に考えてみると、開発基盤を担うスクラムチームと、ユーザーが使う機能を作るスクラムチームでは、プロダクトオーナー（責務）に求められるスキルはそれぞれ異なります。
所属
また今回のnoteではあまり触れませんが、「所属」という切り口もあるとおもいます。所属は、個人が組織図上のどのチームに所属するかを表します。あるチームに所属するということは、そのチームが目指すミッションに対して「共同責任」を負うことになります。
所属は入れ子構造になり、チームのミッションに対して共同責任を負うと同時に、所属する事業部のミッションに対しても共同責任を負うことになります。ここでいうチームとは、「UXチーム」など職種によるものや「Growthチーム」のような目的によるもの、「予約サイトチーム」など対象を表すものなど、議論をややこしくしたりもします。
【ポイント②】職能・責務のそれぞれを拡大する
例えばエンジニアが増えると、開発できるリソースが増えますが、このとき同時にプロダクトマネジメントするリソースやUXデザインするリソースも必要になります。そのため、組織の拡大に伴い、どういうバランスで職種（職能）を補うかを考える必要があります。
一方で、上記の話はプロダクトオーナーという「責務」を増やすこととは別の話です。
例えば、LeSSというフレームワークの場合は、複数チームに対して、プロダクトバックログを1つにして、その優先順位付けをする責務は1人です。つまり、プロダクトバックログの意思決定の責務を1つにし、さらにLeSSの原理原則を守ることで開発組織のアジリティを上げる方向へ力学が働いていると思います。
しかしこれは、大人数の開発者に対して、プロダクトマネジメントスキルが1人分で良いと言っているわけではありません。LeSSは、あくまでプロダクトオーナーの責務を1つにおくというフレームワークです。ビジネスの状況、プロダクトの状況、チームの状況によって、職種（職能）のバランスは様々ですが、プロダクトマネジメントスキル1人分で大勢での開発を回そうと思うと回らなくなる可能性があります。
このような状況のなかで、プロダクトマネジメント（職能）のリソースの獲得方法は外からスキルを持った人を連れてくる方法と、チームが学習しながら習得する方法があり、両方の観点から、バランスを検討することが大切になります。
atama plusでもLeSSを導入した当初、各フィーチャーチームに求められるレベルが上がる中で、様々な取り組みをしてきました。
LeSSの考案者であるBas Voddeもプロダクトマネージャー（職能）の話とプロダクトオーナー（責務）を分けて議論しています。
（一部引用）
On the Product Owner Role
Final note: We are talking about Product Management here and not the role of Product Owner. In LeSS, the Product Owner focuses on overall Product vision, prioritization, and investment decisions. In product companies, the Product Owner tends to be one senior person from a Product Management group, but not all Product Managers will be Product Owners.
プロダクトオーナーの役割について
最後に注意したいのは、ここではプロダクトマネジメントについて話しており、プロダクトオーナーの役割については話していないということです。LeSSでは、プロダクトオーナーは、プロダクト全体のビジョン、優先順位付け、投資決定に注力します。プロダクトカンパニーでは、プロダクトオーナーはプロダクトマネジメントグループの中の1人の上級者であることが多いですが、すべてのプロダクトマネージャーがプロダクトオーナーになるわけではありません。
<Deep Lの翻訳>
【ポイント③】戦略の不確実度合いによって組織拡大の方向性を考える
戦略の不確実性が高い段階ではプロダクト戦略の方向転換の回数も多く、また解くべき課題も疎に分けきれない場合が多いです。そのため、このような段階で複数チームが並列で課題を解こうとしても、チーム間のコンフリクト、調整コストのほうが大きくなる可能性があります。
かといって課題を疎に分けられたとしても、全チームにとって優先度の高い課題でないと、あるチームは優先度の低い課題に取り組んでいる状況が発生します
そのため、組織を拡大するときは戦略の不確実性、解くべき課題の疎具合と、それぞれの優先度を見極めた上で適切にリソースを割り当てないといけません。
ちなみにatama plusの場合は、まだまだ解くべき課題が複雑で期中でも戦略が変わるため、LeSSという形を取りながら、戦略変更に対する適応をしやすくしています。
それと同時に、最近では開発基盤系の課題の重要度が上がってきており、独立性高く動けそうだったため、1チームスクラムチームを切り出したりもしています。
このように、開発組織の体制はビジネスやプロダクトのフェーズを見極めながら設計していく必要があります。さらに、人を採用したり体制を変更するたびに、その体制がうまく機能するまでに慣らし期間も必要なので、先々を見越した採用計画、体制設計が必要です。
その他には、組織拡大のなかでの体制検討の例として、全体工程の上流から下流に流れるプロセスの中で役割分担をすることもあります。（例：企画チームと開発チームなど）
この方法を否定はしませんが、過度に進めていくと、開発の下流工程だけアジャイル開発になっており、組織全体でみるとウォーターフォールになっているケースもあります。
個人的にはウォーターフォール否定派ではないですが、上流から下流に流れる中でシームレスな知識受粉を行うことを意識しないと責務の分断が発生し、発注と受注のような関係性が生まれてしまうのでは考えています。
※ウォーターフォール開発についてはいろいろな捉え方がありますが、ここでは「責務の分断」の例としてウォーターフォール開発をだしています。
柔軟に動きやすいチームサイズを保つために、一定の役割分担は必要という前提をもちつつ、分け方については慎重に検討する必要があります。
一方でスタートアップは採用に踏むことも超重要なので、両者のバランスを考えた開発体制の検討は一生付き合わないといけない課題なんだと思います。
【ポイント④】責務設計に遊びを持たせることで組織学習が回る
開発体制の拡大とは少しずれますが、組織設計をする上で大事なのが「組織学習」をする余地を作ることだと思います。
組織設計をするときに、開発プロセスを整理することがよくあります。しかしそれは現時点、または理想のスナップショットに過ぎません。現状の開発プロセスを整理した後は、責務の設計として、どこに共同責任をおき、そこにどういう職種（職能）が必要かを整理します。
組織は同じ責務範囲を持ち、権限移譲されることで、その責務を果たすために組織学習が回りはじめます。逆に過度に役割分担した開発プロセスを組織に当てはめると、役割・チームを越境する動きが起きにくくなり、組織学習が回らなくなります。
たとえば、UXデザイナーやエンジニア、QAが職能横断チームを組んだ場合、その中で過度に役割分担するのではなく、共同の責務を果たすためにどのような戦術をとるかはチームに委ねます。そうすることで、はじめはスキル不足だったり、やり方がわからない中で学習・工夫を重ねていき、お互いに補い合うことでチームとして成長していきます。
この組織学習を加速させるのがスクラムマスターの役割だと思います。チームが自律していくために不足している要素を見極めて、チームの視座をあげたり、フィードバックしながらチームとともに成長していきます。
atama plusも昔はUXデザイナーとエンジニアが過度に役割分担をして、協働が生まれていませんでした。スクラムマスターを始めた当時、「UXデザイナーとエンジニアで一緒にリファインメントをしよう」と提案しても、メンバーはイメージが湧いていませんでした。しかし今ではチームでユーザー検証に行ったり、UXデザイナーがテストケースをレビューしたり、ときにはしっかり役割分担したりと各チームそのときどきの課題を乗り越えるために試行錯誤し、様々な戦術が生まれました。
【ポイント⑤】守るべき、育てるべきは「強いカルチャー」
ビジネス状況、プロダクト状況によって、組織戦略は変わっていきます。その変化の中で、適応能力を一定程度保ち、組織学習をしていく構造・カルチャーを作り続けることが最も大切であると思います。
atama plusでは全社的にカルチャーにかなり投資をしており、その上で開発カルチャーも育っています。ベースとなるカルチャーがあるからこそコミュニケーションの前提が揃い、軽快な意思決定、適応ができるのだと思います。
組織構造を作ることでその構造に適応したカルチャーができますし、カルチャーがあるからこその組織構造もあります。ニワトリ卵だとは思いますが、両輪を考えながらカルチャーに投資し続けることが、組織の拡大に最も大切なんだと思います。
まとめ
今回は3年間で経験した組織拡大での検討ポイントを纏めてみました。まだまだ言語化しきれておらず、わかりにくい部分も多々あったかと思います。ご質問やフィードバックがありましたらいつでもお待ちしております！
また、atama plusでは各職種仲間を募集しておりますので、ご興味があればぜひお話しましょう！
最後までお読みいただきありがとうございました！
Twitterでの情報発信も始めました！atama plusの開発に関する発信を取りまとめてお届けします。フォローいただけたら幸いです。
▼採用ホームページでもLeSSについての記事を載せていただいています
▼会社紹介
よろしければサポートお願いします！活動費に使わせていただきます！