読者です 読者をやめる 読者になる 読者になる

Yamotty Blog

プロダクトマネージャーの雑記

プロダクトをリニューアルする際のチェックリスト

はじめに

2015年の末より定期的にsprintを回し、自社プロダクトのリニューアルを行っていて(継続中)、 1〜2週間という期間でリリースをし続けながらプロダクトのUXを見直し、再定義することを試みている。

Product Managerとしてこのsprintをできるだけ早く、正確に回し続けるために個人的に重要だと思ったポイントをチェックリストとしてまとめてみた。 リニューアル中は開発チームとともにかなりのハードワークとなるため、その中でも判断を間違わず進めるための指針となれば嬉しい。

TL;DR

チェックポイントとして以下の4つを挙げる。

  • イシューからはじめよ
  • 言語化できないデザインは落とす
  • リリースを分ける
  • フィードバックが集まる基盤を創る

イシューから始めよ

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ―知的生産の「シンプルな本質」

ひとつ目はあの名著のタイトルから拝借。

大前提として、リニューアルするということは運用中のプロダクトがすでに存在している。 運用中のプロダクトがあると、あらゆるステークスホルダーからの「改善の声」にプロダクトが日常的にされされ、膨大な改善リストができあがってくるが、リニューアルはこの改善リストを一掃するために行うのではない、ということを意識しよう。

世の中で「問題かもしれない」と言われていることの総数を100とすれば、今、この局面で本当に白黒をはっきりさせるべき問題はせいぜい2つか3つくらいだ。(中略)問題はまず「解く」ものと考えがちだが、まずすべきは本当に解くべき問題、すなわちイシューを「見極める」ことだ。ただ、これは人間の本能に反したアプローチでもある。

  • リニューアルだと息巻いてプロジェクトを走らせた所で、そのプロジェクトのゴールが明確で無いとチームが息切れをし、いつまでもリニューアルが終わらない、ということが起きる。
  • ブレイクスルーすべきもっとも重要なイシューをProduct Managerが定義しよう。
  • またあるあるだと思うのだが、リニューアル自体が目的になってはいけない

言語化できないデザインは落とす

プロダクトのリニューアル時というのは合わせてデザインUIも変えるチャンス。 多くの若いプロダクトにとっては、ローンチご追加された機能によりUIの統一性が失われたり、結果としてスムーズなUXを提供できなかったりする場合があるため、リニューアルのタイミングでUIの整合性を取り戻すというのは理にかなっていると思う。

しかし、この場合に機能面だけでなくデザインのフルリニューアルを行うことは危険も多い。 参考になるのが下記のneilbookというサービスにおけるデザインリニューアルのスライド。

www.slideshare.net

  • チグハグだったUIを修正するためにUIフルリニューアルを検討したが、
  • 最終的に意義を言語化できる仕様以外は行わない、という意思決定

デザイナーは自身のポートフォリオを拡充することで、まわりに説明しやすい成果物となるため、フルリニューアルをやりたくなるインセンティブがある。それはよくわかるが、ビジネス要件を満たすための最も短いsprintを回せるように、PMがバランスを取っていく必要がある。

ちなみに自社の場合はデザイナーがおらず、僕自身がデザインも行うためこの問題は起きないのだが、 逆に機能を主張する魅力的なデザインを描けないというジレンマを抱えている。

リリースを分ける

リニューアルというと、現在運用中のプロダクトが持つ機能を100%反映した状態で、次のバージョンをリリースすること、という認識を持ちやすいが、これが危険。

  • いつまでもリリースされないことによるモチベーションの低下
  • フィードバックを得る機会が遅れる

リニューアルという大型のプロジェクトこそ、マイルストンをこまめに切って、github flow的にリリースブランチを刻んでいく方が確度が高いプロジェクトにできるだろう。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

フィードバックが集まる基盤を創る

FacebookのProduct DesignerであるTanner Christensen氏のMedium投稿より

medium.com

It’s immensely helpful to reiterate the problem being solved before showing any work in a critique. Vocalizing the problem and context for the work—and why it’s a problem or idea worth tackling in the first place—helps establish a foundation from which productive feedback can be given(批評を受ける際に、仕事や成果そのものについて議論を始める前にすべきことがある。イシューについて、繰り返し言及することだ。これが非常に役に立つ。「なぜ問題なのか」「なぜ解決する価値があるのか」という課題やコンテキストを言葉にしておくことで、生産的なフィードバックを集めることができる).

リニューアルには痛みが伴い、これまでのユーザーが離れることもある。またユーザーの多くは批判はするが批評はしない。 多くの場合、ユーザーが声に出すのは「このプロダクトは良いor悪い」。それのみだ。

  • 適切なフィードバックはだれから、どうやって得るべきなのか?予め設計しよう。
  • フィードバックを相手から得るには、このリニューアルで何を解決するのか、その思想の背景を含めて共有しよう。

僕がプロダクトのリニューアルを開始する際には、社内の情報共有ツール(Qiita::Teamを使っている)に今の事業・プロダクトが抱える問題や、その優先度、思想の背景などをポエムとしてまとめるところから始めた。

機能やデザインが変わっていくことで、確実にビジネスサイドのアクトも進化できることは最近の実感としてあるので、フィードバックを得るためにとどまらず、会社の命とも言えるプロダクトの状況は上手くシェアしていくべきなんだろうなと思う。

まとめ

以上、4つのチェックリストを挙げてみた。

  • イシューからはじめよ
  • 言語化できないデザインは落とす
  • リリースを分ける
  • フィードバックが集まる基盤を創る

リニューアルにかぎらず、大型の機能追加など、比較的長期にわたって実装を進める際にはProduct Managerとしてこれらのチェックリストが役に立つのではないかと思う。

見返すととても当たり前なことが並んでいるが、実践するかどうかが全てなので、僕自身も常に頭の片隅に置いておこうと思う。