（演習）開発テーマをPOA視点・DOA視点で捉え直す

• 日程: Day 3 / セッション2
• 時間: [9:30-10:00]
• 形式: 演習
• ゴール: 開発テーマの処理を、POA視点（処理の流れ）とDOA視点（データの構造）でそれぞれ1つずつ書き出せる
• 学習形式: AIディスカッション

🗣️ 要約

• 開発テーマを「処理の流れ」として説明するか「データの構造」として説明するかで、設計の出発点が変わる

さきほどのセッションで、POA（プロセス中心アプローチ）とDOA（データ中心アプローチ）という2つの設計アプローチを紹介しました。

ここで少し考えてみてください。もし自分たちの開発テーマを「一連の処理の流れ」として説明するとしたら、どう説明しますか？逆に「扱うデータの構造」として説明するとしたら、どう変わるでしょうか？

このセッションが終わる頃には、同じ開発テーマでも、どちらの視点で見るかによって設計の出発点がまったく変わることを、自分たちのチームの言葉で説明できるようになっています。

🗣️ 要約

• POA視点とDOA視点をおさらいし、それぞれの視点で開発テーマを捉え直す

🗣️ 要約

• POAは「レシピ」のように処理の手順を主役にし、DOAは「冷蔵庫の中身」のようにデータの構造を主役にする
• 家計簿システムでは、POA視点は「入力する→分類する→集計する→表示する」、DOA視点は「取引データ・カテゴリデータ・口座データ」という構造になる
• POAとDOAはどちらが正しいかではなく、目的に応じて使い分けるもの（再利用性重視ならDOA、処理の分かりやすさ重視ならPOA）

POA（プロセス中心アプローチ）は、いわば「レシピ」のようなものです。「材料を切る→炒める→盛り付ける」というように、処理の手順（プロセス）を主役にして設計を進めます。

一方でDOA（データ中心アプローチ）は、いわば「冷蔵庫の中身」のようなものです。「肉・野菜・調味料」というデータそのものの構造を先に整理してから、それをどう調理（処理）するかを後から考えます。

たとえば「家計簿システム」というテーマなら、POA視点では「入力する→分類する→集計する→表示する」という処理の流れが最初に思い浮かびます。これは該当します。一方DOA視点では「取引データ」「カテゴリデータ」「口座データ」という情報の構造が最初に思い浮かびます。これも該当します。どちらも同じシステムを説明していますが、切り口がまったく違うことに気づけましたか？

反対に「今日の気分」のような、処理にもデータ構造にも整理しにくいあいまいな感想は、POAにもDOAにも該当しません。なぜなら、どちらのアプローチも「情報として扱えるもの」を前提にしているからです。

特に注意してほしいのは、POAとDOAは「どちらが正しいか」を競うものではないという点です。よくある勘違いとして「最新のアプローチほど優れている」と考えてしまうことがありますが、正しくは「目的に応じて使い分けるもの」です。データの再利用性を重視するならDOA、処理の分かりやすさを重視するならPOA、というように選択します。

実は、日本の情報システム開発の現場では、1990年代から2000年代にかけて「DOAブーム」がありました。当時は「データは変わりにくいが、処理（業務ロジック）は頻繁に変わる」という考え方から、データ構造を先に固めるDOAが持て囃されたのです。ところが皮肉なことに、その後Webサービスの普及でAPIやオブジェクトを中心とした設計（後で学ぶOOADやROA）が主流になり、DOA一辺倒だった議論は少し落ち着きました。技術のトレンドも、ペルソナや時代のニーズによって「多義的」に揺れ動く、というのは情報アーキテクチャ的にも興味深い話です。

🗣️ 要約

• POAとDOAの違いや、自分たちのテーマにどちらが向くか、実務での組み合わせ方をAIに質問できる

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

• 「POAとDOAの違いを、別の開発テーマの例で説明して」
• 「自分たちのテーマはPOAとDOAのどちらで考えた方が設計しやすい？」
• 「実務ではPOAとDOAをどう組み合わせて使うの？」

🗣️ 要約

• 開発テーマをPOA視点とDOA視点でそれぞれ書き出し、どちらが合っているかを話し合う演習

🗣️ 要約

• 開発テーマの中心となる処理をPOA視点（〜する→〜する→〜する）で、データをDOA視点（〜データ、〜データ）で書き出す

チームの開発テーマについて、次の2つを1つずつ書き出してください。

• POA視点：開発テーマの中心となる処理を「〜する→〜する→〜する」という手順で書き出す
• DOA視点：開発テーマの中心となるデータを「〜データ」「〜データ」という構造で書き出す

書き出したら、チーム内で「どちらの視点の方が今のテーマには合っていそうか」を話し合ってください。

🗣️ 要約

• POA視点・DOA視点それぞれで書き出したメモ（各3〜5行程度）

POA視点・DOA視点それぞれで書き出したメモ（各3〜5行程度）

🗣️ 要約

• よく使う動詞に注目するとPOA視点、よく出てくる名詞に注目するとDOA視点で考えやすい
• 意見がまとまらないときはAIに整理してもらい、たたき台として使うとよい

• うまくいかない場合は、まず「開発テーマで一番よく使う動詞は何か」（POA視点）と「開発テーマで一番よく出てくる名詞は何か」（DOA視点）から考えてみてください
• 意見がまとまらない場合は、AIに「（開発テーマ名）をPOA視点とDOA視点でそれぞれ整理して」と聞いて、たたき台として使うのもよい方法です

🗣️ 要約

• 同じ開発テーマでも、処理を主役にするか、データを主役にするかで設計の出発点が変わる
• 次回はMDA・SOA・ROA・OOADという別の視点の設計アプローチとデザインパターンを学ぶ

今回学んだことを一言でまとめると、「同じ開発テーマでも、処理を主役にするか、データを主役にするかで設計の出発点が変わる」ということです。

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

🗣️ 要約

• POA視点とDOA視点の違いを、自分たちの開発テーマを例に説明できるか
• どちらの視点で考えるかによって、最初に決めるべきことがどう変わるか

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

• POA視点とDOA視点の違いを、自分たちの開発テーマを例に説明できますか？
• どちらの視点で考えるかによって、最初に決めるべきことがどう変わるか説明できますか？

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

🗣️ 要約

• 参考リンクは特になく、「プロセス中心アプローチ」「データ中心アプローチ」を書籍等で補強するとよい
• 発展課題は、開発テーマを次回学ぶOOAD視点（オブジェクトを主役にする視点）で捉え直しておくこと

• 参考リンク: なし（社内資料や信頼できる書籍で「プロセス中心アプローチ」「データ中心アプローチ」を検索して補強するとよい）
• 発展課題: 開発テーマを、次のセッションで学ぶOOAD視点（オブジェクトを主役にする視点）でも捉え直すとどうなるか、あらかじめ考えてみる

🗣️ 要約

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

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

🗣️ 要約

• POAとDOAに学ぶ順序の決まりはなく、まず「処理」と「データ」という2つの切り口を知ることが重要
• POAは今も単純なバッチ処理やスクリプトなど手順が明確な場面で有効
• POA・DOA以外にもMDA・SOA・ROA・OOADなど異なる「主役」を置く視点がある

🗣️ 要約

• POA視点とDOA視点の書き出しが同じ内容になってしまいやすい（動詞で終わるか名詞で終わるかで確認する）
• どちらが正解か決めようとして議論が止まりやすい（視点の違いを体感する演習であることを思い出す）