解②：開発を短期化する👩‍💻 - meepa試行錯誤@dotDの振り返り

前回の記事では、「どうすればもっと早く多く失敗できたか？」という問いの1つの解として「不要な実験・開発をスキップする」というの方向性について書きました。

今回はその②として「開発を短期化する」について書いてみます。

---

⚠️先に断っておきますが、僕には開発経験がほとんどありません。
「非エンジニアPOの反省」くらいのノリでおおらかな心でご覧ください。
とはいえ、社内のエンジニアとは議論して作ってるので、大外しはしてないはずですので、その点はご安心を。

---

「開発を短期化する」ってどういうこと？

最初の記事でも書きましたが、当初の理想は開発・実験のサイクルを3ヶ月程度のペースで回すことでした。しかしながら、結果的にはサイクルあたりその倍くらいの時間がかかってしまいました。

特に開発#2、#3は結果的に約半年間開発していたことになります。

これをどうにかできなかったか？
いま振り返ってみて、こうしておけばよかったかもと思うのが以下👇です。

5. 開発プランニングに時間をかける

もちろんmeepaでもスプリントプランニングはやっていました。しかしながら、実験毎（#の単位）に開発着手前にプランニングすることはやっておらず、ガッツフィーリング・目標ベースで開発期限を決め、結果的にそれをオーバーすることを繰り返しました。

今思えば、開発前にバックログを洗い出し（もちろん途中で追加・変更はあるにせよ）、バックログ単位で開発ボリュームを見積り、全体としてのストーリーポイントとチームのベロシティを照らし合わせて期間を見極めるべきでした。で、実験のサイクルが長くなりすぎるのであれば、機能を削るか品質に妥協するかという議論をすべきでした。

スライドでもハイライトしていますが、「アジャイルってそういうもんでしょ」という（誤った）思い込みに支配されていた部分もありますし、前回の「3. チームメンバーの手持ち無沙汰を恐れない」と近しい深層心理で1日でも早く開発着手してもらわなければと思ってしまっていた部分があります。

6. 内製であることよりフルコミットであることが大事

実はmeepaは開発メンバーのほとんどが副業でした。ピーク期に至っては、頭数で言えば7人のエンジニアがいたのですが、工数ベースにすると2人強という時期もありました。

最後の数ヶ月はフルコミットメンバー中心の構成になったのですが、比べてみると開発生産性の違いは一目瞭然でした。

dotDが商売繁盛でエンジニアが足りなかったというのが最大の理由ですが、ここでもまた僕の思い込みが悪さをします。

「アジャイルにプロダクトを開発するなら、エンジニアは内製が当たり前」みたいなことを本やセミナーでシャワーのように浴びていて僕はまたしてもそれが「正解」だと半ば無意識的に思い込んでいました。「dotDの台所事情的に正社員化は難しくても想いに強く共感してくれる副業メンバーを集めるべし！外注はダメ」という発想で体制作りに奔走しました。

でも、振り返ってよくよく考えてみたら、プロダクトの方向性自体がコロコロ変わりうる初期フェーズにおいて内製や想いの強さにこだわる必要はなかったと思います。パッと見高く見えてしまうかもしれませんが、外注でささっと作った方が結果的に安く、たくさん作れただろうと今なら思います。

7. 細部にこだわるのは今じゃない

次のテーマの実験の短期化にも通ずる話ですが、開発にあたって僕が細部にまでこだわってしまったのも、開発が長引いた一つの大きな要因です。

これももしかしたら無意識の思い込みがあったのかもしれません。昔読んだスティーブ・ジョブズの伝記に「神は細部に宿る」「内部の配線まで美しさにこだわった」的な記述があって、痛く感激したことを覚えています。

ただ、より大きかったのは、自分のプロダクトへの想いや仮説への妄信を適切に制御しきれなかったことだと思っています。

「このUIではこの機能の存在に気づいてもらえないのでは」「この挙動ではこの機能の良さが伝わらないのでは」みたいなことにこだわって、今思えば大勢に影響しないことに数週間かけて作り直したこともありました。

プロダクト愛自体は悪いことじゃないと思うものの、ここでは悪い方向に作用してしまいました。

---

「解②：開発を短期化する」はこれで終わりです。
次は、「解③：実験を短期化する🧪」です。

この件で議論に付き合ってくださる方がいたら、ぜひコメントでもtwitterでも何でもOKなので、お声がけください！