あなたがソフトウェアエンジニアで、コードを読んで隅々までプロダクトを把握し、設計の良し悪しもわかっているのだとしたら、それはどんな洞察よりも細かくて正確なはず。
事業を作っていく中で、プロダクトのケイパビリティを増やそうとしたとき、綿密に市場をみて、スコープを決め、ユーザのペインを見て、それを回し続けているチームなら打率はあがっていく。プロダクトが立ち上がって2年ほどはいいが、肌感覚としてそれより長く立ったときにソフトウェアの問題が増えてくる。内部品質の悪化だ。2年もやっているともともと作ろうとしたものではない機能性を増やす場面を重ね、当初いくらきれいに設計したと思っても立ち行かない部分がでてくる。
内部で質の悪いところはソフトウェアエンジニアが一番知っている。書きづらいAPIがあったなら、隣接するインタフェース、あるいはデータへのアクセスが良くないなど、実際に何がどう悪いかというのを知っている。この肌感覚は組織にとってとても貴重だ。未然にこれらを潰すことはどんなときでも難しく、賢い人を集めた小さいチームでも起こりうる。しかしながらこれに気づいたとき、どの程度のリードタイムで違和感を解消するかによってプロダクトチームの加速度が変わる。すぐに直せるチームは2年の壁を超えて伸びていく。そうでないチームはプロダクトマネージャーあるいはソフトウェアエンジニア自身が実現したい機能がでてきても、機能をなかなかリリースできずに衰退していく。
年数を重ねれば重ねるほどこの壁は高くなる。2年で解消できればまだよく、これが5年ものになるともっと高い。複利で高くなる。壁を超えずに作った機能がさらに壁を高くする。さらに高くなった壁を超えるソフトウェアエンジニアを雇うのは、最初に事業を立ち上げるエンジニアを確保するよりも難しくなってしまう。やりがい、スキルセット、難易度など、採用要件を並べると壁を超えるというのは見劣りがちである。自分はこうした仕事を面白いと思うし、いわゆるソフトウェア考古学が好きな人間なのだが、案外こうした仕事は面白くなさそうに外からは見えがちである。コードが読めるソフトウェアエンジニアというのはこうした内部環境及び外部環境からみて、価値が高いと自分も考えている。
コードそれ自体から得られる洞察の重要性は、ソフトウェアエンジニアなら理解していると思う。しかし、案外それ自体がどれくらい個人にとって大事であるという感覚をもっているとしても（たとえばここを倒しておけば次のタスクがスムーズだ、等）、チームやプロダクトにとっても大事だという感覚は小さめであることが多い。自分ごとは問題のサイズがわかりやすいが、他の人のことは感覚が得られないためサイズを小さく見積もりがちである。
---
というような話を今日は配属されてきた新卒エンジニアにしたのでした。春だなあ。
