CoDMON(以下コドモン)でプロダクトマネージャーをしている彦坂です。

コドモンは、日本で一番使われている保育・教育施設向けの業務支援ツールです。

1年間で優れたアプリを表彰する「App Ape Award 2021」では、最もヒトを長く惹きつけたアプリとして受賞させていただきました。

今回は、そのようにユーザーに使い続けてもらえるサービスにするために、どのようにプロダクト開発に取り組んでいるのか、ユーザーリサーチの観点から事例をまとめてみたいと思います。

機能のリニューアルに取り組む際に、どのようにリサーチを進めればいいのか悩まれているプロダクトマネージャーやデザイナーの方々の力になれると幸いです。

2020年4月より、コドモンでそれまで提供していた保育士のシフト管理機能を改善することになりました。

継続的な利用が起こっていなかった、リニューアル前のシフト管理機能

背景として、以前のシフト管理機能を使い続けてくれていた施設はあったものの、最初にお試しで使った後、使わなくなってしまう施設が多かったことがありました。

シフトを管理する体験自体にペインがあることはわかっていたので、大きくリニューアルを行うことに決めました。

まずは、なぜ機能が使われていないのかを考えるため、社内のヒアリングで事前に課題を整理した上で、現場の保育士の方々に課題特定のためのヒアリングを行いました。

規模などの違いを考慮して合計9施設にオンラインで話を聞いています。

この時に意識したのは、今の機能に対する不満を聞くのではなく、シフトを管理する工程全体で何が課題になっているかを聞いていくことでした。

機能が使われていないということで、チーム発足時点では以前のシフト管理機能で提供していた解決策を変えようと考えていました。

しかし社内関係者へのヒアリングを踏まえ、実は課題の選定/絞り方からズレがあるかもしれないという仮説に至ったことから、このユーザーインタビューではシフト作成の前後を含めた全工程の課題を明らかにすることを目的としました。

インタビュー中、実際のシフト表を見せていただいている様子

そのためインタビュー対象施設には、以前のシフト管理機能を活用いただいていた施設も、そうでない施設も含めています。

結果、これまでの機能で提供していた「シフトを組む時」の体験だけでなく、その前後にもペインはあり、特に「シフトを組んだ後」にそのシフトで問題なく保育が回るのか確認するペインも大きいことが分かりました。

業務工程全体から何を解決すべきかを整理し直して、機能でフォーカスする部分を決め直した

「この機能が本当に解決すべき課題の範囲はどこまでか?」というところから疑ってリサーチをしたことで、使い続けてもらうために不足している機能を特定することができました。

解決範囲を見極めた上で、機能に落とし込んでいきます。

ここでリサーチした声をそのまま反映すると本当にユーザーが求めていることにはたどり着きづらく、将来的に機能追加を重ねる中でも破綻しかねません。

そこで、ドメイン全体がどのような構造になっているのかを俯瞰して、ユーザーの関心事にまつわる概念を整理するために「ドメインモデリング」という手法を使ってユーザーの現場で何が起こっているのかを整理してみました。

ドメインモデリングを使って、ユーザーの現場で起こっていることを構造でまとめる

ドメインモデリングとは、利用者が「まさに自分のためのプロダクトだ」と思い受け入れてくれるものを作るために、彼らが目的を達成する上で関心を持つ概念全体をユーザー目線で整理する手法です。

(*ドメインモデリングについての参考記事) https://qiita.com/putan/items/3aa0ec1c104f1defa329

例えば、「持ち場」の設定という機能を新しくつくったのもこの整理がきっかけになっています。

ユーザーインタビューを通して、実はシフト作成において「場所」や「受け持ち範囲」が関わっていることがわかっていました。

ユーザーインタビューログを整理して、シフトに「場所」や「受け持ち範囲」が関わっていることを特定

そこでドメインモデリングを行い、インタビューでの整理を通してわかった「場所」や「受け持ち範囲」という概念に「持ち場」という名前を付けて整理しました。

ドメインモデリングで、シフトに「持ち場」という概念を紐付けて整理する

新しくできた「持ち場」の概念を、プロトタイプのデザインにも反映します。

シフトをつくる時に「持ち場」まで設定できる機能をプロトタイプに反映してテストした

このUIを実際に現場の先生に見せて検証したところ、新しくつくった「持ち場」という機能にも「イメージがつく」という回答をもらうことができました。

「持ち場」の概念が伝わるかをユーザビリティテストで検証

このように、現場で使われている「用語」や「隠れた行動」を見つけて整理することで、ドメイン全体から求められているものをUIに落とし込むことができるようになりました。

整理したドメインモデルをもとに、「持ち場」のような現場の「用語」や「隠れた行動」をプロダクトの機能にどんどん落とし込んでいきました。

例えば、当初開発することをイメージしていたのは、どの施設でも最終アウトプットとして作られていた「1ヶ月間の全体のシフト」を表す表形式の画面でした。

当初想定していた1ヶ月分のシフトを表すプロトタイプ画面

しかし業務理解を進めていくなかで、話を聞いた多くの先生がシフトをつくる時に、頭の中やノート、ホワイトボードで「1日の全体の、どの先生がどの時間にどの持ち場にいるのか」を整理していることがわかりました。

そこで、「1ヶ月分のシフト」だけでなく「1日のシフト」を整理できる画面も開発することとし、2つの画面が連動するような全体構成としました。

実際に現場で行われている行動をもとに、画面の構成をつくり直した

これらの機能をプロトタイプに落として、ユーザーとなる施設の先生方に触ってもらった結果、自然に手が動き始めていたので開発にスムーズに入ることができました。

このような課題探索と仮説検証のプロセスを経て、リニューアルした「シフト管理機能」をリリースしました。

最終的にリリースされた「シフト管理機能」の画面

リリース後も同じようなプロセスで、1年間継続的に改善し続けることで、結果としてトライアルで本格利用したユーザーの90%以上が3ヶ月以上継続的に利用し続ける機能になっています。

今回リニューアルしたシフト管理機能は長く提供してきた機能だったので、ユーザーからの要望は数多くあがってきていました。しかし、ここまで現場を深くのぞき込んで業務工程全体の理解から取り組んだのはコドモンとしても初めての取り組みでした。

ちなみに、今回のプロジェクトでは、エンジニアメンバーにもユーザーインタビューやテストを傍聴してもらいスレッドで実況してもらっていました。

エンジニアメンバーにも開発前のユーザビリティテストに傍聴参加してもらっていた

これまでよりも丁寧なプロセスでリサーチを進めつつ、常にユーザーの声を共有できていたことで、開発前からユーザーに対する理解度が高まったという声をもらえています。

現場の人がどのような言葉を使ってどのような行動を普段しているのか、その中でどのような課題に直面しているのか。チーム全体で解像度を上げることで、自然と使っていただけるプロダクトをつくることができます。

今後もドメインまで深く入り込んだリサーチに取り組んでいきたいと思います。