デスマーチなんだろうか?
久しぶりに喧嘩を売ってみる。
♪デスマーチったらチッタカタァ行進だ デスマーチったらチッタカタァ行進だ 新人くん派遣くん かわりばんこ かわりばんこ 吐いて寝込んで チッタカタッタッタァ 病院へ連れて行け チッタカタッタタァ
♪デスマーチったらチッタカタァ行進だ デスマーチったらチッタカタァ行進だ 上司くんシスアドくん ザックザックボッコボッコ ザックザックボッコボッコ
いい音鳴らして チッタカタッタッタァ 病院へ連れて行け チッタカタッタタァ
か か 変わる 仕様書 み み 未曾有の 修羅場 あるのか ないのか なくても あっても おしまいだ
♪デスマーチったらチッタカタァ行進だ デスマーチったらチッタカタァ行進だ マウスくん 端末くん ひだり みぎ ひだり みぎ ０ １ １０ １１ ぼくも倒れて チッタカタッタッタァ 病院へ連れて行け チッタカタッタタァ ……デスマーチのうた。
IT 業界と医療業界
新小児科医のつぶやき - デスマーチ・プロジェクト がずいぶん盛り上がっていて、コメント欄がなぜか富士通叩きでお祭り騒ぎ。
IT業界のお話というのは本当に参考になることばかりで、このblog でもいつも引用させてもらってばかり だけれど、プログラマの人達と、我々医療者とはやっぱり別世界。
- 仕様書は変わらない:糖尿病の人が「やっぱり腕もう1本増やしてよ」なんていわないし、 基本的にはみんな「よくなって、歩いて帰る」のが要求仕様の全て
- カットオーバーがない:プログラムは、動いてみるまで動くかどうか分からない。人体はいつも動きつづけるから、 よくなれば「よくなって」見えるし、進捗状況は一目瞭然。プログラマの業界では「動かないこと」が問題だけれど、 我々の業界は「動くのに帰るところがない」こと
- プロジェクトが複数:1つの大規模プロジェクトでドツボにはまるのがデスマなら、 我々の業界は小規模プロジェクトを複数同時進行するようなもの
Yosyan 先生の引用先 では、「医療全体」をひとつのプロジェクトにたとえていて、これはたしかにデスマーチなのだけれど、 現場で実感しているのはもっとローカルで、切実な問題。
顧客の要求水準は上がってきたけれど、それはまだ十分に予測の範囲だし、 医療者側の技術水準だって、この10年ぐらいでそれなりに向上した。 デスマーチプロジェクトの顧客というのは もっとうんとわがままだから、医療が現状を「顧客」のせいにするのは、まだちょっと甘いと思う。
デスマというよりサーバー負荷の問題
問題が増えてきたのは、単純にお客さんの数が増えたから。
顧客一件一件が医師に要求する処理というのは、決してそんなに大きくなってはいない。 ところがアクセスがよくなって、病院に殺到するお客さんの数が増えてしまったから、 それをこなす「サーバー」たる医師がパンクした。
IT のたとえでいうなら、これはデスマーチではなくて、「C10K問題」。
個々のクライアントがサーバに要求する処理量は小さなもので、 ハードウェアの性能上は問題がないにもかかわらず、 あまりにもクライアントの数が多くなるとサーバがパンクする。
これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）。
手続き型医療の限界
今までの医療というのは、手続き型のやりかた。
人間は、一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する。 「話を聞いて、診察をして、検査をして薬を決めたら伝票を書いて、 あとは3日待ったら検査を再検して」みたいなやりかた。
それぞれのプロジェクト―病名―ごとに手続きはある程度決まっていて、 医師は複数の手続きを頭の中で 同時進行させながら、日常業務をこなしていく。
手続きは日々改良されているけれど、それでもひとつの「流れ」であるという部分は一緒。 人間の頭を駆動するOS はバージョンアップされていないから、 複数のプロジェクトを同時進行で流すと、必ずどこかに無理がくる。
仕事は忙しくなる。それを何とか乗り越えようとして、ガイドラインや新しい教科書が作られて、 医師の負担を減らそうとしてきたけれど、 そうした努力は「手続き駆動型」の枠を出るものではなかったように思う。
人間の脳がこなせるスレッド数には限界がある。手続き駆動型のままで 多すぎるスレッドを同時にこなそうと思ったら、 入力を絞るか、寝ないでがんばるか、どちらか。
医療をデスマーチにたとえる行為は、 たぶんこんな考えかたの延長なんだと思う。
優秀な主婦はイベント・ドリブン方式でパンを焼く
多重処理の問題を解決するひとつの方法が、イベント駆動型のやりかた。
Life is beautiful: 優秀な主婦はイベント・ドリブン（event-driven）方式でパンを焼くに書かれていることが全てだけれど、そのまま引用する。
(パンを焼きながら洗濯をしたり、掃除をしたり…という複数の仕事をこなす主婦の話) 複数の仕事を同時にこなしている彼女たちにしてみると、自分がそれぞれの仕事のどのステップにいるか （つまりcontext）を常に完>璧に把握しておくことは不可能に近い。 手続き型のレシピのままで作業をしようとすると、それぞれの仕事において自分が何をして おくのかを把握しておくだけで頭がパンパンになってしまうし(memory overflow)、 頭の切り替え（context switch）にやたらと時間>がかかって作業効率が落ちてしまうからだ。
解決策として文中で示されているのが、タイマーを使って手続きを分割するやりかた。
そこで、パンの発酵中にはタイマーをしかけておき、タイマーが鳴ったところで 「あ、キッチンでタイマーが鳴ってる。えっと、何のタイマーだっけ。 そうだ、そうだ、パンの二次発酵中だったんだ。じゃ、次はオーブンの温度を上げてと…」 というイベント・ドリブンな仕事のしかたをしているのだ。
言い換えれば、彼女たちの頭の中では、上の「手続き駆動型のレシピ」が、 以下のような「イベントに応じた作業（event handler）」の集まりである 「イベント・ドリブン型のレシピ」に変換されて実行されているのだ。
手続き型の問題解決手法は、スレッド数が増えれば増えるほど切り替えの オーバーヘッドが増えてしまって、どこかで破綻するのが避けられない。
イベント・ドリブン型は、 それぞれの「イベントに応じた作業」が規格化・単純化されてているため、 仕事の量に応じて人を増やすだけで、 スケーラビリティーの問題が発生しないのが最大の利点。
作業の単純化、規格化がなされるならば、次にくるのは分業の可能性。 業務の一部を看護師に委譲するとか、準医師みたいな資格が将来的に できることになっても、規格化さえなされていれば、対応は可能。
医療者側の反省点はひとつ。ベテランの先生がたは、 みんな手続きを洗練することに淫して いただけで、手続き型のプロセスをイベントごとに ブレークダウンする行為を放棄してしまったこと。
忙しい病院の現場では、イベントドリブンで仕事をすることはよくあって、 それは「汚いやりかた」として敬遠されるけれど、案外うまくいく。
ところがベテランの先生方が集まる世界では、汚い物よりきれいなものが好まれるから、 イベントごとに細分化されたやりかたが広まらない。
病院の現場は、ここに来て忙しさが切迫している。多重処理のスケールが大きくなりすぎて、 従来の手続き型のプロセスではいよいよ追いつけなくなったから。
病院の集約化は、たぶん破滅的な結果を招く。
医師が集約すればするほど、どこかにボトルネックを生じる可能性が高くなるし、 手続きの実行待ち時間、検査の予約とか、書類仕事なんかが膨大になって、 集約化に逆比例して仕事の効率が落ちてしまう。
2人集まれば2倍の仕事ができる医師でも、5人集まれば3人分、 10人集まったって5人分の仕事をこなすのがやっと。
手続き型のプロセスの限界から目をそむけて、 集約化に伴う非効率を何とか根性で誤魔化そうとしているのが 今の流れみたいだけれど、手続き型からイベント駆動型へのプロコルの書き換えをやらないで、 集約化なんてできるはずがない。
大学にいた頃、イベント駆動型の内科マニュアルを作って公開したことがあった。
こういう大きなものを作るときは一種の「ハイ」の状態。それこそ、デスマーチの真っ最中みたいな。 「これがウケなきゃウソだ」とか、「俺って天才?」とか思いながら勇躍公開したけれど、 反響はさっぱり。
某FMJ の某氏からは「あんな匿名のマニュアルには何の意味もないですね」なんて メールをもらったりして、「じゃああんたもっといいもの作れよ」とか思ったけれど、結局それっきり。 こういう作業こそは、やっぱりベテラン勢がきっちりやらないと無理。
受診抑制とか、患者教育とかいろんな「解決策」が提案されているみたいだけれど、 あんなの技術者の解答じゃない。医療者側にもまだまだ技術屋として やっていないことがたくさんあって、 それをやらないでIT に学ぶとかいっても、 たぶんデスマってるプログラマの人達は笑うと思う。
臨床の知恵を我々「下々」にブレークダウンして、 診療スタイルを手続き駆動型からイベント駆動型へと変更できるのは、 現場を生き延びてきたベテランの先生方だけ。
JBM とかやってる時間があるなら、 ぜひともベテランの「守りの知恵」と「攻めの技術」を次の世代に伝えて欲しい。
現場はきっと、何よりもそれを望んでいる。
