技術的負債について考えた
技術的負債についての自分の考えをまとめます。
言いたいこと
- 最初から綺麗なコード・設計を書ける状態を目指せ。
- そうもいかないものは天秤だが、勝手に背負うな。
技術的負債とは？
技術的負債は事業リスクです。放置することによって事業が失速したり損害が発生したりするため、適切に取り扱う必要があります。
負債の種類と対応は、以下の三つに別けられると自分は考えています。
1. 新規で書く末端機能のクソコード・クソ設計
最初から綺麗なコード・設計を書けるを目指すべきですが、時間がかかるのであればスピード重視でよいでしょう。 「もっと良いように書けるべきだけど、どうすればよいか？」とコメントでも添えて、さっさとプルリを投げてしまうべきです。
末端機能で、あとで上に乗っかる物がないのであればコードの品質はそれほど問題ではありません。テストを整備しておけば、後でレベルが上がったときに綺麗にできるでしょう。
使い捨て確定でなければ、テストは書くべきでしょう。テストがない≒リファクタは出来ない、とほぼ同義なので、テストを書かずに進むのは事業リスクが大きいです。
スピード重視、と一口で言いますが、綺麗な設計・コードというのは複雑でもなく記述量も少ないため、最初から書けるのであれば最速です。 リファクタリング本などを読み、最初から書けるように研鑽を積むのが理想でしょう。
2. 何かの土台となる新規のクソコード・クソ設計
許すべきではありません。
設計や関係にも依りますが、ソフトウェアには下が腐っていると上も連動して腐るという特性があるようにおもいます。直そうとしても影響が大きすぎて大変ですし、イケてない実装がコピペで大繁殖ことも多いです。 最初が大事です。
もちろん、そんなちゃんとしたコード・設計を作るのは難しいので、こういった土台部分には十分な実力を持ったエンジニアに担当してもらうのがよいでしょう。チームでのレビューも重ねて、良いと確信できる状態を目指しましょう。
未熟なエンジニアに土台作りをさせるのは止めましょう、これは組織の問題です。
3. 応急処置
障害対応や、キャンペーン対応、やりたいことに対してまっとうに挑むと膨大な工数になるような仕様変更に関しては天秤になります。スピード重視のほうが生存率が高いかどうかは事業と会社規模に依るでしょう。
これに関しては避けられませんし、絶対に発生しますが、エンジニアが自分で勝手に「理想ではない対応（やっつけ対応）」をするのは良くありません。
これらのやっつけ対応には事業リスクがあります。
エンジニアなどが自分から勝手にやっつけ対応を行うのは事業責任者に知らないうちにリスクを背負わせるのと同義で不義理です。
やっつけをやる場合、事業責任者に対して、理想の対応とやっつけ対応とそのリスクを説明したうえで、事業責任者がリスクを承知した上でやるとするべきでしょう。
またその際にはチケット化など可視化しておき、返済するしないに関わらず存在を認識できるようにしておくことが重要です。
素早く負債のない開発を理想としよう
最初から綺麗なコード・設計を書き続けろ、変更にも強いやつな！！！ というのがエンジニアには求められています。そりゃそうだが… としかいいようがないです。
難しいことですが、この状態を目指すための努力を続けるべきだと考えます。
自分でも確信できる答えがあるわけでもないですが、少なくとも正しかろうと思ってやっていることと、なんでこういう考えになったのかは以下のスライドにまとめてあります
このスライドを発表した勉強会の3回目を6/16に行います。
皆様のご参加お待ちしてます！！！
