Movatterモバイル変換


[0]ホーム

URL:


はてラボはてな匿名ダイアリー
ようこそ ゲスト さんログインユーザー登録
< anond:20250213220930 |既婚女の生き様 >

2025-02-14

AI生成記事

九州大学病院オブジェクト指向システム導入の記録

序章:革新的システムへの期待

1990年代半ば、九州大学病院(九大病院)は病院情報システムの全面刷新計画していた。従来の断片化したシステム統合し、最先端オブジェクト指向技術を全面採用した次世代システムに生まれ変わらせるという大胆な構想である

tumblr.com

。入札条件にも「純粋オブジェクト指向技術で実現すること」を掲げ、業界内でも前例の少ない大規模プロジェクトに挑むことになった​

tumblr.com

。この計画応札した日本IBMは、開発言語にSmalltalk採用し、社内外からオブジェクト指向開発の専門家を総動員する。日本IBM自身のチームに加え、Smalltalk豊富経験を持つ多数のシステムインテグレータ各社が協力企業として参画し、一時期は約200名もの技術者が開発に従事する巨大プロジェクトとなった​

tumblr.com

医療現場からは「21世紀を先取りするシステムになる」という期待の声が上がり、IBM側も「国内最高峰病院に最新技術を投入できる」と意気込んでいた。誰もが、この試みに大きな希望を抱いていたのである

1996年プロジェクト始動曖昧要件定義

プロジェクト1996年、本格的に動き始めた。九大病院情報システム担当者たちは、院内各部からシステムへの要望ヒアリングし、「新システムへの要望リスト」を作成して日本IBM提示した。しかし、その内容は具体性に欠けていたと言われる。「実現したい業務全体像がはっきりしていなかった」のだ。病院側は約1,400床を擁するマンモス病院ゆえ、部門ごとの意見をまとめ上げ全体方針を打ち出すことが難しく、提出された要件定義書は「中身はほとんどなかった」と関係者は振り返る。一方の日本IBMも、その不十分な要件定義を十分詰め直すことなく開発を進めようとし、この問題放置してしまった。プロジェクト序盤から、実は大きな不安の種が芽生えていたのである

それでも当初の計画は極めて野心的だった。フェーズごとに順次システムを稼働させる計画で、第1次カットオーバー最初の稼働開始)は1997年1月と定められていた​

tumblr.com

。限られた時間の中、日本IBMと協力各社の開発チームはオブジェクト指向の新手法に挑みつつ、多数のサブシステムを並行開発するという難事業に取り組み始めた。しか要件曖昧さは各所で影響を及ぼす。開発メンバーの一人は後に「実際にはオブジェクト指向入り口にさえたどり着けなかった」と語っており、肝心の新技術を活かす以前に基本事項の詰め直しに追われる状況だったという。

1997年初頭:見えてきた遅れとすれ違う思惑

年が明けて1997年になると、第1次稼働予定の目前になっても開発は難航していた。結局、日本IBM1996年10月末になって九大病院側に「当初予定の1997年1月にはシステム稼働が間に合わない」と突然伝えることになる。これは病院側にとって青天の霹靂であった。代替策として「一部機能範囲を絞れば1月稼働も可能」といった提案すら無く、一方的に延期が告げられたことに、病院担当者たちは強い不信感を抱いたという。プロジェクトマネージャー同士の密なコミュニケーションも欠如しており、延期決定前から両者の意思疎通は十分でなかったようだ。これが最初の綻びとなった。第1次稼働時期は当初計画より9カ月遅れ1997年10月へと大幅に後退する​

tumblr.com

この延期表明を境に、現場は混乱に陥る。病院側は日本IBMだけに任せておけないとの思いから、一部の協力会社と直接組んで独自プロトタイプ開発に乗り出すなど、プロジェクト体制は分裂気味になった。一方、日本IBM側の士気も下がり始める。ある協力会社メンバーは「これほど求心力のないプロジェクトも珍しい」と当時を振り返り、リーダーシップ不足だったIBM姿勢に驚いている。複数の外部企業(延べ10社以上)が関与する巨大プロジェクトでありながら、日本IBM1997年10月頃まで一貫して主導権を握れずにいた、と多くの関係者が指摘する。誰がハンドルを取っているのかわからないまま巨艦だけが突き進む――そんな不安定な状況であった。

事態を重く見た九大病院日本IBMは、1997年2月から6月にかけて要件定義のやり直しに着手する。一度作成した要件定義書を更地に戻し、業務フローも含めてゼロから整理し直す作業だ。しかしこのリカバリーにも時間を要し、プロジェクトの遅延はさらに広がっていった。「ようやく問題点に光を当て始めたかに見えたが、時すでに遅し。気づけば頭上に厚い雲が垂れ込めていた」と語る関係者もいる​

b.hatena.ne.jp

プロジェクトは先の見えないトンネルに入り込み、関係者の心にも次第に不安が募っていった。

1997年春:一筋の光明オブジェクト指向データベースの導入

混迷を極めるプロジェクトに光が差し込んだのは、1997年春のことである要件定義の立て直しと並行して、日本IBMシステム技術基盤を強化すべく重大な決断を下した。従来のリレーショナルDBではなく、米国GemStone Systems社のオブジェクト指向データベース(ODB)「GemStone」を採用する方針を固めたのだ​

tumblr.com

。GemStoneはSmalltalkとの相性が良いことで知られ、オブジェクト指向開発との親和性が高い製品である

tumblr.com

。この採用決定に伴い、GemStone社から複数名のコンサルタント来日プロジェクトに参加。停滞していた開発体制の再整備が行われた​

tumblr.com

経験豊富専門家の助言により設計も見直され、チームはようやく開発の目処を掴み始めたのである

tumblr.com

病院側もこの動きを歓迎した。長引く遅延に業を煮やしていたものの、最新のODB導入で性能や拡張性の課題解決されるならばと期待を寄せた。協力各社の技術者たちも「ようやくトンネルの先に光が見えた」と胸をなでおろした​

b.hatena.ne.jp

現場には久々に前向きな空気が漂う。遅れを取り戻すべく、再結集した開発チームはスパートをかけた。システム全体のアーキテクチャをGemStone前提に再設計し、失われた時間を埋めるため懸命な努力が続けられる。巨大プロジェクトは今、再び軌道に乗ろうとしていたかに見えた。

1997年夏:GemStone契約交渉の決裂、暗雲の再来

しかし、その光は長くは続かなかった。1997年7月初旬、プロジェクトに再び試練が訪れる。日本IBMとGemStone社との契約交渉が突如決裂し、参画していたGemStone社コンサルタント陣が全員帰国してしまったのだ。肝心のGemStone製品も利用不能となり、頼みの綱を断たれた開発チームは一瞬にして暗闇に放り込まれた。まさに「悪夢のような出来事」であった。

7月20日になって、日本IBMはようやく協力各社を集め緊急説明会を開いた。日本IBM側の説明によれば、「GemStoneとの交渉決裂は企業日本IBM)の根幹に関わる問題による」という。詳しい理由として、契約書の条項に**「システムユーザー等が何らかの理由でGemStone社を訴えた場合、メイン・コントラクタである日本IBMが全ての法的対応を負わねばならない」といった内容が盛り込まれており、日本IBMはこの重い責任リスクを受け入れられなかったのだという。さらに料金面でも折り合わず、3カ月間におよぶコンサルタント8名の派遣ソフトライセンス料などに数億円近い費用**を要求されたことも判明した。法的リスクコスト高騰――企業として譲れぬ一線を越える契約条件に、日本IBMは最終的に「ノー」を突きつけた形だ。だが、それは即ちプロジェクト生命線を断つことを意味していた。

この報に接した開発現場は騒然となった。GemStoneを中核に据えて進めてきたアーキテクチャ設計を一から練り直す必要が生じたためである。ある協力会社関係者は「この時点でプロジェクトの失敗を覚悟した」とまで語っている。大黒柱を失ったチームには動揺と失望が広がった。折しも夏本番を迎え、福岡の空は照りつける日差しに覆われていたが、プロジェクトには再び厚い雲が垂れ込め始めた。

1997年8~9月代替案への賭けと懸命の設計変更

GemStone脱落という非常事態に対し、日本IBMと九大病院必死リカバリーを図る。1997年8月上旬、急遽代替のODB製品としてフランスA.D.B社の「Matisse」を採用する決断が下された。Matisseは国内では知名度の低いODBだが、日本でも過去Smalltalkアプリケーションデータベース採用された実績があり、「何とか使えるめどは立つ」と判断されたのである

しか代替とはいえGemStoneとMatisseでは機能に大きな違いがあった。GemStoneで可能だったサーバ側でのSmalltalk処理実行がMatisseではできず、セキュリティ機能も貧弱だったため、開発チームは不足分を自前で作り込む必要に迫られた。この結果、システム全体の設計クライアント中心処理へ大幅に変更せざるを得なくなり、再び設計の手戻り作業が発生した。炎天下での再出発であるエンジニアたちは寝食を忘れ、懸命にコードを書き直した。

その甲斐あってか、1997年9月末の時点で第1次開発の主要部分を年内に実現できる見通しが立ったという。一度は暗転したプロジェクトにも、わずかながら光明が見えた。病院側も「何としても年内稼働を」という思いで支援を続ける。だが、このとき水面下では別の動きが進んでいたことを、現場の多くは知らなかった。

1997年10月:小さな後退、大きな決断

1997年10月9日、事態は最終局面を迎えた。この日開かれた会議で、日本IBMSmalltalkによる開発断念と、マイクロソフト社のVisual BasicVB)への全面的方針転換を突如宣言したのである晴天の霹靂とも言えるこの決断に、現場は凍りついた。幾多の苦難を乗り越えようやく目指してきた最先端技術での構築を諦め、当時広く普及していたVBという「オブジェクト指向ではない」開発ツールで作り直すというのだ。九大病院が当初求めた**「純粋オブジェクト指向」**という条件にVB合致するかは議論の分かれるところだが​

tumblr.com

病院ももはや背に腹は代えられない。最優先すべきはシステム稼働そのもの――この苦渋の転換を受け入れる以外になかった。

実はこの決断に至る伏線存在した。日本IBM1997年4月からかにVB採用可能性を九大病院に打診しており、さら8月からは段階的にSmalltalk担当エンジニア現場から引き上げ始めていたという。ある協力会社メンバーは「裏ではVBによる開発をすでに進めていたようだ」と振り返っている。つまりGemStone交渉決裂後、表向きはMatisseによる巻き返しを図る一方で、日本IBM本体は別動隊でVBシステムの構築に乗り出していた可能性が高い。振り返れば、日本IBMにはSmalltalk固執しない理由もあった。同社は翌98年2月長野冬季オリンピック向けシステムSmalltalkで構築しようとして失敗し、結局VBで作り直したという“前歴”もあったと伝えられる。アトランタ五輪1996年)では自社Smalltalkツール(VisualAge)を投入したものの、国内の大型案件では苦戦が続いた経緯があった*4。豊富人材がいるVBなら「最後人海戦術で何とかできる」という計算も働いたようだ。GemStoneとの契約不成立も、IBMにとっては結果的Smalltalkを断念する良い口実になったのではないか――協力会社メンバーの一人はそんな憶測さえ口にする。

方針転換の発表とほぼ同時に、Smalltalkで開発を担っていた協力会社の大部分はプロジェクトから撤退することになった​

tumblr.com

10月中旬には、多くの外部技術者が病院を後にしている。自ら招いた転換とはいえ日本IBMにとっても苦渋の決断であった。投入したリソース費用は莫大で、一からVBで開発し直すのは会社としても大きな後退だ。しかし背に腹は代えられない状況まで追い詰められていたことも事実であろう。IBM現場責任者は病院側に深々と頭を下げ、「必ずや残された方法で間に合わせます」と約束したという。九大病院担当者も沈痛な面持ちで頷き、「形はどうあれ、患者さんに影響を及ぼす前にシステムを動かしてほしい」と絞り出すように告げた。

以降、日本IBMは自社内のVB技術者や、自社が持つ病院向けオーダリングシステムパッケージ製品*5などを総動員してシステム構築を続行した​

tumblr.com

データベースも、当初IBM提案していながら見送っていた自社のリレーショナルDBDB2」を採用する公算が高まった​

tumblr.com

目標は「年度内(1998年3月まで)の第1次稼働」​

tumblr.com

。もはやオブジェクト指向の夢を追う余裕はない。現実的かつ確実に動く仕組みを、一刻も早く届ける――プロジェクトはその一点に向け再編成された。かつて200名近くいた開発陣は大幅に縮小され、構成メンバーも一変する。病院看護師スケジュール管理など一部のサブシステムは、撤退しなかった協力会社が細々とSmalltalk開発を続けていたが、その姿はもはや主流から外れた存在となっていった​

tumblr.com

。ある古参の協力技術者は去り際に「全力を出して戦う前に、白旗を上げてしまったという感じがする」と寂しげに語ったという。こうして九大病院プロジェクトの第1フェーズ――オブジェクト指向技術による野心的挑戦のフェーズは幕を下ろしたのであった。

1997年末:現場への波紋と社会的注目

VBへの方針転換後、九大病院現場には複雑な空気が流れていた。病院スタッフにとってシステム刷新は長らく待ち望んだ悲願だったが、その中身は当初聞いていた「最新技術結晶から一転して、従来型の技術で作られるものになってしまった。「結局、夢物語に終わったのか」という落胆の声も一部にはあった。しかし同時に、「多少古くてもいい、とにかく業務改善する仕組みを早く動かしてほしい」という切実な声も強まっていた。目指すゴールは変われど、一日でも早く新システムを稼働させ、慢性的業務負荷を軽減することが現場の切実な願いとなったのだ。プロジェクトチームは日夜作業を続け、簡易な操作研修なども始めながら、年明けまでの稼働に向け突き進んだ。

そんな中、1997年11月3日付の西日本新聞朝刊一面にこのプロジェクトに関する記事掲載される。タイトルは「九大病院システム未完 巨額費用批判」。内容は「九大病院システム未完成にもかかわらず日本IBMに月額4,250万円を支払い続けており、税金無駄遣いとの指摘が出ている」という衝撃的なものだった。同日、このニュース地元RKB毎日放送東京ではTBS)のテレビニュースでも報じられ、九大病院プロジェクト社会問題として一気に世間の注目を浴びることとなった。院内では「患者そっちのけで何をしているのか」といった批判も耳に入るようになり、大学本部所管官庁からの問い合わせも相次いだ。追い打ちをかけるように外部から視線が厳しくなる中、病院IBMはただひたすら開発を前に進めるしかなかった。

結末:プロジェクトの結末と残された教訓

1998年初頭、紆余曲折を経た九大病院の新システムは、当初の構想とは似ても似つかない形でようやく一部稼働に漕ぎつけた。日本IBMは多数のVBプログラマを投入して力技でシステムを完成させ、旧来システムの置き換えを順次進めていった。最終的に納入されたのはSmalltalkでもオブジェクト指向DBでもなく、Visual BasicリレーショナルDBによるシステムだった。かくして九大病院の「純粋オブジェクト指向システム」への挑戦は事実上の敗北に終わった。現場医師職員は、当初期待された華々しい先端技術恩恵を受けることはなかったが、ひとまず業務に支障のない情報システムが手に入ったことで安堵するより他なかった。プロジェクトは当初の理念を捨てて現実路線へ舵を切ることで、なんとか沈没だけは免れたと言えるだろう。

振り返れば、この失敗の背景には最新技術への挑戦ゆえの困難もあったが、それ以上に古典的とも言えるプロジェクト運営上の

Permalink |記事への反応(0) | 21:29

このエントリーをはてなブックマークに追加ツイートシェア

記事への反応 -

記事への反応(ブックマークコメント)

全てのコメントを見る

人気エントリ

過去の人気エントリをもっと見る

注目エントリ

はてなブックマークでもっと見る
ログインユーザー登録
ようこそ ゲスト さん
Copyright (C) 2001-2025 hatena. All Rights Reserved.

[8]ページ先頭

©2009-2025 Movatter.jp