Clean Agile 基本に立ち戻れ (アスキードワンゴ)
- 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,角谷 信太郎
- 発売日: 2020/10/16
- メディア: Kindle版
原著は2019年に出版されていて、日本でも2020年に翻訳されている。
「アジャイルソフトウェア開発宣言」が2001年に発表されて、約20年。アジャイル開発の歴史や、考え方、プラクティスなどがコンパクトにまとめられている良書。
ちょうど、そろそろもう一回アジャイルについて、自分の中の考え方を整理してみたいと思っていたところだったので、ちょうど良いタイミング、内容だった。
ただちょっと気になったのは、全体としてウォータフォールとの対立軸をものすごく強調しているところ。
『Clean Agile』を読んでいるんだけど、「みんな頑張ってやってたんやで、そんな悪う言わんでも……」みたいな気持ち
— magnoliak🍧 (@magnolia_k_) 2021年2月5日
ウォーターフォールでも上手くいくためにいろんな工夫がされたけど、そこに名前がつかなかっただけじゃないかなーって
対立軸を煽るのは良くないし、そこじゃない感がある
冒頭はひたすらウォータフォールではプロジェクトが上手くいかず、アジャイルにより上手くいくようになった、みたいなことが書かれているが、本当にそうなのだろうか？
そもそも「正しいウォーターフォール」などというものがどこかに定義されているのだろうか？工程を区切り、順番に進めていき、最後にリリースする…本書ではウォータフォールについてはそれ以上のことは何も言っていない。ただ上手くいかない方法だと書かれている。
進捗について書かれているところも、ウォータフォールでは上手くいかない例ではなく、「進捗で嘘をつくと上手くいかない例」に過ぎない。そりゃそうだ。
中間管理職の価値観の話も、開発方法論となんら関係ない。ウォータフォールだったら、中間管理職はこんな振る舞いをしなさい、なんてどこにも規定されていない。
一方でアジャイルについては、その考え方、プラクティスなど、さまざまな角度からいかに有効であるか論じられている（当たり前だけど）。
因果が逆で、ウォーターフォールだったから上手くいかなかったんじゃなくて、上手くいかなかったことにウォーターフォールだったから、というラベルを付けてないですか？って
— magnoliak🍧 (@magnolia_k_) 2021年2月5日
ちゃんとしたウォーターフォールの入門書って無いんですか
— magnoliak🍧 (@magnolia_k_) 2021年2月5日
いつも対立軸の中でしか語られない、架空の手法だったりしませんか
いろいろな方法論を作り出す人たち、おそらく過去にただ一人たりとも、”プロジェクトが上手くいかないことを願って”作業をした人はいないのでは？（ステークホルダーへの説明責任を過剰に意識し過ぎ、そもそもの成果をおろそかにした方法論はひょっとしたら有ったかもしれない）また、アジャイルを採用していないソフトウェアプロジェクトが全部失敗に終わったわけでもない。色々な創意工夫の上に成り立っている。
なので、その辺りは割り引いて読んでいった方が良いのかも。現実の問題に合わせた対応をしないと、結局ソフトウェアは完成しないのだから。
- プロセスやツールよりも個人との対話を
- 包括的なドキュメントより動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
「アジャイルソフトウェア開発宣言」で語られる4つの宣言…”包括的なドキュメントより動くソフトウェアを”を除くと、アジャイルではないプロセスを採用したプロジェクトでも上手く行っているプロジェクトでは当たり前にやってませんか？個人や顧客を無視したプロジェクトはどんな手法を使っても失敗するし、上手く行っているプロジェクトは現実の変化に対応しているのでは？
ただ、経営層や顧客など、取り巻くステークホルダーの価値観や、視点を変えるために、あえて強く主張するのは、きっと有効。ほんとうにこの本を読むべきなのはアジャイルで開発を行うチームの外にいる人たちではないか、とも言える。成果物をすべて最初にコミットする方法ではなく、ある範囲において柔軟に対応することが求められる価値観を浸透させるための、キーワードとしての、「アジャイル」。
ただ、一方でシステムを要求する側は、大抵は、必要にして最小限と思っている機能を要求している。無駄と思って要求する人はいない、要求した以上はどれも必要な要素だ。
既存のシステムの更改など、最初から既に要求仕様が決まっている、一定以上の規模のソフトウェアを作らなければいけないシチュエーションも存在する。
このギャップをどう埋めるかは、この本には書かれていない。本書は2021年現在でも読む価値は十分にある本だけど、実はもっとも大事なのはここに書かれていないことなのかもしれない。
どうすれば、ここに書かれている方法論が機能する環境を作り出すか？それが実はアジャイルを導入する上で一番大事なポイントなのではないか。
本書を読んでアジャイルのすべてが分かるわけではないし、結局何度も実践していく中で自分たちのやり方を見つけていくしかない。プラクティスは揃っているが、それはあくまでプラクティスであり、自分たちの代わりに何かを生み出してくれるわけでもない。
冒頭でアジャイルは軽量なプロセスと書かれている。でも、それはソフトウェア開発に関わる人たちが実際にやることが少ないことを示しているわけでない。
やることはたくさんある。それをいちいち規定しないと言っているに過ぎない。
結局は自分たちが置かれている環境、課題と真摯に向き合い、柔軟にやり方を変え、最終的なゴールに向けてソフトウェアの点から価値を提供できるか？を実行し続けるしかない。それは逆に言えば、アジャイル以外の方法論でも何も変わらないのだけど、ソフトウェア開発プロセスや、ツールチェーン、クラウドの普及・進化などがアジャイルという方法論の効果をより増大させているのは間違いないので、この流れに乗るのが一つの生存戦略だよね、と言われればそれはそう。
「正しいウォータフォール」「きちんと機能するアジャイル以外の方法論」については、この本を読んでもわからないのだけど、この本に書かれていることを誤った方に読み込んで、”目の前の上手くいかない状況はアジャイルじゃないからだ”というラベリングするのだけはよくないなーと思った次第です。
あと、組織をスケールさせる方法はついに分からなかった……。
だれか教えてください
