プロダクト開発の目線を合わせるための取り組み
イントロダクション
Cloudbaseソフトウェアエンジニアのryukeです。
今回は、現在私が主導で進めている、プロダクト組織内での共通認識の醸成・共通ルール策定の取り組みである「Big Dream Team プロジェクト」についてご紹介したいと思います。
岩井 龍之介（いわい りゅうのすけ）
Cloudbase 株式会社ソフトウェアエンジニア
京都大学卒業後、メルカリに入社。メルカリでは、Microservices Platformチームに所属し、社内のCI基盤の刷新・セキュリティの強化に従事。 2023年1月よりCloudbaseにジョインし、主にデータ基盤部分の機能開発を担当。
背景
このプロジェクトが発足したのは、2023年の12月頃に遡ります。発足の背景として、シリーズA調達完了の目処がついており、今後採用を加速させて組織を急拡大させていくにあたって今から必要な準備を進めていきたいという意識がありました。
前提として、「限られた予算の中でアウトカムの速度を最大化すること」がプロダクト組織のミッションです。
このミッションを達成するに当たって、当初は「チーム分割を見越したアーキテクチャの方向性」をテーマとし、今後メンバーが増えてチームが分割されていくことを前提にどのようにシステムを分割していくか、という論点を主なスコープとすることを考えていました。しかし社内のヒアリングを進めていく中で、そもそも早い段階でチームを分割していくことに否定的なメンバーも多いことがわかってきました。
そこでまずは「組織の拡大」というテーマに対して、メンバーが考えていることを共有するためのブレスト会を開催しました。
挙がったトピックをグルーピングしていく中で、浮かび上がってきた共通の課題が次の3つです。
依存関係：プロダクト・ソフトウェアが複雑になり、コンポーネントが相互に依存するようになる。ソフトウェアは壊れやすくなり、プロダクトを前に進める上で、より多くの依存関係を解決する必要が生じる
アラインメント：メンバーやチームが増えた際に、技術面での方向性のすり合わせや品質をどのように担保していくか
オーナーシップ：組織やコンポーネントが拡大するほど、1人が全体を把握・コミットすることが難しくなり、適切に責務を分割していく必要がある。中央でコントロールする部分と各チームに任せる部分のバランスをどのように取るか
この中でも特に現時点での課題として多く挙がったのが「アラインメント」でした。これまではリファラル採用で、元々繋がりのあったメンバーが多かったという背景もあり、特にコミュニケーションをとらなくとも、統一された品質やコーディングルールを用いることで同じ方向に向かって開発を進めることができていました。
（別記事でご紹介予定ですが、初期からドキュメントは整備しており、個別の機能ベースでは良いものを作ることができる状態にはありました。）
この暗黙のアライン自体は最速で開発を進めるための一つの最適な形であったとは思いつつ、今後多様なメンバーがJoinしていく中で、これまでのような進め方は難しくなっていくと考えました。実際にメンバーが増えていき、徐々に課題として顕在化してきていたタイミングでもありました。
特にチームの分割自体が本当に最適解なのか？今のままでは方向性を揃えながら開発を進めることは難しいのではないか？結果として開発スピードが落ちることになってしまうのではないか？という声が多く挙がりました。
そこから解決策に関する話し合いを進めていく中で、組織が拡大していくにあたってこれまでと同じ水準の開発スピードや品質を保つために「明文化された品質基準や開発ルール・プロダクトの方向性」が必要である、という共通認識を得ることができました。
こうして本プロジェクトは「プロダクト開発の目指す姿・守るべき原則についてメンバーの目線を揃えること」を目的として始動しました。
成果物としてはドキュメントが主になりますが、ルールについては可能な限り実効性のある仕組みや自動化によって担保することを目指します。
また、ドキュメントを”作っただけ”にならないよう、ドキュメント自体よりもその中身に辿り着く過程のディスカッションの中で、メンバーを巻き込みながら共通認識を作っていくことを意識して取り組んでいます。
なお、プロジェクト名である「Big Dream Team」に関しては、キックオフの際にメンバーで案を出しあって決定しました。かなり安直な名前ではありますが（笑）、組織が拡大してもドリームチームでありたい、というメンバーの想いをわかりやすく表現しているところが良いなと思っています。
具体的な取り組み
実際にプロジェクトを進める中では、分野ごとに担当者を決め、メンバーを巻き込んで議論しながら、決めるべき項目の洗い出しからそれぞれオーナーシップを持って進めてもらっています。
技術分野に関しては、以下の4つが主なフォーカスポイントとなっています。
Product Design：プロダクト開発・デザイン
プロダクトビジョン、プロダクト原則、ユーザーペルソナなど
Scanner：クラウド環境のデータを取得するコンポーネント
品質基準、アーキテクチャ、開発ルールなど
App Backend：SaaSバックエンド開発
ビジネスロジックの管理、パッケージ構成など
App Frontend：SaaSフロントエンド開発
共通コンポーネントの管理、コーディングルールなど
全てを紹介することはできませんが、ここでは具体例として自分が関わったスキャナー分野での取り組みについてご紹介したいと思います。
スキャナー分野では、まず「スキャナー」というコンポーネントが何なのかについて、そしてそれが果たすべき役割について用語を整理しながら立ち返って考えるところから始めました。
スキャナーとは、お客様のクラウド環境からリソースの構成情報を取得し、その中からリスクのある設定や脆弱性を検出するコンポーネントのことです。Step Functions上のバッチジョブとして動作するスキャナーが出力した情報をSaaSアプリケーションがデータベースに取り込み、API & クライアントアプリケーションとしてお客様に分かりやすいUIで表示する、という構成になっています。
我々のプロダクトの価値は、クラウド環境に存在するセキュリティリスクを漏れなく、そして誤りなく検知できることであり、プロダクトのコアバリューはスキャンによって得られた「データ」であると言えます。どれだけUIが見やすく使いやすくても、表示されるデータが信頼できないものであれば意味がありません。
改めてこの点を明確にしたことで、スキャナーの責任は「スキャンデータの品質」にあり、その活動の焦点はデータの品質に向けられなければならない、ということをメンバー間で再度確認することができました。
そして、データ品質を計測するための評価軸や指標についてもプロダクトの特性を考慮した上で定義を行い、「品質」というふわっとした言葉ではなく数字に基づいて議論することができるようになりました。
最後に、スキャンデータの品質を担保するための具体的な取り組みとして、以下の3つの活動軸に対する方針を定めました。
サービスレベル：データ品質をスキャナーのサービスレベル指標として計測し、SLOに基づいた障害対応を行う
アーキテクチャ：データ品質の劣化を最小とするようなシステム設計の方針を定める
レビュー：コードレビュー、デザインレビューにおけるレビュー観点とチェックリスト
1.サービスレベル
従来のジョブ成功率に基づいたモニタリングをやめ、品質の定義に基づいた指標をスキャンデータごとに設計して実装していく方針を定めました。
こちらについては以下のスライドでもご紹介しているのでよろしければご参照ください。
2.アーキテクチャ
データ品質を担保するためのアーキテクチャ特性として
「スキャナーとアプリケーションがイベントキューなどの明確なインターフェースによって分離されていること」
「各コンポーネントが独自のデータストアを保有しており、データストアごとにデータ品質が測定されていること」
「コンポーネント間はイベントストリームにより疎に結合されていること」
といった方針を定めました。
修正後
修正前
3.レビュー
「デザインレビュー」「コードレビュー」「リリースレビュー」と、それぞれのレビューにおける観点を明確化し、併せて個人に委ねられていた開発フローと各ステージのルールを改めて明文化しました。
これらの方向性や開発ルールを定めたことにより、レビューにおけるコードや設計の良し悪しをより建設的に議論できるようになったと感じています。また最近チームにジョインしたメンバーにも、オンボーディングで全体像を把握する際に役立ったと声をもらっています。
仕組みに落とし込んでいくところはこれからの取り組みにはなりますが、まずは共通の約束をドキュメントへ書き起こすだけでも、メンバー間での前提認識を揃える上で一定の効果があったのではないかと考えています。
今後の展望
ここまでの取り組みを通して、現時点での共通認識をチームでとることと、新しいメンバーを迎え入れる準備が整いました。
一方で、今は方向性の共通認識がとれたことで、スタートラインに立ったに過ぎず、ここからアーキテクチャの議論や実装など、未来に向けて取り組むべきことがたくさんあります。
そして何よりBig Dream Teamプロジェクトの成果物はまだまだβ版であり、今後実行と振り返りを通じてより良いものへとブラッシュアップを続けて進化させていく必要があります。
組織の急拡大に応じた課題にチャレンジできる機会はそう多くないと思います。私たちと一緒により良い未来を作っていってくださる方を絶賛募集中です。
おわりに
Big Dream Teamプロジェクトは、この記事を書いている現在も進行中であり、本格的な実践や効果測定はこれから行う予定です。
しかし、現時点でもメンバーの前提認識がドキュメントという形で共有されるようになったことは、新しいメンバーのオンボーディングをスムーズに行う上でも、また既存メンバーの仕事の進め方を揃える上でも、とてもポジティブな効果があったと感じています。何よりドキュメントの形成に至るまでのディスカッションの中で、メンバーそれぞれの異なる意見をお互いに知ることができ、それを踏まえて「チームとしてどうしたいのか」を話し合うことは、メンバー間の相互理解を深め、チームとしての成熟度を高めていく上でとても有意義な作業であると感じました。
今回ご紹介したアラインメントの活動は、スタートアップの環境下ではどうしても目先の開発に追われて後回しになりがちなところだと思いますし、だからこそ、シリーズAというこのタイミングで工数を取って組織として取り組めたことは、必ず今後の成長に効いていくと思っています。BigでDreamなチームに向けて、Cloudbaseでは引き続きこの取り組みを続けていきます。
以上、弊社での取り組みを長々と紹介してきましたが、何か少しでも参考になる部分があれば幸いです。最後までお読みいただきありがとうございました！
上記の内容に興味を持たれた方、より深く話を聞いてみたいと感じた方、弊社CTOの宮川がカジュアル面談を実施していますので、ぜひ下記のリンクよりお問い合わせください！
この記事が気に入ったらサポートをしてみませんか？