喋る機会があったのでアジャイルの本質を伝えたくて喋った。せっかくなのでブログにしておく。
お気持ち
アジャイル開発を実践するあたって、いきなりスクラムとかリーンとかについて学んだりしても効率が悪いと思っている。順番が逆で、それよりも前提として「アジャイル開発のアジャイルとはなにか？」を理解して腹落ちしてないと手法やフレームワークの掲げる正論に振り回されて、一向に改善のサイクルが回らない状態に陥ってしまうと感じている。
エンジニアリングの本質が「問題解決」であり「不確実性を削ること」と捉えられるかどうかで日々の思考や物事への向き合い方が変わると思っているので、この前提を飛ばしたくない。
チームは誰かひとりの所有物ではなくて、メンバーの一人ひとりで構成されたみんなの物だと思っている。誰かひとりがアジャイルマインドを持っていても一人でアジャイルを推進するのではすぐ限界がやってくる。みんなで日々の営みの捉え方を揃えてみんなで推進しなければ改善のサイクルは回らないし、うまくいかない可能性を減らせない（うまくいくかわからないという不確実性が削れない）。
ウォーターフォールとアジャイル
アジャイルよりウォーターフォールのほうが向いている開発となるケースもある。一概にアジャイルだけがいいというわけではない。以下のような場合はウォーターフォールのほうが向いている可能性がある。
- リソースが潤沢
- 人的リソース
- 金銭的リソース
- 情報的リソース
- 物質的リソース（工場のような生産ラインのリソース含む）
- 作るものが計画しやすくプロジェクトの開始時ガッチリ決められるもの
- 計画が外的要因による変更が起こりにくい場合
端的に言うと「不確実性と戦う必要がない場合」はアジャイルである必要がないので、対比するとウォーターフォールのほうが効率がよくスピードも早い場合がある。
例えばすでに開拓された市場へ新規参入するような場合で必要な機能や改善点が明確であり、サービスカット時に競合優位性を確実に付けることが必要な場合。
組み合わせる戦略
すでに開拓された市場へ新規参入するような場合で、必要な機能や改善点が明確であり、サービスカット時に競合優位性を確実に付けることが必要な場合。
「競合優位性を付ける」の部分が不確実性を持っている。本当に競合優位性を付けられるかわからない場合もある。こういう場合は、明確に計画できる部分の開発はウォーターフォール的にガッと進めて、不確実性のある部分の開発だけアジャイル開発をするのでもいいと個人的には思う。
アジャイル開発において、イテレーションの連続により不確実性が減っていく様子を小さな滝と捉える人も一部いてミクロな視点でみると確かにそうも見える（実際には軌道修正をするので小さな滝の連続ではないと個人的には思うが）。でもこういう捉え方のほうがイメージしやすい気持ちもわかるし、実際ケースバイケースでこういう捉え方で進めるほうが組織に合っていてプロジェクトが成功するのならそれでいいと思う。
計画の有無
アジャイル開発の誤情報のスライドページには書かなかったけど、「アジャイル開発は計画しない」という誤解を持っている人がたまにいる。そんなわけはなくてアジャイル開発でも計画性は必要。計画なしにどうやって「このイテレーションでなにを達成するのか」を決められようというのか。
アトラシアンのアジャイルのページにタスク粒度の話がある。
Initiative（テーマと呼ばれたりもする）という大きめの目標や達成すべき機能があって、それはどこからやってくるかというと、事業計画のロードマップからドリルダウンして作成される。
Roadmapを達成するために達成すべきInitiativeがあり、Initiativeを達成するために達成すべきEpicがあり、Epicを達成するために達成すべきTaskがある。だからイテレーションでなにをすべきかがわかるわけで、計画がなかったらスーパーマンが勘でやるべきこと決定することになる。
ちなみに計画の立て方や柔軟性や調整については、最近読んだ以下のブログがわかりやすかった。
CCPMの考え方はすごくいい。スコープに対してやることを調整する方向がアジャイル開発においてはよいと思う。
アジャイル開発でうまく行かないパターンとして、「スコープに対してやることを調整しない（デスマーチ化する）」か「やることを調整せずスコープを調整する（お尻を伸ばす）」がある。前者の場合は不確実性と向き合わず削りきれなかった事実とも向き合わない状態で、後者はタイムボックスを伸ばして不確実性を削りきれなかったことをなかったことにしようとしている。
クソ真面目すぎる内容で困るので、もっとふざけた記事を今年は書いていけるといいな。
