はじめに：開発の熱気の中で感じた「静かなる危機」
当時は新規開発の真っ只中でした。
スケジュールは決して余裕がある状態ではなく、初回のリリースに向けて全員が必死にコードを書き続けていました。
まだサービスインしていないため、ユーザーからのクレームや突発的な障害対応こそありませんでしたが、現場は常に「機能実装」に追われている状態でした。
そんな「とにかく前に進むしかない」という熱気の中で、私は 「このままでは危ない」 という強い危機感を感じていました。
チームは少人数。開発のスピードを支えていたのは、個々のエンジニアの「高いスキル」と「責任感」による馬力でした。言い換えれば、「各自が空気を読み、個人の頑張りでなんとか回している状態」 だったのです。
「このまま人が増えたらどうなる？」「もし明日、誰かが異動になったら？」
そう考えたとき、品質を保てなくなる未来、そして開発が破綻する未来がはっきりと見えました。
これは「人の問題（リソース不足やスキル不足）」として片付けるべきではありません。「品質維持を個人の努力に依存している」という「構造の問題」 だと捉えました。
「品質」は「スピード」の対義語ではない
よく「品質を上げようとするとスピードが落ちる」と言われますが、私たちの考えは逆です。
「構造としての品質がなければ、長期的にはスピードが出せなくなる」。
特に私たちのような新規開発のフェーズでは、焦るあまり「まずは動くものを」と突っ走りがちです。しかし、構造がないまま積み上げたコードは、後になって以下のような「見えない無駄」を生み出します。
- 誰が書いたか分からないコードの調査に半日費やす。
- 影響範囲が怖くて、継ぎ足しの修正を行う。
- 単純なミスをレビューで指摘し合い、消耗する。
- 「私のPCでは動くんですけど…」という環境差異の調査に時間を取られる。
こうした負債を抱えたままリリースを迎えることこそが最大のリスクです。本質的な機能開発に全力を注ぐためにこそ、私たちは「人が頑張らなくても品質が保たれる構造」を目指しました。
具体的に、私たちが取り組んだ「構造化」のアクションを紹介します。
1. 「好み」を排除し、IDE設定ごと配布する
まず着手したのは、コードの見た目と一貫性の担保です。
当初、コードレビューは私が一人ですべて担当していました。そこで私が最も意識したのは、「私の主観や好みで押し付けないこと」 です。
私の中に最初から完璧なルールブックがあったわけではありません。むしろ、メンバーのコードをレビューする中で、「この書き方は分かりやすい」「この構造は汎用性が高い」といった 「チーム内の良い実装」を拾い上げ、それを共通のルールとして採用していく（いいとこ取りをする） スタイルを取りました。
そして重要なのは、それを「口頭のルール」で終わらせず、「開発環境（IDE）の設定」として配布したことです。
-
EditorConfigの完全統一:
.editorconfigをリポジトリに含めるだけでなく、Visual Studioの「コードクリーンアップ」設定もエクスポートしてチームに配布しました。 - 拡張機能の標準化: 「Namespaceの自動修正」や「インデントの可視化」など、開発体験を向上させる拡張機能をリスト化し、全員が同じ環境でコーディングできるようにしました。
これにより、「保存すれば勝手に綺麗になる」状態が作れました。可読性を「個人のセンス」から「ツールの機能」へ移行したことで、レビューのノイズが排除され、本質的な議論に時間を使えるようになりました。
2. 暗黙知を「プロンプト」に変えてAIと協業する
次に大きかったのが、レビュー観点の言語化です。
「なんとなく良くないコード」を言語化するのは難しい作業ですが、私たちは過去のレビュー指摘を分析し、「なぜこのコードがNGなのか」を明文化しました。そして、それをAI（LLM）へのプロンプトとして活用することにしました。
- Before: レビュアーが「タイポ」や「よくある書き間違い」を目視で探し、1つのPRに30分〜1時間かけていた。
- After: 明文化された観点を元にAIが一次レビューを行い、単純なミスは事前に潰す。
さらに、この観点には「セキュリティ」や「パフォーマンス」だけでなく、「アーキテクチャ方針への準拠」も含めました。
これにより、人間が行うレビューは劇的に効率化されました。毎回指摘していたような定型的なコメントはなくなり、「ビジネスロジックの正しさ」や「設計の妥当性」といった、人間しか判断できない領域に集中できるようになりました。
3. 明文化しすぎず、「対話」でアーキテクチャを揃える
コードの書き方（Style）はツールで強制しましたが、設計（Architecture）に関してはアプローチを変えました。
「Controllerはこれしかやってはいけない」「Serviceの責務はこれ」といった厳密なドキュメントを最初に作っても、新規開発のスピード感の中ではすぐに形骸化してしまいます。
そこで私たちは、ドキュメントでガチガチに固めるのではなく、「チーム内での認識合わせ（コンセンサス）」 を徹底しました。
レビューや日々の会話の中で、「この処理はServiceに移すべきだね」「Repositoryはデータアクセスだけに徹しよう」という会話を繰り返し、チーム全体で 「私たちのチームにおける正解の形」 というメンタルモデルを同期させていきました。
結果として、分厚い設計書がなくても、メンバー全員が「迷いなく同じような構成でコードが書ける」状態を作り出すことができました。これはドキュメントよりも強い、 「文化としての構造化」 です。
4. 「たすき掛け」開発でドメイン知識を深める
システム開発において、バグや手戻りの最大の原因は「仕様（ドメイン知識）の理解不足」です。
これを防ぐために、私たちは 「たすき掛け」のような担当割り当てを行いました。
例えば、「請求機能」と「入金機能」のように、データや業務フローが密接に関わっている機能があるとします。この時、一人が両方を担当するのではなく、あえて別のメンバーに担当してもらいました。
- メンバーA: 「請求」を担当（データを作る側）
- メンバーB: 「入金」を担当（データを使う側）
こうすることで、AさんとBさんは必然的に会話をする必要があります。「このデータはどういう状態で渡される？」「このフラグはどういう意味？」と連携し合うことで、単独で開発するよりも深く業務フローやデータの整合性を理解できるようになります。
コードレビューやドキュメントだけでなく、「開発体制そのもの」を工夫することで、属人化を防ぎ、相互理解を深める構造を作りました。
5. リリースと改善を「感覚」で語らない
開発だけでなく、リリースや運用改善にも構造を持ち込みました。
① リリースの安全性を構造化する
CI/CDがまだ完全に整っていないフェーズであっても、「気合でリリース」はしません。ブランチの運用ルール、マージ順序、そして手動デプロイの手順書を明確に定めました。「誰がやっても同じ手順でリリースできる」状態を作ることは、開発者の心理的な負担（壊すかもしれない恐怖）を大きく軽減します。
② 生産性を可視化する
また、「なんとなく遅れている」「最近調子がいい」といった感覚的な話を避けるため、PowerBI等を活用して生産性や進捗の可視化を行いました。
週次の振り返りでも、事実（データ）ベースで話をすることで、精神論ではない 「構造的な改善」 の議論ができる場を設けています。
最後に：品質は「人」ではなく「構造」で支える
振り返ってみると、私たちがやったことは 「未来の自分たちへの投資」 でした。
忙しい時こそ、「今はなんとか回っている」という状態が一番危うい。そこで立ち止まり、 「人が頑張らなくても回る仕組み（構造）」 を作れるかどうかが、チームの寿命、ひいては開発生産性を決めると感じています。
私たちは、こうした「技術的な構造作り」自体を楽しみ、課題解決に向けて議論できるエンジニアを求めています。もし、この記事を読んで「その課題、わかる！」「もっと良い方法があるよ」と思った方は、ぜひ一度お話ししませんか？
「整った環境」だけでなく、「環境を整える過程」も一緒に楽しめる仲間をお待ちしています。
【付録】私たちが定義した9つの品質基準とアクション
私たちが「なんとなく」ではなく、具体的にどのような観点で品質を定義し、対策を打ったかの全容です。
| 品質基準 | 実際にやったこと | ねらい（何を楽にしたか） |
|---|---|---|
| ① 可読性 | ・命名ルールをレビューで統一 ・EditorConfig + Code Cleanup 導入 ・過去レビューを元にしたAIレビュー |
他人のコードを「読んで理解する」コストを下げる |
| ② 一貫性 | ・PRは必ずレビュー（全件） ・書き方に迷ったらチームで決める ・レビュー観点をプロンプト化 |
人によって書き方が変わらない状態を作る |
| ③ 保守性 | ・例外スローの整理方針 ・ロジック肥大化の抑制 ・XMLコメント整備 |
修正時に「壊れる範囲」が読める |
| ④ テスタビリティ | ・単体テストを必ず実装 ・テストDB/カテゴリ整理 ・GitHub Actionsでビルド |
変更時の安心材料を用意する |
| ⑤ ドメイン理解性 | ・基本設計資料の共有 ・ER図の作成と展開 ・用語整理（請求/入金/支払など） |
コードと業務知識を結びつける |
| ⑥ 再現性 | ・環境構築手順の明文化 ・開発/コーディング手順書作成 ・拡張機能・ツールの統一 |
新メンバーでも同じ立ち上がりができるようにする |
| ⑦ 自動化可能性 | ・GitHub Actionsでビルド ・AIレビューの組み込み ・コード整形の自動化 |
人がやらなくていいことを減らす |
| ⑧ 安全性 | ・ブランチ運用ルール整理 ・マージ順の明確化 ・リリース手順の標準化 |
「壊さずに出す」確率を上げる |
| ⑨ 可視性 | ・PowerBIで生産性可視化 ・定例での振り返り ・納期/テスト整理 |
会議感覚ではなく事実で話す |
Discussion