ブログ

ryuzeeによるブログ記事。不定期更新

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料）

スクラムがフィーチャーファクトリー化しているサイン

みなさんこんにちは。@ryuzeeです。

「フィーチャーファクトリー」は、プロダクトマネジメントの専門家であるジョン・カトラー（John Cutler）¹が2014年に使い出した単語です。日本語にすると機能工場となり、単に与えられた要求をひたすら作り続けたり、アウトカムやインパクトよりも、作った機能の量や出荷スピードだけに注目したりするチームや組織を指します。

複雑で変化が激しい環境においては、事前に考えたことがすべてそのとおりになることはありません。端的に言うと、多くのものは外れます。外れることを前提にすると、成功するために数を打つこと、そして素早くそれを実行することはとても重要です。でも、それ「だけ」に注目するのは無意味です。

ジョン・カトラーは自身の記事「12 Signs You’re Working in a Feature Factory」のなかで、フィーチャーファクトリーで働いていることを示す12のサインを紹介しています。詳しくはリンク先を読んでもらうとして、この12個のサインをキャッチーな感じにすると以下のようになります。

成果？知らん、測ってないから
チームとプロジェクトでテトリス三昧編
「出せば勝ち」のお祭り騒ぎ
失敗ゼロ（なので学びもゼロ）
自分たちの仕事が何に効いてるんだっけ？
プロダクトマネージャーの辞書に「ふりかえり」という文字はない
決めるのはうまい（？）、でも確かめない
作って終わり、改善は誰もやらない
バケツリレー式の開発プロセス
「アジャイル風」だけど大盛り納品
目先の売上がすべて
ピカピカ新機能偏重

スクラムがフィーチャーファクトリー化しているサイン

では、スクラムを利用しているチームで、フィーチャーファクトリー化しているサインにはどのようなものがあるでしょうか？コーチングや相談などで自分が遭遇したものをいくつか紹介します。

スプリントにいつもたくさんの仕事を詰め込んでいる

「たぶん終わらないけど、とりあえず全部入れておこう」と考えて、スプリントにたくさん仕事を詰め込んでいるのは、フィーチャーファクトリーのサインです。溢れんばかりの仕事を詰め込んでしまう背景には、スクラムチーム外からの何らかのプレッシャー、「作業量の多さ」や「タスクを消化している感」が評価される文化、余裕があるように見えてしまうとチームメンバーが別のチームに引き抜かれてしまうことへの防御などがあります。

スクラム（アジャイル）では、チームが予測可能かつ持続可能なペースで価値を届けることが重視されます（アジャイルマニフェストにも書いてあります）。仕事をたくさんこなすことはスプリントの目的ではありません。

また、スクラムチームが成果を上げるためには継続的な学習が欠かせません。たとえば昨今はAIを使ったコーディングの技術的な進化が著しいですが、仕事を詰め込んで学習に投資をしないままでいると、チームとしての競争力がどんどん低下します。学習には余裕が必要です。

ベロシティをやたら気にする

「ベロシティが◯◯ポイント必要だ」という会話も、フィーチャーファクトリーのサインです。また「前のスプリントよりベロシティが上がった」という会話もその可能性があります。

「ベロシティが◯◯ポイント必要」というのは、つまり「期日までに完成させなければいけない仕事の量が決まっている」ことを指します。でも本来は「期日までの仕事の量」ではなく「期日までに実現したい価値やアウトカム」であるべきです。実現方法が柔軟であればあるほど、実現の可能性は上がりますが、最初から量が決まってしまっているとギャンブルになってしまいます。

また、チームがベロシティの上下をいつも気にしているのは不穏です。ベロシティはあくまで参考値であり、価値や成果を示す指標ではありません。それにもかかわらず、数字ばかり気にしているのであれば、チームにはプロダクトの価値やアウトカム以外にも強い関心ごとがあることを意味します。スクラムの価値観の1つに「集中」がありますが、このような状況は1つの目標に集中できていません。

未完成の仕事を次スプリントに頻繁に持ち越す

スプリントにたくさんの仕事を詰め込むと、当然ながら完成しない仕事が出てきます。その完成していない仕事をそのまま次のスプリントに持ち越すのは、わかりやすいフィーチャーファクトリーのサインです。これは、前述の「ベロシティをやたら気にする」に起因して発生することもあります。チームにとっては量のほうが大事という意思表示に他なりません。

スクラムはゴール主導のフレームワークです。中期的に達成したいプロダクトゴールを定め、スプリントごとにスプリントゴールを達成しながら、プロダクトゴールの実現を目指します。スプリントゴールが達成できれば、洗い出したタスクをすべて終わらせる必要はなく、選択したプロダクトバックログアイテムをすべて完成させる必要もありません。にもかかわらず、未完成の仕事を次スプリントに持ち越しているということは、スプリントゴールを達成できていないか、スプリントゴールが適切でないか、そもそもスプリントゴールに関心がないかのいずれかです。このような状況は改善が必要です。

スプリントゴールを決められない

たくさん仕事をこなすことを目的にすると、スプリントプランニングでスプリントゴール駆動でプロダクトバックログアイテムを選択するのではなく、先にプロダクトバックログアイテムを選択してから、それらに共通するテーマを無理やり見つけてそれをスプリントゴールとしたり、ひどい場合は「No. 774、889、5963のプロダクトバックログアイテムを完成させる」のような意味のないスプリントゴールを設定したりしがちです。

結果的に、何を達成したいのかが不明確なスプリントになります。スクラムは「短期間で意味のあるインクリメントを作って、それを通じて学ぶ」ための枠組みです。ゴールが不明瞭なスプリントは、ベルトコンベア上で物を作り続ける工場と同じです。

なお、「複数のスプリントゴールを設定したい」と思う場合も同様です。