実はPWAを選んだ記憶がない
第1話を書き終えてから、自分でふと考えた。
「そういえば、なぜPWAだったんだろう?」
答えに詰まった。本当に分からなかったからだ。
振り返ってみると、PWAを選んだ記憶がない。Reactを選んだ記憶もないし、IndexedDBを選んだ記憶もない。
2026年2月4日 02:58。
最初にあったのはExcelの計算シートだった。それをClaudeに渡して、こう聞いた。
「ロジックはそのままにしてWebツールに変換できますか?」
これが全ての始まりだった。その時点で、私はPWAという言葉すら知らなかった。
35分後の03:33。動いたコードをブラウザで開いた後、すぐに次の言葉を返していた。
「投与量(mL)を視覚的に見やすくしてください」
動いただけでは満足できなかった。現場で見づらかったら使われないからだ。
その後、動物種が増えるとコードが重くなった。データを保存したくなった。院内のWi-Fiが不安定なので、オフラインでも動いてほしくなった。
「こんな感じで使う」
「こうしたい」
「そうじゃない」
「こうして」
「まだまだ」
「そうそう、それだよそれ」
「いいね」
その都度、目の前の問題を泥臭く直した。
気づいたら、PWAになっていた。
「なぜPWAだったんですか?」という質問に答えられなかったのは当然だった。私はPWAを選んだ記憶がない。次々に現れた問題を潰していった結果、最後に残っていたのがPWAだった。
少なくとも、その時の私はそう理解していた。
最初に決まっていたのは「現場要件」だった
院内Wi-Fiを使えるとは限らない。
というより、大体電波悪いに決まってる。
ノートパソコンを持っているスタッフもほとんどいない。看護師さんが普段持っているのはスマホくらいだというのも知っている。
その場ですぐ使えるものといえば、計算機か、自分の「勘ピューター」くらいなものだった。
メモしながら計算する。筆算する。
「ほんとにこれで合ってるか?」
救急対応中や手術中、クリティカルな場面で毎回そう自分に問い直し、変な汗をかきたくなかった。スマートにやるべきことは他にもたくさんある。計算機と勘に頼っている時間は、本来そこに使うべきではない。
インストールが必要なソフトという選択肢も現実的ではなかった。パッケージ化して配布して、設定して、という手間をかける時間もない。そこまでガチのソフトを作ることも、当時の自分にはできなかった。そもそも使う側にそこまでのITリテラシーを前提にできない。
使うからには、しっかり動いてなんぼ。見やすくてなんぼ。邪魔な広告が見えたら、本当にキレる。
- スマホで動くこと
- オフラインでも止まらないこと
- インストールという壁がないこと
技術選定の前に、先に決まっていたのはこっちだった。
GAS世界線は実在した
「気づいたらPWAになっていた」と書くと、最初からPWAを目指していたように聞こえるかもしれない。
実際には違う。当時はGoogle Apps Script(GAS)で公開する方法も試していた。
2026年3月13日には「Google Apps Scriptで公開できないか」を検討し、翌3月14日には実際にデプロイして動作確認まで行っている。
つまり、GAS世界線は実在した。
最初は順調だった。画面が表示される。計算も動く。
ところが機能を増やしていくと違和感が出始めた。当時のログにはこう残っている。
「オッケー、戻れるようになった。だがしかし、重い。これはgasの仕様か・・・。」
その時点では原因は分からなかった。
後から調べていくと、薬剤データを含むHTML(当時13,000行規模)を毎回サーバー側で展開していたことや、GASのCacheService上限(100KB)を超えていてキャッシュが効いていなかったことなど、複数の要因が絡んでいた。
重要だったのは技術的な詳細よりも、その時の判断だった。私はGASに強いこだわりがあったわけではない。現場で安定して動いてほしかっただけだ。
だから原因を追及した結果、「GASで頑張る」よりも「別の方法を探す」方を選んだ。
振り返ると、この時点ですでに技術選定ではなく、現場要件が意思決定を支配していた。
自分で技術選定した感覚はない
データや機能を分けて管理した方がいいという話は、開発の早い段階から出ていた。CRIの計算はすでに別のHTMLファイルとして動いていたし、GASを試したのもその延長線だった。
ただ、素人がアプリを作って配るとなると、考えることが一気に増える。アプリストアにリリースするには、こちらの負担が先に来る。そこまで必要なのか? そもそも自分で使えればいい話で、院内で使える程度にとどめるのが現実的だった。サポートやクレーム対応で消耗するのも嫌だった。
それでも最終的にGitHubでの公開に踏み切ったのは、「GitHubに上げてリリースするにはどうしたらいいか」と聞いたところから、話が分岐していっただけだ。
薬剤データとコードでライセンスを分けたのも、設計判断ではない。「薬剤データを公開して、まずいことにならないか」と聞いたら、コードと分けて扱う方法を提案された。それだけだった。
AIだのAPIだの、それっぽい構成も検討はした。だが当時の自分の力では現実的に無理だった。
振り返ると、自分でPWAを選んだという感覚はあまりない。現場の要件に押され、AIに次の一手を提案され、その都度試していただけだ。
「GitHubに上げて公開するにはどうしたらいい?」
その問いから枝分かれを繰り返した結果、最後に残っていたのがPWAだった。
獣医師はまず検査結果を疑う
公開後、GitHub Trafficを眺めていて最初に出た感想は「何が起きているのか、正直よくわからない」だった。
「14日間で425 Views、35 Unique Visitors。そしてもう一つの数字、310 Unique Cloners。」
クローンしてまで見たいものなのか? 一瞬そう思いかけて、すぐに頭の中で別の声がした。
「310人もいるわけねーだろ。」
これは特定の誰か、あるいは何かが繰り返しアクセスしているだけではないか。
ここで臨床現場の癖が出た。私は検査結果に異常値が出たとき、すぐには結論を出さない。ASTが極端に高ければ測定条件や溶血を確認するし、血小板が異常に低ければ凝集を疑う。35人しか訪れていないのに310人がcloneしたという数字も、同じように疑ってかかるべきものだった。
そこでclone数ではなく、Popular Contentを見直した。
app_main.jscommitssrcツリー
Popular Contentを見直すと、少なくとも薬剤データそのものよりも、ロジックや実装に関するページのほうが多く閲覧されていた。
私は薬用量計算を必要とする獣医師が主な利用者になると思っていた。
しかしGitHub上で観測できた範囲では、「どう使うか」よりも「どう作ったか」に興味を持つ人の存在のほうが目立って見えた。
クローン数から始まった違和感は、結局別の発見にたどり着いた。
公開後もまた、予想していた場所には答えがなかった。
作る前も、作った後も、ボトルネックは予想した場所にはなかった
Excelから始まった開発では、技術がボトルネックだと思っていた。
しかし実際には、現場要件の整理がボトルネックだった。
公開後は利用者が来ると思っていた。
しかし実際には、コードやコミット履歴を見に来る人たちが目立った。
振り返ると、この4か月で何度も同じことが起きていた。
作る前も、作った後も、ボトルネックは予想した場所にはなかった。
今でもReactとPWAの違いを説明しろと言われたら困る。
でも、院内の電波が悪いことは知っている。看護師さんがスマホしか持っていないことも知っている。CRI計算で変な汗をかきたくないことも知っている。
だから、その問題を一つずつ潰していった。結果としてPWAになった。
後から振り返ると、それを世の中では「技術選定」と呼ぶらしい。
私は技術を選んだ記憶がない。
ただ、動くまでやった。