技術的負債の定義は色々あるが、大きく分けると、改修時に問題となるモノと、時間経過と共に問題となるモノの2パターン存在する。

前者(改修時に問題となるモノ)は開発効率は落ちるが、必ずしも返済の必要は無いモノ。
なぜならば、返済した箇所が今後の改修で、どれだけ使われるか読みきれないから。但し、上手く付き合わないと不具合発生率が高くなる。
また、リファクタリング(動作を変えずに作りやすくする事)は諸刃の剣で、自動テストのケース漏れか仕様理解が足りないと不具合を作るだけで、疲労感しか生まない。

一方、後者(時間経過と共に問題となるモノ)は必ず返済しなければならないモノ。
なぜならば、今まさに問題となっている、または今後、問題が表面化しそうだと気付いたから。
原因は異常系や負荷等の考慮不足の場合が多い。但し、一概にエンジニアの問題とは言えない。
経験不足や疲労で考慮できない事もあるが、スピードを優先して意図的にやらない事も多い。
また、システムには必ず制限事項が存在する。実際、AWSや他のサービスにも存在していて、無限にスケール出来る訳ではない。

しかし、人間は見たくないモノや理解出来ないモノは、無意識に見えなくなる。
この行為と技術的負債の掛け合わせが、(勝手に命名しましたが)思考的負債だと感じている。

スピート優先で作った人も、その不足を補う動きをした人も、制限事項を理解した上で、平等に称賛されるべきで、そうしないと、補う動きをする人は少なくなり、負債がどんどん大きくなって。。。(後は想像にお任せします)

他も同じだと思うが、目立つモノに目を奪われてはダメなんだろうなというお話でした。
誰かが誰かの仕事を支えている(某CMっぽいけど)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です