IT導入・システム開発においては要件や仕様の問題はつきもので、多かれ少なかれ問題は発生します。
仕様を途中から変更することを仕様変更といいますが、仕様変更が多発するとテストなどを進めるにも支障が出てきますので、頓挫の原因にもなりえます。
要件を最初に決めたとしても、仕様に落とし込む段階で、できると思っていたことができなかったり、他の要件から影響を受けて、結果的に一部しか実現できないなど、要件そのものを変更せざるを得ないことも発生します。
仕様として設計していく段階で要件を漏らしてしまったが、既に多くを作りこんでしまい、仕様変更の手戻り影響が莫大となってしまっていることもあります。
このようにプロジェクトの失敗原因となる要件や仕様の問題の事例を見ていきたいと思います。
要件の整理がつかないままプロジェクトがどんどん遅延してしまう
企業グループにおけるシステム統合を目指すプロジェクトでした。グループ企業間に関わる案件ということで、それだけでも難易度が高そうな印象ですが、やはりうまくいかず頓挫したようです。
システム統合の要件定義段階では、すべてを共通機能として提供するのは困難とのことで、共通部分と個別部分を分けて進めていました。
この考え方自身はよくありますし、妥当な見解だったと思われます。しかし、このプロジェクトにおいては要件の問題により遅延が発生し、結果完成しないという事態に陥りました。
原因は、発注側と受注側の双方にあったのですが、どちらかというと発注側の要件未整理が最終的な問題でした。
グループ企業内で要件定義をしなければならなかったため、すべての業務を把握したうえで、共通と個別に切り分け、どちらの要件も確定したうえで進めないといけませんが、どこまでが共通か、個別かという議論がなかなか決まりませんでした。
一旦取り決めたものの、進めていくうちにグループ企業から共通にはできないといった意見や、個別機能に誤りがあるといった指摘が上がってきました。
どこかで要件を決めないと先に進められないといっても、多くの意見を整理するのは一苦労で、グループ企業内を取りまとめなければならない立場である発注側企業においては、とりまとめの責務を全うできなかったということになります。
要件の漏れによりITシステムプロジェクト完了したかと思いきや未完成
要件の中には、ITシステムに具備されるべき機能に関する要件と機能以外の非機能要件と言われるものがあります。
非機能要件で代表的なものの中に、性能要件があります。処理に対する処理速度を表します。
性能は予め取り決めるべきものですが、近年コンピュータの処理速度はスマホであっても高いため、そんなものに問題が出るわけがないだろうと思われてしまいます。
しかし、この事例においては結果動かないITシステムとみなされています。
この事例は重機械の点検システムのシステム開発プロジェクトでした。点検のためのリモート操作については、レスポンスが重要でした。
発注側は要件として、レスポンスを例えば2秒以内等として明示していたわけではありませんでした。
しかし、業務実行の場面を受注側のITベンダーと共有しており、その証拠もありました。明示はされていないものの、リアルに現場とやりとりを行うものであり、レスポンスの重要性は言うまでもありませんでした。
その一方で受注側のITベンダーとしては、リモート操作中に参照すべきデータの量や回線速度の問題から、レスポンスが1分以上になってもおかしくないと思っていました。
この事例は典型的な性能要件漏れとなりました。
しかも受注側が実現したいものの中での重要性を見失ったことが問題でした。
発注側としても、結果役に立たないITシステムが納品されても困るだけだと思います。できる限りデジタルなものとして要件を定義しておくべきでした。
・既存システム仕様どおりという要件が実現できず頓挫
既存システムが存在し、新たなITシステムを導入・開発するプロジェクトは多く存在しますし、その際に発生する典型的な仕様の問題が既存システムどおりの仕様という要件によるものです。
既存システムが存在する場合、何をやりたいかという要求は、既にやれていることは当然のこととして、新たにやりたいことが中心の要求となってしまいます。
新たにやりたいこと以外の部分は、既存システム仕様どおりというのが要件となります。
化学品メーカーにおいてERPパッケージを導入するプロジェクトで発生した問題です。結果としては頓挫し、大惨事となっています。
当IT導入・システム開発のプロジェクトにおいては、比較的順調に進められているように見られました。しかし、終盤に近づいた段階で、実現すべき仕様に漏れがあったことが発覚しました。
その使用を実現するには多大な追加金額が発生するというのが、受注側であるITベンダーの言い分でした。発注側企業は、既存システムの仕様であり、受注側の漏れによるものという主張をしました。さらにプロジェクトが遅延したことで、損害が発生しているという見解も示しています。
今回のプロジェクトはERPというパッケージを導入することでしたので、要件すべてを隅から隅まで定義するというよりは、パッケージに業務を合わせるという面も出てきます。
初期段階で既存業務とパッケージのフィット＆ギャップも行っていました。
しかし、やはり既存システムの仕様に基づく業務をすべて事前に把握することはできませんでした。
プロジェクト終盤で漏れが明らかになったのですが、既存システムどおりの仕様という要件があったということは、認められるでしょうか。
このケースにおいては認められませんでした。
結果的に発注側企業は追加費用が支払えずに、頓挫となりました。
既存システムが存在した場合は、その中に重要な業務プロセスが内包されています。安易にパッケージに合わせたほうがよいはずだ、という思い込みをするべきではありません。
パッケージの導入実績が多いということで、当然仕様を満たしているだろうと思っても、そうでないこともあります。
この事例以外にも、既存システム仕様どおりが実現できなかった問題は複数ありますし、大いに注意すべき事項のひとつです。
当然の仕様が反映されていないことで、ITシステム未完成
医療関係のIT導入・システム開発においての事例です。
電子カルテと医療事務システムをつなぐシステムの開発をITベンダーに依頼しました。ITベンダーはある程度医療関係の経験があり、よくわかっているだろうという期待の下、プロジェクトは進められました。
ところが、プロジェクトの後半のテスト段階において、大きな仕様漏れが発覚します。
仕様をあるべき姿にするには多大な費用がかかりそうでした。この仕様の問題は、事務システムとつなぐ際に項目が不足していたということでした。
医療関係者であれば想像できそうな項目ではあります。しかし要件定義としては、明記されていたわけではありません。
当然のこととして、医療機関側も特に言わなかったとしています。
しかし実態は、要件漏れと思われます。
業界や業種においては取引慣習・ルールなどが当然のこととして決まっていることもあると思います。
関係者同士であれば、当然のこととして受け入れるものもあるでしょう。
しかし、当然の仕様という要件は存在しません。要件は要件として明示されている必要があります。
この事例においては、発注側の問題として扱われています。
当然のことをいちいちすべて並び立てるのは苦痛のこともありますが、わかりきっていると思われることでも、きちんと決めないとうまく動かないのがITシステムです。
プロジェクト担当外からの仕様影響で、動かないITシステム
専門商社にて受発注システムの構築プロジェクトを進めていました。発注側の専門商社は受発注業務をITベンダーAに依頼しました。
この企業は基幹システム刷新の大規模プロジェクトを進めているところでした。ERPパッケージ導入により、中核業務を刷新し、受発注に関しても一部はカスタマイズで、一部はERPで実現する予定となっていました。
ERPパッケージ導入そのものは、ITベンダーBが担当していました。
受発注システムのプロジェクトを進めているうちに、基幹システムとの連携にて致命的な項目の漏れが発覚しました。
受発注システムはキャンセル処理がルールにのっとるため、ERPのルール仕様に則る必要があります。後から考えれば当然のことですが、当事者はその場その場で仕様を取り決めてきており、鳥瞰的に見る目が不足していました。
結果、仕様が漏れており、受発注システムは動かないものとなってしまいました。影響がかなり大きく、ERP側を修正するのか、受発注側を修正するのか、揉めている間に、受発注システム側のプロジェクトは中断となってしまいました。
他にITシステムのプロジェクトが実行されており、影響がある場合は、発注側のプロジェクトマネジメント責任が問われます。
ITベンダー間においてはある程度は仕様確認を行うことはできるでしょうか、最終決定は発注側が実施すべきこととなります。
今回の事例は、受発注という一部機能が動かないまま、発注側が費用負担をすることとなります。
まとめ
IT導入・システム開発のプロジェクトが失敗となる原因として要件・仕様が決まらない、漏れていたという問題が一番多いです。受注者はITシステムのプロとして受託しているわけなので、実現すべきものを仕様として作りこめる能力が当然あるべきです。
しかし、ITシステムにおいては、そもそも何をしたいかというのは発注側の要求であり、何を作るのかも発注側の要件であるので、受注側がなんでも決められるわけではありません。
様々な要因はあるものの、要件の整理がつかない、要件が漏れているといったことは発注側の不注意や管理不足によるものがあります。
また、仕様が実装されていない要因についても、言わなくても当然の仕様と思っていたり、既存システムの仕様が未実装であったりと、後から言った言わないの議論になります。さらに発注側責任となることも多く発生します。
発注側がプロである受注側に仕事お願いしている関係ではありますが、発注のプロジェクトマネジメント能力が問われるケースも多々あります。
発注側の要員や力量の不足が予測される場合は、ITベンダーとは別に支援を依頼することも考えられます。
コメント