こちらの記事はツクリンクアドベントカレンダー2024の12日目の記事です🎉
是非他の記事も気になるものがあれば見てみてください！
ツクリンクでアソシエイトエンジニアリングマネージャーをしている八尾です。
今回は、私が見ている1チームで実施している「Featureチーム」について書いていきます。
今後、職能横断型のチームを作る時に参考になる部分があれば良いなと！
Featureチームとは何か
正直なところ、弊社が取り組んでいる開発体制が、世間一般的に定義されている「Featureチーム」と完全に一致しているかは定かではありません。そこで、まずは弊社における「Featureチーム」の定義をお伝えします。
弊社では「Featureチーム」を、ユーザーへ届ける価値を軸に、PdM・デザイナー・エンジニアといった異なる職能のメンバーが一つのチームとしてまとまる体制としています。
一般的なコンポーネントチームが特定の技術領域ごとに分業するのに対し、Featureチームは職能横断型のチームとして編成します。これにより、必要なスキルや意思決定がチーム内で集約され、ユーザー価値に直結するアウトプットをよりスムーズに届けられると考えています。
この体制の狙いは、開発者を含む全メンバーが「なぜこの機能を作るのか」という問いを常に意識し、チーム全体で価値の最大化を追求することです。コンポーネントごとの部分最適化ではなく、ユーザーが手にする機能を起点とした全体最適を目指すことで、より良いユーザー体験や成果を生む事ができると考えてます。
なぜFeatureチーム化が必要だったのか
これまで弊社は形式的にはスクラムを導入し、PdMが提示する施策を1週間単位のスプリントで運用していました。しかし、「なぜその施策が必要なのか」「ユーザーにどのような価値を届けるのか」といった部分は、エンジニアにとって理解しづらい状況でした。また、エンジニア側からもこうしたWHY（理由・目的）を積極的に汲み取ろうとするには心理的なハードルがあったと考えています。
一言で表せば、「エンジニアが施策のWHYを理解しづらい環境」だったと言えるのではないかと。
その結果、エンジニアは「決まった要件を期限内に実装する」ことが目的化し、ユーザー価値向上の視点が希薄になりがちでした。
さらに、PdM → デザイナー → エンジニアという職能ごとの縦割り構造は、情報の受け渡しコストや手戻りを招き、ユーザーへ価値が届くまでのリードタイムを削減できるなと考えてました。
こうした状況を改善するためには、各職能が一つのチームとして結集し、常にユーザー価値を念頭に置いた柔軟かつ迅速な開発体制が必要だと判断しました。その結果、弊社ではFeatureチームへの転換を進めることにしたのです。
Featureチーム構築へのプロセス
Featureチームを立ち上げるにあたっては、PdMやデザイナーといった他職能チームの協力が欠かせません。また、「Featureチーム」という言葉の定義はあっても、具体的に何を目的に、どのような構成で動き出すのかは事前にクリアにしておく必要があります。
私はまず、「なぜFeatureチームを立ち上げるのか」「どのようなゴールを目指し、どのようなメンバー構成で進めるのか」といった基本的な方針を資料化しました。その後、この資料をもとに部長を交えたミーティングを行い、チーム体制や目的への理解を得るプロセスからスタートしました。ここで合意が得られなければ、そもそもFeatureチーム体制への移行は実現できなかったはずです。
部長や他チームの皆さんが前向きに協力してくださったことには、今でも感謝しています。
次に、実際にFeatureチームとして稼働するメンバーへ「なぜやるのか」「どのような活動を行うのか」といった目的や方向性を共有しました。この段階で、多くのメンバーはまだ具体的なイメージを持ちづらいため、目的だけでなく、ある程度の「やり方」や「進め方」についてもガイドラインとしてまとめることにしました。まずは仮説的な進め方で動いてみて、その後レトロスペクティブを通じてプロセスを改善していく方針です。
こうした一連の流れによって、Featureチームは最初から完璧な形を目指すのではなく、段階的に試行錯誤しながら自走できるチームへと進化していく為の土台を作っていきました。
Featureチームでの実施内容・進め方
弊社では、リリースまでに「着想」「要件・仕様検討」「デザイン」「開発」「QA」「リリース」という6つの工程を想定しています。このうち、現時点でFeatureチームとして取り組んでいるのは、「要件・仕様検討」「デザイン」「開発」の3つの工程です。
具体的には以下のような流れで進めています。
-
ユーザーストーリー作成
ユーザー中心の開発をする為、技術的な背景が違うメンバーとの共通理解を持てる様にする為に「誰が」「なぜ」「何をしたいか」というユーザーストーリーを作成し、チーム全員が同じ目的意識を持つてるようにします。 -
要件定義
ユーザーストーリーを踏まえ、PdM・デザイナー・エンジニアが一堂に会し、どの機能が必要でどのようにしていくかを議論し、必要な情報や前提条件を洗い出します。このタイミングでデザインのモックを作成しながら進めてる事もあります。 -
仕様策定
要件をもとに詳細な仕様を詰めるステップです。機能の振る舞いや技術的な考慮事項を定義し、後工程（デザイン・開発）での手戻りを最小限に抑えます。 -
デザイン
策定した仕様に基づいてデザイナーが画面設計やUIパーツを設計します。エンジニアやPdMが相談可能な状態を保ち、UX向上や実現可能性を踏まえて柔軟なフィードバックを行います。 -
開発
仕様とデザインが固まった段階で、エンジニアが実装に着手します。エンジニアは初期段階から仕様検討に関わっているため、手戻りを減らしスムーズな開発が可能になります。
スプリントイベントのスケジュール
弊社では1週間を1スプリントとしており、各工程を以下のような流れで回しています。
-
火曜日：バックログリファインメント
このイベントで「ユーザーストーリー作成」「要件定義」「仕様策定」を行います。施策の方向性を具体化し、次スプリントで実装可能な状態に整えるための準備段階です。
バックログリファインメントは火曜日に予定はありますが、あくまで「火曜日のみ」というわけではなく、週中で必要に応じて柔軟に行っています。 -
水曜日：スプリントプランニング
バックログリファインメントで整えた要件や仕様をもとに、スプリントで取り組むタスクを決定します。チームは「今週何を実現するか」というスプリントゴールを明確化します。 -
木曜日〜月曜日：デザイン・開発
スプリントプランニングで決めたタスクに沿って、デザイナーとエンジニアがデザインと実装を進めます。必要に応じて仕様の再確認や改善を行い、ユーザー価値向上に努めます。 -
火曜日：スプリントレビュー & レトロスペクティブ
スプリントの終わりには、完成した機能や改善点を確認するスプリントレビューを行います。その後、レトロスペクティブで開発プロセス全体を振り返り、次のスプリントへの改善策を話し合います。
このサイクルを繰り返しながら、ユーザー価値を考えた開発を行い、プロセスの継続的な改善を実現しています。
体制変更後の変化
Featureチーム体制への移行後、定量的な変化を示すことはまだできていませんが、定性的な面では以下のような改善が見られました。
-
ユーザーへの価値を意識する
従来は機能追加や修正を行う際、「その機能がユーザーにとってどのような価値をもたらすのか」という視点が希薄でした。しかし、Featureチーム体制に移行してからは、「ユーザー価値」を念頭に置いた議論が行われるようになりました。
その結果、エンジニア側からも「こうした方が、よりユーザーに価値を提供できるのではないか」といった提案が出始め、開発者自身がユーザー価値向上の当事者になる環境が整いつつあります。 -
目的の明確化
なぜ施策を実施するのかといった目的がより明確になりました。今までは「決まった施策を期限内に実装する」ことに意識がよっている部分がありましたが、Featureチームでは施策の背景や意図が共有されやすくなっています。
さらに、仕様策定段階からチーム全体（エンジニアを含む）が関わることで、よりユーザー価値を発揮できる仕様や最適なリリースタイミングを早い段階で検討できるようになりました。 -
開発に集中できる環境
以前は、エンジニアにタスクが渡った後で仕様の確認や考慮漏れの補填、設計の見直しを行う必要があり、手戻りが発生していました。
しかし、Featureチーム体制ではチームで仕様を決めていく為、エンジニアは実装開始時点で考慮もれがほとんどない状態となります。その結果、手戻りが減少し、より開発そのものに集中できる環境が生まれました。
直面した課題や反省点
Featureチーム体制へ移行する際、事前にガイドラインは用意していたものの、その内容はまだ粗い状態でした。具体的なワークフローやロール定義を十分に詰め切れなかったため、実際に動き出してから「どう進めていけば良いのか」を手探りで探る場面が多く、当初想定より開発スピードが落ちてしまうという課題がすぐに浮き彫りになりました。
また、Featureチームの構成は決めていたものの、「誰がどこまでの役割を担うのか」といった領域分担が明確ではなかったことも問題点として挙がりました。結果として、初期の段階ではメンバー間で認識のズレや曖昧さが残り、やり取りがギクシャクする場面が多々ありました。
上記のような課題は、定期で実施しているレトロスペクティブにて課題を解消していくというやり方で対応していきましたが、今振り返ってみれば想定できた課題ではあるので、初期段階で定義できていれば良かったかなと反省する部分もあります。
また、現在も課題としてあるのは本当にユーザーへの価値はより良いものが出せているのか、より早く提供できているのかという部分になります。
ここは、まだ定まり切っていない効果測定のプロセスの確立とユーザーへの価値の定量化という部分を継続的なレトロスペクティブを用いて定めていきたいと考えております。
今後の展望
Featureチーム体制は、まだ確立途中の段階です。今後は以下の点に取り組み、よりユーザー価値に直結したプロダクト開発を目指していきます。
-
定量的な効果測定の確立
現時点では定性的な変化を中心にご紹介しましたが、今後は定量的な指標を導入して成果を可視化できるようにしていきたいです。これにより、チームとしての改善サイクルを客観的な根拠に基づいて検証・強化できるようになると考えています。 -
より迅速な価値提供の実現
スプリントごとの成果物やリリースまでのプロセスを見直し、ユーザーからの反応を素早く開発プロセスに反映できるようにしていき、よりアジャイルな開発組織への進化させていきたいです。 -
他チームへの展開
現在は一部のプロダクト・チームでFeatureチーム体制を試行している段階ですが、今後は他のチームへも横展開していこうと考えております。これにより、ユーザー価値を意識した開発組織というのを作り上げることを目指します。
まとめ
Featureチーム体制への移行は、職能横断型へとシフトすることで、ユーザー価値への意識向上や手戻りの削減、目的明確化によるスムーズな開発進行といった定性的な効果が現れました。
これは、弊社が目指しているユーザーに届ける価値を意識し、自分ごと化してプロダクトを作れる開発組織を実現するための大きな一歩だと考えております。
まだまだ改善する部分はありますが、この取り組みを継続してより良い開発組織を目指していきます！
Discussion