ベストなセカンドベスト

次善の策というとうまくいかなくて代替案を提示しているように聞こえますが、最善にこだわりすぎる方がうまくいきません。

以前、「向上しようと思ったら、愚かな自分を受け入れろ #dvsumi」に書いたように、人工知能やそれから派生したゲームは最適解を得る事が難しい問題の存在が明らかになる事で発展しました。

計算機が速くなっても、ボードゲームの次の一手を見つける際に全ての組合せを短時間で求める事はできません。ある程度の先読みと何らかの戦略によって次の一手を決めざるを得ません。最適でないからこそ、工夫が生まれます。

ソフトウェア開発も同じです。ガチガチのウォーターフォール開発で、全ての可能性をあらかじめ検討し、段階的に詳細化することは非常に困難です。

ゲームなどの場合にはグリーディアルゴリズム（欲張り法：Algorithms with Python）があり、身近なところで良さそうな決定をします。ナップザックに大きなものから詰めるとそれなりにうまく詰める事ができるイメージ（[#agileto2012] 『チェンジ！』の考え方 ～マネしやんと！～）です。

アジャイル開発は、セカンドベストだと思います。何かをあきらめているからこそ、それなりにうまくいく方法です。過大な理想を追い求めないからこそ成功する方法だと思います。

その過大な理想は達成が難しいもので、単純な設計法でバベルの塔を目指すような理想の実現には非人間的な苦痛が求められました。そこで出てきたセカンドベストがアジャイル開発でした。

しかし、いざアジャイル開発を導入しようとすると、個々のプラクティスの導入はうまくいくものの、開発そのものをアジャイル開発に移行するには様々な制約が邪魔をします。

つまり、ベストなセカンドベストと思えたアジャイル開発も、理想であって現実には難しい問題が存在します。

ここで、ある事に気付きました。人工知能が理想は難しいことを明確にして、セカンドベストを求める事でブレークスルーができたように、アジャイル開発も難しい現実を明らかにして、セカンドベストを求めれば良いのではないか、という事です。

新しいヒントを得たように思いました。