長くサービス開発をしていると、機能領域ごとに開発する内容に特色が見えてくる。ある領域は深く難しい開発が求められ、ある領域は簡単な変更を大量にやる開発が求められる。
前者の方が分かりやすく難しいので注目を集めやすいが、実は後者の方が本当は難しいのではないかと思うようになった。
深く難しいところは、たしかに難しいのだが、結局のところ1人でその時ベストな設計をすればよい。規模にやるが、そういうのはできるエンジニアが1人でえいっとやってしまって終われることも多い。1人で作ればいいのであれば、設計的な難易度はかなり下がると思う。
一方、軽微な修正・仕様変更が連打されるものは、時間軸的に長期化することも多く、そうなると関わる開発者が1人では収まらなくなる。時間が長く、関係者が多くなると、設計意図は簡単に失われる。設計意図が失われると、アドホックな変更を積み重ねてしまい、俯瞰して見た時に何が何だかわからない魔境が簡単に出来上がってしまう。
これのタチが悪いところは、実際それである程度問題が解決してしまうところだ。ここにif文を入れる、このときはこの変数に本来の設計意図とちょっと違う意味の値を入れる、このときはあっちでこう計算しているのでこっちで帳尻合わせをする。それでその場の問題は解決してしまうが、先に述べたような修正方法は明らかに全体設計が破綻していくシグナルだ。質とスピードそのものという感じの話だが、あっという間に損益分岐点を超えてしまう。
解決方法としては、そういう場所にこそ全体設計を俯瞰できるハイスキルで背景をよく知っているエンジニアをアサインするとか、設計意図が失われないように強い輝きや制約を持つ良いカードを書くとかだろうか。特に前者は真逆のことをやってしまいがちなので、注意したい。一見簡単そうで、Good first issueに見えてしまうが、歴史的経緯などを踏まえた割と高度な判断が求められるので、新メンバーに任せっきりにするのは酷で、手厚くフォローするようにしたい。
