設計思想と設計アプローチ

• 日程: Day 3 / セッション 1
• 時間: [9:00-9:30]
• 形式: 座学
• ゴール: UNIX哲学の要点を一言で言える。POA/DOA/MDA/SOA/ROA/OOADの着眼点の違いを、自分の開発テーマを例にして（条件）、それぞれ一言ずつ説明できる（行動・基準）
• 学習形式: 対話型解説

Day 2 では、情報モデルの状態遷移から「機能」と「プレゼンテーション」を分離して抽出しました。
実はあの分離は、ソフトウェア業界が何十年もかけてたどり着いた「設計思想」の実践そのものです。

今日は、その設計思想を「自分で選べる」ようになる日です。

ここで少し考えてみてください。同じ家計簿システムでも、「処理の流れ」から設計を始める人と、「支出データの形」から設計を始める人がいたら、できあがるシステムは同じになるでしょうか？

おそらく違うものになります。どこを中心に据えて設計を始めるか——それが「設計アプローチ」の違いです。
このセッションでは、設計思想の原点であるUNIX哲学から出発し、6つの設計アプローチを「中心に据えるもの」という一つの軸で整理します。

「設計思想」とは、設計するときに従う価値観・信念のことです。
これは料理人の「素材の味を活かす」という信念のようなものです。信念が決まれば、レシピ（設計）も調理（実装）も自然と方向が定まります。

設計思想の代表例が UNIX哲学 です。1970年代にUNIXというOSを作った人たちが実践した価値観で、要点は一言で言えます。

「一つのことをうまくやる小さな部品を作り、それらを組み合わせる」

箇条書きにすると次の3点です。

• 一つのプログラムには一つの仕事だけさせる（Do One Thing Well）
• プログラム同士が連携できるように作る（出力が次の入力になる）
• 早く試作し、ダメなら作り直すことをためらわない

UNIXのコマンドはこの哲学の生きた実例です。

# 支出ログから「食費」の行を抜き出し、並べ替え、件数を数える
cat expenses.txt | grep "食費" | sort | wc -l

grep は検索だけ、sort は並べ替えだけ、wc は数えるだけ。
どれも単機能ですが、パイプ（|）でつなぐと複雑な処理ができます。

「1つのアプリで検索も並べ替えも集計も全部やる巨大プログラム」はUNIX哲学に該当しません。一方、「小さなコマンドの組み合わせ」は該当します。なぜなら、前者は一部を直すと全体に影響しますが、後者は部品ごとに交換・再利用できるからです。

• 設計思想は「正解」ではなく「価値観」。だから複数あり、選ぶ必要がある
• Day 2 でやった「機能とプレゼンテーションの分離」も、「関心ごとに部品を分ける」というUNIX哲学と同じ価値観の延長線上にある
• 「小さく作って組み合わせる」は、この研修の約束事「PDCAを小さく沢山回す」とも通じる

UNIXを生んだケン・トンプソンは、1969年の夏、家族が旅行で留守にしたわずか3週間でUNIXの原型を書き上げたと言われています。OS・シェル・エディタ・アセンブラを1週間ずつ、というペース配分だったとか。「小さく作る」哲学は、締め切り（家族の帰宅）から生まれたのかもしれません。ちなみに相棒のデニス・リッチーはこの後、UNIXを書き直すためにC言語を作ります。言語ごと作るあたり、豪快です。

設計アプローチとは、システム設計の出発点（中心に据えるもの）を何にするかの選択です。
歴史の流れで見ると、中心は「プロセス → データ → オブジェクト → サービス／リソース／モデル」と移り変わってきました。

系譜を図にすると次のようになります。

なぜプロセス中心からデータ中心へ移ったのでしょうか。ここで少し考えてみてください。業務の「手順」と業務で扱う「データ」、10年後も変わっていないのはどちらでしょうか？

答えはデータです。家計簿でいえば、集計の手順や画面は流行で変わりますが、「支出には日付・金額・費目がある」という構造は何十年も変わりません。変わりにくいものを中心に据えるほど、システムは長持ちする——これが歴史から得られた教訓です。

なお、OOADでは分析・設計の結果を UML（統一モデリング言語）という図法で表現します。Day 2 で描いた情報モデル図や状態遷移図は、UMLのクラス図・ステートマシン図の親戚です。皆さんはすでにUML的な活動をしています。

注意点をひとつ。SOAとROAはどちらも「分離して連携する」発想ですが、SOAは「業務機能（サービス）」単位、ROAは「情報資源（リソース）」単位です。「残高を計算する」はサービスに該当しますが、リソースには該当しません。なぜなら、リソースはURIで指し示せる「名詞（モノ）」であり、「計算する」は動詞（処理）だからです。

同じ「支出の一覧を見る」を、ROAとSOAで表現し比べてみます。

ROA流（リソース＝名詞が主役）
  GET /expenses           ← 支出一覧というリソースを取得
  GET /expenses/123       ← 支出123というリソースを取得

SOA流（サービス＝業務機能が主役）
  呼び出し: ExpenseService.getExpenseList(userId)
  呼び出し: ReportService.calcMonthlySummary(userId, month)

ROAはURLの形にWebの思想がそのまま現れます。SOAは業務機能の呼び出しとして現れます。

• 6つを暗記するのではなく、「中心に据えるものが違うだけ」という一つの軸で覚える
• 新しいアプローチが古いものを「置き換えた」のではない。現代のシステムはDOA＋OOAD＋ROAのように組み合わせて使うのが普通
• 皆さんがDay 1-2でやってきた「情報を先に定義する」進め方は、DOAの考え方に近い。自覚してみましょう

分からない用語があれば、この時点でAIに質問してみましょう。「POAとDOAの違いを家計簿システムで説明して」のように、自分のテーマに引きつけて聞くのがコツです。

「データ中心アプローチ」が日本で広まった1980年代、多くの企業システムはCOBOLでプロセス中心に書かれていました。業務手順が変わるたびにプログラムを大改修する羽目になり、「処理は水物、データは資産」という標語が生まれます。日本ではDOAを独自に発展させた「三要素分析法」や「T字形ER法」などの流派も誕生しました。設計アプローチに「流派」があるあたり、武道のようですね。

設計アプローチが「どこから考え始めるか」だとすれば、デザインパターンは「よくある問題への定石」です。
これは将棋の定跡集のようなものです。ゼロから考えなくても、先人が検証済みの手を再利用できます。

代表が GoF（Gang of Four）のデザインパターン です。1994年の書籍で、オブジェクト指向設計の定石23個をカタログ化しました。

• 生成に関するパターン（例: Singleton＝インスタンスを1つに保つ）
• 構造に関するパターン（例: Facade＝複雑な内部に窓口を1つ設ける）
• 振る舞いに関するパターン（例: Observer＝変化を関係者に自動通知する）

もう一つ、ジェネレーションギャップパターンも紹介します。これは「自動生成されたコード（親クラス）と、人が手で書くコード（子クラス）を分離する」パターンです。ツールがコードを再生成しても、手書き部分が上書きされずに済みます。MDA（モデルから自動生成）と相性が良いパターンです。

「if文を減らす自分だけの工夫」はデザインパターンには該当しません。一方「Observerパターン」は該当します。なぜなら、パターンとは名前がつき、共有され、繰り返し使われる解決策だからです。名前がつくことで「ここはObserverで」と一言で会話できるようになります。これはIAで学んだ「見出し」の効果と同じです。

Observerパターンの雰囲気をJavaScriptで示します。家計簿で「支出が登録されたら残高表示を自動更新する」場面です。

class ExpenseBook {
  constructor() { this.observers = []; }
  subscribe(fn) { this.observers.push(fn); }
  add(expense) {
    // 支出を登録し、購読者全員に通知する
    this.observers.forEach(fn => fn(expense));
  }
}

const book = new ExpenseBook();
book.subscribe(e => console.log(`残高表示を更新: -${e.amount}円`));
book.subscribe(e => console.log(`グラフを更新: ${e.category}`));
book.add({ amount: 500, category: "食費" });

登録処理は「誰が画面を更新するか」を知りません。関心の分離がここでも効いています。

• 思想（UNIX哲学）→ アプローチ（POA〜MDA）→ パターン（GoF）は、抽象度の階段になっている
• パターンの価値は「名前で会話できること」。IAの「見出し」と同じ効果
• 23個を覚える必要はない。「困ったら定石集がある」と知っていれば、AIに「この問題に合うデザインパターンは？」と聞ける

GoFとは「Gang of Four（4人組）」の略で、著者4人（ガンマ、ヘルム、ジョンソン、ブリシディーズ）を指します。もともとは中国の政治史に登場する「四人組」をもじった冗談めいた呼び名でしたが、いまや世界中の技術面接で飛び交う正式用語のようになりました。本の正式名は『オブジェクト指向における再利用のためのデザインパターン』と長いので、誰も正式名で呼ばず「GoF本」で通じます。名前重要、を地で行く話です。

• 「私の開発テーマは◯◯です。POA/DOA/MDA/SOA/ROA/OOADのそれぞれで設計を始めると、最初に描く図はどう変わりますか？」
• 「UNIX哲学の『一つのことをうまくやる』に反している有名なソフトウェアの例と、その反省から生まれた設計を教えてください」
• 「GoFのデザインパターンのうち、家計簿システムのようなCRUD中心のアプリでよく使われるものを3つ、理由付きで教えてください」

今回学んだことを一言でまとめると「設計アプローチとは『どこを中心に据えるか』の選択であり、変わりにくいものを中心に据えるほどシステムは長持ちする」です。

• 設計思想（UNIX哲学）: 小さく作って組み合わせるという価値観
• 設計アプローチ: 中心が プロセス→データ→オブジェクト→サービス/リソース/モデル と発展してきた
• デザインパターン: 名前のついた定石集。名前で会話できる

次のセッションは演習です。いよいよ、自分の開発テーマに合う設計アプローチを自分で選び、根拠を言葉にします。AIに反対の立場でディベートを挑んでもらい、選択の根拠を鍛えましょう。

• UNIX哲学の要点を一言で言えますか？
• POAとDOAの違いを、自分の開発テーマを例に説明できますか？
• SOAとROAの「単位」の違い（サービス＝動詞的、リソース＝名詞的）を説明できますか？

• 参考リンク:

  • 『UNIXという考え方』（Mike Gancarz）: UNIX哲学を9つの定理で解説した定番書
  • 『オブジェクト指向における再利用のためのデザインパターン』（GoF本）
  • IPA「共通フレーム」: 日本のシステム開発工程の標準的な整理
• 発展課題:

  • 自分のスマホに入っているアプリを1つ選び、「このアプリはどのアプローチで設計されていそうか」をAIと議論してみましょう
  • ls | grep txt | wc -l のようなパイプ処理を自分で1本組み立て、UNIX哲学を手で確かめてみましょう