杉浦技術士事務所のブログ

日経コンピュータの情報システム大賞を受賞（2003年）した病院の総合予約システムがあります。一般的な診察予約だけではなく、予約の込み具合を勘案したり、患者に不公平感を持たれないような診察順の表示、検査、手術、手術前後の入院に必要な空床管理、前提になる医師勤務スケジュール、台数が限られている特殊な検査を行う場合の予約を含んだ院内の有形無形なリソースを管理するリソースマネジメントシステムでもあり、予約と名のつく業務を全て包含する機能を持っていました。

 

この機能の中に、全端末が止まっていることを前提にしたメンテナンスを行う際、使っているパソコンがあるメンテ作業ができないので、誰も使っていないことを確認するための機能を入れました。使いようによってはどこに置かれたパソコンが使われている（使われていた）かを調べることができます。この機能のお蔭で、ルールを無視した操作、運用を行った事例を発見することができたことがあります。今は、操作履歴をトレースできる機能はセキュリティ製品にもありますが、我々のものは21年前です。

 

文章力養成を兼ねて、その日起こったことをトピックスとしてプロジェクトメンバ全員に報告する制度を運用していましたが、分院から緊急入院に必要なベッドの確保依頼があり、依頼を受けた本院の担当部署がシステムを操作してベッドを割り当てました。しかし依頼して来た分院が、依頼した本院に連絡なしにベッド割り当てをキャンセル。変な操作が行われたのではないかというトピックスが挙がってきました。抜粋はこれです。

ベッドの空き状況を参照しながら治療入院のために比較的長期のベッドを確保するための操作は以下のとおりです。

一定期間の空きを確保するために上掲の機能を使ってやりくりし、ようやくベッドを確保した本院担当に断りなく依頼した側がキャンセルしてしまいましたが、再発防止策としては、遅滞なく連絡することを徹底する！しかありません。

 

問題だったのは連絡してきた分院側師長が『翌日9時過ぎに連絡したから良いでしょう』＆『キャンセル操作をしていない』と主張したことでした。前者は遅すぎ、後者はウソ！彼女はキャンセル操作をしたことがバレないと思ったのでしょう。しかし、既述のようにどの端末（パソコン）からどのメニューからどの画面を開いたのかの履歴をトレースできる機能を用意していました。それによって、何時・何時・何分・何秒に何をしたかをリストアップすることができました。

残念ながら、誰がという情報はありませんが、端末が置かれている場所が分かるので、その時間、操作していたのは誰かを調べれば分かります。上掲のトレース結果を当該師長に見せ、『キャンセル操作をしていない』と事実ではないことを言ったことを認めさせました。良い意味でのお灸になったはずです。操作履歴のトレース機能が奏功した場面でしたが、この機能は21年前のものです。今は、不正操作で情報漏洩が起きないようなセキュリティ機能など、より進んだ機能を持った監視ツールが出ています。適宜これを使って、安心して使える環境を作れる時代になりました。

 

※明日からゴールデンウイークで本ブログも休みます。再開は5/7です。どちら様も楽しい連休でありますように！

 

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

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

よく本来の仕事という言葉を目にし、使います。特に、業務分析をし、無理無駄を省いて整理整頓する際にはこの言葉が飛び交います。毎日送られてくる案内メールにもその様な言葉が散りばめられています。

このよく聞く本来の仕事となに？医師の場合、かいつまんで挙げれば次のとおりです。

①患者を診察する

②診断を確定するために検査をオーダする

③検査結果を踏まえて、診断を下す（所見）

④所見を踏まえて、必要な処方をする（必要があれば、手術を行う）

⑥経過を観察する

⑦症状が改善すれば終診

⑧改善されなければ、原因特定のために新たな検査、あるいは他医にコンサルトする

 

これが医師にとっては本来の仕事です。では、本来の仕事ではないのはなに？文献調査、論文執筆、学会発表などがありますが、患者を診るということには直結しないものの医師としてステップアップするためのもの。これは本来の仕事ではないものの必要なものです。勤務医にとって不要なものは、外来患者数、手術件数、病床稼働率、新患増減など、経営状況に関するものです。しかし、経営を意識しない医師は経営陣から嫌われます。難しいところですが、医師は本来の仕事とそうでない仕事がはっきりしている職業だと思います。ジョブ型雇用という言葉が取り沙汰されていますが、医師はこのジョブ型雇用に分類される職業でしょう。言い方を変えれば、ジョブ型雇用の職業は、本来の仕事がはっきりしていて、付帯する仕事が少ない、あるいはない職業ということになります。話しが横道にそれてジョブ型雇用に飛んでしまいました、戻します。

 

実は、上掲の医師本来の仕事①～⑧の中に付帯的な仕事（作業）が隠れています。それは、検査オーダを出す手間、所見を書く手間、処方を出す手間です。あちこちの台帳、管理簿、関連書籍を見ながら、間違いないようにしなければならないこれらの仕事を、システムに代替えさせることで時間の短縮（手間の縮小）、間違いの減少（精神的負担軽減）が可能です。例えば、薬剤の処方の際に、当該症状では禁忌となっている薬剤、あるいは既に他科で処方されているとの組み合わせで処方には注意が必要な薬剤などを処方してしまった場合には、警告メッセージを表示することで、注意を喚起することができます。

ハイリスク薬も同様に誤って処方してしまうことを避けることができます。実際に山口県立総合医療センターでは、肺がんの患者が10日間にわたりステロイド薬を予定の11倍投与され、このミス発覚後、さらにモルヒネを予定の2倍投与され、その2日後に亡くなるうという医療ミスがありましたが、警告メッセージを出すようなロジックが組み込まれていれば、凡ミスを解消することができます。

以上は医師の例ですが、本来の仕事、付帯的仕事を分析し、付帯的仕事を外部に委託して効率を上げた牧場を経営する農業法人の例を紹介します。

 

ある時、テレビで鹿児島県の薩摩川内市にある、農業法人が紹介されていました。牧場という業種への先入観があったせいか、業務の見直し、無理のない合理的なコスト削減策が採られていたことに感心しました。簡単に言えば、以下のとおりです。
①本業と付帯的なものとを分ける
②本業を社員で行う
③付帯作業は、それを専門とする外部業者に任せる
全てを自社でまかなわないということですが、これはアウトソーシングの基本です。これを肉牛飼育に取り入れたのは社長ですが、この社長、アウトソーシングを知っていたわけではありません。当たり前にそう思ったということです。どこかで習ったとかではなく自然にそう思いついたわけですが、それが本当でしょう。習うものではなく、自ら考えつくものではないかと思います。社員の本業は、
①しっかり餌を食べているか
②体調はどうか
③いじめられている牛はないか
など、牛をしっかり観察することと定義しています。牛にも人間同様、引っ込み思案、自分優先などの性格があり、与えられた餌を我先に食べたり、十分食べられずに後ろで控えている牛が出てきたり、のけ者にされて❝引きこもり❞になってしまうものまでいるそうです。このことにより、製造業で言えば、製品にあたる牛の品質（肉質）の差がでてきてしまい、歩留まりが悪くなる原因になります。歩留まりが悪い＝製造コスト高となります。

 

①～③の状況を観察し、一緒のグループで飼う牛のクラス替えをしたり、具合の悪そうな牛は早めに獣医に診せるそうですが、手間がかかる仕事です。これらの作業を、藁の敷替えや排泄物の処理、牛舎の清掃作業をしつつ十分に行うことはできません。どこかで抜けがでてきます。そこでこれらの作業をそれを専門の外部業者に任せたわけです。もちろん、外注費が発生しますが、本業に注力できる分、一人の社員で管理できる牛の頭数を増やすことができます。この牧場では約5千頭もの牛を、わずか15人でみているとのことで平均の10倍以上の効率です。外注の支出を補ってあまりある生産性を達成しているといえるでしょう。補助金に頼ってきた感のある農家というかJA、補助金をチラつかせ選挙でと図る政治家の図式では、この様な知恵はでてきません。

アグリITという言葉が流行っていますが、この例はITではなくBPRです。何から何まで一人でこなすのが農業と思いがちですが、この様な事例もあります。付帯作業の外部委託だけではなく、十年一日の見方ではなく、視点を変えれば見えてくる景色も違ってきます。

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

 

製造業DX、小売業DX、自治体DX、医療DXなど、猫も杓子もDXDXを連呼！その結果、必然性を吟味しないままシステムとは呼べないその場しのぎ＆全体として統一のとれていないシステムが出来上がっているようです。一部の成功事例が喧伝されると、その背景を調べずに❝ウチも❞となり、IT関連の知識がなくてもシステム開発ができるローコード、ノーコード環境も出てきて、益々煽られる環境になってきました。

 

（必要のないシステムも含め）開発需要に追い付かない開発パワーを補うために、ローコード、ノーコードツールを使って現場がシステムを作る側に回って開発力を補うというケースも出て来ました。システムを作る場合、開発に着手する前に、そのシステムを作る必然性、仕様の吟味、開発費用に見合った効果の確認など、踏むべきプロセスがあります。しかし、DXブームではそれが置き去りにされたまま、とにかく作ることに目が行っています。そうではなく、地に足を付け、何のためにどの様な機能を持ったシステムが必要になるか、そのシステムによって何がどう変わり、改善され、作業負荷が軽減されると共に正確性を担保しつつ、無理なくスピーディな仕事ができるかという面に目を向けるクセをつけましょう。今日はその例を紹介します。

 

過去のブログでも紹介していますが、現場を教育して仕様を検討し、レビューし、必要な資料を作ってプレゼンする力を養ってきましたが、現場（プロジェクトメンバ）にシステム稼働前後を比較をさせた資料を紹介します。分かりやすく比較できるように、ワークシートを作り、そこに記入してもらいました。

表中のピンク字は私のコメントですが、作ったのはプロジェクトメンバの師長ですが、この比較表を作れるまでに育っています。診察予約業務をシステムに載せたことによるメリットデメリットを書いてもらい、これに私がコメントした事例を紹介します。

 

システムに載せた次回診察予約業務
①患者の希望日を聞き、医師勤務表を見ながら双方の都合がつく日をきめる。
②該当する医師の予約簿に患者の氏名、ID、電話番号を記入する。
③診察予約券（ピンク色の厚紙）に日付、Dr（印鑑）、備考欄に必要事項を記入して渡す。
④予約票をカルテに貼る
システムに載せたメリット
①予約簿が必要になる。
　－記入する必要がない。
　－捜す手間がいらない。
　－予約簿の補充頁の在庫が不要になる。
　－コピーが発生しない。
　－その他、紙ベースであることに起因する問題が解消する。
②机の上がすっきりする。
③患者の待ち時間が少なくなる。
④看護師は患者さんに対応する時間的精神的な余裕ができる。

システムに載せたことによるデメリット

①操作に慣れない当初は手間取る。
②メニューが消えてしまう心配はないか？

 

これに対して、コメント（赤字）することで双方向のやり取りとなり、理解を深めていくことができます。

 

システムに載せた業務（作業）
①患者の希望日を聞き、医師勤務表を見ながら双方の都合がつく日をきめる。
②該当する医師の予約簿に患者の氏名、ID、電話番号を記入する。
③診察予約券（ピンク色の厚紙）に日付、Dr（印鑑）、備考欄に必要事項を記入して渡す。
④予約票をカルテに貼る
メリット
①予約簿が必要になる。
　－記入する必要がない。作業改善／効率向上
　－捜す手間がいらない。作業改善／効率向上
　－予約簿の補充頁の在庫が不要になる。省資源！

　－コピーが発生しない。紙ベースでの仕事から解放される
　－その他、紙ベースであることに起因する問題が解消する。☜この時間を測定してください。　

②机の上がすっきりする。作業ミス軽減につながります。
③患者の待ち時間が少なくなる。もっともクレームが多いのが待ち時間。　
④看護師は患者さんに対応する時間的精神的な余裕ができる。その結果、満足度があがる　

デメリット

①操作に慣れない当初は手間取る。
一生懸命操作練習をして覚えてください。マウス中心なので操作はスグ慣れるはずですが、難しいのはシステムがの提供する様々な機能の理解です。臨機応変に機能を使いこなすまでにならないと実用にはなりません。習熟度を見るためにテスト（ペーパ、実技、口頭試問）をします。　
②メニューが消えてしまう心配はないか？
ありません。パソコンがダウンすることはありますが、この場合は予備機を用意しているので、即座に入れ替えます。入れ替えるのは事務長、次長、〇〇さん。私がいたら私。

 

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

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

 

毎日舞い込んでくるニュース、どうでも良いもの多数ですが、時々ブログネタになるようなものもあります。今日も一つ見つかりました。静的解析という初耳語でした。漢字の意味するところから、今迄机上デバッグと称していたものではないか？という察しがつきましたが、コードを実行せずにコードの品質、信頼性、および、セキュリティの検証を行う作業とのことなので、当たり！

デバッグには、仕様通りに動いているかを確認する工程がありますが、コンピュータ（当時はメインフレーム）を使って実際にプログラムを動かしてみるマシンデバッグと、プログラム（ソースコード）を目で追いながら頭で動かしてみる机上デバッグの2通りの方法があります。このうち、後者を静的解析と呼ぶようになったようですが、この記事には『 静的解析を行うと、アプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を開発の早い段階で特定できます』と書いてありました。この記事を書いた記者は、本当にそう思っているのでしょうか？多分、実際にプログラミング、デバッグをしたことがなく、歴史も知らない方ではないかと思います。今日は、これを取り上げます。

 

OSの開発をしている時、デバッグ作業に明け暮れたことを思い出しますが、当時はマシンデバッグしないと検査に回すことができませんでした。要するに、基本的に机上デバックでは検査に送ることができないということです。時代はメインフレームからサーバ、パソコンに代わっても、これは同じはずで、ましてや『 静的解析を行うと、アプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を開発の早い段階で特定できる』などと思う技術者はいないと思います。それはともかく、机上デバッグはいつやるのでしょう？

 

作った処理が機能するかをマシンデバッグする前に、プログラムコードを眺め、仕様通りの処理をしていることを何度も確認するという作業が机上デバッグです。入念な机上デバッグをしてからコンピュータ上で動かして機能通り動いているかを確認するマシンデバッグをするわけですが、一台数億、十数億する高価なメインフレームコンピュータを無駄に使わないということも、マシンデバッグ前に机上デバッグを入念にやりなさいというルールになっていた理由の一つになっていたと思います。決して 『静的解析を行うと、アプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を開発の早い段階で特定できます』ということではありません。

 

この記事を書いた記者は、静的解析をすると早い段階でアプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を発見できるという根拠を検証したのでしょうか？コードを実行せずに机上でのデバッグ作業の方が精度高いチェックができるはずがありません。

 

机上デバッグを静的解析と言い換えても、コードを実行せずに机上での動きをチェックすることに違いはありません。以下は、OS開発時に行っていた仕様が決まった以降の開発プロセスです。

 

①仕様に基づいてコーディングする（プログラミングする）

②書いたコードを見直し、正確に仕様を反映しているかを机上で確認する

③標準コーディングなど、過去の経験を反映したコード規則に従っているかもチェックする

④関係者でレビューを実施する

⑤レビュー結果を反映する

⑥再度机上デバックを行う

⑦上長の承認を得る

⑧マシンデバッグを行う

⑨デバッグ結果を反映する

⑩上長の承認を得る

⑪検査に回す

 

これを見れば、『 静的解析を行うと、アプリケーションの安全性とセキュリティを損なう可能性のあるバグとセキュリティの脆弱性を開発の早い段階で特定できます』という主張に根本的な認識の違いがあることが分かるはずです。現場を知らない実務経験のない記者の書いた記事を専門誌の記事だからといって、鵜呑みにしては危険だということを理解されたと思います。あくまでも実機検証（マシンデバッグ）が必要で、机上デバッグを静的解析と言葉を変えても、その位置づけは変わらないことを理解しておくべきです。

 

今回は静的解析でしたが、この様な新しい言い方が出て来る昨今です。新語に出くわした場合、慌てることなくこの言葉は昔なんと言っていたのかを調べることを勧めます。正に温故知新です。

 

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

DXという地に足のつかないブーム（ブームは大概そうですが）に乗せられ、ISA（information system architecture）を作らず、十分な計画を持たずに手あたり次第にシステム（というほどのものではないツールのようなもの）を作ろうとしています。プログラミングを知らない人向けにローコード、ノーコードという開発支援ツールも出てきて、システム内製化を図ろうとしています。しかし、システム内製化とは、そんな浮ついたものではありません。どのような基準でそのシステムを開発する必要性を判断し、どの様な順番で整備して行くかを決め、ISAに基づいた最終形を描き、それに向けて具体的な仕様を決め、開発していくことが求められます。決して五月雨的であっていけません。全体の整合性がとれないからです。

 

開発を外部のSIerに頼みたいが、費用が掛かるし、SEの質が悪くて、出来上がりの品質も悪い！そこでシステムを社内で、という内製化の動きが出て来たのが10数年前。こんな本も出ていました。

私は昔から現場を育てて仕様を作ってもらう方法を採ってきましたが、今でいうシステム内製化です。どの様に育てて来たのかは既に何回も書いてきましたが、仕様を作ったあと、必ずそれで良いのかを関係者が集まってレビューを行います。レビューの方法も既に幾度となく書いてきましたが、レビュー結果を議事録としてプロジェクトメンバ全員に回覧すると共に、速報で流しました。こうすることによって、やろう！という意識を高める効果を狙ったわけです。

 

ある日の集中レビュー結果を速報で流した事例を少し長いものですが、臨場感があるので原文のまま紹介します。（委員名は隠しています）

～～～～～～～～～レビューサマリ～～～～～～～～～～～～～

１．検査委員（7：00～8：00）

　コンビニ機能にある検査履歴参照をクリックした際の表示方法につき、レビュー実施。

　〇きれいにまとまっている

　〇表示の基本方針を明確にすること

　　－過去の全ての検査履歴を表示する（適宜スクロール）

　　－直近の検査を先頭に持ってくる（現病歴の検査を先頭に持ってくる）

　　－それ以降は時系列

　〇グラフにする検査項目を指定できること

　〇グラフ表示された検査項目を消去できること

　〇視力、眼圧など基本的な検査項目は最初からグラフ表示しておく

　〇検査項目により、スケールファクタが違うので、見やすくするために、色、線の太さ、種類を適宜できる

２．検査委員、医事会計委員（7：00～8：00）

　患者より依頼された書類、証明書の発行に際し、必要となる検査は予め決まっているが、その検査が予約の必要なものであった場合の取り扱いにつきレビューを行った。

　〇Drの追加検査処置で指定されたものが予約の必要であったものの取り扱いと同じにする。

　〇予約して検査を受ける患者に予約のメリットを実感してもらうためには、割り込みはしない。

　〇Drの判断で予約患者を押しのけてまで検査をする緊急性のある場合には、検査中の患者が終わったら、当該患者の検査を行う。

　〇その際、検査指示をしたDr名、検査種類のデータを取っておく

３．コンタクト委員、医事会計委員（8：45～10：10）

　コンタクトでは、診察、検査を待つ場合、待ち時間が長いと一旦帰ってから出直してくるという患者が散見される。新システムになった時には、どうなるのかにつき、ディスカッションした。

　〇何時まで待てば良いのかが分らないので、一旦帰宅すると考えられる

　〇しかし、適当な時間で再来院されても、順番は保証できない

　〇待ち状態を表示することで、おおよその時間を把握できるようにする

　〇コンタクト可否の診察は時間を取られないので、コンタクト担当Drを２名ほど決めておき、そのDrの待ち行列に登録し、現在診察中の患者の診察が終わった段階で、診察を受けて貰う。

　〇割り込むことになるので、他の診察待ち患者の理解を得られるよう“コンタクト適用可否診断のため、先に診察”というメッセージを表示。

　〇一旦出直すと、前回は引き継がないので、新たに受け付けをしなければならないことも周知する

４．薬剤師委員（10：15～11：45）

　既に調剤済みで薬袋が病棟にある退院患者の処方に変更があった場合、および、Drが一旦だした退院処方を変更した場合に、薬剤師が薬局にいなかった場合の処置につき、検討した。

　〇前者についは、変更前後の新旧処方情報を表示し、薬袋を印刷し、変更後の処方に基づいて調剤し、調剤日と薬剤師名を入力した段階で、病棟パソコンに“退院処方調剤済みの××様の処方に変更があり、新処方に基づき調剤しました。薬袋を交換するので、薬局までお願いします”というメッセージを表示する。持って来たら交換する。間違い防止のために、変更薬剤が少なくても薬袋毎交換とする。

　〇後者は、変更が発生したら、薬剤師に持たせた携帯にメッセージを送り、戻ってきてもらう。

５．病棟委員（13：15～15：00）

　手術に必要な書類など、当院が要請したもの以外の書類を受け取った際の処理につき、画面を元にレビュー。

　〇手術が予定されている患者とそうではない患者の場合とに分けて考える

　〇前者は、既にプロト開発に回している通り。後者は別画面を作るが、ほぼ流用可能（発行機関名、書類名）。

　〇プロト開発に回しているものに追加機能が必要なことが判明。

　　- スキャンした中に、新聞の切り抜きのコピーなど、まったく無関係なものが混じっていた場合、これを削除する機能をつける

　　- 捺印もれ、本人、保証人が同じ印鑑、本人、保証人が逆に書かれているなど、不備に気がついた場合、既に登録してある書類の✔を外す処理が必要。正しい書類は上書きではなく、追加にし、誤った書類も参照できるようにしておく。

６．臨床検査委員（15：20～17：30）

　検査業者に外注した検査の管理につき、委員会で指摘された事項を反映した画面を元にレビュー実施。

　〇推移参照機能は、検索機能として別メニューに移し、依頼、受領、登録機能だけにする。

　〇外来処置が処置した結果（物、情報）のうち、情報につき未検討であることが判明。

　〇外来処置が終わった（例えば採血）というイベントを捉え、指定された検査業者のフォルダに当該依頼情報が書き込まれるようにする。

　〇臨検担当者は、メインメニュー → 臨検メニュー → 検査依頼 →検査業者指定 → 指定された検査業者名で依頼案件をピックアップ→画面表示、印刷（依頼一覧表）→依頼案件を確認→依頼一覧表を検査依頼する物と一緒に置く・・・検査業者が取りに来る→依頼一覧表と依頼物を照合 → 署名 →検査結果持参時にこの用紙を持ってくる→臨検担当者は依頼案件と検査結果を照合→合致していたら受領署名する→検査業者に渡す→検査業者はこれが請求の根拠になるなお、当院としては渡した、受け取ったの情報は画面から行う。

 ７．外来委員（17：45～19：15）

   血清点眼、フィブロネクチン点眼処理につき、画面を元にレビュー。

　〇血清点眼製造には時間を要するので、Drの指示が診察後という指示がなければ、受付したら視力眼圧などの検査の前に外来処置で採血を行う。（ロイコカード印字にて案内）

　〇患者が希望する点眼本数によって、スピッツ本数（１０cc／本）が決まる（対応表あり）。

　〇この本数分、スピッツラベルを印刷する

　〇採血終了操作をすると、薬局に、“○○様の血清点眼をお願いします”のメッセージが表示される・・・必要？

　〇採血担当者は薬局にスピッツを持って行く・・・もっていけばメッセージをださなくても良いのではないか？

　外来委員の担当分のプロト開発仕様作成はこれにて終了！ご苦労様でした。

～～～～～～～～～～～～ここまで～～～～～～～～～～～～

この様に、仕様を自分で作っているので自信を持ってレビューできます。システム内製化をするなら、ここまでやらなければなりません。仕様はシステムの骨格・基本で、開発支援ツールなどでカバーできるものではありません。とかくHowtoに走りがちですが、Why、Whatが先にあるべきです。

 

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

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

 

日本のGDPがドイツに抜かれたと大騒ぎしたのが2月。ドイツのシュピーゲル誌にも紹介されていました。

しかし･･･大したことがないのに大騒ぎし、大したことではないのですぐ忘れたり、飽きて別の話題に飛びつくという日本人特有の性格なのか分かりませんが、今はどこへやら！もっとも、GDPがドイツに抜かれたのは円安とドイツのインフレによる影響が大きく、NHK国際ニュースナビを見ると実質抜かれていないという数字がありました。

抜かれたという実態がこういうことなので、気にしていない･･･人口比を考慮すると少しは気にした方が良いのではないかと思いますが･･･ドイツと日本の生産性の違いが指摘されていました。これは大いに気にしなければならないと思います。

先進7ヵ国中最下位！実は昨年だけのことではなく、何年も続いています。日本の労働生産性が低い理由として、遅くまで残っていることが会社に対する忠誠心の現れという旧態依然とした意識が根強く、給与が時間基準であり、効率を上げるという意識が低いことなどが挙げられています。酔わないと本音が言えないのか、飲みにケーションとやらで遅くなることも珍しくありません。この仕事、今やることかと思うものや、同じ様な資料を複数作ったり、どうでも良いことを書き直させられたりすることもありましたが、バカバカしいと思いつつもやってきたのがサラリーマン時代でした。今も続いていると思います。そんな中、こんな本を見つけました。『どうでもいい仕事』･･･

著者のグレーバーはNY生まれの経済評論家ですが、どうでもいい仕事のことをブルシット・ジョブと呼ぶのだそうです。彼の定義するブルシット・ジョブをそのまま流用すると次のとおりです。

①誰かを偉そうに見せるための取り巻き（受付係、ドアマンなど）

②雇用主のために他人を脅迫したり欺いたりする脅し屋（ロビイスト、顧問弁護士など）

③誰かの欠陥を取り繕う尻ぬぐい（バグだらけのコードを修復するプログラマーなど）

④誰も真剣に読まないドキュメントを延々と作る書類穴埋め人（パワーポイントを量産するコンサルタントなど）

⑤人に仕事を割り振るだけのタスクマスター（中間管理職など）

 

必要性を理解していない③や、⑤の手配師的な仕事をする人がいないとプロジェクトが進まないことを知らない実務経験のない評論家ならでは見方や（ ）内コメントに異論はあるものの、思い当たるものがあります。私は日本の最たるブルシット・ジョブは、ほとんど実行する気のないセレモニ的な中期経営計画策定のための資料作りを筆頭に、不要不急な資料作成や、どうでもいい会議ではないかと思っています。特に会議は、その回数、勤務時間に占める会議時間、時間当たりの生産性などから見れば、最たるブルシット・ジョブだと思います。その理由をザッと挙げてみると以下のとおりです。

 

①議題がなんであるかを知らないまま出席する者がいる

②議題を理解しないまま出席する

③会議時間内では見切れない量の資料が配布される
④持ち帰っても見ない
⑤意見を述べない発言０の出席者多数

⑥不必要に参加を要請される部門もある

 

箔をつけるためか、出席人数が多い／職位が高い者が多く参加するほど重要な会議という認識もあります。その出席者が上記①～⑥というのだから、困ったものです。また、トップが招集し議長を務めるところでは、『何か意見、質問はありませんか』に対して質問すると不機嫌になるという場面に何回も出くわしました。あまり触れたくないことへの質問だったり確認だったりすると『話を聞いていたのか』、『それは今ここで話すことではない』など、あからさまな質問封じをするのには呆れたことも多々ありました。私の先輩が、天皇と呼ばれて君臨していた社長に質問したことをきっかけに左遷されたのには驚きましたが、会議も質問も命がけです。生産性の高い会議など望むべくもありません。もちろんそうではない会議もありますが、稀！

 

生産性の低い会議は、日本だけかと思ったら米国でもあるようです。

いずこも同じ秋の夕暮れですが、それをやっても労働生産性の高い米国は、本物の会議の方が多いのでしょう。生産性のない会議は即座に廃止すべきですが、メンツをつぶされると感じる主催者は抵抗するでしょう。しかし、それをやらないと何時まで経っても先進７ヵ国中最低の労働生産性は上がらず、GDPにも影響を及ぼすのを避けられないでしょう。

 

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

医療関係者向けに情報を提供しているところから毎日送られてくるニュースを見ていたら、沖縄タイムスの記事を流用したものでしたが、こんなものを見つけました。

92歳でなお且つ、健康に貢献したいという心意気は大したものですが、電子カルテが操作できないし、紙のカルテに書く文字も悪筆で読めないという二重苦状態。そのため、医師紹介サイトから紹介されたこの医師との契約を破棄したところ、契約通り金を払えという判決になったそうです。採用に先だった面接で『電子カルテは使えるようになれるか』を確認し、『やれる』という言質を得ていたら判決は別のものになっていたと思います。なお、この老医師は悪筆！読めない字を書くとのことですが、生来の悪筆は確かにいて、クライアントの病院で経験しています。で、その医師はこんな字を書いていました。

他にもアラビア文字のような字を書く医師がいましたが、見慣れている診察介助ナースに翻訳してもらいました。処方欄に書かれた薬剤名を読み間違えたこともありました。例えば、クラビットとタリビットを悪筆のため読み誤り、医事職員がそのまま入力して処方箋を出してしまい、薬局からの連絡で間違いに気がついた例が実際にありました。これはヒヤリハット事例にもなる問題でしたが、手書きではなく、キーボード入力orマウスによる選択にすることで解決できます。しかし、今回沖縄タイムスで紹介されていた超高齢医師は、読めない字を書くし、キーボード、マウス操作もできないので、どうしょうもありません。そもそも、この医師の若かりし頃に書いたカルテで問題が起きなかったのが不思議です。悪筆は治りませんが、こんな本があります！

 

一般的に、超高齢者にパソコンを自在に操れる人は極少数だし、実務を伴わない名誉職ではなく、医師として臨床現場でやっていけると思って雇用契約を交わした側の判断ミス。その前に92歳のこの老医師は、人の健康を預かるという自覚をしているのかどうか疑わしいと思います。生活習慣病という言葉をつくり、予防医療や終末期医療の普及に尽力した聖路加国際病院の名誉院長だった日野原さんは、105歳で亡くなるまで病室を回っていたそうですが、これは特別なケースです。

そういえば、時代にそぐわない感覚の老女医（副院長）に実際に出くわしたことがあります。創業者一族と仲が良かったこの医師、医者としてのプライドが高すぎて手に負えませんでした。患者を診るのではなく、診てやるといういわゆるお医者様感覚の持ち主、自分がルールという唯我独尊の持ち主でもありました。システム構築に先立って業務分析する際、その老女医の無理無駄な作業の流れを是正しようとしましたが、創業者からは『患者さんの信頼が厚い〇〇先生なので、彼女のやりたいようにやらせてあげて欲しい』との要請が幾度となくありました。彼女はそうなるように創業者一族に働きかけていたのでしょう。

 

この老女医、一回で済ませるところを検査オーダを何回にも分けて検査に回すなど、効率が悪すぎ、患者の待ち時間も長くなり、患者のイライラを募らせる要因になることもやっていたことが分析の結果分かってきました。

この可視化したデータを見せても頑として診察スタイルを変えず、それを看過する創業者一族には呆れましたが、最後まで抵抗していたリソースマネジメントの発想を取り入れた総合予約システムを稼働させました。このシステムは日経コンピュータの情報システム大賞を受賞しています。

予約制にシフトすると外来患者数が減ってしまうというジンクスがあり、老女医とそれに同調する創業者一族が、これを盾に陰に陽に抵抗してきましたが、このジンクスの主たる原因は、予約システムは簡単にできると考えたために起きたもので、機能、操作性に現場の実態が反映されていないこと、および運用ノウハウがないためです。下図に示すように予約制と来院数には何も関係がありません。

老女医は『県民性として、人に強制されることを嫌う傾向にある』などと持論を展開して予約制に最後まで反対していました。これ以外にもクレームをつけてきましたが、最たるものはこの県民性でした。『都会からきたアンタには、それが理解できない』という屁理屈でしたが･･･実は、優先して診察する必要のない知り合いを優先して診察するなど、今迄自分の裁量で診察順を変更できたことができなくなることへの不満が根底にありました。

 

もちろん、杓子定規な予約制ではなく緊急性のある患者や身障者、幼い子を連れている患者など、考慮すべき事情を抱えている患者は、優先して診察できる機能を用意してありました。順番を飛び越すことになるその場合、当該患者の表示欄に赤字で緊急診察など事情に応じて順番を飛び越す理由を表示するので、待っている患者は納得してくれます。そうではない、優遇してもらうことを前提に来院する老女医の知り合いのように、順番を飛び越えて診察される理由が見当たらない患者がいると投書箱に苦情が入ることになります･･･この老女医がやっていたような恣意的な順番の変更がしにくくなったというわけです。

 

92歳の超高齢医師のニュースを見て、自分の采配でどうにでもできるという独裁者の雰囲気を漂わせていたこの老女医を思い出した次第です。

 

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

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

1980年後半から1990年初めにかけ、バブル景気を反映してかメインフレームの黄金期でした。メインフレームと言っても知らない人が多数を占める今ですが、大型冷蔵庫のような大きさの箱（コンピュータ）が空調の効いた専用の部屋（電算室）に何台も置かれいた大型コンピュータのことです。

空調は大量の熱を発生するメインフレームコンピュータを冷やすために必須な設備でしたが、高性能なほど発生する熱量が多く、空冷ではなく水冷が使われることもありました。それほど熱の対策が重要だったのが、当時のコンピュータ。運用するのは、専門教育を受けた要員からなる情報システム部門でした。

 

最初に手を付けたのが給与計算のような大量一括処理が得意なコンピュータ向けの業務でしたが、そのうち人手を費やしていた生産管理、それをサポートする部品展開、在庫管理、発注管理、出荷管理業務がシステムに載せられてきました。効果の出やすい業務だったのが製造業の生産現場だったからです。自動製図機など、周辺機器の充実と共に、次に目が行ったのが設計部門でした。製図版、T定規、三角定規、コンパスなどを使っていた設計業務を、画面上で行うCAD（Computer aided design）の登場です。

 

CADの結果得られた製造に必要な加工情報を工作機械に送り、実際の製品の加工を行う（製造する）CAM（Computer aided Manufacturing）も登場しました。この二つを併せてCADAM（キャダム）と称していたのが、1985年くらいのことです。コンピュータの性能向上、周辺機器の充実から、実際に物を作らず（試作せず）にコンピュータ上でシミュレーションするというCAE（Computer aided enginering）がでてきました。CAEという言葉がまだない1974年、自動製図機を使ってよりきれいに研磨できる機械の構造を数式化してシミュレーションをしたことがありますが、これが自動製図機ではなく画面になり、シミュレーション結果を得るまでの時間も大幅に短縮されました。

 

CAD、CAM、CAEと来ましたが、これらを統合した概念としてCIM（Computer Integrated Manufacturing）が登場しましたが、個々の業務のシステム化ではなく、最初に大きな方針があり、その方針を具現化する個別システムがあるという統合情報システムの概念がでてきました。これは、当時言われていた経営戦略を支援するためのシステム＝戦略情報システムを整備するための目標でもありました。包含関係で言えば、個別システム（CAD、CAM、CAE）⊆ CIM ⊆ 戦略情報システム ⊆ 統合情報システムということになるでしょう。最初にコンセプト（全体構想、設計）あり！です。設計図なしに家を建て始めることはできませんが、情報システムに関しては台所を作り、トイレを作り、風呂場を作るという作業が先になっていたと思います。

 

包含関係で示した最上流は統合情報システムという概念ですが、これが当該組織に於ける全体を俯瞰した情報システムです。最終的に統合情報システムが完成するよう予算、時間、優先度を勘案しながら、それを構成する要素としての個別システムを整備してゆくことになりますが、これが取りも直さず今でいうところのDXを実現することになるわけです。オッとDXの前にERP（Enterprise Resource Planning）がブームになったことがありました。企業の持つ資金や人材、設備、資材、情報など様々な資源を統合的に管理・配分し、業務の効率化や経営の全体最適を目指し、そのために必要な機能を持った情報システム群のパッケージという位置づけでした。これも、大きな括りで言えば、統合情報システムのコンセプトに包含されます。

 

派閥力学が効き、消去法で首相になった感のある岸田さんが目玉としている政策の一つだからでしょうか、付和雷同にDXが連呼されています。しかし今まで述べ来たことを読み、理解していただいた読者の皆さんは、統合情報システムという概念と同じだということが分かると思います。医療DX、自治体DX、何とかDXなど、全ての業界業種にDXを付けて騒いでいますが、統合情報システムのコンセプトを理解して、計画的にシステム整備をしてきた企業、組織にとっては、DXブームに踊らされることなく、迎合する必要もなく、冷静に対処しているはずです。

 

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

毎日配信されてくるIT系push情報に、こんなものがありました。

700社が1台ずつなのか、1社で複数台使っているのかは分かりませんが、メインフレームということからして、銀行、官公庁、大企業に使われているものと推測できます。保守が大変なものの、安定稼働を続けていることやOSの構造が公開されていないことから外部からのアタックがない（できない）ことが大きな理由になっていると思います。特に、経営の根幹を処理対象にしている基幹システムをメインフレームで動かしている場合には、安定さとアタックを受けないということへでメインフレームへの評価が高くなるのは当然で、そう簡単にはリプレースできないでしょう。

 

それ以外の理由を見つけるとすれば、それは処理の改変（update）が大変だということでしょう。COBOLで作られているこれらのシステムは、COBOLの使いこなす団塊の世代を中心とした技術者が退職してしまった今、怖くて触れないというのが本当のところでしょう。また、全体像を把握することができる者がいないなかで、見える（理解できている）範囲内で改廃変更するとどこにどのような影響があるのか把握できないという問題もあります。

 

❝どこにどのような影響が把握できない❞とならないためにあるのが仕様書です。しかし、1970年～1980年代のメインフレーム全盛の時代が去ってから40年近くなる今、その仕様書が、膨大な基幹システムとそれにつながるサブシステムとの接続仕様まで含んで、仕様書に書かれていることとソースコードと完全に同期がとれていることを保証できなくなっていると思います。怖くて触れないし、どうしてもという時には膨大な工数をかけて微に入り細に亘ってテストして不具合が起きないようにしなければなりません。しかし、タイミングや複数のリクエストがあった時の沈み込みなど、テスト方法についてのレビューをしても、テスト環境を作りにくいテストをするのは大変です。時間をかけてもできないかもしれません。JRの座席予約システムや都銀のシステムのような何千何万の端末からの処理を捌くシステムでは、全てのテストパターンを洗い出すことすら難しいことです。

 

1970年～1990年代、年情報を西暦下2桁で処理してきた日付管理が、2000年になると下２桁が00になって1900年になったしまうという情報システムの2000年問題がありました。2000年はまだ先のことだと思っていて悠長に構えていた関係者は大いに慌てましたが、この伝と同じで、悠長に構えていたツケがメインフレーム、COBOL問題です。まだ先だとか、できない理由を並べてズルズルとメインフレームを使い続けて来たCIOはじめ、情報システム関係者は大いに反省すべきです。彼らは、高性能パソコン、サーバ、高速なネットワーク環境の登場を見て、メインフレーム時代の終焉を見通せなかったか･･･

 

今正しくDXブームですが、経営戦略を情報システム支えるというSIS（戦略情報システム）が叫ばれ、組織内の有形無形なリソースを有機的に睦びつけた統合情報システムが叫ばれた1990年代に真面目に取り組んでいれば、DXという言葉に慌てることないはずです。『DXそれは、昔統合情報システムと呼んでいたもので、うちは30年以上前から取り組み、既に完成しています』と胸を張って言い、『ただし、昔はメインフレーム環境で動いていたものが、今はクライアントサーバ型、クラウド型環境になっただけのことです』と言えるはずです。

 

DX時代と言われ、クラウド環境、ネットワーク環境を前提としたシステム開発に適していないCOBOLで作られたシステムを今後どうするのかもメインフレーム問題と切っても切れない問題です。日経XTECHの学びたくない言語アンケートの筆頭がCOBOLになっていますが、この状態で、メインフレーム上で動くCOBOLシステムをどうするかが喫緊の問題でしょう。

将来を見渡せば、COBOLをエンハンスしてDX時代に適した機能をつけてもらうか、思い切って他の言語で作り替えるかの選択を迫られます。前者の方が安全ですが、COBOLの元締めであるCODASYL（Conference on Data Systems Language）がどこまでやるのか分かりません。各企業のCIOは頭を悩ますことでしょうが、私がCIOならどうする？経営陣を説得して予算をだしてもらい、今風の言語でrecordingします。もちろん、データーベースはベンダ固有のものではなく、オープン環境のものを使います。

 

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