新ビジネスモデル研究会（第28回）

杉浦 和史 氏

　はじめに−現場主導の仕様作成

本日は、システム開発の進め方についてお話いたします。
　現場主導の仕様作成について、宮田眼科病院院内総合電子化プロジェクトの実例を示しながらご説明いたします。私は、2000年から宮田眼科病院の業務改革とそれを踏まえてのシステム整備を指導しています。この病院は宮崎県都城市に本院あり、分院が鹿児島市にあります。地方にありますが、開業から50周年を迎える病院です。来院患者数が年間約15万人、手術件数は約8000件の病院です。規模的には眼科で全国２位くらいだと思います、眼科というのは検査項目が95種類あり、一つの診療科の検査としては最も数が多く、また、時間辺りに診る患者の数が多いのも眼科の特徴です。宮田眼科病院では、現場の人達が仕様を作成しています。しかも、基幹業務の仕様作りですから、本当に作れるのかと思うかもしれません。ところが当院では、ベンダのＳＥなど、専門家しか纏められないと思われている仕様を、現場の人達が実際に纏めています。病院の現場で働く人たちは、 2000年当時は冗談でなくマウスが何であるかさえ知らなかった人たちです。 このプロジェクトに、かれこれ10年取組んでおります。昨年７月から新たに３年計画で院内の電子化プロジェクトが開始しました。先日、孫正義さんも、電子カルテ化することで医療費が削減できるはずだと言っておりました。きちんとしたものなら、そうなるはずです。

　なぜ現場なのか、従来のシステム導入の問題点

いままで、システムを導入する場合、システムの企画から、実装、運用、効果検証までベンダに任せるのが普通でした。しかし、これでは、使いやすいシステムはできません。問題点をいくつか挙げると以下のようになります。

1. 顧客の要望を十分咀嚼できない。
2. 陰に隠れている部分を聞き出せない。
3. 顧客の理解度に応じた説明ができない。
4. 日本語が書けない。
5. イニシアティブを握れない。

特に病院は難しいだろうと思います。また、ベンダやコンサル会社は、一般的に、経営層・管理層に、おざなりのヒアリングをおこなうだけで、実際に作業に携わっている現場の人からは、わずかしか聞きとりをしていないという傾向があります。理事長、院長、事務長など経営層に聞き、総看護師(婦)長あたりに聞くだけでは、現場の声を仕様に反映することはできません。システムインテグレーター（SIer）は、われわれは専門家だから任せろと言いますが、病院の場合、そう簡単にはいきません。病院業務に精通するのはかなり難しいことです。例えば、カルテには作業に必要な多種多様なメモ、ラベルが貼り付けられています。当院の場合、その数は約300種類ありますが、調べ切れないですし、キリがありません。にわか勉強で理解するのは間違いの元になります。それなら、この際、現場の看護師、検査員、医事会計員にやってもらおう、そう考えました。

　現場が仕様を作ったほうがいいと考えた背景

顧客の方では、自分達で仕様を作るのは難しいだろうと思い込んでいました。しかし、難しいというか慣れていないのは、纏め方、表現方法、手段だけです。これらをクリアすれば、現場が作れるはずだし、むしろその方が使い勝手も良く、効果の期待できるシステムができると考えました。現場が主導することのメリットは、期待したものと、出来上がったものとの差がないと言うことです。ですから、納得して使い出します。自ら決めた仕様なので、いい点がたくさんあります。以下がその主な点です。

1. デザインレビューができる。
2. デバッグができる。
3. 委員以外の職員に教育ができる。
4. コンセプトを持って説明ができる（プロダクトアウトやトップダウンではない）。
5. 自分が産んだシステムなので育てようと思う（エンハンスができる）。

もちろん、現場が主導することにデメリットがないわけではありません。なんといっても、現場が主導できるまでに人材を育てる時間と手間がかかります。さらに、デメリットとはいえませんが、注意すべき点もあります。それは、どうしても現状是認型に陥りやすいということと、保守層（守旧派）の巻き返しがあるということです。これらに注意しながら、プロジェクトを進める必要があります。

　病院で仕様を作るときの注意点

システム作りの際には、気をつけなくてはいけない点があります。効果の出ないシステムになってしまう仕様の決め方としては、以下があります。

1. やりたいことが不明確なまま、付和雷同でブームに乗って無理やり纏めた仕様。
2. 要不要、軽重問わず、アレもコレもと、何時・誰がどんな場面で使うかわからない機能のてんこ盛りの仕様。
3. 時間がないので、走りながら考えればよいという、もっともらしい論法で適当に纏めた仕様。
4. 現場を知らない開発関係者がおざなりのヒアリングをもとに机上で纏めた仕様。
5. トップの鶴の一声で決まった仕様。逆に、門外漢を逆手に取り、業者に丸投げあるいは「良きに計らえ」で決めた仕様。
6. 全体のシナリオなしに局所的に最適化された仕様。

こういうことをしてはいけないということです。さらに、病院でシステムの仕様を作るとなると、病院特有の別の問題があります。

• 上意下達組織
• 変更を嫌う体質
• 議論する習慣の欠如（物言えば唇寒し…）
• 基本リテラシの不足
• コンピュータリテラシの不足。

ここでいう「基本リテラシ」という言葉は、私が言い出した言葉ですが、ＩＴ関連業務に携わる者は言うに及ばず、ビジネスマンとして必須な能力です。ヒアリング(聞き出す能力)、ドキュメンテーション(文章で表現する能力)、プレゼンテーション(わかりやすく説明する能力)、ネゴシエーション(利害を調整する能力)の４つを基本リテラシと呼ぶことにしています。こうした、病院に顕著に見られる点を払拭し、改善・改革しなければならない、ということです。「上意下達組織」「変更を嫌う体質」「議論する習慣の欠如」に対しては、意識改革が必要ですし、「基本リテラシの不足」「コンピュータリテラシの不足」に対しては、《How to 教育》が必要になります。

　現場の職員をどうやって教育し、雰囲気を高めていったか

それでは実際に、現場の職員をどうやって教育し、雰囲気を高めていったのかをお話します。まずは、その日あったことを「トピックス」として書いてもらうことにしました。気がついたことを遠慮せずに発信することです。これは、自由に発言する雰囲気の醸成と、基本リテラシの養成とコンピュータリテラシの養成を狙ったものです。まず、自由に発言する雰囲気を醸成することによって、「上意下達組織」、「変更を嫌う体質」からの意識改革、「議論する習慣」の醸成を狙いました。また、トピックスを書くためには、文章、図、表で表現することになります。それをメールで送る。あるいはそこに添付ファイルをつけることになります。さらに文章で説明する必要があります。これを続けることで、基本リテラシの養成、コンピュータリテラシの養成が図られるのです。この制度を１年間続けたところ、約1000件のトピックスが挙がってきました。　顕著なコンピュータリテラシの向上が見られたのは言うまでもありません。文章のみならず、適宜、図・表を作成する能力が養成出来ました。Ward、PowerPoint、切り貼り、メール操作、インターネット検索などが自在にできるようになりました。これらを通して基本リテラシの向上、雰囲気の醸成も図られました。時間をかけず、肩に力を入れず、思ったことを書けるようになり、気がついたことを報告、提案する習慣が出来ました。　ただ、指導する側にも努力が必要です。以下のような点です。

1. 報告には、必ずコメントし、言い放し、聞き放しないことで、一体感を培う。（適宜、各部門責任者に回答をしてもらう。）
2. 具体化できるものは即実現し、報告が役に立っていることを実感してもらう。
3. 必要に応じて表現方法について添削して返す。

これらのことを続けることで，病院に顕著な傾向，先にお話した「上意下達組織」から「コンピュータリテラシの不足」までの問題点が解決しました。

　現場主導で気をつける点

　現場主導で気をつけるべき点があります。現場主導で仕様を作る場合、効果をあげるためには、しかるべき相談相手・指導者がいて行うことが前提になります。やはり、生兵法は怪我の元です。指導者も様々な工夫が必要です。主なものを挙げておきます。

1. 一方通行でないやり取りを通し、意見交換する力、表現力を養う。
2. 議事録は翌日までに提出させ、短時間で一定の内容の分を書く力を養うとともに、中身のある議論ができるように仕向けた。
3. 随時、理解確認チェックを行い、理解度を判断し、適宜指導する。（初回→コメント→追試→コメント）
4. 情報を提供するとともに、レスポンスを期待し、自発的興味を促す。
5. 適宜テキスト、説明資料を用意した。
6. 質問には、即刻対応し、やる気をそがないようにした。
7. やむを得ず、使う専門用語には、用語集を用意した。

　おわりに−巧くいった要因と結論

大きな病院で使い勝手のよいシステム作るのは、簡単ではありません。業務プロセスを徹底して洗い出すビジネス・プロセス・リエンジニアリング（ＢＰＲ）を行う必要があります。現場の「情報」とシステムの「機能」を連携させていかなくてはなりません。宮田眼科における本プロジェクトでは、システムを開発する以外にこの病院のＩＴ推進パワーの増強を図る目的もあり、看護師などから選抜された職員に対し、ＢＰＲの手法、システム開発の上流工程である、現状分析、問題点摘出、評価、改善改革案の作成が行えるよう教育しました。私達の取り組みが評価され、2003年に、院内リソースマネジメントシステム／M-Magicで日経コンピュータ「情報システム大賞」編集部特別賞受賞しました。成功の要因は、次の３つでしょう。

1. 経営層の全面的なバックアップ
2. 職員が優秀だった。
3. 雰囲気の醸成に成功した。

以上、宮田眼科病院院内総合電子化プロジェクトを指導している経験から言える結論は、基幹業務でも、現場による仕様の取りまとめは可能である、ということです。