エンジニアリングチームの技術の焦点: 過ぎたるは及ばざるがごとし

執筆者: Jakub Oleksy | @JakubOleksy & Matt Nigh | @mattnigh

エンジニアリング部門のリーダーは常にエンジニアリングチームを最大限に活用するよう要求されています。これはたいてい、どのようなものをどの程度迅速に出荷できるかによって評価されます。しかし、これはよくある罠に陥りがちです。つまり、一度に多くのことをしすぎると、並行作業が増えることでアウトプットも増えると思い込むのです。

私たちは多くの場合、少なくとも誰かに個々の物事のサイクルを担わせているだけで進展していると考え、自分をごまかしているのです。

しかし、やることを減らすことが実際には出荷を増やす鍵であるとしたら?

第一に、物事は出荷され、使用されて初めて有益になることを認識しなければなりません。そのため、目標は常に物事を導き出すことである必要があります。

いったん導出できれば、さらに追求するか否かの決定を含めて、学習し、適応させ、調整することができます。

これは明らかなことに思えます。結局のところ、最重要であると判断する物事の仕上げには必ず優先順位を付ける必要があるからです。

では、私たちに足りないのはどのような点でしょうか? ほとんどの場合、単純に私たちがノーと言えないことです。それ以外のことも素晴らしいアイディアであり、試行すらしないのも難しいでしょう。しかし、こうした決定 (実際には決定力のなさ) のひとつひとつは最も重要な物事を後回しにするだけです。

もうひとつは、関連する問題として、最も重要な作業を選択しても、それがたいてい一体的に遂行されることです。つまり、終了するまで、必要に応じた方向転換が難しいのです。

顧客に継続的な価値を提供する明敏なエンジニアリングチームの運営を目指すにあたって従うべきいくつかの中核的な原則があります。 - すべての作業を可視化する。 - 作業を小さな塊で定義する。 - 進行中の作業を制限する。 - 潜在的な可能性に向けた資金を確保する。 - おまけ: 未知のことに対応できる余力を残しておく。

すべての作業を可視化

エンジニアリングリーダーは、チームが取り組んでいることについての考えが明確であると思いがちです。

作業を可視化させると現実を無視できなくなります。すべてが 1 つの場所に確実に記録されていれば、チームが「些細な機能をもう 1 つだけ」処理できるというフィクションを続けることはできません。

リスト化すると、現実を確認し、過度なコミットメントを遮断し、余力と優先順位について真摯に対話するためのツールを得られます。さらに、視覚化すると問題を可視化できるだけではなく、実現できるソリューションも明確になります。

チームが集中的に取り組んでいるすべての作業を確認できれば、以下のことを実現できます。

- 優先するべき物事について情報に基づく意思決定を行える。 - 中断または中止するべき作業を特定できる。 - 作業を開始しただけということではなく、作業の完遂にチームを集中させ続けることができる。

これは、スーツケースのパッキングのように考えることができます。ジッパーが壊れるまで物を詰め込み続けることもできますが、最初にベッド上に全部並べ、実際に対処しているものが何かを確認することで成功に向けた意識的選択を下すことができます。

すべてを延々と追跡することが目標ではないことを忘れてはなりません。目標は、チームの時間とエネルギーを投じるべき場所についてさらに優れた決定を下す上で十分な現実をはっきりと確認することです。結局、最も生産性の高いチームはすべてを実行していないからです。つまり、適切な物事を実行し、それを完了させています。

作業を小さな塊で定義

エンジニアリング組織で実行できる最も強力な変革のひとつは、作業をより小さなピースに分割することです。この教訓は自身の経歴全体で繰り返し学んだことであり、ほとんどの場合、方向性を調整する必要が生じ、物事の中断という結果に対処せざるを得ませんでした。

作業項目は大規模にし過ぎると、有意義な進捗を示すことなくチームのエネルギーを消費するブラックホールになります。有能なチームでも数か月に及ぶ開発サイクルで行き詰まり、絶え間なく移動するゴールを追いかけて気運が急低下する可能性があります。

__作業を 1 ～ 2 週間単位にとどめておくと魔法がかかります。__これは恣意的なことではなく、人間の心理とチームのダイナミクスにかかわることです。開発者は有意義な取り組みを 1 週間以内に完了できると成功を規則正しく体験できます。そしてモチベーションを維持できます。さらに、個々のフローの状態を維持できます。最も重要なこととして、開発者は必要に応じ、何か月にも及ぶ作業を棒に振ることなく迅速に方向転換できます。

作業をより小さな塊に分割することで、熟考と調整の時間を生み出すこともできます。このアプローチは GitHub において、大量の内部ツールを出荷することから、社内開発チームと顧客の双方にメリットのある反復的な改善を実現することへ進化する上で私たちの助けとなりました。個々の小さな塊によって「これは引き続き適切な方向に私たちを導いているか?」と問いかける機会を得られました。

また、この小さな塊でコラボレーションも強化されています。作業を 1 ～ 2 週間単位にとどめておくことで以下を実現できます。

- コードレビューを管理しやすくなる。 - 知識の共有を自然に行えるようになる。 - チームの組み合わせを効果的に行えるようになる。 - フィードバックループを強化できる。 - 開発リスクを低減できる。

__しかし、本当に重要なポイントは、作業を小さな塊にすることで開発者フローをサポートしやすくなることです。__開発者は、ゴールを確認できて短い時間枠で有意義な物事を完了できると理解すれば集中力を維持することができます。大量の機能による複雑性に惑わされることもありません。気運も維持できます。

コード品質の領域でもこの違いを見たことがあります。より小さな塊にすると、テストにさらに集中でき、より徹底的にレビューできるため、開発のリスクを軽減できます。1,000 行のコード行を一度にレビューしようとすることと、2 週間で 100 行を 5 回レビューすることの違いです。どちらがよりよく精査できると思いますか?

比較的ゆっくりであると感じるかもしれません。実際に、X か月の初日から終了まで機能を完璧に計画し、それを最後まできちんと実行できるのであれば、さらに迅速に完了できる可能性が高まります。

とはいえ、そのリスクを検討することが重要です。第一に、着手時から計画を誤り、振り返るためのマイルストーンが一切定義されていないというリスクです。第二に、他の予見できない物事の優先順位が高くなった場合の、チームの作業の方向転換にかかるコストです。そして最後に、要件変更が必ず発生します。多くの場合、変更の規模はプロジェクトの全体的な規模に比例します。

物事をより小さなピースに分割することで開発スピードを低下させようとしているのではありません。実際には、進捗を可視化し、気運を維持し、チームが散発的かつ大規模な塊ではなく継続的な価値を提供できるようにすることで開発スピードを加速させているのです。そしてゴールを達成すれば、予測不可能なレースで疲れ果てることなく、実現させたことで満足感を得られます。

これを成功させる重要なプラクティスの 1 つはディーププランニングセッションを開催して 1 ～ 2 週間の個々のスプリントを開始することです。このセッションでは、出口基準は何か、誰が何をするかについて概略を明示します。また、作業をさらに小さな塊に分割しますが、これは多くの場合、半日以内の作業を見極めることによって行います。

進行中の作業を制限

開発者に複数の機能を割り当てることは生産性を高める経路のように思えるかもしれませんが、実際には生産性の破壊につながります。

開発者が複数のプロジェクトをこなすと、そのいずれについても有意義な進捗を達成しにくくなる可能性があります。5 種類のメニューを一度に料理しようとするようなもので、何かを焦がし、材料を忘れ、すべてに倍の時間がかかる可能性が高くなります。

コンテキスト切り替えは特にコストがかかります。開発者は機能をシフトさせると必ず、新しい機能のコンテキスト全体、特に、必須要件、技術的制約、関連コード、未解決の問題を再設定する必要があります。調査によれば、1 回切り換えると焦点を完全に取り戻すのに最大で 23 分かかる可能性があることが示唆されています。複数の機能に対応すると、開発者はコード記述にかかる実際の時間よりも多くの時間をコンテキスト切り替えに費やします。

品質にも悪影響が及びかねません。注意が複数の機能に分断されると、重要な細部が見落とされ、エッジケースが熟慮されず、技術的負債が積み重なる可能性があります。GitHub でもこのパターンを再三見てきました。つまり、進行中に作業が増えるとバグ数も増え、全体的なコード品質が低下したのです。

おそらく最も重要なポイントは、チームに欲求不満が生じたことです。開発者は作業完了とユーザーへの機能出荷の満足感を通じて成長します。すべてが「進行中」であっても、何も達成できていなかったら気力が急激に低下します。インパクトを体感できなかったという理由だけで有能なチームが弱気になったのを見たことがあります。それどころか、彼らは多過ぎる構想全体に薄く分散し過ぎていました。

このソリューションは長時間機能していないか、難化しています。一度にやっても成果は少なくなります。進行中の作業を制限し、チームを一度に 1 つか 2 つの機能に集中させると、実際にはより多くのものを、さらにはより優れた品質の作業を出荷でき、開発者の幸福度を高めることもできます。

チームが同時進行で担っている作業が多過ぎると判断する方法は?

チームレベルでの指標としては以下のようなものがあります。 - 開発者あたりのアクティブな複数の機能 (例: 同時進行のタスクが 4 つ以上)。 - 想定より週または月単位で長引いている機能。 - 多くの機能は部分的に完了しているが、ほとんど出荷されていない。

個々の開発者に関する指標としては以下のようなものがあります。 - 焦点の維持が困難であるか、フローの段階に関与しにくい。 - コードレビューへの対応が大きく遅れている。 - ステータスミーティングにおいて、実行中の作業の説明にかかる時間が増えている。 - 現在の優先順位を明確に示すことが難しい。 - 大規模なプルリクエスト (PR)

気力に関連する症状 - 完了が伴わないことによるチームの欲求不満 - インパクト感と達成感の低下 - 複数の優先事項をこなすことによるストレスレベルの上昇 - タスクの絶え間ない切り換えによる燃え尽き - 新たな構想に向けた熱意の喪失

デリバリーのパターン - 多くの機能は 80% 完了しているが、100% 完了しているものはごく少数 - デプロイ間の時間が増大 - 機能を開発途中で断念 - 緊急的な修正の数が増加 - 開始から完了までのサイクル時間が長期化

潜在的な可能性に向けた資金を確保

これは、最も優先順位の高い作業に十分な資金を確保してから次の物事に移るべきであるというアイディアです。これは、多くのエンジニアリング組織全体で見られる一般的なアンチパターンに対抗する単純な概念です。つまり、「1 人の開発者が 1 つの機能に対処する」アプローチです。

一般的な事例で説明します。8 人の開発者で構成されるチームがあり、あなたは 8 種類の機能を 1 つずつ、個々の開発者に割り当てます。これは理にかなっています。誰もが忙しく、すべての物事が前進しています。しかしこれは実際のところ、デリバリーのスピードを低下させ、知識を断片化させる方策です。

チームの誰もが昇進できるプロジェクトを望んでいるという理由でマネージャーがこの方策を取るのを頻繁に見かけます。マネージャーはそれを実現する唯一の方法について、どの開発者であってもプロジェクトを主導することであると考えているため、必然的に個々の開発者向けのプロジェクトを構築します。

ではこの場合はどうでしょう。最も優先順位の高い物事を取り上げて可能な限り多くの開発者をそれに割り当て、開発者たちはまさにイライラしています。その時、次の優先順位に移ったらどうなるでしょうか。これがいわゆる「潜在的な可能性に向けた資金の確保」であり、変革をもたらすものです。

これがなぜ機能するかについて明確にします。単一の機能に対し、チームとして集団行動すると以下のことが実現します。

- 知識がチーム全体に自然に広がる。 - コラボレーションを通じ、ソリューションの出現が速まる。 - リアルタイムのピアレビューを通じ、コードの品質が改善する。 - 機能の出荷が大幅に速まる。 - 達成感の共有を通じ、チームのエネルギーが蓄積される。

GitHub において、このアプローチは個々の割り当てを凌ぐパフォーマンスを繰り返し実現させています。たとえば、デプロイのパイプラインの改善に取り組んだ際、個々の開発者全体に作業を割り振りませんでした。私たちは作業に群がったのです。その結果、どうなったでしょうか? 私たちは出荷を速めることができただけではありませんでした。エキスパートが 1 人か 2 人だけ在籍するチームではなく、開発者全員がデプロイシステムを深く理解しているチームになったのです。

物議を醸すかもしれませんが、このモデルでは、開発者をペアにして個別のタスクに取り組ませることは有益である可能性があります。一緒に作業させることで開発者の時間を「浪費」していると感じるかもしれません。しかし、分離、つまり、知識のサイロ化、レビューサイクルの長期化、コード品質の低下、各機能を理解している人員が 1 人だけというバスファクターがもたらす隠れコストについて考えてください。

潜在的な可能性に向けた取り組みに資金を供給することで、スピードを最適化できるだけではなくチームのレジリエンスを構築することもできます。すべての機能は学習の機会として共有されるようになります。すべての課題は集団的な問題解決の機会になります。開発者がコーディングだけを担うのではなく、ともに成長する環境を生み出しているのです。

また、昇進に向けた要員の熱意を熟慮し、ここで報酬を成果次第にします。個々の生産性が成功の鍵であると考える要員ではなく、個々の成果以上にチームを尊重した、あるいは成果の改善に懸命に努力した要員をともに昇進させます。

未知のことに対応できる余力を残す

100% のキャパシティで運用されている高速道路は高速道路ではなく、駐車場です。同じ原則がエンジニアリングチームにも当てはまります。余力を確保して想定外の出来事に耐えられるようにする必要があります。その必要量はチームによって差があります。

チームが 100% のキャパシティで機能している場合、実際には不足した状態で運用されています。現実には、計画外の作業が事実上計画されていないからです。計画外の作業は避けられません。計画外に起きることはタイミングや仕様だけではありません。

未知のことに対応できる余力がなければ起きることを以下に示します。

- チームが創造的ではなく後手後手になる。 - 「失った時間を取り戻す」ために手を抜くため、品質に悩まされる。 - 開発者の満足度が急落する。 - 実験する余力が少なくなるため、革新が減少する。 - 技術的負債に対処できる時間がないため、技術的負債が積み重なる。

そこで、バッファとなる余力を意図的に維持すると、以下のことを実現できます。

- チームは、計画済みの作業を頓挫させることなく問題に対応できる。 - 開発者は、ソリューションについて創造的に考える余力を持つことができる。 - 学習、実験、革新に向けた余力を確保できる。 - チームが常に焦っていないので、品質を高く維持できる。 - 持続可能なペースを確保できるため、気力を強い状態で維持できる。

直観と相いれない真実があります。つまり、バッファとなる余力を組み込んだチームは、多くの場合、「フルの」余力で運用されているチームよりも多くの成果をもたらします。こうしたチームは革新性が高まり、レジリエンスが強化され、最終的に生産性が高まります。すべてが緊急事態になると、何もうまくいきません。

では、バッファの適正量は? 20% から開始し、チームのニーズに合わせて調整します。インフラストラクチャチームではさらに多く、機能開発チームではさらに少なくて済むかもしれません。それを計画的に考慮することが大切です。バッファの余力を無駄であると考えてはなりません。これは、現実に対処するチームの能力に対する極めて重要な投資であると見なす必要があります。

チームの余力は、予測できる作業だけが重要なのではありません。予測できない物事に対処できるレジリエンスを維持しつつ、開発者の創造性、エンゲージメント、最善の作業遂行を維持することが大切です。

まとめ

ここでは、より多くを出荷できるようになる道筋に高速化や開発者の増強は関係がなく、一度に行うことを減らすための原則の採用が重要であることを説明しました。そのやり方は見かけによらず単純です。 - 作業を可視化し、現実を隠せないようにする。 - 作業を、気運を維持できる小さな塊に分割する。 - 進行中の作業を制限し、焦点を当てられるようにする。 - 余力を確保するための優先的な取り組みに資金を提供する。 - 想定外の事態に備えて余力を残す。

しかし、単純だからといって簡単なわけではありません。これらの原則はリーダーとしての本能に疑問を投げかけます。つまり、「イエス」と言うよりも「ノー」と言う機会が多くなります。私たちが並行作業の魅力に抗い、より少ない物事に焦点を当てることで実際にはより多くを出荷できるようになると信じることが求められます。チームの真の能力は、チームがいくつの機能をこなせるかによって評価されるのではなく、顧客にいかに効果的に価値を提供できるかによって評価されるのです。リーダーとして実行できる最も強力な方策は、チームの負担を増やすのではなく軽減することである場合もあります。