この記事は何？
個人開発を始めたいと思っても、最初にぶつかるのは実装ではなく、「何を作ればよいのか分からない」という問題かもしれません。（私自身、この壁にぶつかっています。）
技術を試すために作るのも楽しい一方で、せっかくなら誰かに使ってもらえるものを作りたい。でも「世の中にない、画期的なアイデア」を探し始めると、なかなか手が動きません。
この記事では、個人開発のアイデアを考えるときに使える切り口を整理します。あわせて、私が作っている「プロジェクトマネージャ試験 論文添削AI」を例に、切り口をどう企画へ落とし込むかを紹介します。
アイデアは、ひらめきを待つものというよりも、課題を見る角度を増やして見つけるものだと考えています。
まずは「新しいもの」より「困りごと」を探す
個人開発のアイデアを考えるとき、「まだ誰も作っていないもの」を探しがちです。
ただ、完全に新しいものを最初から狙うと、次のような状態になりやすいと思います。
- すでに似たサービスがあると分かって、案を捨ててしまう
- 対象者も利用場面も曖昧なまま、機能だけが増える
- 正解が分からず、実装に入れない
既存サービスがあることは、必ずしも悪いことではありません。少なくとも、そこには誰かの課題が存在する可能性があります。
大切なのは、誰が、どの場面で、何に困っているのかを具体的にすることです。そのうえで「既存の方法より少し楽にできないか」「特定の人にもっと合う形にできないか」を考えると、作るものの輪郭が見えやすくなります。
以下では、アイデアの種を見つけるための5つの切り口を紹介します。
切り口1：自分や身近な人が繰り返している面倒
日常や仕事の中にある、繰り返し発生する小さな面倒を観察します。
- 毎回、同じ形式にデータを整えている
- 複数のサービスを見比べて情報を集めている
- 転記、集計、確認を手作業でしている
- 調べた内容を、次の機会にまた調べ直している
自分が困っていることは、同じ立場の人も困っている可能性があります。特に、面倒ではあるものの「手作業で何とかできてしまう」作業は、後回しにされやすい一方で、ツールによる改善余地があります。
この切り口では、次のように書き出すと考えやすくなります。
〇〇をするとき、毎回△△するのが面倒だ。
□□できれば、この手間を減らせるのではないか。
たとえば「請求書を受け取るたびに、必要な項目をスプレッドシートへ転記するのが面倒」という観察から、OCRで項目を読み取り、確認後に登録できるツールのアイデアにつながります。
切り口2：不安が大きい場面
人が「これで合っているだろうか」と確認したくなる場面にも、アイデアの種があります。
たとえば、次のようなタイミングです。
- 書類やレポートを提出する前
- コードや設定を本番へ反映する前
- 試験や発表の直前
- 申請内容を送信する前
こうした場面では、利用者が求めているのは必ずしも「正解をすべて代わりに作ってくれること」ではありません。抜け漏れの確認、改善すべき箇所の指摘、次に何をすればよいかという道筋があるだけでも、不安を小さくできます。
この切り口のポイントは、利用者が抱える不安を、具体的な確認項目へ分解することです。
| 漠然とした不安 | 確認したいこと |
|---|---|
| この文章で提出してよいか | 設問に答えているか、主張と根拠がつながっているか |
| この変更をリリースしてよいか | テスト漏れや設定漏れがないか |
| この申請内容でよいか | 必須項目や添付書類に不足がないか |
切り口3：既存サービスへの不満
すでにあるサービスを使っていて感じる不満も、立派な出発点です。
- 価格が高く、気軽に試せない
- 結果が返るまで時間がかかる
- 機能が多すぎて、必要な操作にたどり着けない
- 専門知識がないと設定できない
- 日本語や特定の業務フローに合っていない
ここで目指すのは、大手サービスを丸ごと置き換えることではありません。対象者や利用場面を絞ることで、「この人にとっては既存サービスより使いやすい」という価値を作れます。
たとえば「文章添削サービス」という大きな括りで競争するのではなく、「論述式試験の答案を、試験で意識すべき観点に沿って見直す」という場面に絞れば、必要な機能を明確にできます。
カスタマーレビューは課題の言葉を集める場所
自分が当事者ではない領域では、競合である既存サービスのカスタマーレビューを読むのも有効です。レビューには、利用者が実際に感じた不満や困りごとが、利用者自身の言葉で書かれています。
特に次のような表現をメモしておくと、課題の仮説を作りやすくなります。
- 「〇〇ができれば使い続けたい」
- 「△△するのに時間がかかる」
- 「初心者には分かりにくい」
- 「この用途には向いていない」
ただし、1件のレビューだけで需要があるとは判断できません。複数のサービスやレビューを見比べ、同じ不満が繰り返し現れるかを確認する材料として使います。
切り口4：新しい技術で、今まで難しかったことを可能にする
生成AI、音声認識、OCR、画像認識などの新しい技術は、個人開発の選択肢を広げています。
ただし、出発点を「AIを使いたい」にすると、技術のために課題を探すことになりがちです。次の問いに置き換えると、企画として考えやすくなります。
これまで「高コスト」「時間がかかる」「専門家でないと難しい」とされていたことを、もっと手軽にできないか？
技術と課題を組み合わせる例です。
| 技術 | これまでの難しさ | アイデアの例 |
|---|---|---|
| 生成AI | 添削に時間や費用がかかる | 改善観点をすぐ返す文章添削支援 |
| 音声認識 + 生成AI | 会議メモの作成に手間がかかる | 決定事項と次の作業に絞った議事録作成 |
| OCR + 生成AI | PDFや紙資料を横断して探しにくい | 文書を取り込んで検索・要約するツール |
| 画像認識 | 目視での記録・確認が必要 | 写真から状態を記録・比較する補助ツール |
技術は価値そのものではなく、課題を解決するための手段です。技術を使うことで「誰が、何を、どれくらい楽にできるか」まで説明できるかを意識します。
切り口5：対象者を狭くして深く刺す
「誰でも使えるもの」を目指すと、誰にとって何が便利なのかがぼやけやすくなります。
最初は対象者を狭く決めたほうが、課題、必要な機能、伝える言葉を具体化しやすくなります。
| 広すぎる表現 | 対象を絞った表現 |
|---|---|
| 文章添削AI | PM試験の論述答案を見直すAI |
| タスク管理アプリ | 複数案件を並行するフリーランス向けの締切管理 |
| 家計簿アプリ | サブスクリプションの契約更新を把握する家計簿 |
対象を絞ることは、対象外の人を切り捨てることではありません。最初に価値を届ける相手を決めることです。使われる中で、必要であれば対象を広げられます。
また、対象を狭くすると、企業が大きな市場としては優先しにくいニッチな領域を狙いやすくなります。利用者数は多くなくても、困りごとが明確で既存の選択肢が少なければ、個人開発でも意味のある価値を届けられます。
具体例：PM試験の論文添削AIを企画してみる
ここまでの切り口を使って、実際の企画を整理してみます。
私が作っているのは、「プロジェクトマネージャ試験 論文添削AI」です。IPAのプロジェクトマネージャ試験における論述答案を、AIを使って繰り返し見直すための学習アプリです。
問題文を確認しながら答案を書き、採点後は観点ごとのフィードバックを見て次の改善につなげられるようにしています。
このテーマを選んだ理由は、私自身がプロジェクトマネージャ試験の受験を考えており、「自分で使いたい」と感じたからです。個人開発では、自分が当事者である課題から始めると、困る場面や必要な機能を具体的に想像しやすくなります。
試験対策を調べると、午前のマーク式問題を扱うサイトは多く見つかります。一方で、午後の論述式問題について、答案を繰り返し見直すための支援は相対的に少ないと感じました。午後対策に焦点を絞ることで、汎用的な学習サービスとは異なる切り口を作れると考えました。
市場規模は大きくはないものの、ニッチだからこそ検討する価値があります。IPAが公開している令和7年度の統計資料では、プロジェクトマネージャ試験の応募者は13,540人、受験者は8,511人でした。毎年1万人前後が試験を意識する領域と捉えれば、個人開発で仮説を検証する対象としては十分だと判断しました。
この企画を、先ほどの切り口に当てはめると次のようになります。
| 観点 | 整理した内容 |
|---|---|
| 対象者 | プロジェクトマネージャ試験の論述式試験に取り組む受験者 |
| 困りごと | 自分の答案を客観的に評価しにくい |
| 不安が生まれる場面 | 答案を書き終え、提出・練習の次の一手に迷うとき |
| 既存の方法の難しさ | 人に添削を頼むには、時間・費用・依頼のハードルがある |
| 技術でできること | 設問対応、構成、具体性、一貫性などの観点で改善のヒントを返す |
ここで重要なのは、「AIで文章を添削する」こと自体ではありません。
受験者が知りたいのは、単なる誤字脱字だけではなく、設問に答えられているか、経験や根拠が具体的か、答案全体に一貫性があるかといった点です。試験に取り組む人が不安を感じる場面に絞ることで、汎用的な文章添削とは異なる支援を考えられます。
最初のMVP（Minimum Viable Product）をどう考えるか
企画段階で最初から多機能にする必要はありません。このアプリであれば、最初の版は次の流れだけでも価値を検証できます。
- 受験者が答案を入力する
- AIが観点ごとに、良い点と改善のヒントを返す
- 受験者が答案を書き直す
「添削が正しいか」だけでなく、「改善すべき箇所が分かり、次の答案作成に進めるか」を見ることが重要です。
アイデアを形にするチェック項目
候補が出てきたら、次の質問に答えてみます。
- 誰のためのものか？ 一文で具体的に説明できるか
- その人は本当に困っているか？ 想像だけでなく、自分の経験や観察があるか
- 何がどう楽になるか？ 利用前と利用後の違いを説明できるか
- 小さく作れるか？ 最初の版で、価値の中心だけを試せるか
- また使う理由があるか？ 一度きりではなく、継続して使う場面があるか
すべてに最初から明確な答えを出せなくても構いません。答えが曖昧な部分こそ、実際に作って確かめるべき仮説です。
まとめ：正解のアイデアではなく、検証できる仮説を作る
個人開発では、最初から「絶対に使われる正解」を見つける必要はありません。（見つけようとしてもできない）
まずは、身近な面倒、不安が生まれる場面、既存サービスへの不満、新しい技術で変えられること、そして特定の対象者に目を向けます。こうした切り口で候補を出し、最も小さな形で作ってみる。その反応をもとに、企画を育てていくのが現実的だと思います。
私自身、「作りたいものがない」と感じたときは、ひらめきを待つよりも、自分や身近な人が感じた不便を一つ書き出すようにしています。そこから次に作るものの種が見つかるかもしれない、と考えています。
参考リンク
- 個人開発者の技術ノート。 — 個人開発での試行錯誤や技術的な学びを記録しているブログ
- プロジェクトマネージャ試験 論文添削AI — 本記事で企画例として紹介した学習アプリ
- IPA：統計情報（応用情報技術者試験、高度試験、情報処理安全確保支援士試験） — プロジェクトマネージャ試験の応募者・受験者数を確認した統計資料