AI時代のエンジニアリング / 約25分

設計の妥当性を判断するフレームワーク

なぜこれを学ぶか

AIは「もっともらしい設計」をいくらでも生成します。しかし「このプロダクトの、このフェーズで、妥当か」の判断にはコンテキストが必要です。

設計判断の軸: 変化の速さ（この部分は将来どれくらい変わるか）、失敗のコスト（壊れたら何が失われるか）、チームのスキル（その技術を維持できるか）。

例: マイクロサービスは大規模組織には有効ですが、3人のスタートアップには過剰設計です。「Netflixがやっているから」は判断根拠になりません。規模と課題が違う からです。

トレードオフの言語化 が判断の核心です: 「案Aは実装が速いが拡張に弱い。案Bは拡張に強いが初期コストが高い。我々は3ヶ月で市場検証したいので案Aを選び、拡張が必要になったらBに移行する」

判断を記録する文化: ADR（Architecture Decision Records） に「なぜそう決めたか」を残すと、未来のチーム（とAI）が過去の文脈を理解できます。

重要ポイント

判断の軸: 変化の速さ・失敗のコスト・チームのスキル
「大企業がやっているから」は根拠にならない
トレードオフを言語化し、ADRに記録する

理解度チェック

選ぶと即座に解説が表示されます。

設計レビューで「この設計は妥当か？」を問われた。最も適切な評価方法は？

ヒントを見る

「妥当性」とは「一般的な正しさ」ではなく「このプロジェクトのコンテキストへの適合度」です。コンテキストを知らない相手（一般論・他社事例・AI）に答えを求めても核心的な評価にはなりません。

コーディング演習実際に書く

設計のトレードオフを定量化する練習です。2つの設計案のスコアを計算して推薦案を返す関数を書いてください。各案は { name, speed: 実装の速さ(1-10), extensibility: 拡張性(1-10) }。重要度は weights = { speed, extensibility } で与えられ、スコア = speed×w.speed + extensibility×w.extensibility。スコアが高い方のnameを返し、同点なら "どちらでも" を返します。

function recommendDesign(a, b, weights)

模範解答（読んで理解したら、自力で書き直してみましょう）

function recommendDesign(a, b, weights) {
  const scoreA = a.speed * weights.speed + a.extensibility * weights.extensibility
  const scoreB = b.speed * weights.speed + b.extensibility * weights.extensibility
  if (scoreA > scoreB) return a.name
  if (scoreB > scoreA) return b.name
  return 'どちらでも'
}

スキルセルフチェック

このレッスンの内容をどの程度理解できましたか？

弱点マップで全体を確認する

前のレッスン次のレッスン