UIと機能の通信／実行方式／開発手法

• 日程: Day 3 / セッション9
• 時間: [14:50-15:30]（座学30分＋ミニ演習10分）
• 形式: 座学／ミニ演習
• ゴール: REST/JSONとSOAP/XMLの違いを説明し、ネイティブ・Web・クラウド（SaaS/PaaS/IaaS）の実行方式とウォーターフォール／アジャイルの違いを挙げられる
• 学習形式: 対話型解説／AIディスカッション

🗣️ 要約

• UIと機能の通信・実行方式・開発手法という3つのテーマを扱う
• スマホアプリとサーバーの通信は多くの場合、HTTPでJSONをやりとりするだけの仕組み
• Day4で実装するRESTful APIが、なぜ現在主流なのかにつながる

前のセッションでは、RDBの正規化と情報アーキテクチャの違いを考察しました。「情報をどう永続化するか」まで来ましたね。

今回はその続きです。永続化された情報を、画面（UI）とどうやりとりするのか。そして、作ったソフトウェアをどこで動かすのか。さらに、それをどんな手順で作っていくのか。この3つを一気に見ていきます。

ところで、スマホアプリが裏側のサーバーとデータをやりとりするとき、何が起きていると思いますか？ 実は、多くの場合「HTTPで小さな荷物（JSON）をやりとりしているだけ」です。難しそうに見えて、仕組みは意外とシンプルです。

このセッションが終わる頃には、明日Day4で自分たちが実装するRESTful APIが「数ある選択肢の中の、今なぜ主流なのか」を説明できるようになっています。

🗣️ 要約

• 離れた場所の機能を呼び出す通信技術（RPC/CORBA/HTTP、SOAP対REST）
• ソフトウェアの実行方式（ネイティブ・Webアプリ・クラウドのSaaS/PaaS/IaaS）
• 開発手法（ウォーターフォール・反復型・アジャイル）とバージョン管理

🗣️ 要約

• 画面（プレゼンテーション）と機能（ロジック）は別の場所で動くことが多く、それを繋ぐのが通信の仕組み
• SOAPはXMLで厳格にやりとりし、RESTはJSONで軽くやりとりする
• RESTful API・JSONが主流なのは、荷物が軽く通信量やバッテリーに有利だから

画面（プレゼンテーション）と機能（ロジック）は、別々の場所で動いていることがよくあります。スマホの画面はスマホの中で動いていますが、データを保存する処理はサーバーの中で動いている、というように。

この「離れた場所にある機能を呼び出す」ための技術が、通信の仕組みです。

古くはRPC（Remote Procedure Call、遠隔手続き呼び出し）やCORBAという仕組みがありました。これらは「まるで自分のプログラムの中の関数を呼ぶように、遠くのサーバーの機能を呼び出せる」という考え方です。料理に例えると、注文を厨房に直接届けて作ってもらうようなものです。今はHTTP（Webページを表示するのと同じ仕組み）を土台にした通信が主流になっています。

HTTPの上でやりとりする方法にも種類があります。

• SOAP：XMLという厳格な書式でやりとりする方式。WSDLという「取扱説明書」を必ず用意する
• REST：JSONという軽い書式でやりとりすることが多い方式。WADLという説明書を使うこともあるが、SOAPほど厳格ではない

たとえば、住所を1件取得するだけなのに、SOAPは何行ものXMLタグで包んで送りますが、RESTなら {"zip":"100-0001"} のような一言で済むことがあります。荷物を送るとき、SOAPは書類一式を添えた宅配便、RESTはメモ書き1枚を渡すようなものだとイメージすると分かりやすいでしょう。

ここで少し考えてみてください。もしあなたがスマホアプリとサーバーの通信を設計するなら、SOAPとRESTのどちらを選びますか？ 荷物が軽いほうが、スマホの限られた通信量やバッテリーには有利です。これが、RESTful API・JSONが現在主流になっている理由のひとつです。明日のDay4では、まさにこのRESTful APIを自分たちの手で作ります。

🗣️ 要約

• ネイティブアプリは動作が速いが機種ごとの作り分けが必要、Webアプリはインストール不要でどの端末からもアクセスできる
• クラウドにはSaaS（ソフトごと借りる）・PaaS（実行環境を借りる）・IaaS（サーバー機材を借りる）の3段階がある
• オンプレミスは持ち家、クラウドは賃貸に例えられる

作ったソフトウェアを、どこで・どんな形で動かすかにも選択肢があります。

• ネイティブアプリケーション／モバイルアプリ：スマホやPCに直接インストールするタイプ。動作は速いが、機種ごとに作り分けが必要になることがある
• Webアプリケーション：ブラウザで動くタイプ。インストール不要でどの端末からもアクセスできる
• クラウドコンピューティング：自社でサーバーを持たず、外部のクラウド事業者の設備を借りる考え方。SaaS（ソフトウェアごと借りる）、PaaS（実行環境を借りる）、IaaS（サーバー機材そのものを借りる）の3段階がある

これは、住まいの選び方に似ています。SaaSは家具付きの賃貸マンション、PaaSは骨組みだけの賃貸物件、IaaSは更地を借りて自分で家を建てるようなものです。自由度が上がるほど、自分でやることも増えます。

オンプレミス（自社にサーバーを設置する）とクラウドの違いも押さえておきましょう。オンプレミスは持ち家、クラウドは賃貸、とたとえるとイメージしやすいはずです。

🗣️ 要約

• ウォーターフォールは要件→設計→実装→テストの順に後戻りしない前提で進める
• 反復型・インクリメンタル・アジャイルは小さな単位に区切って繰り返し作る
• バージョン管理にはGit-flowのブランチ運用やWIP PRが関わる

最後は「どんな手順で作るか」です。Day2で開発モデルの例（ウォーターフォール、V字、アジャイル等）に軽く触れましたが、ここではもう一歩踏み込みます。

• ウォーターフォール：要件→設計→実装→テストの順に、後戻りしない前提で進める
• 反復型・インクリメンタル・イテレーション：小さな単位に区切って繰り返し作り、少しずつ機能を増やしていく
• アジャイル（XP、Scrum）：短い期間（1〜2週間程度）で計画・実装・レビューを繰り返し、変化に柔軟に対応する

バージョン管理システムも開発手法と深く関わります。複数人で同じソースコードを扱うとき、Git-flowのようなブランチ運用ルールや、WIP（Work In Progress）のPR（Pull Request、まだ完成していないが早めにレビューしてもらう提案）を使うと、チーム開発が円滑に進みます。

なぜ開発手法がこんなにたくさんあるのでしょうか。ここで少し考えてみてください。次のセッションの演習で、まさにこの問いに取り組みます。

REST APIのやりとりのイメージ（実際にDay4で作成するAPIのレスポンス例）：

{
  "id": 1,
  "name": "サンプル情報",
  "createdAt": "2026-08-24"
}

特に注意してほしいのは、「RESTだから軽い・SOAPだから重い」と単純に優劣で覚えないことです。SOAPは金融系など厳格な取り決めが必要な場面で今も使われています。よくある間違いとして「新しい技術＝常に正しい選択」という思い込みがありますが、正しくは「要件（例えばDay2で定義した非機能要件）に合わせて選ぶ」ことです。

RESTという言葉は、実は2000年にロイ・フィールディングという研究者が書いた博士論文の中で提唱されました。もともとは「Web全体をどう設計すべきか」という壮大な考察から生まれた言葉です。今や世界中のスマホアプリが使っている技術の起源が、たった1本の博士論文だったというのは、なんだかロマンがある話だと思いませんか。

🗣️ 要約

• RESTとSOAPの違いの身近な例、SaaS・PaaS・IaaSを自分たちの開発テーマに当てはめた場合、アジャイルとウォーターフォールの実務での使い分けをAIに質問できる

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

• 「RESTとSOAPの違いを、もっと身近な例で説明して」
• 「SaaS・PaaS・IaaSの違いを、自分たちの開発テーマに当てはめるとどうなる？」
• 「アジャイルとウォーターフォールは、実務ではどう使い分けられているの？」

🗣️ 要約

• 開発テーマのシステムをどの実行方式（ネイティブ／Web／クラウド）で動かすか1つ選び、理由を挙げる演習

🗣️ 要約

• 開発テーマのシステムを「ネイティブアプリ／Webアプリ／クラウド（SaaS・PaaS・IaaS）」のどの形で動かすか1つ選び、理由を2つ以上挙げる

チームで、開発テーマのシステムを「ネイティブアプリ／Webアプリ／クラウド（SaaS・PaaS・IaaS）」のどの形で動かしたいか1つ選び、理由を2つ以上挙げてください。

🗣️ 要約

• 選んだ実行方式と、その理由を書いたメモ（1〜2行）

選んだ実行方式と、その理由を書いたメモ（1〜2行で構いません）

🗣️ 要約

• ペルソナが使う端末や、Day2で決めた保守期間から逆算すると選びやすい
• 決めきれない場合はAIに意見を聞き、自分たちの案と比較するとよい

迷ったら、「ペルソナはどんな端末で使うことが多いか」「保守期間（Day2で決めたもの）は何年だったか」から逆算すると選びやすくなります。決めきれない場合は、AIに「（開発テーマ）ならどの実行方式が向いていると思う？」と聞いて、自分たちの案と比較してみましょう。

🗣️ 要約

• 情報をどう届けるか（通信）、どこで動かすか（実行方式）、どう作るか（開発手法）という3つの地図を得た
• 次回は「なぜ開発手法が複数あるのか」を演習で考察する

今回学んだことを一言でまとめると、「情報をどう届けるか（通信）」「どこで動かすか（実行方式）」「どう作るか（開発手法）」という、実装に踏み出す前の3つの地図を手に入れた、ということです。

次回は「なぜ開発手法が複数あるのか」を演習で考察します。今回の内容がそのまま材料になるので、しっかり振り返っておきましょう。

🗣️ 要約

• REST/JSONとSOAP/XMLの違いを説明できるか
• 自分たちの開発テーマならSaaS・PaaS・IaaSのどれが向いているか言えるか

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

• REST/JSONとSOAP/XMLの違いを説明できますか？
• 自分たちの開発テーマなら、SaaS・PaaS・IaaSのどれが向いているか言えますか？

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

🗣️ 要約

• 参考リンクは特になし
• 発展課題は、自分たちの開発テーマのAPIをSOAPで作るとしたらどんなXMLになるかをAIと一緒に1件書き出すこと

• 参考リンク: なし（社内資料のみで完結する内容のため、外部リンクは各自の関心に応じてAIに聞きながら探索してください）
• 発展課題: 自分たちの開発テーマのAPIを、SOAPで作るとしたらどんなXMLになるか、AIと一緒に1件だけ書き出してみる

🗣️ 要約

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

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

🗣️ 要約

• RPCは「手続きを呼ぶ」発想、RESTは「リソースをやりとりする」発想という視点の違いがある
• クラウドを使っても非機能要件の性能設計やセキュリティ設計は引き続き必要
• アジャイルでも設計は毎回行っており、設計をしなくてよいわけではない

🗣️ 要約

• RESTとHTTPを同じものと思ってしまいやすいが、HTTPは通信の土台、RESTはその上の設計の考え方
• SaaS/PaaS/IaaSの境界があいまいになりやすい
• 開発手法を新しさで序列化してしまいやすいが、向き不向きはプロジェクトの不確実性やチーム規模で決まる