介護保険関係者だけの短編小説（小説じゃあないって！）
第１８話 「介護保険システムどのような環境で作られた？」
〜ＳＥとユーザの悩みは解決するか〜
きわめてリアルな会話・・・・・・・・・・介護保険ノンフィクション即席小説
介護保険関係者だけが解る楽屋受けだらけ
日頃のアフターファイブの出来事を小説風におもしろおかしく書き綴った介護保険関係者のためだけの物語です。
登場する人物、団体は全て架空のものです。
無断転載を禁止します。
誤解を招かぬよう、フォローを入れるか、全文を転載することを条件に、事前承諾をいただければ転載可能です。
登場人物の紹介
田中 コンピュータ屋さんと間違われる県職員。実はケースワーカー
山田 とある介護保険事業所のケアマネージャー（社会福祉士さん）
鈴木 市役所介護保険課職員
木村 町役場保健福祉課老人福祉担当職員。実は、かつて企業の人事部に勤務していたこともある。
斎藤 老人ホーム職員
作：野本史男
平成１２年６月５日
〜序〜
本日の介護保険掲示板に「誰のためのシステム開発？」という投稿がありました。
さっそく、この話題を題材に仲間内で論議が・・・・・・
〜誰のためのデザイン？〜
田中 ねえ、誰のためのシステム開発っていう投稿さあ、たしか、家にそんな本があったような気がするんだ。
山田 そうよねえ、田中さんは５年間も大規模システム開発をやっていたんだから、そんな本持っていてもおかしくないわね。
斎藤 そうですよ、田中さんの作ったシステム、まだウチにあるんですよ。でも、措置制度のだから使っていないけど。
山田 私はねえ、ヘルパーの予約実績管理、予実管理って呼んで結構使わせてもらったわ。ただねえ、初期データエントリが大変だったけど、予約と同じならそのままリターンキーひとつで実績になる所なんか、気持ちよかったわよ。それにね、へルーパー単位で実績集計するのも月単位で集計したり、過去に遡って修正できたり、けっこう使わせてもらったわ。
田中 そう言ってくれると嬉しいよ。
斎藤 ところでさあ、田中さんはどんな本読んだの？システムのことけっこう詳しいけど・・・。
田中 そうだねえ、システム開発スタートの時は、Ｈ社のシステム設計研修やＦ社のシステム開発手法の研修も行ったし、自分では本を買いあさって読んだねえ。
山田 そんなに勉強したんだ〜。
田中 だって、パートナーのことが理解できていなければ、一緒にやっていけないじゃないですか。
山田 そうそう、ＳＥさんって、カタカナばかりで日本語はなさないのよねえ！言葉が違うから、コンパイラが必要！なんちゃって。
田中 同じ日本語だって、通常伝えたいことの一部分しか言葉に出ないから、自分が全部判っていても相手はほんの一部分しか伝わらないんだよ。
山田 それじゃあさあ、ＳＥさんに業務を全部知ってもらってえば楽じゃん。
田中 でもね、そこまでＳＥさんに要求するものではないんだ。もしお願いするとなったら、ちょっと違う業種の人を別に頼まなければならない。ただ、ある程度の勉強はしてもらうんだ。ＳＥさんにもこちらの表現を理解してもらわなければ開発プロジェクトは機能しないからね。そこでお互いに理解を深めるために仕様の説明と同時に一般的な福祉の制度の研修会をＳＥさんに何回か開いたんだ。
山田 え〜！？お任せにするならまた別の業種にお願いしなければならないの！？それで田中さんは自分でコンピュータの勉強したの？
田中 僕がコンピュータの勉強したのは別の理由なんだ。こちらが伝えた仕様が指示したとおりに動作しているかを検証するために必要だったんだ。こちらだってシステムのことが判っていなければだめでしょ？
山田 それでうまくいくの？
田中 いやいや、自分がコンピュータに詳しくなっても逆にうまくいかないこともある。必要なのは、的確に業務内容を伝える能力なんだ。
斎藤 うまく伝わらないと誤解されちゃう？
田中 そうなんだ。ＳＥさんって、言われたとおりに仕様を作るから、説明した順序のフローチャートを作ってくれる。そうするとね、処理が複雑になったりり、例外処理を組み込むときにフローチャートに論理矛盾が発生することも良くあるんだ。
斎藤 伝える側が悪いっていうことですかねえ。
田中 悪い例をついでに言っちゃうとさ、仕様が固まって、月締めや半期締めで集計表を作ろうと思うでしょ？そうするとね、データベース構造の変更が必要です！なんてちゃっかり言われちゃう。だから、仕様を固めるまでの間に必要と思われる統計データ等も予めきちんと伝えておかなければならないんだ。
山田 うっかり言い忘れましたなんて、言ってられないのね。
田中 そのとおりです。それでね、ＳＥさんって、過去の開発ノウハウで設計する部分ってあるんだ。得手不得手があるようにね。だからね、この場合は、この処理の方法やテーブル設計の方が最適だって指摘できるだけのノウハウがこちらにも必要なんだ。
斎藤 自分で作っているならいいけど、人に思ったことをやらせるなんて大変なことなんだね。
田中 更にね、自分だけで使うシステムじゃなければ、なおのことだよ。誰が使うか、使う人たちの感性や直感を理解しておかなければ、操作ミスも発生してしまってね、結局使えないシステムってことになるんだ。
山田 なんだか、けっこう田中さんも苦労したみたいに聞こえる・・・・。
田中 ははは、けっこう苦労したよ。あ、そうだ！思い出したよ。僕の家にある本。
斎藤 ああ、さっき言っていた本のこと？
田中 そう、「誰のためのデザイン？」って本。新曜社から出ていた本だよ。
山田 なにそれ？コンピュータの本？
田中 ちがうよ。認知科学のデザイン原論だよ。だから工業デザイナーのための本かな？
〜みんなの介護保険システムはどうやって作られた？〜
田中 今回さあ、介護保険システムって、パッケージシステムあり、開発委託システムありで、いろいろだけどさあ、ユーザさんもＳＥさんも本当にご苦労様って言いたいよ。
山田 え〜？私たちユーザはご苦労様の連続だけど、ＳＥさんは仕事だったんだからいいんじゃあないの？
田中 ちがうよ！ＳＥさんだって大変だったんだ。だってさあ、現場ではシステム完成後のイメージがだれも掴めなかったんだから！
山田 そりゃあそうでしょ？誰だってそうよ。
田中 だから、今システムが動いているだけでも私には奇跡としか思えないんだ。開発に携わったことのある立場としてね。
山田 そうなの？そんなものなの？
田中 だってねえ、システム導入後の業務の流れが厚生省から出されるペーパーからだけしか判らなかったんだよ。例えばさあ、生活保護１０割の受給者番号に文字が入るなんて知っていたの？そんなこと、ＳＥさんは誰から教えてもらえたの？ＳＥさんが知らないっていうことすら知らなかったユーザは、システムが完成してから騒いでも遅いよねえ。端的に言えば指摘しなかったユーザ側の責任だよ。
山田 そうかあ、言われた仕様どおりに作るのが開発業者だものね。
田中 そうなんだ。だからさ、本来は厚生省から出された仕様書をちゃんと読み込んで、疑義があれば委託するユーザさん側が厚生省に確認するなどして仕様を固めていかなければならない。ただね、今回の場合さらに問題を複雑にしたのは、ＳＥさんは自分たちのネットワークを活用して正確な情報を先取りして、ユーザさん以上に情報を持っていた。それだけにユーザさんはＳＥさん達に依存してしまったんだ。結果論から言えば、ユーザさん達は本来のシステム開発を放棄してしまったということなんだよね。お互いに勉強していれば納得ずくで開発ができた筈なんだけどさあ。
山田 でもさあ、今回はユーザの責任じゃあなくて、厚生省の責任じゃあないの？とても間に合わないスケジュールで仕様を提示したんだし、仕様を替えられたりして、運用イメージを判っていた人なんて誰もいなかったんだから。
田中 まあ、客観的に言えばそのとおりだよね。厚生省が仕様を二転三転してしまったから、それを追いかけるＳＥさんたちも精一杯だったし、厚生省の仕様書を理解できるユーザさんなんてほとんどいなかったんだしね。
山田 そうそう、どこかのシステム開発は三交代勤務で行われていたっていうから、開発の統括責任者もよくやったということだよね。力業だよね。
田中 完璧に開発プロジェクトが統括できたか？っていうとできていないと思うなあ。
斎藤 それじゃあ、バグもけっこうあるのかな？
田中 そりゃあ出ているだろうねえ。バグのないシステムなんて無いっていっても良い。ただ、問題が発生する前にいかに解決するかが鍵だよ。そんなイタチごっこが夜通し行われているんだろうと思っている。
山田 ユーザさんに見つからなければバグはなかった訳だし、見つかれば仕様です！と言っちゃえば？
田中 そりゃあ無いだろう。
山田 だけどさあ、あるレセプト請求システムでさあ、何と何を続けて指示するとシステムが止まりますので、このような処理をしないでください。もしそうなったらＣＴＲＬ＋ALT＋ＤＥＬを同時に押してください。って平然と言っていたのよ！
斎藤 そりゃあ、すごい！
田中 まあ、パッチがリリースされるまでの間はそんな指示も出されることもあるからね。まあ、許せる範囲かどうか？っていうことだね。
山田 許せる範囲か否かは個人差があるだろうと思うんですけど。
田中 たださあ、介護保険システムの場合は特に異常な状況で開発されたんだから。それを全部ＳＥさんに押しつけるのはどうかなあ？
山田 判っているわよ。でも、私たちに直接的に関係する問題はシステムなの。怒りの矛先は厚生省だけじゃあ収まらないの！
田中 まあ、怒りは一つにしておきなよ。そうそう、今回のシステム開発は仕方なかったというか、厚生省がこのような開発手法を結果的に容認・・・いや、推奨・・・いや、強要した訳だから、固有の問題としての理解しておいてね。これがシステム開発の基本だとは絶対に思わないでね。
斎藤 ＳＥさんも被害者ってことかな？
山田 判ったわ。そういうことにしておきましょう。
斎藤 そうですね。システム開発は委託側が仕様を提示して、提示したとおりのシステムを受託者が開発するんだという原則をきちんと理解しておくことが必要なんだっていうことですね。
田中 そうですよ。そのとおりです。
〜必要なのは「システム」より「カウンセリング」？〜
斎藤 そうそう、最後に極めつけの話をしましょうか？
山田 なになに？
斎藤 あのね、４月分の請求時、ある事業所のシステムが動かなかったんだ。
山田 それって今回はフツーの出来事だよねえ。
斎藤 そこでね、事業所の人はＳＥさんを怒鳴りつけて、動かないんだったらおまえ達でやれ！ってＳＥさんにデータを作らせちゃったんだって！
山田 え〜！？そんなことできるんですか？
田中 馬鹿なこと言っちゃあダメだよ！開発委託契約書やソフトの売買契約書にどう書いてあったかにもよるけど、フツーじゃあ考えられないよ。
山田 よほど良いお客さんなのか、特別な関係だったんでしょ？その分後で回収できなければやらないよねえ。
田中 まあ、真意の程は判らないけど、そんな不条理というか、理不尽なことってあってはならないよ。きっとさあ、窓口のＳＥさんあたりが、「スミマセン」なんて言っちゃって、やるハメになっちゃったんじゃない？それでね、会社に戻ったら営業課長あたりに「バカヤロー！プロジェクト経費内でやれ！」って言われて、みんなから白い目で見られてさあ・・・可哀想じゃないの？これじゃあいい仕事してもらえなくなるよ！
斎藤 可哀想なことをしたもんだ！
山田 でもさあ、身近なところで一緒に悩んでいる方たちだから、つい当たっちゃうのかしらね？
田中 それじゃあ、ＳＥさんは、みんなのカウンセリングまでしなければならないってこと？お金もらわせちゃおうかなあ？
斎藤 そうだ！介護保険にお怒りの方のために、ヘルメットを被った僕たちが訪問してビニールのバットで頭を殴らせて、すっきりさせるベンチャービジネスもいいかもね。
山田 そうそう！１回１０００円でどう？きっと億万長者だ！
田中 だけどさあ、闇の中で開発したんだからさ、仕様の追加は、どの程度の例外処理が発生するのかを見極めて、ユーザとＳＥが一緒に優先順位を考えて二次開発に入って欲しいね。
斎藤 そうだね。追加したらかえって使いにくくなったシステムなんて良くあるからね。
山田 お金もかかるんだから、やはり慎重にお願いすることを考えていかなければ・・・・
田中 二人の所に入っている業者さんは、これで安心できるかな？
山田 ねえ、聞いてもいい？
田中 なに？
山田 私たちの所に入っている業者さん、田中さんの知り合い？
田中 いや、全然知らないよ。
山田 じゃあ、少しぐらいわがまま言っちゃおうかな？
田中 立場を変えてみて我慢できる程度と思うなら言うことだけは言ってみることもいいかもね。
山田 私我慢強いんだ！
田中 こら！
新しいフレームを開いてトップに戻る 同一フレーム上でトップに戻る
フレームを開いていないときは、左側をクリックしてください