成長し続ける大規模プロダクトを、小さなチームでどう切り拓くか？開発陣のセッションから見えた意思決定の現在地 - Cybozu Inside Out

こんにちは！開発本部開発広報チームの北地（@tos_kitt）です。

4月8日に開催した Cybozu Tech Meetup では、「巨大プロダクトに小さいチームで大きな変化を起こす」をテーマに、kintone の性能ダッシュボード開発の裏側を取り上げました。イベント当日は、技術的な工夫だけでなく、チームの意思決定のあり方や、プロダクトに向き合う姿勢まで含めて、学びの多い時間になりました。この記事では、運営者として印象に残ったポイントも交えながら、当日の内容を振り返ります。

なぜこのテーマで開催したのか

サイボウズが提供するkintoneは、現在42,000社以上にご利用いただいている巨大なプロダクトです。日々機能追加や改善を続けていますが、これだけスケールしたプロダクトになると、新たな機能をどう作り、どう届けるかは決して簡単な問題ではなくなります。

今回テーマに取り上げた「性能ダッシュボード」は、お客様自身でアプリのパフォーマンス問題の把握や改善に向けた判断ができるよう、性能指標を可視化する機能です。単にログやメトリクスを画面に出すだけでなく、どの情報を、誰が、どのように使える状態にするかを考え抜く必要がありました。

運営者としてこのテーマを取り上げたいと思ったのは、ダッシュボード開発副部の取り組みが、単なる機能開発の話に留まらないと感じたためです。大規模プロダクトの一部を担いながらも、小さなチームだからこそできる意思決定や進め方を選び取り、実際に価値提供につなげています。その実践は、同じように複雑なプロダクト開発に向き合っている方々にとっても参考になるはずと思い、今回のイベントを企画しました。

セッションのハイライト

セッション1：小さなチームで、大きなインパクトを〜プロダクトと向き合う面白さ〜

登壇者：kenny（ダッシュボード開発副部エンジニアリングマネージャー）

kennyさんのセッション動画リンク

最初のセッションでは、エンジニアリングマネージャーのkennyさんが、ダッシュボード開発副部の組織的な取り組みや開発スタイルについて話しました。

チームの立ち位置として、「向かう先は同じだけど、走り方は自由」というスタンスが紹介されました。kintone本体のビジョンやゴールは共有しつつも、独自の技術スタックや開発プロセス、意思決定を独立して行うことで、最速で動ける選択をしています。また、「得意を生かす。得意を超える」という姿勢を掲げ、個人の高い専門性を発揮するだけでなく、インフラ担当がUI/UXの議論に参加するなど、専門性の境界を超えた活動を行っています。

さらに、四半期ごとのゴールに対し、チーム内で作戦会議をして意思決定を担う点も挙げられました。Cybozu Days*1のリリース日に間に合わせるため、提供価値や開発コストの観点から作るものを柔軟に変更した事例も紹介され、これらはメンバー一人ひとりの当事者意識によって支えられているとのことでした。

セッション2：kintone性能ダッシュボードの迅速な価値提供を支えた技術的意思決定3選

登壇者：谷昌典（ダッシュボード開発副部プロダクトエンジニア）

谷さんのセッション動画リンク

続いて、プロダクトエンジニアの谷さんが、性能ダッシュボード開発において「仮説検証のサイクルを素早く回す」ために行ってきた、具体的な技術的意思決定について話しました。

迅速な価値提供を支えた意思決定の1つ目として、BFFとTypeScriptの採用が挙げられました。BFFで認証とDB操作の層を分離し、モックサービスを利用することで、フロントエンドとバックエンドの並行開発を実現しています。2つ目は、開発初期段階でのプルリクエストのプレビュー環境整備です。ラベルを付与するだけで、DBを含むフルセット環境や、DBをスキップしたモック環境を即座に立ち上げる仕組みを構築し、開発環境自体への投資が開発速度の向上に繋がっているとのことでした。 3つ目は、Grafanaを活用した表示内容の検討です。ダッシュボードのUIを都度開発して試すのではなく、プロダクション環境上に立てたGrafanaを用いて、どのグラフがお客様にとって意味があるかを検証することで、1回あたりの試行錯誤のコストを軽くしている仕組みについても紹介されていました。

パネルディスカッションとQ&Aタイム

後半は、視聴者のみなさんからの質問も交えながら、さらに開発の背景を掘り下げる時間となりました。生成 AI 機能開発チームの齋藤さんがモデレーターとなり登壇者の二人と対談しました。ここでは、その中でも特に印象に残ったやり取りを一部ご紹介します。なお、全編気になる方は、下記リンクからぜひご視聴ください！

パネルディスカッションとQ&Aタイムの動画リンク

Q. 失敗したことややり直したエピソードは？

谷 : 当初はデータソースを複数想定してBFFを設計したのですが、開発速度を優先してデータソースとサービスを1つに統合した事例があります。この点については、現在となってはこの判断は良かったと振り返っています。一方で、開発を小さく進めてチーム内で相談しながらこまめに軌道修正を行っているので、取り返しがつかないようなクリティカルな失敗は発生していません。

Q. 大規模プロダクト×小チームで「これだけはやった方がいい」ことは？

kenny : リソースが少ないからこそ、エンジニアをプロダクト作りに巻き込むことでチームの方向性を揃え、主体性やアウトプットの質を上げることが重要だと考えています。

谷 : 大きなチームでの "当たり前" を小さなチームにそのまま持ち込むのではなく、一度アンラーニングして疑ってみる姿勢が重要です。小さなチームだからこその素早さを活かせる改善を取り入れていくのが良いのではないでしょうか。

Q. 当事者意識を高める工夫は？（視聴者からの質問）

kenny : 四半期ごとのプロダクトロードマップ更新のタイミングで、チーム全員で議論するようにしています。また、リリース前にチーム全員でプロダクトを実際に触ってバグ出しをする会も実施しており、こうした取り組みを通じてプロダクトに対する愛着や当事者意識を育てています。

Q. 本番デプロイの自動テストとAI活用についてをどうしているか？（視聴者からの質問）

谷: E2Eテストでダッシュボードが表示されることまでを確認し、失敗した場合はCIで落とす仕組みにしています。また、インフラ面ではAWS CDKのスナップショットテストを活用しており、リソースに変更があればテストが落ちるようにすることで、常に意図したインフラ構成になっていることを保証しています。なお、品質保証の工程におけるAIの活用については、現時点ではまだあまり進んでいません。

イベントを振り返って

運営者の立場として一番心に響いたのは、メンバーが自律性を持って活動し、変化を楽しみながら明確な方向性を持って挑戦している姿です。

kennyさんが語っていた「自律的なチーム」「明確な方向性」「挑戦」という3つの掛け算が生むワクワク感や、自分たちで決めた機能が何万というお客様に届くインパクトを糧にする当事者意識。そして、領域を横断してでも本当にお客様に価値があるものを追求し、初期案に固執せず変化そのものを楽しもうとする谷さんの姿勢。そこには、巨大なプロダクトならではの挑戦の難しさを楽しさに変え、自らの手でプロダクトを切り拓いていく、魅力的なエンジニアの姿があると感じました。

当日参加できなかったみなさんにも、この記事を通じて、そんなチームの雰囲気や実践の様子が少しでも伝わっていれば嬉しく思います。それぞれの現場でプロダクト開発に向き合う上で、何かのヒントになれば幸いです。