乱雑なコードの整理から学ぶPjMの設計レビュー術：コード品質とチーム生産性を両立させる実践ガイド
お疲れ様です！IT業界で働くアライグマです！
プロジェクトが長く続くほど、「最初に書いたコードがそのまま残り続ける」「誰も触りたがらないモジュールが増えていく」といった悩みを、PjM仲間からよく聞きます。レビューのたびに担当エンジニアがため息をつき、仕様変更の相談をすると「そこは触るとまずいんですよね……」という空気になるような状態です。
私自身も、複数の開発チームを見てきた中で、技術的負債そのものよりも、「コードが散らかっているせいでレビューの議論が浅くなる」「設計の意図が読めずに議論が進まない」ことが、チーム生産性を大きく削っていると感じてきました。一方で、PjMがレビューに関わると言っても、細かい実装を隅々まで読むのは現実的ではありません。
そこで本記事では、乱雑なコードの整理プロセスをテコにして、PjMが設計レビューの質とチームの生産性を同時に高めていくための実践的なフレームワークを紹介します。単なるリファクタリングのテクニックではなく、「どこから整理を始めるか」「レビューの場で何を確認するか」「整理の成果をどうチーム全体に展開するか」といった観点から整理していきます。
なぜ乱雑なコードはレビューとチーム生産性を同時にむしばむのか
レビューの論点が「バグ探し」に偏ってしまう構造
まず押さえておきたいのは、コードが乱雑な状態だと、レビューの論点がどうしても「目に見えるバグ探し」や「コーディングスタイルの指摘」に偏ってしまうということです。
私が関わったあるチームでは、長年メンテナンスしてきたモノリシックなバックエンドがあり、レビューのたびに次のようなやり取りが繰り返されていました。
- ネストが深すぎて処理の意図が追えない
- 似たような条件分岐がファイルのあちこちに散らばっている
- 変数名に一貫性がなく、レビューコメントが命名批評で埋まってしまう
この状態では、「そもそもこのロジックは本当に必要か」「この設計は将来の拡張に耐えられるか」といった本質的な議論にたどり着く前に、レビュー時間が尽きてしまいます。結果として、レビューは「とりあえず動けばOK」に近いチェックになり、技術的負債が雪だるま式に増えていきました。
PjMがコードレビューから遠ざかると、設計の前提が共有されない
もう1つの問題は、コードが読みづらい状態だと、PjM自身がレビューの場から心理的に距離を取ってしまうことです。「ソースコードは詳しくないので任せます」と言い続けていると、やがて
- 仕様変更の背景と実装のトレードオフが、開発チーム内だけで閉じる
- 設計上の判断がプロダクトの方向性とズレていても、早期に気付きにくくなる
- 障害や品質問題が発生したとき、PjMが十分に状況を説明できない
といった状態に陥りがちです。
私の案件でも、最初は「コードの話はエンジニアに任せる」というスタンスで進めていましたが、ある障害対応で「この設計なら、そもそもこの種の障害が起きやすくなるのでは？」と感じたことをきっかけに、設計レビューの場にPjMとして積極的に参加するようにしました。そこで痛感したのは、「乱雑なコードを整理するプロセス」自体が、設計の前提や判断基準を言語化する絶好のチャンスになるということです。
乱雑さを「片付けプロジェクト」に変えると議論の質が変わる
こうした経験から、私は乱雑なコードをただ嘆くのではなく、
- どの領域から整理を始めるかをチームで合意する
- 整理のゴール（例：依存関係の見える化、責務の分割）を明文化する
- 整理の前後でどの指標がどう変わるかを簡単なメトリクスで追う
という「片付けプロジェクト」として扱うようにしました。PjMがここまでの枠組みを用意すると、レビューの場での会話も「このPRは片付けゴールに近づいているか？」という視点に揃いやすくなります。こうした「どこまでコードに踏み込むべきか」という迷いは、プロダクトマネージャーのための技術理解術：非エンジニアが開発チームと効果的に協働する実践手法でも触れているように、PjM自身が技術的な前提を言語化できていないことに起因するケースも少なくありません。エッセンシャル思考のような思考法の書籍を読みながら、「このプロジェクトで本当に守りたいものは何か」を先に決めておくと、設計レビューに参加するときの軸を持ちやすくなります。
「片付け対象コード」をデータと現場感覚で洗い出す
障害・変更履歴から「痛みの大きい箇所」を特定する
ここからは、具体的にどのようなステップで「片付け対象コード」を洗い出していくかを整理します。
私がPjMとしてまず行ったのは、感覚ではなくデータに基づいて「つまずきポイント」を可視化することでした。具体的には、次のような情報を1枚のスプレッドシートにまとめます。
- 直近3〜6カ月の本番障害チケットと、その原因となったモジュール名
- Gitの履歴から、頻繁に変更されているファイルとその担当者
- レビューで毎回指摘が多くなるファイルやディレクトリ
これをプロダクトバックログとは別の「コード片付けバックログ」として整理し、「どこから手を付けると投資対効果が高いか」をチームで議論しました。障害対応の観点については、GitHub Copilotでチームの生産性が低下する？PjMが明かす本当の導入判断と社内統制で触れているように、「誰がどこに時間を使っているか」を見える化してから議論することが重要です。リファクタリング(第2版)のようなリファクタリング本を参照しつつ、「安全に手を入れられる領域」と「今は触らないほうがよい領域」を切り分けていきました。
設計の意図が追えないコードを優先度高めに扱う
ただし、「障害が多い」「変更頻度が高い」という定量指標だけで優先度を決めると、短期的な火消しだけに終始しがちです。そこで私は、レビュー担当のリードエンジニアに次のような観点でヒアリングを行いました。
- 設計の意図がコメントやドキュメントから読み取れない箇所
- 仕様変更のたびに同じ説明を繰り返しているモジュール
- 新メンバーに引き継ぐときに必ず苦戦する箇所
これらは数字には表れにくいものの、実はチーム生産性を大きく削る要因です。私は、障害・変更履歴とこうした定性的な情報を組み合わせ、「技術的負債のホットスポットマップ」を作りました。マップを使って優先順位を決めると、議論が「誰の好みか」ではなく「チームとしてどこが痛いか」に基づくものになり、合意形成がスムーズになります。
片付け前後のインパクトを簡単なグラフで共有する
片付けの取り組みを継続するには、「やって終わり」ではなく、成果を見える形で共有することが欠かせません。そこで私は、設計レビュー導入前後の本番障害件数を簡単な棒グラフにまとめ、月次のふりかえりで共有するようにしました。
グラフでは、導入前・導入3カ月後・導入1年後の3時点で本番障害件数の推移を比較しました。数字そのものよりも、「片付けと設計レビューの投資が、確かにチームの痛みを減らしている」というストーリーを共有できたことが大きなポイントです。この可視化により、経営層や他チームからの理解も得やすくなり、継続的な投資の合意形成が進みました。
小さなリファクタリング単位に分解して設計レビューの土台を作る
「30分でレビューできるサイズ」に分割する
片付け対象コードが見えてきたら、次は「どの粒度で手を入れるか」を決める番です。一度に大きなリファクタリングを行うと、レビューする側もされる側も消耗してしまい、結局着手できないまま終わることが少なくありません。
私のチームでは、「1本のPRは30分以内にレビューできるサイズにする」というルールを置きました。具体的には、
- 責務の分割や関数抽出など、スコープの明確なリファクタリングだけを1PRにまとめる
- ビジネスロジックの変更と同時に大規模なリファクタリングをしない
- リファクタリングPRには、変更前後で確認すべき観点を簡潔に書き添える
といったルールです。こうすることで、設計レビューの場が「巨大な差分と格闘する時間」から「設計意図とコードの対応関係を確認する時間」に変わっていきました。ソフトウェアアーキテクチャの基礎を参考にしながら、どのレイヤーの責務をどこまで分割するかをチームで合意しておくと、レビューのコメントも揃いやすくなります。
既存テストと観点リストを組み合わせて安全網を張る
リファクタリングを進めるうえで避けて通れないのが、「どこまでテストを書くか」という議論です。私が関わったプロジェクトでは、すべてのレガシーコードに完全なテストを用意するのは現実的ではありませんでした。
そこで、次のような折衷案を取りました。
- 重要なユースケースだけでもシナリオテストを用意する
- テストがない部分は、レビュー時の観点リスト（想定入力・境界値・例外パス）を必ず残す
- リファクタリングで壊しやすいポイント（グローバル変数依存など）を事前に洗い出す
観点リストの作り方については、プロダクトマネージャーのための技術理解術：非エンジニアが開発チームと効果的に協働する実践手法で紹介した「PjMが確認すべき技術的前提」をそのまま活用しました。PjMが「どこを壊したくないか」の前提を共有しておくことで、エンジニア側もリファクタリングの優先順位を付けやすくなります。古典的な良書を土台に、チーム独自の観点リストを育てていくイメージです。
設計レビュー会議を「観点リスト」で回す
レビュー会議の目的を「設計の意思決定」に限定する
次に、設計レビュー会議そのものの設計です。乱雑なコードが多いチームでは、レビュー会議が「愚痴と細かな指摘の場」になりがちで、参加者のモチベーションが下がっていきます。
私がPjMとして最初に変えたのは、レビュー会議の目的を「設計の意思決定」に限定することでした。具体的には、次のようなルールを設けました。
- 会議ではコードの細部ではなく、モジュール分割・責務・依存関係の妥当性だけを扱う
- 命名やフォーマットの指摘は、Lintや別のレビューコメントで処理する
- 決めるべき論点を事前に整理し、会議冒頭で共有する
このやり方は、開発チームの技術選定プロセスで紹介している「論点ベースの会議設計」とほぼ同じです。設計レビューも、技術選定も、「どの選択肢を採用し、何を捨てるか」を決める場だと考えると、PjMがファシリテーターとして関われる余地がぐっと広がります。チーム・ジャーニーを読み込みながら、会議体ごとの目的とアウトプットを整理しておくと、レビューの時間がチームにとって価値あるものになっていきました。
観点リストとチェックボックスでレビューを標準化する
設計レビューの質を安定させるために、私は「観点リスト＋チェックボックス」のテンプレートを用意しました。各レビュー対象ごとに、次のような項目をチェックしていきます。
- このモジュールの責務は1〜2文で説明できるか
- 依存関係は一方向に保たれているか（循環参照がないか）
- 将来の拡張ポイントと制約条件がコメントやドキュメントに明示されているか
テンプレートは、最初は簡素なもので構いませんが、レビューを重ねるたびに少しずつ改善していくことが重要です。私は、レビュー後に出た気付きや追加したい観点をまとめておき、月次のふりかえりでテンプレートをアップデートする運用にしました。こうした標準化の取り組みは、「プラットフォームチーム」と呼ばれる役割に近く、PjMが中心となって整えていくことで、開発チーム全体の負荷を下げられます。
片付けの成果をナレッジ化し、再発防止ルールに落とし込む
ビフォー・アフターの具体例を「設計カタログ」として残す
乱雑なコードの片付けは、一度きりのイベントではありません。同じようなパターンの負債が再び生まれないようにするには、「良い改善事例」をカタログとして蓄積することが有効でした。
私のチームでは、次のようなフォーマットで「設計カタログ」を社内Wikiにまとめました。
- Before：改善前のコードと、そこで起きていた具体的な問題（障害・レビュー指摘・変更しづらさ）
- After：改善後のコードと、責務分割や依存関係の変化
- 効果：本番障害件数・レビュー時間・オンボーディング期間など、数値で見えた変化
このカタログは、オンボーディング資料としても非常に役立ちました。新しく入ったメンバーに対して、「このチームでは、こういうコードの書き方を良しとし、こういう状態は改善対象とみなす」という基準を、言葉だけでなく実例で共有できるからです。ナレッジベースの構築方法については、セルフホスト型ナレッジベース構築術：チーム情報共有を3倍効率化するツール選定と運用設計で紹介した考え方をそのまま応用しました。モレスキン クラシックノート ドット方眼 ラージのようなアナログノートも併用しつつ、「気付き → 実験 → 定着」のサイクルを回していくイメージです。
再発防止ルールは「守れる最小限」にとどめる
もう1つ重要なのが、再発防止ルールを欲張りすぎないことです。乱雑なコードを見た直後は、「二度とこうならないように全部ルール化しよう」と考えたくなりますが、現実には守りきれないルールが増えるだけになりがちです。
そこで私は、「絶対に守りたいルール」を3〜5個に絞り、それ以外は観点リストやチェックリストに落とし込むようにしました。例えば、
- ビジネスロジックとI/O処理を同じクラス・関数に書かない
- 循環依存が発生した場合は必ずレビューで議題に上げる
- 新しく追加する機能には、少なくとも1つのテストと簡単な設計メモを残す
といった具合です。ルールの数を絞ることで、開発チームも「これは本当に守るべき基準なんだな」と認識しやすくなりますし、PjMとしてもレビューの場で自信を持って指摘できるようになります。
設計レビュー文化を育てるためのチーム運営の工夫
「片付けタイム」をスプリントに組み込む
最後のコンテンツセクションでは、設計レビュー文化を継続的に育てるためのチーム運営の工夫をまとめます。
私が導入して効果を感じたのが、スプリント計画時に「片付けタイム」をあらかじめ時間枠として確保するやり方です。具体的には、
- 各スプリントのキャパシティのうち、10〜15% を技術的負債の返済と設計レビュー改善に充てる
- 片付けタスクは通常のユーザーストーリーと同じバックログ上で管理する
- スプリントレビューで、片付け前後の差分や学びを簡単に共有する
というルールです。これにより、「片付けは時間が余ったらやるもの」ではなく、「プロダクト価値を高めるための投資」として位置づけることができました。Time Timer MOD 60分 視覚タイマーのようなタイマーを使って短時間の集中セッションを設けると、開発者にとっても取り組みやすくなります。
PjM自身が「コードに近い言葉」で会話する
最後に、PjMとして強く意識しているポイントが1つあります。それは、「コードそのものを書かなくても、設計の話をコードに近い言葉でできるようにしておく」ということです。
私は、開発環境のパフォーマンスチューニング：IDEとツールの最適化で作業効率を向上させる手法のプロジェクトでも、実際のエディタ設定やツールチェーンに触れながら議論することで、エンジニアとの距離がぐっと縮まる感覚を得ました。設計レビューでも同じで、「ここは責務が多すぎるのでクラスを分けませんか」「この依存関係は逆向きにしたほうが安全そうですね」といった会話ができるだけで、議論の質は大きく変わります。
もちろん、すべての詳細を理解する必要はありませんが、チームが使っている言葉や概念にPjMが寄り添うことで、設計レビューは「エンジニアだけの黒箱会議」から「プロダクト全体の方向性を確認する場」へと変わっていきます。組織設計に関する書籍や事例も参考にしながら、チームの構造とコード構造を揃えていく意識を持つと、設計レビュー文化はより根付きやすくなります。短時間のレビューセッションを定期的に設けることで、PjM自身も無理なく関わり続けやすくなります。
まとめ
本記事では、乱雑なコードの整理をきっかけに、PjMが設計レビューの質とチーム生産性を同時に高めていくための実践的なアプローチを整理しました。
まず、「なぜ乱雑なコードがレビューと生産性をむしばむのか」を確認し、レビューの論点がバグ探しに偏ってしまう構造や、PjMがコードレビューから遠ざかることで設計の前提共有が進まなくなるリスクを見てきました。そのうえで、障害・変更履歴と現場の違和感を組み合わせて「片付け対象コード」を洗い出し、グラフで成果を可視化することで、投資対効果をチーム全体に共有できることを示しました。
次に、リファクタリングを「30分でレビューできる単位」に分解し、既存テストと観点リストを組み合わせて安全網を張る方法を紹介しました。また、設計レビュー会議を「設計の意思決定」に集中させ、観点リストとチェックボックスでレビューを標準化することで、議論の質と再現性を高める工夫についても触れました。
さらに、片付けの成果をビフォー・アフターの具体例としてナレッジ化し、再発防止ルールを「守れる最小限」に絞ることで、現場に根付くガイドラインとして運用できることを確認しました。最後に、スプリントに「片付けタイム」を組み込みつつ、PjM自身がコードに近い言葉で会話することで、設計レビュー文化をチーム全体で育てていく重要性を整理しました。
乱雑なコードは、見て見ぬふりをすればするほど、レビューとチーム生産性の両方を静かにむしばみ続けます。一方で、片付けのプロセスをうまく設計すれば、設計レビューの質を高め、チームが同じ方向を向いて開発できる強力な土台にもなります。あなたのチームでも、まずは1つのモジュールからで構いません。小さな片付けと設計レビューの工夫を積み重ねながら、「コード品質とチーム生産性を両立させる」文化を育てていっていただければ嬉しいです。