この記事でわかること
-
新規事業開発で陥りがちな「早すぎる最適化」を避ける具体的な判断基準
-
技術的負債とスピード感のバランスを取るための実践的アプローチ
-
フェーズに応じた技術選定と設計思想の使い分け方
新規事業開発において、エンジニアはしばしば難しい選択を迫られます。「技術的負債（※1）を避けるべきか、スピードを優先すべきか」「最新技術を採用すべきか、枯れた技術で安全に行くべきか」。こうした判断の積み重ねが、事業の成否を左右することも少なくありません。
前職で約11年間にわたり数多くの新規事業立ち上げに携わってきた首藤宏朗さんは、新規事業でエンジニアに必要なのは「バランス感覚」だと語ります。事業の成長を第一に考え、「今本当に必要なのか」を問い続ける実践的な思考法について伺いました。
※1 技術的負債：将来的に修正が必要になる可能性が高い、品質の低いコードや設計のこと。短期的な開発スピードを優先した結果として生まれることが多い。
首藤宏朗
株式会社ココナラで自称ハイパーメディアクリエイター見習いとして11年、ココナラ初期の開発と（全部ではないけど）ほとんどの新規事業サービス（ココナラ法律相談、ココナラ募集、ココナラテック、ココナラアシスト、他…）の立ち上げに従事。2026年1月現在、同社を退職して起業準備中。
【SNS】：https://www.linkedin.com/in/h-shuto
目次
事業を見据えたマインドセットが全ての出発点
新規事業開発でエンジニアが持つべき「バランス感覚」について教えてください。
バランス感覚で一番大事にしていたのは、エンジニアリング自体が目的になってしまわないようにすることです。専門職なので当然なんですが、その先にある事業がなかなか見えなくなってしまう。近視眼的に目の前のことや、自分たちがやりづらいと思っていることを解消することに重きが置かれがちなんです。
具体的には、どのようなバランス感覚を意識されているのでしょうか。
常に事業として何をすべきかというところに軸を置き、エンジニアとして何をすべきかは二の次にする—これが私の考えるバランス感覚です。技術的な判断が伴うタイミングで「これって本当に必要なんだっけ」と問い続けることで、事業の成長に必要な技術的選択ができるようになります。
技術的な改善ももちろん大切ですが、事業全体の成長を常に意識し続けることが重要ですね。0->1の1にもならずにクローズするなんてことは日常茶飯事なので。
そうした考え方を身につけるのは、エンジニアにとって難しそうですね。チームに浸透させるコツはありますか？
例えば、ロジックを組んだり、データベース設計（※2）をしたりする必要が本当にあるのか、ハードコーディング（※3）をしたりJSONファイル（※4）や別の静的ファイルを置けば済む程度ではないのかといったことを確認します。その機能が事業の核となる価値なのか、それとも単なる検証目的なのかを見極めることを大切にしています。
※2 データベース設計：データを効率的に格納・検索するためのデータベースの構造を設計すること。
※3 ハードコーディング：プログラムの中に値や設定を直接書き込むこと。柔軟性に欠けるが、簡単で高速に実装できる。
※4 JSONファイル：データを格納するためのシンプルなテキストファイル形式。設定値やデータの保存によく使われる。
ブログで「失敗談は大好き」と書かれていましたが、失敗との向き合い方についてお聞かせください。
基本的に私のスタンスとして、失敗と思わないようにしています。それはあくまでも経験であって、「失敗だったな」って思うのはラベリングをしているだけです。
失敗をラベリングしてしまうと、どのような問題が生じるのでしょうか。
「期待した結果は得られなかった」という見方をして、「期待した結果が得られるようにするには、どう改善していくべきか」というところを中心に考えるようにしています。失敗というラベリングをしてしまうことによって、人間の心理としてそこにトラウマが発生するんです。
そうすると、将来同じような状況になったときに、本当はそのフェーズで以前うまくいかなかった手法が最適だったかもしれないのに、その経験があるために「あれはやめといた方がいい」みたいな判断をしてしまうことがある。そこはやはりフラットに見ていかないと、良い判断ができないと思います。
「早すぎる最適化」と先行サービスの罠
新規事業開発でエンジニアが特に注意すべき点はどこでしょうか。
私が常々メンバーに伝えて、自分も気をつけていたのは「早すぎる最適化」ですね。フェーズというのが、エンジニアリングにおいて意識されなさすぎているんです。
フェーズによって、エンジニアリングに求められるものって変わってくるんです。0→1フェーズの考え方が10→100のフェーズに合うかといったら、全然そうじゃありません。
フェーズに応じた判断が重要ということですね。具体的にはどのような例がありますか。
よく言われることですが、当然のことながら新規事業においていきなりマイクロサービス（※5）化するのは適切ではありません。数年前のマイクロサービス全盛の時代に、新規事業ではなくココナラ本体の開発に一時的に戻る機会があり、私もその時代の流れに乗って導入を検討したことがあるんですが、得られたメリットと比較すると、余計な手数が増えてしまい我々の自己満足に終わってしまったのではないかという部分が少なからずありました。
とは言え、これは時流やフェーズの問題だったりもしますし、やって良かったと思える部分も割とあるので難しい問題です。
※5 マイクロサービス：大きなアプリケーションを小さな独立したサービスに分割するアーキテクチャ手法。
マイクロサービス以外にも、「早すぎる最適化」の例はありますか？
もっと個別具体の話だと、データベース設計で抽象化（※6）を丁寧にやろうとしてテーブル（※7）がどんどん増えていくケースがあります。1テーブルで済むようなモデルだったとしても、それを分割してしまいます。
新規事業のフェーズって、そもそもよくわからないことが多くて、一般化できないことが多いんです。「将来いろんなパターンに対応できるように」と考えてデータベース設計を複雑な構造にするのも、ある意味では一般化の試みなんですが、全容が見えていない状態でやりすぎると、無用な考慮事項と手数が増えるだけで、開発速度や品質の向上には何ら寄与しません。
※6 抽象化：複雑な処理や概念を、より一般的で扱いやすい形に変換すること。
※7 テーブル：データベースでデータを格納する表形式の構造。
こうした「早すぎる最適化」が起こってしまう背景には、どのような要因があるのでしょうか。
先行サービスとの比較も判断を難しくする大きな要因ですね。外からは完成品しか見えていないので、「他のサービスにこの機能があるから、自分たちのサービスにも必要」という意見が必ず出るんですよね。
でも、参考にしているアプリやサービスはもう完成品なので、バグもそれなりに潰されているし、いろんなケアもできている。そことあまりにも差があって物足りなく感じてしまい、「これも入れるべき、あれも入れるべき」という議論になってしまいます。
なるほど。具体例があれば教えていただけますか。
例えばECサイトを作ったときに、ECサイトには一般的に「カート機能」がありますが、ECサイトの本来の目的はカートに商品を詰め込むことではなく、実際に購入してもらうことですよね。
初期段階では「カート機能」がなくても買うことはできます。カートの役割って、基本的には商品をストックしておく「お気に入り」機能のようなものなんです。そもそも初めて使うサイトで、いきなり複数の商品を購入することはあまりないので。まずはお試しで1個買ってみて、気に入ったらまた購入するというパターンが多いと思います。
確かに、ユーザーの行動を考えると最初は単品購入の方が自然ですね。
それであれば購入機能に集中すべきです。でも「ECサイトにはカートがあって当然」という考えになると、その開発にコストがかかり、リリースが1週間遅れることになる。特に新規事業のフェーズでは、1週間遅れてでも「カート機能」を作るべきか、それとも早期リリースを優先すべきかという判断が重要なんです。
技術的負債の捉え方と、現実的な技術選定
新規事業でよく議論になる「品質とスピード」のバランスについては、どのようにお考えですか。
エンジニア界隈では、どちらかというと品質を大事にする考え方が主流だと思います。品質を重視することで後の手戻りを防ぎ、結果的に開発効率が上がるという考え方ですね。実際その通りのこともあるんですが、「正解が見えていない状況で、果たして品質の最適解を定義できるのか」という問題があります。
なるほど、正解が見えない状況で品質を定義するのは難しいということですね。
何が正解かもわからないのに「これが品質だ」みたいに定義してしまうと、思考停止になってしまう。過剰設計、オーバーエンジニアリング（※8）になってしまいます。
技術的負債って、後付けで語られることが多いんですが、そのときそのときで、みんな基本的には一番最適だと思うことを選択していった結果なんです。
※8 オーバーエンジニアリング：必要以上に複雑で高度な技術や設計を採用してしまうこと。
確かに、その時々で最適だと思って選択した結果が技術的負債と呼ばれるようになるというのは、よくある話ですね。
10年以上同じ会社の開発現場にいて感じたのは、新しく参加するメンバーが、その時々のフェーズで常に前任者の行動や設計に対して「もっと良くしてやるんだ」と改善提案をする光景です。
常にいろんな人が「自分が考えた最強の○○」みたいなのをやって、またそれが次の人から見直される。それは全然自分を棚に上げるわけではなくて、私もずっとそういうことをやってきています。当時の自分は一生懸命考えて実装していたので、フェーズごとに一生懸命頑張った結果が、結果的に見直されるというのは自然なことだと思います。
最新の技術と枯れた技術の選択については、どのような基準をお持ちですか。
これは非常に難しい話で、変数が多いんです。一律にこれが正解という判断基準があるわけではないので、ケースバイケースで選んでいるところがあります。
それでも何かしらの方向性はあるのでしょうか。
今で言うと、TypeScript（※9）全盛の時代なので、具体的な技術要素でいくと、Next.js（※10）で、Vercel（※11）にホスティングして、Supabase（※12）を繋げて、DBはPostgreSQL（※13）で、みたいな技術スタックを選定していくのは順当だとは思います。
※9 TypeScript：JavaScriptに型安全性を追加したプログラミング言語。
※10 Next.js：Reactベースのウェブアプリケーション開発フレームワーク。
※11 Vercel：ウェブアプリケーションのホスティング・デプロイサービス。
※12 Supabase：データベースや認証などのバックエンド機能を提供するサービス。
※13 PostgreSQL：オープンソースのリレーショナルデータベース管理システム。
一方で技術選定においては「チームのメンバーがその技術を本当に使いこなせるのか」という問題もあります。ただAI時代になって、率直に言うと私自身は個別の言語やフレームワークの重要性は以前ほど高くなくなってきていると感じています。
ちなみに今の自分の会社では上記のスタックは一切使わずにRuby on Railsを選定しています。知り合いから今更なぜRailsなのか？とよく問われるのですが、理由を語ると長くなるのでここでは割愛させていただきます。
AIによって技術習得のハードルが下がったということでしょうか。
そうですね。新規事業での技術選定には二面性があると思っています。スピードが優先される場合や、プロダクトを捨てることも前提にあるなら、チームが慣れ親しんだ枯れた技術を選ぶのが賢明です。一方で、技術革新によって従来の課題が解決されているケースも多く、新規事業だからこそ新しい技術にチャレンジする価値もあるんです。
AIの活用で開発のアプローチも変わってきているのでしょうか。
そうですね。例えば重要度・優先度で、非常に大事な機能ですよということであれば丁寧に作り込んで、そうじゃなくて別に捨ててもいいやというものであれば、手戻りされることを関係なしに、とりあえずテスト的に当ててみる。今だったらAIで一旦コーディングして、とりあえず何か機能として成り立たせるみたいなことができます。
検証のスピードが格段に上がっているということですね。
AIの登場で、以前なら相当な時間をかけて開発していた機能も短時間で作れるようになりました。プロトタイプを素早く作ってユーザーテストを行うという流れが、格段に楽になったと感じています。
ただ、新たな問題も生まれています。AIで簡単に作れるからといって、本来ならGoogleフォームのような既存ツールで十分なシンプルな機能まで、わざわざ自作してしまうケースが増えているんです。技術的にできることと、やるべきことは別問題ですからね。
コア機能の「命名」が将来の拡張性を決める
0→1フェーズで最低限押さえるべき設計のポイントと、後回しにしても良い部分の境界線はどこにありますか。
コアバリューがあるのであれば、非常に丁寧にやるべきです。フェーズが0→1だろうが関係なく、特に命名については徹底的にこだわります。変数名一つとっても時間をかけて「本当にこの名前でいいんだっけ」と考え抜くんです。
命名がそれほど重要なのはなぜでしょうか。
コア機能の場合、それをどんどん拡張していくので、最初の命名が重要になります。例えば、プログラムでユーザーの情報を扱うシステムを作るとしましょう。
極端な例なので実際にはこういうことは起こり得ませんが、本当は「人間」を表現したいのに、適当に「犬」という名前をつけてしまったとします。四つ足があって動き回るという点では似ているかもしれませんが、歩き方も見た目も全く違いますよね。そのまま開発を続けると、人間を扱っているのに犬を扱っているような混乱したシステムになってしまい、最終的にはバグやオペレーションミスに繋がるのは容易に想像できます。
なるほど。実際のプロジェクトでも、そうした命名の問題に直面されたことがあるのでしょうか。
ありますね。人材系のサービスを始めたときに、事業サイドでは何でも「案件」と呼んでいたんです。でも開発する側から見ると、営業が管理している「求人要項」と、ユーザーに見せる「求人広告」は全く別のものなんです。
それぞれ異なるデータ構造や処理が必要なのに、日本語の会話では両方とも「案件」で済まされてしまう。そうすると認識のずれが起きやすいんです。
同じ「案件」という言葉でも、実際には異なる概念を指しているということですね。
その案件の中にはプライベートな情報とパブリックの情報があったり、ログという概念もある。そういう分解できる具体的なモデルに分解する、JobDescription、JobListing、XxxLogといった形でそれを丁寧にやったことによって、のちのち拡張性を持てました。
アーキテクチャ（※14）についてはいかがですか。
※14 アーキテクチャ：システム全体の構造や設計思想のこと。
アーキテクチャやデザインパターンは、あくまで教科書的な「型」だと思っています。よく使われる設計パターンも、単なるテンプレートに過ぎません。「このパターンが最優解だ」と盲信してしまうのは危険ですね。
これは組織作りと全く同じです。どの会社にも「完璧な組織構造」なんて存在しないじゃないですか。
確かに、組織と同様にアーキテクチャにも万能解はないということですね。
その通りです。だから会社は組織再編をしたり人を入れ替えたりするわけで、技術も同じなんです。まったく同じプロダクトを作るなら話は別ですが、ユーザー層や関係者が違えば最適な技術選択も変わってきます。
問題は、デザインパターンや一般論に固執しすぎて思考が硬くなってしまうことです。「このパターンではこうするべきだ」という考えに縛られて、目の前の課題に柔軟に対応できなくなる。これはよくある落とし穴だと思います。
事業サイドとの密な連携が成功への近道
エンジニアが事業全体を見失わないためには、どのような工夫が必要でしょうか。
私が一番大事にしているのは、事業サイドとのコミュニケーションを密にすることです。エンジニア同士でコミュニケーションしていても、そのプロフェッショナル同士の会話なので、どうしてもエンジニアリングとして何が最適かみたいなことに話題が偏りがちです。
具体的にはどのようなコミュニケーションを取られていたのでしょうか。
事業サイドとコミュニケーションして「この機能の重要度はどの程度ですか」「この実装内容は過剰になっていないでしょうか」「本当に必要な機能はどれでしょうか」といったヒアリングを行います。あとは、事業サイドに技術的なことを教える勉強会なども開いていました。あとは一緒に飲みに行くとかですね（笑）。
技術を事業の人に理解してもらうのは難しそうですが、どのような工夫をされていましたか。
例えばデータベースの説明では、Excelを使っている人には「データベースはほぼ無制限に行を追加できる表のようなもので、SQL（※15）という言語でデータを検索・絞り込みできます」といった形で、身近なツールに置き換えて説明し、開発チームの取り組みについてレビューをお願いしていました。そうすると、ある程度理解してもらえて「これはいらないかもですね」って言ってくれるんです。
※15 SQL：データベースからデータを検索・操作するための言語。
なるほど、技術を事業の言葉に翻訳して共有するということですね。相互理解が深まることで、より良い判断ができそうです。
技術的に必要なものはもちろんあるので、その言葉通りに取るんではなくて「これはなぜいらないと言っているのか」を自己解釈やヒアリングをして、「なるほど今はこのフェーズなんだ」ということをちゃんと把握する。そうすると、チームとして今何をやるべきかがある程度見えてきます。
最後に、新規事業に挑戦するエンジニアへのアドバイスをお願いします。
私は、自分の役割を単なる「エンジニア」という職種以上に、「面白いサービスを作る人間」でありたいと考えています。元々は「世の中にないものを作りたい」という想いが原動力で、そのための最も強力な武器がエンジニアリングだった、という感覚なんです。
だからこそ、開発の現場では常に「事業として何をすべきか」を軸に置き、そこから逆算して技術をどう使うかを考えるようにしています。この優先順位こそが、新規事業でエンジニアに求められる「バランス感覚」の本質ではないでしょうか。
技術的な完璧性に固執するのではなく、「今この瞬間の事業にとって何がベストか」を問い続けることが重要だということです。フェーズに応じて最適解は変わりますし、昨日の正解が今日の足かせになることもある。だからこそ、事業視点を軸にした柔軟な姿勢が成功の鍵になると思います。
ライター
