この記事は、CYBOZU SUMMER BLOG FES '25の記事です。
こんにちは。kintone 開発チームのナビゲーション / コミュニケーション系チームでエンジニアリングマネージャー(以下. EM)兼プロダクトエンジニア(以下. PdE)をしている高木です。
私は 2024 年 5 月頃からナビゲーション / コミュニケーション系チームで EM をやっています。今回はそんな私が EM として 約 1 年間どんなことをやっていたのか、どんな失敗をしどんな学びを得たのか、一部紹介してみようと思います。
ナビゲーション / コミュニケーション系チームについて
まず私が所属しているチームについて簡単に紹介します。 私たちのチームはストリームアラインドチームとして活動しており、エンドユーザーに価値を届けることに焦点を当てています。なお、kintone 開発チームには私たちのようなストリームアラインドチームの他に、技術基盤や共通コンポーネントを提供するプラットフォームチームも存在し、互いに連携しながら開発を進めています。
昨年時点の活動内容は以下記事にて紹介しているので、興味がある方は参照ください。 blog.cybozu.io
チーム構成
- EM 兼 PdE: 1 名 (私)
- PdE: 5 名
- QA: 3 名
- SM: 1 名 (※ 他チームと兼務。EM のサポート(e.g. 1on1)やレトロスペクティブでの振り返りサポートがメイン。)
主な担当領域
EM の主な役割
主な責務
今回は、EM の主な責務や私が実施していることについて紹介します。
プロジェクトマネジメント
- 計画策定
- クオータ毎のチームの活動計画
- スプリント(1 週間)毎の計画(≒ スプリントプランニング)
- クリティカルパス/遅延コストを意識したタスクの優先順位付けのリード/サポート
- 進捗マネジメント
- デイリースクラム等でタスクの優先順位変更/スコープ調整サポート
チームマネジメント
- 振り返りによる本質的な問題の抽出/改善
- e.g. レトロスペクティブ/ポストモーテム/開発時のボトルネック分析
- チームの一体感/モチベーションの維持/向上
- e.g. スプリントプランニング/レトロスペクティブ/チームビルディング
- 他チーム(e.g. PdE/PdM/デザイナー/ライター)との連携リード/サポート
ピープルマネジメント
- メンバーとの 1on1
- 適切な委譲とサポート
- 挑戦的機会の提供とサポート
プロダクトマネジメント
- アジリティの高い開発を行うための機能設計/優先順位付け
テクノロジーマネジメント
- コード設計/改善のリード/サポート
- 技術選定のリード/サポート
- 技術スキル向上のリード/サポート
- e.g. PdE 勉強会/スキルマップ作成
EM 1 年目の実体験
EM の実体験として、今回は、「2 枚目以降のポータルを作成できる機能」(以下.複数ポータル機能)に関するテーマを 2 点紹介します。
複数ポータル機能は、2025 年 7 月に月例チャネルにリリースされた機能になります。 機能の概要についてはアップデート情報を参照ください。
エピソード 1: 開発フェーズに適したコスト配分戦略と機能設計
まず前提情報として、上記で紹介した通り、複数ポータル機能には、管理者が表示するウィジェットをカスタマイズしてポータルを作成することができる管理画面と、作成したポータルを利用できるポータル画面があります。
この機能を 0 から開発するに当たって、まずはポータルを作成するための管理画面から作成しはじめたのですが、管理画面でウィジェットを自由に配置できる機能、具体的には、ドラッグアンドドロップでウィジェットを配置する機能に 1.5~2 週間程の開発期間を掛けてしまいました。
今回、管理画面にて kintone では利用実績のないライブラリを利用しておりキャッチアップに多少コストが掛かったのはありますが、それ以外の時間が掛かった主な理由として、ウィジェットのスムーズな配置変更やリサイズについてエンジニアとして満足いく状態にしようとしすぎたという点があります。 もちろん、この時間を掛けたポイントは複数ポータル機能をより良くするものではありますし、エンジニアとしては丁寧に作り込みたい衝動に駆られるのですが、開発初期段階からコストを掛けすぎるポイントではなかったと反省しています。
Donald Knuth 氏による有名な格言で、「早すぎる最適化は諸悪の根源(premature optimization is the root of all evil)」というものがありますが、コードだけでなく、機能についても当てはまるケースがありそうです。
では、どういった機能/要素により時間を掛けると良いのでしょうか。フェイルファストの原理を元に考えると、より高価値で高リスクなものから順に安いコストで仮説検証することで、より大きなリスクを早期に曝露することが重要だと言えそうです。 今回のケースで言うと、まず機能としての価値/重要度という観点では、管理画面よりも作成されたポータル画面の方が高いでしょうし、リスクや不確実性という観点においても、ポータルを複数作ることができるという機能の本質や、エンドユーザー目線でのポータル画面のウィジェットの見え方/使い方等のユーザービリティ不確実性、どのようなウィジェットをどのような順序で実装していくべきかの優先順位不確実性がより検証すべきポイントだったと考えられそうです。これらのことから、管理画面で実施できるウィジェットの配置操作に開発初期段階からコストを掛けすぎるのは、適切ではなかったと反省しました。
また、レバレッジの効く機能設計という観点でも、初期から作り込みすぎるのは適切ではないと実感しました。開発初期段階から 1 つの機能を作り込みすぎてしまうと、これから機能を拡充していく際の選択肢を減らしてしまったり、優先順位付けの的確性を歪めてしまうことにもなりかねません。 例えば、ウィジェットのリサイズを管理者が自由自在に変更できる機能を早い段階で実装していた場合、ウィジェットの UI/UX は、ウィジェットの高さのパターンが無数にある前提で検討することになります。 そもそもウィジェットの高さを管理者が自在にリサイズできることは、ユーザービリティ的に適切かどうか、という話もありますが、まずはウィジェットの高さが固定であることを前提にした方が、より機能としての重要度/ユーザー価値の不確実性が高いと考えられるウィジェットの中身の機能構成やデザインについて、より安いコストで思考/試行することが可能になります。
つまり、高価値/高リスクなものから順により安いコストで検証するためには、どの機能にどれくらい時間を掛けるかというコスト配分戦略だけでなく、機能拡張容易性を考慮した作り込みすぎないアジリティの高い機能設計も重要だと実感しました。
以上のことから学んだことをまとめると、以下になります:
- PBL の優先順位を立てた後、それぞれの PBI に着手する際も、機能を作る目的/仮説(≒ ユーザーストーリー)を的確に理解する必要がある。具体的には、MVP(Minimum Valuable Product)で言うところの、最低限仮説検証するために必要な機能なのか、それともより価値が高く且つリスク/不確実性が高い機能なのかを理解し、都度何にどれくらいコストを掛けるべきか考える必要がある。
- 小さく早く失敗することで、早期にリスクを曝露することが重要。そのためには、機能を作る目的を元に何を仮説検証したいのか本質を的確に理解し、偶有的な部分については早い段階から過剰に作り込みすぎないことで、今後の機能拡張容易性を維持しながら開発を進めることによる開発速度/開発効率向上を図ることが重要。
エピソード 2: チームのモメンタム
複数ポータル機能を数カ月間ほぼノンストップで開発し続け、開発開始から約 3 ヶ月が経った際に一部のメンバーの疲労感/モヤモヤが溜まっていたことが分かりました。 そこで、チームビルディングを開催し、モヤモヤについて深ぼってみると、作り直しが発生することの違和感や、開発速度を求めることに対するモヤモヤが発生しているメンバーがいることが分かりました。 さらに、メンバー一人一人と会話し、モヤモヤの内容を深ぼっていくことで、問題の本質がいくつかありそうなことが分かりました。今回は大きく分けて 2 つ紹介します。
1 つは、エピソード 1 で記載したような、開発フェーズに応じたコスト配分戦略や機能設計が的確でない場合、時間を掛けて実装したものを捨てる/修正する回数が過剰に増えてしまうことで、メンバーのモチベーション低下が発生しやすくなることがあるという問題です。こちらについてはエピソード 1 で記載したような優先順位付けをより的確に実施することで、少しでも余分な実装修正を減らすことが、問題を緩和するために一番重要だと考えています。
2 つめは、私を含めたチーム全体のアジャイルの理解度不足です。エピソード 1 で書いた通り、高いアジリティ/レジリエンスを持った開発を実現するためには、より高価値且つ高リスクなものからより安いコストで検証することで、リスクを早期に曝露することが重要だと考えています。つまり、リスクが曝露されたことで、戦略/計画を変更することになったり、機能を作り変えたりすること自体は問題ではなく、むしろ適切なアクションだということです。また、開発フェーズやバックログの目的に応じた仮説を検証することが重要ということは、目的の本質ではない偶有的な部分は戦略的に作り込みすぎないことで、仮説の本質をより安いコストで検証することに繋がり、その結果開発速度向上にも繋がります。これらについて、チーム全体の理解を深めていくことで、納得感を持った開発に繋がると考え、メンバーとデイリースクラムやレトロスペクティブ、1on1 を通じて、会話を続けています。
最後に
サイボウズでは、現在以下の組織目標を掲げています。
「製品進化スピード 10 倍！インパクト 10 倍！」
https://www.docPdEll.com/s/teppeis/KW1DGY-cybozu-impact-10x
今回 2 つのエピソードを紹介しましたが、他にもまだまだ未熟で反省すべき点があります。 引き続き、様々な観点でスキルアップし、チームをリードすることで、上記の組織目標達成に貢献できるよう邁進していく所存です。
約 1 年間 kintone 開発チームで EM をやってみて、個人的に反省することは多々ありましたが、総じて得られるものも多く、学習意欲の高いメンバーとの開発は非常に楽しいものがありました。 kintone 開発チームの中だけでもサブチームは複数あるので、EM 同士/PdE 同士情報交換しながら切磋琢磨することもできます。 EM としても、PdE としても、成長できる非常にやりがいのある環境だと思うので、もし興味がある方は、ぜひ応募をご検討ください。お待ちしております！
