この記事はハワイアンAdvent Calendar 2020 23日目の記事です。半端な気持ちでペヤングをやっていった時、最初は余裕じゃんという気持ちだったのが8割9割ぐらいで一気に苦しくなるという事がありますが、現在そんな気持ちです。ペヤングをやる時はメンタルも相当大事で、無心で食らいつく事が大事だと気づいてから、多少ペヤングもできるようにはなったのですが、それでも日頃からの胃袋の訓練ってやつがなければ入らないわけで、基礎は大事という事を気付かされます。

3rd partyのライブラリやツールの利用において、一定いい感じで簡単なものならサクッと(それを利用して)作れるんだけどあとちょっと足りないんだよなあとか、カジュアル向けかもしれないなとか、Feature Requestも(窓口がない|なかなか通らない)なあ、それでも現場はやっていかないといけないんだよな、いうような体験をしたことはまああると思います。その依存しているライブラリひいてはツールが巨大になればなるほど、その「あとちょっと」の痛手というのが大きく響いてきます。どれだけツールをこねくりまわしても解決できない問題が出てきてしまうという事です。「ラスト10%の罠」と呼ばれます。

Building Evolutionaly Architectureで挙がっている例は相当でかいツールの話なので問題は多岐に渡るだろうし時系列によるものもあるだろうし一概になんとも言えないところがありますが、もう少し小さく考えてみると「〇〇が満たされないとまずい」「今は大丈夫かもしれないが〇〇な為に将来起こりうるビジネス要求を満たせない、運用で詰む」「今は見えないが根本的な問題を探るために敢えてソフトウェア開発プラクティスを適用しないで観察する」というような「痛みをより早く認識する、認識した上でどこまで許容できるかという境界を導き出す、あるいは解消する」行為はソフトウェア開発をやっていってる方なら普段からよく着手している領域なのではないかなと思います。痛みにも色んな文脈があって、デプロイメントやマイグレーション、適応度関数(Fitness Function)の自動化という話であったり(進化的アーキテクチャでは主にこちらの話)、ソフトウェア設計上の痛みの話であったり(こちらはPain Driven Developmentな文脈でよく使われる)、様々です。何にせよ、痛みを伴うであろうものに素早く着手する事、痛みをいち早く認識する事というのはとても大事というのがよく分かります。盲目的に使っているライブラリやツールがあったら、痛みについて分析しておくと後々役立つかもしれません。