会社をアジャイルにしたい場合に正しく理解すべき 9 つのこと

アジャイルであるということは、変化する環境に対応し、顧客価値を提供し、継続的に学び続けることを意味します。それは必ずしもスプリントを実施したり、ユーザーストーリーを書いたり、オフィスの壁をカラフルな付箋で埋め尽くしたりすることではありません。アジャイルトランスフォーメーションについて話すとき、私たちは通常、組織レベルでの文化、考え方、問題へのアプローチを変えることを意味しています。

しかし、それは言うほど簡単ではありません。一つのチームは少しのサポートやコーチングでアジャイルになることができますが、組織レベルに移行すると、チーム間のコラボレーション、目標設定、予算配分、そして変えるべき他の多くの要素を考慮しなければなりません。フレームワークやトランスフォーメーションのアプローチ、組織の規模にかかわらず、組織のアジャイル性を実現するために必要な重要な要素がいくつか存在します。

1. アジャイルリーダーシップ

「本当にアジャイルな組織は完全にフラットであるべきで、マネージャーはすべて解雇されるべきだ」という意見を耳にすることがあります。このような考え方のために、アジャイルトランスフォーメーションの大きなチャンスが失われることがあります（当然ですが、マネージャーたちはこの考えに賛同しません）。

確かに、よりフラットな組織を目指し、階層レベルを減らすことは望ましいですが、それ以上に重要なのは、マネージャーにアジャイルリーダーとしてのスキルを身に付けさせることです。彼らはもう意思決定を行ったり指示を出すのではなく、チームをサポートし、チーム間のコラボレーションを促進し、他者をコーチングする役割を果たすことになります。どの組織にも権力を何よりも重視するマネージャーが数名はいますが、そのような人にとってはこの移行は非常に難しいかもしれません。一方で、他の多くの人々は新しい役割をむしろ魅力的だと感じるでしょう。意思決定を独占する代わりに、複数のアジャイルチームの創造性を吸収し、彼らが行き詰まったときに助け、自分の知識やスキルを共有しながら成長を楽しむことができます。

2. トレーニングを受けたプロダクトオーナー

組織全体がアジャイルになるにはトレーニングが必要ですが、特に重要な役割を担うのがプロダクトオーナーです。彼らは、チームの目標を設定する方法、バックログを作成し優先順位を付ける方法、ステークホルダーと協力する方法、そしてチームを動機付けする方法を学ばなければなりません。プロダクトオーナーは、目的意識があり、独立して行動でき、野心的である必要があります。また、製品に関する深い知識と優れたソフトスキルも必要です。

トランスフォーメーションを行う前に、プロダクトオーナー向けの内部ブートキャンプやアカデミーを開催し、新しいスキルを学び、実践する機会を提供することが非常に重要です。このような場でお互いを知り、強力なネットワークを築くことで、後にアジャイルチーム間のコラボレーションを促進する基盤が作られます。

3. 製品を中心に構成されたチーム

アジャイルトランスフォーメーションの重要なステップの一つは、組織設計です。このステップでは、新しいチーム、役割、報告ラインを特定します。多くの場合、従来の機能別チームをクロスファンクショナルチームに変換する必要があります。トランスフォーメーションを成功させるためには、チームが製品全体に対してエンドツーエンドで責任を持つことが不可欠です。たとえば、デザイナーのチームだけではアプリのデザイン全体に責任を持つことはできませんが、プロダクトオーナー、デザイナー、エンジニア2人、テスター1人で構成されたチームなら可能です。

アジャイルトランスフォーメーションは、まず組織内のすべての製品とプロセスをマッピングし、組織全体を再設計してクロスファンクショナルチームを構築し、彼らに製品の完全なオーナーシップを与えることから始まります。

4. 心理的安全性

チームが製品に対してエンドツーエンドで責任を持つには、自ら意思決定を行い、実験し、新しいアイデアを試すことができる安全な環境が必要です。実験や新しいアイデアは成功につながる場合もあれば、失敗につながる場合もあります。従来の組織では成功が称賛され、失敗は罰せられることが一般的です。しかし、アジャイル組織ではどちらも称賛されます。失敗は新しいことに挑戦し、貴重な学びを得た証だからです。もちろん、繰り返される失敗は別の問題ですが、イノベーションを推進するためには、実験や新しい挑戦を奨励する必要があります。

5. チーム間の整合性を取るプロセス

Scrumなどのフレームワークから、1つのチーム内でプロセスをどのように組織するかを学ぶことができます。しかし、このチームは真空状態で存在しているわけではありません。アジャイルトランスフォーメーションを行う際には、複数のチーム間での調整やコラボレーションをどのように組織するかを考える必要があります。

これは非常に難しい課題です。一方では官僚主義を減らし、セルフオーガナイズと常識を促進したいと考えますが、他方ではアジャイルに不慣れな会社では一定のガードレールが必要です。そうしなければ、知識が共有されなかったり、依存関係が解決されなかったりする可能性があります。

SAFeのようなフレームワークでは、チーム間のプロセスに関する詳細な概要を提供していますが、多くの場合、それらは会社の文脈に合わせて再設計し、実際に価値をもたらすようにする必要があります。

6. パフォーマンス管理

多くの従来型の組織では、個人目標やKPIが設定され、定期的にマネージャー（または同僚とマネージャー）によって評価されます。しかし、アジャイルの世界では、この方法が問題を引き起こす可能性があります。特に、チームメンバー個人の目標が一致しない場合（そしてその可能性は非常に高いです）。

アジャイルトランスフォーメーションの一環として、目標設定のアプローチを変更する必要があります。個人目標ではなくチーム目標に焦点を当て、パフォーマンス管理をそれに合わせて調整する必要があります。 同時に、個々の成長を支援し、プロフェッショナルスキルを向上させる手助けをすることも重要です。したがって、パフォーマンス管理システムにはこれらの要素も考慮する必要があります。

7. ベンダーの関与

アジャイルトランスフォーメーション後でも、製品開発に外部ベンダーを関与させることは可能ですが、そのアプローチを変更する必要があるかもしれません。アウトソーシングの最大の問題は、ミニ・ウォーターフォールが発生しやすく、「ブラックボックス化」することです。通常、チームが要件を定義し、それをベンダーに渡し、しばらく待った後（ブラックボックス）、最終結果を受け取りますが、それが必ずしもニーズを満たすとは限りません。

アジャイルの世界では、ベンダーをチームメンバーとして扱い、一緒に計画、レビュー、振り返りを行うようにします。彼らが顧客や要件をより深く理解するためには、プロセスに関与する必要があります。同様に、私たちもベンダーのプロセスに関与し、必要な情報を適時提供したり、変更を早めにリクエストしたりする必要があります。

課題となるのは契約です（ベンダーをチームに統合することが常に可能とは限りません）。また、ベンダーに提供する追加のアジャイルトレーニングが必要になる場合もあります。

8. 目標設定プロセス

アジャイルトランスフォーメーション後、チームは（うまくいけば）セルフオーガナイズされ、自分たちで目標を設定し始めるでしょう。しかし、それらの目標がすべて会社の目標や全体の戦略と一致していることをどうやって確認するのでしょうか？また、異なるチームが同じことに取り組んでいることを知らないまま進めるのをどう防ぐのでしょうか？さらに、チーム間の依存関係をどのように調整するのでしょうか？

これにはチーム間での目標設定プロセスが必要です。一般的には四半期ごとのOKR（Objectives and Key Results）の形式で行われます。OKRは、チームが会社（または部門）のOKRに合わせて目標を立てる一方で、「何を、どのように達成したいか」を柔軟に決定できるようにします。OKRの作成、レビュー、最終化のプロセスや依存関係の追跡・調整は簡単ではなく、組織に合わせてカスタマイズする必要があります。

9. 予算配分

最後に予算についてです。これはしばしば大きな痛点となります。特に、厳格なプロジェクト管理プロトコルが存在する会社の場合、問題が顕著です。チームは変化に迅速に対応するための柔軟性を持つ必要があります。そのため、プロジェクトごとに予算を厳密に固定すると、成功を妨げることになります。

他のアジャイルトランスフォーメーションの要素と同様に、「これが正解」という単一のソリューションは存在せず、各会社の文脈に合わせて調整する必要があります。ただし、一般的なベストプラクティスとしては、チームに予算枠を割り当て、柔軟性を持たせ、大規模な支出についてのみ承認を求める方法があります。その代わり、チームは完全な透明性を確保し、チームのビジョンや目標に従ってビジネス成果を出す責任を負います。

もちろん、これらは概要に過ぎません。それぞれのトピックには詳細な説明が必要で、何ページにもわたる内容になるでしょう。ただし、アジャイルでは（原則や価値観を除いて）固定されたものは何もないことを理解することが重要です。すべてのトランスフォーメーションケースは非常に個別的であり、それぞれに異なるアプローチが必要になるかもしれません。