RubyWorld Conference 2025でお仕事の話をしてきました。
今年は映像配信はなさそうですが、講演資料は多分公式から上がるのではないかと思うので、そちらをお待ちください。
今回は話す内容が多く、デモ2本＋3章分話し切るのに5分ぐらい足りないぐらいという見積もりだったので、時間が足りなかった場合は、後半のデモを飛ばして時間内に話し切るという見積もりだったのですが、思ったよりもゆっくり話し過ぎたみたいで、結局丸々一章飛ばしてしまったのですが、それでも様々な人から多くのフィードバックを頂き、総じて発表してよかったなぁと思います。
今回お話しできなかった部分についても興味を持っていただけた人も結構いたので、その部分についても補足できればと思います。
CFP提出まで
前回RubyWorld Conferenceでお話ししたのは2018年のことだったのですが（その時はmruby/cの話で業務は全然関係なく）、その後転職して、ずっと今のシステムを作っていました。
そもそもリリースまで3年かかったこともあり、中々外に発表する機会もなかったのですが、リリースから更に3年改善を重ねてきて、ようやく外に話せる状態になったかなと思い、申し込みました。こういう業務システムの話をするときに、発表する場所はRubyWorld Conferenceぐらいしかないような気がするんですよね。
なお、CFP作成にあたってはclaudeにひたすら壁打ちしてもらいました。なおAI相手の壁打ちでもRubyの話が少ないというのは散々言われましたｗ
話した内容
6年間やっていることなので、話す内容には困らなかったのですが、話したいことがありすぎて絞り込むのには苦労しました。
ただ、細かいことまで伝えることは絶対不可能なので、分かりやすいデモをしっかりやるということだけは決めていました。発表の冒頭でやったデモは、誰もが経験のある歯科医院の通院経験と歯科医院の裏側をリンクさせたもので、自分が初めて歯科医院の裏側を知った時の驚きポイントをデモに詰め込んでいます。
デモの後、以下の3つを話した（or 話すつもり）でした。
1. 医療会計の複雑さについて
保険会計も自分ぐらいの世代だと3割負担ぐらいしか関わりがなかったりするのですが、日本の保険制度は超複雑で、保険、全国公費、地域公費、高額療養費の組み合わせによっては、負担額が誰にも分からなくなるような事例があるよ、という話がしたかったので入れました。ただ、一番闇深い地域公費の説明をする時間があまりなかったのでカットした都合でちょっとだけトーンダウンしちゃいましたが、複雑さは伝わったのではないかなと思います。
なお、複雑さを語るのにスライドを使いすぎたので、ここを話してる最中に残り7分とかになったのが見えたのは焦りました。
後で他の方と話していた時に、この部分は医科と同じだしカットして、歯科特化の話をすれば良かったですかねー？という話をしたのですが、話してた内容は大分シンプルにまとめられてたし、この闇深い制度を共有するには価値があるとフィードバックを頂けました。（いや、そうなんですよ本当に…）
ここはほぼロジックの話だったので、Rubyの話を半ば強引に入れるためにbitemporalなデータ構造を使っているという話をしたのですが、SmartHRの方々に突き刺さったようで…。向こうもbitemporalなデータ構造の話がここで出てくるとは思わなかったというフィードバックを頂きました。このデータ構造、いい話ばかりではないので、辛みは分かります。
2. 保険医療の複雑さについて
医療会計の複雑さに時間を使いすぎちゃったので、ちょっと焦り気味に話しちゃったのですが（翻訳の方すみません…）診療行為を登録するまでにどういうことをやっているのか、という話をしました。1つ1つ細かく説明していく予定だったのですが、時間がなかったのでざっくりと説明したので、どこまでお話しできたか覚えていないのですが、診療行為一つ一つにチェックルールがあって、月に算定できる回数や、一緒に算定してはいけないもの、事前に算定しておかないといけないものが決まっています。
この部分は厚労省の通達文章に明記しているものはマスタデータとして構造化されてルールベースでチェックされているのですが、明記されていないルールなどもたくさんあります。そういうルールを都度追加していってるんですよ、という話をする予定でした。ちなみに歯科の処置行為は1000種類ぐらいあって、現在そのうちの300種類ぐらいは追加の独自ルールを定義しています。こういうのが診療報酬改定のメンテナンス工数に響いてくるんですよね。
ここで、歯科医院特有の事情として、何故歯科の定期メンテナンスに通うと2回治療することになるのか、何故2回目は次月に回されるのか、という話をしました。
恐らく皆さん経験されたことがあることだと思うので、初めて理由に納得がいったという方も多くいらっしゃいました。（あと、更にその後何故3か月後を目処にまた来てください、と言われるのかという話もあるのですが、それは機械的歯面清掃処置という歯のクリーニング作業が3か月に1回しか算定できないから（糖尿病・妊婦の方は例外あり）なんですよねー…という話をおでん電車の中で話をしました。）
ここではRubyの話として追加・変更・削除に合わせて点数計算や依存関係のチェックなどをActiveRecord callbackに書いていたら複雑すぎて崩壊したので、いわゆるサービスクラス相当であるInteractor gemを使ってシンプルに制御しているという話をしました。あとでジョーカーさんから、サービスクラスの良い使い方と言ってもらえたので、ここは自分もうまく設計できたポイントの一つだったので嬉しかったです。
3. 歯科特有の情報処理について
ここは時間がなくて完全にすっ飛ばしたのですが、実はRoppongi.rbのスポンサードLTの時に1回話していて、その時も評判が良かったので、同じ内容を組み込んでいます。
具体的にどういう話かというと、入力した処置に連動して口腔情報データを書き換えるためにどういうデータ構造にしているかという話で、処置の追加・変更・削除に合わせて、歯を欠損状態にしたり、詰め物を入れたり、歯を分割したり（自分もこの仕事を始めるまで知らなかったのですが、世の中には歯を分割して、残った片側を使うという治療もあるのです。）するという話をするつもりでした。
その場合の指定した日付の口腔情報はどういう状態かを得るためのデータ構造の設計ポイントなどをお話しする予定でした。
これは完全に時間がなくて落としちゃったので、2日目のおでん電車の中で少数の方だけに再演しました。また誰か聞きたいという人がいれば、どこかのコミュニティイベントでします。
これは一部の方にしかお話ししてないのですが、pockeさんからblogでフィードバック貰えました。
2025-11-07 - diary
宿に戻ってから考えたことだけど、自然をモデリングする難しさがあるのかなと考えていた。今まで自分は人工物(レシピだったり、記事だったり、帳簿だったり)を対象としたアプリケーションを書いていた。それらは人間が作り出したものであるから、作られたものには何かしら意図があり、その意図をうまく表現したモデリングが必要である。一方で歯というのは自然に生えてくるものであり、そこに人間が何かしらの意図を持って介入するわけで、後から想定しきれなかった要素が出やすいのではないか、と思考を巡らせていた。全然深く考えてないから人工物かどうかに難しさが本当に関係しているのかはよく分からない。
今回話したシステムって、レセプトコンピューターの側面と電子カルテの側面を両方持っていて、レセプトコンピューターの側面では国に請求するフォーマットに合わせる必要があるので、ある程度規格化されたデータを扱うことになるんですけど、医学的判断みたいなものが伴うと、その規格を無視したデータも生まれるわけで（事前に厚生局に話を通しておくことで、診療として認められるというケースがあります）そういう矛盾したデータをある程度許容するような設計が求められます。データ不整合を防ぐためにガチガチにバリデーションを入れたら、入力できないと怒られることになる…みたいな。
なので、データ構造の設計については、ある程度後戻り可能なデータ構造にして、リリース後に最適を探るということもちょいちょいありますね。
まとめ
発表が終わった後は、レセプションで挨拶回りしたり、二次会でイツメンと飲んでたり、おでん電車乗ったりして、RubyWorld Conferenceをエンジョイしました。
心残りなのは「佐香や」という店が自分が前回松江に来た2018年には存在しなかった概念で、夜な夜なRubyistを集めていたらしく、結局今回は行けずじまいだったので、また次回来た時にでも行ってみたいなと思います。（仕事で松江に来ることが今後増えそうなので、またその時にでも）
総じて色々な方から感想もらえ、また他の方の発表も興味深く聞け、とても楽しい時間を過ごせました。いつもありがとうございます。
10月はこの件含めて、色々な仕事の締め切りを10月末に設定しまったため、非常に多忙だったので、11月・12月はちょっとゆとりのある生活を心がけようかと思います。
またどこかのイベントでお会いしたらよろしくお願いします。
