連載
それでも最善を尽くす、それがベンダーの仕事だ――「旭川医大の惨劇」解説その3:「訴えてやる!」の前に読む IT訴訟 徹底解説(49)(2/3 ページ)
ユーザーが出し続けた1000を超える追加要件にベンダーが対応仕切れずプロジェクトが破綻した「旭川医大vs.NTT東日本 病院情報管理システム導入頓挫事件」。病院という「特殊な」ユーザー相手に、ベンダーはどうすべきだったのか――細川義洋氏による同事件のポイント解説、第3弾は「特殊なユーザー」のプロジェクトを成功に導くための方法と考え方を指南する。
「特殊事情」のあるユーザー
私は前回、問題が起きたのは、「ユーザー側の体制や状況について、プロジェクト開始前の確認が足りなかったからではないか」と書いた。
医療現場で本当に要件を決められるのは医師だ。現場で医療システムを使う彼らの意見なしには良いシステムはできない。しかし医師は皆診療や研究に忙しいので、システム開発に協力する時間を十分にはとれない。決まった日時に開催される要件検討会議には出られないが、良いシステムにしたい思いはあるので、数多くの変更要望を出してくる。
さらに、要件のとりまとめを行うはずのシステム部門のメンバーは医療の知識が少なく、組織内の力関係もあって勝手に要件を確定させられない。大方こんな感じだったのではないだろうか。
どんなシステム開発プロジェクトでも、エンドユーザーたちが忙しくて要件検討に十分参加してくれなかったり、ワガママな要望を出したりしてくることはままある。しかし旭川医大は極端過ぎた。とても当初のスケジュールを守れる状況にはなかった。というよりも、プロジェクトスタート時点で実現可能なスケジュールをひくことさえ、ベンダーはできなかったのではないだろうか。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 私は忙しいんです。システム開発に協力できる時間なんてありません――「旭川医大の惨劇」解説その2
ユーザーが出し続けた1000を超える追加要件にベンダーが対応仕切れずプロジェクトが破綻んした「旭川医大vs.NTT東日本 病院情報管理システム導入頓挫事件」。悪いのは100%ユーザーなのか、ベンダーはどうすれば良かったのか――細川義洋氏による同事件のポイント解説、第2弾は「体制」と「開発方針」について考察する - 追加要件を実装しなければ、このシステムは使いません――「旭川医大の惨劇」解説その1
ユーザーが要件を次々と追加、変更させたために失敗したプロジェクトの責任は、要件追加をやめなかったユーザーにあるのか、それとも、それをコントロールできなかったベンダーにあるのか……。2017年8月に第二審判決が出た「旭川医大vs.NTT東日本 病院情報管理システム導入頓挫事件」のポイントを、細川義洋氏が解説する。 - ベンダーはどこまでプロジェクト管理義務を負うべきか
プロジェクトを円滑に推進し完遂するために、ベンダーはどのような活動を行う義務があるのか。ある裁判の判決を例に取り、IT専門調停委員が解説する - 「PoC」の進め方──メンバー選定、環境構築、データ収集と活用、評価まで
導入前検証である「PoCの進め方」全8工程を解説します - 現場の無駄な流血を止めるための「プロトタイプ」とは
プロトタイプとユーザビリティテストは、そもそもどういうものなのかを再考し、プロジェクトに「追加」するのではなく「織り込む」にはどうしたらいいのかを具体的なツールも交えながら考察します