MICINでは、9月20日に「クロンスマートパス」をリリースしました。

これは、患者さんが医療機関を受診する際の受付・会計・薬の受け取りがスマホひとつで完結し、手ぶらで通院が可能な新サービスです。医療機関の導入コストもかからず、患者さん医療機関双方にとってより快適な体験を作り出そうとしています。

クロンスマートパスの詳細は以下よりご確認いただけます
医療機関向け公式サイト ： https://pass-clinic.curon.co/
患者向け公式サイト ： https://pass.curon.co/

公式noteではこの「クロンスマートパス」誕生の裏側について、関わったメンバーによる座談会の様子をお届けしていきたいと思います。

前回に続く、note第2弾の本記事ではUI /UXのデザインとエンジニアリングを担ってきたメンバーに、プロダクトを形にして運用をスタートさせるまでのお話を聞きました。
※第一弾はこちらをご覧ください

酒井 公希 Koki Sakaiオンライン医療事業部 兼 エンジニアリング＆デザイン室プラットフォームチーム プロダクトマネージャー 富士ゼロックスでSEや事業企画の経験を積んだ後、ヤフー・DeNA(現MoT）にてサービスグロースに貢献。その後、MICINに入社。Meety公開中

七田俊輔 Shunsuke Shichidaオンライン医療事業部 プロダクトデザイナーエムティーアイでエンジニアとしてキャリアスタートデザイナーにジョブチェンジ後、自社プロダクトと受託開発の両方を経験しMICINに入社。

吉永昌平 Shohei Yoshinagaオンライン医療事業部 エンジニアユナイテッド、ウォンテッドリーで広告配信システムや HR システムの開発に従事した後 MICIN に入社。

目次

1. 検証目的にあわせて最後までこだわったUXUI設計
2. 中長期的な成長を見据えたバックエンド開発
3. 短期間でリリースするための密なやりとりとドキュメンテーション
4. 「クロンスマートパス」リリース後も改善は続く
5. それぞれのポジションに求める人物像は？

検証目的にあわせて最後までこだわったUXUI設計

酒井：第二弾ということで、これまでの流れを振り返ると
・去年の10月に発案、大まかなビジネスモデルを描き
・今年1月にPdMの僕と、UXリサーチャーの中村さんが参加し検証開始
・今年3-4月の段階で、プロダクトデザイナーの七田さんやエンジニアの吉永さんとプロダクトの設計について議論が始まりました。

リサーチの段階で医療機関には使ってもらえそうだとは分かってきたので、次に検証するのは「患者さんが本当に使ってくれるか」でした。そのためにどういうUXUIにするのかという体験設計段階からデザイナーの七田さんに入ってもらいました。

七田：まずは設計上ユーザーが迷いそうなポイントを、ユーザビリティテストで検証しました。このサービスは、患者さんが医療機関で配られるチラシをもらったところから登録してもらうので、まずは
・チラシでサービスの内容を正しく理解してもらえるか
・メリットを感じて理解した上で、プロダクト内の操作を正しく進められるか
の2点から考え始めました。

酒井：ユーザビリティテストをする前のデザインとかなり変わりましたよね。

七田：そうですね。検証で重視したのは初回利用の体験です。
クロンスマートパスは、受付の時にQRコードを読み取るんですが、診察室に入ったらアプリの存在って忘れちゃうと思うので、診察後にとってもらいたいアクションを事前にイメージしてもらうことを意識して設計しました。
テストでは「画面上で伝えたことを覚えていてくれるか」「通知が届いた時に見てくれるか」など、インタビューで確認し改善しましたね。

吉永：患者さんの行動パターンも10パターンくらい出していましたよね。決済しているかとか処方箋をもらっているかによって違ったりするし、その辺の細やかさがポイントなのかなと思います。

酒井：そうなんです。そこは結構こだわったポイントで、患者さんによって薬が処方される患者さんとされない患者さんがおられますし、このサービスに対応している薬局を選んでくださる患者さんだけでなく、いつもの薬局に行きたい患者さんもおられるので、それによってガイドの内容も変わります。さらに、その患者さんがお会計が終わっているのかとか、医療機関から薬局に処方箋が送られたかとか…それぞれ考えると20パターン以上とか出てきて。エンジニアからするとMVP開発の時点でなるべくこういった分岐を減らしたいと思うんですよね。だから吉永さんには「ごめんなさい」と言いつつも「なんとかなりますかね」と相談していました（笑）

吉永：通院に関わる体験がよく考えられているなと思いました。どのパターンも患者さんにとっての分かりやすさ、使いやすさを考えると必要だと納得感があったのを覚えています。

酒井：β版プロダクトでのトライアル検証なのでできるだけ早く始めたかったのですが、「患者さんが本当に使ってくれるか？」が検証目的だったため、1回目の利用でユーザー登録やサービスの利用の体験が悪かったら、それだけで見向きもされなくなってしまいます。MVPだからといって中途半端なUXUIでリリースしても、きちんと検証ができなくなるため、こだわる必要がありました。結局、ユーザビリティテストは4月に始めたけれど、5月中旬までやってましたよね。

七田：はい、実際ユーザビリティテストをしてみると、サクサク操作できてしまうからこそ、あんまり情報が頭に残ってないという意見もあって。無意識に直感的に操作を進めてもらうところと、意識的に読み込んでほしいところの表現にメリハリをつける必要がありましたが、患者さんが今置かれているシチュエーションに合わせて、「何をどういう風に表現すれば患者さんに必要な情報が伝わるか？」をテストのたびにチームで話し合い調整を重ねました。リリース後に使ってくれた患者さんからも良いフィードバックがもらえて検証の成果が出たことにうれしく思っています。

中長期的な成長を見据えたバックエンド開発

酒井：ユーザビリティにも手を抜けない状況だったんですけど、できるだけはやくトライアル検証をはじめるためにも、並行して開発を進める必要がありました。4月の頭にはプロトタイプでの検証結果を元に要求仕様をPRDとしてまとめていたので、その内容からエンジニアの吉永さんたちにはバックエンド構成やデータベース設計などを進めていただきました。また、その中でも、今回は高いハードルがありましたよね？

吉永：そうですね、今回開発したクロンスマートパスは、既存のMICINのプロダクトであるお薬サポートとオンライン診療を使っていただいている患者さんに新たにユーザー登録することなく使っていただけるようになっています。そのため、、既存プロダクトの患者さんのユーザーアカウントを、利用できるようにつくっていく必要がありました。これだけを考えると既存プロダクトにそのままコードを追加していく方が楽なのですが、既存プロダクトのコードベースは肥大化しステークホルダーも増えていたので、新規のコードベースとして作り、同時進行でアカウント基盤を構築・利用する形で進められました。

酒井：そもそもオンライン診療クロンは、MICINの1stプロダクトであり、単体で使う前提でつくられたため、密結合の構成となっています。ただ、今後のプロダクトの成長を見据えて、アカウント基盤を分離する計画を1月から進めています。クロンスマートパスという新しいプロダクトの開発とアカウント基盤の分離＋繋ぎ込みを並行して進める必要があったため、バックエンドのアーキテクチャなどはエンジニアに主体的に動いていただきました。

吉永：クロンスマートパスの開発とアカウント基盤の分離を並行して進められるように、連携仕様とアーキテクチャ上の境界、インターフェイスだけ先に決めて、仮のログイン状態でクロンスマートパスの機能開発を先に進めていく形にしました。これなら、アカウント基盤側の進捗が遅れてしまったとしても引っ張られずに進められ、実装完了次第すぐに連携もできるので。でも、今回のようにアカウント基盤を切り離しつつ新規サービスも並行して進めるっていうことは、あんまりない例かもしれないですね。

酒井：そうですよね。ほんとうは一個ずつ進めるというか、まずは切り離す。その上で切り離されたものを使う開発計画をたてますが、切り離しながら並行して作るのはあまり聞いたことない気がします。また、全てを作り切ってテストするとなるとスケジュールが押してしまうので、アカウント基盤側のエンジニアと吉永さんで役割分担をしっかりしながらも密に連携しながら進めてくれた気がします。

吉永：今回、各機能を既存プロダクトと連携しつつもクロンスマートパスを新たなコードベースで開発したため、既存プロダクトへの影響の考慮やステークホルダーへの調整等が少なく、素早い実装、その後の改善につなげられていると感じています。また、アカウント基盤が確立されつつあることで今後の新規プロダクトはよりスピード感を持って進められますし、既存プロダクトを含むアカウント周りの体験に一貫性を持たせられ、改善も進めていきやすくなったのではないかと思います。

短期間でリリースするための密なやりとりとドキュメンテーション

酒井：デザインとバックエンド両面で大変な状況だったんですけど、だからこそチームでかなり工夫した点があった気がします。実際にβ版の1stリリースが6月16日だったので、GW期間除くと開発期間としては2カ月ぐらいですかね。こだわりながらもかなり早く出せたんじゃないかなと思っています（笑）また、トライアルを実施いただく医療機関とお約束している時期からずれてしまうとご迷惑をおかけしてしまうので、スケジュールをずらさないように、最後の最後までいろんな調整をしていたとおもいますが、皆さんどうでしたか？

七田：ユーザビリティテストを5月半ばまでやっていましたし、そこからの開発だと正直間に合わないので、先行して開発は進めていただきながら、デザイン面で調整が入っている部分は密にコミュニケーションしながらチームで認識合わせをしていました。あとは、1stリリース後の磨き込みについてもみんな考えながらすすめていたので目線がそろっていた気がします。

酒井：確かに、まずはスケジュール通りにリリースしてから改善していこうみたいな気持ちはみんなの中にありましたね。だからこそ、最初のリリースの時にどこまでやるのかはずっと話し合っていました。「ここはひとまず削っていいよね」とか「削るけど次は出そうね」とか。もちろん1stリリース後にトライアル利用がはじまるので、その時点で何を出すかも結構難しくて、「ここは何とかこだわりたい」とか。ただ、こだわるほど工数がかかるので、エンジニア側として吉永さんからも効率的な開発案はたくさん出してもらいました。

吉永：早く主要なシナリオの実装を完了して、QAを開始したいなっていうのはあったので、デザインを見てユーザーがその場面でやりたいであろうことを実現しつつ、開発工数を削減できる案がある場合にはチームに相談させてもらっていました。そこでこだわりたいところ、妥協できるところを議論していきました。

酒井：チームでは毎日30分くらいオンラインでスタンドアップミーティングをやってるんですが、その中で結構みなさん意見を言ってくださるので助かっています。オンラインミーティングだと意見が出てきづらいこともあると思うんですけど、このチームは毎日大体オーバーする感じでしたね（笑）。

吉永：どんな意見でもすぐに否定するのではなく、いったんは肯定的に受け止めるという雰囲気があったので議論が活発にできたのではないかと思います。

酒井：あと、今回はかなりタイトなスケジュールの中でも仕様書をちゃんとドキュメント化しました。スピード優先になるとドキュメンテーションってどんどんしなくなっていくんですけど、これがないとテストする上で何が正しい仕様なのか分からなくなってしまいます。特に今回は決済のサービスなので機能品質にも手が抜けない状態だったので、テックディレクターの方にも入っていただいて、きちんと仕様を残していくことを徹底しました。そのおかげで、テストも効率よく進められたかなと思いますね。

吉永：ドキュメンテーションがきちんとされていたので、とても助かりました。荒い粒度の仕様書だと、実装前に考慮漏れが無いかを精査する時間を多く取られたり、テストや実装をしてみて初めて問題に気づく、あるいは想定していた仕様と実装が異なるといったことが起こりがちなのですが、正確なドキュメンテーションがあることでその辺りの問題を避けることができたのかなと思います。

酒井：プロダクト開発において「バグは上流でつぶせ」って当たり前のことなんですけど、実践する方が難しくて、急げば急ぐほど作る方に注力しがちで、前段の検討をおざなりにしちゃうみたいなところはあるんです。でも、そこの両立がなんとなく上手くできたのかなとは感じますね。何かを捨てるのはもちろん必要なんですけど、その中でもバランスを取るっていう難しさの中で、みなさんのモチベーションの高さもあったからこそなんとかやり切れたのかなと思います。

「クロンスマートパス」リリース後も改善は続く

酒井：今は実際にユーザーさんの声が集まってきているのですが、コンセプトがちゃんと伝わっているようには感じています。1stユーザーの患者さんにインタビューした時には、このアプリ「神です！」という声をいただきまして、チームメンバー全員で喜んでいました。ただ、「便利なんだけど、こういうところがもうちょっと」とか。患者さんだけでなく、医療機関の方々からも「患者さんからこういうことを聞かれる」とか「こういうとき困るんですよね」といった意見をいただいています。

七田：そうですね。医療機関って診療科によっては処方箋が出ない時もあるし。そうなった時に患者さんはどんな行動をしうるのか、小児科だったら二人同時に兄弟で診察してもらうこともあるし、さまざまなケースがありますよね。実際に使ってくれたユーザーさんたちの声をヒントに解像度を上げながら、プロダクトを改善していきたいと思っています。

吉永：エンジニアの僕らもユーザーインタビューを聞けて、なかなか苦労しながら作ったものに対してポジティブな声をもらえたのは単純に嬉しかったですね。今後はクロンお薬サポートとも連携をさらによくしていったり、MICINの他のプロダクトとの連携を拡張させていくことで、よりユーザーさんの医療体験を良いものにしていけるんじゃないかなと思ったりしています。

酒井：こんなメンバーばかりなので、改善の仕様やデザインを検討している時も、メンバー全員が利用者のことを考えているので、ディスカッションに熱が入ります。実は一度こんなことがありまして、、チームでかなり議論して決めた仕様だったんですけど、2-3日後に七田さんから「やっぱりこういう風にさせてください」って提案があったので、聞いてみるとすごくいい案だったんですよね。

七田：あの時は議論中に感じてた違和感を形にするのに時間がかかり、スケジュールを考えると切り出すべきか悩んだのですが、普段から話しやすい空気がチームの中にありましたので、急な変更にも耳を傾けてくれると信じて思い切って相談することができました。反省と感謝の気持ちでいっぱいです。

それぞれのポジションに求める人物像は？

酒井：PdMって意味だと、機能とかHOWにはあまり捉われないでほしいなと思っています。MICINの場合だと患者さんが通院や診療・治療体験のなかでいろんな課題を抱えている現状に対して、そこにある課題って何なのかを、大きな課題とブレイクダウンした小さな課題に分けて解決していく必要があると思います。さらに、大きな課題っていう抽象的な概念になった時に、将来めざしたい姿とはどんなものなのかを考えられる人に来てほしいですね。かつ、そこをちゃんとチームのメンバーに語れるところですかね。僕もまだ修行中なのであんまり大きなこと言うと偉そうになっちゃうんですけど…やっぱり、チームと一緒に未来を作っていきたいなとすごく思っています。
また、これまで受託型のシステム開発しかご経験がない方でも、プロジェクトマネジメントや仕様をしっかり詰めていく部分はプロダクト開発の中でとても大事な部分ですので、一緒に働いてみたいと思った方であればウェルカムです。

吉永：エンジニアに関して言うと、MICINは一人のエンジニアでやる範囲が広い気はしていて。バックエンド、フロントエンドはもちろん、インフラもやります。。今回はアカウント基盤の構築含む新規プロダクトの開発でしたが、既存プロダクトの大規模なリファクタリングや作り直しを行うこともあります。なので、技術領域、プロダクトのフェーズ問わず、よいプロダクトを作っていく上で必要なことはなんでもやるという方が合っているのではないかと思います。

七田：
デザイナーはHOWのUI部分に責任がありますのでUIを突き詰めるところにこだわりを持つことが重要だと私は考えています。一方で既存のプロダクトが大きくなるとUX負債がどうしても積み上がってしまうので、それを解消するための調整にもパワーを割く必要があります。クロンは複数のプロダクト同士がつながってきているフェーズでして、プロセスから見直す必要があったり横のつながりの課題にデザイナーが動く必要があると感じています。一緒にそこを解決してくれる方がいて下さるとうれしいなと思います。

クロンスマートパスの立ち上げから検証までの記事はこちら！