前回は、アジャイル開発を成功させるためには、開発手法についての正しい理解が欠かせないことを述べた。具体的にはアジャイル開発の目的を把握した上で、それを支える重要な概念である「自己組織化」「タイムボックス」「要件定義の扱い」「振返り（レトロスペクション）」を学ぶ必要がある。今回は「自己組織化」について説明しよう。
アジャイル開発の本質が「超短期リリース」を繰り返すことはすでに述べた。超短期リリースとは文字通り、数週間程度で動作するソフトウェアをリリースすることを指す。
アジャイルの超短期リリースを実現するために欠かせないのが「自己組織化」である。自己組織化とは開発チームにマネージャーを置かずに、チームメンバーが自律的にプロジェクトを運営することである。チームメンバーが自ら計画を立て、日々の進捗を共有し、課題を解決する。顧客とのリレーションを維持し、プロジェクトを振り返って改善につなげる。
多少の言葉の違いはあるものの、どのアジャイル手法も自己組織化を重視している。開発効率を高めるためだ。例えば、何らかの問題が起きた時、マネージャーが報告を受け、関係者を集めてミーティングし、対策を誰かに指示するというのでは時間が掛かる。開発スピードを追及すれば、チームメンバーが自分の頭で考え、行動することが不可欠なのである。
この「自己組織化」こそが、アジャイル開発が失敗する原因の最たるものだ。基本的にアジャイル開発ではマネージャーを置かない。プラクティスによってはコーチと呼ぶ存在を置くこともあるが、これはあくまでチームメンバーの相談役であって司令塔ではない。チームメンバーは自ら目的を立てて、自律的に進捗を管理することを求めている。
しかし、言うは易く行うは難し。実際にやってみると、上手く回らないものだ。
というのも、チームが自律的に振る舞うためには慣れが必要だからだ。多くの開発者はマネージャーの統制の下で規律に従って働くことに慣れている。急に「自律的に振る舞え」と言われても難しいのだ。マネージャーがいなければ、実行可能な計画を作ることもできない。何か課題があっても解決されないまま放置される。非常に効率の悪い進め方が行われることになる。
こうした状況は、開発チームが成熟するまでは続く。頻繁に問題が発生すると開発チームのモチベーションは下がり、自己組織化からは遠ざかる。悪循環である。これが多くのアジャイル開発プロジェクトが陥る失敗のパターンである。
では、どうすればよいか。対策は2つある。
まず、自己組織化されるまでは開発チームにマネージャーを置くこと。マネージャーは開発チームの自己組織化を促進するように運営する。開発チームが成熟して自己組織化されてきたら、役割をマネージャーからコーチに少しずつシフトさせていく。つまり、具体的な指示を出す代わりに助言を与えるのだ。
場合によっては、アーキテクトもおくべきだろう。有名なアジャイルプラクティスに「YAGNI（You Ain't Gonna Need It）」というものがある。
YAGNIとは実際に必要になるまで機能を追加しないことを推奨するアジャイルプラクティスである。解釈によってはアーキテクチャ設計のような先行設計は不要であることを意味する。しかし、余程成熟した開発チームでない限りはアーキテクチャ設計があった方がチームメンバーは迷わず開発できるだろう。
もう1つの対策は、自己組織化するまではリリース期間を長めに取ることだ。具体的には、最初のリリース期間を数カ月程度に設定し、開発チームが成熟してきたところで数週間に縮めるのが良いだろう。自己組織化されていないチームは開発や問題解決の効率が悪い。そうした状態で、数週間のリリースをこなすのは現実的ではない。
アジャイル開発はハイレベルな技術者でないと実践できないか？
ところで、アジャイル開発はスキルの高いメンバーを揃えないと難しいという指摘がある。これはアジャイル開発が“多能工”を求めるためだろう。
多能工とは、1人で多くの役割を担う技術者のことだ。仕様の決定から設計、実装、テストまで手掛ける。チームメンバー全員がどんな作業でもこなすことができれば、チームの問題を人任せにすることなく全員で解決しようとする。開発チームを一致団結させて、自己組織化を促すプラクティスである。
確かに多能工だけで自己組織化された開発チームが編成できれば強力なことには違いない。ただし、現実的にそうしたチームを揃えることは難しいだろう。多能工とは、高いスキルを持ったエース級の技術者にほかならない。
そうした人材ばかりで10人のチームを組むことができるケースは稀だろう。アジャイル開発を実践する過程で徐々に多能工になっていくというのが現実的。当初から多能工だけで開発チームを編成することにこだわる必要はない。
なお、技術力と自己組織化は異なる能力であることも強調したい。仮に高いスキルの人員を集めたとしてもチームとして連携するためには成熟が必要である。
例えば、サッカー日本代表は国内外のエース選手によって構成されているが、それぞれの実力をいかんなく発揮するまでには一定の時間がかかる。チームとしての経験を積んでこそ実力が発揮できる。アジャイル開発におけるチームについても全く同じことが言える。
アジャイル開発とは知識ではなく、チームの成長である。「Don't just do agile. Be agile.」という言葉がある。アジャイルを行うのではなく、アジャイルになるのである。
本を読んだからといって明日からアジャイル開発を実践できるわけではない。本に書かれていることを実践するだけでは成功しない。チームを成長させながら「Be agile」に日々近づくのである。成長の過程にあわせて適用するアジャイルプラクティスも選択していかなければならない。
- 吉原庄三郎（よしはら・しょうざぶろう）
- ウルシステムズ 主席コンサルタント、アジャイル推進室
- ウルシステムズでITグランドデザイン、プログラムマネジメント、開発運用プロセスデザイン、上流工程のコンサルティングを提供している。
- 著書に「はじめての設計をやり抜くための本」（翔泳社）がある。
