ブログ

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

直近開催のScrum Alliance認定スクラムマスター研修のご案内

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロダクトオーナーに何でも決めさせる開発者

「それってプロダクトオーナーが決めるんでしょ?」「決めてくれないと作れません」といった言動や態度がチーム内に広がっているなら、フィーチャーファクトリーのサインです。

スクラムチームは、協働して価値を届けることが求められるユニットです。プロダクトオーナーだけに意思決定を任せてしまうと、開発者は「与えられた作業をこなす人」になり、能動的な価値創出から遠ざかります。これはフィーチャーファクトリーにありがちな「投げられた仕様を黙々と実装する」姿勢とよく似ています。


上記のような状況は改善が必要です。スプリントレトロスペクティブなどを活用して、スクラムチームで話をしてみることをお勧めします。

それでは。

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

  1. 最近は、The Beautiful Messというサイトで毎週記事を書いています。役に立つ内容が多いのでぜひ購読をお勧めします。 ↩︎

前の記事 【資料公開】ソフトウェア開発におけるオプションとは何なのか?
次の記事 【資料公開】開発組織の進化・スケーリングと「開発生産性」

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World