Prott User Meetup vol.25〜ヘルスケアサービスのプロトタイピング〜を開催しました!

Here comes the subtitle

Tim prott author

Tim Prott-03 / 29 / 2018-Event

「プロトタイピング、もちろん概念も知っているし実践しているつもりだけど、うまく使いこなせていない...」

そんな方はぜひ読んでいただきたい記事です!

2018年3月8日に、Prott User Meetup Vol.25 〜ヘルスケアサービスのプロトタイピング〜を開催しました!

本イベントでは、Prottを使ったプロトタイピングを実践している企業様として、株式会社エムティーアイで『CARADA』のUIデザインを担当されている粟田(あわた)さん、株式会社ナビタイムジャパンで『ウォーキングNAVITIME ALKOO』のPMを担当されている植竹(うえたけ)さんにご登壇いただきました。プロトタイピングの価値や実行方法、Prottがどのように使われているかについてお話しいただきました!イベントレポートとして当日の内容をお伝えします。

プロトタイプ中心デザインプロセスのススメ|エムティーアイ 粟田さん

最初に登壇されたのは『ルナルナ』や『music.jp』など、モバイルコンテンツを多領域にて展開している株式会社エムティーアイより、ユーザーセンタードデザイン部粟田さん。健康データを一括管理できるアプリ『CARADA』のデザインを担当されています。

CARADAは、歩数や血圧、食事や睡眠、そしてお薬手帳や健診の結果までもひとつのアプリの中で管理でき、対企業・対薬局・対健診機関といった複数の展開をしているBtoBtoCサービスです。

粟田さんは、サービスに関わった当初に以下の3つの課題を感じていたそうです。

1. 品質向上の必要性・・・開発スピードを重視していたため、プロダクトの品質が高くなかった

2. サービス全体像の共通認識不足・・・急激に成長したため関係者が増え、互いのコミュニケーションが足りず、サービスの全体像について情報が集約されていなかった

3. 目指すべきビジョンの共有不足・・・各BtoBの課題に個別最適化してしまい、全員が共有している指針が存在していなかった

そういった課題が顕在化したところで、解決のための施策として、デザイナー視点での取り組みを紹介していただきました。それが、今回のテーマであるプロトタイピングです。

ツールの導入とプロトタイピングの活用

デザインプロセスの改善が、デザイナー視点での課題に対してのアプローチでした。

CARADAのデザインプロセス

WF(ワイヤーフレーム)作成とビジュアルデザインでは、もともと使っていたツールからSketchに置き換えることで工数が縮まっています。ビジュアルデザイン→コーディングの流れでは、デザイン指示書の作成を行なっていたところからZeplinの導入により、一気に効率が上がったそうです。

そして、キックオフ・ユーザーテスト・ドキュメント整備の段階において、Prottを使ったプロトタイピングを取り入れることに。

キックオフ:コンセプトプロト

ユーザーテスト:テストプロト

ドキュメント整備:仕様プロト・マスタープロト

フェーズごとにプロトタイプの種類が違う

一口にプロトタイプといっても、CARADAのチームの中では数種類のプロトタイプを使い分けていました。それぞれ紹介します。

ゴールの認識を統一する!コンセプトプロト

ビジョンがバラバラという課題に対して「自分たちのゴールはどこか?」を見える化したものがコンセプトプロトです。

普段はキックオフ時インセプションデッキを作って認識を合わせているそうですが、テキスト情報だけだとどうしても解釈の違いが生まれてしまい、ズレが生じてしまいます。そこで、Prottを使ってコンセプトプロトをメイン画面+二階層目の画面くらいまでを作成することで、自分たちがこれから何を解決しようとしているのかを明確に共有できます。

プロトタイプが議論の中心になる

ポイントとしては、MVPのみを作成すること、発想が狭まる恐れがあるときには作らないことを意識されていたそうです。認識を合わせることが大事なので、グラフィック要素などのミクロ視点での議論はNGですね。

ユーザーテストで大活躍!テストプロト

Sketch、Zeplin等のツール導入により工数が圧縮されたため、デリバリー優先の開発の中でもクオリティ担保のためのユーザーテストのステップが入れられるようになったと仰っていました。なぜクオリティ担保のためにユーザーテストが必要かというと、ヘルスケア・BtoBの領域においては自分がユーザーになりきって考えることが難しいからです。何らかの症状をお持ちの方や薬剤師さんなどの反応を知るには、彼らに直接使ってもらうことでしか検証ができないので、ユーザーテストが必要なのです!

ユーザー中心のプロダクトにするためには、実際の声を聞かないとわからない

ユーザーテストもいろんなパターンがあり、実際にユーザーを呼んだテストの場合や、社内からペルソナに近い人を見つけて触ってもらう場合、営業メンバーにテストプロトを持って現場でヒアリングしてもらう場合など、さまざま。

ユーザーテストで難しいのは、どれくらいの量・質が必要なのかというところだと思いますが、粟田さんは一つのテストプロトは5人の被験者で十分だと仰っていました。その実現のために、SketchとProttの組み合わせを重宝されており、SketchでUIパーツ・コンポーネントをシンボル化し、組み合わせて画面作成し、Prottでプロトタイプを作成しているそうです。

仕様書の補足として動くプロトタイプを!仕様プロト

仕様書という静的な資料だけでは伝えきれない実際の動きを説明するものとして、仕様プロトを作成されているそうです。ある程度開発を終えたあとに認識のズレが発生してしまうのを防ぐために、仕様プロトがその橋渡しになります。

開発後の手戻りを防ぐ仕様プロト

また、営業メンバーが開発中の機能をクライアントに見せる際に仕様プロトを改善して提案資料として組み込む場合もあるそうです。

また、ドキュメント整備のときに作るマスタープロトに関しては、最新のアプリ全体像を把握できるものとして、主要な画面を揃えたプロジェクトを用意されているそうです。これを共有するだけで、今どんな状況になっているのかを把握できるものになっています。

プロトタイピングは、開発における全ての課題を解決するものではありません。しかし、プロトタイプを議論に中心に据え置くことで認識のズレを無くしたり、ユーザーの声を取り入れることでクオリティの向上を目指したりできます。粟田さん曰く、ProttやSketch、Zeplinの導入により、今までより50%ほどの時間を短縮できたと話していました。

プロトタイピングや新しいツールをうまく活用できていない方は、ぜひ上記の方法を試してみてくださいね!

新規ビジネスにおけるプロトタイピングと実践|ナビタイムジャパン 植竹さん

続いて登壇いただいたのは、株式会社ナビタイムジャパンのサービス開発部・マネージャの植竹さん。経路探索サービスとして有名なNAVITIMEですが、今回はウォーキングNAVITIME-ALKOO-というサービスの開発についてのお話です。

サービスの紹介や開発プロセスについては、以前掲載したインタビュー記事をご覧ください!

「やるべき業務に集中できるようになった」ナビタイムジャパン開発チーム内の認識のズレを埋めたコミュニケーション術

NAVITIME-ALKOOの開発では、Prott導入前からプロトタイピングを実践されていたそうです。当時のデザインプロセスは以下のような流れでした。

ここで起きていた問題は、印刷された静的な画面をベースに仕様を詰めていき画像を見ながら開発を進めるため、実際の操作感がわからずに開発後に当初のデザインとズレてしまうことでした。デザイン指示書を作成していなかったこともあり、究極的には開発者の感覚で実装が進み、AndroidとiOSのアウトプットに違いがあったりもしたそうです。

Prottが生み出す好影響

Prottの導入によって、全部ではありませんが大きな問題がクリアになったそうです。

誰でも簡単にプロトタイプを作成/確認可能

チームメンバーほぼ全員がProttの編集権限を持っていて誰でも素案を出せるので、それらを確認してつなぎ合わせてデザインを作っていくという工程を踏むことが可能になりました。起案時から皆が関わることで、チーム全員の認識が揃いプロトタイプ自体のブラッシュアップも図れます。

いつでも実際の端末で、確認/テスト可能

アポイントなどで社外に出ているときでも手持ちの端末で確認できるため、社内にいなくとも開発を止めずに確認・コメントができ、コミュニケーションを常に取り続けられます。

効果としては、ツールの導入によって30%くらいの時間短縮ができ、クオリティの向上を感じたとのことです。また、PMの立場として、iOSとAndroidの操作感の違いを事前に防げるようになったのは大きな効果だったと話していました。

プロトタイピングの難しさ

植竹さんは、Prottによるプロトタイピングには難しい部分もあると仰っています。

プロトタイピングをどれくらい、誰に対してやるべきかといった塩梅が難しいのと、成果が具体的な形で現れにくいため、上層部からの支持が得られにくいこともあるそうです。プロトタイピングのゴールをどこに置くのかが明確でないと、ただのコストとして捉えられてしまう可能性があるからです。ムダなステップにならないように、何をもってプロトタイピングの成果なのかをきっちりと明確にしておくことが大事だとのことです。

また、プロトタイピングにビジネス的成果に関する責任は負わせないほうがいいというのが植竹さんのご意見でした。プロトタイピングの目的はプロダクトのクオリティ向上による、リリース後のインパクトを上げることにあって、プロトタイピングによって売れるのかどうかという議論を混ぜ込んでしまうと話がブレてしまうからです。

ビジネスについては、世の中に出してお客さんに使ってもらい、営業時などのビジネスの場面で得られたフィードバックをプロダクトに反映していくことで改善していくものであり、プロトタイピングはプロダクトのクオリティ向上を目的にするものであるという点を切り分けましょうというお話でした。

さいごに、以下のようにまとめていらっしゃいました。

「プロダクト開発において大事なスピード担保のために、一見遠回りに見えるプロトタイピングが長期的に活きてきます。仮説を立てて一度試してみるより当たる精度を高められるように、外れたことを学びにできるような設計にすることで、クオリティ向上につながります。考えて、テストして検証することを繰り返すツールとしてProttがあると思っています」

Prott Update News! Prottの開発方法とは?

Prott update Newsのコーナーでは、Prottのプロダクトマネージャーを行っている中村より、開発の手法やどういった順番で開発項目を選んでいるかという点について、話をさせていただきました。さまざまな国のユーザーの方々からの要望を、スクラムを使った改善サイクルを回し、プロダクトに落とし込む方法についてはなしていました。

こちらは、先日公開したPrott User Meetup Vol.24のイベントレポートに内容が載っているので、Prottの開発に興味のある方はぜひご覧ください。

さいごに

いかがでしたでしょうか?Prottを使ったプロトタイピングについて興味を深めていただけたら嬉しいです。

以上、Prott User Meetup Vol.25のイベントレポートでした。

こちらのイベントページにある「メンバーになる」ボタンを押していただけると、今後もPrott関連のイベントやUserMeetupを開催する際にお知らせが届くようになります。

Prottのことをあまり知らないという方も、過去に参加したことのある方も、是非お気軽に遊びに来てください!