エンジニアからみた新規事業開発5つのアンチパターン

初めまして、小原正大(@shota_kohara)です。今まで大企業やベンチャーなど毛色の違う組織で、エンジニアやプロダクト責任者など様々な立場で、新規事業の立ち上げと成長を仕事にしてきました。

自戒も込めて、身の回りで経験した新規事業のアンチパターンをまとめていきます。大企業よりの話かもしれないです。

後先考えないプロトタイピング

初期にコード負債や設計負債を抱えると、そこから育てていくフェーズで年単位の負債解消をすることになります。

成功すれば後から作り直せばいいみたいな気持ちで、外の業者にプロトタイプ開発を任せたりしてF/Sをするものの、結局その時に着いたユーザーにサービス提供をし続ける必要があったり、DBも引き継ぐ必要があったりなどなど、いざ成功した時に結局スクラップ&ビルドできず、コツコツ負債解消するみたいな苦しい状況になります。

初期投資の課題は多いが、やると決めたなら中長期の生産性も加味して行動したい。

プロダクトゴールが言語化・浸透されていない

これが無いと、短期目線で売り上げを改善するために頑張る、みたいな短略的な計画にフォーカスしがちになります。ゴールが無いとサービスの仮説進化も鈍化したり、ドメイン知識も曖昧になり開発設計も捗らない。

正しさの判断基準も曖昧で、プロダクトの責任者の中でブラックボックスに属人化されます。戦略的な議論は水掛け論になって、トップの鶴の一声で意思決定が進むことも合わさると、開発のモチベーションが低下します。特にベンチャーだと強いメッセージが無いと採用にも悪影響が。

仮決めでもいいから言語化して、後から進化させればいい。意思決定者なりが然るべきリーダーシップを発揮したい。

ログ収集をしていない

これが無いと仮説検証材料不足で厳しくなる。どうせPDCAを回す上で必須級の話なので最初から仕込んだ方が良いでしょう。

コストをかけずとも、ページビューやクリックなどのアクションログを投げてくれるライブラリやSaaS、GoogleAnalyticsなど、小さな一手間で最低限のログを取るだけで結構モニタリングできます。

リリースに集中したいから、みたいな工数削減の観点で落とさない方が良いでしょう。

過剰な納期設定やリソース管理

開発のフロー効率性、リソース効率性両方の観点で、納期や着手優先度を意思決定者が細かくコントロールすれば足かせになります(特に開発知識がない場合)。積んだ玉をベストエフォートで達成していくくらいの温度感でやるのが一番効率が良いです。

コスト見積もるなと言ってるわけではなく、例えば施策の意図とMVPをディスカッションしておけば、それ以上納期やリソース管理する必要はないかと、効率性の観点では。

そもそもプロダクトゴールや仮説を整理すれば、開発者が足元の優先度やMVPを自分で大体判断できるようになるので、そこまでやって任せるのが一番ストレスもなく生産的だと思います。

ビジネスの都合上期日が必要になるタイミングはあると思いますが、やはり開発の効率性を落とすので、先に潰すなりなるべく納期を意識しないでいいように立ち回れると良いと思っています。

成長市場じゃない領域に挑戦し続けること

これは難易度の問題で、風当たりの厳しいフィールドで戦うのはどんな上手いやり方でも難しいという話です。逆に、例えば成長市場で戦えば多少やり方が悪かったり組織が未熟でも、市場成長に比例して成果が出たりして、生存確率が高く感じました。

成功の要素は何も戦い方だけじゃなく戦うフィールドもとても重要みたいなので、工夫しても難しい時は責任を感じてもっと頑張ってみるではなく、撤退したり別のチャレンジをしてもいい、という選択肢も同時に持てればいいのかなあと思いました。

最後に

今までに体験することが多かったアンチパターンをまとめました。

ただ、どんな事業もそれぞれ独特の課題があり、またチームの中でもメンバーの立場やフェーズごとに見える課題や不満は違うものでしょう。

チームメンバーとお互いに頼りあいつつ、必要なタイミングで正しい意思決定ができる強いリーダーシップ発揮して、まだ見ぬ課題を乗り越える良いチームを作っていけたらと思います。