誰か知る松柏後凋の心

たれかしる しょうはくこうちょうのこころ

病院情報システムのプロジェクト、そして次世代のプロジェクトリーダー

先日、仕事先でプロジェクトのキックオフの会に参加してきた。

今月初めに新しく決まった、大学病院のシステム更新の仕事である。

私としては国循を起訴休職となった2014年11月以来、医療情報システム分野では久しぶりの仕事となる。私としては4年のブランクが気になるところではあるが、いずれにしても、これまでのような病院側の立場ではなく、業者側の立場でこのようなプロジェクトに参加するのは初めてのことであるので、初心に立ち返ってやらねばなるまい。身の引き締まる思いである。

病院情報システムに限らず、大型の開発プロジェクトには困難がつきまとう。工数が多いほど関わる人も増え、担当領域ごとにわかれてプロジェクト内に複数のチームができる。チーム内のメンバーも増える。そうすると、チーム内、チーム間のコミュニケーション不足などの理由により想定外の事態が発生する頻度も高くなるし、チームごとのタスクの前後関係・優先関係も複雑になり、そういった問題の最適解を求めるのも容易でなくなる。情報伝達の速度も遅くなる。プロジェクトリーダーが知ったときにはもう手のつけようがない、ということもよく耳にすることである(そもそも問題は隠蔽されやすいのでこれはプロジェクト規模の大小に拠らず発生する)。

 

病院情報システムのプロジェクトの破綻例は枚挙に暇がない。最近では、旭川医科大学の例が記憶に新しいところである。

storialaw.jp

この記事を読むまで私も知らなかったが、旭川医大側の上告は受理されず、判決は平成30年5月11日に「病院側の完全敗北」で決着したようである。

古くは、「九州大学SmalTalk事件」である。

http://drillbits.tumblr.com/post/15664104845/九大病院つまずきの真相-要件定義の甘さが尾を引く

drillbits.tumblr.com

病院業界だけではない、銀行でもある。有名なのは「スルガ銀行」であろう。

tech.nikkeibp.co.jp

上記はいずれも裁判になったものであるが、もちろん、現実には、裁判にならない事例がほとんどであろう。(ちなみに、私が挙げた上記3事件にはいずれも日本IBMが関与しているが、そのことに大きな意味はない)ここまで拗れるのは論外としても、重要な教訓は、業者側にもプロジェクト管理の義務があるという点である。いくらユーザが無茶な要求を積み重ねようとも、プロジェクトが失敗するリスクを背負ってまでそれを受け入れる必要はないということである。

さて、その新しいプロジェクトの、病院側のリーダーは30代の若手である。高校を卒業してすぐに病院の事務職として採用され、いきなり現場にたたき込まれて情報システムのなんたるかを知り、以後ずっとシステム担当を続けているという強者である。ここまで来るのに相当な苦労を重ねてこられたことがうかがえる。私は一回り上であるが、私は社会人を経てこの業界に入ったので、業界のキャリアはほぼ同じである。

キックオフで、そのリーダーが最後に言った言葉は、

プロジェクト成功に導くための基本中の基本として、隠し事をしないでほしい。そこから生まれた綻びがプロジェクトを破綻に至らしめる。自分たちも「モノが言いにくい」環境を作らないように努力するので、どうかよろしくお願いしたい。

正鵠を得た発言である。まさに次世代の医療情報システムを担う人材といえる。実は、私たち業者側のチームのリーダーも彼と同じく30代である。2人の間のコミュニケーションが重要である。何をやって何を捨てるかを決める。そういった局面がこれから出てくるはずである。私は、プロジェクト全体を見て、彼ら2人を支えていかねばならないだろう、そう思わされた瞬間であった。