開発スピードと品質は両立の鍵はテストコード

  プログラミング >     プログラミングの理解 >  

ソフトウェア開発において、「スピード」と「品質」は長年トレードオフの関係にあると言われてきました。

テストコードを書くのは元々あまり好きじゃなく、なくてもいいのではとさえ思っていました。
しかし、AIエディタで自動でコーディングできるようになり、テストコードを書く工数が減り、仕様の確認もしやすくなるのでテストコードの必然性が増してきたように思います。

• スピードを優先すると、設計が雑になり、テストも後回し

• 品質を重視すると、設計が重厚になり、開発は遅くなる

アジャイル、ウォーターフォール、DDD、クリーンアーキテクチャ…。

どれも理想は美しいのですが、現場では“重すぎる”というのが正直なところです。

では、「速く作れて、しかも壊れない」

そんな現実的な解は存在するのでしょうか？

その一つの答えが、直行型アーキテクチャのテストコードです。

---

1. 直行型アーキテクチャとは何か

基本思想はとてもシンプルです。

1リクエスト = 1コントローラ
コントローラからDBまで“直行”させる

多くのアーキテクチャでは、

Controller
  ↓
Service
  ↓
Domain
  ↓
Repository
  ↓
DB

のように層が分かれています。

これは理論上は美しいのですが、実際には：

• 変更時の影響範囲が広い

• 小さな修正でも複数ファイルを触る

• テストのためにインターフェースが増殖する

という問題を引き起こします。

直行型では、こうします：

Controller → DB

必要な処理はそのコントローラに閉じ込めます。

---

2. 疎結合の作り方：あえて「共有しない」

一般的には「共通化は正義」とされがちです。

しかし、実務ではこうなります：

• 共通関数を直す

• どこが壊れるかわからない

• 全テストを回す

• CIが遅い

• 修正が怖くなる

直行型では、コピペを許容します。

なぜなら：

• 修正の影響範囲が1ファイルに限定される

• 安心して変更できる

• レビューが楽

• テスト対象が明確

「DRY」よりも「Safe Change」を優先します。

---

3. それでも共通化が必要なもの

もちろん、何でもかんでもコピペではありません。

最低限の共通処理だけは分離します。

• 認証・認可

• 入力バリデーション

• ログ

• エラーハンドリング

これらは：

pkg/common
internal/shared

のような専用ディレクトリに隔離します。

重要なのは、

業務ロジックは共有しない

という点です。

---

4. テスト戦略：Mockを捨てる

多くのプロジェクトで、テストはこうなります：

• インターフェースだらけ

• Mockだらけ

• 実際の挙動とズレる

• 修正のたびに壊れる

直行型では、本物のDBを使います。

基本ルール

• user_create.go
  → user_create_test.go

• MongoDBはDockerコンテナで起動

• 接続情報は MONGO_URL 環境変数

なぜMockを使わないのか

• 実運用と乖離しない

• テストが仕様書になる

• 設計がシンプルになる

• テストの保守コストが下がる

テストのために設計を歪めない。これが重要です。

---

5. CIが遅いと、開発は止まる

CIが10分かかると、

• 修正する気が失せる

• 細かい改善を避ける

• 技術的負債が溜まる

だから、CIは速くあるべきです。

---

6. 部分CIという発想

変更されたファイルだけをテストします。

例：

controllers/user_create.go

が変更されたら：

controllers/user_create_test.go

だけを実行。

common/ や db/ が変更されていなければ、全件テストは不要です。

メリット

• 数十秒で結果が返る

• 集中力が切れない

• 修正回数が増える

• 品質が自然と上がる

---

7. 全体CIは「要所」だけ

もちろん、全件テストは必要です。

ただし、常にではありません。

実行タイミング：

1. common/ や db/ を変更したとき

2. main ブランチにマージ

3. 夜間の定期実行

これで十分です。

---

8. CIルールの整理

変更内容	テスト範囲
コントローラのみ	対応テストのみ
共通処理	全件
DB変更	全件
mainマージ	全件

シンプルで、説明可能で、運用しやすい。

---

9. この構成が生む「心理的安全性」

この構成の本当の価値は、技術よりも「心理面」にあります。

• 変更が怖くない

• すぐ結果が返る

• 壊れても原因が特定しやすい

• チームが積極的になる

結果として：

開発スピードが上がり、品質も上がる

という理想的な状態になります。

---

10. 重厚設計が向いていない理由

DDDやクリーンアーキテクチャは、「大規模・長期・複雑」なシステム向けです。

しかし多くの現場は：

• 要件が頻繁に変わる

• ビジネス優先

• 人員も固定されない

• スピードが最優先

この環境では、軽さこそが正義です。

---

11. まとめ

直行型アーキテクチャは、

• 設計をシンプルに

• 影響範囲を限定し

• テストを現実に近づけ

• CIを高速化する

ことで、

「速く作って、壊れにくい」

という現場最適解を実現します。

 

by プログラマーこまつ