CONTENT
ここから
「作れるけど、それやって大丈夫？」
― 法律・個人情報・ストア規約まで考えて、世の中に出せるアプリへ ―
1. 前回までのストーリー
第1回では、
面白いアプリを考える
↓
必要な機能を考える
↓
Flutter以外に何が必要か調べる
↓
Database
Authentication
Storage
Payment
Notification
管理画面
まで考えました。
第2回では、
機能
↓
タスク
↓
工数
↓
開発期間
↓
開発費
↓
MVP
まで整理しました。
そして、ついに、
100万円版のアプリ
が完成しました。
2. 開発開始！
社長：
「よし、この内容で開発しよう！」
あなた：
「はい！」
そこへ、
別の人が入ってきます。
3. 新しい登場人物
法務・セキュリティ担当
です。
あなたの企画書を見ながら、
こう質問します。
「ユーザーから何の情報を取得しますか？」
あなた：
「名前、メールアドレス、電話番号、生年月日、位置情報、プロフィール写真です。」
担当者：
「全部必要ですか？」
……
4. 今日のテーマ
今日考えるのは、
「作れるか？」
ではありません。
今日考えるのは、
「やって大丈夫か？」
です。
5. 今日のゴール
授業が終わったとき、
次のことができる状態を目指します。
- アプリで扱うデータを整理できる
- 本当に必要な個人情報だけを考えられる
- 法律とストア規約を分けて考えられる
- プライバシーポリシーが必要な理由を説明できる
- アカウント削除を設計に入れられる
- 写真・位置情報・AIなどのリスクを発見できる
- 課金方法によって確認事項が変わることを理解する
- 他人のアプリを「審査する視点」で見られる
- 自分のアプリを公開前にチェックできる
6. 最初に大切なこと
この授業では、
法律を暗記することが目的ではありません。
また、
「これは合法です」
「これは違法です」
と学生だけで最終判断する授業でもありません。
今日身につけるのは、
「ここは確認が必要では？」
と気づく力です。
7. 実務では3つを分けて考える
アプリを公開するとき、
少なくとも、
法律
ストア規約
サービス独自の利用規約
を分けて考える必要があります。
つまり、
法律上問題ない
だけでは、
App StoreやGoogle Playで公開できるとは限りません。
逆に、
ストアで公開できた
からといって、
すべての法的確認が終わったという意味でもありません。
8. GAME 1
「このアプリ、何個怪しい？」
架空のアプリを用意しました。
アプリ名：
Campus Connect
専門学生向けのSNSアプリです。
9. Campus Connectの仕様
このアプリでは、
・氏名を取得
・電話番号を取得
・生年月日を取得
・学校名を取得
・GPSを常時取得
・プロフィール写真を取得
・友達の位置を地図に表示
・他サイトから取得した画像を使用
・ユーザーの投稿をAIへ送信
・有料プレミアム機能あり
・退会ボタンなし
・プライバシーポリシーなし
・利用規約なし
という仕様になっています。
10. ミッション
この中から、
「ちょっと待って」
と思うところを、
できるだけ多く探してください。
怪しいところ：
1.
2.
3.
4.
5.
6.
7.
8.
11. 判定は3種類
各項目を、
次の3つに分類します。
○ 問題なさそう
△ 確認が必要
× この設計のままでは危険そう
まだ法律を調べなくて構いません。
まずは、
自分の感覚で判定
してみます。
12. 答え合わせの前に
例えば、
「電話番号を取得している」
というだけで、
必ず問題になるわけではありません。
重要なのは、
何のために必要？
本当に必要？
どこに保存？
誰が使う？
いつまで保存？
誰かに送る？
削除できる？
です。
13. 今日の重要キーワード①
データ最小化
アプリを作ると、
つい、
「あとで使うかもしれないから取っておこう」
となりがちです。
しかし、
必要以上にデータを持つほど、
管理する責任も増えます。
Google Playのユーザーデータポリシーでも、アプリの機能に必要なデータのみを収集・使用することが求められています。
14. 実習①
「本当に必要？」
Campus Connectが、
単純に、
学生同士がイベント情報を見るアプリ
だったとします。
次の情報は本当に必要でしょうか？
| データ | 必要？ | 何に使う？ |
|---|---|---|
| 氏名 | ||
| メール | ||
| 電話番号 | ||
| 生年月日 | ||
| 学校名 | ||
| GPS | ||
| 顔写真 | ||
| 性別 | ||
| 住所 |
15. 「取れる」ではなく「必要か」
例えば、
イベント一覧を見るだけなら、
住所
は必要でしょうか？
プロフィールにニックネームだけ表示するなら、
本名
は必要でしょうか？
メールログインなら、
電話番号
は必要でしょうか？
16. 自分のアプリへ戻る
第1回で作った自分のアプリについて、
取得する情報を書き出してください。
【取得する情報】
□ 氏名
□ メールアドレス
□ 電話番号
□ 生年月日
□ 位置情報
□ 写真
□ 動画
□ 決済関連情報
□ 行動履歴
□ その他
17. 実習②
データ棚卸し
| データ | なぜ必要？ | 保存先 | 誰が見る？ | 削除方法 |
|---|---|---|---|---|
ここで、
理由を書けないデータ
があったら、
本当に必要なのか考えてみましょう。
18. 個人情報とは？
日本では、
個人情報保護法や関連ガイドラインがあります。
個人情報保護委員会は、個人情報・個人識別符号・要配慮個人情報などについてガイドラインを公開しています。2026年6月にも通則編が改正されています。
19. 今日覚えてほしいこと
法律の条文を全部覚える必要はありません。
実務で重要なのは、
個人情報を扱っている？
↓
何を取得している？
↓
目的は？
↓
どう保存する？
↓
誰と共有する？
↓
削除できる？
↓
法律・規約上の確認が必要？
という流れです。
20. GAME 2
「情報泥棒を止めろ！」
先生が、
機能を読み上げます。
その機能に対して、
どのデータまでなら必要そうか
を考えてください。
21. CASE A
天気アプリ
現在地の天気を表示したい。
必要そうなのは？
□ 氏名
□ 電話番号
□ 正確な位置情報
□ おおまかな地域
□ 顔写真
□ 生年月日
22. CASE B
イベント予約アプリ
予約確認メールを送りたい。
必要そうなのは？
□ メールアドレス
□ GPS
□ 顔写真
□ 身長
□ 電話番号
□ 住所
23. CASE C
フォトSNS
プロフィール写真を投稿できる。
必要そうなのは？
□ 写真ライブラリへのアクセス
□ マイク
□ GPS
□ カメラ
□ 連絡先
AppleのApp Reviewガイドラインでも、不要なデータアクセスへの同意をユーザーへ強制しないことや、可能なら代替手段を用意することが示されています。
24. 権限を要求するとき
例えば、
アプリを開いた瞬間に、
位置情報を許可してください
写真を許可してください
カメラを許可してください
マイクを許可してください
と全部出されたら、
どう感じますか？
25. ユーザーの気持ち
ユーザー：
「なんでこのアプリにマイクが必要なの？」
となります。
だから、
必要なタイミングで、必要な理由を説明する
という設計も重要です。
26. CASE
例えば、
地図上で近くのイベントを探す機能があります。
位置情報を拒否したユーザーには、
利用不可
ではなく、
都道府県を手動選択
という別の方法を用意できるかもしれません。
Appleも、例えば位置情報への同意がない場合に住所を手動入力するような代替手段を例示しています。
27. GAME 3
「権限を減らせ！」
自分のアプリが要求する権限を書きます。
□ カメラ
□ 写真
□ 位置情報
□ マイク
□ Bluetooth
□ 通知
□ その他
そして、
それぞれ、
絶対必要
あると便利
なくても使える
の3つに分類してください。
28. 次の事件
ユーザーがアプリを使い始めました。
登録者：
10,000人
順調です。
ところが、
あるユーザーから連絡が来ました。
「アカウントを消してください。」
……
あなたのアプリには、
退会ボタンがありません。
29. GAME 4
「消したいのに消せない！」
あなたならどうしますか？
A. メールで連絡してください
B. アプリを削除すれば退会扱い
C. アカウント削除機能を作る
D. データは永久保存する
30. App Storeの場合
Appleでは、
アプリ内でアカウントを作成できるアプリについて、
アプリ内からアカウント削除を開始できるようにすることが求められています。関連する個人データについても、法的に保持が必要なものを除き削除する考え方が示されています。
31. Google Playの場合
Google Playでも、
アプリ内でアカウントを作成できる場合、
アカウント削除をリクエストできる仕組みが必要です。
Google Playでは、
アプリ内だけでなく、
外部のウェブリソースから削除を開始できる方法も求めています。
32. 「アプリを消す」と「アカウントを消す」は違う
ユーザーが、
スマホからアプリを削除
しても、
Backend側には、
名前
メール
投稿
予約履歴
プロフィール
写真
などが残っているかもしれません。
つまり、
アプリ削除
≠
アカウント削除
です。
33. 実習③
「退会したら何を消す？」
自分のアプリについて考えます。
| データ | 削除？ | 残す？ | 理由 |
|---|---|---|---|
| アカウント | |||
| プロフィール | |||
| 投稿 | |||
| 写真 | |||
| 購入履歴 | |||
| ログ | |||
| その他 |
34. 注意
すべてのデータを必ず即時削除すればよい、
という単純な話ではありません。
法令上の保存義務や、不正防止など、
保持が必要になるケースも考えられます。
Google Playも、正当な理由により保持するデータがある場合は、その保持方針をユーザーへ明示するよう求めています。
35. つまり設計時点で考える
ユーザー登録
を作ったなら、
同時に、
アカウント削除
も考える。
これは、
公開直前に追加するものではありません。
36. 次の事件
Campus Connectでは、
ユーザーが写真を投稿できます。
ある日、
ユーザーが、
有名アニメの画像をアップロードしました。
さらに別のユーザーが、
他人のInstagram写真を保存して投稿しました。
……
誰が対応するのでしょう？
37. GAME 5
「この画像、使っていい？」
次の画像をアプリに掲載するとします。
どれが気になりますか？
A. 自分で撮影した写真
B. 友達が撮った写真
C. Google画像検索で見つけた写真
D. Instagramから保存した写真
E. 生成AIで作った画像
F. 素材サイトから取得した画像
38. 「インターネットにある＝使っていい」ではない
画像や動画には、
著作権などの権利が関係します。
また、
人物が写っていれば、
別の権利・プライバシーの問題も考える必要があります。
だから、
「どこから入手した？」
を確認します。
39. 素材サイトでも確認する
素材サイトなら、
なんでも自由、
ではありません。
確認するのは、
商用利用できる？
改変できる？
クレジット表記が必要？
アプリで使える？
再配布できる？
AI学習などの制限は？
などです。
40. ユーザー投稿型アプリはさらに考える
自分たちが画像を掲載しなくても、
ユーザーが投稿できるなら、
違法な投稿
嫌がらせ
他人の写真
不適切なコンテンツ
著作権侵害の疑い
が発生する可能性があります。
41. すると必要になるもの
例えば、
通報
ブロック
投稿削除
管理画面
問い合わせ窓口
利用規約
運営ルール
などが必要になるかもしれません。
つまり、
SNS機能1個
を追加しただけでも、
運用設計が増える可能性があります。
42. 第2回とのつながり
前回、
チャット機能：5日
と見積もったとします。
しかし、
本当は、
チャット
＋ ブロック
＋ 通報
＋ 削除
＋ 管理
＋ 規約
＋ 運用
まで必要になるかもしれません。
すると、
見積もりも変わる
わけです。
43. 次の事件
社長：
「AI流行ってるし、AIチャットも入れよう。」
ユーザー：
「学校生活の悩みを相談できるようにして！」
開発者：
「APIにつなげれば作れそうです。」
……
本当にそれだけでしょうか？
44. AIを入れるとデータの流れが変わる
例えば、
ユーザー
↓
Flutter
↓
自社Backend
↓
外部AIサービス
↓
回答
になります。
つまり、
ユーザーが入力したデータが、
自分たちの会社以外
へ送られる可能性があります。
45. 実習④
「データはどこへ行く？」
自分のアプリのデータの流れを書きます。
例えば、
ユーザー
↓
Flutter
↓
Supabase
↓
外部AI API
↓
結果をFlutterへ返す
46. ここで質問
AIへ送る内容に、
氏名
メール
健康情報
学校名
位置情報
相談内容
などが含まれていたら、
何を確認する必要がありそうでしょうか？
47. AIだから特別、ではない
大切なのは、
外部サービスに何を送っているか
です。
AI以外でも、
Analytics
広告SDK
決済
SMS
メール配信
Crash Monitoring
など、
外部サービスへデータを送る可能性があります。
48. 実習⑤
外部サービス監査
| 外部サービス | 何を送る？ | なぜ必要？ | ユーザーへ説明が必要？ |
|---|---|---|---|
49. 今日の重要キーワード②
プライバシーポリシー
簡単に言えば、
ユーザーに対して、
何を取得する？
何のため？
誰と共有する？
どう管理する？
いつまで持つ？
削除は？
問い合わせ先は？
などを説明するものです。
50. Google Playでは？
Google Playでは、すべてのアプリについて包括的なプライバシーポリシーへのリンクが求められ、アプリ内からもアクセスできるようにすることが示されています。収集・利用・共有・保持・削除などの取り扱いを正確に説明する必要があります。
51. 「テンプレを貼れば完成」ではない
例えば、
プライバシーポリシーに、
位置情報は取得しません
と書いている。
でも実際のアプリは、
GPSを取得している
なら、
内容が一致していません。
52. 実装と文章を一致させる
実際に取得しているデータ
＝
ストア申告
＝
プライバシーポリシー
が、
矛盾しないことが重要です。
53. GAME 6
「プライバシーポリシー監査」
先生から、
架空のプライバシーポリシーを渡されたとします。
記載：
当アプリは個人情報を取得しません。
しかしアプリは、
メールログイン
位置情報
プロフィール写真
Analytics
Crash Monitoring
を使用しています。
どこがおかしい？
話し合ってください。
54. 次の事件
いよいよ、
アプリでお金を稼ぐことになりました。
プレミアムプラン 月額1,000円
を追加します。
社長：
「Stripeつなげればいいよね？」
……
本当にそれでいいのでしょうか？
55. GAME 7
「1,000円課金したい！」
次のどちらを売るか考えます。
A
アプリ内で使う
プレミアム機能
B
実際のイベント参加チケット
この2つは、
同じ「1,000円」でも、
扱いが同じでしょうか？
56. デジタルとリアルを分ける
例えば、
アプリ内の追加機能
ゲーム内アイテム
デジタルコンテンツ
サブスクリプション
と、
飲食物
洋服
配車
現地イベント
物理サービス
では、
ストアの支払いルールが異なる場合があります。
57. Google Playの場合
Google Playでは、原則として、Playで配信するアプリ内のデジタル商品・サービスについてGoogle Playの課金システムを利用する必要があります。一方、物理的な商品や物理的なサービスなどは別の扱いです。
58. Appleの場合
Appleでも、デジタル商品・機能・サブスクリプションなどにApple In-App Purchaseが用意されています。
ただし、日本のApp Storeでは2026年時点でデジタル商品・サービスについて代替決済を提供できる仕組みも導入されています。利用には追加の要件があり、代替決済を使う場合は決済・返金・税・プライバシーなどについて開発者側の責任も増えます。
59. 重要
ストアの決済ルールは、
国
商品の種類
配布方法
最新のストア規約
によって変わる可能性があります。
そのため、
「昔こうだった」
ではなく、
授業や実務の時点で、
公式情報を確認します。
60. 実習⑥
自分の課金はどっち？
自分のアプリで売るものを書きます。
販売するもの：
________________________
次に、
□ デジタル商品
□ デジタルサービス
□ 物理商品
□ 現実世界のサービス
□ 分からない
に分類します。
61. 次に調査
App Storeではどう扱われる？
Google Playではどう扱われる？
外部決済は使える？
ストア課金が必要？
手数料は？
例外は？
日本独自の条件は？
を、
公式サイトで調べます。
62. 調査ルール
料金・手数料・規約は変わる可能性があります。
だから、
授業資料に書かれている数字を、
暗記しない
でください。
調べる場所を覚えます。
Apple Developer
Google Play Console Help
公式決済サービス
公的機関
を優先します。
63. MINI GAME
「売上1,000円は誰のもの？」
紙に、
1,000円
と書きます。
この1,000円から、
何が引かれる可能性があるでしょう？
□ ストア関連手数料
□ 決済関連手数料
□ サーバー費
□ AI API費
□ 運営費
□ 税務上の費用
□ その他
64. 売上と利益は違う
売上
≠
利益
です。
例えば、
売上
↓
決済関連
↓
システム原価
↓
広告費
↓
人件費
↓
その他費用
↓
利益
となります。
この話は、
第4回にもつながります。
65. GAME 8
「あなたはApp Store / Google Play審査員です」
ここから、
立場を変えます。
あなたは、
アプリを作る人
ではありません。
今日から、
審査する人
です。
66. 審査対象
別チームのアプリについて、
次の項目を確認してください。
□ 本当にログインが必要？
□ 不要な個人情報を取っていない？
□ 必要以上の権限を要求していない？
□ アカウント削除はある？
□ プライバシーポリシーは？
□ 外部サービスへのデータ送信は？
□ 写真・動画の権利は？
□ ユーザー投稿への対応は？
□ 決済方法は？
□ 未成年利用は？
□ 通報・ブロックは必要？
□ 説明不足な部分は？
67. 判定方法
3つの判定を使います。
APPROVED
大きな問題は見つからなかった。
NEEDS REVIEW
確認が必要。
NEEDS FIX
このまま公開するのは危険そう。
68. ルール
重要なのは、
「なんとなくダメ」
ではありません。
理由を書きます。
例えば、
判定：
NEEDS REVIEW
理由：
位置情報を常時取得していますが、
アプリの主要機能に必要なのか
説明がありません。
確認すること：
・取得目的
・取得タイミング
・代替手段
・プライバシーポリシー
という形です。
69. 実習⑦
他チームを審査する
| 項目 | 判定 | 理由 |
|---|---|---|
| 個人情報 | ||
| 権限 | ||
| アカウント削除 | ||
| プライバシー | ||
| 外部サービス | ||
| 著作権 | ||
| 決済 | ||
| 運営 |
70. 審査された側は反論してよい
例えば、
審査員：
「電話番号は不要では？」
開発チーム：
「緊急連絡に必要です。」
審査員：
「メールではダメですか？」
開発チーム：
「○○という理由で電話番号が必要です。」
というように、
なぜ必要なのか
を説明します。
71. ここが重要
技術選定と同じです。
電話番号を使う
こと自体が正解・不正解ではありません。
大切なのは、
「なぜ？」
です。
72. 次のミッション
他人のアプリを審査したら、
今度は、
自分のアプリ
を審査します。
73. FINAL GAME
「自分のアプリを公開前監査せよ」
第1回から作ってきた、
自分のアプリを開いてください。
今日は、
公開前日
だと思ってください。
74. STEP 1
データを確認する
取得するデータ：
1.
2.
3.
4.
5.
75. STEP 2
それぞれについて、
何のため？
本当に必要？
どこに保存？
誰が見る？
誰かと共有する？
いつ消す？
を答えます。
76. STEP 3
権限を確認
□ カメラ
□ 写真
□ 位置情報
□ マイク
□ 通知
□ その他
各権限に、
「なぜ必要？」
を書きます。
77. STEP 4
外部サービス確認
| サービス | 送るデータ | 使用目的 |
|---|---|---|
| Database | ||
| Analytics | ||
| AI | ||
| 決済 | ||
| Monitoring | ||
| その他 |
78. STEP 5
アカウント削除
アカウント作成：
する / しない
削除方法：
________________
削除するデータ：
________________
保持するデータ：
________________
保持する理由：
________________
79. STEP 6
ユーザー投稿
ユーザー投稿：
ある / ない
ある場合、
□ 通報
□ ブロック
□ 削除
□ 管理画面
□ 問い合わせ
□ 利用規約
□ その他
について考えます。
80. STEP 7
課金
課金：
ある / ない
販売するもの：
________________
デジタル / 物理：
________________
決済方法：
________________
App Store確認：
済 / 要確認
Google Play確認：
済 / 要確認
81. STEP 8
必要な文章・画面
□ プライバシーポリシー
□ 利用規約
□ アカウント削除
□ 問い合わせ
□ 権限説明
□ 課金説明
□ 返金・キャンセル関連
□ その他
82. STEP 9
公開判定
自分のアプリを、
次の3つから選びます。
APPROVED
NEEDS REVIEW
NEEDS FIX
83. 判定理由
判定：
________________
一番大きなリスク：
________________
公開前に直すもの：
1.
2.
3.
84. ここまでで気づいたこと
第2回では、
ログイン機能
3人日
と考えていたかもしれません。
でも今日、
ログイン
＋ アカウント削除
＋ プライバシー
＋ データ管理
＋ 権限
＋ セキュリティ
＋ ストア対応
まで考える必要があることが分かりました。
85. つまり見積もりにも戻ってくる
法律や規約の問題は、
法務担当だけの話ではありません。
例えば、
アカウント削除画面
を追加するなら、
開発工数が増えます。
管理画面
が必要になれば、
開発費が増えます。
通報・ブロック
が必要なら、
Database設計も変わります。
86. 第1回から全部つながっている
アイデア
↓
機能
↓
システム構成
↓
コスト
↓
工数
↓
法律
↓
規約
↓
運用
全部、
別々の話ではありません。
87. GAME 9
「1つ追加すると何が変わる？」
先生が、
次のカードを1枚出します。
CARD A
位置情報機能を追加
CARD B
ユーザー投稿を追加
CARD C
月額課金を追加
CARD D
AIチャットを追加
CARD E
未成年ユーザーを追加
88. 影響を書き出す
追加機能：
________________
Flutterへの影響：
________________
Backendへの影響：
________________
Databaseへの影響：
________________
コストへの影響：
________________
法律・規約：
________________
運用：
________________
89. システム設計は「機能表」ではない
例えば、
AIチャット
と1行書くだけなら簡単です。
しかし、
実務では、
ユーザー
↓
機能
↓
データ
↓
システム
↓
費用
↓
法律
↓
運用
までつなげて考えます。
90. 今日の最終発表
自分のアプリについて、
次の6つを説明してください。
① どんなアプリ？
② どんなデータを取る？
③ 一番気になる法律・規約上のポイントは？
④ 何を削った・変更した？
⑤ 公開前に何を確認する？
⑥ 現時点で公開できる？
91. 他の学生は質問する
例えば、
「その位置情報、本当に必要？」
「電話番号じゃないとダメ？」
「退会したら写真は消える？」
「AIに何を送ってる？」
「ユーザーが他人の写真を投稿したら？」
「1,000円課金は何を売ってるの？」
「プライバシーポリシーと実装は一致してる？」
などです。
92. 今日覚えてほしい考え方
技術的にできる
≠
何でもやっていい
です。
アプリを世の中に出すなら、
必要性
安全性
法律
規約
ユーザーへの説明
運用
まで考えます。
93. 第3回クリアチェック
□ 必要なデータだけを考えられる
□ データの保存先を説明できる
□ 外部サービスへの送信を意識できる
□ 必要な権限を整理できる
□ アカウント削除を考えられる
□ プライバシーポリシーの役割を理解した
□ 著作権などの確認が必要だと理解した
□ ユーザー投稿には運用が必要だと理解した
□ 課金方法によってストア確認が必要だと理解した
□ 法律とストア規約を分けて考えられる
□ 他人のアプリを審査できる
□ 自分のアプリを公開前に監査できる
ここまでできれば、
LEVEL 3 CLEAR
です。
94. これで完璧？
あなたのアプリは、
技術的に作れる
↓
予算内にした
↓
期間も考えた
↓
法律・規約も確認した
ところまで来ました。
かなり完成に近づきました。
95. しかし、また問題が起きます
アプリを公開する直前、
会議を開きました。
そこに、
いろいろな人が参加しています。
96. ユーザー
「できれば無料で使いたい。」
97. 社長
「利益を出したい。」
98. 開発者
「機能を増やしすぎると保守できません。」
99. 運営担当
「管理画面が使いにくいと毎日困ります。」
100. セキュリティ担当
「個人情報を減らしてください。」
101. ストア側
「ルールに従ってください。」
102. 全員の言っていることは正しい
ユーザーの、
安くしてほしい
も分かります。
会社の、
利益を出したい
も分かります。
開発者の、
複雑にしたくない
も分かります。
運営担当の、
簡単に管理したい
も分かります。
103. でも全部同時にできる？
例えば、
完全無料
高機能
広告なし
サーバー高性能
24時間サポート
セキュリティ最高
利益も出す
を、
すべて同時に実現できるでしょうか？
104. 最後の問題
これまでは、
「システム」
を中心に考えてきました。
次回は、
「人」
を中心に考えます。
105. 次回の登場人物
ユーザー
会社
開発者
運営担当
セキュリティ担当
プラットフォーム
それぞれ、
違う目的を持っています。
106. 次回のゲーム
学生一人ひとりに、
役割カード
を配ります。
例えば、
ユーザー役：
できるだけ無料。
操作は簡単。
個人情報は渡したくない。
会社役：
売上を増やしたい。
運営費を下げたい。
開発者役：
短期間で作りたい。
複雑な保守は避けたい。
運営役：
問い合わせを減らしたい。
管理を簡単にしたい。
107. 全員ワガママ会議
全員が、
自分の立場から、
「こうしてほしい！」
と主張します。
おそらく、
話はまとまりません。
108. そこでルールを変えます
先生：
「誰か1人だけが得する案は禁止です。」
さて、
どうすればよいでしょう？
109. NEXT MISSION
第4回
「誰が得するアプリなら続く？」
次回は、
ユーザーの利益
会社の利益
開発者の利益
運営の利益
安全性
プラットフォームのルール
を同時に考えます。
110. そして最後に
4回の授業でやってきたことに、
ある名前をつけます。
その考え方の一つが、
「ゲーム理論」
です。
ただし、
次回の最初から答えを教えません。
まず、
全員の利害がぶつかる
ところを体験してもらいます。
111. 第3回終了
第1回：
「何が必要？」
第2回：
「いくら？何日？」
第3回：
「やって大丈夫？」
そして最終回は、
「誰にとって良いシステム？」
を考えます。
あなたのアプリは、
「作れるアプリ」
から、
「公開できるアプリ」
になってきました。
次は、
「続けられるアプリ」
へ進化させます。