📖 テーマ設定
🔊 音声設定
1.2
1.0
1.0
▶️ 再生コントロール
🎵 BGM設定
0.3
🔔 効果音設定
0.3

Day 3 イントロ・設計とは

概要

  • 日程: Day 3 / セッション 01
  • 時間: [9:00-9:30]
  • 形式: 座学
  • ゴール: 「設計とは何か」と「なぜ設計思想が複数存在するのか」を、Day 2の成果物を例に1分間で他者に説明できる
  • 学習形式: 対話型解説(AIに問いかけながら進行)

導入(5分)

Day 1で「誰に・何の価値を」を決め、Day 2で「何を作るか(情報モデル・状態遷移・機能・プレゼンテーション・モックアップ)」を定義しました。本日Day 3はいよいよ「どう作るか」のフェーズです。

ここで、ちょっと建築家の気持ちになってみましょう。家を建てる依頼を受け、「3人家族で、共働きで、犬を1匹飼っている」というお客様の要望(=Day 1, 2の成果物)を受け取りました。あなたが次にやるのは「壁の材料は何にするか」「水回りはどこに集めるか」「電気配線はどう走らせるか」を決めることです。これが「設計」です。

つまり、設計とは「制約のなかで、どう実現するかを決める意思決定の連続」です。

本編(20分)

1. 「設計」とは何か

設計を一言で言えば「つくり方を決定する活動」です。決めるべき項目は、おおむね次の4つに分かれます。

  • 構造: 何と何を組み合わせるか(モジュール分割、層の重ね方)
  • 振る舞い: いつ、何が、どう動くか(処理の流れ、状態遷移の実装方法)
  • インタフェース: 部品どうし、人とシステムの接点をどう決めるか
  • 制約への対処: 性能・保守性・セキュリティなど、見えにくい要件への作り込み

要件定義が「Why(なぜ作るか)」「What(何を作るか)」を決める活動だとすれば、設計は「How(どう作るか)」を決める活動です。

flowchart LR A["要件定義
(Why / What)"] --> B["設計
(How)"] B --> C["実装
(Do)"] C --> D["テスト
(Check)"]

ここがポイント

設計の正解は1つではありません。「同じ要件に対して、複数の正解が存在する」のが設計の本質です。だからこそエンジニアの腕の見せ所であり、面白いところです。

コラム

「設計(Design)」という言葉は、ラテン語の「designare(指し示す)」が語源です。「これからこうする」と未来を指し示す行為が設計の語源です。日本語の「設計」も「設けて計る」と書きます。「先に決めて、見積もる」というニュアンスです。コードを書き始める前に、未来の姿を頭の中で組み立てる作業、それが設計なのです。

2. なぜ「設計思想」が複数あるのか

世の中には DOA、MDA、SOA、ROA、OOAD、MVC、MVVM、DDD……など、聞いたことはあっても違いが分かりにくい用語がたくさん存在します。なぜこんなに種類があるのでしょうか。

答えはシンプルで、「時代ごとの主流の課題が違ったから」です。

flowchart LR Y1["1970s
処理が複雑"] --> Y2["1980s
データが複雑"] Y2 --> Y3["1990s
業務が複雑"] Y3 --> Y4["2000s
連携が複雑"] Y4 --> Y5["2010s〜
Webと変化が複雑"]
  • 1970年代: 計算処理が複雑だった → プロセス中心(POA)
  • 1980年代: 業務データが膨大になった → データ中心(DOA)
  • 1990年代: 業務そのものが複雑になった → オブジェクト指向(OOAD)
  • 2000年代: 企業間連携が必要になった → サービス指向(SOA)
  • 2010年代以降: Webスケールの変化に対応する必要が出てきた → リソース指向(ROA)

つまり、新しい設計思想が出てくるたびに「古いものが間違いだった」のではなく、「課題が変わったから、最適な答えも変わった」のです。これは料理のレシピと似ています。和食・中華・イタリアン、どれも正解で、食べたい人と材料に応じて選びます。

ここがポイント

「最新のものが最強」ではありません。プロジェクトの性質に応じて、適切な設計思想を選べることが大事です。「迷ったらDDD」のような盲信は危険です。

コラム

「設計思想」を英語で言うと "Architectural Philosophy" や "Design Paradigm" と呼びます。Paradigm(パラダイム)は「ものの見方の枠組み」という意味です。トーマス・クーンが『科学革命の構造』(1962)で広めた言葉で、「同じ事象でも見方が変わると違う答えが出てくる」ことを指します。設計思想も同じで、「同じ業務でも、見方を変えると違う設計が出てくる」のです。

3. Day 3で扱う「設計」の地図

本日は次の5つのトピックを順に学びます。

flowchart TD S1["3-1 設計アプローチ
(午前)"] --> S2["3-2 永続化
(午後前半)"] S2 --> S3["3-3 通信
(午後中盤)"] S3 --> S4["3-4 実行方式
(午後中盤)"] S4 --> S5["3-5 開発手法
(午後後半)"]

それぞれが「どう作るか」を別の角度から扱います。設計アプローチは「何を中心に考えるか」、永続化は「どこにデータを残すか」、通信は「どう情報をやり取りするか」、実行方式は「どこで動かすか」、開発手法は「どう進めるか」を決めるテーマです。

Day 4の実装では、これらすべての意思決定が成果物として必要になります。

💬 AIに聞いてみよう

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば:

  • 「要件定義と設計の境界線はどこ? あいまいになる例も教えて」
  • 「設計を省略して実装に入るとどんな問題が起きる? 具体例を3つ」
  • 「『設計思想』と『設計手法』と『デザインパターン』はどう違う?」

まとめ(5分)

今日学ぶ「設計」は、Day 2までの「何を作るか」を受けて「どう作るか」を決める活動です。設計の答えは1つではなく、課題に応じて選ぶものです。Day 3を通じて、自チームの開発に「どんな設計思想・永続化・通信・開発手法を選ぶか」の意思決定をしていきましょう。

🔄 振り返りチェック

  • 「設計」とは何をする活動か、4つの観点で挙げられますか?
  • なぜ設計思想(DOA/SOA/ROA等)が複数存在するのか、歴史的な背景を含めて説明できますか?
  • 「最新の設計思想が最強」が誤りである理由を1つ挙げられますか?

補足資料

  • 参考リンク: マーチン・ファウラー『エンタープライズ アプリケーションアーキテクチャパターン』、ロバート・C・マーチン『Clean Architecture』
  • 発展課題: 自分が知っているWebサービス(例: メルカリ)が、どの設計思想で作られていそうかをAIと推測してみる

学習ガイド

想定される質問と回答例

質問 ヒント
要件定義と設計はどう違うの? 要件定義は「何を解決するか(What/Why)」、設計は「どう解決するか(How)」。境界はチームによって解釈が違う
設計書を書く意味って何? 「複数人で同じ未来像を共有するため」「実装前に矛盾を発見するため」「保守時に思い出すため」の3つ
設計と実装は分けるべき? それとも一緒? 大規模・長期は分ける。小規模・短期は一緒でもOK。ただし「頭の中の設計」は必ず先行する

つまずきやすいポイント

つまずきポイント ヒント
設計と要件定義の境界が曖昧 「何のために」が要件、「どうやって」が設計。1つの文を分解して仕分けすると見えてくる
設計思想が多すぎて覚えられない 全部覚える必要なし。「自分のチームに必要なものだけ深掘り」で良い
設計を飛ばして実装したほうが早い気がする 短期的には早い。長期的には倍以上の手戻りコストが発生する。先輩エンジニアの失敗談をAIに聞くと納得できる
読み上げを開始します...

AIに質問する