技術的負債の多寡をフリーランスエンジニアの立場から考える

※ 完全に個人的な考察です

定義

フリーランスエンジニア:
ここでは準委任契約で契約期間が数ヶ月単位のエンジニアのこと。広義でSESも含むとすると母数がかなり多いと思われるためこの集合に属するものを便宜上フリーランスエンジニアとここでは呼ぶ

技術的負債:
開発スピードを優先した結果誕生してしまった、保守性の低いコードのこと

なぜ技術的負債は返済されないか

表にしてみる

こんな表を考えます。
これはプロダクトの性質を売上とシステムの品質の2軸で表現したものです。

ここでは システムの品質が高い = 技術的負債が少ない ということになります。
なぜなら、品質が高いシステムというのは長期に渡ってメンテナンスしていくことを前提として、入念に設計された上で作られているからです。
これ即ち保守性が高い = 技術的負債が少ないという意味になります。

技術的負債だと高いほど好ましくないため、高ければ高いほど好ましい売上とベクトルが逆になってしまいます。
これらを組み合わせて表を作ると違和感があったので、方向性を合わせるために売上とシステムの品質の組み合わせにしました。

表中のA〜Dについて考える

表を4つのエリアに区分けしましたがそれぞれ以下のような所感を持っています。

A : 売上があがっていてシステム品質も高く理想的
B:  拙速が功を奏して売上は立ったが技術的負債が溜まってしまったケース
C: 売上はまだあがっていないがコードはクリーンな状態
D: Bの失敗ケースで技術的負債を作った甲斐がない状態

Aは文句なしですが残念ながら自分は遭遇できたことはないです。
Bは個人的には一番よく見かけるパターンです。売上が立たないサービスが淘汰されていく中、技術的負債を抱えながらもなんとか収益を出しつつサバイブしているプロダクトだと思います。
Cは技術力が高いチームが手がけるプロダクトがまだ黎明期の時などにここに分布しそうです。
Dに関してはそもそもスケジュールは無理なく引いたが保守性が高いコードを書くスキルが元々なかったなんてパターンもありそうです。

Aが文句なしで最高、Dが最低という評価は万人共通だと思います。
BとCに関してはどちらが好ましいか個人の嗜好によると思います（後述）

技術的負債の返済が後回しにされる理由

売上を上げることがシステム品質を高めることよりも優先されるためです。
新機能の追加やプロモーションの企画など、売上をアップさせる施策が尽きない限りはベクトルは基本的に真上に向いていくと思います。

横軸のどこに位置していても売上の軸の極力上の方まで昇りつめないとこのトレンドは止まらないと考えられます。
特に売上の軸で低い場所にいるほどその圧は高まりそうです。

A〜Dの中を再起的にさらにA〜Dに分けたときに、A - A,  A - B,  B - A,  B - B のような領域に到達するまでは継続するように思います。

システムの品質の軸の右側に向かうのは基本的には上記のように売上を上げきってからになると思います。

ベクトルが↗︎ みたいに右斜め上に向かっていくのもあまりみたことがありません。
技術負債を解消しながら売上を上げられるチームは最初から負債を作らないと思われるためです。
クリーンアーキテクチャの著者の以下のような格言を地で行くことができる高いレベルのチームで、相当稀有であると思われます。

売上がフリーランスの契約スパンと同じぐらいの月数で劇的に上がるようなことは現実的には考えにくいです。
成果が出るにはかなり時間がかかりますがそれを待ってようやくシステムの品質を上げようとする余裕が出ると思われます。

したがって、後回しにされた技術的負債は一向に返済されないと考えられます。

どんなプロダクトだと参画したくなるか

雇用形態に関わらず、システム品質が高いところ（横軸上のなるべく右側）から入りたい人は多いはずです。
品質の高いシステムは学びの宝庫であり、そこから収集できる知識や運用という実践の場での体験により人材価値を向上させることができます。
（品質にこだわりがない人もいると思いますが、ここでは除外して考えます）

ただし、フリーランスの場合は契約期間を考慮すべきだと思います。
フリーランスは数ヶ月スパンで契約解除される契機が定期的にあるためです。

そのような条件下で表の左側に入りたいと思うでしょうか？
DエリアからBエリアを目指している間、売上が立つとは限りません。
その間高い当事者意識も求められ消耗することもあると思いますし、仮に目標とする売上を達成することができてもその頃合いで契約も終了するかもしれません。

上記のような事態を回避するためにも、フリーランスなら下図のエリアに分布するプロダクトに携わりたいのではないかと思います。

Cエリアには新規プロダクトも該当しそうで、そういったものは開発環境もモダンなもので開発を始めると思うので個人的には特に好ましいと思っています。

一方、正社員の場合は事情が違うと思っていてBエリアでの参画も十分検討と思います。

なぜかというとBエリアの上部に到達していてベクトルがシステム品質の向上にむかう局面であったり、技術指向が強く早めにシステム品質の改善にピボットするようなチームだとAエリアを目指せるからです。

フリーランスでも技術負債の返済が苦でない人や、開発環境モダン化の実績などを作りたい人とも利害関係は一致するかもしれません。
そして、Aエリアに到達したら正社員であればその恩恵は長期にわたって受けることができます。

したがって、個人的には会社員として雇われるなら入りたいエリアは下図のように拡大できます。

Dエリアに関しては創業メンバーでストックオプションがあるなど特殊なインセンティブを持った人間や、事業をスケールさせること自体が好きといった嗜好の持ち主じゃないとモチベーションを維持できないのではないかと思います。
なので、フリーランスとしてここからの参画を好む人というのはなかなか珍しいと思います。

Aエリアに関しては文句なくここからスタートが理想的だと思うのですが、遭遇すること自体が難しいと思います。

最後に

随分と自分の都合のいいようにモデリングして話を進めてしまいました。

• 複数プロダクトを抱えていてプロダクト横断で活躍を求められる現場ならどうなるのだ？

• 売り上げなんてエンジニアリングだけじゃなくてビジネスサイドの力に大きく左右されるだろうがその辺も考慮すべきでは？

• そもそもプロダクトの規模や性質によって技術的負債のたまりやすさが異なる。要件が複雑ならそれだけコードも複雑になりやすいのでは？

• A,Cのプロダクトにあたってもカルチャーフィットの不一致などの技術面以外の観点からすぐ契約解除されたらどうするんだ？

などなどツッコミどころは色々あると思うんですが、ここでは一旦開発者目線、プロダクト単体という条件で自分の脳内を整理することを主目的としてアウトプットしました。

実際は会社の経営状況やプロダクトの市場など技術以外の選定基準は山ほどあると思います。

あくまで一個人の意見ですが読んでくださった方に参考になる部分があったなら望外の幸せです。

FAQ

この章はおまけです。

過去に技術的負債に関してこんな質問があったので備忘録程度に残しておきます（この記事のコンテンツを基準に回答も考えました）

そもそも技術的負債のない案件なんてないのだからそこに固執するな

事実誤認です。

技術負債は0 or 1 で語るものではなく、度合いの大きさのグラデーションで対比するものでありこの認識を合わせない限り話を進めることができません。

この質問には「新規プロダクトでもない限り」という含意があると思いますが、それも「新規プロダクトではない」かつ「技術負債がない」というものが全く存在しないという主張には無理があります。

技術的負債は必要悪だと思うがあなたの意見はどうか

売上アップのために拙速で行った結果発生したものに関しては同意です。
コピペで適当に作るなどの怠慢で発生したものに関してはそうではないと思います。

まとめ

• 技術的負債の返済は一般的には売上が上がった後

• プロダクトを売上とシステム品質の高さ（≒ 技術的負債の少なさ）の二軸で考えたときに雇用形態によって重視する軸が異なる

  • フリーランスエンジニアにとっては売上がすでに立っているかよりもシステム品質の高さ（≒ 技術的負債の少なさ）が案件参画の誘因となる

  • 正社員として雇用される場合、選定基準は 売上 > 技術的負債 というプライオリティになるかも

• 技術的負債に対する考え方はそれぞれある

  • ただし、有る・無いで黒白の差をつけるべきではなく、度合いのグラデーションで考えるべき

  • ケースバイケースで必要悪と考えることはできると思う