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

言うは易し、行うは難し！サポートとコーチングがあれば1つのチームがアジャイルになることは可能ですが、組織レベルに移ると、チーム間のコラボレーション、目標設定、予算配分など、変更しなければならない多くの要素について考える必要があります。フレームワーク、変革へのアプローチ、組織の規模に関係なく、組織の機敏性を達成するために正しく行う必要がある要素がいくつかあります。

時々、真にアジャイルな組織は完全にフラットであり、マネージャーは全員解雇されるべきだという意見を聞くかもしれません。そして、そのようにしてアジャイル変革の多くの素晴らしい機会が失われていきます（明らかにマネージャーはこのアイデアに夢中になりません）。

私たちは確かに組織をフラットにし、階層レベルの数を減らしたいと思っていますが、より重要なのは、マネージャーにアジャイルリーダーになる方法を教えることです。それは彼らがもはや意思決定をしたり、命令を出したりすることでなく、代わりにチームをサポートし、チーム間のコラボレーションを可能にし、他の人を指導することを意味します。どの組織にも何よりも権力を重視する管理職の人々が数人必ずいます。彼らにとってこの移行はかなり苦痛かもしれませんが、他の人々は通常、自分の新しい役割をはるかに興味深いものと考えています。唯一の意思決定者である代わりに、複数のアジャイルチームの創造性に浸り、チームが行き詰まったときに助け、自分の知識とスキルを共有し、彼らの成長を楽しむことができます。

アジャイルになるためには組織全体がトレーニングを受ける必要がありますが、物事を正しく行う上で最も重要な役割はプロダクトオーナーです。彼らはチームの目標を設定する方法、未処理事項を作成し優先順位を付ける方法、利害関係者と協力する方法、チームを動機付ける方法を学ぶ必要があります。プロダクトオーナーは目的主導型で、独立しており、野心的であり、製品に関する深い知識と素晴らしいソフトスキルを持っている必要があります。

変革を起こす前に、プロダクトオーナー向けの社内ブートキャンプまたはアカデミーを組織することが非常に重要です。そうすることで、プロダクトオーナーが新しいスキルを学び実践しながら、お互いを知り、後にアジャイル チーム間のコラボレーションを可能にする強力なネットワークを構築できるようになります。

アジャイル変革の重要なステップの1つは、新しいチーム、役割、報告ラインを特定する組織設計です。ほとんどの場合、部門横断型に変換する必要がある機能的チームを扱うことになります。変革の成功を保証するためには、チームが製品に対して最初から最後までの責任を持つことが絶対に重要です。デザイナーだけのチームがアプリのデザインに対する全責任を負うことはできませんが、プロダクトオーナー、デザイナー、エンジニア2名、テスター1名で構成されるチームはそうすることができます。

アジャイル変革は、組織内のすべての製品とプロセスを計画し、部門横断的なチームを構築し、彼らに完全な製品所有権を与えるために構造全体の再設計から始める必要があります。

チームが製品に対する最初から最後までの責任を完全に負うとき、彼らは安心して独自に意思決定を行い、新しいアイデアを試し、実験する必要があります。実験や新しいアイデアは、失敗する場合もあれば成功する場合もあります。伝統的な組織では成功には報酬が与えられ、失敗には罰せられます。アジャイル組織では、両方に報酬が与えられます。失敗するということは、あなたが新しいことに試み、貴重な学びを得たことを意味します。もちろん、失敗を繰り返すことは別の話ですが、組織内のイノベーションを推進するために、新しいことを試みたり、実験したりすることを奨励する必要があります。

私たちはスクラムや他のフレームワークから、1つのチーム内のプロセスを組織する方法を学ぶことができます。しかし、このチームは孤立して存在しているわけではありません - アジャイル変革を行うとき、チーム間の調整とコラボレーションを最適な方法でどのように組織するかを考える必要があります。これは難しいです。なぜなら、一方で官僚主義を減らし、自己組織化と常識を奨励したいですが、一方でアジャイルに慣れていない企業では人々に何らかのガードレールが必要です。そうしないと、知識が共有されず、依存関係が共有されない可能性があります。

SAFe などの一部のフレームワークでは、チーム間のプロセスの詳細な概要が示されていますが、ほとんどの場合、企業のコンテキストに適合し実際に価値をもたらすためには再設計する必要があります。

多くの伝統的な組織では、人々は個人的な目標やKPIを設定し、時々マネージャー（または同僚とマネージャー）によって評価されます。アジャイルの世界では、特にチーム内の人々の個人的な目標が一致しない場合（おそらく一致しないでしょう）、問題を引き起こす可能性があります。

アジャイル変革の一部として目標設定へのアプローチが変わります。私たちは今、個々の目標ではなく、チームの目標に注目しており、パフォーマンス管理はそれに応じて調整されるべきです。同時に、各個人の成長をサポートし、彼らが専門スキルを開発するのを助けることが重要なので、パフォーマンス管理システムはそれも考慮する必要があります。

アジャイル変革を行った後も、製品開発にベンダーを関与させることはできますが、アプローチを変更する必要がある場合があります。 アウトソーシングの主な問題は多くの場合、一連のミニウォーターフォールが発生し、ブラックボックスが作成されることです。 最も一般的には、チームは要件を定義し、それをベンダーに提出し、しばらく待って (ブラックボックス)、最終的な結果を得る必要がありますが、それが必ずしも彼らのニーズを満たすとは限りません。

アジャイルの世界では、私たちはベンダーを私たちのチームのメンバーとして扱い、計画、レビュー、振り返りを一緒に行います。彼らは私たちの顧客と私たちの要件をよりよく理解するために、私たちのプロセスに関与する必要があります。私たちは、手遅れになる前に変更を要求し、必要な情報を提供するために、彼らに関与する必要があります。

難しい部分は契約（常にベンダーをチームに統合することは可能ではありません）と、ベンダーに提供する必要がある追加のアジャイルトレーニングです。

アジャイル変革後、チームは（うまくいけば）自己組織化され、自分たちの目標を自分たちで設定し始めます。しかし、彼らの目標がすべて会社の目標と全体的な戦略と一致していることを確認するにはどのようにしたらいいでしょうか？2つの異なるチームが知らないうちに同じことに取り組んでいないことを確認するにはどのようにしたらいいでしょうか？そして最後に、チーム間の依存関係をどのように調整したらいいでしょうか？

これら全てに、クロスチームの目標設定プロセスが必要です。最も一般的には、四半期ごとのOKRの形式で行われます。OKRにより、チームが会社（または部門）のOKRに合わせた目標を立てることができ、何をどのように達成したいかについて柔軟に決定することができます。OKRの起草、レビュー、最終化のプロセス、および依存関係の追跡と対処は単純ではなく、組織に合わせて調整する必要があります。

最後に、予算です。これは特に会社が厳格なプロジェクト管理プロトコルを実施していた場合、大きな問題となることがよくあります。チームは変化に迅速に対応するための柔軟性を備える必要があるので、プロジェクトごとの正確な予算を固定すると、成功から遠ざかることになります。

アジャイル変革のすべての他の側面と同様に、あらゆる種類に適合する万能のソリューションはなく、各企業の状況に合わせて個別に調整する必要がありますが、一般的に最も良い方法は通常、チームに予算枠を割り当てながら柔軟性を許可し、大きな支出のみ承認を要求することです。その代わりに、チームは完全な透明性を作り出し、自分たちのチームのビジョンと目標に従ってビジネス成果を達成する責任を負います。

もちろん、これは単なる概要に過ぎず、これらの各トピックは複数ページにわたる詳細な説明が必要です。しかし、アジャイルにおいて原則と価値以外にきまったものはないことを理解することが重要ですので、全ての変革ケースは非常に個別であり、異なるアプローチを必要とするかもしれません。