ボタンとアクションは違います
第2部で私たちはオントロジーをオブジェクトと関係で描きました。何があり、それらがどう絡んでいるか。しかしまだ立てていない軸が一つ残っています。アクション(Action)です。
オブジェクトと関係が「何があり、どうつながっているか」を語るなら、アクションは「では何をするか」を語ります。普通のITシステムでは、行動はデータの外側にあります。ボタンは画面のどこかにあり、そのボタンがすることはプログラムコードの中に散らばっています。誰がなぜ押したのか、何が変わったのかは、どこにもまとまって残りません。行動とデータが別々に動くのです。
オントロジーはこの行動を構造の中に取り込みます。だから私たちにとってアクションは単なる機能ボタンではありません。誰が、いつ、どんな理由で何をし、それによって何がどう変わったかがそのまま残る行為です。アクションは実行された瞬間に一つの記録となり、その記録には必ず主体が残ります。
アクションが答えなければならない三つの問い
アクションを設計するということは、病院のすべての仕事について次の三つの問いにいつでも答えられるようにするという意味です。
- 今これはどんな状態か。
- この状態でできることは何か。
- その仕事の責任は誰にあるか。
単純に見えますが、今、院長先生の病院でこの三つに即答できる業務がどれほどあるかを思い浮かべると、この問いの重みが伝わってくるはずです。この三つに答えられないデータはどれだけ積んでも報告用の数字にとどまり、答えられるデータだけが運営の言葉になります。第2部で作った知の構造が、第3部でアクションと出会わなければならない理由がここにあります。
世界の最前線が至った同じ結論
興味深いことに、世界で最も進んだ運営プラットフォームとされるPalantir Foundryも同じ結論に至りました。彼らは「データを設計するというより、アクションを設計すると言う方が正確だ」と語ります。データは行動を説明するために、行動は責任を残すために存在するというのです。
彼らはもう一つ言います。こういう構造は技術チームや外部コンサルタントが代わりに描いてくれるものではなく、実際の現場で無数の決定を下してきた人だけが描けると。だから彼らはエンジニアを顧客の現場に常駐させることで知られています。
私たちはさらに一歩内側にいます。私たちは現場に派遣された会社ではなく、病院運営を直接担う現場そのものです。8年間、MSOとして病院を運営し、決定を下す人と構造を作る人が、私たちの中で同じ人でした。世界が理論と派遣で辿り着こうとしている場所を、私たちは毎日の運営で生きてきたのです。
「みんなそうしてきた」が消えます
アクション構造が病院にもたらす最大の変化は、意外にも言葉遣いの変化です。
問題が起きたとき、病院の会議室でよく交わされる言葉があります。「私は伝えられたとおりにやっただけです。」「元々みんなそうしてきました。」「それは私たちのパートの仕事ではありません。」これらが悪い職員の言葉ではないことを院長先生はご存じでしょう。誰が何をしたかがどこにも残らない構造では、真面目な職員でさえこう言うほかありません。
すべての行動に主体と時刻と根拠が残る瞬間、これらの言葉は居場所を失います。代わりに記録が語ります。その日何時に誰がどの状態を見て何を実行したかがそのままあるので、責任を争うことに使う時間は消え、何を直すかを議論する時間だけが残ります。私たちが運営する病院で責任のなすりつけ合いが短くなったのは、職員の人柄が良くなったからではありません。構造がなすりつけを不要にしたからです。
記録が病院を守ります
そしてこの記録は病院を守ります。
私たちのシステムでは、患者が同意画面で確認を押した瞬間、その時刻がそのまま残ります。案内が出た時刻、患者が応答した時刻、相談者が次の手順に進んだ時刻が、一つの流れとして保存されます。後日、誰も「そんな手順はなかった」とは言えません。行動が記録であり、記録が責任だからです。
院長先生にとってこれが意味することは明確です。病院の一日一日が証跡とともに積まれ、問題が生じる最も痛い瞬間に、病院の側に立ってくれる記録がすでに用意されているということです。
守られるのは病院だけではありません。職員も守られます。手順どおりに正確に働いた職員に、その正確さを証明してくれる記録があることは大きな安心です。記録がない病院では真面目な職員が理不尽な目に遭いやすく、記録がある病院では真面目さがそのまま現れます。良い職員が長く残る病院の条件の一つが、ここで作られます。
アクションは機能ボタンではなく、責任を残す宣言です。そしてその宣言が積み重なって、病院を守ります。