CONTENT
ここから
「そのアプリ、本当に100万円で作れる？」
― アイデアを「見積もれる仕事」に変える ―
1. 前回までのストーリー
前回、あなたはアプリ開発チームのメンバーとして、
100万円
の予算を渡されました。
そして、
誰が使う？
↓
何を解決する？
↓
どんな機能が必要？
↓
Flutter以外に何が必要？
↓
Database
↓
Authentication
↓
Storage
↓
Payment
↓
Notification
↓
管理画面
↓
運用
↓
どこにお金がかかる？
まで考えました。
かなり「アプリらしく」なってきました。
2. そして社長に企画を見せました
あなた：
「こんなアプリを作ります！」
社長：
「いいね！」
あなた：
「Flutterを使って、Databaseはこれで、認証は……」
社長：
「うんうん。」
そして最後に、
社長から聞かれます。
「で、いつ完成するの？」
……
さらに、
「100万円で足りるよね？」
……
今日は、この質問に答えられるようになります。
3. 今日のミッション
今日のゴールは、
「なんとなく100万円」から卒業すること。
授業が終わる頃には、
- アプリを機能へ分解できる
- 機能を作業へ分解できる
- 開発工数を考えられる
- 開発費を概算できる
- 見落としやすい作業を発見できる
- 予算オーバーしたときに機能を整理できる
- MVPを説明できる
- 自分の見積もりの根拠を説明できる 状態を目指します。
4. 最初の問題
次の依頼を受けました。
「Instagramみたいなアプリを作ってください。」
質問です。
何日で作れますか？
5. たぶん答えられない
なぜでしょう？
「Instagramみたいなアプリ」
という言葉の中には、
たくさんの機能が隠れています。
例えば、
ユーザー登録
ログイン
プロフィール
写真投稿
動画投稿
いいね
コメント
フォロー
検索
DM
通知
ブロック
通報
退会
管理画面
などです。
6. 「アプリ1個」では見積もれない
例えば、
Instagramみたいなアプリ
100万円
と言われても、
根拠がありません。
しかし、
ログイン
プロフィール
投稿
コメント
検索
通知
と分解すると、
少しずつ考えられるようになります。
7. 今日の重要キーワード①
機能分解
大きなものを、
見積もれる大きさまで小さくする
という考え方です。
8. GAME 1
「このアプリ、何個の機能が隠れてる？」
次のアプリを考えます。
イベント予約アプリ
一見すると、
イベントを見る
↓
予約する
だけに見えます。
本当にそれだけでしょうか？
9. グループで機能を探せ
思いつく機能をできるだけ多く書いてください。
例えば、
ログイン
以外は、まず自分たちで考えてみましょう。
10. 例えばこんな機能がある
会員登録
ログイン
パスワード再設定
プロフィール
イベント一覧
イベント詳細
検索
お気に入り
予約
予約確認
キャンセル
決済
Push通知
メール
QRチケット
履歴
退会
さらに運営側には、
イベント登録
イベント編集
予約一覧
ユーザー管理
返金対応
売上確認
お知らせ
管理者ログイン
などが考えられます。
11. ユーザーから見えない機能もある
実務では、
「ユーザーが使う機能」
だけを見てはいけません。
例えば、
ユーザー
↓
予約
したら、
裏側では、
予約できる？
↓
定員確認
↓
予約データ保存
↓
決済
↓
予約確定
↓
メール送信
↓
管理画面へ反映
などの処理が必要になる可能性があります。
12. 実習①
自分のアプリをバラバラにする
前回作った自分のアプリを使います。
まず、
ユーザー側
の機能を書いてください。
アプリ名：
【ユーザー機能】
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
13. 次に運営側
【運営・管理機能】
1.
2.
3.
4.
5.
6.
7.
8.
14. 「画面」と「機能」は違う
例えば、
ログイン画面
を1枚作れば、
ログイン機能が完成するでしょうか？
実際には、
画面
入力チェック
認証
エラー処理
ログイン状態保持
ログアウト
パスワード再設定
セキュリティ
Databaseとの連携
などを考える必要があります。
15. ボタン1個でも仕事はある
例えば、
[予約する]
というボタン。
見た目は、
1個
です。
でも押したら、
ログインしている？
↓
定員は空いている？
↓
同じ予約をしていない？
↓
決済は必要？
↓
予約データを保存
↓
成功した？
↓
失敗した？
↓
画面へ結果表示
↓
メール送信
などが必要になるかもしれません。
16. 今日の重要キーワード②
タスク分解
機能を、
実際の作業
へ分けます。
17. 例えば「ログイン機能」
ログイン機能
を、
ログイン画面設計
ログイン画面実装
入力チェック
Authentication設定
ログイン処理
エラー処理
ログアウト
パスワード再設定
テスト
へ分けます。
これなら、
「どのくらい仕事があるのか」
が見えてきます。
18. GAME 2
「そのボタン、本当に1日？」
先生から機能が出されます。
例えば、
「写真投稿」
これを作るために必要そうな仕事を、
できるだけ多く考えてください。
19. 写真投稿なら？
例えば、
写真を選択
カメラから撮影
プレビュー
画像サイズ確認
画像圧縮
アップロード
Storageへ保存
Databaseへ情報保存
投稿完了表示
失敗時の処理
削除
権限確認
テスト
などが考えられます。
20. 小さくすると見えてくる
写真投稿機能
だけでは、
簡単そうに見えます。
しかし、
写真選択
画像処理
Storage
Database
通信
エラー処理
テスト
まで分解すると、
必要な仕事が見えてきます。
21. 実習②
一番重要な機能を分解する
自分のアプリで、
一番重要な機能
を1つ選んでください。
機能名：
________________________
その機能を、
最低5個のタスクへ分解します。
1.
2.
3.
4.
5.
6.
7.
8.
22. ここで初めて「何日？」を考える
仕事が見えてきたら、
ようやく、
工数
を考えられます。
23. 工数とは？
簡単に言えば、
その仕事にどれくらいの作業量が必要か
です。
例えば、
画面実装：1日
API連携：2日
テスト：1日
なら、
単純化すると、
1 + 2 + 1
= 4人日
です。
24. 「人日」とは？
例えば、
1人日
は、
1人が1日作業する量として扱います。
1人 × 5日
= 5人日
2人 × 5日
= 10人日
という考え方です。
25. ただし注意
10人日
だから、
10人なら1日で完成！
とは限りません。
例えば、
Databaseが完成しないと
APIを完成できない
APIが完成しないと
Flutter側を確認できない
など、
作業には順番や依存関係があります。
26. GAME 3
「何日かかると思う？」
次の機能について、
まず自分で予想してください。
正解を当てるゲームではありません。
「なぜそう思ったか」
を説明するゲームです。
| 機能 | 自分の予想 | 理由 |
|---|---|---|
| ログイン | ||
| プロフィール | ||
| 検索 | ||
| 写真投稿 | ||
| Push通知 | ||
| 決済 | ||
| 管理画面 |
27. AIに聞いてみよう
次に、
ChatGPTなどの生成AIへ聞いてみます。
例えば、
Flutterでイベント予約アプリを開発します。
以下の機能について、
初心者のエンジニア1人で開発する場合の
タスクを分解してください。
・ログイン
・イベント一覧
・イベント詳細
・予約
・決済
・Push通知
各機能について、
1. 必要な作業
2. 工数に影響する要素
3. 見落としやすい作業
を整理してください。
工数は確定値ではなく、
見積もりの前提条件も示してください。
28. AIの数字は「答え」ではない
AIが、
ログイン：2日
決済：5日
と言ったとしても、
それだけで見積もりを確定してはいけません。
なぜなら、
メールログイン？
SMS？
Google？
Apple？
既存システムあり？
デザイン完成済み？
Backend完成済み？
テスト範囲は？
などで工数が変わるからです。
29. 実務で重要なのは「前提条件」
例えば、
ログイン機能：3人日
だけより、
ログイン機能：3人日
前提：
・メール＋パスワード
・既存の認証サービスを利用
・デザイン完成済み
・Google/Appleログインなし
の方が、
見積もりとして意味があります。
30. 実習③
自分のアプリを仮見積もりする
前回考えたアプリについて、
主要機能を5〜10個選びます。
| 機能 | 予想工数 | 前提・理由 |
|---|---|---|
31. 合計してみよう
例えば、
| 機能 | 工数 |
|---|---|
| Login | 3人日 |
| Event List | 3人日 |
| Detail | 2人日 |
| Search | 4人日 |
| Reservation | 5人日 |
| Payment | 7人日 |
| Notification | 3人日 |
| Admin | 7人日 |
合計すると、
34人日
です。
では、
34日で完成？
……
まだ早いです。
32. GAME 4
「消えた仕事を探せ！」
先ほどの見積もりには、
重要な仕事が大量に消えています。
何が足りないでしょうか？
グループで探してください。
33. コードを書く前にも仕事がある
例えば、
ヒアリング
要件整理
仕様決定
画面設計
UIデザイン
Database設計
API設計
環境構築
があります。
34. コードを書いた後にも仕事がある
例えば、
テスト
実機確認
バグ修正
セキュリティ確認
ストア申請
審査対応
マニュアル
リリース
監視設定
があります。
35. さらに「打ち合わせ」も仕事
実務では、
仕様確認
進捗確認
デザイン確認
顧客確認
修正依頼
レビュー
にも時間が必要です。
36. 開発期間の全体像
例えば、
企画・要件整理
↓
設計
↓
UI / UX
↓
Flutter
↓
Backend
↓
Database
↓
外部サービス連携
↓
テスト
↓
修正
↓
ストア申請
↓
リリース
まで考えます。
37. 実習④
「見えない仕事」を追加する
自分の見積もりに、
次の項目を追加してください。
| 作業 | 必要？ | 工数 |
|---|---|---|
| 要件整理 | ||
| UI設計 | ||
| DB設計 | ||
| API設計 | ||
| 環境構築 | ||
| テスト | ||
| 実機確認 | ||
| バグ修正 | ||
| ストア申請準備 | ||
| ドキュメント |
38. さあ、合計は？
最初、
主要機能だけ
34人日
だったものが、
例えば、
機能開発 34人日
設計 5人日
テスト 5人日
修正 3人日
リリース準備 3人日
────────────
合計 50人日
になったとします。
39. ここで「開発費」を考える
仮に、
1人日 ＝ 50,000円
として計算してみます。
※授業上の計算例です。実際の単価は企業・契約・職種・経験・地域などによって異なります。
50人日
×
50,000円
=
2,500,000円
……
250万円。
40. 社長から電話です
「え？」
「100万円って言ったよね？」
あなた：
「……。」
社長：
「100万円にして。」
41. GAME 5
「予算100万円しかありません」
ここからが、
今日のメインゲームです。
あなたの見積もり：
250万円
社長の予算：
100万円
差額：
150万円
さて、どうしますか？
第2回 実務で使えるFlutterアプリとは
「そのアプリ、本当に100万円で作れる？」
― アイデアを「見積もれる仕事」に変える ―
1. 前回までのストーリー
前回、あなたはアプリ開発チームのメンバーとして、
100万円
の予算を渡されました。
そして、
誰が使う？
↓
何を解決する？
↓
どんな機能が必要？
↓
Flutter以外に何が必要？
↓
Database
↓
Authentication
↓
Storage
↓
Payment
↓
Notification
↓
管理画面
↓
運用
↓
どこにお金がかかる？
まで考えました。
かなり「アプリらしく」なってきました。
2. そして社長に企画を見せました
あなた：
「こんなアプリを作ります！」
社長：
「いいね！」
あなた：
「Flutterを使って、Databaseはこれで、認証は……」
社長：
「うんうん。」
そして最後に、
社長から聞かれます。
「で、いつ完成するの？」
……
さらに、
「100万円で足りるよね？」
……
今日は、この質問に答えられるようになります。
3. 今日のミッション
今日のゴールは、
「なんとなく100万円」から卒業すること。
授業が終わる頃には、
- アプリを機能へ分解できる
- 機能を作業へ分解できる
- 開発工数を考えられる
- 開発費を概算できる
- 見落としやすい作業を発見できる
- 予算オーバーしたときに機能を整理できる
- MVPを説明できる
- 自分の見積もりの根拠を説明できる 状態を目指します。
4. 最初の問題
次の依頼を受けました。
「Instagramみたいなアプリを作ってください。」
質問です。
何日で作れますか？
5. たぶん答えられない
なぜでしょう？
「Instagramみたいなアプリ」
という言葉の中には、
たくさんの機能が隠れています。
例えば、
ユーザー登録
ログイン
プロフィール
写真投稿
動画投稿
いいね
コメント
フォロー
検索
DM
通知
ブロック
通報
退会
管理画面
などです。
6. 「アプリ1個」では見積もれない
例えば、
Instagramみたいなアプリ
100万円
と言われても、
根拠がありません。
しかし、
ログイン
プロフィール
投稿
コメント
検索
通知
と分解すると、
少しずつ考えられるようになります。
7. 今日の重要キーワード①
機能分解
大きなものを、
見積もれる大きさまで小さくする
という考え方です。
8. GAME 1
「このアプリ、何個の機能が隠れてる？」
次のアプリを考えます。
イベント予約アプリ
一見すると、
イベントを見る
↓
予約する
だけに見えます。
本当にそれだけでしょうか？
9. グループで機能を探せ
思いつく機能をできるだけ多く書いてください。
例えば、
ログイン
以外は、まず自分たちで考えてみましょう。
10. 例えばこんな機能がある
会員登録
ログイン
パスワード再設定
プロフィール
イベント一覧
イベント詳細
検索
お気に入り
予約
予約確認
キャンセル
決済
Push通知
メール
QRチケット
履歴
退会
さらに運営側には、
イベント登録
イベント編集
予約一覧
ユーザー管理
返金対応
売上確認
お知らせ
管理者ログイン
などが考えられます。
11. ユーザーから見えない機能もある
実務では、
「ユーザーが使う機能」
だけを見てはいけません。
例えば、
ユーザー
↓
予約
したら、
裏側では、
予約できる？
↓
定員確認
↓
予約データ保存
↓
決済
↓
予約確定
↓
メール送信
↓
管理画面へ反映
などの処理が必要になる可能性があります。
12. 実習①
自分のアプリをバラバラにする
前回作った自分のアプリを使います。
まず、
ユーザー側
の機能を書いてください。
アプリ名：
【ユーザー機能】
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
13. 次に運営側
【運営・管理機能】
1.
2.
3.
4.
5.
6.
7.
8.
14. 「画面」と「機能」は違う
例えば、
ログイン画面
を1枚作れば、
ログイン機能が完成するでしょうか？
実際には、
画面
入力チェック
認証
エラー処理
ログイン状態保持
ログアウト
パスワード再設定
セキュリティ
Databaseとの連携
などを考える必要があります。
15. ボタン1個でも仕事はある
例えば、
[予約する]
というボタン。
見た目は、
1個
です。
でも押したら、
ログインしている？
↓
定員は空いている？
↓
同じ予約をしていない？
↓
決済は必要？
↓
予約データを保存
↓
成功した？
↓
失敗した？
↓
画面へ結果表示
↓
メール送信
などが必要になるかもしれません。
16. 今日の重要キーワード②
タスク分解
機能を、
実際の作業
へ分けます。
17. 例えば「ログイン機能」
ログイン機能
を、
ログイン画面設計
ログイン画面実装
入力チェック
Authentication設定
ログイン処理
エラー処理
ログアウト
パスワード再設定
テスト
へ分けます。
これなら、
「どのくらい仕事があるのか」
が見えてきます。
18. GAME 2
「そのボタン、本当に1日？」
先生から機能が出されます。
例えば、
「写真投稿」
これを作るために必要そうな仕事を、
できるだけ多く考えてください。
19. 写真投稿なら？
例えば、
写真を選択
カメラから撮影
プレビュー
画像サイズ確認
画像圧縮
アップロード
Storageへ保存
Databaseへ情報保存
投稿完了表示
失敗時の処理
削除
権限確認
テスト
などが考えられます。
20. 小さくすると見えてくる
写真投稿機能
だけでは、
簡単そうに見えます。
しかし、
写真選択
画像処理
Storage
Database
通信
エラー処理
テスト
まで分解すると、
必要な仕事が見えてきます。
21. 実習②
一番重要な機能を分解する
自分のアプリで、
一番重要な機能
を1つ選んでください。
機能名：
________________________
その機能を、
最低5個のタスクへ分解します。
1.
2.
3.
4.
5.
6.
7.
8.
22. ここで初めて「何日？」を考える
仕事が見えてきたら、
ようやく、
工数
を考えられます。
23. 工数とは？
簡単に言えば、
その仕事にどれくらいの作業量が必要か
です。
例えば、
画面実装：1日
API連携：2日
テスト：1日
なら、
単純化すると、
1 + 2 + 1
= 4人日
です。
24. 「人日」とは？
例えば、
1人日
は、
1人が1日作業する量として扱います。
1人 × 5日
= 5人日
2人 × 5日
= 10人日
という考え方です。
25. ただし注意
10人日
だから、
10人なら1日で完成！
とは限りません。
例えば、
Databaseが完成しないと
APIを完成できない
APIが完成しないと
Flutter側を確認できない
など、
作業には順番や依存関係があります。
26. GAME 3
「何日かかると思う？」
次の機能について、
まず自分で予想してください。
正解を当てるゲームではありません。
「なぜそう思ったか」
を説明するゲームです。
| 機能 | 自分の予想 | 理由 |
|---|---|---|
| ログイン | ||
| プロフィール | ||
| 検索 | ||
| 写真投稿 | ||
| Push通知 | ||
| 決済 | ||
| 管理画面 |
27. AIに聞いてみよう
次に、
ChatGPTなどの生成AIへ聞いてみます。
例えば、
Flutterでイベント予約アプリを開発します。
以下の機能について、
初心者のエンジニア1人で開発する場合の
タスクを分解してください。
・ログイン
・イベント一覧
・イベント詳細
・予約
・決済
・Push通知
各機能について、
1. 必要な作業
2. 工数に影響する要素
3. 見落としやすい作業
を整理してください。
工数は確定値ではなく、
見積もりの前提条件も示してください。
28. AIの数字は「答え」ではない
AIが、
ログイン：2日
決済：5日
と言ったとしても、
それだけで見積もりを確定してはいけません。
なぜなら、
メールログイン？
SMS？
Google？
Apple？
既存システムあり？
デザイン完成済み？
Backend完成済み？
テスト範囲は？
などで工数が変わるからです。
29. 実務で重要なのは「前提条件」
例えば、
ログイン機能：3人日
だけより、
ログイン機能：3人日
前提：
・メール＋パスワード
・既存の認証サービスを利用
・デザイン完成済み
・Google/Appleログインなし
の方が、
見積もりとして意味があります。
30. 実習③
自分のアプリを仮見積もりする
前回考えたアプリについて、
主要機能を5〜10個選びます。
| 機能 | 予想工数 | 前提・理由 |
|---|---|---|
31. 合計してみよう
例えば、
| 機能 | 工数 |
|---|---|
| Login | 3人日 |
| Event List | 3人日 |
| Detail | 2人日 |
| Search | 4人日 |
| Reservation | 5人日 |
| Payment | 7人日 |
| Notification | 3人日 |
| Admin | 7人日 |
合計すると、
34人日
です。
では、
34日で完成？
……
まだ早いです。
32. GAME 4
「消えた仕事を探せ！」
先ほどの見積もりには、
重要な仕事が大量に消えています。
何が足りないでしょうか？
グループで探してください。
33. コードを書く前にも仕事がある
例えば、
ヒアリング
要件整理
仕様決定
画面設計
UIデザイン
Database設計
API設計
環境構築
があります。
34. コードを書いた後にも仕事がある
例えば、
テスト
実機確認
バグ修正
セキュリティ確認
ストア申請
審査対応
マニュアル
リリース
監視設定
があります。
35. さらに「打ち合わせ」も仕事
実務では、
仕様確認
進捗確認
デザイン確認
顧客確認
修正依頼
レビュー
にも時間が必要です。
36. 開発期間の全体像
例えば、
企画・要件整理
↓
設計
↓
UI / UX
↓
Flutter
↓
Backend
↓
Database
↓
外部サービス連携
↓
テスト
↓
修正
↓
ストア申請
↓
リリース
まで考えます。
37. 実習④
「見えない仕事」を追加する
自分の見積もりに、
次の項目を追加してください。
| 作業 | 必要？ | 工数 |
|---|---|---|
| 要件整理 | ||
| UI設計 | ||
| DB設計 | ||
| API設計 | ||
| 環境構築 | ||
| テスト | ||
| 実機確認 | ||
| バグ修正 | ||
| ストア申請準備 | ||
| ドキュメント |
38. さあ、合計は？
最初、
主要機能だけ
34人日
だったものが、
例えば、
機能開発 34人日
設計 5人日
テスト 5人日
修正 3人日
リリース準備 3人日
────────────
合計 50人日
になったとします。
39. ここで「開発費」を考える
仮に、
1人日 ＝ 50,000円
として計算してみます。
※授業上の計算例です。実際の単価は企業・契約・職種・経験・地域などによって異なります。
50人日
×
50,000円
=
2,500,000円
……
250万円。
40. 社長から電話です
「え？」
「100万円って言ったよね？」
あなた：
「……。」
社長：
「100万円にして。」
41. GAME 5
「予算100万円しかありません」
ここからが、
今日のメインゲームです。
あなたの見積もり：
250万円
社長の予算：
100万円
差額：
150万円
さて、どうしますか？
:
42. 選択肢を考える
予算が足りないからといって、
全部を雑に作る
ではいけません。
考えられる方法はいくつかあります。
機能を減らす
仕様を簡単にする
公開を段階的にする
既存サービスを利用する
自動化しすぎない
後から追加する
では、
何を残して、何を捨てますか？
43. まず「全部必要」を疑う
例えば、
イベント予約アプリに、
ログイン
イベント一覧
イベント詳細
検索
お気に入り
予約
決済
チャット
AIおすすめ
レビュー
ランキング
Push通知
QRチケット
SNS共有
管理画面
があったとします。
本当に、
最初から全部必要？
でしょうか。
44. GAME 6
「機能オークション」
グループに、
100ポイント
を配ります。
これが今回の開発予算です。
機能には、それぞれ仮の開発コストがあります。
| 機能 | 必要ポイント |
|---|---|
| 会員登録・ログイン | 15 |
| イベント一覧 | 10 |
| イベント詳細 | 5 |
| 検索 | 10 |
| 予約 | 20 |
| 決済 | 20 |
| お気に入り | 5 |
| Push通知 | 10 |
| QRチケット | 15 |
| チャット | 25 |
| AIおすすめ | 30 |
| レビュー | 10 |
| SNS共有 | 5 |
| 管理画面 | 20 |
※ポイントは授業用の仮定です。実際の開発費を表すものではありません。
45. ルール
あなたのチームは、
100ポイント以内
でアプリを完成させてください。
ただし、
最初に決めた「誰の、どんな問題を解決するアプリか」を壊してはいけません。
選んだ機能を書いてください。
選択した機能：
1.
2.
3.
4.
5.
6.
合計：
________ポイント
46. ここで質問
例えば、
「イベント予約を簡単にする」
ことが目的なのに、
AIおすすめ
チャット
ランキング
SNS共有
を優先して、
予約機能
を削ったらどうでしょう？
アプリは豪華ですが、
目的を達成できません。
47. 機能には優先順位がある
そこで、
機能を3種類に分けてみます。
MUST
絶対に必要。
これがなければ、アプリの目的を達成できない。
SHOULD
できれば欲しい。
なくてもサービスは成立する。
LATER
後から追加できる。
最初の公開時にはなくてもよい。
48. 実習⑤
自分の機能を3つに分ける
MUST
1.
2.
3.
4.
SHOULD
1.
2.
3.
4.
LATER
1.
2.
3.
4.
49. 削る基準は「好き・嫌い」ではない
判断するときは、
次の質問をします。
この機能がないと、
ユーザーの問題を解決できない？
YESなら、
MUSTの可能性があります。
NOなら、
最初のリリースでは後回しにできるかもしれません。
50. 今日の重要キーワード③
MVP
Minimum Viable Product
日本語では、
実用最小限の製品
などと説明されます。
簡単に考えるなら、
ユーザーの重要な問題を解決できる、最小限の状態でまず公開する
という考え方です。
51. 「機能が少ないアプリ」ではない
MVPは、
ただ機能を削った、
ショボいアプリ
という意味ではありません。
重要なのは、
余計なものは少ない
でも
一番重要な価値は提供できる
ということです。
52. 例えばイベント予約アプリ
目的が、
イベントを見つけて、簡単に予約できる
なら、
最初は、
イベント一覧
↓
イベント詳細
↓
予約
↓
予約確認
でも価値を検証できるかもしれません。
一方、
AIおすすめ
ランキング
チャット
アバター
ポイント
SNS
は後から追加できる可能性があります。
53. GAME 7
「予算がさらに半分になりました」
社長から再び電話です。
「ごめん。」
「100万円も厳しくなった。」
「50万円でお願い。」
……
さあ、どうしますか？
54. ルール変更
先ほどMUSTにした機能も、
もう一度疑ってください。
例えば、
SMS認証
が必要だと思っていた。
でも、
メール認証ではダメ？
と考えます。
55. 「機能を削る」以外の方法もある
例えば、
案A
独自チャットを開発
ではなく、
最初はチャット機能なし
にする。
案B
高度なAIおすすめ
ではなく、
カテゴリによるおすすめ
から始める。
案C
複雑な管理アプリを作る
ではなく、
シンプルなWeb管理画面
にする。
案D
すべて自社開発
ではなく、
既存サービス・クラウドサービスを利用
する。
56. 実習⑥
50万円版を作れ
自分のアプリを、
「最小構成」
に変更してください。
【最初の企画】
機能数：
________________
【100万円版】
残す機能：
・
・
・
・
【50万円版】
残す機能：
・
・
・
57. 削ったものを書く
削った機能：
1.
理由：
2.
理由：
3.
理由：
「お金がないから」
だけではなく、
「今なくてもユーザーの中心的な問題を解決できるから」
という説明ができると良いです。
58. でも、ここで事件発生
あなたは、
開発費を50万円に収めました。
社長：
「完璧！」
……
ところが経理担当から質問されます。
「開発した後のお金は？」
……
何のことでしょう？
59. 開発費だけでは終わらない
アプリを公開すると、
場合によっては、
サーバー
Database
Storage
SMS
メール
外部API
AI API
監視
ドメイン
決済
ストア関連
などにも費用が発生します。
つまり、
開発費
と、
運用費
は別です。
60. 初期費用とランニングコスト
初期費用
最初に発生する費用。
例えば、
企画
設計
デザイン
開発
テスト
初期設定
など。
ランニングコスト
運用を続けることで発生する費用。
例えば、
クラウド利用料
Database
Storage
外部API
SMS
監視
保守
などです。
61. GAME 8
「社長が勘違いしています」
社長：
「開発費100万円払ったから、もうお金かからないよね？」
あなたは、
エンジニア
として説明してください。
62. 社長への説明を作る
次の文章を完成させます。
開発費は、
________________________
のための費用です。
公開後には、
________________________
________________________
________________________
などの費用が発生する可能性があります。
特に、
________________________
は利用量によって増える可能性があります。
63. 前回のお金マップを思い出す
前回、
￥
を書いた場所を思い出してください。
例えば、
Flutter App
↓
Authentication ￥
↓
Backend ￥
↓
Database ￥
↓
Storage ￥
＋ SMS ￥
＋ Payment ￥
＋ AI API ￥
でした。
今日は、
これを見積もりに追加します。
64. 実習⑦
「本当の見積書」を作る
自分のアプリについて、
大きく3つに分けます。
A. 開発費
| 項目 | 工数 | 概算 |
|---|---|---|
| 要件整理 | ||
| UI設計 | ||
| Flutter | ||
| Backend | ||
| Database | ||
| 管理画面 | ||
| テスト | ||
| 修正 | ||
| その他 |
65. B. 初期費用
| 項目 | 必要？ | 概算 |
|---|---|---|
| 開発者登録等 | ||
| ドメイン | ||
| 外部サービス初期設定 | ||
| その他 |
料金が分からなければ、
「要調査」
で構いません。
66. C. 月額・従量費
| 項目 | 料金タイプ | 月額予想 |
|---|---|---|
| Database | 固定 / 従量 / 要調査 | |
| Storage | 固定 / 従量 / 要調査 | |
| SMS | 固定 / 従量 / 要調査 | |
| 固定 / 従量 / 要調査 | ||
| AI API | 固定 / 従量 / 要調査 | |
| Monitoring | 固定 / 従量 / 要調査 | |
| その他 |
67. 「要調査」は悪い回答ではない
実務では、
分からない数字を、
勝手に作る
方が危険です。
例えば、
SMS料金
→ 分からない
なら、
要調査
確認先：
利用予定サービスの公式料金ページ
とします。
68. ここで新しい依頼
社長：
「なるほど。」
「じゃあ3か月で作れる？」
あなた：
「工数は50人日なので、50日ですね！」
……
本当にそうでしょうか？
69. 工数と期間は同じではない
例えば、
50人日
というのは、
作業量
です。
一方、
2か月
というのは、
カレンダー上の期間
です。
似ていますが、同じではありません。
70. なぜズレる？
例えば、
デザインが完成していないと、
Flutter画面を完成できない。
UI設計
↓
Flutter
Backendが完成していないと、
API連携テストができない。
Backend
↓
Flutter連携
↓
テスト
つまり、
作業には順番がある
ということです。
71. さらに待ち時間もある
実務では、
顧客確認待ち
デザイン確認待ち
素材待ち
アカウント発行待ち
外部サービス設定
審査
修正確認
なども発生します。
72. GAME 9
「3人なら3倍速？」
60人日のプロジェクトがあります。
先生：
「1人だと60日か。」
「じゃあ60人雇えば1日で終わるね！」
本当にそうでしょうか？
73. チームが増えると発生する仕事
人数が増えると、
情報共有
コードレビュー
役割分担
Git管理
仕様確認
ミーティング
競合する変更の調整
なども増えます。
つまり、
人数を増やせば無限に速くなるわけではない
ということです。
74. 実習⑧
開発の順番を作る
自分のアプリについて、
どんな順番で開発するか考えます。
例えば、
要件整理
↓
画面設計
↓
Database設計
↓
Authentication
↓
主要画面
↓
Backend連携
↓
決済
↓
管理画面
↓
テスト
↓
修正
↓
公開
自分のアプリ版を作ってください。
75. 自分の開発ロードマップ
①
↓
②
↓
③
↓
④
↓
⑤
↓
⑥
↓
⑦
↓
リリース
76. 予定どおりに進む？
ここで、また事件です。
開発中に、
社長：
「やっぱりGoogleログインも追加して。」
1週間後、
「動画も投稿できるようにして。」
さらに、
「AIチャットも入れよう！」
……
どうなるでしょう？
77. GAME 10
「仕様変更カード」
先生から、
ランダムに仕様変更が出されます。
例えば、
CARD A
Google / Appleログインを追加
CARD B
動画投稿を追加
CARD C
AIチャットを追加
CARD D
海外対応
CARD E
決済機能を追加
CARD F
ユーザー数が
1,000人 → 100,000人
78. 仕様変更の影響を考える
カードを1枚引いて、
次を考えてください。
追加された仕様：
________________________
影響する機能：
________________________
追加作業：
________________________
開発期間：
増える / 変わらない / 要調査
運用費：
増える / 変わらない / 要調査
他に確認すること：
________________________
79. 変更は「その機能だけ」に影響するとは限らない
例えば、
動画投稿
を追加すると、
Flutter
Storage
Database
通信量
アップロード処理
管理画面
監視
テスト
運用費
など、
複数箇所に影響する可能性があります。
80. だから見積もりには前提を書く
例えば、
開発費：100万円
だけではなく、
開発費：約100万円
前提：
・iOS / Android
・メール認証
・動画投稿なし
・AI機能なし
・日本国内のみ
・管理画面は最低限
・主要機能は○○
とします。
:
81. 「何を作らないか」も仕様
実務では、
対象外
を明確にすることも重要です。
例えば、
今回含まない：
・チャット機能
・動画投稿
・AIおすすめ
・海外対応
・多言語対応
・高度な分析機能
・複雑な権限管理
と最初に決めておきます。
82. なぜ「作らないもの」を決める？
例えば、
見積もりを出した後に、
「チャットって当然入っていますよね？」
と言われたらどうでしょう？
開発側：
「入っていません。」
依頼側：
「普通あるでしょ？」
という問題が起きます。
だから、
作るもの
＋
作らないもの
の両方を確認します。
83. GAME 11
「それ、見積もりに入ってます？」
2人1組になります。
役割を分けます。
A：依頼者
追加機能を要求します。
例えば、
「通知も当然ありますよね？」
「Appleログインも欲しいです。」
「管理画面からCSV出せますよね？」
「ユーザー同士でDMできますよね？」
「海外の人も使えますよね？」
B：開発者
すぐに、
「できます！」
と言ってはいけません。
次の順番で確認してください。
① 今回の仕様に含まれている？
↓
② 含まれていなければ追加仕様
↓
③ どこに影響する？
↓
④ 追加工数は？
↓
⑤ 費用は？
↓
⑥ スケジュールは？
↓
⑦ 本当に今必要？
84. 開発者として回答する
例えば、
「チャット機能も追加できますか？」
と言われた場合。
技術的には実装可能です。
ただし、
現在の見積もりには含まれていません。
追加する場合は、
・メッセージ画面
・Database
・リアルタイム通信
・Push通知
・ブロック
・通報
・管理機能
・テスト
などへの影響を確認する必要があります。
そのため、
追加工数と費用を再見積もりします。
という考え方になります。
85. 「できます」より大切な言葉
実務では、
「確認して見積もります」
と言えることも重要です。
分からないものを、
その場で適当に、
3日くらいです！
と答える必要はありません。
86. 見積もりは「約束」に近い
依頼する側は、
見積もりを見て、
予算を確保する
担当者を決める
リリース日を決める
広告を準備する
イベント日を決める
社内へ報告する
などの行動をします。
だから、
根拠のない数字を出すと、
開発者だけの問題ではなくなります。
87. 今日の重要キーワード④
バッファ
予定どおりに進まない可能性を考えて、
余裕を持たせる考え方です。
88. なぜバッファが必要？
例えば、
API仕様の確認に時間がかかった
想定していなかったバグが出た
実機だけで不具合が出た
外部サービスの設定に時間がかかった
仕様確認が遅れた
ストア申請で修正が必要になった
などが考えられます。
89. ただし「適当に30%追加」ではない
バッファは、
根拠なく金額を増やすためのもの
ではありません。
どこに不確実性があるかを確認します。
例えば、
| 項目 | 不確実性 |
|---|---|
| 通常画面 | 低 |
| 初めて使うAPI | 高 |
| 決済 | 高 |
| 既存DB利用 | 中 |
| 新しいAI API | 高 |
| 単純な静的ページ | 低 |
90. 実習⑨
「危険なところ」に⚠を書く
自分の見積もりを見てください。
不確実性が高いところに、
⚠
を書きます。
例えば、
ログイン 3人日
一覧 2人日
検索 3人日
決済 5人日 ⚠
AI 5人日 ⚠
外部API 3人日 ⚠
テスト 4人日
となります。
91. ⚠が多いプロジェクトは？
当然、
予定がズレる可能性も高くなります。
つまり、
同じ、
30人日
という見積もりでも、
A
すべて経験済みの技術
と、
B
初めて使う技術が大量
では、
同じようには考えられません。
92. 見積もりを「幅」で考える
情報が少ない段階では、
42日です。
と断定するより、
例えば、
現時点では、
40〜50人日程度を想定。
ただし、
決済APIと外部連携については
詳細調査後に再見積もり。
とする考え方もあります。
93. 精度は情報量で変わる
企画段階：
分からないことが多い
↓
見積もりの幅が大きい
仕様が決まる：
分からないことが減る
↓
見積もり精度が上がる
実装直前：
詳細仕様が決まる
↓
さらに精度が上がる
つまり、
最初から100%正確な見積もりを作るのは難しい
ということです。
94. GAME 12
「見積もり会議」
ここから最終ゲームです。
グループで役割を決めます。
役割A：社長
できるだけ安くしたい。
できるだけ早く公開したい。
役割B：ユーザー
便利な機能が欲しい。
使いにくいアプリは嫌。
役割C：開発者
無理なスケジュールは避けたい。
品質も守りたい。
役割D：運営担当
公開後に毎日使う。
面倒な作業を減らしたい。
95. 条件
社長から、
次の条件が出ました。
予算：100万円
公開：できるだけ早く
ユーザー：1,000人からスタート
将来的には10,000人を想定
この条件で、
自分たちのアプリを再設計してください。
96. 社長の要求
社長：
「全部欲しい。」
ユーザー：
「便利にして。」
運営：
「管理を簡単にして。」
開発者：
「その条件では全部は難しい。」
さあ、
どうしますか？
97. チームで交渉する
次の表を完成させます。
| 機能 | 社長 | ユーザー | 開発者 | 運営 | 最終判断 |
|---|---|---|---|---|---|
| ログイン | |||||
| 検索 | |||||
| 決済 | |||||
| 通知 | |||||
| チャット | |||||
| AI | |||||
| 管理画面 | |||||
| その他 |
98. 全員の希望を全部入れられる？
おそらく、
難しいはずです。
だから、
誰の要望を優先する？
何を残す？
何を後回しにする？
どこまでなら予算内？
どこまでなら期間内？
運用できる？
を話し合います。
99. 最終的に決めること
チームで、
VERSION 1
を決めてください。
【今回作る】1.
2.
3.
4.
5.
【次回以降】
1.
2.
3.
【今回は作らない】
1.
2.
3.
100. その判断には理由が必要
例えば、
AIおすすめは今回は作らない。
理由：
アプリの中心的な価値は
「イベントを簡単に予約できること」。
AIがなくてもその価値は提供できる。
まず予約機能を公開し、
利用者が増えてから追加を検討する。
というように説明します。
101. FINAL MISSION
「100万円版」を完成させる
第1回で作ったアプリを、
今日の内容を使って、
現実的な開発計画
へ変えます。
102. STEP 1：目的
アプリ名：
誰が使う？：
解決する問題：
最も重要な価値：
103. STEP 2：機能
MUST
1.
2.
3.
4.
SHOULD
1.
2.
3.
LATER
1.
2.
3.
104. STEP 3：工数
| 機能・作業 | 工数 | 不確実性 | 理由・前提 |
|---|---|---|---|
| 低 / 中 / 高 | |||
| 低 / 中 / 高 | |||
| 低 / 中 / 高 | |||
| 低 / 中 / 高 | |||
| 低 / 中 / 高 | |||
| 低 / 中 / 高 |
105. STEP 4：見えない仕事
□ 要件整理
□ UI / UX
□ Database設計
□ Backend
□ 外部API設定
□ テスト
□ 実機確認
□ バグ修正
□ セキュリティ確認
□ ストア公開準備
□ ドキュメント
□ その他
106. STEP 5：合計する
機能開発：
________人日
設計：
________人日
テスト：
________人日
修正：
________人日
公開準備：
________人日
その他：
________人日
────────────────
合計：
________人日
107. STEP 6：開発費を計算する
授業では仮に、
1人日 ＝ 50,000円
として計算します。
________人日
×
50,000円
=
________________円
※これは計算練習用の仮定です。実際の単価を示すものではありません。
108. 予算オーバーしたら？
予算：
1,000,000円
見積もり：
________________円
差額：
________________円
オーバーしていたら、
もう一度設計します。
109. 削る
削る機能：
________________
理由：
________________
110. 簡単にする
元の仕様：
________________
簡略化：
________________
なぜ：
________________
111. 後回しにする
VERSION 1では作らない：
________________
VERSION 2で検討：
________________
112. STEP 7：運用費も忘れない
Database：
￥________________ / 月 または 要調査
Storage：
￥________________ / 月 または 要調査
Authentication：
￥________________ / 月 または 要調査
SMS：
￥________________ または 要調査
AI：
￥________________ または 要調査
Monitoring：
￥________________ または 要調査
その他：
￥________________
113. STEP 8：対象外を書く
【今回の開発に含まないもの】
1.
2.
3.
4.
5.
これも、
立派な仕様
です。
114. STEP 9：前提条件を書く
例えば、
・日本国内向け
・iOS / Android
・メール認証
・動画投稿なし
・AIなし
・ユーザー1,000人から開始
・管理画面は最低限
などです。
自分のアプリについて書いてください。
【見積もりの前提】
・
・
・
・
・
115. 最終発表
「このアプリを100万円で作ります」
チームまたは個人で説明します。
発表する内容は、
7つ
です。
① 何を作る？
② 誰の問題を解決する？
③ VERSION 1に何を入れる？
④ 何を削った？
⑤ 何人日かかる？
⑥ いくらかかる？
⑦ なぜこの構成にした？
116. 他のチームは「社長」になる
発表を聞く側は、
次の質問から1つ以上選んでください。
「その機能、本当に最初から必要？」
「その工数の根拠は？」
「テストは入っていますか？」
「管理画面は？」
「運用費はいくら？」
「ユーザー1万人になったら？」
「予算50万円になったら？」
「3か月で本当にできる？」
「その機能を後回しにできない？」
「何を対象外にしていますか？」
117. 開発者は説明する
大切なのは、
見積もりを当てること
ではありません。
まだ経験が少なければ、
正確な工数を出すのは難しくて当然です。
今日練習しているのは、
大きな仕事を
↓
小さく分解して
↓
必要な作業を考えて
↓
不明点を見つけて
↓
前提を決めて
↓
数字にする
という考え方です。
118. 今日の最初を思い出そう
授業の最初は、
Instagramみたいなアプリ
↓
何日？
↓
分からない
でした。
今なら、
まず、
どんな機能？
↓
誰が使う？
↓
どこまで作る？
↓
認証方法は？
↓
Backendは？
↓
管理画面は？
↓
外部サービスは？
↓
テスト範囲は？
↓
対象外は？
↓
前提条件は？
と確認できます。
119. 「見積もる」とは？
見積もるとは、
勘で値段を決めること
ではありません。
要件
↓
機能
↓
タスク
↓
工数
↓
期間
↓
費用
へ分解することです。
120. さらに実務では
開発費
だけではなく、
初期費用
運用費
外部サービス費
保守費
81. 「何を作らないか」も仕様
実務では、
対象外
を明確にすることも重要です。
例えば、
今回含まない：
・チャット機能
・動画投稿
・AIおすすめ
・海外対応
・多言語対応
・高度な分析機能
・複雑な権限管理
と最初に決めておきます。
82. なぜ「作らないもの」を決める？
例えば、
見積もりを出した後に、
「チャットって当然入っていますよね？」
と言われたらどうでしょう？
開発側：
「入っていません。」
依頼側：
「普通あるでしょ？」
という問題が起きます。
だから、
作るもの
＋
作らないもの
の両方を確認します。
83. GAME 11
「それ、見積もりに入ってます？」
2人1組になります。
役割を分けます。
A：依頼者
追加機能を要求します。
例えば、
「通知も当然ありますよね？」
「Appleログインも欲しいです。」
「管理画面からCSV出せますよね？」
「ユーザー同士でDMできますよね？」
「海外の人も使えますよね？」
B：開発者
すぐに、
「できます！」
と言ってはいけません。
次の順番で確認してください。
① 今回の仕様に含まれている？
↓
② 含まれていなければ追加仕様
↓
③ どこに影響する？
↓
④ 追加工数は？
↓
⑤ 費用は？
↓
⑥ スケジュールは？
↓
⑦ 本当に今必要？
84. 開発者として回答する
例えば、
「チャット機能も追加できますか？」
と言われた場合。
技術的には実装可能です。
ただし、
現在の見積もりには含まれていません。
追加する場合は、
・メッセージ画面
・Database
・リアルタイム通信
・Push通知
・ブロック
・通報
・管理機能
・テスト
などへの影響を確認する必要があります。
そのため、
追加工数と費用を再見積もりします。
という考え方になります。
85. 「できます」より大切な言葉
実務では、
「確認して見積もります」
と言えることも重要です。
分からないものを、
その場で適当に、
3日くらいです！
と答える必要はありません。
86. 見積もりは「約束」に近い
依頼する側は、
見積もりを見て、
予算を確保する
担当者を決める
リリース日を決める
広告を準備する
イベント日を決める
社内へ報告する
などの行動をします。
だから、
根拠のない数字を出すと、
開発者だけの問題ではなくなります。
87. 今日の重要キーワード④
バッファ
予定どおりに進まない可能性を考えて、
余裕を持たせる考え方です。
88. なぜバッファが必要？
例えば、
API仕様の確認に時間がかかった
想定していなかったバグが出た
実機だけで不具合が出た
外部サービスの設定に時間がかかった
仕様確認が遅れた
ストア申請で修正が必要になった
などが考えられます。
89. ただし「適当に30%追加」ではない
バッファは、
根拠なく金額を増やすためのもの
ではありません。
どこに不確実性があるかを確認します。
例えば、
| 項目 | 不確実性 |
|---|---|
| 通常画面 | 低 |
| 初めて使うAPI | 高 |
| 決済 | 高 |
| 既存DB利用 | 中 |
| 新しいAI API | 高 |
| 単純な静的ページ | 低 |
90. 実習⑨
「危険なところ」に⚠を書く
自分の見積もりを見てください。
不確実性が高いところに、
⚠
を書きます。
例えば、
ログイン 3人日
一覧 2人日
検索 3人日
決済 5人日 ⚠
AI 5人日 ⚠
外部API 3人日 ⚠
テスト 4人日
となります。
91. ⚠が多いプロジェクトは？
当然、
予定がズレる可能性も高くなります。
つまり、
同じ、
30人日
という見積もりでも、
A
すべて経験済みの技術
と、
B
初めて使う技術が大量
では、
同じようには考えられません。
92. 見積もりを「幅」で考える
情報が少ない段階では、
42日です。
と断定するより、
例えば、
現時点では、
40〜50人日程度を想定。
ただし、
決済APIと外部連携については
詳細調査後に再見積もり。
とする考え方もあります。
93. 精度は情報量で変わる
企画段階：
分からないことが多い
↓
見積もりの幅が大きい
仕様が決まる：
分からないことが減る
↓
見積もり精度が上がる
実装直前：
詳細仕様が決まる
↓
さらに精度が上がる
つまり、
最初から100%正確な見積もりを作るのは難しい
ということです。
94. GAME 12
「見積もり会議」
ここから最終ゲームです。
グループで役割を決めます。
役割A：社長
できるだけ安くしたい。
できるだけ早く公開したい。
役割B：ユーザー
便利な機能が欲しい。
使いにくいアプリは嫌。
役割C：開発者
無理なスケジュールは避けたい。
品質も守りたい。
役割D：運営担当
公開後に毎日使う。
面倒な作業を減らしたい。
95. 条件
社長から、
次の条件が出ました。