※ChatGPTを使用して記事を作成しています。
「もう設計の話はやめよう。」
その一言で、会議室の空気が少しだけ軽くなった。
長い間、私たちは「正しいアーキテクチャ」を追い続けていた。
クリーン、MVVM、DI、UseCase、Repository──。
でも、その“正しさ”がいつしかチームを縛っていた。
今回は、設計を一度捨てたことで、チームが本当の意味で動き出した話をしたい。
設計がチームを止めていた
プロジェクトの初期。
私たちは、過去の失敗を繰り返さないために、完璧な設計を目指していた。
- ViewModelにはロジックを一切書かない
- Repository層は必ず抽象化
- UseCaseを1画面につき1つ定義
- 依存関係はHiltで完全DI化
見た目は美しかった。
しかし、半年後にはこうなっていた。
「どの層を直せばいいか分からない」
「Repositoryが多すぎて探せない」
「UseCaseが増えてメンテ不能」
レビューコメントは「命名規則違反」「層が間違ってる」ばかり。
肝心のUI改善や機能追加は後回し。
私たちは気づかぬうちに、設計を守ることが目的化していた。
設計レビューが宗教戦争になった日
ある日、チーム内で設計方針を巡る議論が起きた。
新しい機能を追加したい若手がこう提案した。
「この機能、ViewModel内で処理書いちゃダメですか？
UseCaseに切り出すほどのロジックでもないので…」
すると、すぐに設計原理主義者の私は言い放った。
「いや、それは責務の分離違反だよ。アーキテクチャが崩れる。」
その瞬間、若手の顔が曇った。
──この瞬間だった。
設計の“正しさ”が、成長を止めていた。
彼はこう漏らした。
「なんか最近、設計に怒られてる気がします。」
胸が痛んだ。
転機：「動くこと」を最優先にした日
リリースが迫る中、会議で私は提案した。
「ルールを一度、全部外そう。
今は“動くものを作る”ことだけ考えよう。」
チーム全員が驚いた。
けれど、その日から空気が変わった。
- ViewModelでAPIを直接叩いてもOK
- UseCase不要なら作らない
- Repositoryは抽象化しないで実装クラスのみ
- テストも必要な範囲だけ
「完璧」ではない。
でも、とにかく動いた。
UIの改善スピードは2倍に上がり、バグ報告も減った。
そして何より、チームの会話が“設計論”から“プロダクトの価値”に戻った。
混沌の中に秩序を見出す
設計を捨てた結果、確かにコードは少し雑になった。
でも、そこには新しいルールが自然に生まれ始めた。
- 同じ処理を2回書くなら、共通化しよう
- 無駄にクラスを分けず、理解できる範囲でまとめよう
- 新メンバーでも3分で流れが分かる構造にしよう
これらは文書化されたルールではない。
「現場が育てた文化」 だった。
人間が動いて、初めて“設計”が意味を持つ。
それを痛感した瞬間だった。
再び設計を取り戻す
半年後、プロジェクトが安定し始めたころ。
私は再び、設計を見直した。
ただし、今度は現実と折り合いをつけた設計にした。
- 共通UseCaseは「本当に共通化できるもの」だけ
- RepositoryはDataSourceが2種類あるときだけ定義
- ViewModelは“UIロジックを含んでもいい”
- テスト容易性よりも、まず「動く設計」
結果、コードレビューは減り、議論は増えた。
「なんでこの構成にしたんですか？」という質問に、誰もが自分の言葉で理由を説明できるようになった。
設計はチームの鏡だ
後になって気づいた。
設計とは、そのチームの状態を映す鏡だ。
- コミュニケーションが薄いチームは、層が無駄に厚くなる
- 責任を押し付け合うチームは、抽象クラスが増える
- 信頼し合えるチームは、単純なコードで動く
設計を捨てたことで、「チームとしての信頼」を取り戻した。
そして、そこに初めて“設計”が戻ってきたのだ。
教訓：設計は「共有言語」であり、拘束ではない
設計はルールブックではない。
「チーム全員が同じ方向を向くための共有言語」 だ。
完璧な構造を追うより、「誰が見ても理解できるコード」を書くこと。
それが最強のアーキテクチャだと、今は思う。
まとめ
- 設計を守ることが目的化すると、チームが止まる
- 一度ルールを外して、自由に動くと本質が見える
- 設計は“教科書”ではなく“チームの文化”である
- 人が動けば、設計は自然と整う
エピローグ
設計を捨てるという選択は、勇気がいる。
でも、その勇気がチームを救うことがある。
「設計通りに動かす」ではなく、「動くために設計を変える」──。
この連載を通して伝えたかったのは、“正しさより動きやすさ”を大切にする姿勢だ。
失敗から学び、再び立ち上がる。
それこそが、エンジニアとしての成長の証だと思う。
