前回の接続とこの講義の役割
前回のM-01では、作る価値を考える企画と、作る対象と条件を明文化する要件定義を分けました。企画の出発点は「誰の何の課題を解くのか」でした。ところが現場で最初に聞こえてくるのは、課題ではなく「こういう機能が欲しい」という要望であることがほとんどです。この講義では、その要望を入り口にしながら、奥にある課題へ遡る道すじを学びます。
このスライドのポイント
- 前回M-01: 作る価値を考える企画と、対象・条件を明文化する要件定義を分けた
- 企画の出発点は「誰の何の課題を解くのか」だった
- ところが現場で最初に聞こえるのは、課題ではなく「こういう機能が欲しい」という要望であることが多い
- この講義の役割: 要望を入り口にして、奥にある課題へ遡る道すじを学ぶ
要望と課題の定義
まず言葉を定義します。要望とは、利用者が口にする「欲しい機能」のことです。たとえば「検索機能が欲しい」という声がこれにあたります。一方の課題とは、その背後にある解決すべき状態のことです。「過去の申請が見つからず、二重申請が起きている」といった、困っている事実そのものを指します。ここで大切なのは、要望は課題を解決する案の一つにすぎず、必ずしも最適とは限らない、という点です。
このスライドのポイント
- 要望＝利用者が口にする「欲しい機能」（例: 検索機能が欲しい）
- 課題＝その背後にある解決すべき状態（例: 過去の申請が見つからず、二重申請が起きている）
- 要望は課題を解決する案の一つにすぎず、最適とは限らない
なぜ課題まで遡るのか
課題まで遡らないと、要望をそのまま実装しても問題が解決しないことがあります。先ほどの例なら、検索機能を付けても、そもそも入力時に重複を検知すれば二重申請は防げたかもしれません。要望どおりに作ったのに、困りごとが残るのです。とくにバイブコーディングでは、AIは言われた機能をそのまま素早く作るのが得意です。だからこそ、要望の奥にある課題へ遡る仕事は、人間が引き受ける必要があります。
このスライドのポイント
- 要望をそのまま実装しても、課題が解決しないことがある
- 例: 検索を付けても、入力時に重複を検知すれば二重申請は防げたかもしれない
- AIは言われた機能をそのまま素早く作るのが得意
- だから要望の奥にある課題へ遡る仕事は、人間が引き受ける
氷山で捉える要望と課題
要望と課題の関係は、氷山の図で捉えると分かりやすくなります。水面の上に見えているのが要望、つまり実際に聞こえてくる言葉です。水面の下に隠れているのが課題、すなわち解決すべき状態と、その原因です。見えている言葉から、見えない部分へ潜っていくために、二つの問いが役立ちます。「それができると、何が良くなりますか」と、「今は何に困っていますか」です。この二つを繰り返すと、要望の下にある課題が姿を現します。
このスライドのポイント
- 水面の上＝要望（聞こえてくる言葉）
- 水面の下＝課題（解決すべき状態と、その原因）
- 遡る二つの問い: 「それができると、何が良くなりますか」「今は何に困っていますか」
経費精算アプリでの具体例
経費精算アプリで考えてみます。利用者から「CSV出力機能が欲しい」という要望が出たとします。そのまま作る前に聞き取っていくと、月次の集計を毎回手作業で作っていたことが分かりました。つまり本当の課題は、集計作業の自動化だったのです。すると、CSV出力よりも、アプリの中に集計画面を用意するほうが正解かもしれません。同じ要望からでも、課題を確かめるかどうかで、作るものが変わります。
このスライドのポイント
- 要望: 「CSV出力機能が欲しい」
- 聞き取ると、月次の集計を毎回手作業で作っていた
- 本当の課題: 集計作業の自動化
- CSV出力よりも、アプリ内に集計画面を用意するほうが正解かもしれない
技術サンプル: 課題へ遡るプロンプト
要望から課題へ遡る作業は、AIとの壁打ちでも進められます。ここでは、課題の仮説出しを頼むプロンプトを紹介します。本体はそのまま、「この要望の背後にありそうな課題の仮説を3つ挙げてください。確かめる質問もそれぞれ付けてください」です。読み方のポイントは二つあります。一つは、答えを一つに絞らず仮説を複数出させている点。もう一つは、その仮説を裏づけるための確かめる質問まで一緒に得ている点です。仮説はあくまで出発点なので、最後に実際の利用者へ確かめる工程は人間が担います。
混同しやすい概念: 要望と課題
ここで混同しやすいのが、要望と課題の区別です。要望は解決案の一つ、課題は解決すべき状態そのものでした。見分ける目印があります。相手の言葉の中に「検索」「出力」「通知」といった機能名が入っていたら、それはまだ要望の段階で、課題には届いていないサインです。機能名が出てきたら、その一つ手前にある困りごとを確かめる合図だと考えてください。
バイブコーディングでの確認点
バイブコーディングで確認したいのは、機能を作り始める前の一手間です。誰かから機能を依頼されたときも、自分で思いついたときも、「この機能で何が良くなるのか」を一文で書けるかを確かめてください。書けないうちは、まだ課題がはっきりしていない状態です。その一文を、AIへの依頼にそのまま添えると、AIは目的に沿った作り方を選びやすくなります。
このスライドのポイント
- 機能を作り始める前の一手間
- 依頼されたときも、自分で思いついたときも、「この機能で何が良くなるのか」を一文で書けるか確かめる
- 書けないうちは、まだ課題がはっきりしていない状態
- その一文をAIへの依頼に添えると、目的に沿った作り方を選びやすくなる
一問一答とまとめ
最後に一問一答です。「検索機能が欲しい」は、課題と要望のどちらでしょうか。……答えは要望です。機能名が入っているので、その背後の課題を確かめる必要があります。30秒のまとめです。要望は利用者の口にする欲しい機能、課題はその奥にある解決すべき状態。要望をそのまま作らず、課題へ遡るのが人間の仕事でした。次回は、その課題を誰のために解くのかを具体化する回へ進みます。関連資料は、「業務整理質問集100」と「無料相談で聞くべきことリスト」です。
このスライドのポイント
- 一問一答:「『検索機能が欲しい』は課題と要望のどちら？」→ 答: 要望（背後の課題を確かめる）
- 30秒まとめ: 要望＝口にする欲しい機能／課題＝奥にある解決すべき状態／要望をそのまま作らず課題へ遡るのが人間の仕事
- 次回: その課題を誰のために解くのかを具体化する回へ
- 関連資料: 「業務整理質問集100」「無料相談で聞くべきことリスト」
