見出し画像

プロダクト開発はマラソンだ

プロダクト開発はマラソンだなと、よく思います。

クラシルという料理動画サービスを運営しているdely, Inc.でプロダクトマネージャー兼開発部の責任者をしている奥原 (@okutaku0507) です。

まず、初めに「プロダクト開発はマラソンだ」という言葉は僕の言葉ではありません。「Lean UX 第2版 ―アジャイルなチームによるプロダクト開発 」という本の監訳をされた坂田一倫さんの言葉です。そのまえがきを一部引用します。

健全なプロダクト開発はマラソンである
 健全なソフトウェア開発は、マラソンのようなものです。ソフトウェアをつくったとしてもその開発を常に続けなければ意味がありません。マラソンを走るためにはまずリズムを整えるためにペースを維持する必要があります。ソフトウェア開発においても同じようなことが言えます。

リズムを整える

同書にもあるように、プロダクト開発ではリズムが大切です。

弊社が運営しているクラシルは、近年急激な成長をしているプロダクトです。2016年のリリースから現在では累計1,400万ダウンロードを迎えて、組織もプロダクトも成長し続けています。

僕はクラシルのリリース当初から関わっていて、2017年の大型調達からの全国区のTVCM放送など急激な変化をしていた時には、中にいた者としても、これは短期決戦で、Winner Takes Allだと思っていました。しかしながら、現在はこの戦いは長期決戦だと思っています。

そのため、プロダクト開発においては長期でユーザーに価値を届けるために、開発組織や開発プロセスの整備はもちろんのこと、僕ら各々のモチベーションも持続させていく必要があります。その文脈において、リズムが大事だと思いました。

この規模にきたクラシルにおいては、ブランド醸成、さらなるユーザーグロース、マネタイズなどプロダクトにとって大事なことが多く、関わる部署も多いため、プロダクト開発は複雑性を極めます。それぞれの部署において、プライオリティが高いことがありますが、開発リソースは一つで短期的な拡大もありません。全ての部署の優先度が高いことだけを行っていては、ユーザー体験の向上などプロダクトを利用してもらう本質的な部分には着手できなくなってしまいます。また、各部署からしたら優先度が高いため、期限を問うと「なるはやで!」と返ってくるのみです。これらをどんどん消化していきリリースするのみのプロダクト開発では、リリースのスケジュールがどうしても過密になりがちで、ひょんなことから不用意なバグを生んでしまったり、その対処に追われてしまうと僕らのメンタル的にも厳しいものがあります。

その文脈において、開発の持続可能性を担保しつつ、ユーザー、ビジネス、僕らの三方良しのプロダクトを世に届けていくために、弊社ではプロダクトマネージャー (PM) を立て、各部署の情報非対称性をPMに集約させて、事業全体を加味した統一的な意思決定ができるようにするのと、スクラムを導入して、アジャイルな開発を行って、自分たちのタスクを可視化して、無理のない開発スケジュールを立てるようにしています。急な差し込みタスクもPMがしっかりと向き合い、それぞれの優先度と部署間の期待値を調節して、全体として幸せになるようにしてしつつ、タスクの可視化によって、広告商品の開発など重要な機能がリリースされるまでの説明責任を果たすことに注力しています。それにより、各OSリリースのスケジュールに秩序がもたらされ、無理のない持続可能な開発を行うことができています。

寄り添う

プロダクト開発はゴールの見えない、長い長いマラソンです。

※ ちなみに筆者はフルマラソンなど長いマラソンをしたことがないため、原体験ではお伝えできないのをご了承ください。

長い時間走り続けていく中で、苦しくなる時も、ランナーズハイのように無限に走り続けられるような感覚になる時もあります。勿論ですが、プロダクトには良い時も悪い時もあります。

プロダクトの全ての側面に寄り添い、走ることを諦めずに、寄り添うことがとても大切です。確かに、プロダクトが伸びてない時には、隣の芝生は青く見えてくるものです。そこで見捨てることなく、プロダクトの未来を創造し、可能性を信じて、走り続けることが大事だと思っています。走り続ければ、きっとさらに大きなことを実現していけるんだと信じています。

何を創るか

プロダクト開発はマラソンですが、ただ単に走り続けていれば良いのかと言えば、全くそうではありません。全く詳しくないですが、マラソンにおいても戦略が大事だと思います。

組織やプロダクトのフェーズや競合関係などによって、今何を創るかにフォーカスしなければ、走ることもままならなくなってしまいます。その中で弊社で導入しているのは、リーンでアジャイルな仮説検証です。以下に、僕がAWS Dev Day 2018で登壇した時の資料を貼ります。

プロダクト開発における技術がどんどん簡略化し、ある程度なら誰にでも扱い易くなってきた昨今において、プロダクトをローンチするハードルは下がっています。その世界において、プロダクトの機能的な価値はすぐさまコピーされしまいます。また、日本においてはスタートアップの資金繰りもし易くなっている印象を受けます。そして、どこの会社もエンジニアやデザイナーの採用に苦戦し、プロダクト開発におけるリソースは枯渇していると思います。機能的価値がコモディティ化しつつある中で、プロダクトに差異をつけ、ユーザー数を拡大していくためには、ユーザーに価値あるプロダクトを最速で届け続けることが重要です。そのためには、プロダクト開発に潜む最大のムダである、使われない機能が大きな開発リソースを使ってリリースされることを防ぐことが肝です。そのための弊社の解決方法が上記のリーンでアジャイルな仮説検証フェーズの導入でした。

この開発プロセスの導入により、プロダクト開発に潜むムダがなくなり、ユーザーの価値になる機能が多くリリースされるようになったと実感しています。その詳細について興味がある方は是非、お声がけください。

成長は全てを癒す

スタートアップでは「成長は全てを癒す」という言葉を頻繁に耳にします。

長い長いマラソンにおいて、今自分たちがどこにいてどこに向かっているのかわからなくなる時があります。その中で、今自分たちは進んでいるということがわかる感覚、つまり成長していることを実感できることは、とても大切です。

しかしながら、当たり前ですが、プロダクトの成長はそう簡単には上手く行きません。その中で諦めずに走り続けられることが大事になってきます。そのためには、走るコース (戦う市場) の選択も重要で、走る戦略、一緒に走る仲間が全て揃う必要があると思っています。

長いマラソンの先にあるものが何なのか、走り続けている僕らにはわかりません。終わりがあるのかすらわかりません。しかし、その過程を楽しみながら、走り続けることにこそ意義があると思っています。

プロダクト開発はマラソンだ。


この記事が気に入ったらサポートをしてみませんか?