ソフトウェア エンジニアリングではなぜ予測可能性が速度よりも優先されるのか

テクノロジーの世界では、開発チームの生産性を測る際にベロシティが頼りになることがよくあります。ベロシティは、アジャイル ソフトウェア開発で、チームが特定の期間内に完了できる作業量を測定するために使用される評価で、通常は各イテレーションで完了するストーリー ポイントまたはユーザー ストーリーで表されます。言い換えれば、チームがどれだけ速くコードを作成し、機能をプッシュするかがすべてです。しかし、スピードは素晴らしいことですが、バランスが正しくなければ、劣悪な結果や舞台裏での混乱につながる可能性があります。

他にも、相互に関連して進捗状況を追跡するための優れたシステムを構成する測定値は数多くありますが、速度は依然として最も一般的なものの 1 つであり、したがって最も誤用されているものの 1 つです。

速度の魅力…そしてその危険性

多くの場合、スピードが中心的な役割を果たします。チームは、新機能をいかに早く実現できるか、または最新の市場の変化に適応できるかに誇りを持っています。この速度の追求は、競合他社に遅れをとらず、ユーザーの関心を維持し、継続的に革新したいという願望を物語っています。思考プロセスは単純です。早く行動すればするほど、より多くの成果を達成でき、より多くの価値を利害関係者に提供できます。

では、分解してみましょう。フルスピードで作業することは、より重要なこと、つまり燃え尽き症候群をほとんどまたはまったく発生させずに、つまり一貫性を保って作業できる能力を逃すことを意味する場合があります。超高層ビルを超高速で建設できるが、基礎が不安定であることを想像してみてください。時間の経過とともに、これにより大量の技術的混乱が積み重なる可能性があります。これは、後でしわ寄せがくるその場しのぎのソリューションの隠れたコストです。確かに、超高速の配達には魅力がありますが、その後に生じる可能性のある頭痛の種について考えてみる価値はあります。

予測可能性: 強力なツール

測定としての予測可能性は、チームまたはシステムが一定期間にわたって結果をもたらす一貫性と信頼性を指します。チームはベロシティを重視するのではなく、予測可能性を高めることに焦点を移すべきです。

これにはいくつかの理由があります。

• ステークホルダーに対して明確な期待を設定します。

  ある月に 100 ポイントを獲得しても、次の 2 か月ではわずか 10 ポイントというさまざまな結果をもたらしたチームは、関係者にとってジェットコースターになる可能性があります。結果が定まっていないため、利害関係者は次に何を期待すればよいのか分からず、ジレンマに陥ります。代わりに、たとえば毎月 40 ポイントを継続的に達成するチームが MVP となり、ゲーム内で信頼できるプレーヤーになります。そして、それこそがビジネスの領域で本当に切望されているもの、つまり予測可能性です。

• エラーが少ないほど、ゲームは長くなります。

  予測不可能性は時折輝きをもたらすかもしれませんが、長期的に真に勝利を収めるのは予測可能性の安定です。ここで重要なのは、予測可能性へのロードマップは普遍的なものではないということです。確かに、各チームには独自の旅があります。しかし、トップパフォーマーにはパターンがあります。

  
  

  成熟したアジャイル プラクティスは、高いパフォーマンスを発揮する予測可能なチームに共通するものです。スクラム、カンバン、またはそれらの方法論の混合に没頭しているかどうかに関係なく、これらのチームは自分たちのコアと一致するリズムを確立し、構造化された作業と創造的な自由の両方のためのスペースを確保しています。その一方で、すべてのスプリントやイテレーションを前のスプリントやイテレーションよりも優れたものにしたいという、改善への絶え間ない意欲があります。

  
  

  具体的な例を考えてみましょう。 Atlassian の Jira は、単純なバグと問題の追跡ツールとして始まりましたが、世界で最も人気のあるプロジェクト管理ツールの 1 つに成長し、そのサービスを幅広い業界に提供しています。もちろん、会社の躍進にはさまざまな要因が膨大にありますが、予測可能性が最も重要な要因の 1 つであることは間違いありません。 Jira は、一貫した反復の歴史 (一貫した定期的な更新の展開)、フィードバック ループ、拡張可能なエコシステム、透明性の高いロードマップにより、世界中の多くの組織でその地位を確保しています。

バランス: 速度と予測可能性

この記事の私の最大の目的は、予測可能性が速度よりも優れている理由を示すことですが、私の義務は、ベスト プラクティスは常にこれら 2 つのバランスをとることであると言及することです。最も公平な測定を選択する場合、予測可能性が最も長期戦を約束するものであることは間違いありません。しかし、多面的な評価システムを構築できる能力がある場合は、両方 (またはそれ以上) の測定値を調整する方法を見つけることが最善の方法です。

その黄金の中間点を見つけるには、ハイブリッドなアプローチが必要です。これは、単に違いを分割することを意味するのではなく、両方の要素を開発ライフサイクルに統合することを意味します。たとえば、反復開発では、特定のスプリント中に速度が急激に向上し、その後、予測可能性と改良が優先される期間が続きます。スピードと一貫性の両方の価値を認識することで、チームは特定のプロジェクトやフェーズに合わせてアプローチを調整し、それぞれの強みを活用してタイムリーで信頼性の高い製品を生み出すことができるようになります。

結論として、ソフトウェアの領域が終わりのない負担であると感じるべきではないということを心に留めておくのは、難しいですが本当に重要です。すでに複雑なエンジニアリング作業が、問題を抱え、時には浅薄な指標によってさらに複雑になると、仕事の本当の本質が曖昧になり、不必要な緊張が高まることがよくあります。あなたが技術チームの指揮を執っている場合、成功をどのように評価し、チームを指導するかを熟考することが極めて重要です。最も良いのは、評価したい他の開発者に質問し、チェックし続けることです。