私は忙しいんです。システム開発に協力できる時間なんてありません――「旭川医大の惨劇」解説その2:「訴えてやる!」の前に読む IT訴訟 徹底解説(48)(3/3 ページ)
ユーザーが出し続けた1000を超える追加要件にベンダーが対応仕切れずプロジェクトが破綻した「旭川医大vs.NTT東日本 病院情報管理システム導入頓挫事件」。悪いのは100%ユーザーなのか、ベンダーはどうすればよかったのか――細川義洋氏による同事件のポイント解説、第2弾は「体制」と「開発方針」について考察する。
特性をふまえて「スケジュール」や「開発方針」を検討すべし
病院相手のプロジェクトは、要件定義の期間が通常の2〜3倍かかると覚悟した方がよいし、医師への説明と確認を辛抱強く行うことが必要だ。
開発方式は「ウオーターフォール」ではなく、部分的に要件を確認しながら小規模な実装を積み上げていく「アジャイル」の方が良かったかもしれない。
アジャイル開発であれば、業務の都合上、最低限必要な機能から順次リリースできるし、取りあえず基本的な画面を作った上で、それを見ながら追加の要望を取り込むことも効率的に行える。作りかけの画面やリリースした画面を見ながら要望を検討できるので、忙しい時間を割いてくれる医師たちのストレスも軽減できただろう。
誤解のないように申し上げるが、私は「今回の開発は、スケジュールに余裕を持って、アジャイル開発で行うべきだった」と短絡的に申し上げているわけではない。
大切なのは、「スケジュール」や「開発方針」を含む「プロジェクト計画」を考えるときは、「ユーザーの体制」「スキル(システムや業務に関する知識)」「関与度」「現場とシステム部門の力関係」「精神状態」などを考慮した上で、「ユーザー組織の都合(システム化の目的や組織としてのデッドラインなど)」と掛け合わせて検討することが必要だということだ。
そもそも、これはやってもよいプロジェクトだったのか
ベンダーの多くは、最終的な納期を確認した後、類似システムの開発経験や自身の要員計画などを元にスケジュールを決め、開発するシステムのタイプに応じてアジャイルやウオーターフォールなどの開発方針を決める。しかし、そこにユーザー、特にエンドユーザーの体制や都合を色濃く反映していかないとうまくいかないことが多い。
以前、生命保険会社のコールセンターシステム構築でプロジェクトマネジャーの役割を担ったときのことだ。要件定義工程はエンドユーザー部門の責任者だけが参加してくれればよいと当初考えていた私は、オペレータースタッフたちをプロジェクトに参加させるべきだと途中で気が付いた。
オペレーターの参加決定後に確定したスケジュールや開発方式は、当初のものとは似ても似つかないものだった。しかしこれは、現場にしか分からない作業の詳細を理解し、オペレーターに会議に参加してもらう時間を確保するために、どうしても必要な変更だった。
そのプロジェクトは納期を順守して完了したが、要件の優先順位は当初案とは随分と違ったものになった
今回の旭川医大のプロジェクトがどのような状態であったのか、門外漢の私には分からない。少なくとも現場の医師の関与を大切に考えた上で、ベンダーがスケジュールや開発方針を検討していれば、惨劇は起こらなかったのではないかと考える。
そして、そうやって作ったプロジェクト計画にユーザーがどうしても合意しないならば、そんな開発はそもそも請け負うべきではないかもしれない、とも思う。
※「旭川医大の惨劇」解説記事、その3は11月6日に掲載します(編集部)
細川義洋
政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員
NECソフト(現NECソリューションイノベータ)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。
独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。
2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる
書籍紹介
本連載が書籍になりました!
成功するシステム開発は裁判に学べ!〜契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック
細川義洋著 技術評論社 2138円(税込み)
本連載、待望の書籍化。IT訴訟の専門家が難しい判例を分かりやすく読み解き、契約、要件定義、検収から、下請け、著作権、情報漏えいまで、トラブルのポイントやプロジェクト成功への実践ノウハウを丁寧に解説する。
細川義洋著 ダイヤモンド社 2138円(税込み)
システム開発に潜む地雷を知り尽くした「トラブル解決請負人」が、大小70以上のトラブルプロジェクトを解決に導いた経験を総動員し、失敗の本質と原因を網羅した7つのストーリーから成功のポイントを導き出す。
プロジェクトの失敗はだれのせい? 紛争解決特別法務室“トッポ―"中林麻衣の事件簿
細川義洋著 技術評論社 1814円(税込み)
紛争の処理を担う特別法務部、通称「トッポ―」の部員である中林麻衣が数多くの問題に当たる中で目の当たりにするプロジェクト失敗の本質、そして成功の極意とは?
「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則
細川義洋著 日本実業出版社 2160円(税込み)
提案見積もり、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。
細川義洋著 日本実業出版社 2160円(税込み)
約7割が失敗するといわれるコンピュータシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 追加要件を実装しなければ、このシステムは使いません――「旭川医大の惨劇」解説その1
ユーザーが要件を次々と追加、変更させたために失敗したプロジェクトの責任は、要件追加をやめなかったユーザーにあるのか、それとも、それをコントロールできなかったベンダーにあるのか……。2017年8月に第二審判決が出た「旭川医大vs.NTT東日本 病院情報管理システム導入頓挫事件」のポイントを、細川義洋氏が解説する。 - ベンダーはどこまでプロジェクト管理義務を負うべきか
プロジェクトを円滑に推進し完遂するために、ベンダーはどのような活動を行う義務があるのか。ある裁判の判決を例に取り、IT専門調停委員が解説する - 2年超も仕様が確定しないのは、ベンダーの責任か?
システム設計書を提出しても、プロトタイプを作成しても、どうしても仕様を確定させてくれないユーザー。この契約、解除しても大丈夫? - ユーザーが資料をくれないのは、ベンダーの責任です
ユーザーが要件定義に必要な資料を提供しなかったため、システム開発が頓挫した。責任を取るべきはユーザー、ベンダー、どちらでしょう? - ベンダーのプロジェクト管理義務(べんだーのぷろじぇくとかんりぎむ)
ンダーのプロジェクト管理義務とは、ITの専門家であるベンダーが「請負契約のシステム開発で、ユーザーの目的を達成するために、自らの知見、経験を発揮し、プロジェクトを円滑に進め、ITの専門家としての責任を果たすこと」を約束するものです