2017年、サイボウズで、開発PMむけに、「社内 POStudy」 をやってみました。
目的は、「要件を作り、説明するため」の共通のやり方をつくるための
方法として「プロダクトマネージャの手法を学ぶ」としました。
「要件の思考、伝達」にフレームを使いたいPMさんのとっかかりとなると幸いです。
サイボウズのワークショップをワークショップするの図
#社内 POStudy の実施
pmjp でお世話になったり、以前KPIツリーの社内講義をしていただいた POStudy 主宰者である関満徳さんに社内勉強会のお願いをしました。
約半年間で11回、**「要件からプロダクトバックログにすることろを改善するための手法を学ぶ」**として、以下のテーマで実施していただきました。各テーマに、参考となるリンクを追記しています。
ペインストーミング
自社サービスである kintone, Garoon を題材にして、ソリューションを考えるのではなく、Person / Activities / Insights / Needs から改善する問題点を探すワークショップを行いました。また、painを説明するツールとして「サービスブループリント」を使いました。
http://www.leapfrogging.com/2013/06/20/painstorming-for-innovation/
事前期待のマネジメント
前回の勉強会より、サービスの業務プロセスに着目して改善点を見つけようとすると、けっこう案が出やすいようだったので、サービスに対する顧客の事前期待(4つのタイプがある)と、提供する6つのサービス品質をテーマにしました。サイボウズのワークショップを開催している部署を招待して、「サイボウズのワークショップの事前期待、提供サービス品質を考える」ワークショップを行いました。
https://www.slideshare.net/fullvirtue/it-75913522
6up sketches / リーンダイアグラム
課題、対象が決まった状態で、どう解決するかについて、チーム内での合意形成の手法を学ぶことをテーマにして、製品・サービスにおいて、最も価値がある部分について、使用前、使用後を 6コマ漫画で書いてみる(6up stetches)、あるいは、問題から解決に至るまでのターゲット、解決方法にリーンダイアグラムを使うワークショップを行いました。リーンダイアグラムで表現するためのワークは3度行うほど難しかったです。
http://leandiagram.com/
Discover to Deliver
企画と開発で プロダクトバックログの合意形成を素早く行う方法として、プロダクトに対するニーズとその実現スケジュールを3つの時間軸と7つの側面から分析・表現することで合意を得やすくするための枠組み(Discover to Deliver)を学びました。プロダクトバックログに記載する内容の抽出を、この枠組みに従ってオプションボードで表現するワークショップを行いました。
http://www.ogis-ri.co.jp/otc/hiroba/technical/IntroDtoD/
Lean UX
最後に、企画から開発まで落とし込む作業を一気にやれるように「Lean UX」の手法を使いながら解決するべき問題の説明、またその内容からコンテキストを抽出するワークショップを行いました。Lean UX の概要を確認して、Lean Canvas, Proto Persona, 6up Sketches で書いて、そこからコンテクストを抽出、その内容を共有、ディスカッションするワークショップを行いました。
同じようなワークショップを理解無く半年前に行って、ほぼ全滅・・・に比べると、かなり説明できるようになっていました。
http://uxxinspiration.com/2014/03/lean-ux/
https://uxdaystokyo.com/articles/context05/
#やってみて思ったこと
自社製品で考えるのが良い
ワークショップの対象となる題材には毎回悩みました。他のPMの製品をとやかく言うのは・・・という気持ちもありましたが、自分担当の製品についてワークショップをすることで、他の製品に興味を持つ、視点を広められるということが出ました。案ずるより産むが易し・・・というよりも、どんどんするべきでした。
視点における気づき
サイボウズは、ソフトウェアベンダーだったこともあり、「モノありき」での思考になりがちであることに気づいたという意見が多くありました。この勉強会では、利用者から考えることで新たな気づきがあり、今後の作業で活かせそうです。また、レビューするのに「サービスブループリントでは」とか「リーンダイアグラムでは」という視点で見てみるようにしたい、という意見もありました。
販売側のメンバーとよりよい議論が出来るようになるかも
販売のメンバーとの話が、顧客の状態を聞くだけではなくて、誰が何を問題としていて、どのような価値を提供することで、というのを話せるフレームを学べたと思います。また、振り返りでも「導入事例を多く見てみる」とか「お客様と話す機会を増やすようにする」といった意見も出ていました。
意外と絵は描けるもの
6up sketches をやってみて思ったことです。ちゃんと価値が分かって入れば、どんな絵でも伝えられるもの。「味のある絵」なら、それはそれで盛り上がりますしね。この勉強会後、私はデザイナーと 6up sketches をお互いに書いて、同じ価値提供を考えているかを確認しました。
他部署を巻き込む
「事前期待のマネジメント」では、実際にセミナーを運営しているメンバーとワークショップしました。快く参加してくれたのもありがたかったですし、参加してくれたメンバーから「持ち帰って改善を考える」「学んだフレームを使って考えるようにする」というフィードバックもらえました。他部署がどのような考えでサービス提供しているかをワークショップを通じて知ることが出来て、開発PMとしても視野が広がったし、サイボウズ全体としてもサービス品質を改善するきっかけを作ることが出来ました。
#最後に
事前期待の会では、他部署にも参加してもらい、サービスは開発だけではなく、リリース後も含めて考えることもより意識しやすくなったと思います。同時に、各PM毎に、異なる製品、ライフサイクルのフェーズ、チーム内での役割の違いなどがあり、「共通事項」として認識していくことの難しさも分かりました。ただ、何かを起案することについて、どのような考え方で、どのように説明するかについて考える、そのとっかかりにはなったのではないかと思います。
ひとまず、「やり方」を学びました。ここからは、サイボウズとして、現場で共通言語化していくフェーズとなります。学んだフレームを使いながら仕事が出来るようになってきているので、どのように定着させていくかを考えていきたいです。
あらためまして、関さん、ありがとうございました！