「サイボウズ メールワイズ」という製品で、 モバイルアプリを開発するにあたり、 「開発PM」として考え、実施したことを 説明した資料です。 ※開発PM・・・製品責任者 ジャーニーマップを使った顧客開発、ストーリーマッピングを 使った要件・仕様検討の事例として見てもらえればありがたい です。

1. 共感する開発のことだけ考えた。
サイボウズ株式会社
Yamada Shoji
2016/11/26

2. この資料について
• 「サイボウズ メールワイズ」という製品で、
モバイルアプリを開発するにあたり、
「開発PM」として考え、実施したことを
説明した資料です。
※開発PM・・・製品責任者
• ジャーニーマップを使った顧客開発、ストーリーマッピングを
使った要件・仕様検討の事例として見てもらえればありがたい
です。

3. やったことの概要
開発計画
ストーリーマッピング
ジャーニーマップ＋
ストーリーマッピング
共感と探求の
振り返り

4. 自己紹介
Yamada Shoji
遠い昔ですが、文系であります。
最初の会社では、プログラマでした。
1999年7月 サイボウズに「開発補佐」でジョイン。
2005年 辞めて 2007年 出戻り社員。
「メールワイズ」のプロダクトマネージャをやっています。

5. メールワイズは、サイボウズのサービスです。
ターゲットユーザー：社内でお客様対応をする人
何が出来る：メールを共有して対応できる
2003年に、オンプレミス版で
リリース。
2012年にクラウド版も発売。
バージョンは 5
開発メンバー(当時)
PM 1人
エンジニア 4人
松山2人 /東京2人
リーダーは、松山

6. 開発計画
開発計画
ストーリーマッピング
ジャーニーマップ＋
ストーリーマッピング
共感と探求の
振り返り

7. お客様からの要望リスト from サポート
サポート要望では1位
販売側からの要望もあり

8. 対応を検討する
• メールワイズは、社内で使う顧客対応ツール
→サポートのマネージャ(社外出そう)のために作る？
→「より汎用的に使える」としよう
→ターゲットは、社外でメールを見て対応する職種で
新しいターゲット、新しいシーンを考えるということに

9. 要望をくれたお客様にヒアリングしてみた
• 答えてくれたのは、社長さん、現場マネージャさん
• 「外でメールのチェックがしたい」
• 「Webブラウザの表示が見づらい」
• 「Webブラウザ表示での返信(文字入力)が苦痛」

10. モバイル対応を計画→開発へ
• ターゲット「状況を確認したい人」
• 経営者 / 個人が強い職場の各個人
• 出来ること
• 社外でメール見てスムーズに返信できる

11. 当初の仕様決定方針(いままでに倣う)
PM が、タタキとして機能毎に外部仕様作ってエンジニア に説明、
それを元にエンジニアが仕様書作成→PMサインオフ→実装
外部仕様書の例

12. 今までのやり方で良いのか？
• モバイル開発が初めてで、全体が見えない。
• PMの要件が、エンジニアにとってもやもやしそう。
→共感に時間がかかり、PMがボトルネックになる恐れ
エンジニアにこんな顔をされたくないんだ(検索してみて)

13. エンジニアからストーリーマッピングの提案
• ストーリーを、エンジニアとPM で一緒に作ろう。
• ストーリーから「やること」を決めよう。
一覧で見る
コメント
書ける 宛先を見る
通知受ける
ストーリー
今までの合意ポイント
必要性確認・・・

14. PMのロジック(思い込み) < 共感
今回は、思い込みは熱意ではない
共感とって進めることが熱意

15. ストーリー
マッピング
開発計画
ストーリーマッピング
ジャーニーマップ＋
ストーリーマッピング
共感と探求の
振り返り

16. ストーリーマッピングで 開発だ
オンラインで
やってみるが
むずかしい。
集まって付箋で
マッピング。
マップの優先度付
け。
できたー。
ストーリーの見直
しと課題確認して
から、実装開始。
エンジニアがス
トーリーマッピン
グを元に、プロト
タイプを作る。
その後、PMと整
合性を確認
1週間

17. ストーリーはこんな感じで共有して実装

18. 探求不足？
開発計画
ストーリーマッピング
ジャーニーマップ＋
ストーリーマッピング
共感と探求の
振り返り

19. 良かった点・課題(チームの振り返りから)
• 利点
• PM と エンジニア で「ゴール」が明確に握れる。
• 細かい仕様検討会議は、なし。開発集中できた。
• 課題
• 優先度は、「なんとなく」決まっていた。
(実装のしやすさ、とかあったかもしれない)

20. 社内お披露目会にて
サイトビジットとか、少数のヒアリングはしましたが、
「問題解決からみる」開発の「想像」が強いです。
このストーリーは、「本当」？
※実際は上司からの指摘

21. 現状分析・理解 → プランニング
AS-IS
(現状分析・理解)
TO-BE
(プランニング)
Inside-Out
サービス視点
①サービス現状分析 ③サービス拡張
Outside-In
顧客視点
②ユーザー行動分析 ④新サービス企画
ここ弱いわけです
出典：http://www.concentinc.jp/labs/2013/12/customer-journey-map-patterns/

22. ジャーニーマップとの出会い
ちょうど、そのころ。
樽本さんにジャーニーマップを
教えていただく社内勉強会が！

23. 早速、自分たちでやってみた
ボーディングでやってみる。問題点も共感できて、なかなかいい感じ！

24. 開発方針の改善
• メンバーの共感度・理解度を上げる(keep)
ストーリーマッピングを使った仕様策定を行う。
• ストーリーの探求をする(try)
ユーザー行動分析として、ジャーニーマップを採用。
ジャーニーマップを元にストーリーマッピング を行う。

25. ジャーニーマップ＋
ストーリーマッピング
開発計画
ストーリーマッピング
ジャーニーマップ＋
ストーリーマッピング
共感と探求の
振り返り

26. ジャーニーマップをやってみる
• 社内営業部でメールワイズを採用してくれたチームがあった。
→ターゲットになっていただく
• ジャーニーマップを営業部に作ってもらおうと考えた。
• 「素振り」してみたら、範囲広すぎだった。
→シーン決めてから、ジャーニーマップ作成の順で作業。

27. ジャーニーマップ作成対象決め
営業と重要度/頻度 でまとめて、
開発で対象を決める

28. 営業が、ジャーニーマップを作って開発に説
明する

29. ところで
他部署とワークショップするのに最適な方法が
サイボウズにはあります。(費用対効果的に)
仕事Bar
出典:【公式】わくわくFAQ(サイボウズ)
社内に内容・結果を掲示する必要がありますが、
モメンタム作りだと思えば、面倒というより
チャンス。

30. ジャーニーマップからストーリーへ
ジャーニーマップを PMが データ(エクセルです)にして
・モバイルアプリで出来る(ノートPC で出来るなら外す)
・メールワイズで出来る
箇所をチームメンバーに説明

31. 社内合宿してストーリーマッピング、そして実装
開発メンバー変わる

32. わかったこと
今後のこと
開発計画
ストーリーマッピング
ジャーニーマップ＋
ストーリーマッピング
共感と探求の
振り返り

33. この開発での振り返り
• 出来たこと
• 「本当」に近くなったと思う。(探求)
• 「やること」を、短時間で新メンバーに「横展開」ができた。(共感)
また別の視点を持って
仕様作成にあたれたとおもう。
すでに仕様が固まったところに投入され
るより実装イメージがつきやすいです。
エンジニア
じーこ
エンジニア
かりぽむ

34. 再度考えてみる
すくなくとも、想像ではなくなってきている。
後は、サンプル数か？
このストーリーは、「本当」？

35. ジャーニーマップで「本当」に近づいた？
• 約30個のジャーニーマップを社内外で「作ってもらえた」。
• 開発は、利用場面、求められていることを、その時々で認識で
きた。
• 探求するフレームワークとして「ジャーニーマップ」が理解で
きてきた(ヒアリングの仕方とか)。

36. 「本当」・・・ではないかもだけど
「感情曲線」にヒントがあった
製品で「ユーザーが気分上げ」な状態になるようにしたいと考えるようになる。
※感情曲線は曖昧なイメージがあるけれどちゃんと書いてもらうのがよい

37. 感情といえば・・・いまいち共感のないペルソナ問題
メールワイズ本体から持ってきていたペルソナは、開発メンバーにあまり参照されてなかった。

38. バリュープロポジションの「顧客プロフィール」で
考えてみることにした。
こっち側

39. 社内でワークショップするところから始めてます

40. 現在(2016年11月時点)とこれから
• クローズドβを実施
• β版ユーザーの利用ログからの行動分析/ヒアリング で探求
• フィードバックが「次回ストーリーのマップ」になっている
• リリース
• 利用ユーザー数が増えれば、さらにストーリーの探求ができる
利用ログ・要望・ヒアリングから
・マップ作成
・ペルソナ、ジャーニーマップの
メンテナンス
ストーリーマッピング
して実装
利用ユーザー
増加

41. 結局、開発Fixで、こうなるといいな。