新規事業とソフトウェアエンジニアリングの葛藤
新規事業とソフトウェアエンジニアリングってそんなに相性良くない気がするけどどうするかというメモ
「最小限でいいからつくりたい」
「最小限ってなんやねん」
はじめに
ソフトウェアエンジニアリングに係るプラクティスの多くは、変化を伴う長期において力を発揮するものだ。
一方、新規事業あるいはスタートアップの初期においては、その長期が存在するかどうか自体が不明だ。また、スタートアップは生き残るためにピボットするときがある。そのときに、ソフトウェアエンジニアリング自体が必要かどうかも不明だ。もしかしたら何も作らないほうがいいかもしれない。その時になってみないとわからない。
たしかにプラクティスはスタートアップの初期においても多くの場面で役に立つ。
ただし、それが必須かどうかは別だ。
スタートアップの初期を脱したと思われる状態、理想的にproduct market fitされた状態であればプラクティスは間違いなく役に立つし、むしろいかにしてプラクティスを徹底するかが重要になる。
その前の状態はどうだろう。区切りとして、minimum viable productの時点でソフトウェアエンジニアリングのプラクティスはどの程度実行されるべきだろうか。
Minimum Viable Product
定義
ChatGPTより
「Minimum Viable Product（MVP）」は、製品やサービスの開発において、最小限の機能だけを持った初期版を作る手法です。これにより、市場やユーザーからのフィードバックを早期に得ることができ、製品の改善や次のステップの判断に役立てます。MVPの目的は、できるだけ早く、最小のコストで市場に投入し、実際のユーザーの反応を基に製品を進化させることです。
教科書的には
フェーズを3段階に分ける
customer-problem fit：顧客の課題を検証する段階である。この時点ではものをつくるべきではない。というより、ものは存在すべきではない。
problem-solution fit：解決方法が課題に対して適合することの検証段階である。なにかしらのものが必要だろう。解決方法がプロダクトならばプロトタイプが必要である。コードは書いて良い。ただし、エンジニアリングすべきではない。
product market fit：プロダクトが市場で価値あることを証明する段階である。この段階のプロダクトがminimum viable productである。
実行可能あるいは検証可能という言葉だけだとふわっとしすぎなので、実際にはもう少し詳細な定義をつくる。例えば
XXX円で売った場合に、YYY人が興味を持ち、買ってくれる人がZZZ%いる
検証時のKPIをこのような形で定めるなら、minimum sellable productと呼んだほうがいいかもしれない。
現実
上で段階を3つに分けた。出典によって呼び方は異なるがだいたい似たようなフェーズ分けになる。教科書的にはこれで正しいが、現実にこのステップを踏むことは多くないだろう。これで上手く行くならスタートアップはピボットしない。普通は
最初からそれなりに市場を考慮する
最初からそれなりの「もの」が用意できるならそれを使う
途中でなにかが破綻したら別のことをする必要がある
初期の仮説にトラップされるべきではないが、本当に「ゼロから新規」はない。最初の一人はなにかしらの知識や経験、アセットを持っているし、それを大いに利用する。
PMFの一つの目安はunit economicsが成立することだが、これを省略することがある。競合が存在せず時代が変化しないならばゆっくり進めれば良い。しかし、現実はそうとも限らない。
市場を制圧することの優先度が高いという状況は珍しくない。他者が「自身以外の誰かの検証によって」ステップを飛ばすこともある。
スタートアップにはあまり時間がない。
Minimum Viable-Quality
今を考える
QCDを考えよう。
minimum viable productにおけるQCDは
cost → 最小限にする
delivery → 最速にする
quality → 最小限にする
それはそう。もう少し具体的には
cost → バーンアウトしないようにする
delivery → バーンアウトしないようにする
quality → 検証すべき事項が検証される限りにおいて最小限にする
検証すべき事項が検証されないのであれば、再び検証することになる。すなわち、costとdeliveryが増加する。
求められる品質はそのプロダクトとフェーズに依存する。minimum viable productは不確実性を下げ、十分に再現可能な状態をつくるためのステップである。検証すべき事項が
XXX円で売った場合に、YYY人が興味を持ち、買ってくれる人がZZZ%いる
ならば、これを満たす最小限の品質が求められる品質になるし、これ以外はover-productionである。
こういう形で、短期的に求められる品質を定義することはあまり難しくない。プロダクトによるが、各々の状況に対して適切な基準が見つけられるだろう。
未来を考える
それより面倒なのは
品質が低いこと自体がcostとdeliveryを悪化させる
次のdelivery、次の次のdelivery、、が存在する
という状況だ。1点目はQCDのトレードオフ、2点目はエンジニアリングのトレードオフである、時間軸の考慮とその積み上げという言い方をしても良い。
適当なイテレーションの期間、例えば1ヶ月で区切ったときに、何らかの検証あるいは目標の達成を目指すとする。経験的には
今月と来月で検証や目標が大きく異なるということはあまりない
物事が進むにつれ「スケールアップした」検証や目標になることは多い
これはある程度先読みした最適化が必要なことを示唆する。それはエンジニアリングに他ならないが、やりすぎるとover-engineeringである。
どうしようか。具体的に考えるしかないが、目安としては
不確実性が高すぎる場合は、未来のことは考えないほうが良い
イテレーションの2つ先程度を読むと良い
原則論しか言っていないがこの程度ではないか。それなりに不確実性が高く、今月と来月で似たようなことをやるなら再来月は考慮するが、半年先は考慮しない。なにかをつくるのに6ヶ月かかるなら18ヶ月先は考慮するが、36ヶ月後は考慮しない。
過去から始まる
また、もっと面倒なのは
短期において、エンジニアリングが事業に一切寄与しない
何らかの理由で品質を改善することが困難である
1つ目は文字通りの意味で、こういう状況はある。すべての行動がover-engineeringになる。2つ目の例は「すでに作られた大きなプロダクトがある」場合で、こういうこともある、むしろこういうことのほうが多いと思う。
創業者が最初から少しずつプロダクトを改善しつつ現在に至る、という物語は実はそう多くないと思う。プロダクトを作るということ自体が制約になるからだ。ものを作るよりも買ったほうが早いかもしれない。すでにあるものを売りにいったほうがいいかもしれない。
それよりも、プロダクトを作れない創業者が事業を進めて後にプロダクトを作れるメンバーがジョインする・・ことのほうが現実的なシナリオのように思える。エンジニアリングで最も悩むのはこういうエンジニアリングとそれ以外の境界だ。一般的な解答はない。がんばろう。
おわりに
もう少し具体的にまとまったらまた書く
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？