最近少しずつアジャイル開発の解像度を上げようとしていて、それが少し整理されてきたのでざっくり考えていることをまとめてみようと思います。
アジャイル開発をやりたいと言った時、取り組むべき領域は大きく2つに分けられると思います。それはデリバリーの仕組みとチームの2つです。そしてそれぞれに段階や考えるべきことがあると思います。
アジャイルなデリバリーの仕組み
アジャイル開発の大筋は、作ったものに対していち早くフィードバックを集め学習しプロダクトに反映することです。そのために、スクラムをはじめとしたイテレーティブな開発プロセスによって軌道修正の機会を増やしたり、CI/CDの整備のようなエクストリームプログラミングのプラクティスによってイテレーティブな開発にかかるコストを小さくしたりといった、仕組みの整備が広く語られています。アジャイル開発というとまずこういった話題を思い浮かべる人が多いでしょうし、実際に型から入るというのは現実的なやり方だと思います。
この仕組みのスコープをさらに2段階に分解できます。ひとつは、ユーザーへのリリースはビッグバンだが、ステークホルダの間でのみ内々にフィードバックループを回してイテレーティブに開発を進めている段階です。これは開発環境へのデリバリーという意味ではアジャイルなデリバリーができていますが、ユーザーのフィードバックの反映という意味ではアジリティを獲得できていません。これまではこの段階を乗り越える方法論が不足しており、多くのアジャイルチームが伸び悩んだのではないかと感じています。
しかし最近、データ駆動戦略のような方法論の台頭によって、その壁を乗り越え、ユーザーへのデリバリーも含めた全ての開発プロセスをアジャイルにする方法論が広く示されたように思います。それこそがアジャイルなデリバリーの仕組みにおける2段階目で、本番へのリリースを繰り返して、ユーザーの行動データを元に仮説検証を繰り返し目的不確実性に対処していくやり方です。このあたりは『DMM.comを支えるデータ駆動戦略』を読んだ - yigarashiのスクラム開発ブログでも少し書きました。
アジャイルなチーム
デリバリーの仕組みにおける段階を進めるのと半ば独立に、チームのアジリティという軸があるように思います。つまり、チーム自身がどれくらい素早く変化に適応し成長できるかの度合いです。自己組織化と言い換えてもよいでしょう。これは見逃されがちですがアジャイル開発における非常に重要な要素だと思います。
仮にアジャイルにデリバリーするための枠組みが整ったとしても、チームがアジャイルでなかったとしたらどうでしょう。たとえば、最初に腕力のある人が開発プロセスやテンプレートを整備しまくって、それをただ使っているという状態です。それではより大きな変化が訪れた時に対処できず、徐々に衰退していきます。変化とは、ライブラリが更新されたり、新しいツールの導入を迫られたり、新サービスが台頭したり、技術革新が起こったりといった、サービス開発に訪れるあらゆる変化のことです。我々は、仕組みを育てるのと同時に、こうした変化にアジャイルに対処するマインドを育てなければいけません。そのために、ふりかえりやスクラムマスターによるティーチング・コーチングといった支援が重要になるでしょう。
また、アジャイルなチームを育てる上で、組織構造の問題が如実に現れるのではないかと考えています。というのも、チームのアジリティは、デリバリーの仕組みに比べてスケールしづらいように感じるからです。ある程度の人数でもアジャイルなデリバリーの仕組みを運用することは現実的で、バックログの流量が増えさえすればある程度スケールします。しかし文化を育てるという活動をスケールさせるのは難しく感じます。最終的には、チームが関わるプロセスをアジャイルにカイゼンできるようになりたいわけですが、そのプロセスに関わる人が多く多様であるほど難易度が上がります。例えば、ふりかえりの参加者が15人にもなると、ふりかえりの手法を毎回変えて試すといった大胆なファシリテーションは望めません。この点から、アジャイルなデリバリーの仕組みは運用できているが、長期的に見るとアジャイルなチーム作りに支障があるので、チームや会議体を再編しましょうといった議論が可能になるかもしれません。
まとめ
アジャイル開発を大きく2つの領域に分けてそれぞれ解像度を上げて深めてみました。これらは完全に独立というわけではなく、どちらかというと豊かな相互作用を起こす関係にあると思います。仕組みによって考え方が変わったり、アジャイルなマインドが育つことによって仕組みの整備が進むといったようにです。今回の議論をもとに、ひとつひとつのカイゼンアクションを尖らせつつ、アジャイル開発を根気強く育てていきたいものです。
