1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

技術的負債を完全に防止することは無理!!というお話

Last updated at Posted at 2025-04-11

はじめに

webアプリを個人開発する機会があり、自由な個人開発なのだから技術的負債をゼロにするぞ!!と息巻いたものの敗北したお話です。技術的負債にどう向き合うべきかまとめました。
割と当たり前な内容ですが、折角経験したので残しておきます。

結論

  • 技術的負債をゼロにするために頑張るなら、サービスに力を注ぐのもあり
  • 技術的負債は適切なものと、不適切なものに分かれる
  • 適切な技術的負債は状況によっては受容すべきだが、返済計画は立てるべき

技術的負債とは何か

議論の前に、前提となる「技術的負債とは何か」を抑えておきます。

設計、フレームワーク、言語、コードに関し、継続的に開発を行う上で理想状態から離れたもの

つまりは「あるべき」ではない状態です。
さらに、マーティン・ファウラーは、技術的負債を4象限に分けて整理しています。
image.png
(引用:@hirokidaichi, https://qiita.com/hirokidaichi/items/c66682a64ac2fc59cdf3)

このうち慎重な無意識の領域については、リリース後に初めて発覚するものなので、開発中に気付くのは原理的に無理です。
さらに慎重で意図的な領域の負債は許容すべきだと思う場面が多くありました。

慎重で意図的な技術的負債

この領域は、技術的負債を自覚したうえでスピード、リリース、コストを優先して敢えて負債をこしらえます。
例えば、今回の開発では設計をかなり妥協しています。
そもそも設計書を必要最低限しか作っていません。作ったのは下記ぐらいです。

  • テーブル設計書
  • 特に複雑なロジックの基本、詳細設計書
    以上。
    絶対特大の負債をこしらえています。
    しかし、詳細完璧な設計書を作ったところでサービスが売れずに没になったら設計書も闇に葬られます。
    それであれば最低限動くサービスをいち早く作って市場に投入して、継続していける見込みが立てばリバースエンジニアリング方式で設計書を作ったほうがよっぽど生産的です。
    上記のような理由で妥協している箇所が他にもあり、現在進行形で負債は膨らんでいます。

ではどうするのか

負債が膨らんでいる以上、返済計画を立てなければいけません。無計画な負債は、遠くない将来に首が回らなくなります。
今回の開発では、特にいくつかの対策を講じて返済計画としています。

概要

  • ソースコードに実装意図を細かく書いておく
  • 複雑なSQLは生のSQLをソースコードにコメントで埋め込む
  • 将来的な修正はGitHub Issuesに起票しておく

詳細

ソースコードに実装意図を細かく書いておく

ロジックの内容はコードを読めば分かるので、ロジックの意図、理由を細かく記載します。
一人開発であっても、理由や意図は時間経過とともに忘れていくのでしつこいぐらいに書きます。

複雑なSQLは生のSQLをソースコードにコメントで埋め込む

今回の開発ではlaravelを採用しており、Eloquentというライブラリを使っています。

return User::select('name')
                ->where('id', 〇〇〇〇)
                ->where('deleted_at', null)
                ->get();

SQLをこんな感じに書けて便利なのですが、複雑なSQLになっていくと読むのが若干厄介になっていきます。そのため、動作確認も兼ねて適当なSQLエディタで生のSQLを書いて整形した後に、コメントとしてそのままコードに埋め込みました。
これはコードが冗長化することに繋がり兼ねないので良し悪しですが、自分のようなよわよわレベルだと生のSQLを書いておいたほうが後々把握しやすいのでこうしています。

将来的な修正はGitHub Issuesに起票しておく

issueとして起票しておくと、どの程度自分が負債を作っているのか可視化出来ます。
後々、把握していない負債が爆発するリスクを低減出来るとともに、リファクタリングする際にコミットやプルリクエストにissueを紐づけることでリファクタリング内容や意図を明確にすることが出来ます。
スプレッドシートやNotionで変更管理するよりは、変更を追いやすいと感じています。

さいごに

個人開発は誰に縛られることもなく自由なので、せめて意図的な技術的負債は防ぎたいと思っていました。
しかし、主にリソース不足が原因でチーム開発よりむしろ増えた実感あります。
慎重な無意識の領域については言わずもがな、チーム開発ならシニアエンジニアに相談出来た部分を独力で解決しなければならないため、膨大な量の負債を溜め込んでいる自覚があります。

某Vtuber上場大手事務所のテックマネージャーの方を会話をする機会があり、その際に「技術的にも経営的にも安定した今、注力しているのは技術的負債の返済」と話されていたのが印象的でした。
大抵の負債はどこかで返済する必要があり、放置するほど開発が進み肥大化するので、せめて返済しやすいように準備しておきたいものです。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?