カテゴリMからの接続と、この章の役割
カテゴリMでは、利用者や課題、必要な機能といった「何を作るか」を決めました。しかし、要件が決まっただけでは、まだ作り始められません。同じ要件でも、作り方は何通りもあるからです。カテゴリNは、その「どう作るか」を実装の前に決める章です。開発の流れでいえば、要件と実装のちょうど真ん中にあたります。実装そのものはAIが得意としますが、その手前の設計の判断は、人間が引き受ける仕事です。
このスライドのポイント
- カテゴリMで「何を作るか」（要件）が決まった
- カテゴリNは「どう作るか」を実装前に決める章
- 位置づけ: 要件（M章）→ 設計（N章）→ 実装（AIが担当）の真ん中
設計の定義と、6つの決定事項
設計とは、要件を満たす構造を決める活動です。決めることは、大きく6つあります。1つ目は部品、つまり何に分けるか。2つ目は責任、どの部品が何を担うかで、これはA-01で学んだ責任範囲の考え方です。3つ目は接続、部品どうしのやり取りで、K-02の契約にあたります。4つ目はデータ、何をどう保存するか。5つ目は例外、失敗したときの振る舞いです。6つ目は品質条件、M-06で扱った非機能の要求です。この6つを決めるのが設計です。
このスライドのポイント
- 設計＝要件（M章）を満たす構造を決める活動
- 6決定事項:
設計を飛ばすと何に失敗するか
なぜ設計が要るのでしょうか。設計を飛ばすと、要件からいきなりAIに実装を頼むことになります。すると、アプリの構造は、AIがその場その場で下した判断で決まってしまいます。作り始めのうちは、それでも動きます。問題は少し先に来ます。機能を足すたび、直すたびに、あちこちが壊れるアプリになっていくのです。これはバイブコーディングの中期的な最大のリスクです。最初に構造を決めておくことが、後の作り直しを防ぎます。
このスライドのポイント
- 設計を飛ばすと、要件から直接AIに実装させることになる
- するとアプリの構造が、AIの場当たりな判断で決まる
- 小さいうちは動くが、変更のたびに壊れるアプリになる
- これがバイブコーディングの中期的な最大のリスク
開発の3段と、人間とAIの分担線
もう少し全体像を見ます。開発は3段で進みます。まず要件をM章で固め、次に設計としてN章の6決定事項を埋め、最後に実装へ進みます。ここで思い出したいのが、A-04で引いた分担線です。実装、つまりコードを書くところはAIが得意です。一方、6つの事柄をどう決めるかという設計の判断は、人間が持ち続ける仕事でした。設計とは、人間がAIに渡す「作り方の指示」の土台になります。ここが弱いと、実装も揺らぎます。
このスライドのポイント
- 開発の3段: 要件（M章）→ 設計（N章：6決定事項）→ 実装
- 分担線: 実装はAIが得意、設計の判断は人間の仕事（A-04の再訪）
- 設計＝人間がAIに渡す「作り方の指示」の土台
経費精算アプリの「承認機能」で展開する
具体例で見ます。経費精算アプリの「承認機能」を作るとします。要件はたった1行、「上長が申請を承認できる」です。これを6決定事項へ展開します。部品は申請画面・承認画面・承認処理。責任は、承認の可否をサーバーが判定し、画面は表示と操作に徹します。接続は承認処理を呼ぶ窓口、データは誰がいつ承認したか、例外は二重承認への対処、品質条件は応答の速さです。1行の要件から、決めることが12個以上出てきます。この展開を人間が持つほど、AIの実装は安定します。
このスライドのポイント
- 題材: 経費精算アプリの「承認機能」。要件は1行「上長が申請を承認できる」
- 6決定事項に展開すると、決めることが12個以上に:
技術サンプル: 6決定事項の担当講義マップ
7枚目は、この章全体の地図です。設計の6決定事項は、それぞれ後の講義で深掘りします。部品のうち画面はN-02の画面設計で、データはN-03のデータ設計で、接続はN-04のAPI設計で、責任はN-05の責任分離とN-06で扱います。品質条件はN-09です。この講義は地図、以降が各地の詳細図だと考えてください。実装をAIに頼む前には、こう聞くと有効です。「この要件を実装する前に、6決定事項でまだ決まっていないものを列挙してください」。抜けを先に潰せます。
このスライドのポイント
- 種別: table ／ 目的: 6決定事項が本章N-02〜N-09のどこで深掘りされるかを示す地図
混同しやすい概念: 要件と設計
混同しやすいのが、要件と設計の違いです。要件は「何ができるべきか」を表します。たとえば「上長が承認できる」。一方の設計は「どういう構造で実現するか」です。判定をサーバーに持たせるのか、承認の記録をどう残すのか、といった作り方の中身にあたります。ここで大事なのは、要件が1つに定まっても、それを実現する設計は何通りもあり得る、ということです。だからこそ、どの構造を選ぶかという判断が必要になります。その判断が、人間の仕事です。
このスライドのポイント
- 混同しやすいのは「要件」と「設計」
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIに実装を頼む前に、こう指示する習慣をつけてください。「設計上の判断が必要な点を、先に質問してください」。これは、A-07で学んだ「AIに渡す情報の種類」を、設計の場面で実践したものです。AIは、指示がなければ構造を場当たりに決めてしまいます。だから、先に判断すべき点を洗い出させるのです。あわせて、6決定事項のうち空欄が残っていないかを、発注の前に自分で点検しましょう。空欄は、判断の先送りのサインです。
このスライドのポイント
- AIに実装を頼む前の口ぐせ: 「設計上の判断が必要な点を、先に質問してください」
- これはA-07「AIに渡す情報の種類」を、設計の場面で実践したもの
- AIは指示がなければ構造を場当たりに決めてしまう（スライド4の再確認）
- 6決定事項のうち空欄が残っていないかを、発注前に自分で点検する
一問一答とまとめ
一問一答です。設計の6決定事項は何でしょうか。（少し間をとります）答えは、部品・責任・接続・データ・例外・品質条件です。30秒でまとめます。設計とは要件を満たす構造を決める活動で、要件と実装のちょうど間に位置します。この6つを人間が先に決めるほど、AIの実装は安定します。次回のN-02では、部品にあたる「画面」を、1枚の設計書に落とし込む方法へ進みます。関連資料は「Webアプリ構成図入門」と「AI Builder 技術ロードマップ」です。
このスライドのポイント
- 一問一答: 設計の6決定事項は？
- 30秒まとめ: 設計＝要件と実装の間で6決定事項を決める活動
- 次回: N-02 画面設計
- 関連資料: 「Webアプリ構成図入門」「AI Builder 技術ロードマップ」
