連載現場発,病院と患者のためのシステム連載現場発,病院と患者のためのシステムExcelのマクロが組め(作れ),Accessも使いこなせるし,インターネットを駆使して情報を入手し,適宜編集して利用することもできる…20年以上前の大型汎用コンピュータの時代に非専門家の登場と問題杉浦和史*は,専門的な教育を受けた者にしかできなかったことが,今や簡単なシステムなら,非専門家だった者が作ってしまう時代になりました.専門家ではじめに手軽に購入できるようになったパソコンを使い,試行錯誤と経験で知識を得た一家言もっている医師はじめ医療従事者はたくさんいます.これらの方々が,新しい製品や環境が発表されると直ちに製品を購入して使い勝手を確かめ,実務に応用してしまうことは,それほど珍しはない現場の者が直接システムに関与することをEUC(EndUserComputing)といいますが,医療機関でのEUCとその問題につき簡単に説明します.いことではない時代です.20年以上前の大型汎用コンピュータ時代に専門的な教育を受けた昔の技術者が,「じっくり考えて」「機能解説書を読んで」などといっているうちに,試行錯誤しながらアッという間に使いこなしてしまう非専門家は確実に増えています.EUCが進めば,欲しい機能を手に入れるまでの時間が大幅に短縮され,実務に基づいているので,使いやすい機能,操作性に優れていることは容易に想像できます.しかし,良いことばかりではなく,問題もあります.代表的なものを3つあげます.①全体を見据えていない.②信頼性,品質,性能への関心が希薄.③保守性,拡張性を考慮しない.それぞれにつき,簡単に説明します..全体を見据えていない“群盲,象を撫でる”というインドの寓話があります.目の不自由な者が何人かで象を撫で,それぞれ撫でた部分の感想を述べるというものです.牙を触った人は,堅い細長いもの,鼻を触った人はグニャグニャした長いものというでしょう.尻尾を触った人は,綱のようなものというに違いなく,結局,触ったものが象であることは誰にもわかりません.象に関する説明をし,特徴を理解してもらったうえで,牙はここ,鼻はここ,という説明を受ければ,眼が不自由でも理解できたでしょう.システムも同じです.何を作ろうとしているのかの全体像(最終形)を理解せず,牙,鼻,尻尾,足や耳に相当す(81)0910-1810/14/\100/頁/JCOPYる部門のシステムを作っても,部門間の機能の連携がわからず,情報の授受もわからず,システム全体として不整合なものができあがってしまう怖れがあります.最初に手をつけるべきは,院内業務をシステムに載せるための一環した方針を作り,最終形を描くことです.つぎに,この方針をスタッフに強制するのではなく自発的に理解してもらいます.周知された後,非専門家だがパソコンに習熟している者なら対応可能な範囲の機能を切り出せば,その部分をシステム化しても問題ないでしょう.しかし,院内全業務をカバーするシステムにチャレンジするのは止めましょう.考慮する幅と深さが違います..信頼性,品質,性能への関心が希薄1.信頼性一言でいえば,“動けば完成”と考えるのは危ない,ということです.自分の守備範囲の作業効率化(PersonalAutomation:PA)や,トラブル発生時に影響を受ける範囲が限られた業務,作業であり,代替え手段がある場合には,それほど気にしなくても良いかも知れません.しかし,対象が基幹業務だった場合には,トラブル発生で病院の業務が止まってしまいます.今や,24時間365日稼働するシステムは特別なケースではなくなって*KazushiSugiura:宮田眼科病院CIO/技術士(情報工学部門)あたらしい眼科Vol.31,No.1,201481いますが,相互に正しく動いていることを前提としているなか,おかしくなったら最初(再起動)から,という発想は危険です.立ち上げ中は,そのシステムとの間で情報授受ができなくなり,玉突き衝突的に不具合が連鎖し,システム全体が止まってしまいます.しかし,パソコン黎明期には再起動して最初からやり直せば済むという考え方が普通でした.パソコンが独立して使われるスタンドアロンの使い方なら構いませんが,相互に連携して動く規模の大きなシステムの場合には,この発想は危険です.2.品質品質を保証するためには,適当にピックアップしたいくつかのケースでテストするのではなく,処理の対象となる業務,作業で起こりえるすべてのケースでテストをしなければなりません.テスト漏れがないよう,テスト項目を洗い出し,テストの方法を含めてのレビューも必要になります.テストの方法とは,環境も含め,その方法でテストしたことになるかどうかということです.3.性能性能(レスポンス)は見落としがちな点ですが,とても重要な要素です.検査結果,所見,処方指示などのデータがあるサーバにアクセスが集中する場合を考えてみましょう.コンピュータ,記憶装置などは一度に多くの要求を処理しているようにみえるものの,顕微鏡的にみれば,瞬間的には1つの処理しかしていません.パソコンからの処理要求は,処理の順番がくるまで待ち,行列のなかで待たされます.しかし,超高速で処理されるため,あたかも一度に多くの要求が処理されているようにみえるだけです.サーバを参照したり書き込んだりするパソコンの台数が増えれば,必然的に処理要求数が増えます.その分,待ち行列の長さが長くなり,順番が回ってくるのが遅くなる=レスポンスに影響が出るということです.システム化対象業務を増やしたり,パソコンを増やしたら,レスポンスが悪くなった例はよく聞きますが,性能に関する基本的な知識を身につけ,気にする習慣をつけていれば大事には至りません..保守性,拡張性を考慮しないシステムを設計する際には,今後変わるかもしれない要素を考慮しなければなりません.例えば,保険請求,82あたらしい眼科Vol.31,No.1,2014薬剤処方,用法用量の規則です.これらは変化があることを前提とした作り方になっていなければなりません.医師はじめスタッフも追加・削除・変更ができるようになっていないと,採用,退職に対応できません.消費税が8%,10%に引き上げられることが決まりました.竹下内閣のときに導入されたこの消費税,最初は3%でした.橋本内閣のときに5%に上がりましたが,この税率を固定にしたプログラムの作り方にしてしまうと,変更のあった都度,関係する個所を直さなければなりません.これを売価×aのように,消費税率をパラメタaにしておき,aの値を変えることで関係するすべての該当個所が間違いなく更新されるよう,プログラムすべきです.これはプログラミングの基礎で教えてもらうことですが,この辺の気配りが,非専門家と一連の系統だった教育を受けた者との違いになって現れます.また,眼科は検査の種類が多いことで知られていますが,新しい検査機器が増設されたときのサポート手順も決めておかなければ,検査結果をシステムに取り込めるようになるまでに時間を要してしまいます.この辺の配慮も,訓練を受け,実戦経験をした者と,そうではないパソコン操作が長じた非専門家とでは,違いがでてくるところです..その他システム化対象業務,作業はBPR(業務改革)が実施されていることが望ましいのはいうまでもありません.非専門家にとっては日常的にやっている業務を根本から見直すなどということは,なかなかできませんが,システム化の前に行うことが望ましいことはいうまでもありません.例外処理はBPRの対象として適しているというのが過去の経験です.往々にして,無理無駄の宝庫であり,トラブルの発生源になっていますが,例外処理が腕の見せ所だったベテランは,その価値を失うことを怖れるかも知れません.しかし,仕事の属人性を解消するためには必要なことと理解しなければなりません.例外処理が少なくなれば,プログラムは作りやすくなり,テストもしやすくなり,システムの品質向上が期待できます.手間を要す例外処理がなくなれば,作業の品質も上がるはずです.(82)