企業がアジャイルを導入して、自己組織的なチームが生まれ始めると、マネジメントは制御を失ったと感じる可能性がある。アジャイルに移行すると、手続きやレビュー委員会、コンサルテーション委員会などが無駄になってしまう可能性がある。しかし、そのような立場になる人は無駄になってしまうことに気づかない、とMarcel Heijmans氏は言う。再び、制御を取り戻そうとすると、問題はもっと厄介になり、"プランニングの死"へと到る。
Marcel Heijmans氏は、Mnemonicsという名前で活動しているフリーのソフトウエアエンジニアだ。氏は、Agile and Software Architecture Symposium 2014でdeath by planningというタイトルで発表をする予定だ。このイベントはオランダで開催される1日のカンファレンスで、ソフトウエアアーキテクト、開発者、情報アナリストがソフトウエア設計の知識を共有する。
InfoQは氏にインタビューを実施し、アジャイルプロジェクトの計画作りや、アジャイルのスケーリング、アジャイル適用におけるアーキテクチャ、小さなデリバリを頻繁に実施するための実践方法について話を聞いた。
InfoQ:あなたのプレゼンは"death by planning"というタイトルですね。意味を詳しく教えてください。
Marcel: "Death by Planning"はプロジェクトマネジメントのアンチパターンです。ソフトウエアプロジェクトに対する過剰な計画によって引き起こされる問題を指し示しています。詳細な計画作りは線形に拡大する、あらかじめ決定されているプロセスにとっては適切なやり方です。しかし、プロセスがより、推測が必要な振る舞いだった場合、詳細に計画してしまうことから生ずる複雑さは急速に向上します。多くのソフトウエア開発プロジェクトはその特性上、不確実で複雑な活動を含んでいます。
InfoQ: ウォーターフォールのプロジェクトとアジャイルのプロジェクトでは、計画作りはどのように違うのでしょうか。
Marcel: "プロジェクト"は一定のピリオドと一定のコスト、かつ/または、一定のスコープで形成されます。ウォーターフォールでは計画作りのための構造を与えて、これらのパラメータを制御します。私は"アジャイルプロジェクト"はこの反対だと思っています。"計画作り"の定義を緩やかにする場合、プロダクトバックログの優先順位付けを計画作りと定義できるかもしれません。もちろん、スプリント(スクラムの)は従来の計画作りです。というのは、スプリントは時間とスコープで形成されるからです。しかし、スプリントの期間は詳細な計画作りが活用できるほどに小さいという、解釈が成り立ちます。
InfoQ: あなたはソフトウエア開発をエンジニアリングと考えています。これは、どのような意味でしょうか。
Marcel: エンジニアリングは製造に先立つ問題解決であり、計画するのは難しいのです。幸運にも、多くの領域で、エンジニアリングは全体の作業の中の小さな部分を占めているだけで、その部分は一度だけ、最大限の正確さを持って実施すればいいのです。ソフトウエア開発プロセス全体がエンジニアリングであるなら、ソフトウエア開発に詳細な計画作りを活用するのは、あまりそぐいません。
InfoQ: 企業でのアジャイルの導入についてはどのように考えていますか。アジャイルはスケールできるでしょうか。どのようにスケールすればいいでしょうか。
Marcel: アジャイルは成功しているので、企業はアジャイルを受け入れています。アジャイル(スクラム)の多くの側面は簡単に企業になじみます。しかし、アジャイルの中核は、そうではありません。簡単に見逃されます。"ユーザフィードバック"の部分(とそれに対応するプロダクトオーナの役割)は大きな組織にとっては難しいです。皮肉にも、この部分は成功に対して大きく貢献します。アジャイルの簡単に企業になじむ部分、例えば、チーム作り、イテレーションの実行、デイリースタンドアップ、スプリントレビューをスケールするのは、可能であり、多くのフレームワークが存在します。しかし、製品の素早さを決定する"ユーザフィードバック"のループをスケールするのは、組織の文化に依存します。
InfoQ: 企業がアジャイルを導入したときに、計画作りに関連するアーキテクチャの役割はどうなるでしょうか。
Marcel: ソフトウエア開発のエンジニアリングの性質は、大企業の複雑さと企業が一貫した方法で一貫した方式でアジャイルを実行できないことが合わさっており、予測不可能性を引き起こします。マネジメントが制御できていないと感じると、アジャイルは、瀬領を取り戻すための"標準的"なマネジメントツールになります。しかし、詳細な計画作りはエンジニアリングの活動には不便です。それゆえ、アーキテクトの役割は問題に対して技術的な解決策を提供することになります。そうは言っても、すべての問題が設計上の問題として解決するのが最適なのではありません。
InfoQ: 小さなデリバリを頻繁に実施したい企業へ、経験に基づいたアドバイスをしたいただけますか。
Marcel: 多くの企業は、アジャイルを導入した後、リリース頻度を低くして、リリースカレンダーを遵守します。この方法は、マネジメントによる過剰な計画作りを生み出す下地になります。システムの複雑さとシステム間の依存関係がリリースで発生する問題の主要な理由です。"計画作り"によって、多くのリリースカレンダーを同期するのは無駄です。
Fowlerの言う"Feature Toggle"と似た仕組みを導入し、提供側と利用側の間にあるリリースの依存を解消するのがいいのでしょう。そうすれば、少しの努力を追加するだけで、リリースの複雑さを低減できます("Feature Toggle"を構築するということです)。
また、自動デプロイを実施するのもいいでしょう。リリースを自動化し、より信頼できるものにするためのツールを提供することで、リリースの頻度を向上できます。システム間の依存関係は残りますが、リリース頻度を増やすことで、リリースカレンダー同期の圧力を低くすることはできます。