連載現場発,病院と患者のためのシステム連載現場発,病院と患者のためのシステム病院におけるシステム企画時のチェック項目杉浦和史*.目的は明確か横並び意識,ブームへの付和雷同ではないか?煽るマスコミも悪いと思いますが,付和雷同に乗せられる側も勉強不足です.数少ない成功事例の影に多くの失敗事例があることを知っておいて損はありません.また,その成功は大変な努力の結果であることに思いが至らず,同じ成果が得られると勘違いする安易さが問題です.ブームに迎合したり,開発(導入)ありきで必然性を強調する側の意図を見破れないと,時間とお金をかけて不要不急なシステムを導入してしまうことになります.導入したら経常費がかかることをお忘れなく!.経営幹部は提案を鵜呑みにしていないかバブルがはじけた頃,業界業種を問わず各企業は一斉にシステム開発投資を削減しました.当時の『日経コンピュータ』に,ある都銀の幹部が「開発を止めたが,ほとんど影響がなかった」と述べていたことを思い出します.システムの必要性がまことしやかに説明されていたにもかかわらず!経営幹部は,提案を通すための作文になっていないかを見きわめる評価眼が求められます.技術ではなく業務の視点で評価すればいいので,可能(なはず)です..効果は見込めるか量的評価の可能なわかりやすいシステムはだいぶ前にやり尽くし,今や質的な効果を議論する時代です.風が吹けば桶屋が儲かる的な,因果関係が定かでない評価のむずかしい質議論の陰に隠れて不要不急,効果の見込めないシステム(機能)を作ろうとしていないかに注意する必要があります.ただし,水,電気のようにシステムが院内業務のインフラになっている面があり,単純に費用対効果だけでは評価できない場合もあることも理解し(91)0910-1810/14/\100/頁/JCOPY単体のシステム,総合的なシステムの導入を検討する際,何に注意すれば良いのかを聞かれることが少なからずあります.今回は,システム導入を検討時のポイントをいくつかご紹介します.ておかなければなりません..病院のシステム整備計画,ポリシーに沿っているか単体で動くシステムを寄せ集めても,相互に連携した院内業務全般を担うシステムにはなりません.院内各業務を担うシステムと情報,機能が連携して動かなければ全体としての生産性が上がらないし,効果的なシステム投資にはなりません.それには,どのような順にどの業務をシステムに乗せるか,あるいは最初から統合情報システムを作るのかの整備計画とポリシーが必要です.もちろんそれは経営戦略に沿っていなければなりません..体制,要員は整っているか院内に専門部門,要員がいないことが多く,ベンダ(システム開発会社)に丸投げするのが一般的です.しかし,丸投げで失敗することが少なからずあります.取りあえず動くので失敗と思わないかもしれませんが,費用対効果の視点でみると疑問符がつく事例があります.丸投げではなく,院内にプロジェクトチームを立ち上げ,仕様書作成まで院内で行い,モノ作りをベンダに任せるという方法があります.仕様書作成に必要なスキルを養成する系統だった教育計画とOJTによる指導が欠かせませんが,院内に人材が育つという,無形ですが大きな財産を残すことができます..ベンダ選択は間違っていないか信頼できるベンダはどこかを見きわめなければなりません.どのような要求でも聞くところは避けたほうが無難です.バランスのとれない機能を要求した場合には,「止めたほうが無難です」といえるくらいの見識,力量*KazushiSugiura:宮田眼科病院CIO/技術士(情報工学部門)あたらしい眼科Vol.31,No.5,2014717をもっているところが理想です.一方,技術,経験の差につけ込み,顧客をおだてて取り込むベンダがいることにも注意を払うべきでしょう.彼らの提案内容がわからない場合には,実戦経験豊富なコンサルタントに評価してもらうのも一つの方法です.また,院内のプロジェクトメンバに必要以上にベンダと親しくなり,個別折衝をしてしまう者がでないよう注意することも,チェックポイントの一つです.もう一つのポイントは,名前が通ったベンダでも誰が担当するかで雲泥の差が出てくることにも注意することです..現場からの要求を反映しているか机上から現場を推測したり,通り一遍のヒアリングで済ませて決めた仕様で作られたシステムでは,十分な効果を発揮しないことは知られています.お仕着せのパッケージ導入ではそのようなケースを見受けます.システムの開発と運用が成功するためには,システム化対象現場の協力が不可欠です.現場とは,診察現場だけではなく,受付,検査,会計,手術,病棟,給食など多岐にわたります.とかく診察業務が中心となりがちですが,他の部門も含め,バランスがとれていなければ,繋ぎ目の部分で手間がかかります.一連の連続した作業であるにもかかわらず,ある部分は電子的に処理され,ある部分は従来通り手作業で処理するのでは,作業効率は改善されず,時間と費用をかけた割には効果を発揮することがむずかしくなります.関係するすべての現場から漏れなく要望を吸い上げるには,システム構築の主旨が理解され,自発的な協力が得られる雰囲気が醸成されていることが求められます.良い雰囲気が醸成されていると,現場から忌憚のない要求が出てくるようになりますが,現場にとってはあまりに馴染みすぎていて,仕様として出てこないものもあります.それらがわかったとき,可能な限り吸収できる構造のシステムであるように作りますが,自ずから限界があります.そこが,柔軟性のある紙と鉛筆での作業と,教え込まれたとおりにしか動けないシステムの違いです.大きなポイントを忘れていました.それは,現場重視ではあるものの,現状のやり方に合わせるのではなく,必ずBPRを行うということです..仕様は絞り込まれているかいつ誰がどのような場合に使うことを前提とした機能なのかを吟味したか?想定する使用シーンが稀にしか起きないものか?日常的に起きるものか?また,頻度は少なくても重要度が高い機能なのか?これらの区別を行い,不要不急な機能によって仕様が膨らまないようにしなければなりません.ただし,ドロップせずにシステムに乗せておかないと,乗せなかったために全体が足を引っ張られる機能もあることに注意する必要があります.また,諸要求が五月雨的に出てくることも想定されます.この取り扱いルールを明確にしておかなければ,いつまでたっても仕様が定まらず,工期は延び,費用も膨らみます.しかし,仕様をフィックスした後に出てきた要求が,システムの根幹にふれるものであった場合には,杓子定規にそれを切ることはできません.期間を延ばす,優先順位の低い機能を次のバージョンに回すなど,臨機応変な処置が必要になります..スケジュールに無理はないか実行可能なスケジュールになっているか否か.根拠となる体制,要員,技術,経験,難易度は十分検討したか?イベント毎に実施するレビューも入っているか?レビュー要員は適任か?レビュー方法は明確か?なども盛り込んでおかなければなりません.もちろん,機能,性能のテストにも十分な時間を費やすべきです.特にテストは,すべてのパスを検証できるデータの作成とテスト環境の実現がポイントです.これをおろそかにすると稼働後に問題が発生します.無理な仕様,スケジュールで進むことは,最初から難破することがわかっている船出といえ,もっとも危険なものです.しかし,危険なのか,ぎりぎりセーフなのか,余裕があるのかの見きわめはむずかしく,経験,先見の明,それに文殊の知恵が必要になります.もっとも重要なのはスケジュールの進捗管理で,忌憚のない報告ができる雰囲気があり,その事実を全員で共有し,リーダが精神論でない適切な判断と対策を行えるか否かです.最大限努力しても稼働後に問題を起こす可能性が予想されれば,見栄を張らずに稼働時期の延期を行うべきです.718あたらしい眼科Vol.31,No.5,2014(92)