はじめに
今回は以下のイベントに参加した際のレポートを記載します。自分の中の意識を切り替えれるような発表だったのでしイベントに行けなかった方にも伝われば幸いです。レポートの内容としては、実際話された内容と自分の解釈や考えたことを記載します。気になった際は登壇資料公開されてますので、ぜひ資料の方ご確認ください！
登壇概要
登壇者プロフィール：株式会社SODA VPoE 林雅也 様
スニーカー&トレカフリマ「スニダン」を開発・運営する株式会社SODAのエンジニア組織は直近2年半で2名から35名、プロダクト開発組織全体で見ると50名弱にまで急拡大しています。また、組織の急拡大と同時に、プロダクトのMAUも100万人から500万人に増加し、負荷高騰時は1万〜2万rpsまでスパイクする規模に急成長しています。そのような急拡大する組織と急成長するプロダクトの裏側には様々な課題が発生しましたが、「フロー効率を重視すること」で様々な課題を解決してきました。このセッションでは、そんなSODAのプロダクト開発組織での取り組みや考え方をご紹介します。
登壇資料
レポート
今日のキーワードは「フロー効率」「具体と抽象」。この2つのワードにフォーカスして話をしていました。
フロー効率とは、リソース効率が仕事を始めることを優先したものと比べて、仕事のサイズを最小化して状況の変化に対応し、仕事を終わらせることを優先することと定義しています。早く終わらせることによってより多くの価値を早めに得ることができます。
もうひとつのワード、具体と抽象については以下の本を引用しながら開発プロセスの具体的な話を抽象的に捉えながら話を進めていました。
具体的な改善ポイント「早くすれば早く終わる！」という話は「サイクルタイム」の一部であるという話に抽象化でき、段階的に抽象化や具体化を行き来することでメトリクスに目を向けることができ、最後はフロー効率の改善という抽象層で考えることができます。登壇全体の流れとして具体的な事例と抽象的な考え方を往復することで課題解決の質の改善を実施されていました。
自分自身もフロー効率をあげることが重要という話はよく聞いていましたが、抽象度が高く具体に降ろしていかないと何を改善するためのものなのか、なぜこの仕組みを強化すべきなのか見失いやすかったです。逆に個別の施策を考えすぎると全体感を見失いやすいので、具体と抽象を往復する考え方は定期的に取り入れたいと感じました。
上記までが前振りで本編では以下の項目ごとに話をしていました。
- プロダクトの急成長と組織の急拡大
- リソース効率を重視したことによる課題
- 「フロー効率を高める」とは
- 解決した課題、予期せぬ好影響
プロダクトの成長
MAUが2年半で100万人から500万人に、リクエスト数も1~2万rps、ソースコードも数千単位のPJに巨大化。人数もタイトルの通りエンジニア2名から35名、開発組織全体は4名から50名と急拡大が伺えます。その際に起きた問題について話されていました。ただその大きな組織の中でも月間デプロイが100回以上、 deploys/a day/a developer(d/d/d)の指標も0.3とデプロイまでの動きが非常に効率的に行われていたことが伺えました。
リソース効率を重視したことによる課題
少人数であったときはツーカーの仲でうまく開発できていたのが、人数の拡大によって並行稼働するタスクが多く把握しきれなくなり、仕様を把握するためにレビューコストが増加し出して遅延しがちになったという問題が語られていました。ただ事業成長を得ることはでき、事業成長を重視する考えは文化と定着できたそうです。
受託開発企業で仕事をしていると仕様固められない時があるのと自社の社員メインだと人数規模をスケールさせずらいので、なかなかここまでのスピード感は出せていないのですが、スピード感を出せる環境でもなかなかたくさんの課題が生まれそうな感じでした。
実際に課題として段々以下の問題が出てきたそうです。
- 成果物の属人化
- 他人のタスクへの無関心→個人事業主の集まりみたいになる
- 仕様理解やコード理解が大変になる、仕様のキャッチアップから始まる、レビューの長期化やPRの肥大化
- スケジュールの予想が立てづらい、ベテランと新しい人の差が大きい
- PdMの認知負荷が高まる
上記のような課題は、急拡大している組織だけでなく感じました。自分もPdM、PO的な動きをしている際にメンバーの並行の仕掛かり作業が増えすぎて認知負荷が高まっていたのですが、何故困っているのかよく分かってなかったのです。しかしながら、今回の発表を聞いて自分自身の問題にも気づくことができました。
「フロー効率を高める」とは
エンジニアの数が15名から35名に増える際、フロー効率を高めるためVPoEとして以下の取り組みを行ったそうです。
- フルサイクルなチーム
- 機能開発は同時に1つだけ
- チームで計画し振り返る
フルサイクルなチームにするため、チームの単位を2pizzaレベルに分割し全てのサイクルに関わるように変更。チームトポロジーのストリームアラインドチームを意識して作られていました。この際に思考法として使用されていたのが具体と抽象です。2pizza teamというAmazonの取り組みは、「you build it, you run it.」という具体的な動きを体現するためのものであり、それを再度抽象化→具体化を繰り返すことで改善解決の幅を増やすことができると語られていました。
機能開発は同時に1つだけにする理由をまた具体と抽象の思考で探り、最小の価値単位を届ける動きへと再度具体化していました。これはスクラムガイドでも「仕事の価値単位を最小にする」ことが語られており、エンジニア組織論でも「不確実性を減らす」ことの重要さが語られています。
チームで計画し振り返るの部分でも具体と抽象の行き来で、課題解決を検討していました。ここの部分について自分はベロシティは意識しているものの、ベロシティはXPの第2版では利用を推奨していないという話も知らなかったので、まずはここから理解を深める必要があると見直すきっかけになりました。
解決した課題、予期せぬ好影響
属人化していた状態から属チームの状態に変わることで、チームが自律的に動き、スプリント達成のための協力が生まれ、課題を言語化し改題解決の再現性を担保することで、外部からも評価されやすくなると語られていました。
最後は飛躍もあるかと思ったのですが、ここまで自分の考え方や、やってきたことを言語化されている登壇者の方や生産性の改善に取り組んだチームのメンバーだと考えると、どんな現場でも再現性高く問題の設定と解決ができ信頼できそうだと感じました。
所感
イベント自体は元々FourKeyやメトリクスの扱い方について調べるために参加したのですが、組織の課題を具体と抽象で往復しながら考える話がとても面白く、今後自分の仕事の進め方でも意識したいと思い記事にしました。自分の記事自体は抜粋した内容になっているので、ぜひ本編のスライドの方もご確認ください！
17
