0→1フェーズを高速に立ち上げるための要点

kikitoriでエンジニアマネージャーをしている坂村です。青果流通の新しい事業を立ち上げるなかで、これまでの0→1フェーズでの経験を活かしつつ、日々チームで挑戦しています。

本記事では、その経験をもとに 高速に0→1フェーズを立ち上げるための要点 を整理します。技術的な工夫はもちろん、チームづくりや文化面の工夫についても触れますので、kikitoriの開発文化を知っていただくきっかけになれば嬉しいです。

要件定義

新規事業の立ち上げでは、ビジネスの仮説は発案者が持っていることが多いため、仮説の立て方そのものには触れません。ただし、その仮説や信念、あるいはひらめきを 発案者と同じレベルで自分ごと化すること がとても重要だと考えています。

そのうえで、我々エンジニアは事業を技術的な視点から解像度を高めていきます。

今後どんな付加価値を提供できるか
採用する技術が運用コストを高めてしまわないか
技術自体を参入障壁にした場合、その陳腐化リスクをどう見るか

たとえばAIがコモディティ化しつつある近未来においては、「AIそのもの」だけで優位性を担保するのは難しくなっていくでしょう。

次に、サービスが提供する価値をどうやってエンドユーザーに届けるのかを、ユースケースとして分解します。この過程で大枠の機能要件が見え、データの流れや外部連携も整理されます。ユースケース図や全体のワイヤーフレームを作りながら、事業とサービスの解像度を高めていきます。

開発

個人的な感覚ですが、要件が6割程度固まった段階からは同時並行で開発を進め 実際に動くものを見せながら共通認識を形成する 方が早いです。

もちろん作り直しは発生しますが、そこは「プロトタイプだから仕方ない」と割り切ります。設計と開発を明確に分け、レビューを通して承認を得る…といったフローは0→1フェーズにはスピード感が合いません。

ただし、手戻りを最小限に抑える工夫は必要です。

変更が入りそうなテーブルは正規化しておくことで、柔軟性を担保しつつ後の仕様変更に耐えやすくする
バックエンドはインターフェースを先に定義し、実装はDIで差し替えられるようにする

こうした仕込みをしながら、仕様変更や方向転換があっても極力追加工数を増やさない工夫を施します。

チーム

0→1フェーズは 少数精鋭 が圧倒的に進めやすいです。

採用観点でいえば、技術を突き詰めるタイプよりも事業に共感できるタイプの方が適しています。要件定義と開発を並行して進めるため、常にチームで共通理解を得ながら走り続ける必要があり、大規模なチームだとマネジメントコストが高すぎるのです。また、エンジニア自身も自分はサービス全体のどこの何を作っているのかという意識づけを常にしておくこと、マネージメント側からするとそういうインプットをメンバーにし続けることもポイントになります。でないと、せっかく担当機能を作ったのに結合してみるとちょっと思ったのと違った、みたいな状況になりかねません。ただただ仕様や設計をまとめてエンジニアに渡すのでは0→1フェーズではうまくいきません。

さらに、0→1フェーズでは要件や仕様が変わることは避けられません。確度の低いものは後回しにする工夫をしても、最後はどうしても変更が発生します。だからこそ 変化に強いチーム構成 を意識することが重要です。

また、特に我々の青果流通ドメインは学習コストがとても高いため、単に技術に強いだけでは立ち上げられません。生産者さん、JA関係者や市場事業者や運送事業者との会話から要件を拾うことも多く、事業に強く共感できるメンバー でないとキャッチアップが難しいのです。