デリバリー文化の違いに気がついたという話

ヨシミツダです。
スタートアップに転職してまもなく2年。
今さらですが、前職のエンタープライズとスタートアップのデリバリー文化の違いを感じた話をしたいと思います。

最初はあんまり意識してなかった

当初、入社して受託案件に関わっているときには、あまり違いは感じていませんでした。
お客様の要求を理解して、計画を立てて、計画通りに進むように開発を進めるといった形です。
途中からPjMとして加わったそのプロジェクトでは、仕様もほとんど決まっていました。

きちんと計画して、決めたリリース日を守って段階的にリリースを進めていきました。
もちろん、お客様にはリリースごとにフィードバックをもらいながら。

しかし残念ながら最終的には、あまり価値のあるソフトウェアになりませんでした。

何が原因だったのか？

アプローチの違いに気づく

このソフトウェアは、探索を必要とするソフトウェアでした。つまり、学習することが前提にあったのですが、PdMが決めた仕様に対してはあまり疑問を抱かず受け入れていました。

しかし、あまりよくなかったのだと思います。
ソフトウェアデリバリーは、これまでに思いつかなかった新規プロダクトや新規サービス、機能を「発見」するための手段と考えて、プロダクトの在り方に疑問があったら、PdMとボトムアップで議論すべきだと反省しました。
そもそも自分が使いやすくていいものだと思えているのかという感覚にもっとこだわって仕事をすべきでした。

顧客が真に何を求めているのか発見しないといけません。そのため、ソフトウェアデリバリーでも探索的にリリースを重ねて、そこで得る「発見と学習」を大切にする。計画に忠実であることより、価値あるソフトウェアにつながる計画を生み出さないといけない。
顧客へのインパクトが重要なのです。

前職のエンタープライズでは、何を作るかという部分にたくさんの時間をかけていました。
そもそも、経済合理性を含めて完璧に説明できないプロジェクトは開始することすらできませんでした。そして一度立てた計画を変えるのは難しく、計画に忠実であることが求められました。
仮にプロジェクトの途中で変動が発生すると、多大なエネルギーを要する報告会議が求められるのです。プロジェクトの遅延はよくありましたが、途中で方向転換しようものなら、なぜ最初に考えつかなかったのかと偉い人たちから詰められます。そのため、プロジェクトの中で、方向転換をすることはまずありませんでした。

受託のプロジェクトでは、顧客要望への対応だけで工数が手一杯になり、提案ができるケースは稀でした。その時の上司にはSIerのように仕様は必ず顧客に決めさせろと教わりました。そうしておけば、顧客は文句を言えないからです。（と理解していました。）

しかし、上記の進め方、というよりマインドではダメでした。よいプロダクトは作れない。

プロジェクトが持つ問題

これは、プロジェクトそのものが持つ問題も関係しています。

期間があまりにも短い

プロジェクトは、定義により始まりと終わりがあります。終わりがくれば解散では、プロダクト開発はうまくいかない。期間が短すぎるのです。
通常は、最初のリリースが終わってからイテレーションを重ねることが続くのです。

プロジェクトは融通がきかない

プロジェクトは融通があまりにも効きません。「ゴール」を設定して、そこに目がけて突き進むみます。途中で何かを発見したり、寄り道して新しい知見を取り入れたりする余地は多くありません。計画に含まれていないからです。

そして私が陥っていたように、納期や予算の計画に従おうとするばかりに、考えることも、気にかけることもやめさせてしまいます。

つまり、インパクト、顧客、プロダクトの価値よりも納期と予算に重きをおきすぎてしまうのです。

上記のことは、「ユニコーン企業のひみつ」という本を読んで、一般的に起きうる問題なんだなと気づくことができました。

純粋なプロダクト開発ではなく、受託からはじまるプロダクト開発では上記の側面が現れることを認知して進め方を考えなければいけません。

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

スタートアップでは、常にインパクトを実証しなければいけません。しかも、エンタープライズよりもずっと短い時間軸でそれを達成する必要があるのです。
そんなことを感じた苦いレッスンラウンドでした。