Day3まとめ
概要
- 日程: Day 3 / セッション11
- 時間: 16:20-16:30
- 形式: 座学
- ゴール: 本日学んだ設計思想・アーキテクチャの中から、開発テーマに使うものを1つ選んで理由とともに言える
- 学習形式: 対話型解説
導入(5分)
🗣️ 要約
今日の内容は「全部覚える」ことではなく「開発テーマにどの考え方を使うか選べる」ことがゴール 前回(開発手法が複数ある理由)の視点を、設計思想全体に広げて振り返る
今日は朝から、たくさんの「〜アーキテクチャ」「〜駆動」「〜指向」という言葉が出てきました。正直なところ、名前を覚えるだけで一日が終わりそうになった人もいるのではないでしょうか。
でも、今日のゴールは「全部覚えること」ではありません。「自分たちの開発テーマに、どの考え方を使うか選べるようになること」です。このセッションが終わる頃には、今日出てきた選択肢の中から1つを選び、理由とともに言えるようになっています。
前回(セッション10)は、開発手法が複数ある理由を考察しました。今回はその視点をもう一段広げて、設計思想全体を振り返ります。
本編(5分)
🗣️ 要約
今日学んだ内容は「情報をどう捉え、構造化し、動かし、保存し、届けるか」という1本の線でつながっている 設計アプローチ→デザインパターン→多層アーキテクチャ→永続化→UIと機能の通信→実行方式→開発手法という順で振り返る
1. 今日歩いてきた道を振り返る
🗣️ 要約
今日の内容は料理のたとえで整理できる:食材の仕入れ(設計アプローチ)→調理の型(デザインパターン)→キッチンの役割分担(多層アーキテクチャ)→保存方法(永続化)→注文の受け渡し(UIと機能の通信)→厨房選び(実行方式)→チーム作業(開発手法) どの要素が欠けてもソフトウェアは完成しない
今日学んだ内容は、実はバラバラな知識の寄せ集めではありません。「情報をどう捉え、どう構造化し、どう動かし、どう保存し、どう届けるか」という1本の線でつながっています。
たとえば料理に例えると、こういう流れです。
- 食材をどう仕入れるか(設計アプローチ:POA/DOA/MDA/SOA/ROA/OOAD)
- よく使う調理の型を使い回す(デザインパターン)
- キッチンの役割分担(多層アーキテクチャ:3層・MVC・MVVM・DDD)
- 食材の保存方法(永続化:RDB・KVS)
- 注文の受け渡し方(UIと機能の通信:REST/SOAP)
- どの厨房で作るか(実行方式:ネイティブ/Web/クラウド)
- チームでどう作業を進めるか(開発手法:ウォーターフォール/アジャイル)
どれか1つが欠けても、料理(ソフトウェア)は完成しません。ここまでで、今日学んだ内容が1つのつながりだったとイメージできましたか? ピンとこない部分があれば、AIに「今日出てきた用語を、料理の例えでもう一度整理して」と聞いてみましょう。
ここがポイント
- 特に注意してほしいのは、これらは「優劣」ではなく「使い分け」だという点です
- よくある誤解として「アジャイルの方が新しいから常に正しい」と思い込むケースがありますが、正しくは「開発テーマの不確実性・チーム規模・納期によって適切な手法は変わる」です
コラム
建築の世界では「様式(スタイル)」という言葉があります。ゴシック様式、モダニズム様式など、時代や目的によって使われる様式が変わりますが、どれが正しいということはなく「その建物が何のために建てられたか」で選ばれます。ソフトウェアアーキテクチャも実は同じで、MVCやDDDといった「様式」は、建築様式と同じくらい歴史と哲学を背負った選択肢なのです。今日皆さんが名前を覚えた用語の1つ1つに、それを考え出した人たちの「こうすればうまくいく」という試行錯誤の歴史が詰まっています。
💬 AIに聞いてみよう
🗣️ 要約
自分たちの開発テーマにMVCとMVVMどちらが向いているか、DOAとOOADの違い、実務での設計思想の決め方などをAIに質問できる
ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば:
- 「うちの開発テーマなら、MVCとMVVMどちらが向いている?」
- 「DOAとOOADの違いをもう一度、身近な例で説明して」
- 「実務では設計思想はどうやって決めているの?」
まとめ(5分)
🗣️ 要約
設計思想やアーキテクチャは、開発テーマの目的に合わせて選ぶ道具箱である 今日1つ、開発テーマに使う設計思想・アーキテクチャを選び理由を言えるようにする 次回Day4はいよいよ実装に入り、今日選んだ設計思想が指針になる
今回学んだことを一言でまとめると、「設計思想やアーキテクチャは、開発テーマの目的に合わせて選ぶ道具箱である」ということです。
- 今日1つ、開発テーマに使う設計思想・アーキテクチャを選び、理由をチームで言えるようにしておきましょう
- 次回(Day4)はいよいよ実装に入ります。今日選んだ設計思想が、明日の実装の指針になります。しっかり選んでおきましょう
🔄 振り返りチェック
🗣️ 要約
開発テーマに使う設計思想・アーキテクチャを1つ選び、その理由を説明できるか 3層アーキテクチャとMVCの対応関係を説明できるか
以下の問いに答えられるか確認してみましょう:
- 開発テーマに使う設計思想・アーキテクチャを1つ選び、その理由を説明できますか?
- 3層アーキテクチャとMVCの対応関係を説明できますか?
答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。
補足資料
🗣️ 要約
参考リンクは特になく、必要に応じて各自AIに検索してもらう 発展課題は、選んだ設計思想と別の設計思想で実装がどう変わるかをチームで比較すること
- 参考リンク: なし(社内資料のみで完結する内容のため、外部リンクは各自の環境に応じてAIに検索してもらってください)
- 発展課題: 選んだ設計思想を採用した場合と、別の設計思想を採用した場合とで、実装がどう変わるかをチームで比較してみましょう
学習ガイド
🗣️ 要約
受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている
このセクションは、受講者が理解を深めることをサポートする参考情報です。
想定される質問と回答例
🗣️ 要約
唯一の正解はなく、開発テーマの規模・保守期間・チームの経験を踏まえ、まずは小さく始められるものを選ぶ 複数の設計思想を組み合わせてもよく、実務でも3層アーキテクチャ+MVC+DDDのような組み合わせが一般的
| 質問 | ヒント |
|---|---|
| 結局、うちのチームはどれを選べばいいですか? | 唯一の正解はない。開発テーマの規模・保守期間(Day2で考察した保守期間)・チームの経験を踏まえ、まずは小さく始められるものを選ぶとよい |
| 複数の設計思想を組み合わせてもいいですか? | よい。実務でも3層アーキテクチャ+MVC+DDDのように組み合わせるのが一般的 |
つまずきやすいポイント
🗣️ 要約
用語が多すぎて選べず決められなくなりやすい 今日の内容と昨日までの内容(情報モデル等)のつながりが見えにくい
| つまずきポイント | ヒント |
|---|---|
| 用語が多すぎて選べない・決められない | 「完璧な選択」を求めず、まず1つ仮決めして進めてよいと伝える。実装しながら見直せばよい |
| 今日学んだ内容と昨日までの内容(情報モデル等)のつながりが見えない | 「情報モデル(Day2)→多層アーキテクチャのModel層(Day3)」のように、対応関係を1つずつ言語化させる |