LIFULLで企画上流を三職種一体で進めながら、プロセス改善で開発期間を大幅に短縮した話
みなさん、はじめまして。
株式会社LIFULLでサービス企画・プロダクトマネージャーをやっています井上洸太朗と申します。
Slackのアイコンはだいたい室伏広治さんです(顔が激似)。
今私はLIFULL HOME'Sの物件検索サービスをより便利で使いやすくするための新機能を開発するチームでプロダクトマネージャーをやらせてもらっています。
今回はこのチームで採用している企画・開発プロセスと、そのプロセスが出来上がるまでの経緯や混乱などについてご紹介したいと思います。
■プロセスを作った目的と背景
三職種一体でのプロダクト開発
現在LIFULLではプロダクトマネジメントを導入する中で、プロダクト開発にデザイナーやエンジニアの専門性を最大限に活かすことにも全社的に注力しています。
また、新機能開発がミッションである私のチームでは特に、様々な視点からのアイデアを活かすため、三職種それぞれが企画フェーズから関わることが重要だと考えています。
「とにかく試す」のスピード感
新機能開発は「やってみないと分からない」という部分が多いため、机上の空論に時間を使うより、とにかくリリースしてユーザーの反応を見てみることが大切です。
そのため、施策実施のスピード感はこのチームの必須要素であり、具体的には「2週間でPDCAを回す」ということを目標に置いていました。
このような背景から、私のチームでは企画・デザイナー・エンジニアの三職種で積極的に意見を出し合いながら、高速で施策をリリースする仕組み・プロセスが必要でした。
しかし、この「企画上流を三職種一体で進めること」と「2週間に1回施策をリリースするプロセスを作ること」は、まさにトレードオフの関係なのでした…。
■混乱期: プロセスの必要性に気づくまで
最初はとにかく時間がかかった
このチームでのスタートとなる記念すべき1施策目。その企画にはとてつもなく時間がかかってしまいました。
チームメンバー全員でアイデアを出しながら、何をやるべきか・どうやったらできるかなどの議論を、決め方も決まっていない手探り状態で進めてしまったため、2週間でPDCAを回したいのにも関わらず、企画だけで1ヶ月以上の時間を費やしてしまいました。
それでもメリットはあった
この企画プロセスについてチームメンバーで振り返りを行ったところ、スピード感についての課題はやはり全員共通で持っていました。
しかし一方で、メリットとして「(企画職ではない)自分も企画アイデアを出せた」とか「企画から参加できるので施策に対する納得感が高くなった」など、ポジティブな声も多く挙がりました。
そのためそのメリットは残しつつ、スピード感という課題を解消できるプロセスを考えることにしました。
■検討期: 2週間に1回を現実化するには
1施策は2週間に収まんない
通常の施策には「企画」「デザイン・開発」「効果測定」というざっくり3つのプロセスがあると思います。
これらを2週間に収めたかった訳ですが、そもそも実は「効果測定」だけで2週間ぐらいはデータを収集します。つまり、2週間で1施策は物理的に不可能なのです。
これには最初から薄々気付いていましたが、プロセスを明確化する必要が出てきたため、この問題とも向き合うことになりました。
何らかのマジックが必要です。
プロセスを徹底的にパラレル化
まずは「2週間でPDCAを回す」の定義を、2週間に1施策を収めるのではなく、2週間で1施策リリースするという形に改めました。これにより、1施策にかかる期間は関係なく、最終的なデリバリー(リリース)が2週間サイクルであればOKになります。
次に「企画」「デザイン・開発」「効果測定」のプロセスを、それぞれ切り離してパラレルに進行できるようにプロセスを組みました。
言葉では説明しにくいのですが、このようなイメージです。
1つの企画を検討しながら、パラレルで次の企画にも着手し始めます。1企画あたりの検討期間は長短ありますが、複数同時検討するので2週間に1本は平均して企画が固まるようにします。
デザイン・開発のプロセスは、企画が固まったものから順次着手していきます。施策規模にもよりますが、2週間程度での開発期間であれば、2週間に1回のリリースが可能になります。
(エンジニアは本来1ラインしか取れない人数なのですが、巧みな連携プレイによりあたかも2ラインあるかのように動いてくれています。感謝)
そして、リリース後の効果測定の期間を経て、その結果を踏まえた次の企画を検討していきます。
職種ごとの役割も明確化
また、1施策ごとのプロセスも細かく定義しました。
各フェーズでのアウトプットや、職種ごとの関わり方もドキュメント化して明確にしました。
これにより、全員でしっかりと議論すべき部分と、必要な職種だけが関わる部分とを明確にし、無駄な工数が増えることを抑制しました。
役割分担の明確化にはRACIチャートというフレームワークを利用しました。RACIチャートとは、誰がどのような役割を担うかをR・A・C・Iの4つの分類で整理する方法です。
R=Responsible: 実行責任者（主担当）
A=Accountable: 説明責任者（OKを出す人）
C=Consulted: 協業先（何かあれば相談に乗ってくれる人）
I=Informed: 報告先（情報共有だけでOKな人）
RACIチャートについては、下記のページが詳しいです。
ちなみに、この役割分担やプロセスも三職種(リーダーだけですが)で集まって、各職種の要望を取り入れながら作りました。
■運用期: やって良かったプロセス改善
新プロセス導入後、リリースの頻度が向上
結論としては、このプロセス導入は成功でした。
プロセスに慣れるまで少し時間は必要でしたが、課題であったスピード感は大きく改善されました。イレギュラーなどがない限り、基本的には2週間に1回程度のリリース頻度を維持できています。
メリットもそのまま維持できた
「企画職じゃなくても企画アイデアが出せる」「企画から関わるので納得感が高い」というメリットも維持できています。
デザイナーもエンジニアもほぼ全員が企画アイデアを出し、その中から実際に施策化したものも多数あります。
また、企画職が出した企画の場合でも、デザイナー・エンジニアからの意見や提案を元に、より良い施策にブラッシュアップできています。
みんなで議論する文化という副次効果
「みんなで企画内容を議論する」というプロセスの副次効果として、何でもみんなで議論できる雰囲気が生まれました。
企画内容だけではなく、施策の優先度、プロセスの課題と改善方法、そしてプロダクト全体の方針まで。様々な活動についてみんなで議論をして、意見を吸収しながらチーム作りに役立てることができています。
「みんなで意見を出し合える」というチームの基礎体力として一番重要な部分が、このプロセスによって鍛えられていると感じています。
以上、私たちのチームの開発プロセスについて紹介させていただきました。
みなさんのチームの開発プロセス作りに少しでもお役に立てば幸いです。
この記事が気に入ったらサポートをしてみませんか？