リファクタリングをしたいエンジニア

これは30日チャレンジの16日目（2019/09/24）に書かれた文章です

新規事業においては、プロダクトの方向性が変わったり、当初は想定していなかった機能が増えたり、What―何を創るのかという点の不確実性が大きい。 結果として、コンポーネントの責務範囲が曖昧になることでコード全体の品質が低下する。 類似のコードがそこかしこに偏在に、保守性が低く、バグの温床になりやすい。

経験や知識に裏打ちされた洞察でWhatの部分想像したり、適切なデザインパターンを採用することで、不確実性に起因するコード品質の低下を防ぐ努力はできる。 しかしながら、どれほど優れたエンジニアであってに、本質的に新規事業の未来を予見することは不可能だ。 むしろ刻々と変化するビジネスに追従・先回りできるだけの柔軟性と機敏性を保つことに心血を注ぐべきだろう。

一方で、「防げる」種類の問題も存在する。それはかの有名な名言「早すぎる最適化」である。 これはHow―どうやって創るのかに関する不確実性と関係している。 Howは定義からしてWhatに準じる概念であり、Whatが定まらない限りはHowの不確実性も収束しない。 しかし残念ながら、我々エンジニアという生き物はHowの不確実性を正しく認識できないらしい。

さまざまな理由が考えられるだろう。新しいデザインパターンを試してみたい、慣習に従うと数値型よりも文字列型のほうが便利だ、現状のままでも問題はないが煩雑としたコードベースを許せないなど、可能性はいくらでもある。 筆者が一番気に入っている比喩は手術好きの医者の例である。じつは一部の医者は「手術をしたい」と考えているのだそうだ。 自分が患者の身になったところを想像すれば、なんて恐ろしいことかと思うだろう。 しかし「手術が好き」で医者になった人間からすれば、当然手術をしたいと考えるし、そのような診断を下したとしても違和感のない話である。 同様にして、技術が好きでエンジニアになった人間が手術＝リファクタリングをしたいと考えるのはごく自然なことだろう。 これが認知バイアスとなって働き、Howの不確実性を正しく認識することを妨げている可能性は否定できまい。

筆者が今、エンジニアとして新規事業の開発に携わっているという話はこれまでも何度か述べた。 じつは数週間前から細々と取り組んでいたリファクタリングがあったのだが、本日リファクタリングを元に戻すことが決定した。

主な理由は２つあった。

• (1)リファクタリング過程において複数の機能実装間でコードの一貫性が欠ける
• (2)不確実性の収束が期待できず後ほどまた別の変更が必要になる可能性が高い

(1)に関しては、近々多数のエンジニアがチームにジョインすることが決まっているため、コードベースの理解を妨げる要因を避けたいという外部状況も関係している。 そして注目すべきは(2)の理由で、まさに上で述べた議論に一致している。

今回、筆者が犯してしまった失敗は、WhatとHowの両方で不確実性が高い状態のままリファクタリングを進めてしまったことである。 「リファクタリングは（少なくともコードに改善する限りにおいて）良い習慣だ」という認識をもっており、不確実性の観点を十分に考慮に入れることができていなかった。 本経験をとおして、プロダクト開発における不確実性の考え方を一層深めることができた。