医療系サイト制作で苦労したこと

構想を実際に動くサービスにするには、たくさんの壁がありました。今日は、メドパスを開発するなかで特に苦労したことを、技術面を中心に振り返ります。

React と Next.js を選んだ理由

メドパスは React と Next.js（App Router）で作っています。この組み合わせを選んだのは、いくつかの理由があります。

• ページごとに最適な描画方法（静的・サーバー・クライアント）を選べる
• 検索エンジンに見つけてもらいやすい構成にしやすい
• コンポーネント単位で UI を組み立てられ、改善を重ねやすい

特に医療情報を扱うサービスでは、検索から来た人にきちんと届くことが大切です。そのため、表示速度と検索エンジン対応（SEO）を両立できる構成を最優先に考えました。

いちばんの難所は「症状データの整理」

技術的に最も苦労したのは、実はコードそのものよりもデータの設計でした。

症状と診療科の関係は、きれいな一対一ではありません。

1. ひとつの症状が、複数の科にまたがる
2. 言い方が人によって違う（「お腹が痛い」「腹痛」「胃が痛い」）
3. 部位や状況によって、案内すべき科が変わる

これをそのまま扱うと、案内がぶれてしまいます。そこで、症状をキーワードと同義語の集合として整理し、部位や組み合わせから候補を導く仕組みを作りました。地道な作業でしたが、ここがサービスの心臓部です。

正確さは、派手な機能ではなく、こうした地味なデータ整理から生まれる。

開発を通じて、何度もこの言葉を噛みしめました。

「診断に見えない」ための工夫

医療系サービスで最も気をつけたのが、診断と誤解されないことです。便利にしようとするほど、「これは病名を当ててくれるのでは」と受け取られる危険があります。

そこで、

• 表現はすべて「受診の目安」「案内されやすい科」に統一
• 断定を避け、最終判断は医療機関に委ねる文言を随所に配置
• 緊急性が高い症状には、ためらわず受診を促す注意書きを表示

といった配慮を、UI の隅々まで行き渡らせました。機能の追加よりも、言葉づかいの設計に時間をかけたと言ってもいいくらいです。

UI改善は、終わりのない作業

最初に作った画面は、自分では分かりやすいつもりでも、いざ人に見てもらうと「どこを押せばいいか分からない」と言われました。

• ボタンの位置と大きさ
• 一画面に出す情報の量
• スマートフォンでの押しやすさ

こうした点を、少しずつ調整し続けました。UI は「完成」がなく、使う人の反応を見ながら育てていくものだと実感しています。

苦労の先にあるもの

技術的な壁にぶつかるたびに、立ち返ったのは「誰のためのサービスか」という問いでした。迷っている人が、迷わずに次の一歩を踏み出せること。その一点に照らせば、どこに力を注ぐべきかは自然と見えてきます。

次回は、こうした苦労を経て、メドパスを公開するまでの道のりについて書きます。