MVPだからといって雑なコードを書かない方が良いという話
新規プロダクト構築の支援をすることが多いのですが、MVP（Minimum Viable Product）だからという理由で雑なコードでプロダクト開発を進めている会社をよく見かけます。
「どうせ捨てるから」だとか「検証目的だから」といった言葉によって雑なコードが許容される風潮にありますが、それは悪い選択であるということをこのエントリで説明していきます。
MVPを用いる期間は想定よりもとても長い
MVPという言葉が一人歩きして久しいですが、あなたがMVPと呼ぶそのプロダクトはいつまで使うものなのでしょうか。
一日限りの検証で終わるものであれば雑なコードだろうが紙芝居だろうがなんでも良いのですが、そんなことはまずありません。
多くの場合、短くとも数週間〜数ヶ月、通常であれば数ヶ月〜数年程度は「自称MVP」を用いた仮説検証が行われます。
つまり、MVPと言いながらも、そのコードが存在しうる期間は自分たちの想像よりも長くなることが通常です。
コードの存在期間が長いということはメンテナンスの時間も長くなるとういことであり、雑なコードが増えれば増えるほどプロダクト開発の効率は落ち、結果としてビジネスのスピードも低下していきます。
[補足]
MVPを使った仮説検証の期間は、toBサービスの方が長くなる傾向にあります。MVPを使っていただく顧客を探すことに時間がかかるのもそうですし、顧客の業務にそのサービスを組み込んでもらうまでにも当然に時間がかかるからです。
見込み顧客獲得〜製品説明〜初期設定〜利用支援〜利用後のフィードバック獲得といった流れが通常ですが、それらには連絡時のバッファが当然にかかるため、1日で全てを終わらすことは当然にできず、見込み顧客が多数いる場合を除いては一回のサイクルを回すだけでもかなりの時間がかかります。ですから、当然にMVPを用いる期間は長くなっていきます。
多くのコードは再利用される
MVPを用いた仮説検証が終わった後にそのコードがどうなるかは大きく三つのケースに分かれます。
全てをゼロから書き直す
大掛かりなリファクタリングを行う
そのままのコードで事業を進める
プロダクト開発の初期フェーズにおいては「ゼロから書き直す」と息巻いているかも知れませんが、そうは問屋が卸しません。
プロダクトのコードが書き直されることは稀
プロダクトのコードが書き直されることが少ない理由はとても簡単で、ビジネス観点からは雑なコードを書き直すという選択肢を取る理由は無いに等しいからです。
これは当然のことですが、仮説検証が終わった状態であればビジネス的には今すぐにでも売上を作っていく方向にシフトしたいですよね。
つまりは「書き換えている時間なんて勿体無いからさっさと売上を作ろう」といった圧力が自然と増えていきます。これはしょうがないことです。
時間をかけて作り直している間に競合に全てを持っていかれる可能性もありますし、作り変えたからといって今より良くなる可能性はあまり高くないからです。
そのため、多くの場合において「ゼロから書き直す」という選択がこのタイミングで取られることはありません。MVPのはずだったコードが、いつの間にか本番で利用するコードに変わっていくわけです。
雑なコードを元に書き直すという苦行
もし幸運にもゼロから書き直す機会が得られたとしても、MVPだったはずの何かにドキュメントがあるケースは稀ですし、通常はMVPのコードを見ながら何とかしていくことになります。
つまりは「雑なコードを読む→仕様を把握する→書き直す」といったステップが通常であり、それは当然にかなりの時間を使う行為になります。
ビジネスサイドからすれば「作り直しなのに何故こんなにも時間がかかるのか」といった不満のもとになりますし、エンジニアからすれば「何故もっと綺麗に作っておかなかったのか」という後悔と現在の辛さを生み出す原因となるわけです。
[補足]
個人的には、MVPだろうがなんだろうが最初は速く作れる技術を用いてプロダクトを作るべきだと思っています。いわゆるRailsとかDjangoとか、重めのフレームワークを使ってサクサク作るようなイメージです。
それをどこかで静的型付け言語の何かに置き換えたりすることで性能面や保守性の向上などを狙う、、、というのが理想論ですが、そんなうまくいくことはほぼありません。
ゆえに、速く作れる技術を用いながらそれなりに綺麗に作るというのが最適解かなとは思っています。
エンジニアとしてはどうあるべきか
それではエンジニアとしてはどうあるべきでしょうか。
速く作ると雑に作るは異なる
MVPを作る際はコア機能以外は「作り込まない」というのが鉄則です。雑に作るわけではなく、ただ単に「作り込まない」だけです。
必要最小限のバリデーションにしたり、フレームワークやライブラリに多くの処理を任せたりすることで、そもそもとしてコードを書くことを減らしていきます。
それゆえに速く作れるのであって、雑に作るとは全く違うということをまずは心がけておくべきです。
不可逆なものが何かを理解する
上述のように、残念なことにそのコードの多くは使いまわされます。そして、多くの場合、データベース等の可逆性が低いものについてもそのまま使われてしまいます。
つまりはデータベース設計などの可逆性の低い行為を行う場合、より慎重に行うことが将来のスピードの担保につながります。
MVPを作りたいわけではなく、ビジネスをより速く作り上げるためにMVPを作っているわけで、雑なコード・雑な設計によって将来のスループットを下げていくことは本末転倒です。
作らないを選択することで速く作る
上述の内容と近いですが、ビジネスサイドが必要という機能であったとしても、作らなくて済むと考えるものについては「作らない」という選択を取れるようにしましょう。
本当に必要なものだけを作るがゆえに、速く作れるわけです。
コメントだけでもちゃんと書こう
「綺麗なコードが書かれていればコメントは不要」といった論は正しいと思いますが、そんなコードを書けないから多くの場合に困っているわけです。
速く作るために「もっと良い書き方があるはずだけど調べる時間がなかった」といったケースは沢山あるわけですが、そんな時はコメントだけでもちゃんと書いておきましょう。
「ここの処理はこんな感じで書きたかったが時間がなかったのでひとまずこの形にした」だとか、「この処理は捨ててくれてよい」だとか、何を考えてそのコードが作られたかが書かれていると、後々とても役に立ちます。
書き直す時やリファクタリングする時などは、そのコメントがあるかないかで生産性が大きく異なります。
ビジネスサイドとしてはどうあるべきか
MVPが何かを正しく理解しよう
私が関わってきたスタートアップのビジネスサイドの多くは、MVPが何なのかを理解せぬまま「MVP」という言葉を連呼していました。
それゆえに、検証目的も持たず、ただただ自分が欲するものをMVPと呼び、プロダクトチームに作らせるという愚行を繰り返していました。
MVPと検証目的はセットです。そのために必要なモノ（機能に限らず）が何かをまずはきちんと理解し、その上で作るというジャッジをしましょう。
コードを書かなくても出来る検証を自分たちの手で進めよう
検証が目的であれば、コードを書かなくともできる検証はいくつもあります。また、全ての検証をひとつのプロダクトで行う必要もありません。
これは自分たちが何を検証したいかを正しく理解できていれば自明ですが、なぜだか「これを作らないと仮説検証ができない」といった思想になるビジネスサイドをよく見てきました。
まずは自分たちが何をしたいのか、きちんと考えていきましょう。
エンジニアの話をちゃんと聞こう
MVPを用いた仮説検証ができると嬉しいですよね。その状態でイケイケな雰囲気のチームに対し、「作り直すにはMVPを作った期間の倍程度かかってしまいます」といった意見を言えるエンジニアがどれだけいると思いますか？
つまりは、多くの場合にエンジニアの「これはマジでヤバい」という気持ちは押し殺され、イケイケムードのまま何かが進んでいき、「こんなクソコード誰も触りたくねーよ」という道に進んでいくわけです。
それなりに経験のあるエンジニアであれば、ビジネスの状態をきちんと説明すれば「エンジニアリングとしてどのような選択をとるべきか」も考えられるはずです。
きちんと対話して、それらの意見をちゃんと受け止めましょう。
おわりに
過去に関わっていたサービスで、4タブで書かれたの数万行のRailsのコードに出会ったことがありました。スタートアップの初期フェーズに良いエンジニアがいないことは当然なので何も感じませんが、その状態のヤバさを経営層に理解してもらうことはなかなかできませんでした。「動いてるしいいじゃん」みたいな感じでしたが、結局その部分が足を引っ張って、そのサービスの成長は大きく遅れてしまいました。
適切なタイミングでの適切なアーキテクチャの選定はとても難しいのですが、だからこそ経営層やビジネスサイドの「イケる！」という根拠のない言葉ではなく、コードをきちんと読んだエンジニアの「マジでヤバい」をもっと尊重できると良いなとは思います。
また、そうならないためにも、MVPだろうが何だろうが最初からきちんと書くと良いと思います。
P.S. ニートすぎて遊びすぎて飽きてきました。プロダクトの初期開発の支援とかはそれなりに得意なので、何かあればお気軽にご連絡ください。
まいにちのご飯代として、よろしくお願いします。