本記事は LIFULL Advent Calendar 2025の21日目の記事です。
こんにちは！LIFULLエンジニアリングマネージャーの吉永です。
本日は、エンジニアがついやってしまいがちな 「How（技術・手段）先行」でのアイディア具体化 について、なぜそれがサービスやビジネスとしてうまくいかないことが多いのか、私なりの考察をまとめてみたいと思います。
エンジニアの方であれば、新しい技術に触れた時や、自分の得意な実装パターンがハマりそうな時にアイディアがどんどん膨らんでいく...という経験、ありますよね？
私自身も「この技術を使って何か作りたい！」という衝動に駆られることはよくあります。
ただ、ビジネスやサービスとして成功させる上では、この 「How先行」は非常に高い確率で苦戦する原因 になってしまうようです。
今回はその理由をいくつかの観点で整理しつつ、自戒も込めて記事にします。
なぜ「技術的に優れている」のにうまくいかないのか？
構造的な理由として、主に以下の3点が挙げられると考えています。
1. 「課題（Why）」が不在になりがちだから
これが最大の理由だと思います。
ビジネスの基本は「誰かの困りごとを解決すること」ですが、Howから入ってしまうとどうしても 「解決策ありき」で課題を後付けする ことになってしまいます。
-
ハンマーと釘の法則
- 「金槌（特定の技術）」を持つと、目にするものすべてが「釘（課題）」に見えてしまう現象ですね。
- 例えば「ブロックチェーンを使いたい！」という思いが先行して、普通のRDBで十分なアプリに無理やり導入してしまい、結果として動作が遅く使いにくいものができてしまう...といったケースです。
-
Need（必要性）よりWant（作りたい欲）
- ユーザーが「お金を払ってでも解決したい切実な悩み」よりも、エンジニアとしての「作っていて面白い機能」が優先されてしまいがちです。
2. 「手段の目的化」が起こるから
ユーザーにとっては、裏側でどんな技術が使われているかはあくまで仕組みの話であり、極論どうでもいいことです。
ユーザーが欲しいのは「ドリル（技術）」ではなく「穴（結果・価値）」ですよね。
-
価値の不一致
- 私達エンジニアは「この処理速度はすごい」「このアーキテクチャは美しい」と評価しますが、ユーザーは「で、私の生活はどう便利になるの？」という視点でしか評価しません。
-
過剰品質
- 最初は安価でシンプルな検証（MVP）が必要なのに、How先行だと最初から堅牢で複雑なシステムを作り込んでしまい、コストと時間がかかりすぎてしまうこともあります。
3. ピボット（方向転換）が困難になるから
スタートアップや新規事業は、リリース後に市場の反応を見て修正することの繰り返しだと思います。
しかし、How（特定の技術や実装）に固執していると、この修正が効かなくなってしまいます。
-
サンクコスト（埋没費用）の呪縛
- 「せっかく苦労してこの高度なアルゴリズムを実装したんだから、これを捨てたくない」という心理が働いてしまい、市場が求めていない機能にしがみついてしまうことがあります。
-
柔軟性の欠如
- 本来は「顧客の課題を解決するためなら、プログラムを書かずにExcel運用でもいい」という柔軟な発想が必要ですが、技術ありきだとその選択肢が見えなくなってしまいます。
How先行 vs Why先行 の比較
ここまでの話を整理すると、だいたい以下の表のような対比になるかなと思います。
| 項目 | How先行（エンジニア発想） | Why先行（プロダクト発想） |
|---|---|---|
| 出発点 | 技術・ツール・実装方法 | 顧客の痛み・不満・課題 |
| 主語 | 「我々は何を作れるか」 | 「顧客は何を求めているか」 |
| 開発の優先度 | 技術的な面白さ、完成度 | 課題解決のスピード、価値 |
| 失敗の原因 | 誰も欲しがらないものを作る | 解決策が技術的に実現できない |
| 修正の方針 | 技術を活かせる別の場所を探す | 課題を解決できる別の技術を探す |
こうして見ると、アプローチが真逆であることがよく分かりますね。
例外：How先行でも成功するケース
もちろん例外もあると思います。
以下のような場合は、むしろHow先行（技術ドリブン）が強みになるケースです。
-
Deep Tech（ディープテック）領域
- 圧倒的な技術革新（例：新しいバッテリー素材、画期的なAIモデルなど）そのものが価値であり、後から用途がついてくる場合です。
-
開発者向けツール
- 自分自身がドッグフーディング（自社製品を愛用）できる場合です。「自分が欲しいもの」がそのまま「市場（他のエンジニア）が欲しいもの」と一致するため、Howへのこだわりが正解になります。
まとめ
サービスが失敗するのは技術が悪いからではなく、 「解決するに値する課題」を見つける前に「解決策」を作ってしまうから なのかなと思います。
エンジニアとしての「実装力（How）」は最強の武器です。
ただ、その武器を抜く前に、 「誰の、どんな課題を解決するために抜くのか（Who & Why）」 を徹底的に突き詰めることで、成功率は劇的に上がるのではないでしょうか。
私自身も、今後何かを作る際には 「あえてその技術を使わずに同じ価値を提供するならどうするか？」 という逆説的な問いを自分に投げかけて、本質的な価値を見極めていきたいなと思いました！
最後まで読んでいただきありがとうございました！
また次の記事でお会いしましょう。