「待つこと」は、今や通院する人にとって避けられない重荷となっているようです。医療従事者もまた、使い勝手のよくない現行の予約受付システムと患者対応の板挟みになり、心身ともに疲弊することが少なくありません。

「私は子どもの頃から“プロの患者”でした。もっと良い解決策があるはずだと信じていました」と語るのは、家昱家チームの共同創業者であり、新しい予約受付システム立ち上げの推進役である彭昱融（Hugo）氏です。

「診察の体験は、予約しようとしたその瞬間から始まっています」。家昱家チームの創業者である彭昱融氏と、プライマリケアのクリニックで7年以上勤務し、長年にわたり現場を見つめてきた郭家穎医師は、通院体験は診察時に始まるのではなく、なんとなく不調を自覚し、予約を決めたその瞬間から始まるべきだと考えています。

長年の起業経験と起業支援の経験を持つ家昱家チームの共同創業者、彭昱融氏と郭家穎医師は、デザイン思考を取り入れました。デザインワークショップやサービスデザイン、医療従事者や郭医師が長年診てきた多くの患者への定性・定量インタビュー、さらにチーム自身と支援者である医師のエンジェル株主たちによる各クリニックでの長年の経験に基づくフィードバックを重ね、フロントエンドのUI/UX専門チームによる長期にわたる設計と検証も組み合わせました。試行錯誤を重ねながら前進し、紹介を通じてついに専門的で安定した開発力を持つ5xRuby（五倍紅寶石）と出会います。そして課題を解決するResonance予約受付システムを共に作り上げ、まずは自ら創業した交感心身クリニックに導入しました。患者により良い予約・受診体験を提供することを目指し、開業から半年で延べ2,500人の利用による検証を積み上げています。

大きい =\= 良い、チームのニーズを理解することこそが鍵

「5xRubyのソフトウェア開発チームと出会う前に、私たちはすでに多くの技術チームと話をしていました。100人を超える大規模な国際的システムインテグレーターも含めてです」と、家昱家および交感心身クリニックの共同創業者の一人であるHugo氏は苦笑しながら語ります。

「でも私たちが求めていたのは、本当のニーズ（Job to be done）を理解してくれるチームでした。大きいことが必ずしも良いとは限りません。むしろ中小規模のチームが提供できる柔軟性や機動力こそ、私たちが求めていたものでした」

SaaSサービスのMVP段階では、スタートアップはまず“乗れるスケートボード”を作り、素早く市場に投入し、迅速に検証と改善を繰り返す必要があります。Hugo氏は、5xRubyとの最初の打ち合わせの段階から、MVPに対する理解とチームの柔軟性が他社を大きく上回っていると感じたといいます。

スタートアップと一般企業の違いを理解し、スタートアップの事業計画に合った行動のリズムを提供できること。それが、家昱家が5xRubyを選んだ重要な理由の一つです。

臨機応変な対応で、不可能なスケジュールを可能に

スタートアップの差し迫ったスケジュールに応えるため、5xRubyは最初の打ち合わせの段階からTech Leadを参加させました。依頼を受けた時点で、重要なマイルストーンの検収まで残りわずか2か月あまり。さらに本プロジェクトには3つのチームが関わっていました。UI/UXの専門家である「遊石設計」、MVPのシステム分析を担当するMXIチーム、そしてその後のSA、データ構造設計、開発、デプロイを引き継ぐ5xRubyチームです。弊社からはCEOの慕凡が自ら最大10名の開発チームを率いて開発に全力を注ぎ、自身もシステムアーキテクトとして、20年以上にわたるシステム開発経験を活かし、複雑なシステム設計を手がけました。

受付の現場には多くの複雑な要件があり、そのすべてをシステム設計の段階で考慮しなければなりません。システムが発行する診察番号は現場の状況に応じて4つのタイプに分かれ、どの番号も必ずいずれか一つのタイプに属し、「タイプ指定なし」は存在しません。空き枠の有無を判断する際も、異なる時間軸を掛け合わせて考えなければ、システムの判断が困難になってしまいます。そのため、各診療枠や診察番号の状態を判断するには非常に多くの要素を考慮する必要があり、その過程で業界知識を補うことも欠かせませんでした。

だからこそ、要件に関するすべての議論には、プロジェクトマネージャーのWinnieだけでなく、メインのシステムアーキテクトである慕凡も自ら参加しました。それによって、デザインカンプを受け取ってからシステム設計、開発、初版リリース、さらには単体テストまでを2か月以内で完了させるという、驚くべき成果を実現できたのです。

高効率な協業の秘訣はコミュニケーション管理

第1フェーズでチームが焦点を当てたのは、心療内科・精神科における窓口受付の課題の解決でした。診療科の特性上、ユーザーが予約を変更する際には、診療科、診療区分、時間帯、日付という4つ以上の変数が関わります。それぞれの変数は、残りの3つの変数に応じて判断され、変化します。さらに、診療が行われているか、予約が可能かどうかも別途判断が必要です。こうした変数が生み出すさまざまな状況を整理し、理解したうえで分解・再構成するには、非常に明晰なロジックが求められます。

- 開発前に徹底的に理解する

利用シナリオが非常に複雑であったため、5xRubyは図解を用いてPMとシナリオを確認し、操作フローを明確にしたうえで、スケジュールに基づいて実装すべき機能の優先順位を決定しました。

- 実装時の透明なコミュニケーション

当初のSAは、他社のSAが一部を完成させた後に5xRubyチームへ引き継がれたものでした。5xRubyのプロジェクトマネージャーWinnieは遊石設計と共にすべての仕様を統合し、指定された検収スケジュール内で最も実現可能な規模へと絞り込みました。

3者とも初めての協業であり、チーム間のコミュニケーションのペースを揃えることに加え、それぞれの専門性に基づく考慮点も少しずつ異なるため、すり合わせには多くの労力を費やしました。Slackでのリアルタイムな議論に加え、毎週定例会議を開いて進捗を確認し、かんばんツールを活用してタスクの状況を共有するなど、オープンで透明性の高い協業によって認識のずれを防ぎました。

経験と技術力の掛け合わせで、より良い解決策を提案

台湾で最もMVP開発の経験が豊富なチームの一つとして、5xRubyにはより良い解決策を提案する責任があります。課題に直面したとき、お客様はご自身で望む解決策をお持ちかもしれません。しかし5xRubyは、全体のアーキテクチャ設計や利用ロジック、データ設計を優先的に考慮し、「まず要件の背景にある理由を確認し、それから解決策を提案する」という方針を取っています。これにより、「期待に応えるためだけで、最善の方法ではない」という状況を避け、プログラムやデータに不合理なロジックが生まれ、プロダクトにリスクをもたらすことを防いでいます。

第1フェーズで5xRubyチームが採用した技術的な解決策は以下のとおりです。

- フロントエンド：Hotwire

複雑なフロントエンドのUIインタラクションを、バックエンドの手法で実現しました。

- データベース：PostgreSQL

医療スタッフのフロントエンドでの操作体験に関するニーズに応えるため、PostgreSQLの「連続した順序付きデータ」を生成する機能を採用しました。たとえば1/1〜1/31までの日付の連続データを生成することで、ユーザーはデータベースへのクエリによって、その週やその月にどのようなイベントがあるかを、まるで本物のカレンダーのように簡単に把握できます。

より適した開発ツールを選ぶ

診療のニーズに応じて、多くの項目で特製の「フォームのようなもの」が必要でした。5xRubyはさまざまな解決策を比較検討したうえで最適なツールを選び、全体の開発効率を高め、開発の難易度を下げました。

たとえば、ある診療枠の診察番号の数を設定する際には、診察番号ごとに「さらに」タイプを設定する必要があります。従来は取得する要素をすべて個別に記述する必要がありましたが、今回の開発ではStimulus JSを採用することで、必要な対象だけに絞って素早く実装でき、機能も目的ごとにきちんと分かれているため、開発時にもひと目で把握できました。

対象クリニックの診療ニーズに合わせて、システムには多くの特殊な機能が求められましたが、再利用可能な要素を使うことで開発時間を大幅に節約できました。たとえばドロップダウンメニューは、テンプレートを一つ作るだけでさまざまな場面で幅広く使い回すことができ、活用の幅が広がります。

次の挑戦へ

ジェットコースターのようにスピーディーで目まぐるしかった開発期間を振り返り、Hugo氏は深い感謝とともにこう語ります。「5xRubyのチームは、いつも技術の長所と短所を評価し、私たちにわかりやすく分析してくれました。開発の進捗も透明で確実で、とても実務的なチームです。本当に何かを成し遂げたい、この業界の何かを変えたいと思っているなら、心から5xRubyとの協業をおすすめします」

予約受付システムは初版リリース後、ユーザーの増加とともにユースケースがより多くの患者や医療スタッフによって検証され、次の段階である最適化とパフォーマンス向上という挑戦に入っています。

あなたも素晴らしいソフトウェアのアイデアをお持ちで、それを実現しようと決意されていますか？ぜひ5xRubyのソフトウェア開発チームまでご連絡ください。私たちの技術力で、プロダクトづくりを共にお手伝いします。