都知事選挙に出馬して約166万票を獲得した石丸さん、自民党筋は蓮舫さんを3位に叩き落した功労者と思っているようですが、彼等が応援した小池さんは、前回獲得した366万票から75万票も減らした291万票になり、小池票も食ったと思った方が無難です。安芸高田市の市長として既得権にしがみつく昔ながらの老害議員とのやり取りが全国に拡散され、既存の清濁併せ呑むという既存政治家のスタイルとは一線を画す石丸さんの歯切れの良い答弁ぶりは大変魅力的です。質問を受ける際には、その質問の趣旨を確認し、何を答えるべきかを整理したうえで的確に答弁する様子はYoutubeでおなじみですが、その彼がプレゼンの上手い人はたとえ話が上手いと言っていました。

あの冷静に分析し、理路整然と説明する彼をして『上手い』と言われたのは、三菱UFJ銀行時代の先輩でしたが、難しい話でも優しく解説し、解説された方は『なるほど』と理解するスキルの持ち主だったそうです。

 

20年近く前ですが、市ヶ谷の公認会計士協会で午前午後4コマで開いた研修の講師をしたアンケートに、たとえ話の持ち出し方が良いという評価があったことを思い出します。


石丸さんの評価項目と同じだったのは有り難いことですが、難しい話や説明の中で皆さんの反応がイマイチだった場合には、できるだけ身近な言い得て妙なたとえ話をするようにしてきました。プレゼン力を磨くというセミナの案内が舞い込むことがありますが、その様なセミナを受講してもプレゼン力が向上することはないと思った方が無難です。なぜ?プレゼンを上手くする技法などないからです。プレゼンしようとする内容が、実際にやってきたことであれば自信を持ってプレゼンできるはずです。質問にも自信を以て答えることができるでしょう。

 

安倍、菅、岸田首相や閣僚の答弁が、官僚の書いた紙を理解することなく棒読みするような場面はしょっちゅう見かけますが、この様な経験を何回積んでもプレゼンの力がつくことはありません。唐津一さんという有名な技術者がいて何回か講演を拝聴しましたが、スクリーンには講演テーマだけが映し出され、終わるまで変わりませんでした。彼は講演開始時に腕時計を外し、演台の上に置き、やおら始めます。原稿も何もなく、頭にある無尽蔵の知識経験をシナリオに沿って分かり易く話をして時間通りに終わります。唐津さんではない凡人の我々はそうはいきませんが、正にプレゼンの達人でした。我々凡人はどうすれば良いプレゼンができるのでしょう。経験に基づき、ポイントを列挙します。


《ポイント1》
とかくアレもコレもとなりがちですが、訴求したい内容を理解してもらえる展開になるようなシナリオを作ります。言いたいことが10あったら、まず半分の5に絞り、次に3つにします。最後に1つだけと言われた時のために最も優先順位の高いものを決めておきます。この様に、テーマ/audienceのレベル/期待値などに応じて主張したいことの優先順位を決めておくことを勧めます。また、飛ばしても良いところ/少し時間をかけて説明した方が良いところを決めておき、audienceの反応、時間の進み具合に応じて適宜反映します。
《ポイント2》
アドリブで説明を追加できるようにしておくことも印象に残るプレゼンにするポイントです。『ここには書いてありませんが、~のようなこともあります』と前置きしてから話します。この時audienceがメモを取ったり、うなづくようですと関心があることが分ります。それを観察しながら『巧く行っている!』と思うわけです。それが自信につながり、良い気分でプレゼンを続けることができるようになります。しかし、何より人前で話す機会を積極的に作ること=場数を踏むことが最も効果的ではないかというのが経験から言えることです。
《ポイント3》
司会者の紹介のあと『ご紹介いただきました××でございます』で始まりますが、いきなり本題に入らず、audienceを観察することを勧めます。このとき、会場の右から左、前から後ろまで、期待しているか文句をつけようとしているのか、義理で参加しているのかをサッと観て感じ取ります。次に歯切れ良く『本日のテーマは、ここに掲げる~です。』と、トップページの表題を見ながら読み上げます。『このテーマは~』と、どうしてそのテーマにしたかの背景を簡単に説明します。この時、audienceがどの様な反応を示すかを観察します。反応が鈍かったら、冗談を交えるなど❝面白そう❞と感じてもらうようにします。ただし、まだ入り口なので手短に話さなればなりません。場面にあった話(たとえ話)をアドリブで話せるよう話題を豊富にしておくことも必要です。次にシナリオ(目次)を説明しますが、一つずつ読み上げるのではなく(時間がかかるので)、「ここに書いてある順にお話します」と言って注目させます。『ここ』と言われると、『どこ?』ということになり、audienceは顔を上げて説明画面を見てくれます。強調したいものがあれば、『特にココは重要ではないかと思っています』と言いつつ、ポインタを当てて強調し、注目を促します。この時もaudienceの反応を観察します。アニメーション機能を有効に使うことも一つの方法です。この段階を最初の1,2分で済ませますが、audienceの関心を高める(イニシアティブを握る)重要な時間です。ここが上手くいけばプレゼンは順調にすべり出します。
《その他》
学会では発表原稿を作る場合がほとんどですが、私は作ったことがありません。上述のように、audienceの反応を見ながら発表を調整(内容変更、補足、削除etc)することはよくありますが、発表原稿に沿って説明しているとそれができません。邪魔です。そもそも、原稿を読んでいるようでは発表する資格がありません。みっともないので止めましょう。

 

明日から3連休。ブログもお休みします。


※質問はosugisama@gmail.comにどうぞ。
※リブログを除き、本ブログ内容の無断流用を禁じます。

今やネットワークはインフラとなり、公私を問わず無意識のうちに使っています(使わされています)。詐欺もネットワーク経由となり、あちこちでうまい話に乗せられ、多額のお金を取られる事件は毎日のように新聞、テレビで報じられます。先日、岡山県精神科医療センタが攻撃を受け、患者情報が流出する被害を受けました。

個人ではなく、企業や医療機関、自治体、団体などが対象になる場合は、このように情報漏洩が問題になります。特に知られたくない個人情報を扱っている医療機関は、サイバー攻撃に対して厳重な監視をしなければなりません。もっとも、米国の国防総省のような厳重に監視されているはずの政府機関でさえも攻撃を受けるのだから、限界はあります。

ロシアのハッキング技術米国の防御技術の戦いのような、国の盛衰、存亡に関係している国家の間で繰り広げられるサイバー攻撃は、我々庶民が関与できるものではなく、どうしょうもありません。我々が直接間接に関係するのは、お金目当てのサイバー攻撃です。大概は、サイバー攻撃で入手した情報を漏洩させると脅し、多額の金を要求されたり、データを改ざんしてから復旧してやるから金よこせ!というデータを人質にとった身代金(ランサムウェア)要求です。

 

2年前のことですが、徳島県半田町の公立病院がサイバー攻撃を受け、診療録などのファイルが書き換えられて使えなくなり、診療ができなくなって休診を余儀なくされる事件がありました。関係者は『うちのような田舎の会社が狙われるとは思っていなかった』とぼやいていたそうですが、ネットワークの時代に田舎も都会も国境もないことを理解していなかった病院とシステムを納入・保守していた業者の時代感覚のズレが原因の一端ではないかと思います。

それはともかく、手間をかけず電子的(自動的)に攻撃リストを参照しながら攻撃をするよう作られたプログラムが攻撃を仕掛けるので手間いらずです。困った手間いらず機能ですが、悪いことをしようとする連中は頭が良く(悪知恵!)、様々な方法を考え付きます。それを防ぐ側とのイタチごっこですが、攻める側vs守る側では、攻める側が有利であることは周知の事実です。

今回、攻撃側はデータを暗号化し、通信傍受されても内容を読み解くことができないという公衆回線に他者が覗き見ることができない仮想的な伝送路を使って送受信するVPN(Virtual Private Network)を使って安心していた病院を狙いました。専用線のような高価な回線を使わないので導入しやすいのが特徴で、多くの企業、団体で使われています。しかし、VPNが安全安価なのには条件があります。それは、VPN回線の制御機器の保守を確実に行っているというものです。

 

VPN回線の制御機器を作っている会社では、製品の性格上、細心の注意を払って設計・製造・検査をして出荷しますが、やはり使っているうちに判明する不具合が出て来ます。それを迅速に制御プログラムにフィードバックし、ユーザが不具合のあるまま使わないようにします。そのため、修正を行うパッチ(※)をユーザに提供します。ユーザができない場合は、そのユーザのシステムを運用保守する業者がそのパッチを適用します。※パッチとは、コンピュータにおいてプログラムの一部分を更新してバグ修正や機能変更を行うためのデータのこと。変更を施すことを『パッチを当てる』と言う。

 

サイバー攻撃を受けないためには、確実にパッチを実行しなければなりませんが、半田病院のシステムを担当する業者は怠っていました。理由は上掲の『うちのような田舎の会社が狙われるとは思っていなかった』ということ!ちなみに、半田病院の場合は、

VPN回線の制御に使っている米フォーティネット社製のVPN機器へのパッチを当てていなかったことが原因で攻撃を受けてしまいました。同社では以下のアナウンスを機器を使っているユーザに配信していました。

Malicious Actor Disclosesとは、アクセスに必要な情報を盗んだ者のことですが、このMalicious Actor Disclosesは、米フォーティネット社製のVPN機器を使っている多くのユーザの中から、同社が配布するパッチを当てていないズサンなものを見つけて侵入。そこから同社製のVPN機器にアクセスするために必要な情報を入手し、これを公開してしまったようです。公開されてしまったVPN機器の数は世界で87000台!その公開情報を使って攻撃されたうちの一つが、日本の徳島県つるぎ町にある町立半田病院でも使っている機器だったというわけです。

私が汎用機OSの設計をしていた際に、OSに不具合が見つかると確実にパッチを当てるため、ユーザを担当するSEが最優先でユーザを訪問して実施しました。今回の岡山精神科医療センタの場合はどうだったのか?その辺の情報はありませんが、制御プログラムが最新の状態にあることが前提の防御力を発揮するVPNなのに、最新の状態にするupdateを怠っていた可能性は高いでしょう。専門家の調査で、同医療センタからは約4万人の患者情報が盗まれ、ダークウェブ上にupされてしまっていることが確認され、もはや、どうにもならない状態。悪用されないことを祈るばかりです。

 

※質問はosugisama@gmail.comにどうぞ!

※リブログを除き、本ブログの無断転載、流用を禁じます。

『使えない電子カルテはどうしてできてしまうのか』の最終回です。既に1,2回目をご覧になっている方は、イントロまで飛ばし、『5.システムを作るのは誰』からお読みください。

 

10年以上前ですが、宮崎のシーガイヤホテルで日本看護協会の研究会が開かれ、講演したことがあります。

タイトルは『使えない電子カルテはどうしてできてしまうのか、使える電子カルテはどうすればできるのか』です。当時は黎明期のそれよりもマシになってきてはいたものの、診療科では最も検査の種類が多い眼科では、使える電子カルテは皆無でした。もちろん、使っているところはありましたが、オーダメイドではなくいわゆる出来合いのパッケージなので、帯に短したすきに長しでした。短いところは面倒な操作をし、長いところは使わないということ、要するに不具合を慣れでカバーし、使っているうちに慣れるというものです。実際、医局からローテータで来る医師は、使えるところだけ使い、機能不足はアナログでカバーして使っていると『いつの間にか慣れる』と言っていました。業者も『そのうち慣れます』が常套句でした。今日、明日の2回、講演した内容を紹介します。なお、言わんとしていることは今でも変わっていませんが!12年前の講演であることをご了解ください。

 

~~ イントロ ~~

電子カルテという言葉が普通に語られるようになってから、かなりの時間が経過しています。ブームが去って本当の浸透が始まると言われていますが、厚生労働省が掲げる普及率には遠くおよびません。習熟容易性、費用対効果など、幾つかの要因が考えられますが、電子カルテに限らず、パッケージ化された医療機関向けシステムが提供する機能、情報、および操作性が、現場の作業実態を反映していないことが最たる要因ではないかと考えらます。

お仕着せのパッケージ以外に選択肢はないのでしょうか?自主開発はできない?それより前に、今の仕事の仕方に無理無駄はないのか?どの様な機能が必要なのかを洗い出したか?など、システム導入に際し、解決すべき有形無形の問題が山積していることを理解しなければなりません。その状況を踏まえ、ベンダ(システムを開発する会社)の言うことを鵜呑みしたり、経営陣の鶴の一声で導入を決めてしまう愚はさけなければならません。人間ならではの業務を除き、電子カルテを含む、院内業務を包括的に処理するシステムをパッケージではなく、自主開発するに至った開発経緯を紹介し、皆さんの参考にしたいと考え、今回の発表に至りました。

 

5.システムを作るのは誰

一般的に、システムを作るのは、ベンダ(システムを作る会社)の専門的な教育を受けたSE(system's engineer)が担当することになっていて、そのプロセスは以下の通りです。

①企画(システム化の必然性、費用対効果を検討したのち、おおまかな機能を考える)

②仕様(作業実態に合わせ、画面設計、操作設計、画面遷移、メッセージ、ガイドなどを作る)

③実装(実際にプログラムを書く作業)

④テスト(仕様通りに出来上がっているかのチェック)

⑤運用(システムを使い始める)

⑥エンハンス(必要に応じて、機能の追加・変更)

このうち、①が最も重要であり、次に重要なのは②ですが、これらの作業を情報システムの素人である病院職員ができるか?という疑問や躊躇があるのは当然です。ベンダは『我々プロに任せなさい』と言い、一般的には彼らに任せることになります。 しかし、任せっきりにした結果が

のようになっているのはなぜかを考える必要があります。ベンダ任せにできなければどうしたらいいのでしょう。自らやればよいというのが、私の過去やってきた結論です。ただし、の実装は具体的にプログラムを書く作業であり、付け焼き刃で臨むのは危険と判断し、餅は餅屋(ベンダ)に任せることにしてきました。のテストは自ら作ったどういう機能が必要なのか=仕様❞なので、期待した結果が得られるかをチェックすることは問題なくでき、実際に各部門の担当者が自分が決めた仕様通りに動くかをチェックをしました。

は自ら作った仕様通りに運用し、法改正、患者要望などの条件の変化を反映して適宜エンハンス(機能強化)する仕様を決め、ベンダに作ってもらうだけなので、問題ありません。この様に考えれば、病院主導でのスクラッチ開発はそれほど難しくはないということで、現場を育てて開発するという、今風で言えば内製化によるシステム開発を志向しました。

 

肝心の仕様ですがその重要な仕様を作るにはどの様な知識、経験が必要なのかを考えてみると、おおよそ以下の通りです。

①業務知識(当該業務のみならず、関連する業務を含む作業内容、方法、手順など)

②聞き出す能力(どの様な機能が必要かを観察し、適宜聞き出す)

③資料作成能力(聞き出した事実と問題点を整理し、仕様書に纏める)

④説明能力(纏めたものを分りやすく説明する)

⑤調整能力(異なる意見要望が出てきた場合の調整、経営層の意向反映など)

このうち、基本となる能力は、①の業務知識と②の業務内容を聞き出す能力ですが、現場が担当すれば、も不要となり、残るはです。これらは、いわゆる基本リテラシに属しますが、時間をかけてプロジェクトメンバとなった現場の看護師、薬剤師、栄養士、検査員などのスタッフ教育して実戦投入しました。彼らは、プロジェクトメンバではない他のスタッフを教えるようにし、病院全体のスキルアップを図りました。メンバには、時々理解度を把握するためにテストを行い、丁寧なフォローをするようにしました。(赤ペン先生と呼ばれていました)

 

また、プロジェクトメンバは部門毎に教え合い、意見交換し、情報を共有することで、プロジェクトメンバのスキルの幅と深さを広げることも行いました。


6.結論

昔、食品メーカのコマーシャルで、❝私作る人、私食べる人❞という表現が、婦人団体に糾弾されたことがあります。理由は、夫婦の役割を固定化し、主婦に負荷を押しつけるものであるとのことでした。目くじらを立てるほどのことかと思ったことがありましたが、その是非はともかく、ベンダが作り(パッケージを提供し)、顧客が使うという関係が固定化していることと似ていると感じました。本来、ベンダはより広く深く、現場の状況を観察し、顧客は現状と改善して欲しいことを説明し、相互に協力し合い、効果を実感できるシステムを整備しなければなりません。ただし、顧客が発注者であることを誇示したり、ベンダはぺこぺこするという図式では、優れたシステムをできないことを、双方共に理解する必要があります。ぺこぺこしている裏で、評価能力の少ない顧客を手玉に取るベンダもいるので注意を要します。

 

以上、3回に亘って役割を固定化せず、双方の得意とするところを活かす方法として、自前のスクラッチ開発という手段もあることを紹介しました。時間はかかりますが、教育されたスキルの高い人材が育ち、業務の整理整頓ができ、組織の雰囲気も高揚するという、有形無形の財産が得られるという大きなメリットは見逃せないと思います。

 

※質問はosugisama@gmail.comにどうぞ。

※リブログを除き、本ブログの無断転載、流用を禁じます。

『使えない電子カルテはどうしてできてしまうのか』の2回目です。既に一回目をご覧になっている方は、『3.優れたシステム』からお読みください。

 

10年以上前ですが、宮崎のシーガイヤホテルで日本看護協会の研究会が開かれ、講演したことがあります。

タイトルは『使えない電子カルテはどうしてできてしまうのか、使える電子カルテはどうすればできるのか』です。当時は黎明期のそれよりもマシになってきてはいたものの、診療科では最も検査の種類が多い眼科では、使える電子カルテは皆無でした。もちろん、使っているところはありましたが、オーダメイドではなくいわゆる出来合いのパッケージなので、帯に短したすきに長しでした。短いところは面倒な操作をし、長いところは使わないということ、要するに不具合を慣れでカバーし、使っているうちに慣れるというものです。実際、医局からローテータで来る医師は、使えるところだけ使い、機能不足はアナログでカバーして使っていると『いつの間にか慣れる』と言っていました。業者も『そのうち慣れます』が常套句でした。今日、明日の2回、講演した内容を紹介します。なお、言わんとしていることは今でも変わっていませんが、12年前の講演であることを承知の上、お読みください。

 

~~ イントロ ~~

電子カルテという言葉が普通に語られるようになってから、かなりの時間が経過しています。ブームが去って本当の浸透が始まると言われていますが、厚生労働省が掲げる普及率には遠くおよびません。習熟容易性、費用対効果など、幾つかの要因が考えられますが、電子カルテに限らず、パッケージ化された医療機関向けシステムが提供する機能、情報、および操作性が、現場の作業実態を反映していないことが最たる要因ではないかと考えらます。

お仕着せのパッケージ以外に選択肢はないのでしょうか?自主開発はできない?それより前に、今の仕事の仕方に無理無駄はないのか?どの様な機能が必要なのかを洗い出したか?など、システム導入に際し、解決すべき有形無形の問題が山積していることを理解しなければなりません。その状況を踏まえ、ベンダ(システムを開発する会社)の言うことを鵜呑みしたり、経営陣の鶴の一声で導入を決めてしまう愚はさけなければならません。人間ならではの業務を除き、電子カルテを含む、院内業務を包括的に処理するシステムをパッケージではなく、自主開発するに至った当院の開発経緯を紹介し、皆さんの参考にしたいと考え、今回の発表に至りました。

 

3.優れたシステム

失敗するシステムの要因を述べたので、次は優れたシステムと言える条件を説明します。優れたシステムとは、高邁なコンセプトや、使っている技術の先進性、高度なテクニックではなく、経営幹部や企画者の自己満足でもなく、“効果が実感でき、安定した稼働が続けられ、経営層から現場まで歓迎される”システムです。具体的には、システムが提供する機能により、次の効果が実感できることです。

 - 少人数で処理できるようになった。

 - 短時間で処理できるようになった。

 - 正確に処理できるようになった。

加えて、

 - 今までできないことができるようになった。

 - 気分良く仕事ができるようになった。

 - 雰囲気が良くなった。

これが、上から下までそれぞれの現場に於いて実感できるシステムが優れたシステムです。この様なシステムを作り、運用するに次表のような条件があります。

4.パッケージ

ほとんどの病院がベンダの提供する出来合いのパッケージを導入していますが、果たして満足しているのでしょうか。下図は電子カルテの評価を導入の段階を追って調査した矢野経済研究所のデータをグラフにしたものですが、使っていくうちに使えないことが分ってくることを示しています。そのうち慣れるという営業の説得に応じてきた導入側であるが、使っているうちに評価が下がって来る実態が読み取れます。使える範囲で使い、慣れてきてそれなりに使っているものの、満足しているかと問われると、このグラフの感想になるということです。

スーツを購入する際、安価・手軽なことから出来合のものを購入するのが一般的ですが、より体型にフィットしたものを希望する場合には、高めだし時間を要しますがオーダします。パッケージを出来合のスーツに、スクラッチ開発(0から作ること)をオーダスーツに置き換えると分りやすいと思いますが、必要となる費用の桁が違い、システムはスーツのようには簡単には買い換えられないことに注意が必要です。このことを頭に入れて上図を見ると、使っているうちに使い辛いことが分ってくるものの、一旦導入すると、慣れるしかなく、使い続けなければならない状態であることが分かります。慣れてしまうと、問題だと思っていたことを問題と思わなくなってしまうことが大きな問題と言えます。

 

次回は明日(最終)です。

  

※質問はosugisama@gmail.comにどうぞ!

※リブログを除き、本ブログの無断転載、流用を禁じます。

10年以上前ですが、宮崎のシーガイヤホテルで日本看護協会の研究会が開かれ、講演したことがあります。

タイトルは『使えない電子カルテはどうしてできてしまうのか、使える電子カルテはどうすればできるのか』です。当時は黎明期のそれよりもマシになってきてはいたものの、診療科の中では最も検査の種類が多い眼科では、使える電子カルテは皆無でした。もちろん、使っているところはありましたが、オーダメイドではなくいわゆる出来合いのパッケージなので、帯に短したすきに長しでした。短いところは面倒な操作をし、長いところは使わないということ、要するに不具合を慣れでカバーし、使っているうちに気にならなくなるというものです。実際、医局からローテータで来る医師は、使えるところだけ使い、機能不足はアナログでカバーして使っていると『いつの間にか慣れる』と言っていました。業者も『そのうち慣れます』が常套句でした。今日、明日、明後日の3回、講演した内容を紹介します。なお、言わんとしていることは今でも変わっていませんが、12年前の講演であることをご了解のうえ、お読みください。

 

~~ イントロ ~~

電子カルテという言葉が普通に語られるようになってから、かなりの時間が経過しています。ブームが去って本当の浸透が始まると言われていますが、厚生労働省が掲げる普及率には遠くおよびません。習熟容易性、費用対効果など、幾つかの要因が考えられますが、電子カルテに限らず、パッケージ化された医療機関向けシステムが提供する機能、情報、および操作性が、現場の作業実態を反映していないことが最たる要因ではないかと考えらます。

お仕着せのパッケージ以外に選択肢はないのでしょうか?自主開発はできない?その前に今の仕事の仕方に無理無駄はないのか?何のためにどの様な機能が必要なのかを洗い出したか?など、システム導入に際し、解決すべき有形無形の問題が山積していることを理解しなければなりません。その状況を踏まえ、ベンダ(システムを開発する会社)の言うことを鵜呑みしたり、経営陣の鶴の一声で導入を決めてしまうはさけなければならません。人間ならではの業務を除き、電子カルテを含む、院内業務を包括的に処理するシステムをパッケージではなく、自主開発するに至った開発経緯を紹介し、皆さんの参考にしたいと考え、今回の発表に至りました。

 

1.はじめに 

医事会計システムに端を発した医療機関向けシステムは、必要とされる機能、情報の全体像を描いてから、ニーズを踏まえた開発優先順位を以て順次整備されてきたものではなく、必要になった都度、屋上屋を重ねるようにして作られてきた経緯があります。その結果、業務相互の連携、作業の連続性が考慮できていないことによる機能間のつなぎ目での手間、システムに乗せられた作業と、そうではない手作業とが混在することによる煩雑さ、操作の一貫性に問題を抱えることになってしまいました。本来、システムの持つべき仕様(機能、情報、画面レイアウト、画面遷移、操作性など)は、使う側が決めるべきですが、ほとんどの病院では、お仕着せのパッケージをカスタマイズして使っているのが現状と言えます。しかし、できるだけ適用範囲を拡げるために、汎用性を考えて作られているパッケージを、カスタマイズ可能な範囲でフィッティングする程度では、現場のニーズをきめ細かく吸収できるはずがなく、使いづらさ、不具合を慣れでカバーしている現状があります。これは、売っているベンダ(システムを作る会社)が一番承知していて、『そのうち慣れますよ』、 これが常套句となっています。顧客のニーズに合った機能を提供する役割を担っているはずのベンダが慣れを期待するのでは話になりませんが、顧客である病院とベンダとの技術、知識の彼我の差が、これを当たり前にしてしまっているところに問題があると思われます。 

 

2.失敗するシステム導入要因 

電子カルテだけではありませんが、システムを導入しても十分な効果が感じられない場合が多いのはどうしてでしょう。様々な要因が考えられますが、おしなべて言えることを整理すると以下の通りです。  

(1)目的が曖昧、あるいは他動的。

世の中の趨勢だから/他もやりだしたらしいので、などという希薄な根拠で企画されたシステムはうまく行きません。また、他の病院が巧くいったから当院でも!と思いがちですが、成功要因、背景を吟味しないと失敗します。スキルに長け、やる気のある医師が一人で仕切るクリニックで巧くいっていても、スキルや意識に違いのある複数の医師や職員がいる病院では百家争鳴となり、収拾がつかない傾向が見られます。プロジェクトリーダーの手腕の見せ所です。

(2)リーダがいない。

実行可能なシナリオを描くことができ、快活で少々のことではめげない人物が望ましい。とかく『ヤルぞ!行くぞ!』という元気の良い人物がリーダになることがありますが、長続きしないし具体性に乏しく頓挫します。実際には動かない幹部が、お飾りで開発プロジェクトのトップに座る例は枚挙に暇がありませんが、意味がないどころか、迅速な意志決定の障害になることは過去幾つも見てきました。また、任せると言いながら任せきれずに枝葉末節にこだわる幹部がいると成功への道は遠くなる一方です。

(3)組織全体の雰囲気が盛り上がっていない。

上層部だけ、あるいは関係者、関係部署のみが燃えている場合は失敗する危険があります。システムを使うのは現場であることを忘れ、机上の空論で議論を進めるとこうなる可能性は高くなります。実務に疎い評論家的なコンサルタントを入れると更にその傾向が強まります。ビジョンはトップダウン、実行はボトムアップでというのが私の方針ですが、権威を背景に上意下達でビジョンを押しつけると面従腹背になってしまうし、高邁なスローガンを掲げても浸透しません。強制しなくても自らの意志で積極的に参画しようとする雰囲気がボトムから湧き上がって来なければ、成功はおぼつかないでしょう。

(4)BPR(ビジネスプロセス・リエンジニアリング)がおろそかになっている。

業務プロセスの整理整頓を疎かにし、無理無駄を残したままの仕事の仕方を前提としたシステム開発、導入は失敗します。しかしながら、旧態依然とした雰囲気が漂う歴史ある病院では、指揮命令系統の再編成/権限の再配分まで含むBPRを行うのは困難を伴います。しかし、BPRを行い機能を損なわずに無理無駄を廃したスリムな業務プロセスにした後でなければシステムの仕様は決められません。無理無駄を残したままのシステム化は効果が期待できないからです。万難を排して実行しなければなりません。それができなければ、システム化は止めた方が無難です。一方、京都の学会でしたが、このBPRを数ヶ月で済ませることができると豪語するベンダに出くわしたことがあります。それなりの規模の病院でそれをやったとのことでした。意識改革を伴うBPRをそれほどの短期間で終わることは常識的にあり得ないと思いましたが、バグが多かったこともあり、その病院はしばらくして紙のカルテに戻しました・・・

(5)性急な期待をする。

土作り、地ならしが必要なことは、農業や土木の世界だけではありません。業務をシステムに載せて効果を期待するなら、そのシステムが効果を発揮するための土作り、雰囲気作りを優先して行うべきです。いずれも時間と忍耐を要するもので、予算がクリアできれば何とかなるというものではありません。急がば回れ!

 

※質問はosugisama@gmail.comにどうぞ!
※リブログを除き、本ブログ内容の無断転載、流用を禁じます。

新聞の投書欄に載っているものは、冗長なものや主張が不明確なもの、不適切なものは担当部がチェックしているのでまともですが、猫も杓子も投稿するSNSはそうではありません。FaceBookや旧ツイッタの中には、義務教育を履修して来たのかと思う稚拙なものも少なからずあります。そのレベルはともかく、社会人の中にもまともな文章が書けない人を散見することがあります。このブログでも、時々文章について書いてきましたが、配信されてきたセミナ案内の中にこんなものがあったので、今日はこれを取り上げます。

 

そして、受講を勧めるのはこんな人らしいです。

 

講師はライター歴の長い方だそうですが、19:30~21:00の1時間半の講義でこの効果が得られるなら、このセミナを受講すべきです。しかし、過去の経験から無理だと分かります。国税庁の税務大学校で全国の国税局から集まった研修生(国税調査官)に業務分析、ITの基礎を教えていた際、基本リテラシ®を教えていました。基本リテラシとは、ヒアリング、ドキュメンテーション(ライティング)、プレゼンテーション、ネゴシエーションで商標登録をした私の造語です。

40日の集中研修の間、毎日10minutes writingを課しました。10分間の時間を与え、文章を書いてもらい、これにコメントして返しました。最初は『今日は××について思うところを書いてください』とテーマを与えて書いてもらいましたが、途中から家族、趣味、世相、税金のことなど、何でもいいから10分間自由に書いてもらうことしました。最初から纏まり良く、上手な言い回しで書ける人もいましたが、総じて研修終了まじかになると分かりやすい文章を書けるようになってきました。元々然るべき仕事をしてきている皆さんなのでキチンと書けて当たり前ですが、お役所文書のような決まり切った形式と表現で過ごしてきた彼らには、書式自由で何を書いても良く、それも10分間で纏まった文章を書きあげるのは、結構大変だったようです。


で、どんなコメントをしたのかですが、言わんとしていることへの感想の他に、おかしいと思われるてにをは/接続詞/修飾語の位置/表現の適切性/文章の区切りなどについて指摘しました。国税局で一人前に仕事をしている研修生にとってはうるさい奴、偉そうな奴と思われたかもしれませんが、30年ぶりくらいに会った彼らの中には、自分の書いた10minutes writingと私の赤ペンでのコメントをファイルして持っている者もいましたが、いい思い出になっているとのことでした。文章力向上に、この10minutes writingは有効だと思った次第です。

 

10minutes writingとは、私の造語ではなく、富士山の麓にあった通産省と外務省の外郭団体であった貿易研修センタ(IIST)で3ヵ月受講した全寮制英語研修の際、外国人講師が何でもいいから10分間、英語で何かを書いてみよ!というものがあり、これをヒントにしたものです。

富士宮研修センター

案内がきた19:30~21:00の1時間半のライティング塾と毎日10minutes writingすることの違いが理解できたと思いますが、文章力向上のセミナ、講座は大なり小なりこんなものです。文章力を向上させるには時間がかかり、毎日の積み重ねが必要です。

 

改めて今回のセミナの案内を見ると
「SNSやブログに何を書けばいいかわからない...」
「文章を書くのが苦手...」
「自分の文章が読者に伝わっているか不安...」

という人向けとのこと。

そもそも、『何を書けばいいのか分からない』という人は、文章を書く前に解決しなければならない問題があります。何を書けばいいのかが分からなければ、どうやってうまく表現しようかに悩む必要はないし、うまく伝わっているかを心配することもありません。伝えたいことが決まっていないのだから当然で、何回受講しても変わりません

 

また、案内によればこのセミナを受講すると以下のことができるようになる・・・

✔️文章を書くのが苦手な方でも、自信を持って書けるようになります。
✔️SNSやブログでの効果的な文章の書き方がわかります。
✔️「書かない」文章づくりのポイントが理解できるようになります。

講師はどうやって教えるつもりなのか分かりませんが、19:30~21:00の1時間半のセミナでこれらを実現できると思わない方が無難、無理です。

文章力向上は、時間のかかるものと思いましょう。新聞、特に知識経験豊富な記者が担当する社説を読みましょう。また、示唆に富み、軽妙謝絶な表現が光る天声人語のような卓越した表現力を持つ記者の書いた記事を読み、参考にしましょう。それに日記をつけることを勧めます。少し大げさですが、ローマは一日にして成らずという言葉のとおりです。

 

※質問はosugisama@gmail.comにどうぞ!
※本ブログの内容を全部、あるいは一部を無断で転載、流用することを禁じます。

 

毎日送られてくる医療系のニュースに、日本医師会の幹部が『紙カルテを全て電子カルテに置き換えることは不可能』というタイトルのものがありました。

紙カルテをそのまま電子的に置き換えるのは難しいことは、オリジナルな電子カルテを作ってきたことから経験していますが、『紙カルテを全て電子カルテに置き換えることは不可能』と発言した幹部は、診療所を含む全ての医療機関に(強制的に)電子カルテを使わせることはできないという意味のようでした。それならニュースタイトルは、簡潔に『紙カルテ全廃は不可能』とすべきでした。それはともかく、ニュースにつられて今日は紙カルテvs電子カルテを取り上げます。

 

20年以上前ですが、現場の作業実態を反映していない使い勝手の悪いものが多かったこともあり、臨床を担う現場の医師からは不評が絶えなかった電子カルテ!学会のホームページには拙速な導入は診療に支障を来すとまで書かれていたほどです。

最近では少しはマシになってきたのか、不具合を慣れでカバーして使っているうちになじんでしまったのか、普及率を見ると何とか使えているようです。

私は、病院の業務のうち、注射、手術、包帯などどうしても人の手が必要なもの以外の業務・作業を電子的に取り扱えるようにできる院内業務総合電子化プロジェクトを率いてきた中で、如何様にも書ける紙カルテの冗長性と手軽さをそのまま電子的に実現するのは難しいことを実感してきました。これは、紙と鉛筆と消しゴムの冗長性に比べ、コンピュータが必須で、キーボード、マウス、画面のそれを見れば誰でも分かると思います。紙カルテの機能をそのまま電子的に写し取るのではなく、紙カルテではできなかった機能を電子的に実現する+αを発想すべきです。

 

院内には、検査、診察、処方、手術、入院、薬剤、給食、治験、保険、会計など様々な業務がありますが、それらの間を流れる情報(検査結果、メモ等)は、紙カルテに挟まれ、適宜参照されていました。つまり、診察の部分だけ電子カルテにしても、参照したい情報が紙にあるままの状態では話になりません。検査データなど、紙にある情報も全て電子化されていなければ当該患者の情報一覧性が実現できません。情報一覧性が電子化する最大のメリットです。ただし、連携をするために逐一操作、ハンドリングが必要となるようでは使い勝手が悪すぎます。ポリシーなく、五月雨的に業務対応のシステム(パッケージ)を導入するとその様になります。

情報が統合データーベースに集められ、必要に応じて組み合わされ、その情報を必要とするスタッフが利用可能になる院内業務総合電子化システムになっていなければなりません

そうなるためには、電子カルテのシステムだけが独立して存在していて、他の院内のシステムとの情報連携ができていないということではなく、院内で発生する全ての情報が電子的に取り扱えるになっていなければなりません。

もちろん、部門毎の業務をカバーするシステムが整備されていなければなりません。そうでなく、電子カルテのシステムだけが独立して存在していては、他の院内のシステムとのリアルタイムな情報連携ができないことになります。

 

そうならないためには、ISA(information system architecture)と呼ぶ情報システム整備計画を作る必要があります。それを作れる見識を持ったCIOとその整備を指示するCEOが必要になります。

 

日本医師会のホームページには、医療DXの定義が書かれています。

能書きだけで、どうやってその環境を実現していくのかが分かりませんが、関係がある情報がシームレスにストレスなく連携していれば、実現できます。ただし、先進的な医療機関だけではなく、大小合わせ、首都圏も地方も併せてそうなっていなければ、このホームページにあるようなことは実現できません。日本医師会幹部に、それを理解している人物が何人いるのか?有識者と称する机上の空論を戦わす学者や、泥をかぶってシステム構築してきたことのない机上から指示を出してきた管理職たちの議して決せずの結果出てきた無難な案(官僚の作ったたたき台?)をだして、やったつもりでいる現状を改革しなければ、実行可能解は出てこないと思っています。

 

※質問はosugisama@gmail.comにどうぞ!
※リブログを除き、本ブログ内容の無断転載、流用を禁じます。

何時の時代にもブームがあります。メインフレーム全盛時代だった昭和56年前後に起こったOAブームの時は、当時晴海で開かれたビジネスショウ、データショウは、OAの大合唱でした。OAの意味を知ってか知らずかコンピュータ各社は、OAの名前を冠した事業部、部を新設した時代でもありました。私も新設されたOAシステム部の技術グループに配置換えとなったのでよく覚えています。OAがOffice Automationの頭文字であることすら分かっていない上司がいたことは、更によく覚えています。なんだかガッカリする話しですが事実でした。Factory Automationなら何となく想像がつくものの、Office=事務所、そのAutomation=自動化ってなに?という人たちは少なからずいて、その大部分は小規模のEDPのことをOAと思っている人たちでした。その伝で言えば、SAのSales Automationも理解できなかったと思います。

 

製造業などで見られるように、現場レベル(直接部門)でのシステム化は分かりやすく、生産性向上、効率向上が図られましたが、事務部門のそれは手つかず状態。それを解決しようということで発想された概念がOfficeのAutomation=OA。しかし、物理レベルで効果が目に見える直接部門のシステム化ではなく、間接部門の事務作業を効率向上とか生産性向上という視点で評価/観察することはとっつきにくいものでした。せいぜい、紙ベースで仕事をしていたものが、紙に書かれたデータ(情報)が電子化されて扱いやすくなった程度です。確かに、事務作業の典型である台帳との突合せ/伝票参照/転記/集計などは、一人一台のパソコンの普及と関連するソフトの充実で楽になりました。しかしこれは、今迄の手作業をパソコン作業に置き換えただけです。もちろん、パソコンで作業できるような環境を整えなければなりませんが、それは本来のOAの趣旨ではありません。本来のOAとはなんでしょう?

 

それは全ての業務をシステムに載せる際に共通していることですが、業務を構成する作業を一つずつ見直すことから始めなければなりません。その過程で重複している作業が見つかったり、あってもなくてもいい作業だったりするものが見つかります。業務分析をしていると、これは要らないのではないかという作業を発見することがあります。それは『どうして、何のためにこれをやっているの?』という質問に答えられない作業で、彼らの答えは『昔からやってきているものです』というものです。この答えを引き出したら、その作業の廃止はほぼ決定です。この作業は、盲腸に似ています。

 

よく言われる『盲腸はいらない』を調べてみると分かります。盲腸は、ウサギなどのように草を食べている動物の盲腸は、草草を消化し、そこから栄養を取る役割を果たしている、草食動物には必須で大きな臓器です。肉食動物の盲腸はかなり小さいのは、草から栄養を取る必要がないからで、人間も同じです。ただし、人間の場合はその発達の歴史の中で草から栄養を取る必要がなくなって来たことから小さくなってきて、やがて要らなくなってきました。私も40年ほど前に、盲腸(急性虫垂炎)になったことがありますが、医師に『盲腸は本当に要らないのでしょうか』と質問したところ『取っても、生活するうえで不都合が起きることはない』とのこと。つまり、虫垂炎になる要因を抱えているだけ損ということです。

 

業務分析、作業分析をしてきた結果、要らないのはないかと思い、現場に聞くと『昔からやってきているもの』というものは、この盲腸と同じです。人間は手術して取り除きますが、何でもないのに手術するのは気がひけるとして人間は虫垂炎にならない限りは手術することはありません。しかし、事務の分析をしていて盲腸的作業が見つかった場合には問答無用で取り除きます問答無用・・・実はそう簡単には行きません。どうしてでしょう?それは、その盲腸作業を作り、十年一日の如く、その作業をしてきたベテランスタッフ達のメンツです。

 

確かに、その作業が必要だった時期があったと思いますが、人間が草を食べなくなり、草から栄養を摂取する機能を持つ盲腸がいらなくなったように、環境の変化と共に役目を終えたということです。しかし、そこは人間。『私が考えたものを不要というのか!』となるわけです。ベテランスタッフが陰に陽に邪魔をしてきます。実際に病院の業務プロセス、作業内容を分析していて、ベテランの抵抗に出くわしたことがあります。
 

発見したのは、医事会計システムが導入される前に外来看護師が行っていた点数記入作業です。医事会計システムを導入して不要になった後も、そのまま残していた!ということです。

私の場合、定年を控えた女ボスが相手でしたが、このような人物が居座り、牢名主として隠然とふるまっている組織では、業務・作業の改革改善は進みません。意識改革ができず、変化を好まず旧習を押し付けるこの様なタイプの人材がはびこると、組織が非活性化してしまいます。意識改革、業務改革を行い結果として生産性向上を目指すBPRを行う際の障害になり、Office Automationも進みません。

 

皆さんの組織に牢名主、いませんか?

 

※質問はosugisama@gmail.comにどうぞ!

※リブログを除き、本ブログの無断転載、流用を禁じます。

このブログでは、猫も杓子も唱える付和雷同のDXへの批判を幾度となく書いてきました。先日、IT系情報サイトが『DXの足かせになるレガシーシステム』などというタイトルの記事をアップしてきたので、いささか食傷気味ですが、この話題を取上げることにしました。

この種の記事に共通しているのは、書いた記者がメインフレーム時代から続く情報システムの歴史を知らず、汗をかいてシステムを作った経験もなく、あちこちから聞いた情報を机上で纏めているということです。その原稿をチェックできる知識経験を持った者が編集部にもいないのでしょう、そのまま記事になってしまうようです。全国紙でもこの方面では同じようなもので、過去に情けない記事に出くわしたことがあります。それは・・・病院の改善事例を紹介した記事に関するものです。

記事下段左左側に黒くリバースしている❝入院時の待ち時間(~説明・術前処置)、163分から26分に❞となっている部分があります。病院コンサルティングを現場に入り込んで12年やってきた経験から、直感的にオカシイと思いました。簡単に分かるのは、入院時の待ち時間という言葉です。字づらだけ見ると、入院当日に来院してから病室に入るまでのことなのか?と思いますが、予定入院なのに163分も待たされるはずがありません。しかも、記事上段のタイトルには入院待ち時間ではなく手術待ち時間が163分⇒26分と書いてあります。この時点で書いた記者、記事をチェックする編集・整理部に業務知識がないことが分かります。もう一つのオカシイと感じたのは、時間短縮の要因を❝針や注射器の置き方を統一した❞としたことです。one of themの要因とは思いますが、そんな程度のことで劇的な改善がないことは現場を知っている者には自明です。しかし、中身は分からないものの改善によって2時間半近くも短縮されたと感心してしまうのが一般的です。

 

その様な記者が書いた❝レガシーシステムがDX化を阻害している❞という記事になので、読む気にはなりませんが、DXDXと叫ばれている今なので、どんなことを書いているのかちょっとチエックしようと思った次第です。彼が引っ張り出してきた情報に、IPA(情報処理推進機構)が発表したDX白書2023に、レガシーシステムが半分以上残っている企業は41.2%と書いてあるそうです。おそらくメインフレーム時代から営々と機能の改廃・変更・追加されてきた基幹システムと周辺システムから成るレガシーシステムがどんなものなのか、機能的にどこまでカバーしているのかまで踏み込んで調べていないのでしょう。彼らは、今はやりのモダナイゼーション(modernization)とかいう流れを作りたいのかもしれません。システム開発の実務に従事したことがない彼らは、雰囲気作り、風潮作り、ブームを起こして一儲けしたいだけ?と思ってしまいますが、確固たる方針(ISA:information system architecture)を持っていれば、不必要・無定見にブームに踊らされることがありません

 

メインフレーム全盛時に、日立、IBMと市場を3分した富士通は、同社製のメインフレームが700台も残っているそうです。

現役で使われているとはいえ、既に生産が終わっているメーンフレームを700台も保守し続けるための要員、部品の確保をするのは負担なので、オープン系に移行して欲しいというのが富士通側の本音でしょう。しかし、おいそれとマイグレーションできない事情があります。それは、メインフレーム時代から営々と機能の改廃・変更・追加されてきた基幹システムと周辺システムから成るレガシーシステム支障なく新インフラ環境で稼働させる確信が持てないからです。

 

どうしてでしょう?それは、現役で運用されているシステムの最新の仕様書がないからです。プログラムと仕様書の内容とが完全に一致していなけばなりませんが、タイムラグなく抜け漏れなく、最新の状態で同期がとれている自信がないからです。私がOSの開発をしていた時には、複数人、複数部署による何段階もの確認を経て完全に一致させていましたが、アプリケーションが動く地面(インフラ)であるOSの性格上、そうでなければリリースできません。一方、一般企業での情報システムで、そこまで厳密に同期をとっているところは少ないと思います。そう思うのは、多くの手間を食い、神経をすり減らすからです。しかし、基幹システム+関連する周辺システムが、当該企業にとっては日々の企業活動になくてはならない機能を提供していることを考えれば、当該企業にとってはOSのような位置づけになるはずです。これを考えれば、手間がかかる、神経を使うことが免罪符にはならないことが分かるでしょう。

 

しかし、ここまで考察しているCIOは少なく、CEO至っては限りなくゼロに近いのではないかと思います。そこに来てDXDXの大合唱。レガシーシステムだからDXが推進できない、レガシーシステムをマイグレーションしてモダナイズしていればDX推進ができるという単純な結びつけをするIT雑誌の軽薄な記事に踊らされてはいけません。

 

ISAを再度勉強し、基幹システム+関連する周辺システムが持っている情報を洗い出し、適宜それを参照・利用する環境を整え、それを利活用するためのスキル教育をOJTでやってみましょう。レガシーシステムが問題ではなく、残っていても問題なく、DXでいうところの狙いは達成できます。

 

※質問はosugisama@gmail.comにどうぞ!

※リブログを除き、本ブログの無断転載、流用を禁じます。。

このブログでは、時々IT系メディアのニュースを批判しています。特に、中身の薄い記事を平気で配信してくる場合には厳しく批判してきました。想像するに、記事を書く記者は泥をかぶり汗と恥をかきながらシステムを構築した経験がないのでしょう。レガシーシステムを批判する彼らですが、何十年もの間、その時々で利用可能な技術・製品を使って情報システムを作ってきた歴史を知らずに(調べずに)、何を聞きだそうとしてどの様な質問をし、得られた回答に更なる質問をして背景を理解し、事実を確認したか?と聞きたいものです。

 

情報システムが給与計算など一部業務のコンピュータ処理から、処理の対象となる業務が広がってきた経緯、そして全社全業務を包含する統合情報システム構築の必要性がうたわれ、経営を支援する戦略情報システムという概念が出てきた背景を理解しているのだろうか?戦略情報システム構築を指揮する情報システム担当役員(CIO)が出てきた経緯も知っておいて欲しいものです。初期には、そのCIOの位置づけが理解されずに、経理部長や人事部長、総務部長などが兼務したり横滑りした時代もありました。重大トラブルが続いたみずほ銀行のCIOは適材適所ではなく、適不適を問わず人事畑出身者が就任する指定席になっていたそうです。IT系専門誌の記者なら、こういう背景も理解しておくべきでしょう。


また、ブームに対する対応も調べておくべきでしょう。古くはOA、ERP、SISがあり、10年くらい前からはクラウド、ビッグデータ、データサイエンス、AI、そしてDXなどがあり、その都度起こるこの種のブームに迎合した上っ面な提灯記事を見ることが多々ありました。参考にされるIT系専門誌の記事を書く記者だったらブームの起こった背景を分析して欲しいものです。センセーショナルなキャッチで興味をひき、読んでもらえばOKという薄っぺらなことでは困ります。

 

今や、都知事3選を目指して立候補した小池さんが自治体DXと言い、厚労大臣の武見さんが医療DXで医療界を動かすと言ってしまう、猫も杓子もDXDXの大合唱です。

ブレーンと称する取巻きが、スローガンとして挙げておいた方が良い、話しをしておいた方が先見の明を持っていると思ってもらえると入れ知恵をしたのかもしれませんが、意味を理解して発言しているのかどうかは大いに疑問です。

 

で、そのDXですが、日経BPから配信されてきたものに、こんなものがありました。

さんざんローコード、ノーコードの開発ツールを紹介し、成功事例を喧伝しまくっていた日経BPが『いきなりツールを導入するのは最悪』とのこと。いや~参ったなぁ~!書いた記者は、日経系のIT雑誌が何を書いてきたのかを検証したのでしょうか?

 

DXブームに乗せられ、必要性を吟味せず、既存システムとの整合性も考慮せず、会社としてのシステム整備方針もなく、全体を俯瞰したスケジュールもなく、システムとは名ばかりの身の回り&当面の作業をパソコンで動かす事例が多数紹介されてきました。専門部署や外部業者に頼んでいては、時間も費用も掛かるので、ノ-コード、ローコードを使って自分でやりたいことをパソコンでやってしまおうということですが、ブームを煽るテレビのCMも見かけます。

豊川悦司演じる部長が、自ら画面を操作し、必要とする視点の情報分析をする機能を作ってしまうというものです。

それで良いのか?というブログを書いたこともありますが、それは過去のOAブームや、EUC/EUDブームを経験しているからです。この時何が起きたかは、調べれば誰でも分かります。簡単に言えば、人事異動でローテーションされた人が作ったメンテされない野良アプリが溢れてしまったということです。もちろん、仕様書とか他のシステムとの接続仕様書などはありません。その前に、その様々なツールを使って作った局所的アプリが、当該組織、企業全体のシステムから見て、どの様な位置づけにあるのかの全体像が見えないまま、気が付いたところ必要になったと思うところをノ-コード、ローコード開発ができるツールを使って作るわけです。OA(office automation)どころか、PA(personal automation)です。もちろん、PAでも構いませんが、それがどうして野良になってしまうのかです。便利な局所的最適解のアプリ一過性だったということです。

 

企業経営を情報システム面で支えるのが戦略情報システム(SIS)ですが、その構築方針は、ISA(information system architecture)と呼ばれるものです。この方針に従って、予算、開発規模、重要度、緊急度、開発力を勘案して順次整備して行く進め方を採用することが必要で、それを主導/指揮するのがCIOです。その様な見識を持ったCIOがいればいいのですが・・・どの様に進めれば良いのかを順番を以下に。

①ISAが定められていなかったら、最初にこれを作る

②当該組織、会社のシステム全体像を描く

③システム化スケジュールを作る

(既にシステム化している部分、非システム化部分の明確化)

④今回システム化対象業務・作業の選択

(予算、開発規模、重要度、緊急度、開発力を勘案)

⑤業務分析

⑥無理無駄の発見

⑦無理無駄とされた業務、作業を担当していた部署、人に説明

⑧無理無駄以外の残った業務・作業のシステム化検討

⑨情報システム部門が担当するもの

⑩ツールを使って現場がやるもの(現場にやってもらうもの)

⑩まで来て初めて、ツールの出番です。今までのようなHowtoが全面にでたDXでは整合性の取れない個別最適化の野良アプリの残骸の山が出来上がってしまうでしょう。

 

※質問はosugisama@gmail.comにどうぞ!

※リブログを除き、本ブログの無断転載、流用を禁じます。