#4654 不便な受付システム変更：人の対応でしっかりカバー Nov. 17, 2021

　前回#4653の続編ですから、読んでいない方はそちらもお読みください。　

　8時15分に病院へ到着、自動診察受付機に診察カードを通したが、あいかわらず同じ表示「期限切れのため保険証の確認要求」が出てます。受付カウンターがオープンするのは8時半だが、カーテンの向こうではすでに仕事が始まっている様子。3分後にもう一度やってみたら、「受付履歴がないか受付済み」の表示。自分ではまだ受付処理していないので、なんだかわけがわからない。受付の女性が患者の呼び出しのために外へ出てきたので、事情を話すと、「診察券をお預かりします」と言って引っ込んだ。
　8時30分になってカーテンが開き、仕事が始まった。診察カウンターの方で名前を呼ばれたので、行くと診察票を渡された。数分後に受付カウンターで名前を呼び声がしたので行くと、保険証と診察カードを返却してくれた、受付処理がなされていると説明があった。システム上の不具合があっても、てきぱき処理してくれました。朝一番の忙しい時にスムーズな対応、ありがとう。

　診察予約時間は8時半～9時までである。受付番号は40番だが、割り込み処理がなされたようで2番目くらいに眼科受付がなされ、すぐに2番の部屋で網膜検査、5番の部屋で視野検査をしてもらう。「コロナが収まってよかった、このまま増えないでほしい」と男性の検査担当の人が言う。そのとおりだ、増えたら病院も通院している患者も、入院予定の患者もみんなたいへんだから。
　次回の予約を入れてくれた。3/1に眼底検査をする。白内障の手術をしたほうの目が緑内障の前駆症状があるので、定期的な眼底検査が必要なのだ。白内障手術をしてくれた眼科の大谷先生に定期的に診察をしてもらえると安心である。

　事務処理の流れを考えると、診察受付処理の前に保険証の確認処理は合理的ではある。予約がある場合は朝7時前に行って受付処理をしなくてよいのかもしれない。予約時間の30分前に行ってやればよいだけ。年に2度しか市立病院を利用しないわたしが事情を知らないだけだろう。
　予約がない時は、朝早く行って診察受付処理しないと待ち時間が2時間くらいになってしまう。予約がない時は前日に保険証確認をしに病院へ行くのは不便だ。受付カウンターが開いてから、保険証の確認を済ませ、自動受付機へ診察カードを通したのでは、受付番号がずっと後の方になる。受け付けた順番に番号が発行され、その順番で診察が行われるからだ。
　予約のない時は保険証確認が済んでいなくても自動受付機で処理を拒否しないでもらいたい。受付カウンターが開いてから、後付けで保険証の確認処理ができるような流れに戻してもらえたらありがたい。
　何か理由があってシステム変更したのだろう。だが、それは事務処理の都合だけで、利用者の不便を前提に事務処理の合理化がなされるようなことがあってはならないと思う。システム改善が必要なことはよくわかるので、利用者目線でのシステム変更のチェックを心がけてもらいたい。

*投稿欄をご覧ください。病院のシステム関係者の投稿だと、半年以上受診していないと自動診察受付機がエラー処理するような設計になっているそうです。眼科で白内障の手術は年間200-250件ほどですから、その後半年に一度の定期検診数を3年分と仮定すると600-750人が半年先の予約をしているはず。プログラムのエラー処理部分を180日から210日に変更するだけでいいのですから、変更によって他に不具合がなければ管理者と話し合って変更をお願いしたい。


にほんブログ村

コメント 26

仕様　変更　ない
運用　が　事務　目線　な　だけ
保険　確認　半年　未確認　エラー
理由　事務　混雑　さける　


by もち (2021-11-17 14:07) 

もちさん

仕様変更なしですか。
半年間、保険証の確認がなければ、自動受付機での受付処理でエラーではじくようになっているのですね。
前回も半年で受診していますが、半年以内にぎりぎり入っていたということのようですね。今回は半年を過ぎていた。
半年ではなくて、1年間にプログラムを直すだけで、OKなら、管理者と話し合ってください。5分でプログラム直せるでしょう？何か不都合がありますか？
眼科は半年先の予約が普通にあります。次の予約は3/1ですから、エラーには引っ掛かりませんが、眼科受診で引っかかる人がいるかもしれません。
どうやら診療の実態を知らないSEの仕事のようですね。ユーザー側（事務部門）も気がついていない。
気がついたら直せばいいのです。作業は簡単。
by ebisu (2021-11-17 15:38) 

半年に一度しか通院しない高齢者は稀なのでしょうね。
わたしはスキルス胃癌で全摘しているので3か月に一度、岡田医院で定期検診してもらっています。
市立病院の受信は眼科だけですから、半年を過ぎることがあります。予約が前倒しになるときはセーフ、後ろ倒しになればアウト。（笑）
眼科の診療実態を考慮すれば「180」を「210」に修正していただければ、実際上はエラー処理に遭わずにすみます。考慮をお願いします。
by ebisu (2021-11-17 16:10) 

管理部　要望　仕様
事務　確認　増える　面倒
機械　で　はじく
事務　作業　減る
by もち (2021-11-17 16:45) 

●「管理部　要望　仕様」

ユーザー部門のひとつである事務部門の要望を聞いて仕様に織り込んだということのようですね。
病院システムのユーザーは事務部門や診療部門だけではありません。患者もユーザーの一人。自動診察受付機を利用しているのは患者なのですから、眼科の診療の実態と受付操作をする患者を考慮に入れなかったのは仕事としては「？マーク」がつきませんか？ベンダーのSEの仕事だったのでしょうか？
こういうレベルの仕事をする人をわたしは「御用聞き」と呼びます。プロとしての仕事の基本がなっていない。

「事務　確認　増える　面倒」と書いてありますが、何がどのように面倒なのでしょう。180日を210日に変更することで事務部門に「具体的にどのような余計な負荷」がかかるのか、しっかり調べて総合判断するのがシステム設計者、あるいはメンテナンス要員の役割です。
ユーザー部門が素人集団ならなおさら担当SEあるいはメンテナンス要員の仕事の責任は重い。

それはそうとして、180日を210日にして生ずる不都合を具体的に書けますか？
いい仕事すれば溜まっているストレスが発散できると思いますが、いかが？
他人の仕事の後始末も大事な仕事です。
by ebisu (2021-11-17 23:20) 

「事務　確認　増える　面倒」
会計時　保険　確認　増え　患者　待たせる
患者　当日　保険　持参　しない
患者　保険　切替　確認　できない　処方箋の保険直し

仕様は　病院幹部　が　策定
ベンダーSEなど　メンテナンス要員　仕様設計　介入　できない

180日を210日　変更　問題ない
by もち (2021-11-18 10:03) 

持ちさん回答ありがとう。

①会計時　保険　確認　増え　患者　待たせる
②患者　当日　保険　持参　しない
③患者　保険　切替　確認　できない　処方箋の保険直し

①の会計時の保険証確認は通常の流れでやっているので、「180日⇒210日」の変更には関係がありません。
②の当日保険証持参してきていないケースは会計の時に判明するのでこれも関係なしでしょう。予約があって半年通院していないケースだけをエラーではじく意味はないと思います。
③の保険証の切り替えは、たとえば70歳の老人で3割から1割負担の切り替えケースが考えられますが、これも通常処理は会計時に保険証確認で判明するものです。予約の場合で、半年受診していないものだけをエラー処理する意味はなさそうにみえます。実際に私の場合は該当していません。

③のケースを防ぐには、毎月初めて受診するときに、会計の前に保険証確認をする事務の流れにすれば解決できる問題ではないでしょうか。「受付カウンターで保険証の提示・確認をお願いします」と表示すればいいだけではないでしょうか。受付番号票に印刷されるようになっていればもっといい。
診察前に保険証確認しているのが一番スムーズに事務処理ができます。

つまり実務デザインを変えたらいいということですが、システムメンテナンス側から提案すらできないのですね。話し合いの場もない。
病院管理職の方で弊ブログを見ていたら、システムメンテナンス担当の人と話し合って改善していただけませんか？
システム側と病院管理職の定期的な話し合いの場があれば、もっとよくなると思います。
改善は日々行われるべきものです。定期的な話し合いの場すらないというのは組織管理の在り方としては不健全ですよ。

by ebisu (2021-11-18 23:01) 

ebisuさん。
こんにちは。
電子カルテ問題面白いですね。
読み物として以下をご紹介します。
https://www.nissoken.com/jyohoshi/kk/zai/mihon_inukai.pdf
by 四谷怪談 (2021-11-19 13:14) 

四谷怪談さん
こんにちわ。
この問題は1980年代からずっとありますね。
なんにも変わっていません。
要するにシステム開発側はアプリケーション分野の実務や専門知識を知らず、ユーザー側はシステム開発の専門知識がないということ。これはFでもNでOでも一緒です。

うまくいくのはユーザー部門にそれぞれの業務に関する専門知識と実務知識があり、さらにSEと同等程度のシステム開発知識があるケースです。
まったく新しい実務設計をして現場のそれぞれの部門を納得させられる技術のある人が一人いればいいだけですが、それが100社に1社くらいしかいないのです。

システム開発部門がアプリケーション分野の専門知識や経験をもっており、実務設計ができる人というのは見たことがありません。オービック、NEC、それとNCDさんのトップレベルのSEとだけしか仕事をしたことがありませんが、それでもいません。この点では富士通も一緒です。富士通は2度提案書を見る機会があったので、その開発レベルを知っています。

市立根室病院も、建て替えしてから新システムを導入して3年足らずで不具合続出であきらめて、いまのシステムを導入したように耳にしてます。5億円くらいのシステムだったでしょうから2億円程度の特別損失を出したはずです。
おそらくユーザ部門にシステム開発の専門知識のある人材がいないのです。病院の管理課の人事を見ても数年間で次々に人が変わっています。診療実務と病院事務そして患者とユーザーは三つに分かれます。
2-3年では学力がかなり高くても、消化できないでしょう。
もっと具体的に言うと、診療実務に関して医者と対等に話ができるほど医療について詳しいこと。病院事務について流れを熟知していること。患者のニーズがわかっていること。少なくともこの三つの知識は必須です。

勉強熱心な職員が幹部職員が何名かいるなら、勉強会でもしたらいい。
資料を見てわからなければわたしのところに聞きに来たらいい。どこの会社のパッケージでも問題ありません。システム関係資料の解説ぐらいはできます。

電子カルテに関しては「臨床診断システム開発及び事業化案」を1986年につくったときに、標準化プロジェクトをつくる予定でいました。そちらの担当が能力不足でやれませんでした。臨床検査項目コードだけが日本の標準規格になりました。
産学共同プロジェクトをつくって5年かけたらやれますよ。規格化された骨格があれば、あとはオプションで付け加えたらいい。
そういう大きな構想と人の調整ができる人材がいないのでしょう。
若い人たちは、可能性を信じて大きな構想をもってもらいたい。

そうですね、大手のパッケージシステムを持ち寄って、電子カルテ部分の仕様のすり合わせから始めたらいいと思います。プロトタイプができたら、どこか大学病院で試したらいい。それからオープンにします。
by ebisu (2021-11-19 13:48) 

ebisuさん。
こんにちは。
実際どこの業種でもこの問題ある。
例え要求仕様通りのアプリでも暫く使用すると使い勝手が悪いと言い始め、それが他に伝染し、利用側が悪い場合も最終的に提供側が悪者になる

ただ
人間は欲望がある限り、常に何かが変わり、生まれる。
今日という日を明日にすることさえ欲望です。
欲望がないと新しい技術もできません。
それが良いことか悪いことかは後世が判断するのかもしれません。
by 四谷怪談 (2021-11-19 15:18) 

四谷怪談さん

●例え要求仕様通りのアプリでも暫く使用すると使い勝手が悪いと言い始め、…

こういう仕事のスタイルをわたしは「御用聞き」と呼んでいます。
トラブルになって当たり前です。ほとんどのSEがこの領域であえいでいます。
1980年代は技術が半端なSEは精神を病んで自殺する人もいました。契約金額が決まっているので、稼働しなければ、支払いがなされないので担当SEの人の責任なり、ダダ残業でカバーしようとする。そのうちに疲れ果てます。子会社のシステム開発でそういう例を聞いてます。

「御用聞き」は危ない仕事のスタイルです。
わたしは、ユーザ部門ではありませんが、ユーザ部門からヒアリングはします。ヒアリングの前に、経験のない業務や知らない専門分野の場合には、その分野の専門書を複数読んでからやってました。担当者以上の専門知識がなければ生産性を飛躍的にアップする実務設計ができません。
産能大方式か日能方式で既存の実務フローチャートをつくって、担当者と一緒に確認します。
そのあとで、必要なデータをデータフロー図をつくって確認し、入力帳票を設計します。処理のアルゴリズムも書きます。同時に、アウトプット帳票のデザインをして、そのプログラミング仕様書を書きます。
最後に、実務デザインして、産能大あるいは日能方式でフロー図におとして担当者に説明します。

ユーザー側にいくら新しいシステムの仕様を求めても無駄です。まったく新しい実務になるので仕様書が書けるわけがないのです。無理に書かせると、いままでの実務をそのままコンピュータに載せてほしいとこうなるわけです。「御用聞き」をやってしまうとアウトです。
わたしは生産性が2倍以上、精度が一桁アップを最低目標にして実務デザインをしてました。ときどき、実務は100％システムに吸収されてしまい、ゼロになりました。

輸入商社では営業マンが毎日顧客へ出す、見積書をつくっていました。全員理系大卒の営業マンでしたが、1日の活動の半分くらいは見積書作成です。たとえば、横浜営業所と東京営業所でそれぞれの管轄のＮＥＣの工場へ見積もりを出しますが、担当者が違うので価格が違います。本社でチェックが働いてたまにはクレームになる。
そこで為替変動に連動させた円定価システムをつくりました。東京営業所長の遠藤さんの発案でした。このシステムが動き出すと、営業マンは見積書作成から解放されました。ドル単価に為替レートを勘案して見積書をつくる作業がなくなりました。同時に売上高利益率をそれまでの28％から42％へアップしました。営業マンは社内で見積書作成の手間がなくなったので、営業活動の時間が2倍になりました。だから簡単に売上が1.5倍以上になりました。
これユーザー要望ではなくて、東京営業所長とわたしがコンビで考えた、利益構造の変革の道具の一つでした。
為替の管理も担当者からは旧来のやり方しか出てきませんから、為替リスクを回避するユニークなシステムをつくっています。それで、為替変動に左右されていた業績が安定しました。
輸入業務も電算化して生産性をアップしてます。海外メーカとの納期管理もシステム化しましたので、営業マンと業務課の担当者から、同じ案件で納期確認メールが行くということもなくなりました。

生産性アップのための実務設計は担当部門の要求仕様ではやれないのです。

SRLに転職して経営統合システム設計をしたときも同じです。実務デザインはすべて自分でやりました。生産性を飛躍的にアップさせる実務の仕様を担当部門に聞いても無駄ですから。担当者は必要なシステム知識も業務に関する専門知識も足りません。
そして優秀なSEでもシステム以外の業務に関する専門知識を求めるのは無理でした。簿記の原理や会計学、原価計算学、経営分析学、輸入業務、外国為替、会計情報システムに関する最先端情報など。
テストデータも自分で作成してました。プログラム仕様書道理にプログラムができていなかったり、テストデータをつくらず手抜きして後からエラーが出たら困ります。

実務設計であとからトラブルが起きたことは一度も経験がありません。快適な環境で仕事をするか、それまでの業務自体がシステム化でなくなってしまいますので。

通算して5年間ほどシステム開発の仕事を経験しました。自然に外部SEとの仕事の棲み分けができてました。
わたしはシステム全体の外部設計と実務設計、そしてシステム間インターフェイス仕様書の作成。外部SEは内部設計というふうに。

話しの要点は「要求仕様通りのアプリ」というのは「御用聞き」スタイルの仕事で、それこそがトラブルの元だということ。ご用心。
by ebisu (2021-11-20 01:28) 

ebisuさん。
こんにちは。

「要求仕様通り」＝「御用聞き」スタイルの仕事というのはおかしくないですか？
その理論だとユーザ要求以上を常に提供するのがSE側の仕事になる。これを「御用聞き」と言い始めたら、この世の中のすべてが「御用聞き」案件になる。
その考えだと「もちさん」のようなパーフェクトなSE以外対応できない。仕様変更も改修も発生しませんからユーザ側にはお得ですね。
たしかに優秀なＳＥはある程度の将来を見越した設計する。しかし10年後などを想定した設計をすることは難しい。こんなSEなんて一握りもいませんよ。

80代初頭コンピュータが多くに導入され、主に「計算」目的に使用していましたが、近年技術が進歩し、オフラインアプリやＷＥＢアプリが構築されている世の中です。
ebisuさんの論理だと、80代初頭コンピュータ時にオフラインアプリやＷＥＢアプリ、ＡＩまでを想定した仕組みをＳＥが準備しておくというのが当然なのでしょうか？

違いますよね！？

ＳＥは「要求に対して１００点のもの」を構築する仕事です。１００点以上の要求外機能も考慮するが１０年先の技術を考慮したものは設計しません。

そもそも「御用聞き」の仕組みを構築したのは「ユーザ部門」サイドなんです！
ユーザ部門が独自で開発ソフトが売れると考え、そのユーザ部門が開発側にまわり、開発ソフトの使い勝手をよくするため他ユーザ部門の「御用聞き」で仕様変更し行きました。
開発側はユーザ部門の要求に対する仕様設計し費用見積もりを出します。ユーザ部門側は現場などに何度も確認し不必要な機能を排除して費用を安くする。運用開始時は不必要でも運用していくうえで、不必要な機能が必要となり追加するという流れを昔からある。
ユーザ部門の責任者が変わると要求範囲が変更になることもある。またユーザ部門が要求範囲を超えた要求をするのが常態化したことが「御用聞き」を生みました。

そもそも世の中の既存システムの８割は「御用聞き」の仕組みです。
海外は多少の不具合は寛容だが、日本は完璧を求めるため不具合に対し厳しい面もあるのが現実です。
日本の「お客様は神様」理論が色々な業界をおかしくしています。お客様が要求することが「良い」ことで対応できないのが「悪い」ことが多くあります。
確かにお客様の声は重要な意見です。お客様要求に対し対応するのが正しいことですが、何でもかんでも対応するのはおかしくないですか？

今回の記事のようなことでも、ebisuさんやもちさんのように「自分の考えが正しい」ので修正すべきというのは問題では？
経営側にも考えがあった上での制限かもしれませんよ。それとも本当に考えがないのかもしれませんが？

政治家や医者などだったて間違えることがしばしばあります。
結局、開発側もユーザ側もお互いの意見を正しく聞けば大きな問題にならないのかもしれませんね？
by 四谷怪談 (2021-11-20 09:16) 

四谷怪談さん
おはようございます。
読んでいる人は面白いでしょうね。投稿に感謝します。

どこか話が食い違ってきているようですね。さて、どこなのでしょう？
言っていることの中身は案外同じなのかもしれません。3-4点、取り上げて具体的に書いてみます。

四谷怪談さんの話、とくにAIを考慮した設計なんて80年代にはできるはずもないというのはその通りで、まったく異論はありませんが、そこでも80年代には80年代の時代の制約を受けながらの問題があったことを書いておきたくなりました。話がどんどん脇にそれていくようですが、せっかくの幽霊と現世の人間との対話、楽しみたいと思います。

1984年に経営統合システムを2か月の並行ランを含んで8か月で本稼働させた後、全社の予算編成や予算管理がメインで暇を持て余していた時に、臨床検査の講習会が1年間ほどありました。さまざまな大学のドクターをお呼びして社員対象に分野別に講習会が毎月開催されました。興味があって、お二人の大学の先生と講義のあと話をしたのですが、血液疾患の専門医だった東京医大の藤巻先生が血液疾患の診断ロジックが複雑なので、専門医を育成するのがたいへんだとおっしゃり、診断ロジックをプログラムにすれば臨床診断エキスパートシステムが作れそうなのでご意見をお聞きしてしてみました。それで、1年間ほど文献を調べて、「臨床診断システム開発及び事業化案」をつくりました。疾患分野ごとにエキスパートシステムをつくって事業化するつもりでした。NTTデータ通信事業本部が関東逓信病院でネットワークをつくって何かやろうとしていたので、2度ばかり会議をセットしました。コンピュータの性能と通信速度がネックになっていたので、専門家の意見を聞きたかったからです。画像を送って処理する必要がありました。当時は東京⇔大阪間の専用線を引くだけで30万円/月の使用料がかかりました。インターネット回線、光回線が出てくる前でした。専門家のご意見は30年先だということ。それで、開発をあきらめました。SRLの創業社長からはとりあえず200億円のフィジビリティスタディの予算を認めてもらっていました。使えませんでした。（笑）
エキスパートシステムの延長線上にあったのがAIですが、当時は夢の話ですから、もちろん現実のシステム開発にそうしたものを考慮するはずもありません。NTTデータ通信事業本部と会議をしたときの私の所属は「経理部管理会計課」です。10年くらいでコンピュータと通信速度が要求仕様を満たせるなら、共同開発するつもりでした。創業社長の了解は得ていましたから。入社2年目でSRLを臨床検査最大手の会社から、臨床診断支援システムを事業化の柱にする会社へ転換してみたいと本気で思ってました。

エキスパートシステムはともかくとして、会計情報をベースとした経営情報統合システム仕様に、AIが入り込む余地はありません。そんなAIなんて存在してませんから。手塚治虫の漫画のような単なる夢の話になります。
会計システムや原価計算システム、購買在庫管理システム、売上債権管理システム、経営分析システムを統合した経営情報システムは、5-8年くらいで更新されるので、そういうスパンで全体構想や仕様を検討しました。いまある技術を使ってどこまで挑めるかというのが基本スタンスでした。
システム間インターフェイスは35年たった今でも、当時わたしが書いた仕様でなされていると思います。仕様書で最も難しいところの一つでしたが、1週間で書き上げて、各サブシステム担当者にこれでシステム開発を進めるように指示しています。
AIを想定したシステム仕様は夢物語、そんな必要は当時はないということ。その点では四谷怪談さんと一致。しかしAIの全段階であるエキスパートシステムは構想し、開発と事業化を進めていたということ。手の届きそうな範囲はやってました。仕事はロマンです。

だいじなところは「御用聞きの話」でしたね、話を限定して、具体例を書きます。1978-1983年までの産業用エレクトロニクス輸入専門商社勤務時代の話です。
輸入商社はどの会社も例外なく為替変動で業績が揺れます。自己資本比率が低い会社は大幅な円安があれば大きな損失をだし、債務超過に陥り会社が経営破綻の危機に見舞われます。
為替対策実務に何をやっているのかは、経理課長や業務課長にヒアリングはしますが、彼らからは為替変動を回避するアイデアはもちろんのこと「要求仕様」も出てきません。「いま、これこれこういう実務をやっているから、それをコンピュータに載せてください」とうのが彼らのスタンスです。
わたしは社長から特命事項で会社の命運を左右する5つのプロジェクトを任されていました。為替に関しては為替変動にびくともしない経営にしたいと希望を聞いているだけです。もちろんこんな希望は「要求仕様」ではありえません。
まったく新しい実務とそれを載せるシステムを考案するしかありません。「要求仕様」はどこにもないのです。もちろん、トップレベルのオービックのSEも日本電気情報サービスのSEも具体例すらないのですから、夢のようなシステムの「要求仕様」を知るはずもありません。要求仕様なしにシステム設計しなければなりませんでした。自分が書けばいいだけでした。
納期管理システムと為替対策システムと円定価システムをリンクさせることで、為替変動から会社の業績を切り離しました。世の中にはまだないシステムでした。
だから、オービックのSEは自分の会社だけで輸入商社20社に販売できるので、うちに来ないかと、会社を辞めて2週間目くらいに連絡をくれたのです。

SRLの経営統合システムも事情は同じです。業界初の上場のために参考になるシステムがありません。SRLはそういう意味でパイオニアでした。関連するユーザ部門から現状の実務をヒアリングしてフロー図に落として確認はしますが、システムに関する要求仕様は出てくるはずもないですから、聞きません。該当する業務に関して、専門知識のレベルに差があるのです。実務を話してくれた人はほとんどの場合は仕事がなくなります。システム化で人間による作業が、とくにベテランによってなされていた作業がなくなるか、単純化されて、新入社員に置き換わります。
「要求仕様」がユーザー部門からは出てこようがない分野が存在することはご理解いただけるのではないかと思います。

二つ目の論点は、そういうレベルのSEはほんの一握りだという点ですが、それもそのとおりです。そういうレベルの話をしていました。
だから、逆説的な話になりますが、ほとんどのSEは「御用聞き」です。だからトラブルはつきもの、日常茶飯事でしょう。大半はシステムの入れ替えをするまで放置されます。
業界全体で、病院システムの規格化のプロジェクトすら30年もやれないというのは本当に情けない話ではありませんか。臨床検査項目コードの標準化は大手六社と臨床病理学会で産学協同プロジェクトを1986年にスタートさせて1990年代初頭から日本全国の病院システムがこのコードで動いています。それと比べたときに電子カルテの規格化すらないというのは、業界全体の怠慢です。

三つ目の論点は「自分の考えが正しい」という点です。誰もが自分が正しいと思っています。自分が間違っているかもしれないとは思うでしょうが、自分は間違っていると思って何かを主張する人はいませんよ。
それに、わたしはそれほど独善的ではありません。だから、「180日を210日に書き換えることで実務上不都合があればそれを具体的に書いてください」ともちさんにメモしたはずです。全部を見ているわけではないので、そう書いています。これは経験智でしょうね。
「経営側にも考えがあった上での制限かもしれませんよ」そう思うから、「管理者側と話してください」という意味のことも書いています。

システムメンテナンス担当の人と管理者側が定期的に話す場すらないというのは、組織のマネジメントの観点から、重大な問題であることにも言及しています。
治験データ管理会社では、データ管理部門とシステム部門は経営管理担当役員のわたしの下にありましたから、毎日誰かと話はしてました。机の横に小さな丸テーブルとイスを置いてあったので、基本は社内メールで処理してますが、重要事項はさらに口頭で確認してました。そのための丸テーブルでした。一日の1/3は社員からの報連相に時間を割いてました。
そうしないとマネジメントができるはずもありませんので。仕事に対してはしごく謙虚なのです。

こうした四谷怪談さんとの忌憚のない対話を若い人たちが自分の仕事の糧にしてもらえたら幸いです。
by ebisu (2021-11-20 11:30) 

「臨床診断支援システム」は全国の大学病院や疾患別に専門病院をネットワークする構想でした。NTTデータ通信事業さんとの2回の打ち合わせの収穫は、このシステムがCAE（Computer Aided Education）に利用できることが分かったことでした。
by ebisu (2021-11-20 14:30) 

二つ前の投稿に漢字変換ミスがありましたので訂正します。

「しかしAIの全段階であるエキスパートシステム」⇒「しかしAIの前段階であるエキスパートシステム」
by ebisu (2021-11-20 14:37) 

　妻の通院は松戸市立医療センター。物凄い混みようです。でも、1年後の予約もできます。MRI検査や超音波検査は混み過ぎて1年後の予約がやっと取れるだけです。
　杓子定規の受付担当者はたくさんいます。外注だからです。でも中には良い人もいます。顔見てお願いする担当女性を選べば大丈夫です。
　仕事も大学も相手の顔ツキを判断する能力が大切です。調子よくしたらこの歳ですので楽に生きられます。
　会社の苦労が後期高齢者になり役立ちました。
by tsuguo-kodera (2021-11-20 17:29) 

koderaさん

診察カードを自動受付機に入れると「期限切れのため保険証の確認」表示とアナウンスが流れます。再度やると、「受付履歴がないか受付済み」の表示。カードが使用できなくなった理由がわからないので、受付カウンターが開くのを待ちました。開く10分前に前に運よく受付の人が他の患者に用事があって出てきたので、事情を話したらすぐに対応してくれました。いやな顔してませんでした。（笑）
朝の忙しい時にイレギュラー処理は患者のわたしの方も恐縮ですし、対応してくださる受付の方にも迷惑でしょう。
白内障手術後の眼科の予約は半年単位です。年間200-250人も手術していますから、ふだん通院していない年寄りは診察券の自動受付でトラブルが起きます。他への影響がないなら、エラー処理の数値を180日から210日にしてくれたら、トラブルが回避できるのですが、システム側と病院管理職のコミュニケーションの場がないというのに驚いてます。話し合って周辺への悪影響がなければプログラムを修正してコンパイルすればいいだけです。5分で処理が終わります。

病院は毎年16億円の赤字ですが、6億円は比較的簡単に解消できますが、赤字の解消は細かい改善の積み重ねではなくて、大きなところをやるだけでも年間6億円減らせるのです。こんな小さな改善もコミュニケーションが悪くてできないようでは、この先赤字の縮小もできないでしょうね。
根室は医療でも教育でもとっても頑迷固陋です。わが古里ながらあきれてます。

今回こうして市立根室病院の受付システムについて具体的なことを論じたお陰で、わたしが現役時代にやってきたことはどうやらSEの仕事ではなかったようです。
SEの仕事が「御用聞き」だとしたら、わたしのはシステムクリエータ（SC）とでも呼ぶ職域のような気がしてきました。
ユーザーの要求仕様から出発するのではなくて、経営者の「願望」のようなものから仕事をスタートさせていたからです。売上総利益率を27％から42％にアップするとか、生産性を3倍にアップして赤字の会社を黒字にするとか、治験のデータ管理システム事業分野でパッケージシステムをつくって売上を数倍に伸ばすとか、システム化で人がやっていた作業を半分失くしてしまうとか、それらはただわたしが新しいシステムをデザインするときの自分に課した目標値でした。あとで決算数値で効果を確認してました。もちろん、システム開発をしているときには損益シミュレーションもしてました。だから効果の測定も決算でできたのです。

複数のアプリケーション分野でそれぞれの専門知識を武器に、従来のSEとはまったく異なるやり方で最先端を走っていたことがようやく理解できました。

時代の20～30年ほど先を走っていたようです。
by ebisu (2021-11-20 21:29) 

　コメントに失敗しました。富士通の悪口とAIに判定されたかも。(笑)
　先の文章を思い出して短くかきます。
①師匠は分野ごとにいた。論文、SE、計算機、事業企画など、各分野に天才がいた。
②阿保が元気に長く仕事ができる。天才は身体を壊すか、足を引っ張られるか。会社はアホだらけ。3万人の会社はアホが抵抗勢力。そのトップが社長になれる。
③天才SEは3年先の経営環境とユーザを考えてシステム仕様書をまとめさせた。彼が病に倒れ富士通は潰れそうになった。真面目な天才は皆さん身体を壊しました。
④細く長く生きるか太く短く生きるかは個人の好みです。ebisu先生は前者を選び幸運にも生きながらえた。私は後者を選びバドをして若者と遊んだ。どちらも幸運だったと思います。
by tsuguo-kodera (2021-11-21 14:24) 

　済みません。間違えがありました。3年ではなく、30年です。
by tsuguo-kodera (2021-11-21 14:26) 

koderaさん

投稿常連のkoderaさんの紹介をしてから、富士通のことを書きます。
小寺さんは富士通本社で働いていた方です。汎用小型機ga売れ始めた時代です。ワープロの名機OASISはタッチしたのだったかな。第五世代コンピュータ技術研究組合の方も関係しています。その後シャープに転職されました。東大工学部、同大学院から富士通入社です。期待の星の一人だったのではないでしょうか。

SRLは基幹業務系に富士通製の当時最大クラスの汎用大型機を導入してました。1984年のことです。OSに不具合があり3か月ほど全社で応援体制を組み、手書きで対応したり、とにかく人海戦術で不具合を乗り切りました。IBMと違ってユーザーが国内ですから数が少なくて、OSのバグが潰しきれない、そういう時代でした。
当時のSRLにはシステム部とシステム開発部がありましたが、基幹業務系システム開発は富士通さんにおんぶにだっこでした。どちらの部長もシステム開発能力はナシでした。だから、経営情報系はシステム部は関与ナシ、NCDさんが外注先で、社内で各分野別にプロジェクトが組まれてました。棲み分けがなされていました。
1993年頃、システム部起案の開発稟議書をみましたが、あまりお粗末なので、誰が書いたのか訊いたら、添付資料は富士通さんの入社3年ほどのSEが作成したというので驚きました。億円を超える開発案件でこんな程度のSEが担当では話にならないと思いました。
接点はそれだけで、わたしは経営情報系のシステム開発担当だったので富士通さんとは一緒に仕事したことがなかったのです。富士通さんのトップレベルのSEと仕事してみたかった。
オービックとNECとNCDさんはそれぞれトップレベルのSEと一緒に仕事しているので、会計や経営情報系のトップレベルのSE力量がどの程度かわかっています。それはすでに書いたので、もういいでしょう。

小寺さんの投稿は、いわば富士通の内部情報です。20-30年後を見据えて仕事していたSEがいたようですね。仕事で接点もちたかった。残念ながら、大手コンピュータメーカと共同プロジェクトをやるようなテーマがありませんでした。

小寺さんがSRL担当だったら接点ができたかもしれませんね。小寺さんクラスをSRL担当にしてくれることはなかった。富士通の方でもSRLシステム部の扱い方を心得ていたようです。真偽はわかりませんがシステム部長の家に行くと家電製品が富士通ゼネラルのものだらけなんて噂が飛んでました。業務課員が業者から毎月現金で150万円収賄していて首になるなんてこともありました。ほかにも2件知ってますが、書くのはやめておきます。結構ルーズでした。業務監査が年々シビアになって、少なくはなりました。

仕事では人間関係がだいじでして、一度会って会議でもお酒の席でも、少し話をすればお互いの力量は見当がつくので、何かテーマを立ち上げて一緒に仕事をする機会がたいていの場合はできるものです。

臨床検査項目コードの日本標準規格は、もともとはBMLのシステム部長のお名前は北川さんだったかな、彼がBMLの新ラボ建設のときに、ラボシステムに業界統一コードを使おうと提案したものです。
2回目のミーディングにシステム開発課長の栗原さんからわたしに声がかかったので、臨床病理学会の項目コード検討委員会・委員長の櫻林郁之助（当時は自治医大の助教授でSRL臨床化学部電気泳動顧問）を巻き込んで、日本標準をつくろうと、臨床化学部長の川尻さんに話して、2度目の会議へ乗り込んだのです。業界だけで統一コードをつくっても、病院側では使ってくれないから、臨床病理学会から発表してもらえば、日本標準コードになり、臨床検査センターと病院システムのインターフェイスが簡単になると提案、全員賛成で、3回目に臨床病理学会の櫻林先生へ参加を招請することになったのです。

「臨床診断システム開発及び事業化案」が社内の経営会議でオーソライズされていたので動きやすかった。当時の名刺は経理部管理会計課員でした。櫻林先生から学会の項目コード検討委員会の仕事を手伝ってくれと入社1年後に頼まれていたのです。どういうわけかラボのシステム部ではなく、本社で経営情報系システム開発をしていたわたしに依頼があったのです。「今の部署で動きにくいなら、社長に話して総合企画部へ異動できるようにするから」とおっしゃってくれましたが、専門的なスキルのある人が一人もいない総合企画室は御免でした。学生運動崩れの管理職が粋がっているような部署でした。それで、お断りしたのです。櫻林先生は病理学会長だった河合教授の一番弟子。河合教授のススメで藤田光一郎さんは特殊検査のSRLを起業したのです。だから、櫻林先生は藤田社長と直接話ができたのです。

光カードとカルテの標準規格のプロジェクトの方は創業社長の藤田さんが社内の総合企画の部長職へ回したのですが、専門的なスキルのない人でしたから、自然消滅でした。なぜあんなにむずかしい仕事を専門的なスキルが一つもない彼に回したのかわかりません。できると勘違いしていたように感じました。そのあと藤田さんは彼を赤字子会社の社長にしましたが、うまくいかず、居場所をなくしてやめていきました。能力以上の職位につけてはいけないのです。あまり人を見る目がなかった。その一方で、藤田さんは自分の仕事の管理は実に厳しい人でした。毎月30項目ほど自分の行動を目標管理していました。お客様との食事の回数、社員との食事の回数、営業所を訪問する回数...、「先月は２５勝５敗だった」という風に。３度だけ一緒に仕事してます。
交渉ごとのときに、間の取り方が上手な人でした。間をたっぷりとって沈黙の時間が長いんです。それが大きな圧力になります。演技派の俳優でしたね。重要案件でJAFCOを訪問したときに、間の取り方を演じて見せてくれました。1度だけで十分でした。帝人相手の交渉事のときに、無意識に使っていたのかもしれません。臨床治験合弁会社の資本提携解消と帝人臨床検査子会社の買収がスムーズにいきました。
帝人常務が「こんなことは初めてだ、合弁会社をやってもうまくいかないことが多くて、後始末は今まで帝人側がやってきた、黒字になってうまくいって合弁解消、そして赤字の臨床検査子会社を引き取るなんて交渉は初めてです」と言われました。帝人の子会社の社員を全員引き取っていました。帝人常務は「次の社長は当然ebisuさん」、御世辞でしょう、わたしは3年間で近藤社長と約束した四項目の仕事が終わったので、残るつもりはありませんでした。社内ルールからややこしいことになるから。有力子会社の社長はSRL社内の暗黙の了解で、親会社の役員ポストでした。すぐにはしなくても、数年後にはそうしなくてはならない。社内はやっかみが多いのです。そんなことに巻き込まれるのはコリゴリでした。のびのび仕事したかった。
早期退職制度に乗っかって、首都圏で老人医療事業にチャレンジ。療養型病床の病院常務理事への就任を半年前から誘われていたのです。病院を核に老健施設、ナースステーション、グループホームを展開して、シームレスな介護を考えていました。一つうまく行ったら、首都圏で10か所くらい展開するつもりでした。病院を買収すれば次々に展開できます。
理事長との関係がうまく維持できなくて、病院建て替えをやって、辞職しました。
そして経営企画部長としてある外食産業の上場のお手伝い。上場要件である原価計算システムをつくりました。仕様書作成は1週間、開発期間は1か月、簡便なシステム構成にしたので600万円でNCDさんに請け負ってもらいました。その会社はすぐに上場してます。
それからは、古里に戻って小さな私塾をやってます。現役で根室高校から一人国立医大へ合格したので、気が済みました。やり方は弊ブログに記録してありますから、誰かが真似したら、同じことが可能です。
あと1年間、しっかり仕事します。（笑）

道内では名だたる進学校の旭川東高校でも、年に3-4人しか国立旭川医大へ合格してません。東北・道東推薦枠で、No.2での合格は、案外すごいことだったのかもしれませんね。小論文が295/300点でしたから。生徒が優秀でした。
いま同じくらいの中３が７月下旬からきています。札幌の高校は進学します。あと３年間古里で教えるなら、根室高校を薦めますが、そうはいかないので、北大理系現役合格すれおぼつかないでしょう。札幌へ進学して、そこから米国の大学へ進学したらいい。科学者になりたいそうです。
パイオニアであれ！
by ebisu (2021-11-21 20:55) 

ebisuさん、あと１年間なんですか?!
既に根室管内から出てしまった私が言えることではありませんが、びっくりです。
前に書いていらしたように東京へ戻られるのでしょうか？


by amanda (2021-11-23 11:32) 

amandaさん

ええ、そういう目安で考えています。古里でやりたかったことはやり、言いたいことは繰り返し言いましたので、思い残すことが日々小さくなっていきます。
家の売却処分などもしないといけませんので、はてさて予定通りに行きますかどうか、多少なりとも未練はありますからもうすこしながくなるかもしれません。
目安はあと1年、いまいる生徒たち相手に、健康で全力投球の授業がしばらくのあいだできたらうれしい。

足腰のしっかりしているうちに、東京へ戻りたいと思います。だんだん怪しくなってます。（笑）
東京の住まいももう20年近く空けたままですから。
徒歩で行ける距離に住む一人娘と一人孫の女の子が「ジジ、早く来てほしい」って首を長くして待ってます。
by ebisu (2021-11-23 13:11) 

四谷怪談さんとebisuさんの内容を見て思ったこと。

どんなに有能社員がいても上層がおかしいと最適解にならないのはどこも一緒だ。

この例に似た状況を見たことがあるのですこし。

Ａ会社にＡ君とＢ君がいる
Ａ君は先輩でＢ君は後輩である
Ｂ君はＩＴ業界以外からの中途転職者でＡ君は生粋のＩＴ業界人でスキルに大きな開きある

Ａ君の上司Ｚ君は、採用時Ｂ君の「成長を長い目で見てほしい」と指示。３年経過しＡ君とＢ君の能力の差が縮まることなく開く一方
Ｂ君は上司Ｚ君に「Ａ君の指導が悪い」と言い、再度１から指導することを上司Ｚ君がＡ君に提案
Ａ君は上司Ｚ君に３年間の現状と指導点を説明
さらにＡ君は上司Ｚ君にＢ君のＩＴ資格など取得を提案するが上司Ｚ君は却下。「Ｂ君の成長を長い目で見てほしい」と回答
Ａ君は上司Ｚ君の指示に従うしかなかった

私が見たところ
先輩Ａ君は職人気質なフィールドエンジニア
後輩Ｂ君は公務員気質の典型的な指示待ち人
上司Ｚ君は経営側の管理職で常に型にハメたがる
という感じで

Ｚ君とＢ君は相性が良いがＡ君はＢ君とＺ君とは相性が悪いと感じる
結局、Ａ君はＡ会社を辞め別Ｂ会社に移籍した
Ａ君移籍でＡ会社のお得意様は、当初はＡ会社で問題なかったが能力低下を感じ取ったのかＢ会社と仕事するようになった
ＩＴ業界はいつもこんなです。
by 秋月信彦 (2021-11-27 09:51) 

秋月信彦さん
仮面ライダーのキャラクターでしょうかね。

IT業界に限りませんね。

以下はSRL社内の話です。
応用生物統計の職人のF君は、慶応大学産婦人科との出生前診断MoM基準値づくりの産学共同研究の多変量解析を担ってくれましたが、その仕事が終わると、独立起業してます。優秀な統計職人です。

営業担当取締役は3人いましたがどれも凡庸以下。声が大きいだけでしたね。
学術営業部のS君は米国臨床栄養学の博士学位をとって独立。日本の臨床栄養学の草分けになりましたが、2017年に59歳で病気で亡くなりました。
学術営業部長の窪田さんも定年前に退職して独立起業、初回は大失敗でしたが、2度目に大成功。ペプチドリームを起業し（一部上場企業）社長です。
この二人は、声が大きいだけで無能な営業担当取締役にずっとストレスを感じ続けていたと思います。

現在のＳＲＬ社長は新卒採用のようで、わたしよりも入社年次は2年早い人ですが、わたしは名前も知りませんでした。
ＳＲＬの社長は創業者の藤田光一郎さんもその次の近藤俊之さんも医者でした。どちらも経営者としては優れた人でした。社長の「格」がかなり、三ランクほども下がったように感じます。

SRLはダントツで業界ナンバーワンでしたが、昨年はBMLに売上で追い抜かれたようです。

社長の一番大切な役割は、人を適材適所で使うこと、そのために人の能力を見極められることです。
3業種4名の社長にお仕えしましたが、それが適切にできた方はいらっしゃらない。皆さん標準よりはずっと経営力がありました。
能力を見極め、適材適所で人を使うのはとってもむずかしいことなのです。
そういう能力のもち主は社長になりにくいのかもしれません。
いやいや、トップに限りません、課長職でも部下の能力を見極めて、適材適所で使えなければ、秋月さんが挙げたようなことが起きますね。
by ebisu (2021-11-27 12:06) 

人の使い方に関して、少し具体的な話を書きます。

いまや東証1部上場企業でベンチャーナンバーワンとなっているペプチドリームの窪田さんはSRLの学術営業部長時代にさまざまな大学病院のドクターと接点をもっていました。その中の一人がペプチドリームのパートナーの東大の先生でした。
SRLの営業担当取締役にまともな人材がいたとしたら、窪田さんはSRL社内で新規事業を立ち上げたでしょう。製薬メーカ相手の研究開発事業分野がSRLの新規事業となった可能性があります。

わたしは、欧米の製薬企業からの八王子ラボ見学の対応要員を1年半ほどやっていました。ラボの設備を全部売ってもらいたい、いくらなら売ってくれるのか、なんて申し入れが米国大手臨床検査センターを傘下に持つ製薬企業からありました。もちろん返事はノーです。米国に臨床検査子会社をつくる計画をもってましたから。設備を全部もって行けばいいだけですから、立ち上げと展開はとってもスピーディにできます。必要な国内機器メーカーには個人的なチャンネルがあったので、米国に拠点を作ってもらうつもりでした。お金が足りなけりゃ、こちらが用意する。
提案したら、社長は言い出しっぺのわたしにやれというに決まっていましたから、言い出しませんでした。まだ日本でやりたい仕事がありました。
でも、これをやるとSRLの売上規模は2倍を軽く超えます。利益はそれ以上見込めます。何よりのメリットは必要な500-1000億円の資金調達のために増資することでした。親会社である製薬企業の富士レビオの存在が気になっていたのです。米国進出を口実に増資すれば、親会社の持ち株比率を薄められます。
わたしが言い出さなくても、誰でもよかったはずですが、そういう絵柄の描ける取締役が一人もいなかったということ。

もう一つ事例をあげます。わたしを学術開発本部へ引き抜いたI神取締役は、異動して半年ぐらいの間に、マネジメントに関わる重要問題を次々に片づけたのを見て、「数年後にはebisuに使われているかもしれないな」と言いました。彼は数年後にわたしが社長になるかもしれないと思ったのです。
青山学院大で有機化学を教えていた人でした。わたしが1年半で、異動した後に、細部工学関係の新規事業にチャレンジして失敗。その責任をとるようにしてお辞めになったと噂で聞きました。
学術開発本部には学術情報部と開発部と精度保証部がありました。性質の異なる三つの部をまとめるのにはマネジメント力が要求されますが、そこに弱点がありました。開発部がらみで細胞工学に関する新規事業のマネジメントがうまくいかなかったのでしょう。マネジメントを担える管理職がいなかった。新規事業は経営力も要求されます。マネジメントスキルの高い管理職を配置してあったら、細胞工学事業は成功したでしょう。SRLに新規事業分野が加わっていた。

こうしたことを考えると、臨床検査業のままの現在のSRLとは、その事業内容も売上規模も、展開する地域もまるで違った、数倍の企業になっていた可能性があったのです。

わたしが50歳でSRLを退職してから十数年後に、富士レビオはSRLを吸収合併してしまいました。そこから、わずか十年ほどで、業界2位だったBMLに売上規模で抜かれてしまう。
ほんとに情けない。SRL学術開発本部スタッフ時代ころから、BMLを追い詰める戦略を練っていました。株価を1/10に落としても証券取引委員会が買収を認めないでしょうから、そこがネックでした。戦略はその後3年間更に具体的に煮詰めてから棄却しました。わたしの性に合わない。
米国へ進出する方がよほどスマートで効果が大きいですから。

人の使い方というのはほんとうにむずかしいもののようです。
by ebisu (2021-11-27 13:17) 

＜よくやる人の使い方の間違い＞
類似の問題はいまもあるでしょうから、1990年代初頭のSRLとその周辺の臨床検査会社の実例をいくつか開示します。
千葉ラボ（SMS：当時）と九州のラボ（JML）は三井物産から買収したラボでした。もちろん赤字です。九州のラボには販売会計部長だったK藤さんが社長として赴任してます。400人ほどの社員の顔と名前を一致させるために、社長室に全員の顔写真と名前を壁に貼っていました。家族構成もノートにメモしてましたね。臨床検査のことはわからないから真摯でした。彼はペンキの大手の会社からの転職組です。日本ペイント、関西ペイント、どちらだったかな。1984年にSRLへ転職したときに経営統合システムの一部を任されましたが、販売会計システムを担当していたのがK藤さんでした。うまくいかないので、稼働直前に、本稼働を1年後に延ばしました。結局、それから2年かかりました。いい判断でした。

千葉ラボが大赤字だったので、1991年にできたばかりの関係会社管理部が経営改善をバックアップしました。担当はebisuです。ラボのシステムが使い物にならないので新システムを導入することに決めました。生産性をトータルで2倍以上に高めることを目標にデザインしてます。2台入れたコンピュータの内の1台は、コンピュータの素人でも使えるAS400でした。データベースマシンで、SQL言語でデータ加工ができます。千葉ラボの社員2名の選択でした。SRLへ入社する前からつかIBMのデータベースマシンが使ってみたかったので、そのまま彼らのアイデアを通しています。もちろん、正解だからです。損益シミュレーションを稟議書に添付してありましたが、SRLでは損益シミュレーションが添付されたシステム導入稟議書をつくりました。結果はすぐに出ました。稼働直後の2か月間、春の健康診断シーズンの受注激増の負荷をクリア、生産性が3倍ほどになりました。赤字会社は黒字転換です。
せっかく黒字で、高収益会社に生まれ変わったのに、2年後くらいに実質赤字のSRL東京ラボへ吸収してしまいました。これはアホな判断でした。
わたしは、その時に同時並行で北陸の臨床検査会社と東北の臨床検査会社の経営分析と買収・資本提携交渉を担当していました。創業社長の藤田社長からの指示で、どちらかのラボを選べというので東北のラボへの出向を選びました。こちらの方が経営改善がむずかしい会社だったからです。千葉ラボが導入していたシステムはこの会社が開発して販売したものです。臨床検査会社の創業社長としてはシステムがわかって人でしたが、半端でした。取締役経営企画部長での目標期間3年間の出向でした。経営改善して3年間で黒字にしろと創業社長の藤田さん。千葉ラボのシステムを導入すれば簡単に生産性がアップし、1年間で黒字転換が可能でした。でも、それは自分が臨床検査業界ではシステムについては一番詳しいと自惚れている東北の会社の社長のメンツがつぶれるので、別のやり方をとりました。染色体画像解析装置を仙台のラボに導入していたので、そのコストと生産性を調査しました。培養液の濃度に大きな違いがあり、精度はデータを見る限りSRLの染色体検査部よりもよかった。八王子ラボの染色体課長へやり方を見せて意見を求めて確認してます。染色体検査はSRLが80％以上を独占している分野でした。八王子ラボは、ニコンの子会社のニレコ社との染色体画像解析装置の開発をあきらめ、1989年頃に英国の会社の画像解析装置を導入してます。このあと1年後くらいに帝人の臨床検査子会社と東北の臨床検査子会社が同じ装置を導入した情報を、日本電子情報サービスの営業担当者から入手しています。八王子ラボへ3台導入したときに、1台5千万円の機器の購入担当がebisuでした。この時に、東北の会社と帝人子会社は経営が困難で、検査メニューを増やすために染色体画像解析装置を導入したと推測していました。そして、入れても検体を集められないので、更に赤字幅を大きくすることも予想していました。東北の会社はその2年後に、帝人の臨床検査子会社の買収は7年後にわたしが担当することになるのです。運命の糸は不思議です。

北陸のラボを買収して、まもなく経営改善チームができました。八王子ラボ業務課のY根君がリーダーでしたが、経験がありません。案の定、八王子ラボ方式でした。
一番古い臨床検査子会社であるSRL東京ラボは、八王子ラボとシステム部がメインで人を送り込み、いつまでたっても生産性の上がらないラボでした。SRLの重厚長大な生産システムをコピーしてはいけなかったのです。
千葉ラボはまったく設計思想の異なる「軽い」そして生産性の高いシステムでした。94年だったかなわたしがSRL東京ラボへ出向することになりましたが検査担当取締役のS袋さんは八王子ラボの臨床検査2課の課長だった人です。八王子ラボの検査課長の中では優秀な人でした。でも彼は一般検査ラボを任されて困ったでしょうね。臨床化学部といっても特殊検査の八王子ラボと一般検査のラボではシステムがまるで違います。社長は八王子ラボの元臨床化学部長だったM輪さんでした。千葉ラボへシステム導入したときに兼務で千葉ラボの社長もしていたのですが、生産性の高いシステムのメリットが理解できていなかったのかもしれません。

SRLが臨床検査会社を買収したあとが問題でした。だれが担当しようと同じことでした。重厚長大な八王子ラボの仕組みを移植しようとするのです。赴任して何が最適化と考える頭のある九州ラボのK藤さん以外はいませんでした。K藤さんは販売会計部長でしたから、検査のことはまったくの素人、だから現場で考えました。その一つが400名の社員の顔写真を社長室の壁に貼り付け、毎日それを横目で眺めながら仕事してました。

九州ラボも、北陸のラボも、東京ラボも全部、生産性の高い千葉ラボのシステムを導入すればよかったのです。社員の給料を親会社並みに大幅にアップしても売上高経常利益率は10-15％を維持できました。SRLグループ全体の売上高経常利益率だって12％にアップ可能でした。

それをやれたのは、SRLグループ内では千葉ラボのプロパーの社員2人とわたしだけでした。3年間で三つとも大した労力なしにやれたはずでしたが、そういう指示が出ませんでした。いやなんです。八王子ラボがいつでもお手本、胃パン検査センターに最適なシステムを真似するのは沽券にかかわったのかもしれません。千葉ラボのシステム開発の稟議書を見て、その後の決算書とシミュレーションを比べたら簡単に理解できたはずです。創業社長の藤田さんにはそういう経営判断ができませんでした。特殊検査会社を創業して、東証1部へ上場した人ですから、そこから発想が抜けられなかった。製薬企業の富士レビオも藤田さんの創業です。当時現役社長で2社上場させた人はいません。まぎれもなく優秀な経営者でした。

人の使いかたひとつで、会社にはまるで違う未来があるということが言いたかった。それはSRLに限りません。どこの企業でもある問題でしょう。
by ebisu (2021-11-28 09:24)