大規模アジャイルを乗りこなすために(イントロダクション)

2年近く前
斎藤 紀彦
アジャイルコーチ
斎藤 紀彦

はじめに

最近では、小さなプログラミングチームでアジャイルを実施することから、チームを拡張してアジャイルを実施するケースが増えてきました。

ここでいうチームの拡張とは、「チーム数が増加すること」という横方向への拡張と「UXデザイナーやQAエンジニアなどプログラマー以外の職種がチームへジョインすること」という縦方向への拡張の両方を指します(以後、このようにチームを拡張した組織体制でのアジャイルを「大規模アジャイル」と呼びます)。

実際、弊社の顧客のほぼ全ては、何らかの形での大規模アジャイルを実施しています。そこで、これから数回にかけて大規模アジャイル特有の課題について、有効だったアプローチを中心に解決の方向性を述べていきたいと思います。

people-305836_960_720.png

大規模アジャイルで浮かび上がる様々な課題

アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない(Robert C.Martin『Clean Agile 基本に立ち戻れ』(2020, KADOKAWA))

アジャイルをスケールする一番うまいやり方は、スケールしないこと(某アジャイルコーチ)

前述の通り、大規模アジャイルを実施する組織は増えています。

しかし、『Clean Agile 基本に立ち戻れ』にも触れられている通り、多くのアジャイルのプラクティスは小さなプログラミングチームに合わせて体系化されてきたという経緯もあり、そもそもアジャイルと大規模化との相性は決して良いとは言えません。

そのため、大規模アジャイルを実施する中で以下のような課題が噴出し、いつの間にかアジャイルが形骸化し、アジャイルを断念したり、もしくはアジャイルのメリットを十分に引き出せないまま実施しているケースは珍しくありません。

  • UI/UXデザイナーがどうチームに関われば良いか悩んでいる
  • 既存の品質管理部門との関わり方や、アジャイルに適した品質管理手法がわからない
  • 顧客や企画部門が積極的に協力してくれない
  • プロダクトのステークホルダーが多すぎて調整と意思決定に苦労している
  • 期間内に特定機能を出荷しろというプレッシャーが開発者にかかる
  • チームがサイロ化し、情報共有や協力がうまく機能していない
  • 段階的にアジャイルを拡張したいが、最初のチームの成果がなかなか出ない
  • スクラムチームの評価や報酬についてどうすべきかわからない
  • プロダクトではなく職務で組織が分けられている

もちろん、これらの課題は小さなチームでも起こりえますが、特に大規模アジャイルで顕在化しやすい課題だと言えます。

大規模アジャイルの課題を解決するための最大のポイント

さて、大規模アジャイルを実践する中で上記のような課題が噴出した組織は、「スクラムを教科書的に実施するのが目的ではない・スクラムイベントをすべて開催するのは現実的には難しい・組織に合わせてスクラムを最適化したい」と、アジャイルやスクラムをテーラリングする道を模索し始めます。

しかし、筆者の経験では早急なテーラリングはほとんどうまくいきません。

なぜならば、そのような組織はアジャイルやスクラムのマインドセットが身についていないので、たとえば、「期間内に特定機能を出荷しろというプレッシャーが掛かるのは仕方ないので、開発者を増員させる」「チームだけでは調整と意思決定が難しいので、プロジェクトマネージャーを配置する」のように、従来の価値観と判断基準でテーラリングするためです。現実解と言えば聞こえは良いですが、このような解決策は現場に混乱をもたらし、アジャイルのメリットを享受することをますます難しくします。

筆者が考える大規模アジャイルの課題を解決するための最大のポイントは、早々にテーラリングする方向とは逆の方向、すなわち、アジャイルやスクラムのマインドセットを解決の方向性として、一つ一つの課題に真摯に向き合うことです。そのためにも、一見遠回りに見えますが、組織にアジャイルやスクラムのマインドセットを浸透させることが重要になります。

そこで、連載の初回は「アジャイルやスクラムの理解が表層的だったり、人によってバラツキがある」という課題を取り上げます。
次回は、組織にアジャイルやスクラムのマインドセットを浸透させる方法を、できる限り具体的な方法論として提示したいと思います。
最後までお読みいただき、ありがとうございました。
次回もどうぞお楽しみに!!

組織にスクラムを浸透させるための冴えたやりかた(スクラムガイド読み合わせのススメ)リレーブログ#13 自律的なチームを作る情報設計(3)
SHARE