[#TiDD #agile] アジャイルプラクティス導入の効果パターン

プロセス改善する際にアジャイル開発のプラクティスを導入する場合、組織の状態によって効果が変わります。個人的に感じている傾向がありましたが、コミュニティでのお話や最近増えてきたアジャイル開発の記事を読んでいると、いくつかのパターンがあるのではないかと思いましたので、イメージを図にまとめてみました。

２割８割

典型的なパターンと考えていたのは、パレートの法則として知られている２割８割の法則に従ったものです。組織の大きな問題を解決する２割のプラクティスによって、８割の改善効果が得られます。しかし、その後は導入コストがかかるものの徐々に改善の効果が少なくなってしまうパターンです。

このような曲線を描くのは、ビジネスと作る人との距離が近いなど、アジャイル開発の目指している方向に改善が進んでいる組織です。大きな問題が少なくなっているので、それを改善する事で大きな改善が得られるでしょう。

後半に効率が悪くなっているのは、スコープ変更の壁があると考えているからです。TOC/TOCfE関西分科会の感想 で書いた様に、CCPMでもアジャイル開発の目指す物の多くは実現できます。しかし、柴山さんのスライド「NTTデータはどうやってCCPMを導入したのか？」のマネジメントトライアングルに示される通り、アジャイル開発ではスコープを可変するという特徴があるからです。これは、契約とも関係しますので、組織的なコミットメントが必要になり、アジャイル開発の最後の壁になると思っています。

このほかにも、SEPG Japan 2014で乗松さんが「問題解決重視とモデル重視 ~組織に合ったプロセス改善モードを探す~」(PDF)で発表された様に、ほかの壁や罠があるかもしれません。

順調

特に大きな問題や壁がない場合、順調にプラクティスを導入できるかもしれません。UAS2の記事に書いた様に、タイムボックスを守ってスコープを変更することもプラクティスです。ユーザがリスクを取ってでも、より最適な開発するという意識があれば、この壁(グラフのへこみ)はなくなってより直線的なグラフになると思います。

もし、時間をかけて導入するなら、不足しているプラクティスに代替プラクティス代わるが代替プラクティスが用意されるかもしれません。そのような場合、代替プラクティスで最適化されて、全てのプラクティスを実践する前に最適なプロセスに至るかもしれません。

このように全てのプラクティスの導入が最適なプロセス出ない場合、一旦全てのプラクティスを導入した方が、効率的な場合もあるでしょう。全てのプラクティスを導入する事で、プレクティス間の関係の理解を深めることができるからです。

障壁

最近の記事で、アジャイル開発の導入によって期間短縮とコスト低減を実現したとの記事がありました。

アスクル、コールセンターをアジャイル型の手法で刷新--期間は3分の1、コストは5分の1に

この記事では、アジャイル開発によって早い時期から業務ユーザが参加する事ができた、とされています。しかし、このようなフロントローディングだけであれば、アジャイル開発でなくても実現できるでしょう。

この事から考えられるのは、より良い開発プロセスを実現できるような工夫、たとえばプロトタイピングや段階的なリリースなどが実施できない文化があったのかもしれません。アジャイル開発は工夫をしなくてもより良い開発を実現できるプロセスと言えるでしょう。

このように、障壁となる文化をなくして一気に改善する方法として、一気にアジャイル開発を導入することが考えられるでしょう。その際は、全てのプラクティスを導入しただけでは、文化までは変わっていない最適ではない状態である事を認識してください。

また、こんな記事もありました。

［覆面座談会］現場ではケンカが頻発　「アジャイル」成功・失敗の分岐点（１）　：日本経済新聞

ひどいお話です。この開発を主導した人はきちんと理解していたのでしょうか？具体的なイメージが抱けていたのでしょうか？アジャイル開発であれ、なんであれ、どのような仕組みでプロセスが構成されてメンバーがどのように行動するべきか、わかっていなければうまくいく事はないでしょう。

第１ステップとしてのチケット駆動開発

最初に示したグラフは、私のイメージした典型的なパターンです。変化のより激しい場合や、その時期が異なる場合、そして、組み合わせたパターンも存在します。

組み合わせのパターンで典型的な物は、チケット駆動開発からアジャイル開発に移行するパターンです。意図して 第１ステップとしたかどうかは別として、現状の問題解決の手段としてチケット駆動開発を導入する方法です。

アジャイル開発の効果を理解した上でチケット駆動開発を導入すると、アジャイル開発の特徴である見える化やリズムなど、理解しにくい知識を経験できます。そしてイメージできる様になってから、アジャイル開発に移行するパターンです。

このパターンを利用すると、上で引用した失敗パターンの危険性は低くなります。ただし、チケット駆動開発もイメージできないとうまく実施できませんので、まずは障害管理から始める事をお勧めします。

言葉の定義（まとめに代えて）

「アジャイル開発とは何か？」良く聞かれる質問です。私は「アジャイルソフトウェア開発宣言」にある、価値と原則を満たすプロセスだと考えています。少しでも満たさなければ、アジャイル開発を理想としていたとしても、それは「アジャイル開発をベースに最適化した開発」あるいは「アジャイル開発をめざしている開発」であり「アジャイル開発」とは言えないと思います。

また、アジャイル開発を参考にプラクティスを導入しても、タイムボックス管理に伴うスコープの変更を基本としない、それとは異なる最適化したものを理想とする場合もあるでしょう。これも「アジャイル開発」ではありません。

また、上に挙げたUAS2の記事の様に、アジャイル開発の基本であるタイムボックス管理に伴うスコープの変更は行うものの、アジャイル開発の価値と原則を全てを満たそうとしていないので「アジャイル開発」ではありません。これらをなんらかの言葉で表現する場合、定義して使う必要があります。

アジャイル開発は、より良い開発を実現できる工夫(プラクティス)があらかじめ組み込まれたプロセスです。プラクティスやその仕組みが広く知られ、「アジャイル開発とは何か？」を説明しなくても良くなった時、言葉の定義の問題は自然となくなると思います。そのような時を心待ちにしています。