はじめに
チームに相談せず、1人で「これは絶対にいいアイデアだ」と思い込んで実装した機能が、リリース後に誰からも触られなかったことがあります。
逆に、同じように1人で思いついたアイデアが、そのままチームの標準機能になったこともあります。
同じ「1人よがり」から始まったのに、結果が正反対になった。この違いはどこにあったのか、ちゃんと振り返ってみたいと思います。
間違ったアプローチ
最初にやってしまったのは、こういう進め方でした。
1. 自分の中で「こうすれば便利になるはず」と結論を出す
2. 誰にも相談せず実装を始める
3. 完成してから「どうですか、使ってみてください」と共有する
4. 反応が薄い、または誰も使わない
5. 「まだ良さが伝わっていないだけ」と思い込み、さらに機能を追加する
このループにハマると厄介なんですよね。反応が薄いのを「伝え方の問題」だと捉えてしまって、もっと機能を盛ることで解決しようとしてしまう。実際には、そもそも誰の課題も解決していなかった、というだけのケースが多かったです。
エリック・リースが『リーン・スタートアップ』で述べているように、プロダクト開発における最大のムダは「誰も欲しがっていないものを、効率よく作ってしまうこと」です。1人よがりのアイデアは、まさにこの「誰も欲しがっていないもの」を作るリスクを一番背負いやすい進め方だったんだと思います。
正しい理解
振り返ってみると、成功したケースと失敗したケースには、いくつか明確な違いがありました。ステップごとに整理してみます。
ステップ1: アイデアの起点を確認する
失敗したケースは「自分がこうしたら気持ちいいだろう」という起点でした。成功したケースは「チームの誰かが毎日ちょっとイライラしていた作業」を見て思いついたアイデアでした。
つまり、1人で思いついていても、種が自分の願望なのか、他人の観察された課題なのかで、勝算は大きく変わってきます。
ステップ2: 検証を安く済ませる
成功したケースでは、いきなりフル実装をせず、まず10分で作れるモックや、既存機能の組み合わせで「これで解決しそうか」を1人か2人に確認してから本実装に入っていました。
失敗パターン: アイデア → フル実装(数日〜数週間) → 公開 → 反応を見る
成功パターン: アイデア → 簡易検証(数十分) → 反応を見る → 本実装
検証のコストが低いうちに反応を見ておくと、外したときのダメージが小さくて済みます。これは当たり前のようで、1人で盛り上がっているときほど忘れがちなポイントでした。
ステップ3: フィードバックを「途中」でもらう
失敗したケースは完成してから初めて他人の目に触れました。成功したケースは、実装の途中の粗い状態で一度誰かに見せていました。
トム・デマルコが『ピープルウェア』で指摘しているように、ソフトウェア開発における問題の多くは技術的な問題ではなくコミュニケーションの問題だとされています。1人よがりのアイデアが失敗しやすいのも、技術力の不足ではなく、単純に「途中で誰にも見せていない」というコミュニケーションの欠落が原因になっているケースが多い、というのが実感です。
ステップ4: 「誰得か」を最初に言語化する
成功したケースでは、実装前に「これは誰のどんな困りごとを解決するのか」を1文で説明できる状態になっていました。失敗したケースでは、それを聞かれても「便利だから」としか答えられませんでした。
良い例: 「毎朝の集計作業を手動でやっている人の、その5分を減らす」
悪い例: 「なんとなく便利だから」
この1文が作れるかどうかは、思いつきと課題解決の分かれ道になっていました。
ステップ5: 小さく出して育てる
1人よがりのアイデアがそのまま大きく育つことはほとんどありませんでした。成功したケースでも、最初のバージョンは今よりずっと小さく、粗いものでした。そこから使われ方を見て、削ったり伸ばしたりを繰り返した結果、今の形になっています。
つまり、1人で思いついたアイデア自体が悪いわけではなく、「1人で完成させてから見せる」という進め方が問題だったんだと思います。
おわりに
1人よがりのアイデアそのものは、悪いものではありません。むしろ、誰かが困っていることに気づける観察力や、それを解決しようとする発想は貴重なものです。
分かれ道になるのは、そのアイデアを「自分の中だけで完成させてしまうか」、それとも「早い段階で他人の目に触れさせるか」というところでした。
次に「これは絶対いい」と思うアイデアが浮かんだら、まず完成させる前に、誰かに1分だけ見せてみようと思います。