| 大分類 | 観点 | 注意事項 | 備考 |
| 設計整合性 | パターン網羅性 | 正常系・準正常系・異常系は仕様通り準備されているか。 | |
| モジュール設計方針 | 各モジュールが単一責務を担い、依存は明示されているか。 | SOLID原則 | |
| データ構造設計 | 引数・戻り値・構造体やDTOが目的に沿っているか | 設定等が細かく引数が多くなる場合には配列や構造体を渡す等も考慮例の一つ | |
| 外部依存設計 | 他モジュール・外部API・ライブラリの仕様変更に強い構造になっているか。 | インターフェース抽象化・依存注入（DI）を考慮 | |
| 保守性向上 | 冗長性 | 同一ロジックの重複を失くしているか。 | DRY原則 |
| 再利用性 | 共通化できる部分を共通化しているか。 | メンテコスト削減 | |
| 結合度 | 不必要な依存・参照を排除しているか。 | モジュール結合度が低い方が拡張性が高い | |
| 変数・定数管理 | 定数は意味のある名前で定義しているか。 | ||
| 変数のスコープは最小化しているか。 | ・グローバル乱用防止。 ・static等のクラス変数よりも関数内(スタック変数)の方がアクセスコストが小さい。 ・別々のスコープでの命名重複を避ける。 ・完全に使い捨ての定数は変数化しない。 ・環境に関係する設定は別ファイルへの切り出しも検討する。 | ||
| 最適な型を選択しているか。 | |||
| キャッシュ・再計算 | 再利用できる計算結果をキャッシュしているか。 | メモリと性能のバランス調整 | |
| 可読性向上 | コード構造 | モジュール・関数・クラス・条件分岐の構造が簡潔にしているか。 | ネスト過多を避け1関数1責務 |
| モジュール・関数・クラス・条件分岐の分割粒度は統一しているか。 | フォルダ構成や命名規則も統一する | ||
| 命名規則 | 一貫性・意図が分かる命名にしているか。 | 命名スタイルの統一（snake/camel/UPPER) | |
| コメント | 背景・意図・前提条件を明示しているか。 | コードから意図が分かるのが基本、コメントは補足用 | |
| 実装意図 | プログラム作成者だけの暗黙ルールを排除しているか。 | 属人化防止。例えば、単なる数値や文字列を関数で返す感じだと、他の設計書を見ないと何を実際に受け渡しているのか分からない。分かりやすい名前の構造体や変数を返したりする等で意図が分かるように工夫できる。 | |
| 統一性 | インデント(タブ・改行含む)・括弧・改行の使い方等の記述に一貫性を持たせる形にしているか。 | 静的解析ツールを使うのも手 | |
| 正確性・性能 | ロジック整合性 | 条件式・演算が仕様通りに動くようにしているか。 | 二重否定等の複雑条件を単純化しておく。 |
| 例外・エラーハンドリング | 例外発生時の挙動・再スロー・ログを適切な内容にしているか。 | 例外を握り潰さない | |
| エラー制御が必要な範囲を最小化しているか。 | |||
| 入力値検証 | 想定外・境界値・型異常を扱えるようにしているか。 | バリデーション必須 | |
| 資源管理 | ファイル・接続・メモリ等を確実に開放しているか。 | スコープ制御・finally／defer等の仕組みを意識。使用後オブジェクトの場合はnull代入等。 | |
| 並行性 | 排他・共有資源の整合性を保てるようにしているか。 | スレッド競合、デッドロック防止 | |
| パフォーマンス最適化 (ただし過剰最適化は可読性を損なうため禁止。プロファイリング実測に基づく判断を推奨。) |
ループや条件分岐に不要な処理を入れないようにしているか。 | 不要なループ処理には、例えばwhileやfor文内(括弧内の条件式含む)での計算やオブジェクト生成等が含まれる。外に出せる分はきちんと出すこと。 | |
| 計算結果・生成物を再利用できるようにしているか。 | 動的計画法に準じる。メモリ増加に注意する。 | ||
| 条件評価順序は早期終了等の短絡評価を意識しているか。 | 条件評価順序の工夫はif(条件A || 条件B)等の場合は条件A,条件Bのうち、falseになる確率が高い方を条件Aに書き、条件Bまで判定させないなど。 | ||
| 不要分岐や無駄な初期化を避けるようにしているか。 | ◾️不要な分岐を避ける例 ・到達不能・冗長なif文を作らない。 ・逆に全てのケースで共通的に実施する必要のない処理は、特定分岐内でのみ処理できるようにif文に入れる。 ◾️無駄な初期化を避ける例 各コンパイラでデフォルトで設定がサポートされているのに自前で初期化する等。 | ||
| 関数のインライン化を適切に行うようにしているか。 | ごく短い関数をインライン化してオーバーヘッド削減。 | ||
| セキュリティ | 入力検証 | 不正入力（SQLi/XSS等）に対する保護をしているか。 | サニタイズ・エスケープ必須 |
| 認証・認可 | ユーザー識別・権限制御を適正に実装しているか。 | ゼロトラスト意識。アクセストークンや認証範囲も確認しておきたい。 | |
| 機密情報 | パスワード・APIキー・トークンを平文で扱わないようにしているか。ハードコードしないようにしているか。 | 外部Secret管理を利用 | |
| ログ・例外 | 機密情報をログに出さないようにしているか。 | 出力内容・保存期間管理 | |
| 依存管理 | パッケージや外部依存の脆弱性を定期的に検査しているか。脆弱性の高いパッケージを使わないようにしているか。 | ||
| テスト容易性 | 独立性 | モジュールが独立テスト可能な構造にしているか。 | 副作用の少ない関数化 |
| 網羅性 | 主要処理経路(正常・準正常・異常系・境界値など)がテストできるようにしているか。 | 観点テスト | |
| 判定・分岐は仕様通りか、ループ処理の終了条件は仕様通りか | |||
| コードカバレッジは測定できているか | |||
| データ設計 | 通常値・異常値・境界値・大規模等のデータを準備しているか。 | 自動化しやすい形式 | |
| 妥当性 | 呼び出し処理のパラメータや戻り値に問題ないか | ||
| モック・スタブ | 外部依存を切り離せるようにしているか。 | API/I/Oの再現性保証 | |
| ファイル入出力 | ファイル操作(オープン・クローズ読み書き)は仕様通りか | ||
| DB | DBのCRUD処理は問題なく実施できるか | ||
| 排他制御やセッション管理は問題なく実施できるか | |||
| 自動連携 | CI/CDで実行可能な構成にしているか。 | 継続的品質検証 | |
| 運用性 | ロギング | 適切な粒度とレベル設定でログ出力しているか。 | WARN/ERRORの基準統一 |
| 監視・検知 | 実装内のメトリクス・ログが運用監視可能な形式にしているか。 | 異常検出容易性 | |
| リファクタリング | 定期的に設計・実装を見直す文化を保持しているか。 | 技術的負債抑制 |
