開発チームと”握る”ためにMVPキャンバスを使っている話

この投稿は[ギルドワークスAdventCalendar2017](https://adventar.org/calendars/2564)の20日目の記事です。
私が開発に関わっている「RODEM」の開発チームで共有ツールとして使っている「MVPキャンバス」について書こうと思います。

##忙しい方向け[今北産業](http://dic.nicovideo.jp/a/%E4%BB%8A%E5%8C%97%E7%94%A3%E6%A5%AD) 
- RODEMは開発単位を「MVP」として、開発と検証のサイクルを可能な限り早く回そうとしている
- MVPを作るにあたり、何を検証するために何を作ってどうなることを目指すのかを開発チームと握りたい
- 開発チームとの”握り”のために「MVPキャンバス」を使っている

##背景：開発チームの状況
- RODEMとは
    - ビジネスマンを「めんどくさい」から解放するためのサービス
    - カレンダーに訪問予定を入れるだけで、システムが移動予定と精算データを作ってくれる

<img width="500" alt="RODEM.png" src="https://rodem.valwebservices.com/assets/web/portal/architecture@2x-4ebc6295989680afb0264addbf775b7f3c22e8f003040467cda5d269dfdef9c1.png">

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">ビジネス・サポートサービス「RODEM」紹介動画: <a href="https://t.co/r4vbgol4as">https://t.co/r4vbgol4as</a> via <a href="https://twitter.com/YouTube?ref_src=twsrc%5Etfw">@YouTube</a></p>&mdash; 魔法少女★駅すぱあと (@ekispert_502_PR) <a href="https://twitter.com/ekispert_502_PR/status/935057944043053056?ref_src=twsrc%5Etfw">2017年11月27日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

- 開発はギルドワークスさんに開発支援をいただいています
    - 詳細はギルドワークスさんの実績紹介から
        - [ビジネスパーソンのめんどくさいを解決する！「RODEM」の制作ストーリー「企画編」](https://guildworks.jp/works/item.html?id=19)
        - [ビジネスパーソンのめんどくさいを解決する！「RODEM」の制作ストーリー「開発編」](https://guildworks.jp/works/item.html?id=20)
<br><br>
- RODEMの開発チーム
    - PM、POと開発チーム(エンジニア)で構成
    - 私はPOとしての立ち位置で開発項目の検討や優先順位の調整などを行っている
<br><br>
- 開発の単位は「MVP(Minimum Viable Product)」にまとめている
    - MVPとはBuild-Measure-Learnのフィードバックループ１周を回せる『必要最低限の労力』＋『最低限の実装時間』バージョンの製品」のこと
    - 小さく作っては検証、を繰り返すための開発

##開発チームと”握りたい”ことは？
- MVPの開発と検証のサイクルを可能な限り早く回すために、下記を共有し、目的、開発要件、得たい結果を”握って”おきたい
    - 何故やるのか
    - 何のためにやるのか
    - これをやることでどうなる事を目指すのか
    - (事後に)結果としてユーザーにどういう行動変容を起こせたか

##開発チームとの共有ツールとして、MVPキャンバスを使っている
- 本来のスクラムのお作法では、プロダクトオーナーがユーザーストーリーを書くとされる部分
    - ユーザーストーリーとは？
        - POが要求仕様を下記のような自然言語で簡潔に記述したもの 
        - 「役割」として 「機能や性能」が出来る、それは「ビジネス価値」のためだ。のような書き方をする
<br><br>
- これが割とモヤッとしていることがあるので、代わりにMVPキャンバスを使っているが、これがユニークなようで会社見学でも注目されることがある

##MVPキャンバス
###オリジナル版
- AppSociallyの高橋氏とRecruitのMTLが共同で開発したもの
- 仮説を元に何を学び、そのために何を作るのかを具体化させるためのフレーム
    - 参考：https://www.slideshare.net/aerodynamic/mvp-canvas

<img width="500" alt="MVP1.png" src="https://qiita-image-store.s3.amazonaws.com/0/152460/00ffa33a-67f8-16d5-5763-f5821a970564.jpeg">

各項目を意訳すると
<img width="500" alt="MVP2.png" src="https://qiita-image-store.s3.amazonaws.com/0/152460/b00a37c8-5bc0-1a39-c3b6-eb14b05d368d.jpeg">

###アレンジ版
RODEMの開発チームでは、オリジナル版をベースに項目を追加したり、使っていない項目は無くしたりといったアレンジをしたものを使用しています。

<img width="500" alt="MVP３.png" src="https://qiita-image-store.s3.amazonaws.com/0/152460/53cd40ac-53cd-f03b-fc6a-2d34cd6c1532.jpeg">

####アレンジ版の構成
- Idea、Learn、Data、Build、Measureの5層構造としています
    - これが、開発における思考の順番と合っていると感じています 
        - **Idea**：MVPを作成する理由となる仮説は何か(主にユーザーの現状に基づく)
        - **Learn**：MVPの開発とそれを使った検証を通して何を学ぶのか。ユーザーにどのような行動変容をもたらすことを狙うのか。ユーザーはどんな価値を得ることになるのか
        - **Data**：OK/NGをジャッジするために何を計測するのか。何がどうなっていることを判断基準とするのか
        - **Build**：具体的に何を作るのか。POとしてリリースGoサインを出すための受け入れ条件は何か
        - **Measure**：ユーザー計測(定量、定性)の結果より得た学びは何か

####オリジナルとの差分
- 追加した項目
    - **期待する効果**：機能追加や仕様変更によってユーザーにどのような行動変容をもたらす事を狙うのか(AsIsに対するToBe)を共有したいため
    - **ユーザーベネフィット**：上記と同じく、それがユーザーにとってどんな価値になるのかを共有したいため
<br><br>
- 無くした項目：何か理由があって無くしたと言うよりは、使ってなかったからという方が表現としては正しいですｗ
    - 成長の原動力
    - イメージ
    - 回避/発生する将来のリスク

##まとめ
- 開発と検証のサイクルを可能な限り早く回すために、開発チームとの”握り”が重要だと考えています
- そのためには開発用件に対する共通認識をより具体的に可視化できるツールが有るといい
- 私のチームではMVPキャンバスをアレンジしたものを使っており、今のところの感触は良い

##参考
今回の内容は下記の発表内容を元にしたものです
- [UX Cafe: B2BサービスのUXデザインを語ろう 発表スライド「UXデザイナーがPOとして開発チームと”握る”ためにやっていること」](https://www.slideshare.net/itow_ponde/uxpo-170927-80220011)