小幡 知弘 
みなさんこんにちは、小幡です。
本日は『Clean Agile 基本に立ち戻れ』を読んだ感想です。
私は全体的に肯定的です。
アジャイルとは何か？
この本では、プログラマーの歴史的ななことが注意深く記載されている印象です。
アジャイルマニフェストが誕生したストーリーは、とてもわくわくしました。
プレ・アジャイルと呼ばれる、アジャイルが誕生する以前から、何かを成功させるための手段として、本書でなんども語られている思想が登場します。
小さなことをする小さなチームの運営については、私も賛成です。
大きいことを大きなチームで達成しようとすると、あらゆる事が複雑になっていしまう印象があるからです。
これまで長い間、どんな風にプロジェクトを成功させるかを考えてきた歴史があるなかで、たまたま最近になってアジャイルという名前が付けられただけで、ずっと考えられてきたものだということです。
基本に立ち戻り、よりシンプルに考えていくと、より小さく進めて行くことが重要だと考えています。
納期は変わらない
本書の中ではウォーターフォールとの比較が出てきます。
その中で一番驚いたのは、アジャイルを導入しても基本的には納期が早まることは無いということです。
それはアジャイルが魔法の道具のように、納期が短縮できるなどという間違った印象を打ち消すために記載されたかのような印象で、筆者はアジャイルという言葉が生まれてから、これまでの流れにあまり良い印象ないように感じました。
最も重要なことは、納期は変わりませんが、遅延が発生する可能性を早く知ることができることです。
すごく乱暴な表現ですが、リリースサイクルが早まると次のリリースの見込みがわかります。
ウォーターフォールの場合、１つずつのフェーズが1回しかないので、PDCAが回せません。すると、最後の段階になってやっと納期が遅れることがわかるのです。
しかし、遅延が発生する可能性が早くに知ることができれば、あるいは納期どうりに終わることがわかれば、ステークホルダーへの報告も傾向と対策をしっかり踏まえることができるようになります。
ウォーターフォールという、わら人形
本書を読んで驚いたことの１つに、ウォーターフォールは、後で論破される悪い例（わら人形）として提示された図から誕生したものだったということです。
悪い例として挙げられた図が、論文の序盤に提示されたことにより、その論破する文章よりも悪い例が世界中に認知されてしまったことは、とても不幸なことだと思います。
筆者も述べていますが、ウォーターフォールは希望だったという感覚が私には理解できませんが、今以上にプログラミングの現場は開発手法に乏しく、激務であり、何かに助けを求めたい状態だったのかもしれませんし、この新しい開発手法でうまく行けばみんながハッピーになれそうだという感覚があったのだと考えています。
残念ながら私もウォーターフォール開発でうまく行っているところを見たことがないので、感覚的にはわら人形だったんだろうなと考えています。
継続的な改善
ソフトウェアの開発現場では、想定していたよりもプロジェクトが長く続き、後のことを考えずに進めてしまった負債が溜まっていることが多いです。
その原因の１つには、今開発しているチームが次回の開発に携わっていない可能性があるなど、開発現場のシステム的な問題もありますが、それよりも全体的な技術力に問題があることにも気づかされました。
本書では絶えずソフトウェアを改善していく手法についても丁寧に書かれていますが、それは同時にソフトウェア開発に関係するすべての人に、新しい継続的な改善方法の学習も促しているのです。
仮に現場の人全員が素晴らしい継続的な改善手法をマスターしており、明らかに導入した方が良いとわかっているのであれば、納期が厳しい場合でもステークホルダーも納得し、よりよい改善活動と品質の高いソフトウェア開発が行われているはずです。
継続的な改善は大きな視点から捉えなおし、少しずつ人と人のコミュニケーションによって技術力の底上げが必要だと感じました。
まとめ
今回は『Clean Agile 基本に立ち戻れ』を読んだ感想を書きました。
『エクストリームプログラミング』を読んだ時も同じ印象を受けましたが、何十年も前の開発手法や良いと言われてきたことが、どうして導入されていかないのかについても、深く考えることができたと感じています。
目先の自分の仕事に集中するだけでなく、そこに至るまでの様々なコミュニケーションにも目を向けて、小さく進めることを実現できるように、努めていきたいと考えています。
何事も基本が肝心、そんなことを強く感じました。
以上です。