この記事はすきま経営からの転載です。
結論から書く。個人開発でクリーンアーキテクチャを採用する価値は「ある」が、無条件ではない。私は複業のfinance-managementリポジトリ（家計データの集計・シート同期・Slack通知）でdomain/ports/adapters/usecaseの構成を採用し、実際に開発速度が落ちなかった一方、別の小さなスクリプトでは同じ構成を見送った。この線引きの基準を、実体験から書く。
「オーバーエンジニアリング」批判は半分正しい
個人開発でクリーンアーキテクチャを検討すると、必ず「1人でやるプロジェクトに層分けは過剰だ」という批判にぶつかる。この批判は半分正しい。
layer分割・依存性逆転・インターフェース定義には、書く量が確実に増えるコストがある。CRUDを1本書くだけの使い捨てスクリプトに、domain層とport層を用意するのは明らかにやりすぎだ。私も複業のうち検証段階のスクリプト（storeforgeのリサーチ用一時ツールなど）では、1ファイルに手続き的に書き切ることの方が多い。「型を守ること」自体が目的化してしまうと、本業でクライアントに提供しているはずの「動くものを最短で作る」という価値と矛盾する。
批判が半分しか正しくないのは、この判断が「クリーンアーキテクチャか否か」の二択ではなく、プロジェクトの性質に応じた選択の問題だからだ。
採用を決めた基準は3つ
finance-managementでクリーンアーキテクチャを採用した際、判断基準にしたのは次の3つだった。
- 外部依存の数と入れ替わりやすさ: このリポジトリはMoneyForwardのCSV、Google Sheets API、Slack Webhookという3つの外部インターフェースを扱う。CSVのフォーマット変更、Sheets APIの仕様変更、Slack通知先の変更は、それぞれ独立して起こり得る。外部依存を1つずつport/adapterに切り出しておけば、変更の影響範囲を1ファイルに閉じ込められる
- テストのしやすさが成果に直結するか: 集計ロジック（家計の4象限分類など）は金額を扱うため、ロジックのバグが実害に直結する。domain層を外部I/Oから切り離しておけば、Sheets APIやSlackを一切呼ばずにユニットテストで集計ロジックだけを検証できる。これは1人開発でも省略したくない部分だった
- 開発が単発で終わらず継続するか: 数週間で書き捨てるスクリプトなら層分けの投資は回収できない。finance-managementは週次で動き続け、今後も通知先や集計軸が増えていく前提だったので、初期コストを払う判断をした
3つとも満たすプロジェクトは、複業の中でもfinance-managementくらいで、storeforgeの検証スクリプトやafflowの一時的なGASボットはどれも満たさなかった。
実際にかかったコストとリターン
正直に書くと、finance-managementの初期構築では、単純にファイルを書いていくより明らかに時間がかかった。ports（インターフェース）を先に定義し、domain層をI/Oから独立させ、usecase層で組み合わせる、という順序を守る必要があったからだ。1人開発だとレビュアーがいないので、この規律を破ろうと思えばいつでも破れる。それでも守ったのは、後で自分自身が「なぜこの層にこのロジックを書いたか忘れて壊す」ことを防ぐためだった。
リターンが出たのは、後から新規取引のSlack通知機能を追加したときだ。既存の集計ロジック（domain層）には一切手を入れず、Slack通知用のadapterとusecaseを追加するだけで実装が完結した。既存のCSVチェック機能やシート同期機能を壊すリスクがほぼゼロだったのは、層が分かれていたからだ。PR単位でも変更範囲が「新しいadapter1つ追加」に閉じたので、レビュー（といっても自分でのセルフレビューだが）も素早く終わった。
逆に言うと、このリターンは「機能を継続的に追加する」というシナリオでしか発生しない。1回書いて終わりのプロジェクトでは、このリターンを回収する機会自体が来ない。
個人開発での判断チェックリスト
自分の複業群で繰り返し使っている、採用可否の簡易チェックだ。3つ以上当てはまるなら採用を検討し、1つ以下なら手続き的に書く方が早い。
- 外部サービス・APIへの依存が2つ以上あり、それぞれ独立して変更され得る
- ロジックにバグがあると金銭的・信用的に実害が出る（家計・決済・顧客対応など）
- 数ヶ月以上、機能追加が続く見込みがある
- 将来、外部サービスの差し替え（例: Slack→別ツール、Sheets→DB）が現実的に起こり得る
- 自分以外の第三者（将来の自分を含む）が半年後にコードを読む可能性がある
FDEの現場でクライアントのコードベースを見るときも、結局この基準は共通している。個人開発だから緩めていい部分と、個人開発でも譲れない部分は、規模ではなく「継続性」と「実害の大きさ」で決まる。
まとめ
- クリーンアーキテクチャは個人開発でも「無条件に過剰」ではなく、プロジェクトの性質次第で価値が変わる
- 採用の判断基準は「外部依存の数」「テストで守りたいロジックがあるか」「開発が継続するか」の3つ
- finance-managementでは初期コストを払った分、後からの機能追加（Slack通知）を既存ロジックに触れずに実装でき、リターンを回収できた
- 書き捨てのスクリプトや検証段階のツールには、同じ構成を持ち込まない判断も同じくらい重要
次回は、複業それぞれで使っている技術スタックの選定基準について書く予定だ。