1.企画

学習目標

企画が、何を作るかを決める最初のフェーズだと説明できる
企画を Why（課題）→ How（解決策）→ What（プロダクト）の順に、解像度を上げて具体化できる
既存のアプリの Why・How・What を読み解き、自分たちの企画に活かせる
ユーザー・テクノロジー・ビジネスの3つの視点で企画を検討できる
Why・How・What を、プロダクトのコンセプトとしてまとめられる

開発プロセスは、全体像のとおり企画から始まります。企画では、これから何を作るかを決めます。本章では、企画を Why（課題）→ How（解決策）→ What（プロダクト）の順で組み立て、ユーザー・テクノロジー・ビジネスの3つの視点で検討して、プロダクトのコンセプトにまとめます。

1. 企画フェーズ

1-1. 企画で決めること

企画は、開発プロセスの最初のフェーズで、これから何を作るかを決めます。作るものが定まっていなければ、その後の要件定義や設計で、何を対象にするかが定まりません。

企画でまとめた内容は、次のフェーズである要件定義の前提になります。企画があいまいなまま進むと、後のフェーズで前提が崩れ、企画まで戻って決め直すことになります。

1-2. Why → How → What

作るものを決めるとき、作るもの自体から考え始めることがあります。先に作るものを決めると、誰が何のために使うのかが後回しになり、誰も必要としないものを作ってしまうおそれがあります。

そこで、なぜ作るのか（Why）から始め、Why（課題）→ How（解決策）→ What（プロダクト）の順に具体化します。

段階	問い
Why	なぜ作るのか。ユーザーのどんな課題を解き、どんな価値を生むか
How	その価値を、どんな解決策で生み出すか
What	解決策を形にしたプロダクトは何か

How では、「課題を解決する」で止めず、価値を実際に生み出すところまで解決策を具体化します。この具体化の深さが、企画の質を決めます。

次節からは、多くの開発者が使う Q&A サイト Stack Overflow を例に、Why から What までを読み解きます。

2. Why

Why は、なぜ作るのかを定める段階です。解決したい課題と、それを解く価値を明らかにします。

2-1. ユーザーと課題

課題は、必ず「誰の」課題かを伴います。まず、ソフトウェアを使うユーザーを具体的に定め、その人がどんな状況で何に困るのかを捉えます。ユーザーがあいまいなままでは、課題もあいまいになります。

例：Stack Overflow のユーザーは、コーディング中にエラーや実装で行き詰まる開発者です。行き詰まると答えを探しますが、このサービスが生まれる前、頼れる場所には欠点がありました。有料サービスは、答えを検索エンジンには見せながら、人が開くと隠して課金を求めました。掲示板やメーリングリストでは、良い回答が時系列に埋もれ、古くなっても直されません。信頼できる答えに、早くたどり着けませんでした。

2-2. 課題の確かめ方

課題は、思い込みになりやすいものです。想像で決めると、誰も困っていない課題を解こうとしてしまいます。そのため、思い描いた課題が本物かを、実際のユーザーに確かめます。本当に困っているか、どれくらいの頻度で起きるかを聞きます。

例：Stack Overflow の創業者は開発者自身で、この困りごとを日々経験していました。自分や身近な人が実際に抱える困りごとは、確かめやすい出発点になります。

2-3. 解決の価値

価値は、課題が解決した状態と現状との差です。価値を見るときは、それが誰にどこまで届くかまで捉えます。目の前の一人にとどまらず、より広い範囲に届く価値もあります。

例：Stack Overflow では、同じ疑問に世界中の開発者が何度も直面します。一度書かれた良い回答は、あとから検索する何千人もの役に立ちます。このサービスの価値は「質問した一人を助ける」ことではなく、「一度の回答を、将来同じ疑問を持つ多数が読める形で残す」ことです。

3. How

How は、課題をどう解決するか、その解決策です。価値を実際に生み出すところまで具体化します。

3-1. 解決策の組み立て

How では、価値をどんな解決策で生み出すかを描きます。表面の機能を並べるのではなく、その機能が成り立つ理由まで捉えます。「誰が、どうやって、それを続けるのか」を問うと、その理由が見えてきます。

例：Stack Overflow が解くのは「信頼できる答えを、多数に、古びない形で届ける」ことでした。専門家が一人ずつ答えていては、増え続ける疑問に追いつかず、回答もいずれ古くなります。そこでこのサービスは、回答の質を見極める仕事そのものを、コミュニティに委ねました。誰でも回答でき、誰でも投票でき、多くの人が正しいと判断した回答が上位に来ます。古くなれば、気づいた利用者が書き換えます。

この解決策を支えるのが評価（reputation）です。役に立つ回答をするほど評価が上がり、できることが増えます。そのため開発者は、報酬がなくても進んで回答し、修正を続けます。核心は機能の寄せ集めではなく、「コミュニティが自分たちで良い回答を選び、改善し、保ち続ける」という解決策そのものです。

3-2. 解決策と価値の対応

解決策は、Why で定めた価値に答えていなければなりません。答えていなければ、Why に戻って課題を捉え直すか、別の解決策を考えます。Why と How がつながっていることを、What に進む前に確かめます。

例：Stack Overflow の解決策は、コミュニティが選んで改善した最良の回答を、検索で見つかる形で残します。これにより、将来同じ疑問を持つ多数に届き、Why で広げた価値に応えます。

4. What

What は、解決策を形にしたプロダクト（製品・サービス）です。Web サービスもプロダクトの一種です。

4-1. 解決策からプロダクトへ

How で解決策を具体化していれば、作るプロダクトは自然に定まります。解決策を形にしたものが、そのままプロダクトになります。

例：Stack Overflow の「コミュニティが選んで改善する」解決策が形になると、できあがるのは掲示板ではありません。一つの疑問に対する最良の回答が検索で見つかり、コミュニティの手でつねに新しく保たれる、質問と回答の集まりです。

4-2. 企画の範囲

What で決めるのは、プロダクトの輪郭までです。細かな仕様は、次の要件定義で詰めます。企画では、Why・How・What を一貫させるところにとどめます。

例：Stack Overflow なら、評価が何点で何ができるか、編集をどう扱うかといった具体は、企画では決めません。

5. 3つの視点

Why → How → What で組み立てた企画が妥当かを、3つの視点で確かめます。ユーザー・テクノロジー・ビジネスの視点で、それぞれ別の問いを立てます。

視点	問い
ユーザー	ユーザーは本当にこれを使うか
テクノロジー	技術的に実現できるか
ビジネス	作り、使い続ける価値があるか

よい企画は、3つすべてを満たします。1つでも欠けると、使われない・作れない・続かない、のいずれかになります。

5-1. ユーザーの視点（Desirability）

ユーザーが本当にこれを使うか（望ましさ）を確かめます。ユーザーの目標・利用状況・制約・感情に照らします。

例：Stack Overflow では、開発者は日々疑問に直面し、その多くは検索から答えにたどり着きます。質問者だけでなく、検索で訪れる多数に価値があるため、使われ続けます。逆に、回答が集まらず質も低ければ、使われません。

5-2. テクノロジーの視点（Feasibility）

その解決策を技術的に実現できるか（実現可能性）を確かめます。チームでは、自分たちの技術と限られた期間で作りきれるかが特に問われ、作れる範囲に収まっているかを見ます。

例：Stack Overflow の中心となる質問・回答・投票は、データの保存と集計で実現でき、Java Web の CRUD に投票の集計を足した構成です。この部分は期間内でも作れます。一方、評価による権限や編集の扱い、検索の最適化は、それぞれ大がかりで、期間内には収まりません。

5-3. ビジネスの視点（Viability）

作って使い続ける価値があるか（事業性）を確かめます。かけた労力に見合うか、使いたい人が十分にいるか、似たサービスとの違いがあるか、長く使われ続けるかを見ます。

例：Stack Overflow では、質問と回答が増えるほど、開発者が検索したときに既存の回答に当たる確率が上がります。検索から訪れる人が増え、回答が多いほどさらに人が集まります。一度書かれた回答は、後から何度も読まれます。答えを無料で公開したことが、答えを隠して課金していた有料サービスとの違いでした。運営は求人広告などの収入で支えます。

6. コンセプト

6-1. Why・How・What をまとめる

Why（課題）・How（解決策）・What（プロダクト）の3つを合わせたものが、そのプロダクトの コンセプト です。コンセプトは、「誰の・どんな課題を・どう解決し、何を作るか」を一つにまとめた、企画の中心です。3つの視点での検討は、このコンセプトが妥当かを確かめる材料になります。

例：Stack Overflow のコンセプトは、「コーディングで行き詰まる開発者に、コミュニティが選んで保つ最良の回答を、検索で届けるプログラミングの Q&A サイト」です。

6-2. コンセプトの例

例：Stack Overflow のコンセプトを項目で整理すると、次のようになります。

項目	内容
プロダクト（What）	開発者の疑問に最良の回答を届ける、プログラミングの Q&A サイト
ターゲットユーザー	コーディングで行き詰まる開発者と、同じ疑問を検索する開発者
課題（Why）	信頼できる答えに早くたどり着けない。既存の情報は隠れる・古い・埋もれる
価値（Why）	一度の回答を、将来同じ疑問を検索する多数が読める形で残す
解決策（How）	回答の質を見極める仕事をコミュニティに委ね、投票で最良の回答を上位にし、編集で古びさせず、評価で貢献を促す

本章では、コンセプトを固めるところまでを扱います。スケジュールや体制は、プロジェクトの進め方であらためて扱います。