オリエンテーション／UNIX哲学／設計アプローチ①（POA・DOA）

• 日程: Day 3 / セッション1
• 時間: [9:00-9:30]
• 形式: 座学
• ゴール: UNIX哲学の考え方を1つ挙げ、POA（プロセス中心）とDOA（データ中心）の違いを説明できる
• 学習形式: 対話型解説

🗣️ 要約

• 設計の流派が複数あるのは、プロジェクトの性質によって「何を中心に考えると設計がうまくいくか」が違うため
• ゴールは丸暗記ではなく、開発テーマに合った設計視点を選べるようになること
• まずUNIX哲学という設計思想の原点と、POA・DOAという最初の2つの設計アプローチの違いを扱う

おはようございます。Day3が始まります。今日は「設計思想・アーキテクチャ」がテーマです。

昨日（Day2）は、情報モデルから機能とプレゼンテーションを抽出しました。今日はその一歩先、「どう設計するか」を考えます。

ところで、設計の考え方や流派が、なぜこんなにたくさんあるのだと思いますか？ POA、DOA、MDA、SOA、ROA、OOAD…名前を聞くだけで気が遠くなるかもしれません。

実は理由はシンプルです。プロジェクトの性質によって「何を中心に考えると設計がうまくいくか」が違うからです。処理の流れを中心に考えたい場合もあれば、データの構造を中心に考えたい場合もあります。

今日のゴールは、丸暗記することではありません。「自分たちの開発テーマなら、どの視点で設計するのが合っているか」を選べるようになることです。このセッションが終わる頃には、その第一歩として「UNIX哲学」という設計の考え方の原点と、最初の2つの設計アプローチ（POAとDOA）の違いを説明できるようになっています。

🗣️ 要約

• UNIX哲学（部品の分け方の思想）と、POA・DOA（何を中心に部品を分けるかという設計アプローチ）を扱う
• どちらも「正解」を教えるものではなく、開発テーマに応じて選ぶための視点

🗣️ 要約

• UNIX哲学は「1つのプログラムに1つのことをうまくやらせる」「出力を次の入力にしやすくする」「早期に試作する」という設計思想
• 専門化した道具を組み合わせる方が、万能な1つの道具より自由度が高く壊れにくい
• 目的は機能を細かく分けること自体ではなく、組み合わせて全体がうまく動くように責任の境界を考えること

いきなり抽象的な話をする前に、身近な例から始めましょう。

スマートフォンのアプリを思い浮かべてください。カメラアプリは撮影に特化し、写真編集アプリは編集に特化しています。1つのアプリが「撮影も編集も送信も印刷も全部やります」となっていたら、どう感じますか？ おそらく動作が重く、使い方も複雑になっているはずです。

UNIX哲学とは、まさにこの発想の源流にある設計思想です。1970年代にUNIXというOSを作った技術者たちが大切にした考え方で、代表的なものに次のようなものがあります。

• 1つのプログラムには1つのことをうまくやらせる
• 出力は次のプログラムの入力になるように作る（組み合わせやすくする）
• 早い段階で試作し、動くものを確認しながら進める

これは、いわば「料理の道具」に例えるとわかりやすいかもしれません。万能調理器具が1台あるより、包丁・まな板・鍋がそれぞれ専門化していて、組み合わせて使える方が、結局は自由度が高く壊れにくい、という発想です。

ここで少し考えてみてください。皆さんの開発テーマ（家計簿システムなど）で、「1つのことをうまくやる部品」に分けるとしたら、どこで区切れそうですか？

特に注意してほしいのは、UNIX哲学は「機能を細かく分けろ」という表面的なルールではないということです。よくある誤解として「とにかく細分化すればよい」と思われがちですが、正しくは「組み合わせたときに全体としてうまく動くように、責任の境界を考えて分ける」ということです。細かくしすぎて部品同士のやり取りが複雑になっては本末転倒です。

UNIX哲学を語るときによく引用されるのが、UNIXの開発者の一人であるダグラス・マキルロイの言葉です。「1つのことをうまくやるプログラムを書け。協調して動くプログラムを書け。テキストストリームを扱うプログラムを書け。それは万能のインタフェースだからだ」という趣旨のことを言ったとされています。

面白いのは、この考え方が生まれたのが、コンピュータの性能が今とは比較にならないほど貧弱だった時代だということです。メモリもCPUも限られていたからこそ、「1つのプログラムを軽く保つ」ことが死活問題でした。ところが皮肉なことに、コンピュータがどれだけ高性能になった現代でも、この考え方は色褪せるどころか、マイクロサービスやAPI設計の基本思想として生き続けています。制約から生まれた知恵が、制約がなくなっても最強の武器であり続ける、というのは技術の世界ではよくある話です。

🗣️ 要約

• POAは「処理の流れ」、DOAは「データの構造」を中心に設計を組み立てる考え方
• Day2で作った情報モデルはDOA寄り、状態遷移図はPOA寄りの視点にあたる
• POAとDOAに優劣はなく、データ構造の方が処理手順より変化しにくいため、長期運用システムではDOAが好まれる傾向がある

UNIX哲学が「部品の分け方」の思想だとすると、ここから紹介する設計アプローチは「何を中心に部品を分けるか」という、より具体的な切り口の違いです。

まずは対照的な2つを見てみましょう。

• POA（プロセス中心アプローチ、Process Oriented Approach）：「処理の流れ」を中心に設計を組み立てる考え方です。「注文を受ける→在庫を確認する→発送する」のように、処理の順番を軸に考えます
• DOA（データ中心アプローチ、Data Oriented Approach）：「データの構造」を中心に設計を組み立てる考え方です。「顧客」「商品」「注文」といったデータそのものの関係を軸に考えます

例えば家計簿システムを考えると、POAの視点では「入力する→分類する→集計する→表示する」という処理の流れが主役になります。一方、DOAの視点では「支出データ」「カテゴリデータ」「月次集計データ」というデータの構造とその関係が主役になります。

ここで思い出してほしいのは、Day2で作った「情報モデル」です。情報モデルは情報の属性・関係・制約を定義したものでした。実はこれは、DOAの考え方にとても近いものです。逆に、状態遷移図で表した「処理の順番」は、POA的な視点だと言えます。つまり、皆さんはDay2の演習で、すでにPOAとDOA両方の視点に触れていたことになります。

ここで一度考えてみてください。皆さんの開発テーマは、処理の流れ（POA）とデータの構造（DOA）、どちらを主役にして考えた方がしっくりきますか？

特に注意してほしいのは、POAとDOAは「どちらが正しい」という優劣の話ではないということです。よくある誤解として、DOAの方が新しくて優れていると考えられがちですが、正しくは「変化しやすいのはどちらか」で選ぶという考え方です。一般的に、業務の処理手順（POA）は組織変更などで変わりやすいのに対し、データの構造（DOA）は比較的安定しているため、大規模で長期運用するシステムではDOAが好まれる傾向があります。ただし、これも「傾向」であって絶対のルールではありません。

🗣️ 要約

• UNIX哲学とマイクロサービスの関係、POAとDOAを自分たちの開発テーマに当てはめた説明、DOA向き・POA向きの具体例などをAIに質問できる

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

• 「UNIX哲学とマイクロサービスの関係をもっと詳しく教えて」
• 「POAとDOAの違いを、自分たちの開発テーマ（〇〇システム）に当てはめて説明して」
• 「DOAが向いているシステムと、POAが向いているシステムの具体例をそれぞれ挙げて」

🗣️ 要約

• 設計思想は目的に応じて選ぶための道具箱であり、UNIX哲学の上にPOA（処理中心）・DOA（データ中心）という2つの視点がある
• 次回はMDA・SOA・ROA・OOADという設計アプローチとデザインパターンを学ぶ

今回学んだことを一言でまとめると、「設計思想は目的に応じて選ぶための道具箱である」ということです。UNIX哲学という土台の上に、POA（処理中心）・DOA（データ中心）という最初の2つの視点を学びました。

次回は、MDA・SOA・ROA・OOADという、さらに視点の異なる設計アプローチと、デザインパターンを学びます。今回の「何を中心に考えるか」という視点の違いが土台になるので、しっかり押さえておきましょう。

🗣️ 要約

• UNIX哲学の考え方を1つ、具体例とともに説明できるか
• POAとDOAの違いを、自分たちの開発テーマに当てはめて説明できるか

以下の問いに答えられるか確認してみましょう：

• UNIX哲学の考え方を1つ、具体例とともに説明できますか？
• POAとDOAの違いを、自分たちの開発テーマに当てはめて説明できますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

🗣️ 要約

• 参考資料はUNIX哲学・プロセス中心アプローチ・データ中心アプローチの解説記事や書籍
• 発展課題は、普段使うアプリの中でUNIX哲学に沿っている部分／あえて統合されている部分を探すこと

• 参考リンク: UNIX哲学、プロセス中心アプローチ、データ中心アプローチについて解説している技術記事や書籍
• 発展課題: 自分たちが普段使っているアプリを1つ選び、「UNIX哲学に沿っている部分」と「沿っていない部分（あえて統合されている部分）」を探してみる

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

このセクションは、受講者が理解を深めることをサポートする参考情報です。

🗣️ 要約

• UNIX哲学はマイクロサービスやコンテナ技術など現代のアーキテクチャの根底にある考え方
• POAとDOAは優劣ではなく、変化しやすさ（処理手順は変わりやすく、データ構造は安定しやすい）で選ぶ
• Day2の情報モデルはDOA寄り、状態遷移はPOA寄りで、両方の視点が併存してよい

🗣️ 要約

• UNIX哲学を「機能を細かく分割すればよい」と単純化して理解してしまいやすい
• POA・DOAをどちらか一方でしか捉えられず、両方の視点を併用できないことがある