場当たり的な対応で工数が少なくてすみ、影響範囲も少ないが、コードは汚くなるという案と
影響範囲が広いし工数も掛かりそうだが、コードは綺麗になるという案があるとき、
僕は、よほどの差でない限り、コードが綺麗になるほうを選ぶ。
ここで場当たり対応を選んでしまうことは、
「現実をみた大人の意見」のように思えるかもしれないが、
僕からすると、大事の前の小事にこだわるという、本末転倒の考え方にしか見えない。
保守で、既存プログラムの修正をやろうという後輩から相談を受けた。
既存プログラムのSQLの一箇所が違うだけのメソッドを作る必要があるとのことだ。
メソッドをコピーして重複したコードを書くことに後輩は納得がいかず、うまい方法は無いものかと僕に相談をしてくれた。
僕は、このメソッドの引数を追加して条件分岐できるようにし、元のシグネチャオーバーロードとして別途定義する案を上げた。
後輩は、我が意を得たりと納得し、嬉々としてその実装に取り掛かった。
しかしながら、保守チームの上官から待ったが掛かった。
この既存メソッドは、幾つかの箇所で呼び出されていて間接的な影響範囲は大きい。
だから、「変更よりも追加を」の原則で、コピーして新規に同じようなメソッドを
作ってほしいといわれたらしい。
僕は非常に落胆したが、今後しばらくその後輩の面倒を見てくれるのは
その上官なので、「従うように」と指示した。
この安全策の意図は、たしかに理解できる。
保守チームの発想としては普通の考えかただろう。
「出来るだけ綺麗にというのは、新規開発の発想で、保守では通用しない」
というようなことも言われたらしい。
僕が、この保守チームを率いたなら、このような後手後手を生み出すだけの思想は許さない。
「安全に動くこと」はたしかに保守サービスで大事なことだが、
「綺麗にしてはいけない」というのは、どういったサービスか？
２言目には「コストが、工数が」という言葉が返ってくる。
しかし、こういった汚いコードによって1つ1つの修正が無茶苦茶大変な作業になっている。
それにより、とんでもない工数を請求している現実に目を向けているのだろうか。
場当たり対応が、保守の費用を上げる元凶になっているのだ。
目先の小金を得るために、最小限の工数で対応することが正解だという姿勢は正しいのか？
修正のために新たな重複コードを埋め込むことが保守なのか？
貰った工数が少ないからといって、場当たり対応することが果たして最終的にお客さんのためになるのか？
ここでもっと綺麗に直しておけば、次の機会にはもっと短い工数で対処が出来るのに。
「保守性を高めたら、顧客から保守費用がいただけない。」
と知った顔で、もし偉そうにいう奴がいれば、言ってやる。
そんな仕事をビジネスとは呼ばない。ただの詐欺だ。
僕は、エンジニアなのに付け焼刃のビジネス感覚でビジネスを議論するより前に
自信をもって作ったものを顧客に提供できるようにすることが第一なのではないかと思う。
※ちなみに、ここに登場する上官氏も別に問題を認識していないわけではない。
組織の文化を変えるのは言うのはたやすいが実践するのは難しい。
しかし、何を理想とするのかを正しく持っていなければ理想にたどり着くどころか近づきもしない。
