はじめに

はじめまして。株式会社エヌケーエナジーシステム CTOの松本です。

弊社は、AI搭載のデジタルセールスルーム「コレタ for Sales」を開発・運営しています。

この記事では、スタートアップの0→1フェーズ——PMF（Product-Market Fit）を目指す過程で、開発組織としてどんな判断をし、何を大切にしてきたかをお話しします。「こうすべき」という教科書的な話ではなく、実際にやってきた中でのリアルな考え方を共有できればと思います。同じようなフェーズにいるエンジニアやCTOの方に、少しでも参考になれば嬉しいです。

創業の原点や、なぜこのプロダクトを作ろうと思ったのかについては、CEOの野田がこちらの記事で詳しく話しているので、気になる方はあわせて読んでみてください。

自己紹介

簡単に私の自己紹介をさせていただきます。

新卒では自動車メーカーの研究職として働いていましたが、趣味で始めたプログラミングに魅入られ、WEBエンジニアに転身しました。受託開発企業、中小企業支援のSaaSを提供する企業を経て、現在は「コレタ for Sales」のCTOとしてプロダクト開発を牽引しています。

0→1フェーズで最も大事にしていること

CEOの意思決定を最速で形にする

PMFを達成するまでのフェーズで、開発組織として最も重要な役割は何か。私の答えは明確で、「CEOの意思決定を最速で実現すること」です。

PMFしていないプロダクトにおいて、完璧な機能を作り込んでからリリースしようとするのは悪手だと考えています。どれだけ事前に検討しても、結局はユーザーに使ってもらって初めてわかることが多い。仮説を素早く形にして、市場からのフィードバックを得ることの方がはるかに価値があります。

ソフトウェア開発の世界には「YAGNI（You Aren't Gonna Need It）」という原則があります。「今必要でないものは作るな」という考え方です。実際、コレタでもPhase2で対応予定だった改善が、今でも他の優先事項に押されて未着手のまま残っているものがあります。逆に言えば、それでもプロダクトは前に進んでいる。当時「絶対に必要だ」と思っていた機能も、蓋を開けてみれば優先度が変わっていることは珍しくありません。

ただし、手を抜いてはいけない領域がある

とはいえ、すべてをスピード優先で進めればいいわけではありません。注力すべきポイントは明確にあります。

特に重要なのはデータ構造の設計です。データ構造が適切に設計されていないと、ビジネスロジックが必要以上に複雑になったり、後からデータの移行や構造変更が必要になったりします。それは短期的には見えにくいコストですが、中期的に見ると開発速度を大きく落とす原因になります。

また、後から変更しにくい大きな仕様の判断、採用するアーキテクチャ、技術選定なども同様です。これらは「一度決めると引き返しにくい」性質を持っているので、相対的に多くの時間をかけて検討する方がコストパフォーマンスが良いと実感しています。

スピードを重視する部分と、しっかり時間をかける部分。このメリハリが0→1フェーズにおける開発の肝だと思っています。

属人化を恐れすぎない

エンジニアリング組織の文脈では「属人化は悪」という考え方が広く浸透しています。私自身もそう思ってきました。しかし、初期フェーズにおいては属人化を許容してスピードを高めた方が、結果的に何倍も早く進めるという実感があります。

もちろん、属人化を完全に放置するわけではありません。追加メンバーがジョインした際のキャッチアップや、チーム内での情報共有のために、最低限のドキュメントは残すようにしています。ただ、初期フェーズで過度にドキュメント整備や仕組み化に時間を使うと、それ自体がプロダクトの進化を遅らせてしまう。「今この瞬間に最適なバランスはどこか」を常に意識するようにしています。

CTOとして向き合ってきた難しさ

CEOと顧客を深く理解すること

「何を作るか」のミスマッチを防ぐことは当然として、CTOに求められるのはその先にある理解だと思っています。今作っている機能の次に、どんな要望や改善が求められるのか。その解像度を持っておくことで、設計やアーキテクチャの中に「備え」を仕込んでおける。

これは一見、先ほど述べたYAGNIと矛盾するように見えるかもしれません。しかし、明確に拡張が求められると予想される領域に全く備えずに作るのは、中長期の工数を不必要に増やしてしまいます。「投機的に作り込む」のと「備えを持って設計する」のは似て非なるものです。

UI/UXの設計でも、背景への深い理解が効いてきます。ビジネスの文脈を理解した上でUIを設計すると、「この設定項目は別の画面に置いた方がユーザーにとって自然だ」といった判断が自然にできるようになる。逆に、表面的な理解で実装を進めると、後から「想定とズレていた」ということが起こります。軽微なズレなら実装フェーズで修正できますが、大きなズレはまるまる工数が無駄になるリスクを孕んでいます。

中長期のビジョンを把握しておくこと

エンジニアメンバーとの対話においても、中長期のビジョンの理解は重要です。

誰でも、自分が作る機能がプロダクト全体の中でどんな意味を持つのか知りたいと思うものです。意義がわからないまま機能追加をするのは、エンジニアにとってモチベーションの低下に直結します。「なぜこれを今作るのか」「この機能が将来どうつながるのか」に対して明確に答えられる状態を保つことが、CTOとしての責務だと感じています。

そのためには、日頃からCEOと密にコミュニケーションを取り、事業の方向性やビジョンを自分の中に取り込んでおく必要があります。技術だけを見ていては、良い開発組織は作れません。

日々の改善を後回しにしないこと

スピード感を持って開発を進めていると、「改善した方がいいとわかっていること」を後回しにしがちです。目の前の機能開発に追われて、コードのリファクタリングやCI/CDの改善、開発体験の向上といったことが置き去りになる。

大事なのは、顧客に価値を届け続けることを短期ではなく中長期のスパンで捉えることです。日々の小さな改善が積み重なって、中期的な開発速度を引き上げる。わかっていても、目の前のタスクに追われていると実行に移すのは簡単ではありません。

コレタの開発チームでは、定期的に振り返りの時間を設けて、改善すべきポイントを洗い出し、実際にアクションに移すサイクルを回しています。完璧にはできていませんが、「改善を忘れない仕組み」を持つこと自体が大事だと思っています。

やりがいと、これから

顧客の声を直接聞きながら、新しい機能や改善を届けていけることは、このフェーズならではの大きなやりがいです。自分たちが作ったものに対する反応がダイレクトに返ってくる。その距離感の近さは、スタートアップの開発チームにいるからこそ味わえるものだと思います。

ありがたいことに、コレタ for Salesは着実に成長を続けています。「営業×AI」の領域で独自のポジションを築きつつあり、中小企業から大企業まで幅広い企業様にご利用いただけるようになってきました（プロダクトの詳細やビジョンについては、こちらの記事でも紹介しています）。

利用企業の規模や業種が広がるほど、求められる機能の幅も深さも増していきます。だからこそ、技術的な難易度は日々上がっている。しかし、その課題に対して試行錯誤するプロセスそのものが楽しいと感じています。特に今はAIの進化によってプロダクトで実現できることの幅が大きく広がっています。「ここまでがエンジニアの仕事」と境界を設けるのではなく、テクノロジーを活かして顧客にどんな価値を届けられるかを考え続けること——それがコレタの開発組織が持ち続けたい姿勢です。

プロダクトの成長に伴い、開発組織としても次のステージに向けた体制強化を進めています。一緒にプロダクトを成長させていける仲間が増えたら嬉しいなと思っています。

おわりに

0→1フェーズの開発に正解はないと思っています。ここに書いたことも、あくまでコレタというプロダクトの文脈で私たちが選んできた道であり、すべてのスタートアップに当てはまるわけではありません。

ただ、「スピードと品質のバランスをどこに置くか」「属人化とのつき合い方」「ビジネスへの理解がなぜ技術に効くのか」といったテーマは、多くの開発組織が向き合うものだと思います。この記事が、同じような課題に取り組んでいる方にとって、何かしらのヒントになれば幸いです。

ここまで読んでいただき、ありがとうございます。
コレタでは、この挑戦を一緒に進めてくれる仲間を探しています。

新卒、インターン、中途、問いません。スタートアップ企業で裁量を持って働きたい方、急成長するプロダクトに関わりたい方。

まずはお気軽にカジュアル面談でお話ししましょう。 ご連絡お待ちしています。