銀の弾丸を求めて迷走した私の失敗談。個人開発でオーバーエンジニアリングして気づいた「技術のコスト」の話

はじめに

本で読んだ『理想の設計』をコードに落とし込んだはずなのに、なぜかコードを書く手が止まってしまう……。そんな経験はありませんか？ここでは失敗談をベースに学んだことをまとめていきます。

個人開発でオニオンアーキテクチャを導入して失敗した話

そもそもなぜ導入しようと思ったの？失敗から始まった導入

導入以前に作ったプログラムでは1つのメソッドに1000行ぐらい実装するというヤンチャなことをしており、それが原因でバグの特定や機能拡張が困難になった経験があります。この経験から、ソフトウェア設計技術に関心を持つようになりました。この影響で徹底した責務の分離や拡張性の担保のためにオニオンアーキテクチャを導入しようと考えました。

結果どうなったのか

確かに責務が分離され、一定の効果を挙げましたが副作用に悩まされました。

最大の失敗理由：開発物と技術のマッチング

当時開発したものは一般的な企業製のアプリと比較して小規模かつドメインが単純なものでした。しかし、オニオンアーキテクチャは、チーム開発や長期運用を前提とした「変更耐性」を重視する設計です。 そのため、変更頻度や人の出入りが少ない小規模な個人開発では、その恩恵を受ける前に構造の複雑さというコストが先に顕在化しました。また、プロダクトの性質上GUIの実装とデータ出力や入力処理が複雑化しやすかったためオニオンアーキテクチャだけでは担保できない部分で問題が発生することもありました。

でも、技術を試したいなら個人開発が一番安全

こう感じている理由を説明します。

個人開発なら失敗しても問題ない！

失敗談は個人開発のもので、技術的なコスト以外は発生しませんでした。もし実務上であった場合はどうなるでしょうか。実務で失敗するとチーム全体が疲弊しますが、個人開発なら、途中で「やっぱりこの設計はやめた！」と全部壊しても誰にも迷惑をかけません。この 「設計の破壊的変更を許容できる場所」 は個人開発でなければ得られない場所だと思います。失敗できるという心理的安全性は学習のモチベーションにも大きく関わると思います(例えば、AzureやAWSなどクラウドの学習はお金がかかるので心理的ハードルが高い)。このように、個人開発は失敗しても大きな代償を払わずに済みます。 だからこそ、実務では許されないような「極端な選択」をあえて試すことができます。

失敗しても良いなら原理主義的な学習・実践ができる

ここでいう「原理主義的」とは、実用性よりも設計原則を最優先する姿勢を指します。 目的は「技術の限界を知ること」です。デメリットやコストを度外視して 100か0かの極端な実装を試すことで、その技術の真の境界線が見えてきます。原理主義的に実践することのメリット・デメリットを挙げます。

このように一長一短ではありますが、学習は選択肢を広げるためにあると思うので、試してみる価値はあると思います。

その一方、実務では実利的な選択が求められる

実務ではコスト・パフォーマンスのバランスをとった実利的な選択を余儀なくされるため、このような原理主義的な学習はできません。チームの習熟度や運用コスト、納期を考慮し、35や67といった「泥臭い妥協点」を探る判断が求められます。では、そのバランス感覚はどのように身につけるかを考えた際に、個人開発で失敗した経験は単純な知識量以上に役立っていると感じています。

学ぶ時意識した方が良かったなと後悔したこと

技術を学ぶ・導入する目的を明確にすることに意識を向けていましたが、それだけでは不十分で、その目的を達成するまでの「コスト・パフォーマンス」について意識すべきだったと思います。何か特定のトピックについて学ぶ際は基本的にその技術のメリットの部分に注目しがちでデメリットを過小評価してしまいました。

何かを得るために何かを犠牲にするという前提があると思った方が良かった

「銀の弾丸は存在しない」という意識を常に持たなければいけないと感じています。かなり前に話題になったFizzBuzz Enterprise Editionというジョークコードからも分かりますが、「SOLID 原則」「Clean Architecture」などを盲目的に適用し、結果的に「疎結合・高凝集」などのパフォーマンス以上に「複雑さ」というコストが増してしまうことが現実に起こり得ます。

参考：FizzBuzz Enterprise Editionのリポジトリ

技術のメリットやデメリットの影響は開発するプロダクト・組織によって異なること

本や記事に書かれている技術のメリット・デメリットは一般的に説明されています。例えば、「Dockerを導入するメリット・デメリット」について説明すると、

というような内容が挙がると思います。しかし、簡単な個人開発で1台のPCのみで開発する場合などは、Dockerを導入するコスト（設定ファイルの記述、ビルド待ち時間、リソース消費）が、得られるメリット（環境の統一）を上回ってしまうことがあります。「みんなが使っているから」ではなく、「今の自分のプロジェクトに、そのオーバーヘッドを支払う価値があるか？」を判断する力こそが、現場で求められるエンジニアの技術選定の力なのだと最近感じています。

まとめ：技術を「武器」にするために

本や記事で学んだ「理想の設計」や「最新技術」は、あくまで道具箱の中の一つのツールに過ぎません。それらを自分の真の武器にするためには、以下の3つのステップが重要だと私は考えています。

• 個人開発を「技術の実験場」にする: 失敗が許される環境で、あえて「やりすぎ」なほど原理主義的に技術を適用し、その限界（境界線）を感じる。
• 「得られるメリット」と「支払うコスト」を天秤にかける: 導入することで複雑性が増していないか、今のプロジェクト規模に合っているかを常に自問自答する
  • 可能であれば定量的に測れると良いと考えています
• 実務では「泥臭い最適解」を恐れないようにする。100点満点の設計を目指すのではなく、チームや目的に合わせて「35点や67点の妥協点」を戦略的に選べるエンジニアを目指す

そして何よりも失敗を恐れない。そのために失敗をしても良い環境を用意することが大事であると強調したいです。

「みんなが使っているから」という理由を超えて、「今のこの課題には、このコストを支払ってでもこの技術が必要だ」と自信を持って言える技術選定の力を、これからも個人開発を通じて養っていきたいと思います。