この記事はハワイアンAdvent Calendar 2020 24日目の記事です。寒い。

適応度関数についててっとり早く理解するにはFitness Function Driven Developmentを読むのが多分一番良いです。

実際のサービス開発の現場ではMonitoring、障害、FTS(Fail Teaches Success)から再発防止策として実践していくケースが多いのかなあと思います。ただ、実際に各次元で問題が起きる前に適応度関数を早く導き出す、という意味では自分もあまり実践できてない所があります。いわゆる基礎だったり原理原則だったりノウハウだったりプラクティスが世の中には溢れていますし、最終的に職人芸というやつでなんとかなってしまう所もありますし、企業体力だったり事業優先度としてそこに着手する優先度がなかなか上がらなかったりする面もあります。特定の次元のFitness Functionが用意されていても、他の次元を優先されて結果陳腐化してしまったり、Fitness Function自体の定期的な整理が行われずに形骸化してしまったり…。

しかしながら、サービス開発がデータ駆動や機械学習な方向に動いているのにソフトウェアエンジニアリングだけがいつまでも職人芸という状況はよくないというのはその通りで、どうやったらその状況を変えられるのかなあというのは直近一番時間をかけて考えているかもしれません。ソフトウェア開発は本当に楽しいんですけど、なんか考慮しなければならない事が技術の進化と共にどんどん増えて難しくなってしまったんですよね。「いやまあそれでも学ぶんだよ」で済むならこの記事は書いてないです。

そこに対して刺さりそうな手段というのが思いつかないので、(自分が職人かと言われれば奢りでもそんな事はいえないし一生ペーペーな気持ちですが)一旦自分が直近重要視してるプラクティスを手放す為にこのAdvent Calendarを書き始めたわけですけど、結果としてまあまだもやもやしている。複数の次元が別の次元に対して押し付けにならず、かつ効果的にソフトウェアの漸進的な成長に貢献できるFitness Functionとはなんなのか。「チームで合意がとれればよい、時と場合による」で終わらせてしまうとまた職人芸の世界になってしまう…。

まあただ今日までガーッとブログを書いて改めてThoughtworksのブログを読むと、なんかまだできる事があるかもしれないみたいな気持ちになってきました。あまり気持ちになると寝られなくなりそうなので終わりです。