コンテンツにスキップ

Decision Quality と設計判断失敗パターン

チェック

  • [ ] 本文を確認した
  • [ ] 概要を確認した
  • [ ] タグを確認した
  • [ ] inbox/ 直下へ移行した

概要

Decision Qualityの6要素を、ソフトウェア設計判断の失敗パターンへ接続する整理。 設計判断の失敗は、FrameとValues、特に「いま何を支配軸にすべきか」の取り違えとして説明できる。 AIコーディング時代には、ベテランの暗黙知で抑えられていた判断ミスが増幅されるため、失敗パターンを言語化してレビューやプロンプトに組み込む必要がある。

本文

Decision Qualityの6要素

Decision Qualityは、良い意思決定の条件を6つに分ける。

  • Frame: 解くべき問題の枠組み
  • Alternatives: 選択肢
  • Information: 情報
  • Values: 評価基準
  • Sound Reasoning: 論理的推論
  • Commitment to Action: 実行へのコミット

中心的な主張は、意思決定全体の質は一番弱い要素で決まるというもの。 また、意思決定そのものの質と結果は区別する。 良い意思決定でも結果が悪いことはあるし、悪い意思決定でもたまたま結果が良いことはある。

設計判断への読み替え

記事では、設計判断の失敗の多くをFrameとValuesの取り違えで説明する。 Valuesは設計判断の評価軸として整理し、Frameの取り違えは「支配軸の取り違え」として扱う。

設計判断で使う評価軸は次の8つ。

  • 目的適合性
  • 制約適合性
  • 実現可能性
  • 品質影響
  • 時間効果
  • リスク・不確実性
  • 整合性
  • 合意可能性

支配軸は、いまの判断で最も重視すべき評価軸。 二次条件は、支配軸ほど重くないが最低水準を満たすべき軸。

例:

  • 障害対応なのに長期的な理想設計を始める
  • 基幹刷新なのに短期実装容易性だけで選ぶ
  • セキュリティ問題なのにUXだけで判断する
  • PoCなのに本番運用品質を要求する
  • 本番機能なのにPoCの速度感で作る

代表的な失敗パターン

車輪の再発明

標準解があるのに独自実装へ逸脱する。

例:

  • 標準の認証ライブラリを使わず独自トークン認証を作る
  • Spring Securityで足りるのにFilterとThreadLocalで独自認可にする
  • DB制約で表せるものをアプリ側のif文に押し込む
  • HTTPステータスコードを使わず常に200で独自エラーコードを返す

AIは「動く」コードを書くが、「普通これは自作しない」という判断は出しにくい。

牛刀をもって鶏を割く

問題の規模に対して過剰な構成を選ぶ。

例:

  • 社内30人向け管理画面を最初からマイクロサービス4分割にする
  • 4状態しかない申請フローにイベントソーシングを入れる
  • 日次500件のCSV取込にKafkaを組む
  • 単純な入力チェックにルールエンジンを採用する

AIは一般的に見栄えのよいベストプラクティスへ寄りやすい。 文脈上の十分性を人間が指定する必要がある。

身の丈に合わない設計

技術的には望ましい構成だが、組織のスキル、人員、オンコール体制を見ていない。

例:

  • 24時間オンコールがないチームにマルチリージョン構成を採用する
  • KubernetesやKafkaの運用経験者がいないのに本番採用する
  • DBAがいないのに複雑なシャーディングを入れる
  • SREがいないのにSLOやエラーバジェットを掲げる

エージェントは組織のスキル分布を知らない。 プロンプトに運用チームのスキル前提を書かないと、望ましい構成だけを出しやすい。

羹に懲りて膾を吹く

過去の失敗を恐れて、技術的に劣る選択へ過度に寄る。

例:

  • JavaのLambda / Stream APIを読めない人がいるとして禁止する
  • Optionalを禁止し、戻り値のnull判定を呼び出し側へ押し出す
  • TypeScriptを導入できる場面でもJavaScriptで書き続ける
  • CIを「誰も保守できない」と退け、手動リリースを残す

保守容易性や現場が回ることが、下方迎合の言い訳として機能することがある。

場当たり対応

短期的にコードが通るため、判断の手前で止まらない。

例:

  • エラーを握りつぶして画面だけ進める
  • 既存の責務分離を無視してControllerにロジックを追加する
  • ドメインルールを画面側だけでチェックする
  • テストが落ちるので期待値を実装に合わせる

障害一次対応なら許されるが、適用時刻、差し戻し条件、恒久対応チケットを残す必要がある。

早合点

コマンドが通った、テストが緑、200が返った、を目的達成と混同する。

例:

  • HTTP 200なので成功と判断するが副作用が発生していない
  • バッチが完走したが対象0件で何もしていない
  • マイグレーションがエラーなく終わったが対象テーブルが存在せずスキップされている

エージェントは戻り値や終了コードを成功条件と等価に扱いやすい。 業務的な成立条件を明示して検証する必要がある。

要点

  • 設計判断の失敗は、支配軸の取り違えとして捉えるとレビューしやすい。
  • AIは代替案やメリデメを出せるが、自分が失敗パターンに入っていることは自覚しない。
  • プロンプトやレビューでは、目的、制約、運用組織、受け入れ条件、判断軸を明示する必要がある。
  • 「動くか」ではなく「この文脈で十分か」「どの軸を優先しているか」を問う。

タグ

decision-quality #architecture #design-review #ai-coding #software-design #judgment