私たちは幼い頃から潜在能力を最大限に発揮して目標を達成できるように、高い基準を設定するために「大きく考える」ことを教えられてきました。次の大きい目標を追求して大胆に実行しようというときに、企業もまた同じことをします。
しかし、大きく考えて「大きく困難で大胆な目標」に挑戦しようとすると、チームの作業が大きくなりすぎて処理しきれなくなるという事態が往々にして起こります。これらの大規模で規範的な取り組みは進行が遅く、顧客やユーザーに段階的に価値が提供されることはほとんどありません。または、まったく逆に、作業を小さくしすぎて、より長期的なビジョンを理解せずにあまりにも多くのタスクに取り組むことになる場合もあります。
Amplitude の製品研究および教育責任者である John Cutler 氏は、アトラシアンとの会話の中で、チームや企業が成功するためには、大きく考えて小さく作業する適切なバランスを見つけることが必要になることが多いと語りました。
作業を大きくしすぎていますか?
「作業を大きくしすぎる」と、基本的にチームが大規模プロジェクトに取り組むことになります。ここでは、価値が段階的に生み出されず実験が行われず、統合の頻度は低くなります。チームが大規模プロジェクトに挑戦すると、行き詰まってタスクを進めるための取り組みが迅速に行われなくなります。
チームの作業が大きすぎることを示す兆候には、顧客についての理解不足、現在の市場や最近のテクノロジーに関する知識の反映不足が挙げられます。この反映不足は、製品リリース時に企業が市場に後れをとる原因になります。スコープは利用可能な時間いっぱいまで拡大してロードマップ上の作業は増加し、チームは無理な計画に追いつくために苦労します。
しかし、なぜ企業やチームは作業を大きくしすぎるのでしょうか? 上級管理職を喜ばせて財源を獲得することを目指すなど、チームにとって多くのインセンティブがあります。明確な目標がある大規模プロジェクト計画は具体的な結果を生み出せるように見えるため、経営陣にとって魅力的です。
作業を小さくしすぎていますか?
対の問題として、チームの「作業を小さくしすぎる」ことがあります。つまり、チームが大規模プロジェクトのより小さい部分の作業を行いながら、自分の作業がより大きな戦略やミッションにどのように関連しているのかわからないということです。このアプローチではチームがアジャイルを採用しているように見えても、過剰な計画が発生するとアンチパターンが現れ始めます。たとえば、バックログに数百ものストーリーがある企業では、これらのストーリーの分析に時間がかかりすぎる可能性があります。さらに、作業が進む勢いは感じられてもレビューを 6 か月や 12 か月先にすると、チームにとって作業によってビジネスがどのように前進するかが見えにくくなります。作業はつながりを欠くリアクティブなものに見えます。
Cutler 氏はもう 1 つの問題として、大きい作業を小さいピースとして定義するチームを指摘します。チームは小さく作業しますが、フィードバックに対応することが難しくなる場合があります。レゴ ブロックと同じように、小さいピースをまとめる計画に従う必要があります。しかし、作業の 20% が価値の 80% を占めるとしたらどうでしょうか?
大きく考えて、小さく作業
そこで、作業を適度な大きさで捉えてみてはどうでしょうか? 「大きく考えて、小さく作業」することが適切なバランスの実現につながると Cutler 氏は語ります。これは「一貫した戦略にリンクされている説得力のあるミッション」を持つことを意味します。チームは会社のビジョンを理解して、そのビジョンをサポートして実現するタスクを作成して管理します。これは、影響と成果の観点から戦略的に考えて、6 か月または四半期先を見据えた戦略を立てながら、実験と検証のための十分な余地を確保することを意味します。
単に大きく作業しているなら、大きい目標にとって適切なコンテキストで小さく作業してみることを Cutler 氏は提案します。単に小さく作業しているなら、戦略的イニシアチブを定義してから作業に落とし込むと有益です。小さく作業して大きい目標を規範的に定義している場合は、規範性を緩和してミッションと戦略に焦点を合わせるようにします。
Cutler 氏によると、チームは作業の取り組みの「理由」から始まる学習バックログを作成できます。学ぶための「方法」ではなく、この新しい情報を学ぶことが大切です。「理由」から始めるということは、各タスクにコンテキストをもたらすことを意味します。チームは定期的にバックログ グルーミングを実行して、作業のバックログをレビューする必要があります。これによって、優先順位付けを適切に保ってフィードバックが取り込まれるようにできます。また、チームが作業上の課題にリアクティブ (受け身) であることを回避できます。
チームは学習バックログから始めることで、広範な調査によるものであれ何時間もかかる開発によるものであれ、学習が必要である内容に優先順位を付けます。また、このことは会社全体で共通言語を確立するためにも有益です。作業の分類法が設定されると、会社のさまざまな形や種類の作業をより適切に説明するために役立つためです。
結論
