- エンジニアリングチームはしばしば「より多くの機能をより速くリリースする」ことを求められる
- しかし、あまりに多くの作業を同時に進めると、かえって生産性は低下する
- 「より多くをリリースする秘訣は、むしろ少なくすること」 -
Less is More
主要な原則
- すべての作業を 可視化 する
- 作業を 小さな単位で定義 する
- 進行中 の作業を 制限 する
- キャパシティに合わせてリソースを配分 する
- ボーナス: 不測の事態に備えて 余白を確保 する
# すべての作業を可視化する
- 作業を可視化すると、現実を直視できる
- すべての作業が一目で見えると、次のような利点がある
- 優先順位を明確に設定できる
- 不要な作業を中止または一時停止できる
- チームが始めた作業を完了させることに集中できる
- 目的は、すべての作業を永遠に追跡することではない → 現実を明確に把握し、より良い意思決定を行うため
# 作業を小さな単位で定義する
- 作業が大きすぎると、チームのエネルギーが消耗し、進捗も明確でなくなる
- 作業単位を1〜2週間程度に制限 する
- 開発者は短期的な成果によってモチベーションを維持できる
- すばやくフィードバックを受けて修正できる
- 小さな作業単位の利点
- コードレビューがしやすくなる
- 自然な知識共有が進む
- チームメンバー間の協力が強まる
- デプロイのリスクが下がる
- 作業単位を小さくするとスピードが上がる → 複雑な機能に圧倒されず、モメンタムを維持できる
# 進行中の作業を制限する
- 複数の機能を同時に処理すると、かえって生産性が低下する
- コンテキストスイッチのコスト が発生する → 新しい作業に適応するのに最大23分かかる
- 進行中の作業が増えるほど、次のような問題が発生する
- チームレベルの過負荷のサイン
- 開発者1人あたり4件以上の作業を抱えている
- 完了までの時間が想定より長くなる
- 完了した機能より進行中の機能のほうが多い
- 個人レベルの過負荷のサイン
- 集中力の低下
- コードレビューへの応答時間の増加
- ステータス会議で優先順位の説明が難しい
# キャパシティに合わせてリソースを配分する
- 「1人の開発者が1つの機能を担当する」というアプローチは非効率である
- 最も重要な作業にチームのリソースを集中 する
- 協力が強化される → 問題解決のスピードが向上する
- コード品質が向上する → リアルタイムのピアレビューが活性化する
- 作業完了までのスピードが上がる
- 開発者は協力を通じて、より深い理解を得られる
- チーム単位の成果を促すべき → 個人の成果ではなく、チームの成果を重視する
# 余白を確保する
- 100%のキャパシティで運営すると、かえって成果が落ちる
- 想定外の作業は避けられない → いつ発生するかわからないだけ
- 余白がないと起こる問題
- チームが場当たり的に働くようになる
- 品質の低下
- イノベーションの減少
- 技術的負債の増加
- 余白があると、次のような利点がある
- 想定外の問題にも柔軟に対応できる
- 創造的な問題解決が可能になる
- 高い品質を維持できる
- 持続可能な作業ペースを維持できる
- 適切な余白は約20% → チームの特性に応じて調整可能
主要戦略の要約
- 作業を可視化 → 現実を直視できるようにする
- 作業を小さな単位で定義 → モメンタムを維持
- 進行中の作業を制限 → 集中力を高める
- キャパシティに合わせてリソースを配分 → 優先順位に沿って集中
- 余白を確保 → 柔軟性を確保
結論
- より多くの作業をこなすためには、むしろ少なくする戦略 が必要である
- チームの成果は、どれだけ多くの機能を同時に処理したかではなく、どれだけ効果的に顧客へ価値を提供できたか で測るべきである
- リーダーの役割は、チームにさらに多くの作業を追加することではなく、不要な作業を取り除くこと である
12件のコメント
ギークニュースで何度も言及されていた本『フェニックスプロジェクト』でも、似たような話が出てきます。稼働率が100%に近づくほど、応答時間は指数関数的に長くなる、と。
おお。その話は『Goal』という本にも出てきます！
『フェニックス・プロジェクト』自体が『The Goal』のIT版として書かれた本ですからね。
えっ……ありがとうございます！！
業務を80%、余白を20%確保しようとしていますが、どんな基準で決めるべきか…毎回悩みますね。単純に時間ベースで考えるべきなのかとも思います。
だから私は金曜午後は、個人開発の時間として完全に空けてあります！
このように細かいタスクに分割してしまうと、大きな全体像を持っているリーダーの権限が大きくなります。一緒にいるエンジニアたちは、むしろ動機を失って「自分たちはいったいどこへ向かっているんだ」となってしまいます。スプリントベースのアジャイルの代表的な欠点です。
あまりにもリーダーの視点だけで書かれているように思いますね、タイトルどおり。
エンジニアのモメンタムは、リーダーが旗をどの方向に掲げているかにも大きく影響されます。顧客に提供したい価値が何なのか、各スプリントごとのoutputとdelivery outcomeが何なのかを示せる方法についても、もう少し考える必要がありそうです。もちろん難しいソフトスキルなので、きちんとできるリーダーを見ることも少なく、そうした文章もあまりありませんが。
このコメントには強く共感します。技術的な部分に対するマイクロマネジメントが発生するリスクがありました（あります）。本当に簡単ではありません。
大きな全体像を共有し、全員が理解した状態で業務を小さなタスクに分割することではないでしょうか??
1〜2週ごとに分けることになると、自然と1つの機能についての全体像は限られた人しか分からなくなる気がします。プロセスとスレッドの違いのように。関心を限定しつつ生産性を高めるわけですから。
たとえ全体像を共有したとしても、その全体像に対して疑問を持つだろうという前提ではあるのですが、スプリントプランニングのたびに少しずつ変わる方向性に応じて、大きな絵をどう追っているのかを合わせられない、という前提も私が自然に置いていたようです。
私はこの記事で示されている内容に全面的に同意しつつ、ご指摘の問題にも同意します。
実際、私自身が悩んでいるポイントでもあります。
スクワッドごとに違いはありましたが、スプリントプランニングにチームメンバーを積極的に参加させると、ご指摘の問題は発生しませんでした。プロジェクトの文脈を共有し、スプリントごとに変化する状況を共有しながら、変わっていく作業を十分に認識できるよう努める一方で、作業はかなり細かく分解して分けてみようと求めました。
おっしゃる通り、管理の観点で進捗状況、作業速度の測定、予期しない状況への対処、作業内容が意図通りにならなかったときの機会費用を考えると、細かく分けたほうが結局はうまく進むことが多いですね.
似たような文章が繰り返されますが、人間の欲は尽きず、同じ失敗を繰り返してしまいますね
コンピュータのCPUロードが100%なのは正常ではありませんが、
人間の業務負荷が100%なのは、もっと頑張るべきだ……という結論になってしまうのですから