ゼスト Tech Blog

ゼストは「護りたい。その想いを護る。」をミッションに、在宅医療・介護業界向けのSaaSを開発しています。

在宅医療・介護業界向けSaaSのプロダクトマネージャーって面白いの?やりがいは?

こんにちは。「護りたい。その想いを護る。」株式会社ゼストのプロダクトマネージャーを担当している川添です。

私はもともと在宅医療・介護の業界にも、プロジェクトマネージャーというキャリアにも縁がありませんでした。そんな私だからこそ言語化できるであろう、この仕事の「面白さ」「やりがい」について書いてみようと思います。在宅医療・介護業界のSaaSに興味を持っている方の参考になれば幸いです!

SaaSのプロダクトマネージャー」という面白さ

私はプロジェクトマネージャーとしてのキャリアはまだまだこれからですが、長くやっていたウェブディレクター・プランナーに比べるとさまざまな特徴があって非常に興味深く感じています。

プロダクトの将来像を描き続ける

ウェブディレクターとして動いていた頃はコーポレートサイトからプロモーションサイトまで幅広く手がけていましたが、特に商品に関するウェブサイトの寿命は短く、1ヶ月しか公開されないコンテンツというのも多々あります。公開期間が短いために「締め切り死守」である一方、「短期的にやり過ごせればよし」でもあります。それに比べてSaaSは基本的には継続的に使い続けていただくものなので、長い目線で使いやすいサービスでなければなりません。将来の拡張性まで視野に入れながら今やるべきことを考えるのは大変で、かつ面白い部分です。

設計の重要性が高い

情報発信を主目的としたウェブサイトがコンテンツ重視だとすると、SaaSは設計重視です。何がどこにあり、どうすると結果どうなるのかが「何かをおこなう前からわかる」。そのためには、画面設計、導線設計はもちろん、ひとつひとつのボタンのラベリングでさえ「本当にわかりやすいか?」を自問し続ける必要があります。多機能が便利とは限らない、という点も面白い部分です。細部までこだわりたい気持ちのある方には向いているかもしれません。

自分たちでジャッジしていく必要がある

プロダクトマネージャーとして、日々「こうするべきか、しないべきか」と岐路に立つことが頻発するのですが、その度に自分たちで答えを選び続ける必要があります。SaaSは常に仮説と検証の繰り返しです。だからこそ、小さく始めてフィードバックを得たり、顧客にこまめにヒアリングさせてもらったり、社内のメンバーを呼んで壁打ちさせてもらったりできる環境が大切だと感じます。

個別最適より全体最適

クライアントワークとの大きな違いのひとつに、「1社の要望に応えるか、顧客全体の要望に応えるか」という点があります。ハイタッチで関わった1社1社の要望を聞いてそのまま実装してしまうと、あちらを立てるとこちらが立たずという状態に陥りがちです。要望の裏に潜む背景、Whyの部分を深掘りして、顧客全体にとってどうなのか、どうすべきなのかを考えるのは「理想の答え」を模索するのが好きな人にとっては非常に面白いと思います。

顧客とビジネスのバランスがより重要

SaaSは顧客あってのものです。しかし、同時にビジネスとして成立しなければ継続的に高品質のサービスを届け続けられません。このバランスがとても難しく頭を悩ませる部分ですが、個人的には「受託制作で継続的に価値を上げ続ける」という難題に比べると非常にクリアで、健全な悩みだとも思っています。

「在宅医療・介護業界」特有の面白さ

続いて、在宅医療・介護業界に関わる面白さについても挙げていこうと思います。

顧客の志の高さ

ゼストに関わるようになって一番驚き、嬉しかったのは、顧客である在宅医療・介護のサービス提供者の方々が情熱に溢れていることでした。もう本当に、良い人たちが多いのです。いろんな業界の方々とお仕事してきましたが、「誰かのために何かしたい」という気持ちの強さはずば抜けているなと感じています。「貢献したい」という思考が強い方にとっては、顧客と互いに理解しあえて居心地がいいと思います。

バーティカルであり、ホリゾンタルでもある

顧客は強い責任感を持ち、利用者・患者のために日々奔走する方々です。社会に必要とされている存在であるにもかかわらず、本来もっと力を注ぎたいであろう医療・介護サービスに安心して集中できる環境がまだありません。なぜなのか。それは、関係者が多岐に渡りひとつの問題解決にも複数のステークホルダーへの配慮が求められること。ひとつのサービス事業所が関わる保険制度が複数に及ぶこと。サービスを受ける利用者・患者が千差万別でたくさんの特例が生じがちであることなど、この業界特有の複雑さが起因しています。そのため、訪問看護訪問介護、訪問診療などの業態ごとに深く理解するのと同時に、在宅医療・介護業界全体を見据えた判断が必要です。私はひとつのことを突き詰めるのは得意である一方、やり過ぎると息切れしまうので、バーティカルかつホリゾンタルの両方が求められるのは性に合っているなと感じます。

自分自身が(将来)当事者になる

健康と無関係な人はいません。そして、家族や友人に広げて考えると、現在または近い将来「在宅医療・介護」の当事者・関係者になる可能性は高いでしょう。早めに在宅医療・介護について知っておくといざという時ためになりますし、在宅医療・介護業界への貢献はやがて自分たちに返ってきます。仕事として人生の何割かの時間・労力を割くなら、自分にとって意味のあることに投じたいものです。

自分たちの手で変革できる

業界の課題が山積みということは裏を返せば「自分たちの手で解決できる」ということでもあります。特にこの業界のデジタル分野はまだまだ未開拓です。より良いプロダクト、サービスを生み出すことによって世の中に大きな良いインパクトを与えられるというのも魅力の一つです。

在宅医療・介護業界向けSaaS企業に向いている人の特徴3選

個人的にですが、在宅医療・介護業界のSaaSに合っている人の特徴はこの3つではないかと思っています。

課題を放置できない

「困っている人をそのままにできない」「未解決課題にモヤモヤしてしまう」「大きな課題ほど燃える」という方にとっては毎日ワクワクしかないでしょう。課題は山積みで、難易度も高いのです。でも、その分、新しい解決方法を顧客に提示した時の相手の「わあ!」という嬉しい反応を見る機会もたくさんあります。

全体最適できたときにアガる

木を見て森を見ずでは、SaaS、特に在宅医療・介護業界のSaaS企業では太刀打ちできません。反対に、「小さなリソースで全体に良い影響が及ぶ」といった視点で動ける人は活躍できると思います。

社会的意義のあるサービスをつくりたい

個人的に、ゼストで仕事していて一番感じるのはここです。「これをやりたかったんだなぁ」と日々思っています。本当に世の中の人のためになるサービスを作れるチャンスがこの業界にはたくさんあります。

いかがでしたか?ニュースで語られる在宅医療・介護とは違った視点で業界を知っていただけたでしょうか。この記事を読んでちょっとでもゼストに興味を持たれたら、ぜひ一度、弊社のWantedlyをチェックしてみてください!

www.wantedly.com

Azure Windows VMでRemote Desktopに接続できない場合の対応方法

title

ZESTではGoogle Cloud Platformに加え、一部Microsoft Azureも使用しています。

Azure環境ではWindows Virtual Machine(VM)を運用しているのですが、先日、Windows UpdateでRemote Desktopにアクセスできなくなる事象が発生しました。 その際に利用した、RDP接続できない場合でもVMにアクセスする方法についてご紹介します。

azコマンドからのPowerShellスクリプトの実行

learn.microsoft.com

VMエージェントがインストールされている場合*1、az コマンドからPowerShellスクリプトをリモートで実行することができます。

# script1.ps

Get-Item .
 az vm run-command invoke --command-id RunPowerShellScript --name <VM name> -g <Resource Group> --scripts @script.ps1

上記の実行結果は下記のようになります。value[].message に実行結果が格納されます。

{
  "value": [
    {
      "code": "ComponentStatus/StdOut/succeeded",
      "displayStatus": "Provisioning succeeded",
      "level": "Info",
      "message": "    Directory: C:\\Packages\\Plugins\\Microsoft.CPlat.Core.RunCommandWindows\\1.1.15\n\n\nMode                 LastWriteTime         Length Name                                                                 \n----                 -------------         ------ ----                                                                 \nd-----         9/17/2023   7:24 AM                Downloads                                                            \n\n",
      "time": null
    },
    {
      "code": "ComponentStatus/StdErr/succeeded",
      "displayStatus": "Provisioning succeeded",
      "level": "Info",
      "message": "",
      "time": null
    }
  ]
}

管理者以外でrun-commandを実行する場合には別途 Microsoft.Compute/virtualMachines/runCommands/write の権限が必要になります。

コマンドの実行には、Microsoft.Compute/virtualMachines/runCommands/write アクセス許可が必要です。 仮想マシンの共同作成者ロール以上のレベルには、このアクセス許可があります。

正常に実行結果を取得する場合には、443ポートを許可が必要になるケースがあります。

正常に機能するには、実行コマンドに Azure のパブリック IP アドレスへの接続 (ポート 443) が必要です。 この拡張機能にこれらのエンドポイントへのアクセス権がない場合、スクリプトが正常に実行されても結果が返されないことがあります。

またAzure portal実行コマンド - RunPowerShellScript メニューからも実行することができます。

Azure PortalからのPowerShell実行

Azure シリアルコンソール

learn.microsoft.com

Azure portalからシリアルコンソールに接続することができます。

事前準備として、Emergency Management Services(EMS)を有効化します。

Azure portalから 実行コマンド - Enable EMS を実行します。*2

EMSの有効化

EMS有効後、メニューの シリアルコンソール からコンソールにアクセスできます。

CMD #チャンネルを作成

ch -si 1 #チャンネルに接続

シリアルコンソールへのアクセス

ログインプロンプトが表示されるので、Windowsログインに利用しているID/PASSを入力します。

ログイン後、コマンドプロントが起動します。

コマンドプロンプト

PowerShellも起動することができます。

PowerShell

またazコマンドからシリアルコンソールに接続することもできます。

learn.microsoft.com

az serial-console connect -n <VM name> -g <Resource Group>

az コマンドによるシリアルコンソール接続

まとめ

Windows サーバにRDP接続できない場合でも、上記の方法でVMにアクセスすることができます。 今回Windows UpdateでRDP接続できない事象が発生しましたが、コマンドやコンソールからRDP接続できない原因の調査、修復をすることができました。 またRDPを用いずにVMを操作できるため、上記のような調査以外にも、作業の自動化にも利用できると思います。

*1:Azure PortalからVMを作成した場合、標準でインストールされていると思います

*2:有効化した後、VMを再起動する必要があります。

Google CloudのTech Acceleration Programに参加しました。

アイキャッチ

Google Cloud社のTech Acceleration Program(TAP)にご招待頂き、開発本部のメンバーで参加してきました。 本エントリーではTAPの詳細や参加した感想などについて紹介したいと思います。

Tech Acceleration Program(TAP)

TAPはGoogle Cloud社が提供している開発内製化を目指す会社や組織のためのアジャイル型の開発支援ワークショップです。

cloud.google.com

このプログラムでは開催中Google Cloud社のエンジニアの方がつきっきりで最適なアーキテクチャ設計〜プロトタイプ開発について、サポートしてくれます。

弊社では既に開発については、内製化されているため、新規プロダクトについてのアーキテクチャ設計検討やプロトタイプ開発について、3日間に渡り開催頂きました。

初日

初日はGoogle Cloud社の六本木オフィスでの開催でした。

午前中はアーキテクチャ検討をするにあたり、まずはビジネス要件やシステム構成の共有から始まりました。印象的なこととして、ワークショップを始める前に、よりよいワークショップとするために、心理的安全性を確保する方法についての説明があったことです。心理的安全性の重要さを発見・実践している企業なこともあり、このような文化を大切にしている印象を持ちました。

ランチをはさみ、午後から本格的に今回対象とするスコープとアーキテクチャ検討について議論しました。 アーキテクチャ検討については、現在の要件を満たしつつ、将来的な拡張性も含めて検討し、またそれを実現するGoogle Cloudのサービスの組み合わせについても検討しました。

2日目

2日目は渋谷オフィスでの開催。

エイプリルフールで紹介されたデバイス
エイプリルフールで紹介されたデバイスが展示されていました。

前日に検討したアーキテクチャについて、プロトタイプをモブプロで作成します。

プロトタイプでは利用するそれぞれのGoogle Cloudのサービスについて、まずはサンプルで動作を確認してから、ミニマルな実装へと進んでいきました。また、定期的にタイピストを交代しながら進めたこともあり、これまで利用したことがないサービスであっても、メンバー全員が理解を深めながら実装することができました。 モブプロ実践においては、Cloud Workstationsを利用しました。各個人で環境を用意する必要がないため、スムーズに進めることができました。

起動すると、ブラウザ上に見たことのある画面が広がります。

cloud.google.com

3日目

3日目は再び六本木オフィスでの開催でした。

3日は前日に引き続き、モブプロを進め、プロトタイプの完成を目指します。 モブ側でAI Chatツールを駆使しながら、タイピストのコード作成を支援するというチームワークで進めたことで、無事完成までもっていくことができました。

モブプロの風景

完成後、少し時間があったため、今回のプロトタイプの対象から外れていたGoogle Cloudのサービスについてもご紹介頂き、全員で利用方法について理解を深めました。このあたりも大変柔軟にご対応いただきました。

最後に今回のTAP全体の振り返りを行い、よかったところ、学びになったこと、改善点などについて確認しました。

TAPに参加した感想

Googleのエンジニアの方がドメインを理解した上で、アーキテクチャの検討からプロトタイプの作成までサポートして頂けるので、より弊社のシステムに適した形でGoogle Cloudのサービスを利用できるようになりました。

Google Cloudのサービスについて、ちょっとした疑問や同様な機能を提供するサービスについてどちらを選択したほうが良いのか等の質問も、その場で詳細な回答を伺うことができるので、Google Cloudに不慣れなメンバーもこの3日間で各サービスについて理解を深めることができたと思います。

TAPの充実した内容はもちろんのこと、ランチの時間での美味しい社食やオフィス内カフェもTAP中の楽しみの一つでした。

カフェ

最後に

Google Cloud社の方々には期間中とてもホスピタリティ高くサポートして頂き、非常に充実した3日間を過ごすことができました。この場を借りてお礼申し上げます。

この貴重な機会を活かし、プロダクト開発を加速していきます!

色覚多様性に配慮した配色を考えてみる

こんにちは。株式会社ゼストでプロダクトデザインを担当している長沢です。

ゼストプロダクトデザイナーとしての主な役割は、顧客のヒアリングから業界の課題を見出し、顧客に分かりやすく伝えるための情報設計、提供しているプロダクトが抱える問題解決をUI/UXを通して機能的にデザインすることです。

そんなプロダクトデザイン業務で意識していることのひとつ、「色覚多様性に配慮した配色」について今回は考えてみたいと思います。

色覚多様性とは

色覚とは、私たちの目が光の波長を感知し、色を認識する能力を指します。人間の目には、主に3つの種類の錐体細胞があり、それぞれ赤、緑、青の波長の光に対して感度があります。この3つの錐体細胞の組み合わせによって、私たちは様々な色を識別することができます。

しかし、人々の錐体細胞のタイプや感度には個人差があり一部の人は特定の色を区別するのが難しい場合があります。これが色覚多様性です。

色覚多様性は、個人の体験に影響を与えるものであり、デザインやアクセシビリティの観点からも重要な要素となります。色覚多様性を理解することで、より包括的なアプローチを取ることができるため、デザインや情報の伝達において配慮することが重要です。

色覚タイプ

日本人の場合、男性では20人に1人、女性では500人に1人の割合で一般的な色の見え方とは違った色に感じている人がいます。

先天赤緑色覚異常の発生頻度は、日本人では男性の5%、女性の0.2%です。つまり、男性では20人に1人、女性では500人に1人の割合です。決してまれではありません。ちなみに、白人における発生頻度は8 ~ 10%とされています。女性の場合は、色覚は正常であっても、保因者といって先天赤緑色覚異常の遺伝子をもっていることがあります。この保因者の頻度は10%、10 人に1人です。

参照:冊子「色覚異常を正しく理解するために」 | 色覚関連情報 | 公益社団法人 日本眼科医会

特性に応じた色の見え方は以下のタイプに分けられます。

C型色覚(Cipher)

ほとんどの人が持つ色覚タイプ。

P型色覚(Protanopia)

赤と緑の色を区別するのが難しい状態。

D型色覚(Deuteranopia)

緑と赤の色を区別するのが難しい状態。P型色覚に近い見え方をする。

T型色覚(Tritanopia)

青と黄色の色を区別するのが難しい状態。※割合はごく少数。

A型色覚(Achromatopsia)

色を全く感知することができない状態。※割合はごく少数。

配色の考え方

色覚多様性を配慮したデザインを行う場合、色だけで違いを出すことはおすすめできません。文字やマーク、テクスチャを使用するなど色に依存しない別の方法で表現できないかを検討するべきです。色で解決をする方法は最終手段とするべきでしょう。

しかし、今回は敢えて色だけで色覚多様性に配慮したデザインを考えてみたいと思います。

条件

  1. 色だけで表現するためP型・D型・T型を対象とし、A型については対象外とする。
  2. 隣り合ったカードを視覚的に別のカードとして認識できるかをゴールとする。
  3. マジカルナンバー4±1(※1)の考えに基づき、使用するカラー種は4色までとする。

※1: 心理学者ネルソン・コーワンによって提唱された理論

配色パターン:1

緑色・黄緑色・黄色・オレンジ色の4つの配色で試してみます。

全体的に色の違いが分からない組み合わせになってしまいました。

とくにP型・D型では、カードB・カードCの違いを色だけで認識することはほぼ不可能です。P型・D型を考慮すると、緑色、黄色、オレンジ色の組み合わせは相応しくないことが分かります。

暖色だけの配色では色覚多様性に配慮して別のカードとして認識させることは難しく、緑系統の色はP型・D型では、グレーに近い色になってしまいます。

次は、寒色と暖色を使って表現してみましょう。

配色パターン:2

水色・青色・赤色・黄色の4つの配色で試してみます。

配色パターン:1よりも違いを感じられるようになってきました。

ただ、全体通してカードAとカードBの違いが若干分かりにくように感じます。T型は特に差が無いように見えます。P型・D型のカードCの赤色はグレーに近い色味に見えます。また、T型のカードDは色の違いは感じますが、他のカードに比べてかなり薄く見えるのが気になります。

ここまでくると、色の種類だけで調整するのが難しくなってきました。今後は明度を調整してみましょう。

配色パターン:3

配色パターン:2の「青色」と「黄色」の明度を低くして調整しました。

P型のカードB・カードCの違いがやや分かりにくいのが少々気になりますが、全体的に差を感じるようになりました。

まとめ

  1. 暖色同士・寒色同士の色は見分けがつきにくいため、暖色・寒色を組み合わせて調整すると差を付けやすい。
  2. P型・D型では緑色と赤色はグレーに見えるので一緒に使わない。
  3. 明度の調整でさらに色の差を付けると効果的。
  4. 色だけで表現する場合は3色程度が限度。

最後に

色覚多様性に配慮して、色だけで差別化をする事はやはり難しい印象です。色を使わなくて済むのであれば別の手段を検討した方がより良いユーザー体験を提供できると思います。

今回は色覚多様性をテーマにした配色について考えてみました。今後もこのようなデザインに関する考察や情報、開発の裏側の話など発信していけたらと思っています!

BtoBバーティカルSaaSにおいて顧客解像度を爆上げできた5つのトレーニング

こんにちは。「護りたい。その想いを護る。」というミッションを掲げている株式会社ゼストプロダクトマネジメントを担当している川添です。

私は2022年春に副業メンバーとしてゼストに参画し、ちょうど1年前の8月に正式ジョインしました。それまではディレクターやプランナーとしてBtoCのデジタルクリエイティブに携わっていた期間が長く、まさか自分が在宅医療・介護業界に関わるとは思ってもみませんでした。

今回はそんな業界初心者だった私が顧客について理解を深め、PdMとしてプロダクトの舵取りをするための判断力を培ううえで効果的だったトレーニングを紹介したいと思います。バーティカルSaaSに関わる方の参考になれば幸いです。

1. 顧客の声を聞く

「顧客の声を聞く」というと、真っ先に思い浮かぶのは顧客インタビューではないでしょうか。

プランナー・ディレクター時代にもネットリサーチやグループインタビュー、デプス調査などの経験はあったのですが、簡単に共感できるBtoCと異なり、BtoBのインタビューではまず業界を知らなければ仮説も立てられず、聞くべきこともわかりません。

そこで、最初から大勢を対象に話を聞くのではなく、ひとりひとりにじっくりと向き合い深掘りする「N1分析」に注力しました。商談に同席させてもらったり、顧客と利用者宅まで同行して実際に看護する様子を見学させていただいたりもしました。

特に気をつけていたのは、とにかく「なぜ?」を引き出すこと。考えや感想ではなく本当の困りごとは何か。どういう課題や解決方法に感情が揺れ動くのか。

ただ、N1分析は「時間がかかる」「視野が狭くなる」といった懸念もあります。そのため、まず短時間で幅広くキャッチアップするために、

  • 営業メンバーの商談動画をどんどん共有してもらう
  • 営業メンバーを質問攻めにする(とにかく「なぜ?」を聞きまくる)
  • これまでに寄せられたプロダクトへの問い合わせや要望を読み込む

といったこともおこないました。その際にも漫然と取り組むのではなく、毎回ひとつでも仮説やヒアリングテーマを持って臨むようにしていました。

2. 社内メンバーに業界・顧客について伝える

在宅医療・介護業界は一見とてもわかりやすいサービスです。介護?ヘルパーさんがいろいろ助けてくれるんでしょう?医療?お医者さんや看護師さんが家に来て様子を見てくれるんでしょう?と。だからこそ、慎重に深掘りしていかなければ「何がわからないかわからず、なんとなくわかったような気がする」錯覚に陥ってしまいます。PdMとしては致命的です。

そうならないために、と思っていたわけではないのですが、結果的によかったなと思う取り組みがありました。「開発対象のドメインについて深く理解しながら開発したい」という想いを胸にジョインしてくれたtechチームのメンバーに向けて、「在宅医療・介護業界の勉強会」や「顧客の状況を疑似体験するワークショップ」を開催したのです。

参加してくれたメンバー以上に、PdMである私自身のためになる機会だったように思います。これまでに見聞きしてきた顧客の課題感や置かれている状況を「人に伝える」ために矛盾なく整理し自分の言葉として伝えることで、「ああ、やっと自分のものにしたな」という手応えがありました。

3. Twitterで業界のリアルな声を知る

在宅医療・介護業界は制度も仕組みも複雑で一筋縄ではいきません。いえ、一見シンプルに整備されているかのように見えるのですが、実は大きな落とし穴があります。

それは、サービスを必要とする利用者の事情が千差万別なために「介護保険制度」「医療保険制度」といったようなルールだけでカバーされない部分や解釈の余地が多々あるということ。書籍や厚労省のサイトに書かれた情報は正しいのですが、実態と実情に関しては抜け落ちている(現場に委ねている)ことも多いのです。

そこで、やってよかったのが「Twitter」です。Twitterには「こういう時にとても困る」「こんなことがあって大変だった」といったツイートが溢れています。下手にインタビューをするよりも、生々しく時に矛盾をはらむリアルな気持ちがわかる場合があります。最近だと、Threadsでも警戒心なく本音を吐露している人たちがいるかもしれません。Instagramで投稿している「理想の姿」とのギャップに着目する方法もあると思います。

また、お客様個人とSNSで繋がっておくと、次に顧客インタビューなどでお話する時により深いヒアリングができる関係性を築けるメリットもあります。

4. プロダクトバックログを運用する

具体的な実務に近い部分でトレーニング効果があったのは、日々挙がってくる改善要望や不具合に対して優先順位をつけるというものでした。ちょうどその頃、弊社はtechチームが拡大する手前の時期だったこともあって、限られたリソースで何をすべきかの判断を間違えられない状況でした。影響範囲と緊急度、優先度、ビジネスインパクトはどうなるのかを洗い出し、営業に現場の温度感を確かめて順位を決定していく中で、プロダクトを取り巻く顧客の実務や課題が見えてきました。

その後、RICEスコアを取り入れることになりましたが、「今、何を優先すべきか?」といった問いが完全になくなるわけではありません。

5. 繋がりを活かす

N1分析にせよ、プロダクトの商談にせよ、プロダクトを日々運用する立場の方と対面させていただくケースが多いのですが、決済権を持つ方や経営層がまったく同じ思考で動いているかといえばそうではありません。現場の従業員も同様です。そのため、ゼストでは業界の繋がりを活かして様々な立場の方にヒアリングをおこなっています。

また、自分たちのサービス、プロダクト単体で業界のすべての業務をカバーできるわけではないので、業界で必要とされる他のSaaS企業との繋がりも重要になります。たとえばゼストは在宅医療・介護業界で電子カルテ・レセプトを提供する株式会社エス・エム・エス社と業務提携をおこない、顧客理解に繋げています。自社だけで限界があることを、自社で閉じてしまわずに他社と協業していくことも重要です。

最近は、在宅医療・介護業界で働いていた人を採用する動きもあります。現場の課題や外からは見えない動きなど、学ぶべきことが多くあります。

まとめ

いかがだったでしょうか?

顧客解像度を爆上げするには、地道なトレーニングが必要です。私の場合、techチームに自分の言葉で業界・顧客について語れるようになるまでに4か月〜半年ほどかかりました。これは様々な実務と兼務していたからとも言えますが、実務を並行しなければ理解できない部分も多かったので今振り返ってみてもこれが最速だったかな…と思います。

どれくらいのスピードで顧客理解が進むかは人によりますが、本人も会社も「ある程度の時間を投資する」という覚悟が必要です。顧客理解をないがしろにするのもよくないし、顧客理解がまだ不十分だからと何もアクションを起こさないのもよくないので、顧客に深く踏み込みつつも小さく開発してフィードバックを得る、そういったスタンスが重要だと考えています。

在宅医療・介護業界はまだまだたくさんの伸びしろがあります。そして、この業界の課題は地域で暮らす私たちにとって非常に関係の深いものです。社会を変えたい、多くの人に貢献したいという想いを大切に、これからも進化を続けていきたいです。

React向けコンポーネントライブラリにMantineを採用した理由

こんにちは。株式会社ゼストでWEBアプリケーションエンジニアをしている、海老原です。

以前、Webアプリケーション開発に使用しているライブラリの紹介をしましたが、今回はその続きとして、フロントエンドの開発で約半年間使用しているMantineというライブラリを紹介しようと思います。

前回の記事はこちら。

techblog.zest.jp

Mantineとは

Mantineは、ButtonやModalなどのUIに関するコンポーネントを提供するライブラリの一つで、React向けに開発されています。比較対象はMUIやChakraUI、Ant Designなどになります。本記事ではこれらをまとめてUIコンポーネントライブラリと呼んでいます。

mantine.dev

特徴としては、2023年8月現在トップページに”A fully featured React components library”と書いてある通り、コンポーネントとhooksの種類が豊富であることと、定義済みのコンポーネントに対するカスタマイズがしやすいことがあります。特にカスタマイズのしやすさが気に入っています。

UIコンポーネントライブラリを導入する際の懸念点として、実装したいデザインとライブラリが定義したコンポーネントが乖離していると逆に負荷が大きくなりやすい点があります。

例えば、あるコンポーネントを実装する際に、定義済みのスタイルを上書きする部分が多すぎて、1からCSSを書いた時よりも開発に時間がかかり管理もしづらい実装になってしまうことがあります。UIコンポーネントライブラリを使っていて、同じことを感じた方もいらっしゃるのではないでしょうか。

Mantineは「定義済みコンポーネントが高機能であること」と「カスタマイズする手段が豊富であること」の2点から、この懸念が解消されていると感じています。

定義済みコンポーネントが高機能であること

Selectコンポーネントを例に見るとわかりやすいかと思います。

mantine.dev

アイテムの文字列検索やアイテムの新規追加、入力内容の消去ボタンなど、一つひとつ実装していくと骨が折れるような機能が定義済みの状態で多く提供されています。

これによってライブラリの力を借りれる範囲が広くなり、安定した開発時間の短縮が見込めます。

カスタマイズする手段が豊富であること

Mantineでは、UIコンポーネントライブラリではもはやあるあるの機能となったデザイントークンの定義の他にStyles APIという仕組みが提供されています。これによってコンポーネントのルート要素以外の要素のスタイルをカスタマイズすることができます。MUIのslotsと似ている機能です。

Selectコンポーネントの例ではこれだけのスタイルをカスタマイズすることができます。

例えば、Selectコンポーネント内に表示されるアイコンのマージンを調整したい場合には以下のように書くことができます。

<Select styles={{ icon: { marginRight: "16px" } }} />

ドキュメントの見やすい箇所に載っていることからも分かりますが、Mantineはこの「カスタマイズのしやすさ」に目を向けた設計がされているため、スタイルのカスタマイズが細かく必要なコンポーネントの定義も公式のAPIを使って行うことができます。

なぜUIコンポーネントライブラリなのか

ここまで、UIコンポーネントライブラリというスコープの中でMantineの特徴について解説してきました。

コンポーネント実装の選択肢には、UIコンポーネントライブラリ以外に、Tailwindや最近話題のvanilla-extractのようなスタイル実装にフォーカスしたライブラリを使う選択肢もあります。ここからは、その中でUIコンポーネントライブラリであるMantineを使用する理由を説明します。

バンドルサイズ

Mantineを含むUIコンポーネントライブラリは、高機能で実装面でのカバーする範囲が広いため、その反動でバンドルサイズが大きくなるというデメリットがあります。これを許容できるかどうかは、実装するプロダクトの特徴によるところが大きいです。

toCサービスやメディアのようにページにアクセスした時の表示速度が重要なプロダクトの場合には、バンドルサイズの削減もまた重要になりやすいです。反対に、プロダクト内の回遊が多く同オリジンでの画面遷移が多いプロダクトの場合は、リンク先ページのプリフェッチなどの工夫ができるため、バンドルサイズに対しては比較的寛容になれます。ゼストが開発しているプロダクトは後者の特徴が大きいため、UIコンポーネントライブラリも採用候補に含まれました。

実装の保守

UIコンポーネントライブラリを使うことによって実装者による成果物の差異が減ることを期待しています(まだ使用して半年ということもあり、保守の観点については「期待」になります)。

スタイル実装をする際のプリミティブがCSSからコンポーネントやライブラリのAPIになることで抽象度が増します。これによって同じスタイルを実装する方法が絞られ、実装者が違っても似た実装、読んで分かる実装になりやすいのではないかと考えています。この点に関してはこれからもウォッチして行きたいと思っています。

最後に

UIコンポーネントライブラリのMantineを紹介しました。

まだ使い始めて半年ですが、使い心地が良く個人的に気に入っているライブラリの一つになっています。

使い続けた感想も、またいつかこちらのブログで書けたらと思います!

在宅医療・介護の経営指標を可視化!ZEST BOARD開発ストーリー

こんにちは。株式会社ゼストプロダクトマネジメントを担当している川添です。

2023年6月21日、新プロダクト「ZEST BOARD」をリリースしました。

今回はこのプロダクトが生まれた背景や、開発ストーリーを振り返りたいと思います。実はこのZEST BOARD、社長やCROとエンジニアが膝を突き合わせて開発したプロダクト。どのように話し合い、開発を進めたのか?ぜひ読んでいただけると嬉しいです!

ZEST BOARDとは?

ZESTを利用されているお客様の予定データ・位置情報を活用して、経営指標として有効なデータを可視化できる経営ダッシュボードです。お客様は普段通りZESTを使い続けるだけで必要な指標を可視化できます。さらに、営業強化ポイントを明確化するために、サービス提供事業所の営業先である居宅看護支援事業所MAPも可視化します。 有料オプションであるにも関わらず、すでにお客様から続々とお申し込みをいただいています。ありがとうございます!

なぜ、経営指標の可視化なのか?

私たちは在宅医療・介護業界の「護りたい。その想いを護る。」をミッションに掲げています。具体的に言えば、お客様が理想とする医療・看護・介護を安定して利用者様に届けられる手助けをしたい、そのためにZESTによって時間を創出する支援を、その後、空き時間を共有するZEST MEETを提供してきました。なぜ、次の一手を経営指標の可視化に決めたのか。ZEST BOARDの発案者である社長の一色さんにインタビューしました。

「ZEST BOARD」が生まれた背景

- 経営ダッシュボードはいつ頃から構想があったのですか?

「ZESTをスケジュール作成ツールから脱却させる」という考えを、ゼストにジョインした昨年夏頃から持っていました。「スケジュールを効率的に作る」のは、あくまで手段でしかなく、私たちが本当に提供すべき価値は「より良い経営がおこなわれ、従業員満足度とその先の利用者満足度を高められる」ことです。そのためには非生産的な時間を短縮して生産的な時間を増やす改善が必要ですが、その内訳が目に見えない状態では改善のしようがありません。そこで、まず第一歩として経営指標を可視化するダッシュボードによって「移動時間とアイドルタイムに目を向けてもらう」ことを考えていました。

- 業界全体でDXが当たり前になっているわけではなく、「経営指標を可視化したい」という顧客ニーズが顕在化していない状況でした。今、開発に踏み切る判断ができた理由は?

1つ目は構想の段階で業界の方々にヒアリングすることで、移動時間とアイドルタイムの可視化には手応えを掴んでいたことです。

実際にお話を聞いてみると、経営者だけでなく職員の立場から見ても「訪問件数や訪問時間だけで評価されることへの不満」があったんです。というのも、近場を回る職員は訪問件数、訪問時間を伸ばせますが、遠方の利用者宅を割り当てられた職員は移動に時間がかかる分、訪問件数を増やすのが難しくなります。野球のホームランと送りバントのような関係で、どちらか一方ではダメでそれぞれが役割を果たすことが大切ですが、遠方の利用者を訪問する職員は評価されにくいのが現状です。また、同じ訪問時間でも入浴介助のように体力を必要とするサービス、ターミナルやお看取りのように精神的な負荷が大きなサービスもあります。

今はそれらがすべてブラックボックスなので、「可視化することで少しでも解決に繋がれば」という想いがありました。

それから、2つ目は心強い開発チームがいる安心感ですね。

実をいえば、この「ZEST BOARD」はこれほど早くリリースできると思っていませんでした。開発リソースは有限ですし、ゼロからの開発になるので1年以上は先になると思っていました。でも、ある時「いつかやりたいんですよ」とCTO豊島さんに話したら、techチームで検討してくれて「既存ツールを組み合わせれば意外と早く作れるかもしれない」と回答をいただいて。メイン開発者の宮原さんの素早いキャッチアップと実装力のおかげで、最終的にtechチームがたった3ヶ月でリリースしたのは本当に衝撃でした。

また、新しいプロダクトは常に手探り状態から始まるので、顧客フィードバックを元にPDCAを回すのが大前提になります。せっかく顧客に見ていただいて有益なフィードバックをいただいても、プロダクトに反映できなければプラスにならないどころか、ご協力いただいた顧客との関係性にも悪い影響が出かねません。その点、プロダクトに責任を持って開発してくれるメンバーに恵まれていることは、ゼストの強みのひとつでもあります。

リリースまでと今後について

- techチームの責任感、チームとしての一体感は本当に強いですよね。今回の「ZEST BOARD」は一色さんたちビジネスサイドの方々とエンジニアが直接議論しながら作り上げたプロダクトですが、どのように開発を進めていったのでしょうか?

私の方でリリース原稿の草案を書き、それを元にtechチームが開発してくれました。そして、開発したプロトタイプを協力してくださる顧客に見ていただき、リアルなフィードバックをいただいてブラッシュアップしていきました。「第1弾では難しいかもしれないですが」と伝えたフィードバックがどんどん形になるので、驚きの連続でしたね。

リリース後に顧客から喜ばれる機能の多くは、こうしたブラッシュアップの中で生まれたものだったので、スピード感のある対応をしていただけたのは大きかったなと思います。

- お客様からの反響はどうでしたか?

「ようやく業務負荷を定量化できた」という喜びの声や、チャレンジする姿勢を評価する声を多く頂いています。一方で、明確なリクエストもいただいているので、随時対応していきたいですね。

- 今後「ZEST BOARD」をどのように進化させていきたいですか?

今は「ZESTをスケジュール作成ツールから脱却させる」ためのスタートラインに立ったところですので、まだまだ進化の余地があると思っています。

在宅医療・介護業界は、ビジネスであり社会インフラでもあるという二面性を持っているが故に経営手法が浸透しきっていません。しかし、社会インフラであるからといって経営努力をしなくてもいいわけではありません。むしろ、他業界からの学びを取り入れてより良い経営をおこなうことでサステナブルな事業として成長させることが、最終的には職員と利用者の満足に繋がります。

業界全体で生産性を高められるようなプロダクトに進化させていきたいですね。

開発者インタビュー

メイン開発者の宮原さんに、開発の苦労話や得た経験についてインタビューしました!

開発の流れ

- どのような流れで開発を進めたのですか?

一色さんの構想をもとにデータベースの構造を確認しながら、できること・できないことの精査をおこないつつ、小さく開発しては確認してもらうといった進め方をしました。その後で、本格的な技術選定や全体のアーキテクティングをおこないました。リリーススピードにはこだわりたいと思っていたので、手戻りの少ない進め方を意識しました。

- 社長やCROなどビジネスサイドの方とすり合わせながらの開発でしたが、どうでしたか?

やりたいことが明確だったので、動くものを見せながらすり合わせるようにしました。要件やスケジュールにブレが出ないように週次定例の場を設けて随時連携しながら進めたのですが、慣れない在宅医療・介護業界の専門用語が飛び交うこともあり、質問しながら進めましたね。また、顧客にとって本当に使えるプロダクトにするため、時には議論が白熱したり、途中で仕様変更したりしながら詰めていきました。

大変だったこと

- ZEST BOARD開発にあたって、大変だったのはどういったことでしたか?

一番苦労したところでいうと、私は入社してまだ日が浅く、自社の既存システムのデータベース構造を学びながら開発しなければならなかった点です。ただし、単にテーブル構造を見て学ぶよりも、目的を持って実際に手を動かしながら学んでいったので、通常よりも早く学べたのではないかと考えています。

あとは、いくつかのサービスを組み合わせた構成になっているのですが、初めて使うサービスもあってチャレンジではありましたね。たとえば、データソースが複数あったため、自動でデータパイプラインを構築するサービスが必要で、5〜6サービスほど検討しました。GCPのサービスや、GUIベースの簡単な設定ですぐに使えるサービスなど様々あり、選定は割と大変でした。

参考:詳しい構成は宮原さんのブログ記事をぜひ!

成果と今後のこと

- 今回、うまくいったと感じることは?

「平常時であれば、メンテナンス工数がほとんどかからない」というのを実現できたことですね。でも、実はさらに運用工数を下げるための工夫を温めているところです。

- ちなみに、ZEST BOARDの由来は?

チームで話し合っていた時にいくつか候補があって。その中から一番しっくり来たものを選びました。

- 今後こうしていきたい、といったものはありますか?

実はお客様から利用申し込みがあった時の初期設定には改善の余地があるんです。ひとつのURLで、招待されたアカウントによって画面を出し分ける形でできるといいなと思っています。絶対そうしたい(笑)。

お客様の反響とメッセージ

- お客様からの反響を聞いてどう思いますか?

素直に、すごくありがたいです。リリースしてすぐに依頼がたくさん来て嬉しかったです。嬉しい反面、変なバグがないかハラハラしてしまうところもありますが…(笑)。

- 最後に、ZEST BOARDをご利用中のお客様へのメッセージをどうぞ!

ご利用いただき、ありがとうございます。期待に応えられるよう、より進化を続けていきたいです。ZEST BOARDが良くなれば、お客様も良くなる循環が描けると思うので、ぜひ一緒にがんばっていけたらと思います!

最後に

いかがだったでしょうか?在宅医療・介護業界は人材不足が叫ばれ、生産性を高めようにも課題も山積みです。顧客は、「人」にしかできない医療・介護サービスを提供する方々。だからこそ、システムが代われる業務はどんどん手放していただき、「利用者を護りたい」という想いを叶えるお手伝いができたらと思います。