開発環境のUPDATEと開発を進めて、やっと少しめどがついてきました。
HTML/CSSではまだ少し面倒な問題が残っていますが、私はそもそもデザイナーではないので、このあたりはあまり得意な分野ではありません。
ひとまず、自分のサイトでは堂々と1.0.1β版に差し替えてみました。
コードについてはもう少しだけ修正するところがありますが、一区切りついたので、ここからドキュメントの更新に移ろうと思います。
API.md
SPEC.md
README.md
UPDATING
今回の1.0.1β版では、訪問施術料1～訪問施術料5の一覧表を追加し、それに伴う呼び出し関数も追加しました。
一つの建物に何人施術に訪れているのか。
この人数を訪問施術料を表示させる仕組みです。
訪問施術料というもの
この仕組みをコードにしながら、あらためて考えていたことがあります。
これは、私がサラリーマン訪問マッサージ師だった頃に、実際の現場で経験してきたこととも関係しています。
制度が想定していた医療・施術者側の負担。
それが現場では「足代」のように理解される。
さらに、それが経営上の収益要素として扱われる。
その結果、現場の運用が変わる。
そして制度側が、またルールを変更する。
こういう循環が、訪問施術に関する制度の変化の一つの側面としてあるように思います。
もちろん、制度そのものには制度を作る側の事情があります。
例えば、訪問看護の制度を参考にしているという話もあります。
こう考えていくと、単純に「料金がいくらになった」という話だけではなく、
制度と経営の政治
という問題が見えてきます。
「足代」から経営の要素へ
往療に関する料金も、もともとの意味を考えると少し違った景色が見えてきます。
往診料というものは、医療機関や医師が本来の診療場所を離れて患者のところへ赴くことによって生じる負担やリスクに対する対価として考えられたようです。
ところが、訪問を専業とする経営形態では、そもそも「院を閉じて往診する」という状況とは違います。
それでも同じような訪問に対する料金が存在する。
そうなると、その料金が経営上どのように扱われるのかという問題が出てきます。
このあたりは20世紀末頃から制度上も見直されてきた問題で、訪問施術をめぐる制度が単純な「足代」の話ではないことが分かります。
そして、実際の現場では、もっと具体的な問題が出てきます。
例えば、一つの家に複数の家族がいて、それぞれ施術する場合。
誰に往療に関する料金を付けるのか。
利用する側からすれば、当然「安い方がいい」という感覚もあります。
そうなると、どの人に付けるのかという判断自体が、現実の問題にです。
制度を使って施術を提供する以上、現場はその制度のルールから自由ではいられません。利用者にとって安い方を選びたいという事情があっても、施術者側は制度上の区分や算定条件に従って判断しなければならない。
つまり、制度を利用することで負担を軽減できる一方、その制度に定められた運用にも拘束されるのが現実です。
ただし、現場のサラリーマン施術者が、その運用に対して自由に意見を述べたり、異議を唱えたりできるとは限りません。
雇用主と使用人という関係の中では、経営者が決めた運用に口を出すこと自体が許されない場合があります。
制度上問題があると分かっていても、雇用されている側には、それに抵抗できない現実があります。
「片棒を担がされる」という現実が、そこにはありました。
むしろ、分かっていても、仕事を続けるために従わざるを得ない。
それがサラリーマンとして現場にいるということです。
さらに、一つの施設などへ別の場所を挟んで何度も往復することで、訪問に関する料金を重複して得るような運用も、顕在化していったと考えられます。
制度からすれば、不必要な出費は抑えたいという政治が働くのは当然だと思います。
そこで、一つの建物について何人訪問するのかを基準として、訪問施術料を変える仕組みが導入されていきました。
今回1.0.1β版で追加した訪問施術料一覧表は、すでにコード化されていた制度を、「訪問施術料1～5」の一覧表として視覚化したものです。
制度をコードにすると見えてくるもの
こういう制度をプログラムにすると、面白いことがあります。
文章で読んでいると、
「こういう場合はこうなる」
で済ませられることでも、プログラムにするには条件を明確にしなければなりません。
何人なのか。
どの条件なのか。
どの料金になるのか。
例外はあるのか。
人間なら曖昧なまま扱えるところでも、プログラムは曖昧なままでは動きません。
今回も、単に「訪問人数を入力して料金を変える」というだけではなく、その背景にある制度の考え方まで考えざるえませんでした。
そして、それが自分自身が現場で経験してきたことともつながっていきました。
令和4年の負担割合の変更から始まった
そもそも、このシミュレーターを作る構想が生まれたきっかけの一つは、高齢者の窓口負担割合の変更でした。
これまでホームページや手持ちの資料に掲載していた「1割負担」の一部負担金表だけでは対応できなくなりました。
1割だけではなく、
1割
2割
3割
を考えなければならない。
制度が変われば、料金表も作り直さなければならない。
それなら、固定された料金表を作るのではなく、条件を選べば自動的に計算されるようにすればいい。
そこから始まったのが、このシミュレーターです。
ただ、構想ができたからといって、すぐに形になったわけではありません。
実際に動くものになってきたのは、それからおよそ3年後でした。
ソフトウェアの公開するにあたり
そして、実際に形になってくると、今度は別の問題が出てきました。
せっかく作ったのだから、自分だけで使うのではなく、OSSを参考にした形でソフトウェアとして公開してしまおうかと考えてました。
そうなると、今度はライセンスを考えなければなりません。
AGPLを筆頭に、GPL、BSD、MIT、BSLなどをあらためて読み直しました。
なぜ、単に既存のライセンスを選ぶのではなく、PLSLというものを考えることになったのか。
これも、今回のシミュレーターを作った経緯と切り離せない話です。
「制度と経営の政治」という問題は、このプログラムそのものが生まれた背景でもあり、後にPLSLを考えることになった理由にもつながっています。
そのあたりは、もう少し開発が落ち着いてから、あらためて書こうと思います。
まずは1.0.1β版。
ここから、実際のコードとドキュメントを整理していきます。
