課題設定・分析
W2-1 価値を最大化する
イシュー度×解の質で価値の高い作品を作る考え方、よいイシューの3条件とイシュー分解、企画書の作り方、3つの制約理論にもとづく技術選定を網羅的に解説します
このレクチャーのテーマは「価値を最大化する」。自己満足で終わらない、ユーザーにとって価値の高い作品作りのコツと、最小労力で実現するための技術選定を扱います(講師:上津原 和弘)。
5週間の全体像
オンラインレクチャーを中心に進め、選抜された方は東京での成果発表会に参加できます。各週には「お題」が設定されています。
| 週 | レクチャー回 | テーマ | お題 |
|---|---|---|---|
| Week1 | 2/26(木)キックオフ | AIコード生成とクラウド | アイデアをAIで形にして投稿しよう |
| Week2 | 2/21(土) | 取り組むテーマの選定と企画 | アイデアソンで取り組むテーマを決めよう |
| Week3 | 3/7(土) | データベースとAI | データベースやAIを活用してアイデアを形にしよう |
| Week4 | 3/14(土) | センサーとスマホアプリ | 制作したアプリをインストールできるようにしよう |
| Week5 | 3/21(土) | スライド作成と発表準備 | プレゼンテーションを完成させよう |
| 成果発表 | 3/26(木) | 東京での選抜成果発表会 | 参加者にサービスを理解してもらおう |
💡 関連イベントとして、積水ハウスグループのDX活動/事例紹介(2/28 土)、(株)ザイマックスデジタルのDX活動/事例紹介(2/27 金)が予定されています。
目次
- 仕事の意味(バリュー)の本質
- 価値の最大化(喜んでもらえる作品を作る)
- 今週の課題
- Appendix(もっと知りたい人へ)
AIサービスについて
これまでのAIコード生成ツール
前回資料では v0 を使用したコード生成を推奨していました。ただし無料枠が 5$ のみという課題があります。

- 複雑な画面を作ると、あっという間にクレジットを消費してしまう
- 開発作業が途中でストップしてしまう大きな原因に
メイン推奨:Gemini Canvas

- 無料枠に余裕がある:v0 の課題だった「すぐ制限にかかる」問題が解消されやすい
- リアルタイムプレビュー:ブラウザ上で生成された Web 画面の動作をすぐに確認できる
- 直感的な部分修正:コード全体を作り直さなくても、プレビュー画面から特定の場所だけを指定して修正できる
上級者向け:Claude Code

- ターミナル統合:ターミナル(コマンドライン)から直接呼び出す
- 自律的なファイル操作:AI が自分で複数のファイルを読み込み、コードの書き換えや保存まで行う
⚠️ 運営サポート外:強力ですが、設定の手順が多いためサポートしきれない場合があります。Codex Web 版、Gemini CLI もおすすめです。
より少ないコストで良い作品を作るコツ
例えば、人に仕事をお願いするときのように、分かりやすくやるべきことを伝えてみましょう。
整理した情報を伝える
一回のメッセージの中に、制作に必要な要点を箇条書きなどで簡潔にまとめ、より少ない回数 / 文字数でも AI が迷うことなく開発できる状態を目指しましょう。
やみくもにもがくことをやめる
解決策が分からず詰まっている状態で、やり取りを何度も繰り返すのはもったいないです。コード生成 AI はコストや時間の消費が大きいので、衢動的に使うより考えてから動くのがベストです。その場合はコード生成 AI からいったん離れて、Gemini などに納得のいく解決策を提案してもらってから、なぜこの対策で直りそうなのか理解したうえで試行錯誤を続けてみましょう。
W1の優秀作品紹介
工事情報掲示:Building Navigator

- 重要性が高いのにアナログで通知されがちな工事の通知を、デジタルで見れるケース
- 消費者向けのサービスだが、収益モデルは工事業者から利用料を得る to B としての発展性もある
- シンプルな解決策で、現実世界の切実なニーズを解決できる費用対効果の大きいアイデア
レシート家計簿

- アナログで蓄積されてしまった情報をデジタル化する、DX の分かりやすい事例
- AI を使った自動読み取りで、入力の負担を極限まで減らしている点が印象的
- 必要な機能の取捨選択が出来ていて、分かりやすい
求人サイト:STUDENT CONSOLE

- サービス説明から自然に利用を開始できる。初見の人でも無意識にサービスのユーザーになる設計
- ソフトウェア単体で完結するのではなく、ソフトウェアが入り口となってリアルで繋がりが生まれるきっかけを提供している
💡 技術重視 or 課題解決重視? Zoom で作品制作エピソードを教えてください。
1. 仕事の意味(バリュー)の本質
参考図書:安宅和人

安宅和人(1968年富山県出身)
- 慶應義塾大学 環境情報学部 教授
- LINEヤフー株式会社 シニアストラテジスト
- 一般社団法人「残すに値する未来」代表
経歴
- 1993年:マッキンゼー・アンド・カンパニー入社
- 1997年:イェール大学 脳神経科学プログラムで博士号(Ph.D.)取得
- 2008年:ヤフー株式会社入社
- 2012年:ヤフー株式会社 CSO(チーフストラテジーオフィサー)就任
- 2018年:慶應義塾大学 環境情報学部 教授に着任
- 2022年:LINEヤフー株式会社 シニアストラテジストとして戦略・研究開発を担当
書籍
- 『イシューからはじめよ ― 知的生産の「シンプルな本質」』(今回の参考図書)
- 『シン・ニホン ― AI×データ時代における日本の再生と人材育成』 など
「イシュー」とは
「イシュー」とは、下記の両方を満たすものです。
- 二つ以上の集団の間で決着のついていない問題
- 根本にかかわる、もしくは白黒がはっきりしていない問題
バリューのある仕事は、次の2軸で決まります。
| 軸 | 意味 |
|---|---|
| イシュー度 | 自分の置かれた局面で、この問題に答えを出す必要性の高さ |
| 解の質 | そのイシューに対して、どこまで明確に答えを出せているかの度合い |
おすすめのアプローチ
💡 「ひたすら頑張る」は無駄!
バリューのある仕事に到達するには、闇雲に努力量を増やすのではなく、次の順序で進めます。
- イシューの見極め(イシュー度の高い問題を選ぶ)
- 解の磨き込み(選んだイシューに対する解の質を高める)
縦軸に「解の質」、横軸に「イシュー度」を取ると、いきなり解の質だけを上げようと「ひたすら頑張る」ルートは無駄になりがちです。まず①イシューの見極めで右へ進み、その後②解の磨き込みで上へ進むことで、効率よく「バリューのある仕事」に到達できます。

解の質 × イシュー度のマトリクス(講義スライドより)
よいイシューの3条件
① 本質的な選択肢である
- 選択肢があり、どちらになるのかによって大きな影響が出る
- 例:地球を中心に世界が回っている or 地球自体が回っている
② 深い仮説がある
- 強引にでもまずは仮説を立てるのが重要
- 主語と動詞を入れる
- Why ではなく Where、What、How で表現する
| 評価 | 例 |
|---|---|
| × | 都市Aは将来どうなるのか / なぜ商品Bが売れないのか |
| ○ | 都市Aの経済状況は悪化しているのではないか / Bに商品力がないのではなく、販売方法がよくないのではないか |
③ 答えを出せる
- 「既存の手法や現在取ることができるアプローチで答えを出せる」かどうかを見極める
- 答えが出せなさそうな場合はイシューの分解(後述)をする
イシューの分解
多くの場合、イシューにいきなり答えを出すことは難しいため、イシューを分解して答えを出せるサイズにします(イシューツリーを作る)。
💡 分解する時にはモレなくダブりなく(MECE)。サブイシューには仮説を立てる。
メインイシュー
├─ サブイシューA
│ ├─ サブイシューA1
│ └─ サブイシューA2
├─ サブイシューB
└─ サブイシューC

イシューツリーのイメージ(講義スライドより)。サブイシューには仮説を立てる
イシューの分解の例(新規事業のコンセプトの場合)
| 問い | 観点 |
|---|---|
| 事業のコンセプトは何が良いか | Where:どのような領域を狙うべきか |
| What:具体的に何の価値を提供するか | |
| How:どのように実現していくか |

新規事業のコンセプトを Where/What/How に分解した例(講義スライドより)
2. 価値の最大化(喜んでもらえる作品を作る)
優れたアイデアを出すチームの特徴
優れたアイデアを出すチームは、次の4点を大切にしています。
- コミュニケーション
- 意味のあるミーティング
- リサーチ
- 文章作成
コミュニケーション
目的意識を持った会話が多いチームほど、良いアイデアが生まれやすいです。
- Discord のスレッドを活用して、話題ごとに議論を整理する
- 口頭で完結させず、Notion / Docs または Discord に記録を残す
- ミーティングは「前」と「後」が重要
議事録 × AI
議事録は手間がかかりますが、AI に任せれば会話に集中できます。
- Notion AI や tl;dv を使えば、録画から自動で議事録が作成される
- 議事録は「アジェンダ / メモ / ネクストアクション」の構成にする
- 誰が何をいつまでにやるのか、タスクの割り振りまで記録に残す
ミーティングは前と後が重要
| タイミング | やること |
|---|---|
| ミーティング前 | 話し合うこと(アジェンダ)を整理。可能であればチェックボックスに |
| ミーティング中 | 要点を箇条書きでメモ |
| ミーティング後 | 誰が何をいつまでにやるのか決めてタスクを割り振る |
口頭で完結させず、Notion / Docs または Discord に記録を残しましょう。
- Discord の場合はスレッドをうまく活用するのがおすすめ
- Notion AI や tl;dv を使った AI 議事録作成もおすすめ
リサーチ
方向性を間違えないためには、思い込みではなく一次情報をもとに判断することが大切です。
Perplexity + Deep Research
- 多角的に、複数の Web サイトを引用しながら回答してくれる AI
- 課題の背景や市場規模を調べるとき、一次情報をもとに明確な根拠を示せる
- 「なんとなく」ではなく「根拠をもって」意思決定するために使う
フィールドワーク + Gemini
- 実際に現場を見て感じた不満や疑問を、Gemini になぜそうなのか質問する
- 現場から戻ってから、Gemini の会話ログを元に企画の原案として整理する
- この方法では、デスクリサーチだけでは見えない「現場のリアル」を企画に反映できる
文章理解 / 作成
企画書やドキュメントの質を上げるには、書いて終わりではなく「レビューと改善」の繰り返しが必要です。
NotebookLM × 論文理解
- 企画の内容と関連しているが、自力で読むのが難しいサイトや論文を複数個ブックマークしておく
- 集めた論文やサイトを NotebookLM のソースに加える
- スライド生成などで要点を視覚的に理解できる教材を作る
【将来的活用】NotebookLM × ナレッジ検索
- プロジェクトが大きくなり Google Drive に大量のファイルが蓄積してきた場合に活用
- 例えば案件単位で、重要ファイルをリストアップし NotebookLM のソースに加える
- 前任者の代わりに AI が答えてくれるので、引き継ぎの労力を削減できる
誰のために作品を作ろうか
💡 本当にあなたの力を必要としているのは、あなたの得意なことができない人です。
作品を届ける相手(ペルソナ)は、普段出会うことのない人かもしれません。そんな人が心から欲しいと思う作品を作るには、その人のことを細かく知る必要があります。必須ではありませんが、インタビューをする機会があれば理解が深まるはずです。
相手が「日常的に抱えている問題」や「相手が取る行動」を推測できるなら、自分の作品を「本当に使うのか」や「本当に課題の解決につながるのかどうか」を、作品を届ける前に予測できるようになるはずです(カスタマージャーニー)。
もし商業的に成功させたいのであれば、企業のことについてもっと知り、多くのお金を払ってでも解決したい問題を、それより安い金額で解決することが出来れば、その差額が利益になります。
全てのものは二度作られる
『7つの習慣』で紹介されている考え方です。皆さんが「モノづくり」と聞いて思い浮かべるのは、おそらく素材を加工したり、コードを書いたりする事でしょう。しかし、それは「第二の創造」にすぎません。
企画書やデザイン、場合によっては頭の中にあるイメージこそが「第一の創造」であって、この段階で明確に完成像が決まっていなかったり、作るものを間違えていたりすると、「第二の創造」は必ず失敗します。
プログラミングや製造は、あくまで第一の創造で作られたイメージに従っているだけにすぎず、「企画やデザイン」こそが「モノづくり」の土台にあると言っても良いでしょう。
企画書のテンプレートを使う
| 項目 | 例 |
|---|---|
| ターゲット | 最新技術の導入の遅れとそれに伴う生産性の低下を自覚している中堅企業 |
| 解決したい課題 | コミュニケーションコスト。属人化。自動化できる作業でも手動 |
| コア機能(優先順位順) | 既存プロジェクトから標準化されたドキュメントの自動作成。更新自動検出。カスタマイズ機能 |
| 使い始めてから使い終わるまでの手順 | ドキュメント化したいファイルのURLを入力 → Driveにドキュメントが作成される → 読み進めながら分からない点の質問や内容の追記を行う → 新規メンバーに共有、読めば即戦力として活躍できる |
| 開発スケジュール | コア機能の作成(1週間) → 補助機能の作成(1週間) → リリース対応(1週間) → バグ修正 & 改善(1週間) |
最小労力で実現する(技術選定)
技術選定では「より少なく、より良く」「目的を達成できる技術を選択せよ」「多めに見積もろう」の3点が軸になります(Pinterest : How to create Effective…)。
より少なく、より良く
💡 あなたの作品は、誰かにとっての1番ですか?
すべての人にとっての1番である必要はありません。「たった一つ」の機能でも「ニッチ」な機能でもいいので、作品を届ける人にとって最善の選択肢になりましょう。
頑張って余分な機能を増やした結果、直感的な理解が難しくなり、逆に利用者が離れてしまう事さえあります。あくまで方向性(課題の価値)が正しい事が前提ですが、進むべき方向が定まった後は質を重視しましょう。
「品質」を確保する方法(プロジェクトの3つの制約理論)

「コスト」「時間」「機能数」は、どれかを優先するなら他のものを犠牲にする必要があります。それを行わなかった場合は「品質」が犠牲になります。
個人開発の場合、使える「コスト」と「時間」には上限があります。だからこそ「機能数」を制限しなければ「質」が確保できないことがあります(プロジェクトの3つの制約理論)。
「目的」を達成できる技術を選択する
💡 釘を打つときは「ノコギリ」ではなくて「ハンマー」を使わなければならないように、目的には必ずその達成に「適した技術」があります。
自分の使い慣れた技術を使うのは結構ですが、それを優先するあまり、まるでノコギリで釘を打つような状態になってしまったら本末転倒です。
例えばプログラミング言語を選ぶとき、「〇が実現可能」「遅延〇秒以内」「シェア〇位以内」など満たしたい要件を事前に決めて、より多くの選択肢から最も良い物を選ぶべきです。
期間を多めに見積もろう
これまでスケジュール通りに進んだ事や、計画通りに進んだ事はどれだけあったでしょうか。多くの人は、過小に見積もることはあっても、過剰に見積もることはほとんどありません。もし「コスト」と「期間」を少なく請求してしまったら、「炎上」は避けられません。
⚠️ 全てが理想的に進むことはほぼないため、最低でも2倍の期間は見積もっておきましょう。また、当初計画していたプラン通りに進められないリスクもあるため、確実に成果を出すことが出来るプランBを用意しておくことも重要です。
3. 今週の課題
Issue Driven アイデアソン(プチアイデアソン)

Figjam を使って、20分間(準備含む)のライブアイデアソンを行います(参加はこちら)。
Figma のアカウントを持っている方や今この場で作れる方はライブで参加できます。作成が難しい方は、見るだけでも問題ありません。
お題
- これから作ってみたい作品をなるべく多く書いてください。ソフト / ハードなど形態は問いません(10分)
- そして、Issue Driven で紹介した「解の質」と「イシュー度」のグラフに、自分で配置してみましょう
この場で実装をするわけではないので、アイデアをとにかく出してみてください。
【チームごと】企画書を提出しよう
〆切:3/6(金) 23:59
※余裕を持って提出し、メンターからフィードバックをもらいながら改善することを推奨します。
企画書テンプレートを参考に企画書を作成してみましょう。企画書は評価対象になるため、取り組む課題の社会的価値や第三者からの読みやすさを意識しましょう。
提出方法
Google Formで課題を提出し、Discord で担当メンターに告知。必要があれば共有Google Driveを活用してください。
⚠️ 絶対に守って欲しいこと
- 提出忘れの場合は評価ができない可能性があるため、不完全でも提出を優先しましょう
- URLは第三者から見れる状態になっているか確認してから提出しましょう
4. Appendix(もっと知りたい人へ)
学習リソース紹介
書籍
- ISSUE DRIVEN:「解の価値」と「解の質」の考え方の原著
- 7つの習慣:「第二の創造」の考え方の原著
- これから始めるFigma:Webデザイン習得の際に実際に利用した書籍
オンラインコース
- Google Project Management:「質」(3つの制約理論)の考え方の元教材
用語解説
| 用語 | 意味 |
|---|---|
| ペルソナ | 空想上の人物像で、対象ユーザーの具体例であることが多い |
| ニーズ | 需要 |
| ニッチ | 人数が限られるため大企業は進出しにくいが、中小企業では利益の出せる領域 |
| シェア | 特定のものが占めている割合 |
| ターゲット | 対象とする相手 |
| デザイン | 本スライドでは、主に Web デザインを指す |
| プロジェクト | 企画とも言う |
| 企画書 | プロジェクトが目指す姿や、具体的な実現計画について書かれた資料 |
💡 免責事項:分かりやすさを優先しているため、厳密な定義と異なる場合があります。