フィーチャーチームについてまとめてみた

こんにちは、SmartHR本体機能の開発をしているkouryouです。

SmartHRでは毎月多くの方が入社しており、日々組織が拡大しています。

しかし一般論ですが、組織は拡大とともに分業化が進み、顧客価値を中心にチームで仕事することが難しくなっていきます。実際SmartHRでも同じ課題感がありました。そこで当時、組織が拡大しても顧客価値を中心にプロダクトを作るための考え方である「フィーチャーチーム」に注目し、推進しました。

今回は当時理解を促すために社内向けに書いたドキュメントを改めてまとめてみました。

フィーチャーチームとは

エンドツーエンドで顧客中心の機能を実現する、安定した長期存続するチームのことです。

出典: 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

何かしらの案件を「着想」レベルで受け取り、チームメンバーだけで「リリース」までたどり着けるスキルセットを揃えられていることが条件です。

スクラムガイドには

スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。

と書いてあり、実はスクラムチームはフィーチャーチームであることが前提になっています。

フィーチャーチームの対義語として、「コンポーネントチーム」という言葉があります。コンポーネントチームとは、特定の専門領域での役割を果たすことを目的としたチームです。このチーム構成は着想からリリースまでに、複数のチームを跨ぎながら仕事が進みます。

SmartHRではどうなっていたか

かつてのSmartHRでは、開発工程を

着想
仕様検討
デザイン
開発
QA
リリース

とすると、その全ての工程が別々のコンポーネントチームで行われていました。

特にLarge-Scale Scrum（LeSS）を採用している本体機能では、コンポーネントチームによるデメリットが目立ってきていました。そこでフィーチャーチーム推進室というコミュニティを立ち上げ、フィーチャーチーム化を推進していきました。

フィーチャーチームのメリット

フィーチャーチームにはどのようなメリットがあるのでしょうか？実際に試してみて感じたメリットについて詳しく説明していきます。

顧客にとって最良で価値があるものを提供できる
製品をリリースするまでの時間を短縮できる

顧客にとって最良で価値があるものを提供できる

フィーチャーチームでは、顧客とチームメンバー(特にエンジニア)との間に間接的な層がないため、メンバー全員が「何を、なぜ、誰のために作るのか」を理解し、より目的のある作業ができます。コンポーネントごとの部分最適はなくなり、顧客目線でPDCAを回せるようになります。

一方コンポーネントチームでは、前工程の人が後々の工程の人に対してコンテキストを伝える必要があります。そのためドキュメントや打ち合わせなど、顧客価値に直接繋がらないアウトプットや作業が増えてしまいます。

特にバリューストリーム（後述）の下流に行くほど、顧客の1次情報に触れないため、提供する価値に対してオーナーシップを持ちにくくなります。例えばエンジニアが顧客目線を忘れ、PMが作った仕様に忠実に開発することに専念するといったケースが発生します。

製品をリリースするまでの時間を短縮できる

コンポーネントチームでは、後々の工程に入ってから判明する上流工程への手戻りや、各工程間のコミュニケーションコストの増加が発生します。

一方フィーチャーチームでは、上記のような遅延を引き起こす依存関係がなくなるため、リリースまでにかかる時間を短縮することができます。

以下では開発工程を表すバリューストリームマッピング(VSM)と呼ばれる図を使って、バリューストリームがどれだけ最適化されたかを見ていきます。*1

フィーチャーチームになってから、横長だったVSMが非常に短くなりました。これは仕様検討・デザイン・開発・QAのフェーズが全てチーム内で完結するようになった影響が大きいです。チーム内で完結するため、各工程の改善が加速しました。

また2年前はスプリント中にはエンジニアの実装工程しかありませんでしたが、今では多くの工程がスプリント中に完了しています。

ちなみに私の所属するチームでは、仕様・デザインをリファインメント中に決めています。別々だった工程がまとまり、依存関係が解消されました。

フィーチャーチームのデメリット

もちろんメリットばかりではなく、デメリットもあると感じています。

複数のフィーチャーチーム間のコラボレーションが不足する可能性がある
(特に専門性に関する)組織内ノウハウが溜まりにくい
チームメンバーはより多くの領域を学ぶ必要がある

複数のフィーチャーチーム間のコラボレーションが不足する可能性がある

各チームがバラバラにフィーチャー開発をしているため、コンフリクトが生じる可能性があります。コンフリクトはコードだけではなく、仕様やUXでも起こりえます。

各チーム間のコラボレーションを不足させない工夫（プランニングの際にコンフリクトがないか確認するなど）が必要になります。

(特に専門性に関する)組織内ノウハウが溜まりにくい

同じ会社に属するチームは似た問題に直面しがちですが、社内ノウハウが溜まっておらず、各々のチームがゼロから解決の道を探る可能性があります。また、設計やUI/UXがバラバラになってしまう懸念もあります。

これらは似たようなスキルや関心を持った人々のコミュニティを形成することで解決できます。

チームメンバーはより多くの領域を学ぶ必要がある

メンバー全員が何でもできる人になる必要はないですが、メンバーのうち何人かは他の新たな領域を学ぶ必要があります。そのためにお互いに教え合わないといけないので、教育コストもかかります。人によっては、教え方も学ぶ必要があります。

最後に

SmartHRでは顧客目線の開発体制を推進しています。デメリットはありつつも、顧客価値に繋がるメリットが大きいため、フィーチャーチームを採用しています。

興味を持たれた方は、ぜひ一緒に価値あるプロダクトを作りましょう！

hello-world.smarthr.co.jp

*1:本体機能はLeSSを導入しており、各チームでVSMは異なります。

SmartHR Tech Blog

SmartHR 開発者ブログ