自分のテーマに合う設計アプローチを選ぶ

• 日程: Day 3 / セッション 2
• 時間: [9:30-10:15]
• 形式: 演習
• ゴール: 自分の開発テーマに対して（条件）設計アプローチを1つ以上選択し（行動）、選択理由と不採用理由をそれぞれ一文以上で記述できる（基準）
• 学習形式: AIディスカッション

前のセッションで、6つの設計アプローチを「どこを中心に据えるか」という軸で整理しました。
知識として並べただけでは、まだ「選べる」とは言えません。このセッションでは、自分の開発テーマに対して実際に選びます。

最初に大事なことを言い切ります。この演習に正解はありません。目的は正解探しではなく、根拠づくりです。

ここで少し考えてみてください。先輩に「なぜこの設計にしたの？」と聞かれたとき、「なんとなく」と「支出データの構造が最も変わりにくいからです」では、どちらがエンジニアとして信頼されるでしょうか？

設計の現場で問われるのは、選択そのものより選択の理由を言葉にできることです。
そして理由を鍛える最良の方法は、反対意見とぶつけることです。今日はAIに「あえて反対の立場」を演じてもらい、ディベートで自分の根拠を鍛えます。

アプローチ選びは、健康診断の問診のようなものです。次の3つの問いに答えると、候補が絞れます。

1. 何が一番変わりにくいか？ — 変わりにくいもの（多くはデータ）を中心に据える
2. 何が一番複雑か？ — 複雑さの正体（処理手順？データ構造？業務ルール？）に合ったアプローチを選ぶ
3. どう公開・連携するか？ — Web APIで公開するならROA、業務機能単位で連携するならSOAが視野に入る

たとえば「毎月のバッチ集計が主役で画面はほぼない」システムならPOAも候補に該当します。一方、「多数の画面から同じデータをCRUDする」システムにPOAは向きません。なぜなら、画面や手順が増えるたびに処理の複製が増え、データの整合が崩れやすくなるからです。

判断に迷ったら、この3つの問いをそのままAIに投げてみましょう。「私のテーマでは何が一番変わりにくいと思う？」という聞き方で十分です。

家計簿システムで通しの選択例を示します。皆さんは自分のテーマでこれと同じことをやります。

【家計簿システムの設計方針メモ（例）】

採用: ROA ＋ DOA
- 採用理由(DOA): 家計簿の中心は「支出・収入・費目」というデータであり、
  集計方法や画面は変わっても、この情報モデルの構造は最も変わりにくいから。
- 採用理由(ROA): Day2で抽出した機能はほぼ支出レコードのCRUDであり、
  リソース（/expenses等）にHTTPメソッドを対応させると設計がそのまま
  RESTful APIになり、Day4の実装（モックAPI＋UI）に直結するから。

不採用: POA
- 不採用理由: 「入力→集計→表示」という手順を中心に据えると、
  ペルソナの要望（例: 週次でも月次でも見たい）で手順が変わるたびに
  作り直しになるから。手順はこのシステムで最も変わりやすい部分。

不採用: SOA
- 不採用理由: 単独アプリで外部の業務システムと連携する予定がなく、
  サービス分割の恩恵よりも管理の手間が上回るから。

採用理由が「Day1-2の成果物（情報定義書・情報モデル・機能一覧）」に根ざしている点に注目してください。根拠は空から降ってきません。自分の成果物の中にあります。

• 「採用理由」と同じくらい「不採用理由」に価値がある。不採用理由を書けた人は、他の選択肢を検討した証拠になる
• 根拠は必ず自分の成果物（情報定義書・ペルソナ・情報モデル・機能一覧）と結びつける
• 複数採用（例: ROA＋DOA）は普通のこと。ただし「主軸」がどれかは決める

「ディベートで根拠を鍛える」は歴史ある学習法です。中世ヨーロッパの大学では「討論（disputatio）」が正式な授業形式で、学生はあえて自分の信じていない側を弁護させられました。反対側を本気で弁護してみて初めて、自分の主張の弱点が見えるからです。生成AIの登場で、この贅沢な学習法（専属の論敵）が誰でも使えるようになりました。しかもAIは何度負かしても機嫌を損ねません。

• 「私の開発テーマ◯◯で『最も変わりにくいもの』と『最も変わりやすいもの』は何だと思いますか？情報定義書を貼るので分析してください」
• 「DOAとOOADを両方採用すると矛盾しますか？実務ではどう共存させていますか？」
• 「私の不採用理由に説得力がないところを指摘してください」

以下の4ステップで「設計方針メモ」を作成します。時間配分の目安付きです。

ステップ1: 仮選択（5分）
本編の「3つの問い」に自分のテーマで答え、採用するアプローチを1つ以上、仮に選びます。Day1-2の成果物（情報定義書・ペルソナ・情報モデル・機能一覧）を手元に開いておきましょう。

ステップ2: AIディベート（15分）
AIに反対の立場を演じさせ、最低2ラウンド反論に応答します。次のプロンプトをコピペして使ってください（テーマとアプローチ名は自分のものに置き換える）。

私は家計簿システムに ROA＋DOA を採用しようと思います。
理由は「支出データの構造が最も変わりにくく、機能の大半がCRUDだから」です。

あなたは SOA を推す立場でディベートしてください。
ルール:
- 私の主張の弱点を具体的に突いてください
- 1回の反論は3点以内、各2文以内で
- 私が応答したら、さらに反論するか、認められる点は認めてください
- 3ラウンド終わったら、ディベートを中立の立場で総括し、
  私の根拠のうち「強かったもの」と「弱かったもの」を挙げてください

ディベート中に「たしかにそうかも」と思った反論は、メモしておきます。それはあなたの設計方針メモの「不採用理由」や「留意点」の材料になります。

ステップ3: 立場を替えてもう1本（5分）
今度は逆をやります。次のように、自分が不採用にしたアプローチをAIに擁護させるのではなく、自分が擁護してみます。

今度は立場を交換します。私が POA を擁護するので、
あなたは私の採用案（ROA＋DOA）を推す立場で反論してください。
最後に、私のPOA擁護に説得力があったか判定してください。

自分の不採用案を本気で擁護してみると、不採用理由が「食わず嫌い」だったのか「検討の結果」なのかがはっきりします。

ステップ4: 設計方針メモの清書（5分）
ディベートの結果を反映して、設計方針メモを清書します。

「設計方針メモ」（Day 3 成果物の一部。このあとのセッションでも参照し、Day 4 の実装の拠り所になります）

必須項目:

• 開発テーマ名
• 採用アプローチ（1つ以上、主軸を明記）
• 採用理由（各一文以上。自分の成果物への言及を含める）
• 不採用アプローチ（1つ以上）と不採用理由（各一文以上）
• ディベートで見つかった留意点（あれば）

• 理由が書けないときは、本編の「3つの問い」に戻る。特に「何が一番変わりにくいか」が最強の出発点
• 家計簿・レシピ・オークションのようなCRUD中心テーマは、DOA/ROAが有力候補になりやすい。ただし「みんなそうだから」は理由にならない。自分の情報モデルのどこがそれを示すのかを書く
• AIの反論が強すぎて心が折れそうなら、「反論のレベルを初心者向けに下げて」と頼んでよい。ディベートの難易度も自分で設計できる
• 選択を変えたくなったら変えてよい。「ディベートの結果、採用案を変更した」というメモは、むしろ高品質な根拠づくりの証拠

今回学んだことを一言でまとめると「設計アプローチの選択とは、正解を当てることではなく、自分の成果物に根ざした根拠を言葉にすることである」です。

• 3つの問い（変わりにくいもの・複雑さの正体・公開の仕方）で候補を絞った
• AIディベートで根拠を叩いて鍛えた
• 採用理由と不採用理由を設計方針メモに残した

休憩のあとのセッション3では、選んだアプローチを実装の形に落とすときの業界標準、**多層アーキテクチャ（3層・MVC・MVVM・DDD）**を学びます。Day 2 でやった「機能とプレゼンテーションの分離」が、実は業界標準そのものだったことが分かります。

• 自分の採用アプローチと、その理由を一文で言えますか？
• 不採用にしたアプローチについて、「なぜ不採用か」を一文で言えますか？
• AIの反論のうち、一番効いたものは何でしたか？それは設計方針メモに反映しましたか？

• 参考リンク:

  • 『Webを支える技術』（山本陽平）: ROA/RESTの考え方を日本語で学べる定番書
  • マーチン・ファウラー「Design Stamina Hypothesis」: 設計に投資する価値についての短い記事
• 発展課題:

  • 自分と違うテーマ（例: リアルタイムチャット、ゲーム）ではどのアプローチが有力になるか、AIと議論して「テーマとアプローチの相性表」を作ってみましょう
  • 自分の設計方針メモをAIに渡し、「新人エンジニアの設計レビュー役」として辛口レビューしてもらいましょう