製品やサービスの開発には、多くの場合、迅速な実験による学習が重要です。また、多様なスキルや専門知識を持つ人々が協力し合うことも前提となります。そのためには、コラボレーションをサポートする環境が必要です。また、このデジタル時代を生き抜くためには、価値ある目標に突き動かされ、ポジティブな影響を与えようとするモチベーションを持ったチームに大きく依存しています。競争の激しい市場においては、リスクをコントロールしながら、Time-To-Market（市場投入までの時間）を短縮し、上記すべてを行う組織の能力が真の競争優位性となっています。
残念ながら日本が例外の１つになるかもしれませんが、アジャイル開発、特にスクラムは、上記を達成するための非常にポピュラーな方法となって来ています。VersionOneが毎年行っているグローバル調査の2022年版では、回答者の80％以上がスクラムまたはスクラムを含むハイブリッドを導入していると答えています。
しかし、アジャイル開発を導入している回答者のうち、28％が「満足していない」と回答しています。この不満の大部分は、以下のような理由から来ています。
- 経営層の関与が不十分（Not enough leadership participation）、42%
- アジャイルに関する知識が不十分（Not enough knowledge about Agile）、40%
- 変化に対する一般的な組織の抵抗（General organizational resistance to change）、40%
- 上司からのサポートが不足（Lack of management support）、38%
これらの問題に取り組むのは簡単ではないが、以前にも他の人たちが取り組んでおり、その経験から学べることはたくさんあります。
**組織構造と文化を意識する**
組織は、既存の文化、プロセス、目的をサポートするように構造化されています。特に大きな組織では、それらの目的が何であろうと、最初から柔軟性やスピードでイノベーションを起こす能力がTop Priorityであることはほとんどありません。
チームの働き方を変えようとすると、既存の構造が根本的に邪魔になります。組織を適応させなければ、スクラム導入は少なくとも部分的に失敗し、最初の構造がチームを従来のやり方に引き戻してしまうことが多いです。
具体例①：機能横断的なスクラムチームは共通で唯一のプロダクトゴールとスプリントごとにスプリントゴールを設定します。しかし、伝統的な組織では、これらの目的は各部門や個人ごとに定義された目的と共存しています。後者が人のパフォーマンスを評価するために使われると、スクラムチームの共通目的は二の次になり、スクラムチーム内の作業はサイロ化したままになってしまう傾向が見られます。
具体例②：スクラムチームは、「今あるものから始めるよう」と決めて、やりながら学び、進歩するにつれて学んだことをステークホルダーに対して透明化することができます。これがまさにスクラムのコアとなる複雑な問題に対応するアプローチです。ただし、アジャイル開発に慣れていない伝統的な組織は、チームからの「新しい学習」のすべてを、計画と準備が不十分であることの証拠とみなす傾向があります。プロジェクトの途中での新しい気付きに対して透明性を保つことがいかに問題になるかを見て、チームは情報を隠し始め、詳細な計画を立てずに何かをすることをやらなくなってしまいます。
**全体像を把握しながら、小さく始める**
しかし、だからといって会社の構造を完全に見直すまで、機能横断的な自己管理型チームを立ち上げない方がいいという意味ではありません。逆に、スクラムはできれば小さく始めるべきだと思います。そこから、プロダクトやそのプロダクトを開発するチームを少しずつ改善させるとともに、組織全体も改善させていくようにしましょう。
ただ、スクラム導入に取り組むなら、経営陣・リーダーは、最終的に自分たちが何に直面しているのかを意識することも重要です。スクラムは、開発者の働き方をマイナーチェンジするものではありません。特に大きな組織では、スクラム導入は努力が必要で急進的な変化です。
**難しい質問を探る**
組織にとって重要なのは、「なぜ働き方を変えることにしたのか」について足並みを揃えることです。ただし、パワーポイントのスライドに「顧客重視になる」や「デジタルを活用する」など、表面的な理由を書くだけでは十分ではありません。残念なことに、私はこのようなかっこいい資料をよく目にしてきました。チームとそのリーダーは、次のような、より厳しい問いを探求することをお勧めします。
- 柔軟性を高めるために、何を手放してもいいのか？
- それを実現する責任は誰にあるのか？
- 現在の組織体制、働き方、文化で気に入っているもののうち、なくなる可能性があるものは何か？私たちはそれでも構わないのか？
- 成功していることをどうやって確認するのか？
- 最悪のシナリオは？それを防ぐには？
- スクラム・アジャイルを機能させるために行動しなければならないが、まだ議論に参加していないのは誰か（人事、コンプライアンス、財務、マーケティングなど）？
私が組織の支援を依頼されたとき、このような会話をするようにしています。一度だけではありません。スクラムを活用したプロダクト開発と同様に、スクラム導入自体も透明性、検査、適応が必要な反復プロセスです。そのような会話には、私はしばしば「リベレイティングストラクチャー」（Liberating Structures）を活用するようにしています。リベレイティングストラクチャーとは、「すべての人を巻き込み、解き放つ」ためのコラボレーションのテクニックです。リベレイティングストラクチャーは、特に、最後に到達する結論や決定だけでなく、その途中の会話にも価値があるような会話において非常に効果的です。「アジャイルサムライ」で有名になったInception Deckもためになる時があります。
**リーダーや様々な部門を巻き込む**
私は複数のスクラムとアジャイルの導入に携わってきました。ある会社ではスポンサーがCEOであったり、ある会社ではスポンサーがCIO/CTO/COOであったり、小さな会社ではスポンサーが一人のエンジニアリングマネージャー/ディレクターであったりしました。
スクラム・アジャイル導入のスポンサーが誰であるかによって、その結果の差は驚くほど大きくなります。繰り返しますが、スクラムは開発者の仕事のやり方を変えるものではなく、もっと根本的なものなのです。したがって、CEOのサポートなしで達成できることは限られています。
例えば、財務部門の協力がなければ、予算配分のプロセスを変えることは難しいです。また、マーケティングや営業部門のサポートがなければ、スクラムチームをエンドツーエンドで完全に機能横断的にすることは難しいです。
とはいえ、全員が最初から支持者や声高なサポーターになる必要はありません。人々が懐疑的になるのはよくあることです。実際、懐疑的であることはヘルシーで、カーゴ・カルトアジャイルを避けるためには大事なことだと私は思います。しかし、新しいことを試し、とりあえず何が起こるかを見ようとする意欲は少なくとも必要です。
組織全体の足並みを揃えることの重要性と、それを行うことの難しさは、小さく始めるもうひとつの正当な理由です。そして、最初のスクラムチームが少しずつ前進し、組織に良い影響を与えるようになれば、より多くのステークホルダーと関わり始め、彼らの信頼を得ることができます。
**学びを続ける**
スクラム・アジャイルの導入を成功させるためには、多くのことが必要です。「成功させる」とはどういうことか、そのチーム、その組織によって大きく異なりますが、「組織の目標の達成、顧客、従業員などに貢献するような形で」という意味が含まれているはずです。スクラムマスターの人数や、デイリースクラムの頻度などの表面的なこととは何の関係もありません。
いずれにせよ、自分のチームや組織の成功の可能性を最大化するために、グロースマインドセットを持って、本や研修、ケーススタディ、信頼できる人々からできるだけ多くのことを学ぶことをお勧めします。特にこの記事が共感を呼ぶ皆さんや上記を深堀りしたい皆さんには以下のリソースをお勧めします。
- 本から学ぶタイプの方には、「スクラム実践者が知るべき97のこと」または「アジャイルリーダーシップ」（Zuzana Šochová）から始めることをお勧めできます。英語が読める方には「The Professional Agile Leader」 (Kurt Bittner, Laurens Bonnema, Ron Eringa)もお勧めします。
- 本よりも研修で学ぶことを好む方には、Professional Scrum Master 研修（日本語、英語）またはProfessional Agile Leadership Essentials 研修（今のところ英語のみ）をお勧めします。
- 人々との直接の交流から学ぶことを好む方には、実践者のコミュニティやカンファレンスに参加することをお勧めします。
Good luck!