はじめに
プロダクト開発の現場では、開発の効率化やステークホルダーとの連携が常に課題となっています。特に昨今、プロダクト開発の複雑化や市場環境の急速な変化により、これらの課題への対応がより重要になってきています。
そこで今回、異なる事業特性を持つ4社のプロダクトリーダーをお招きし、各社の取り組みについて話を伺いました。デリバリーの進め方から、市場への展開方法まで、現場ですぐに活かせる具体的な知見が共有されました。
登壇者紹介
当日はパネルディスカッション形式で、次の4名の方にご登壇いただき、モデレーターはファインディのプロダクトマネジメント室 室長 稲葉が務めました。
編注
記事中の各位の所属および役職は、イベント開催時点（2024年10月25日）のものです。
登壇者：
- 株式会社LayerX バクラク事業部 VPoP 飯沼広基氏（@numashi_Biz）
- セーフィー株式会社 執行役員 企画本部副本部長 兼 VPoP 植松裕美氏（@yum_it）
- PIVOT株式会社 プロダクトマネージャー 蜂須賀大貴氏（@PassionateHachi）
- 株式会社タイミー 執行役員 CTO 山口徹氏（@zigorou）
モデレーター
- ファインディ株式会社 プロダクトマネジメント室 室長 稲葉将一（@bachio178）
テーマ1：デリバリー効率を高めるために、リリースの締切を定めるか？理想と現実について
ファインディ 稲葉：最初のテーマは、「デリバリー効率（プロダクトの生産品質を確保しつつ、ユーザーに製品を届け、メンテナンスする作業の効率性を指します）を高めるために、リリースの締切を定めるか？ 理想と現実について」です。ビジネス映像メディアを手掛けていらっしゃるPIVOTの蜂須賀さんからお伺いできればと思います。お願いいたします。
PIVOT 蜂須賀：僕が最初に関わったのがアジャイル系・スクラム系のコミュニティでした。その中で、ソニックガーデン倉貫さんの「納品のない受託開発」から強い影響を受けています。自分たちでデリバリーの頻度を決めて、言い方を選ばずに言うとデリバリーの手綱を握るというやり方を取ってきました。
ただ、人間なので、シンプルにスケジュールのない状態とか、自分たちでスケジュール提示できる状態って結構実態は怠けると思っていて、他人が怠けているのは別にいいんですけど、自分が怠けるなと思って。それで今は、あえて締切を作るやり方に戻しました。
一周二周、回って戻ってきたという感覚があるので、皆さんがどうなのかをお聞きしたいです。
稲葉：最近はウォーターフォール開発とスクラムによるイテレーション開発（一連の工程を短期間で繰り返す開発サイクル。 短いスパンで開発手法を見直す「アジャイル開発」における概念）の両方のケースがありますが、LayerXの飯沼さんはどのように進めていらっしゃいますか？
LayerX 飯沼：私は最初ハードウェアエンジニアでしたが、ハードウェアはかなりがっつりウォーターフォールなんですよ。例えば、私が作っていたプロトタイプが1個遅れると1年半くらい開発が遅れるみたいな感じなので。
今のLayerXでは、締切は定めているのですが、撤回できるようにプロダクトマネジメント組織がハンドルを持っているというような形になっています。
ハチ（蜂須賀）さんがおっしゃっていた「怠ける」も分かるんですけど、決めすぎるといろいろ価値として欠損したりとか届けるべきものが届けられない状態であったりとか、リファクタリング（ソフトウェア開発において、プログラムの動作を変えずにソースコードを改善する作業）を後々やらないといけなかったり、価値だけでなくむしろ心も欠損してしまうところがあります。
なので、ハンドルは握るので撤回できるようにはするんですけど、締め切りはいったんつけるというスタイルでやっているのが一番フィットするので、そのようにやっています。
セーフィー 植松：結構プロダクトによって違っていて、定常的に改善していくものはマンスリーでリリース日を決めてスケジュールを合わせていく。新規のプロダクトはいったんスケジュールを決めて、そこに合わせてやっていく。toBのプロダクトなので、最初に重要なお客さんがついてくれて、そことの調整をしながらそこに合わせにいくというのが一番近いです。
自分の失敗談で行くと、自分は締切を守りたい派なので、結構締切をガチガチにしすぎてプロダクトマーケットフィットしていないものを出してしまったという失敗もありました。なのでそれをやり過ぎるといけないことは理解していますが、ハチさんがおっしゃっていたように締切を決めないと皆がズルズルとなってしまうので、なるべくそこのバランスを取りながらリリースしていこうとしています。
タイミー 山口：自分は締切というものを定めていない派ですね。うちのプロダクトマネジメントの考え方の参考にしている書籍だと「ビルドトラップ本」（書籍『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』）が一つ挙げられるのですが、アウトプットの延長じゃいけない、リリースすることが目的になってはいけない、といったところだったりとか、一定「課題を解くべき」という前提に立つのであれば、不確実性に向き合うために顧客にヒアリングをしながら、課題を当てながら、やっていくというところを大事にしているので基本的には締切はないです。
ただ、一方で、うちのプロダクトロードマップを「プロダクトイニシアチブ」（企業のビジョンや戦略的意図に基づいて、製品の開発や目標設定などに方向付けること）という形で表現しているのですが、イニシアチブ1個1個のアイテムにどれくらいのタイムリーさを出したいか、というのは指標がついていて、クォーターレベルでの目標は必ずついているという形です。なので基本的にはクォーターレベルで収まる範囲内でできる限り早く。でもきちんとアウトカムがでるように、という考えでやっていますね。
