要注意　要件定義作業の責任は導入者側にもあり！

最近大手の証券会社とこれも大手のIT企業との間で、システム導入失敗の責任を巡る民事裁判の二審判決が出ました。一審ではIT企業の責任と認定しましたが、二審では逆転し証券会社の敗訴となりました。このように、大手企業の大規模システム開発プロジェクトについては、開発投資額が巨大であるが故、失敗が訴訟に直結する場合が多いものです。しかし、なぜこのようなことが起きてしまうのでしょうか？実はこれは大手企業だけの問題ではなく、中小企業の小規模システム導入の時にも実に多く発生していることなのです。

かく言う私も、発注者側として過去何回か失敗したことがあります。「要件定義書を確認して頂いているので、その通りに作りました」という前提で納品されたシステムが、現場の業務に適合していなかったり、要件定義で伝えたことが誤解されたため、実現したい機能が無かった・違っていたということが発覚し、失敗に至る。という経緯が多かったと記憶しています。

今回の事件については、その判決文を全文精査できていませんので、間違いもあるかもしれませんが、どうやら今回の訴訟もこのような類いのトラブルの様で、その経緯は以下の様なものと思われます。

（1）発注後、要件定義作業が始まった

（2）当初計画していた要件定義期間が終わっても、機能要求が出続けたため、要件定義作業が大幅に遅延した。

（3）要件定義書策定以後も追加要求が出続けた

（4）受注側は仕様の固定（これ以上の要求は出さないでください、という「以後何も聞きません」というやり方）を提案したが受け入れられなかった

（5）それでも設計・導入段階に入り、機能確認をし始めたが「不具合（＝これはおそらく仕様に関する相互の誤解とか伝達ミスだと思います）」が多発。

（6）以後、開発の目処が立たなくなりプロジェクト中止

証券会社側としては、開発会社がきちんと要求を理解しきることができなかった、という言い分になる経緯です。しかし、開発側も工数や予算で制約を受けていますので、そういつまでも聞き続けることはできませんし、そもそも契約締結までに基本事項は同意していたはずなので、その時の想定を大幅に超えることはできません。

それでも開発側が追う責任は大きいとは思いますが、ここで着目するべきは（4）の「仕様が固定できなかった」というところです。仕様が固定できない、つまり要求を開発側に伝えきることが出来ない、という事態が発生した責任は発注者側にもあるからです。ごく当たり前のことを言いますが、「こうして欲しい、と言い切ることができるのは発注者側だけであり、開発側はそれを正確に把握することしかアシストできない」ものです。開発側は要求をうまく引き出すためのコミュニケーションを実現する工夫が必要ですが、どんなにうまくコミュニケーションしたとしても、発注側の意図は発注側の口から言ってもらわないと話になりません。

発注者側のキーマンがきちんと要求を伝えきる能力があれば、コミュニケーション失敗の可能性は減りますが、物事を理路整然と説明できない人も世の中には多いものです。そのような場合でもこれをきちんとすることができるのは発注者側の人だけなのです。

今回はどうやら発注者側のキーマンに複雑な業務が属人化してしまっており、それを開発側に伝えきることができなかったということがトラブルの一因となっていると思われます。

これは大規模なシステム開発の時だけに起きるものではなく、かなり小規模なシステム化プロジェクトであっても発生することです。それを防ぐため社長はどうすれば良いのでしょうか？

社長が決裁したシステム化作業なので、自社の担当者が自社の要求を理路整然と開発側に伝える義務があります。それができているかできていないか管理するのは社長の役目と言えます。全部伝えきってそれが実現出来なかったときは開発者側の問題ですが、システム化プロジェクトの失敗事例の大半が要件定義段階に起因しているので、社長や経営層の責任は重大です。この点を自分ごととして捉えられていない社長が主導するシステム化は失敗する可能性が高いのです。

いかがでしょうか？自社のシステム化プロジェクト、少なくとも要件定義段階での進捗やコミュニケーションの質については社長や経営層の関与が必須です。決裁の後部下任せにしない、開発側とどのようなコミュニケーションが出来ているか自ら確認する・・・こういった行動が社長に求められるものなのです。