はじめに
先日、「開発生産性カンファレンス 2025」と「SRE NEXT 2025」にスポンサーし、「今から新規事業・プロダクトを開発するならこれをやっておけ！」をテーマにブース出展しました。
当日は現場の課題に向き合う多くのエンジニアやマネージャーの方々がブースに立ち寄ってくださり、その場でしか聞けないリアルな課題や、各社の開発・運用ノウハウについて生の意見やアドバイスをたくさんいただくことができました。
また、「理想論と現実のギャップに悩んでいるのは自社だけではない」という共通認識を、多くの参加者と共有できたのも大きな収穫です。どの会社も「理想」と「現場」の間で試行錯誤していることが分かり、お互いにエールを送り合えた気がします。
この記事では、会場で集まった意見や気づきを、創業4ヶ月目の弊社の現状や実際の課題と照らし合わせて整理してみました。同じフェーズのスタートアップ、新規事業に挑むみなさんの参考になれば幸いです👋
イベントで集まった意見
今回のイベントでは、さまざまな立場の参加者から実践的なアドバイスが寄せられました。私自身にも響くトピックが多く、当日もディスカッションが活発に行われ、「悩み」や「工夫」を率直に語り合う場になったのがとても印象的でした。
ここからは、いただいた意見をもとに、改めて得た知見や気づきを、自社の現状と照らし合わせながら整理していこうと思います。
自社の現状といただいた意見
インセプションデッキの作成
インセプションデッキは、アジャイル開発や新規プロダクト開発の現場で「なぜやるのか」「誰のため」「どうやって成功させるか」などのプロジェクト全体像やビジョン、ゴール、優先順位、スコープを明確にするためのフレームワークです。
この手法を活用することで、迷走や認識ズレが未然に防げたり、変化のときに原点へ立ち返ることができます。特に外部パートナーや新メンバーの参画、試行錯誤が多いプロジェクトでは、その重要性が高いと実感しています。
ただ、創業4ヶ月・少人数スタートアップである現状を振り返ると、今は「ほぼ1人1プロダクト」^「toB SaaS 後発組」という背景もあり、要件を固めてから作るウォーターフォール型に近い進め方になっています。そのため、今すぐインセプションデッキが必須とまでは感じていません。
ただ、事業やチームが拡大したとき「なぜこの事業をやるのか？」といった根本にいつでも立ち返れるようにしておくこと、暗黙知が伝わりにくくなるタイミングを見越して、どこかで言語化や共通認識を持てるよう備える意識は持っておかないとなと改めて感じました。
ユーザー像・ペルソナの明確化
プロダクト開発における最大の難関の一つが「ターゲットユーザーの明確化」です。本来は「誰にどんな価値を届けるか」をできるだけ早い段階で明文化し、プロダクト設計や営業方針としっかり紐づけておくのが理想かと思います。しかし実際の現場では、「開発を進めながら仮説検証し、ターゲットを調整する」ことも多いのが実情です。
弊社もまさにこの課題に直面しています。
- 「国内企業の PoC 用途なのか、グローバル展開できる設計なのか」といった粒度や視点が曖昧
- セールスと開発の間で、「今どの機能を誰向けに、いつまでに届けるのか」という認識を常に揃えられていない
現在、弊社では機能単位で「PMF（プロダクト・マーケット・フィット）レベル」を β、Level1、Level2、Level3、Level Max と段階分けしていますが、実際にはそのレベル感や認識にズレが生じていたケースも多々ありました。今後は、各機能ごとに PMF レベルの定義やターゲット像をより具体的に明文化し、開発や営業の現場で共通認識として持てるよう整理していく予定です。
RDB 正規化をやりすぎない
データベース設計では「RDB の正規化」は王道ですが、やりすぎがパフォーマンス悪化や複雑化の原因になることもあります。
弊社では原則として正規化ベースで DB 設計をしていますが、人材データの履歴のような複雑な情報は JSON で持ち、Join なしで高速アクセスできる形にしています。一方、従業員一覧画面やアプリの一覧画面では Join が多発し、「正規化しすぎたせいで重くなる」いわゆる Join 地獄にも陥っています。
まずはクエリの見直しやインデックス設計などのパフォーマンスチューニングで改善を試みていますが、今後さらにデータが増えていくことを考えると、「NoSQL データベースを採用し、より柔軟かつ構造化データを効率よく管理する設計」に移行する必要性も見えはじめています。
今後も既存の設計思想は大事にしつつ、データ量・アクセスパターンの変化に応じて、柔軟に最適なストレージ技術・構造を選択していきたいと考えています。
AI の積極的利活用
スタートアップのリソース制約を逆手に取り、「AI の早期導入」は弊社の大きな方針の一つです。
- 全社員への Cursor Pro プラン導入
- Devin の活用
- Gemini Code Assist for GitHub によるコードレビュー
- Claude Code や Perplexity 等も現在検討中
このようなツールを初期から積極的に導入するとともに、週2回の30分輪読会を設け、AI 活用のノウハウや最新動向が自然と社内に循環する仕組みも取り入れています。
近年はグローバルの急成長スタートアップでも「AI 活用の速さ・習熟度こそが持続的な競争力」だと言われており、弊社も “AI 前提” のカルチャーづくりに注力しています。実感として、AI の活用を“当たり前”にしたことで、個々の業務効率化だけでなく、日々の開発やリサーチ、意思決定のスピードアップに直結していると感じています。
DDD・CI/CD・IaC・テスト・オブザーバビリティ体制の早期構築
新規事業の現場では「まずはスピード重視で作る」ことが優先されがちですが、弊社では「やらないこと」を明確にし、以下のような本当に必要な技術（基盤）しっかり投資するという「引き算志向」のアプローチを重視しています。
- DDD
- CI/CD の自動化
- IaC
- テスト
- オブザーバビリティ
この考え方の根底には、「すべてを手当たり次第に実装するのではなく、アーキテクチャの特性や優先順位をよく見極め、事業フェーズや開発リソースに応じて“削る勇気”を持つ」という考え方があります。安易に最新トレンドやベストプラクティスを全て取り入れるのではなく、自分たちの今とこれからに本当に必要な基盤だけを見極めて、そこにしっかりリソースを集中させています。
この「引き算志向」は、開発生産性カンファレンスで登壇したかわうそさんによる実践事例とも重なります。具体的な設計判断やバランス感覚については、こちらのスライドも是非ご覧いただければと思います。
おわりに
今回、カンファレンススポンサーという立場を通じて、改めて「理想」と「現実」のはざまで日々格闘するスタートアップ経営・プロダクト開発のリアルを肌で感じました。王道のベストプラクティスや他社の知見に学びつつも、自社の状況に適した意思決定を積み重ねていく、その難しさと面白さを実感しています。
この記事が、同じように悩みながら前に進む方や、同じフェーズのスタートアップ、新規事業に挑むみなさんのヒントやエールになれば嬉しいです。
また、来月の Platform Engineering Kaigi 2025 にもスポンサーとして参加します。今後もさまざまな企業の方々とカジュアルに情報交換したり、悩みや工夫を気軽に共有し合いながら、交流を広げていければなと思ってます！
Discussion