はじめに：品質は「人」ではなく「構造」で担保する
「コードの品質を上げよう」と号令をかけるだけでは、現場は変わりません。
レビューで「読みやすくして」と指摘し続けるのも、指摘する側・される側双方にとってコストが高い作業です。
私たちは、新規開発の立ち上げにおいて、コード品質を個人のスキルや努力に依存させるのではなく、「ツール」と「プロセス」による構造化で担保するアプローチをとりました。
本記事では、私たちが実際に定義した 「9つの品質基準」 と、それを実現するために導入した具体的なアクション（設定、ルール、運用）を紹介します。
私たちが定義した「9つの品質基準」
まず、漠然とした「品質」という言葉を以下の9つに分解しました。これらをどうシステム的に解決したかを後述します。
| 品質基準 | 実際にやったこと | ねらい（何を楽にしたか） |
|---|---|---|
| ① 可読性 | ・命名ルールをレビューで統一 ・EditorConfig + Code Cleanup 導入 ・過去レビューを元にしたAIレビュー |
他人のコードを「読んで理解する」コストを下げる |
| ② 一貫性 | ・PRは必ずレビュー（全件） ・書き方に迷ったらチームで決める ・レビュー観点をプロンプト化 |
人によって書き方が変わらない状態を作る |
| ③ 保守性 | ・例外スローの整理方針 ・ロジック肥大化の抑制 ・XMLコメント整備 |
修正時に「壊れる範囲」が読める |
| ④ テスタビリティ | ・単体テストを必ず実装 ・テストDB/カテゴリ整理 ・GitHub Actionsでビルド |
変更時の安心材料を用意する |
| ⑤ ドメイン理解性 | ・基本設計資料の共有 ・ER図の作成と展開 ・用語整理（請求/入金/支払など） |
コードと業務知識を結びつける |
| ⑥ 再現性 | ・環境構築手順の明文化 ・開発/コーディング手順書作成 ・拡張機能・ツールの統一 |
新メンバーでも同じ立ち上がりができるようにする |
| ⑦ 自動化可能性 | ・GitHub Actionsでビルド ・AIレビューの組み込み ・コード整形の自動化 |
人がやらなくていいことを減らす |
| ⑧ 安全性 | ・ブランチ運用ルール整理 ・マージ順の明確化 ・リリース手順の標準化 |
「壊さずに出す」確率を上げる |
| ⑨ 可視性 | ・PowerBIで生産性可視化 ・定例での振り返り ・納期/テスト整理 |
会議感覚ではなく事実で話す |
1. 開発環境の構造化（可読性・再現性）
レビューで「インデントがずれている」「改行位置が気になる」といった指摘をするのは時間の無駄です。これらは環境側で強制します。
.editorconfig とコードクリーンアップの配布
個人の好みを排除するため、チーム共通の .editorconfig をリポジトリに配置することは基本ですが、それだけでは不十分です。Visual Studioの 「コードクリーンアップ」機能の設定自体もエクスポートして配布しました。
- 狙い: 「保存時」や「コミット前」に自動整形をかける習慣の統一。
- 効果: PRが出された時点で、フォーマットは既に統一されているため、レビューでスタイルの議論が一切発生しなくなりました。
拡張機能の標準化
「Namespaceの自動修正」や「インデントの可視化」など、開発効率や品質に直結するVisual Studio拡張機能はリスト化し、全員にインストールを推奨しました。
「あの人の環境だと警告が出る」といった環境差異によるトラブル（再現性の欠如）を防ぐ基盤となります。
2. レビューの構造化（一貫性・自動化可能性）
レビューの質がレビュアーの体調やスキルに依存しないよう、プロセスを変えました。
「好み」での指摘を禁止する
リーダーやレビュアーが、その時の気分で「こっちの方が好き」と指摘し始めると、チームの基準がブレます。
私たちは 「ツール（Linter/Formatter）で指摘できないことは、原則として許容するか、ルール化してツールに落とし込む」 という方針を徹底しました。
現場のコードから「良い書き方」が見つかれば、それをルールに昇華させる（いいとこ取りをする）ボトムアップな運用で基準を作っています。
レビュー観点のプロンプト化（AI活用）
過去のレビューで頻出した指摘事項（命名規則の揺らぎ、単純なロジックミスなど）を分析し、AI（LLM）へのプロンプトとして定型化しました。
- Before: 人間が目視でタイポや単純ミスを探す（疲れる、漏れる）。
- After: AIが一次レビューを行い、人間は「ビジネスロジックの正しさ」「設計の妥当性」に集中する。
これにより、レビュー時間は短縮され、かつ指摘の粒度が安定しました。
3. 設計とドメイン知識の構造化（保守性・ドメイン理解性）
ドキュメントを書きすぎると形骸化し、書かないと属人化します。バランスの取れたアプローチが必要です。
ドキュメントより「対話によるメンタルモデルの同期」
「Controllerの責務」「Serviceの粒度」といったアーキテクチャのルールは、厳密な仕様書を作るよりも、レビューや日常の対話を通じて チーム内のコンセンサス（合意） を作ることを重視しました。
「私たちのチームではこう書く」という共通認識さえあれば、分厚い設計書がなくてもコードの構成は統一されます。
「たすき掛け」開発による知識共有
仕様理解（ドメイン知識）の属人化を防ぐため、関連する機能の実装をあえて分担させました。
- 例: 「請求機能（データ作成）」と「入金機能（データ利用）」を別の担当者が行う。
こうすることで、「このデータはどういう仕様で来るのか？」という会話が必然的に発生し、相互に業務知識を補完し合う関係性が生まれます。ドキュメントを読むよりも深く、確実な仕様理解につながります。
4. 安全性と運用の構造化（テスタビリティ・可視性）
テストは「変更への恐怖」を消すために書く
単体テストの目的を「バグ発見」以上に 「リファクタリングの安全地帯を作ること」 に置きました。
テストコードがあり、GitHub Actions等のCIで自動ビルドが通ることが保証されていれば、エンジニアは恐れずにコードを変更できます。この「安心感」こそが、開発スピードを維持する鍵です。
手順書と可視化で「感覚」を排除する
- リリース手順: CI/CDが完全でなくとも、手動デプロイの手順書、ブランチ運用、タグ付けルールを明確化し、「誰でも事故なくリリースできる」状態を作る。
- 生産性の可視化: PowerBI等で進捗や課題を可視化し、「なんとなく遅れている」といった感覚的な議論を排除する。
まとめ
これらは一見、面倒な「縛り」に見えるかもしれません。しかし、これらを徹底することで得られるのは 「迷う時間の削減」 と 「本質的な開発への集中」 です。
- フォーマットで迷わない。
- 単純ミスでレビューを往復させない。
- 壊す恐怖に怯えながら修正しない。
「今は回っているから大丈夫」ではなく、平時のうちにこうした構造を作り上げることが、中長期的な開発生産性を最大化する投資になります。