設計用語をIAの手法で整理する

• 日程: Day 3 / セッション 4
• 時間: [11:00-12:00]
• 形式: 演習
• ゴール: Day 3午前に登場した具体語（MVC、DDD、DOA、GoFパターン等）をカードの材料にして（条件）、「アーキテクチャ」「設計」「駆動」「アプローチ」「パターン」の5用語をカードソーティングの手法で整理・分類し（行動）、見出し付きの分類マップを作成して各用語の違いを一文ずつで説明できる（基準）
• 学習形式: ケーススタディ＋AIディスカッション

今朝からの2時間半で、あなたは何個の横文字に出会ったでしょうか。
POA、DOA、MDA、SOA、ROA、OOAD、UML、GoF、MVC、MVVM、DDD、ユビキタス言語……。

正直に言って、頭の中が散らかっていませんか。それで正常です。

ここで少し考えてみてください。この状況、どこかで見覚えがありませんか。
そうです、Day 1のセッション2「散らかった情報を整理してみる」と同じです。
あのとき散らかっていたのは架空の情報20件でした。今日散らかっているのは、あなた自身の頭の中の設計用語です。

このセッションでやることはシンプルです。
Day 1で学んだIAの手法（整理・分類・見出し・カードソーティング）を、設計知識そのものに適用します。

これはメタ演習です。IAは家計簿の「支出」や「カテゴリ」だけに効く技術ではありません。
情報でありさえすれば何にでも効きます。設計用語も、立派な情報です。
それを自分の手で確かめるのが、この1時間のミッションです。

Day 1を思い出しましょう。IAの手順はこうでした。

• 整理: 必要な情報を残し、不要な情報を捨てる
• 分類: 似たものをまとめてカテゴリに分ける
• 見出し: まとめたグループを抽象的に捉えた名前を付ける
• カードソーティング: 情報を1枚1件のカードにして並べ替える（オープン＝グループを自分で作る／クローズド＝グループが先にある）

今回はオープンカードソーティングを使います。グループの正解は用意されていません。

まず「カードにできるもの」を確認します。
「MVC」はカードに該当しますが、「今朝の話はなんとなく難しかった」はカードに該当しません。
なぜなら、カードは1枚につき1つの、名前を付けられる情報でなければならないからです。感想や気分は名前の付いた情報ではありません。

これは、部屋の片付けのようなものです。
床に散らばった服・本・ケーブルを、まず1つずつ手に取れる「モノ」として認識する。
そこから「衣類」「読み物」「ガジェット」と棚に分けていく。
カード化は「1つずつ手に取れる状態にする」工程です。

今回のカードの材料です。抽象語5枚＋具体語です。テキストファイルや付箋アプリで十分です。

【抽象語カード（今回の主役5枚）】
アーキテクチャ / 設計 / 駆動 / アプローチ / パターン

【具体語カード（午前中に登場した語から）】
POA（プロセス中心アプローチ） / DOA（データ中心アプローチ）
MDA（モデル駆動型アーキテクチャ） / SOA（サービス指向アーキテクチャ）
ROA（リソース指向アーキテクチャ） / OOAD（オブジェクト指向分析設計）
3層アーキテクチャ / MVC / MVVM / DDD（ドメイン駆動設計）
GoFパターン / ジェネレーションギャップパターン / ユビキタス言語 / UNIX哲学

具体語カードは「抽象語がどう使われているかの証拠品」です。
たとえば「MDA＝モデル駆動型アーキテクチャ」という1枚には、抽象語が2つも埋まっています。

• IAの手法は情報一般に効く。対象が「支出」でも「設計用語」でも手順は同じ
• カードは1枚1情報。名前が付けられないものはカードにならない
• 具体語カードは、抽象語カードの意味を推理するための証拠品として使う

「アーキテクチャ」の語源は大工の棟梁

アーキテクチャ（architecture）の語源は、ギリシャ語の arkhitekton（アルキテクトン）です。arkhi は「長・統率する者」、tekton は「大工・職人」。つまり「大工の棟梁」が原義です。個々の職人が壁や柱を作る中で、棟梁だけは建物全体の構造と意図に責任を持ちます。この言葉が数千年かけて建築の世界で育ち、1960年代、IBMのSystem/360開発でフレデリック・ブルックスらが計算機の全体構造を指して「アーキテクチャ」と呼び始めました。ソフトウェアの世界がこの語を輸入したのは、部分の集まりではなく「全体の構造と意図」を語る言葉が必要になったからです。棟梁の視点、と覚えておくと腹に落ちます。

さて、5つの抽象語をどう分類するか。答えは渡しません。代わりに、考察の観点を3つだけ渡します。

観点1: 抽象度の違い
「アーキテクチャ」と「パターン」は、どちらも構造の話です。では守備範囲は同じでしょうか。
建物に例えると、片方は「ビル全体の構造方針」、もう片方は「よく使う階段の作り方の定石」のような関係かもしれません。全体か、部分か。一度きりか、繰り返し使うか。

観点2: 「〜中心」と「〜駆動」の違い
午前中の用語には「データ中心アプローチ」と「モデル駆動型アーキテクチャ」「ドメイン駆動設計」がありました。
中心（oriented / centered）は「何を軸に据えて考えるか」。
では駆動（driven）は何でしょうか。車の「前輪駆動」を思い出してください。駆動輪とは、エンジンの力を受けて車を前に進ませる車輪です。
ここで少し考えてみてください。DDDでは、何が開発を前に進ませるのでしょうか。

観点3: 語の役割（品詞のように見る）
「設計」は行為（設計する）にも成果物（この設計は美しい）にもなります。
「アプローチ」は取り組み方の方針です。「アプローチする」対象があり、進み方を決めます。
つまり5つの語は、同じ土俵に並ぶ対等な仲間とは限りません。修飾する側とされる側があるかもしれません。

家計簿システムを主語にして、5つの語を実際の文で使ってみます。助詞と動詞に注目してください。

1. 家計簿システムを「データ中心アプローチ」で設計する
2. 家計簿システムに「3層アーキテクチャ」を採用する
3. 一覧画面の更新に GoF の Observer「パターン」を適用する
4. 「ドメイン駆動」で設計を進める
5. この「設計」をレビューする

「アプローチで設計する」「アーキテクチャを採用する」「パターンを適用する」。
語ごとに結びつく助詞と動詞が違います。使われ方の違いは、意味の違いの証拠です。
「〜で進める」は該当しても「〜を適用する」は不自然な語があります。なぜ不自然なのかを言語化できれば、定義はもう半分できています。

• 分類に正解はない。ただし「分類の根拠を一文で言えること」が合格ライン
• 抽象度（全体／部分）、中心と駆動（軸／推進力）、語の役割（行為／成果物／方針）の3観点で観察する
• 迷ったら具体語カードに戻る。「MDAのこの部分が駆動だ」と証拠品で確認する

パターンの父は建築家 クリストファー・アレグザンダー

「パターン」という考え方をソフトウェア界に持ち込んだのは、プログラマではなく建築家です。クリストファー・アレグザンダーは1977年の著書『A Pattern Language（パタン・ランゲージ）』で、「心地よい街や建物には繰り返し現れる253の型がある」として、「小さな窓辺の腰掛け」「街路を見下ろすバルコニー」などを名前付きで記述しました。これに衝撃を受けたのがプログラマのウォード・カニンガムとケント・ベックで、「ソフトウェアの良い設計にも繰り返し現れる型があるはずだ」と考え、その流れの先で1994年にGoF本『デザインパターン』が生まれました。ちなみにアレグザンダー本人は後年、ソフトウェア業界の熱狂に対して「私の意図が正しく伝わっているか疑問だ」と述べています。分類と命名は、それほど強力で、それほど誤解も生む道具だということです。

分類の途中で手が止まったら、抱え込まずにAIに聞いてみましょう。ただし「答え」ではなく「観点」をもらうのがコツです。

• 「『データ中心アプローチ』と『ドメイン駆動設計』の『中心』と『駆動』は何が違いますか。私に直接答えを教えず、考えるためのヒントを3つください」
• 「『アーキテクチャ』と『パターン』を建物に例えて対比してください。そのあと、この例えが崩れるケースも教えてください」
• 「『設計』という言葉が行為を指す文と成果物を指す文を、家計簿システムを題材に3つずつ作ってください」

以下の手順で、設計用語の分類マップと一文定義を作成してください（目安45分）。

1. カード化: 本編のカード一覧をテキストや付箋アプリに書き出す。午前中のメモから追加したい語があれば足す
2. オープンカードソーティング: 抽象語5枚と具体語カードを、自分の基準でグループ化する。基準は途中で変えてよい（PDCA）
3. 見出し: 各グループに見出しを付ける。「その他」という見出しは禁止。付けられないなら分類をやり直す
4. 一文定義: 「アーキテクチャ」「設計」「駆動」「アプローチ」「パターン」それぞれの違いが分かるように、1用語1文で定義を書く
5. AIディスカッション: 下のプロンプト例を使い、自分の定義に反例をぶつけてもらう。崩れたら定義（必要なら分類）を直す

AIに揺さぶってもらうときは、次のプロンプトをコピペして使ってください。

私は設計用語を自分なりに定義しました。

- 駆動: （あなたの一文定義）
- アプローチ: （あなたの一文定義）

この定義では説明できない反例や、定義同士が衝突するケースを挙げてください。
ただし正しい定義を先に教えないでください。私が自分で直します。

私は設計用語を次のグループに分類し、見出しを付けました。
（分類マップを貼る）

この分類をクローズドカードソーティングで検証したいです。
午前の講義に出た用語を3つ出題するので私がどのグループに入れるか答えます。
私の答えに矛盾があれば指摘してください。

• 設計用語の分類マップ: グループ分けと見出し（テキストの箇条書きで可）
• 5用語の一文定義: 「アーキテクチャ」「設計」「駆動」「アプローチ」「パターン」各1文

この2つは本日の「設計方針メモ」を書くときの語彙の土台になります。

• 分類の正解探しで止まったら、Day 1の合言葉を思い出す。「定義→価値の確認→再定義」を小さく回す
• 一文定義は自分の言葉で。AIや辞書の文をコピーすると、次のAIディスカッションで一撃で崩されます
• 5つの抽象語が「同じグループに全部入る」結果になったら、抽象度の観点を見落としているサイン
• 具体語カードが1枚も入らないグループができたら、その見出しは実態のない見出しかもしれない

今回学んだことを一言でまとめると「IAの手法は情報一般に効く。設計用語という知識さえ、整理・分類・見出しで探しやすくできる」です。

• 頭の中が散らかったら、それはIAの出番。カード化→ソーティング→見出しの手順は対象を選ばない
• 分類に正解はないが、根拠の一文が言えない分類は分類ではない
• 抽象度・中心と駆動・語の役割という観点は、今後新しい設計用語に出会うたびに使い回せる

午後はいよいよ「永続化」です。次のセッションでは、データを失わずに保存する仕組み（ACID）と、正規化を扱います。
そこで「情報モデルはペルソナのため、正規化はコンピュータのため」という、本日最大の対比が登場します。
今この演習で鍛えた「言葉の違いに敏感になる力」を、そのまま持って行ってください。

• 「アーキテクチャ」と「パターン」の違いを、抽象度という言葉を使って一文で言えますか？
• 「〜中心」と「〜駆動」の違いを、車の駆動輪以外の自分の例えで説明できますか？
• 自分の分類マップの見出しについて、「なぜこの見出しか」を各グループ一文で言えますか？

• 参考リンク:

  • GoF『オブジェクト指向における再利用のためのデザインパターン』（原著: Design Patterns, 1994）
  • クリストファー・アレグザンダー『パタン・ランゲージ』（鹿島出版会）
  • IPA「システム構築の上流工程強化」関連資料: https://www.ipa.go.jp/
• 発展課題:

  • 「フレームワーク」「ライブラリ」「プラットフォーム」の3語を今日と同じ手法で分類し、5用語の分類マップに追加してみましょう
  • 自分の一文定義を使って、明日Day 4で使う予定の技術（REST、モックAPI等）を「これはパターンか、アーキテクチャか」と判定してみましょう