最近自分のやっていることはなんなのだろうか？と思い返す機会が増えた。次のことをやっている。
* 広告に関連するWeb周辺技術の動向やらリサーチをしつつ
* アプリケーションが長期に渡って安定し拡張可能になるように設計するのを手伝いつつ
* サブシステムの分割がいい感じになるように相談にのりつつ
* 事業で中長期に渡って伸ばしたい領域を決めて技術的観点からコミットする
基本的には事業がうまくいけばよく、そのために採用やら面談やらチームづくりやらツール選定やらが紐付いてくる。働き始めて3,4年ごろはもうちょっと自分の市場価値を強く意識していて、あまり自分の価値を伸ばさなさそうな仕事には手を出すのをためらうふしがあった。今はそれよりも必要なことを必要な仕事としてやる、というスタンスになっている。
特定技術領域には当然弱くなっていくし、どれも深く入り込んでいくよりは他の代替手段を効果的に使っていくほうがレバレッジが効くことも増えた。中にはどうしても性能要件を超えるために細かなチューニングが必要になる場面も発生するが、案外単体のソフトウェア性能だけではなくて事業上の制約を変えることでこれを解決することもある。単体のソフトウェアで解決すべき課題はスコープを絞り、難易度をなるべく下げて解決可能な課題に落とし込む。そういった工夫のほうがうまく事業を回すためには効果的なことが多い。
ソフトウェア単体を堅牢に書く技術は年々ついてきた。これは単体テストを書こうとか、Observabilityを高めて複雑なシステムの故障に早く気付けるようにしようとか、技術的なアプローチに習熟している面もある。ソフトウェアにおける堅牢さとは読みやすさであると思う。読みやすさはTestabilityに繋がり、何が起こっているかをチームに理解させる力になる。読みやすいコードは自明であり、そのソフトウェアが何をすべきかをわかっていないと生まれない。リファクタリングが別の工程になるとうまく行かないのは 感覚的にも正しく、思考のループの中で洗練されたコードになる。これがチームで生み出せるとどんどんよい方向にソフトウェアが改善されていく。
事業におけるソフトウェアエンジニアリングとは細部でみれば上記のような観点があり、これらはすべてリスクコントロール手段である。良いソフトウェアがかけるならばトライが増やせる。トライをする意思決定がしやすくなる。ソフトウェア、あるいはWebサービスが長期に渡って動くために、CI/CD・Testability・Observabilityへの投資は常に効果的で、高速に変更を重ねる文化はすでにできている。チームのScaleを確保するのはいつでも難しいが、同じ人数でもスループットが増えていくのは自分たちもまたソフトウェアの力によって加速が可能な構成になっているからである。
日々の仕事がリスクコントロールであることは、ソフトウェアに限らない。すべての仕事は決めることを決めることだ。それが当たり前になってしまっていて、なかなか言葉にするのは難しい。