システム構築の発注における受注側・発注側双方の注意点！

こんにちは。

小規模事業・個人事業主に向けたITサービス利用のご支援をしています！

ITコーディネータさとよです。

---

システムを構築する際に要件定義フェーズというのがあります。

このフェーズは突き詰めれば実に難しく、数々の失敗プロジェクトの原因を生み出す根源となっています。

まず、一人で開発するシステムづくりについてはこのようなことはないと思います。自分でどんな要件が必要なシステムかを自分で考えて構築する点で齟齬が生まれる余地がないからです。

問題が発生するのは構築を担当する受注者側と発注側のユーザが分かれるときに発生します。

その発生する問題が、要件定義の見方が一緒ではないということに起因します。

要件定義の認識相違はなぜ生まれるのか

どういうことかというと、SEはモノづくりを考えるので、システムにどのような機能を持たせるかというのを考えます。どのような技術でどのような機能を実装させるかを考えます。システムに必要な要件は全部ユーザが提示するべきと考えています。どのような機能を盛り込むかで見積もりを行います。

一方ユーザは業務からシステムを考えています。自分たちの業務に必要な要件を出していきます。細かいことはSEさんが汲んでくれると思って、具体的に提示しないことも多いです。ベテランSEであればそんなことは百も承知で、具体的な要件を確認してくれるSEもいます。しかし、やはり業務を行っていない分多少の漏れが発生してしまうこともあります。

本来であれば、業務要件からシステム要件を抽出して構築するための要件定義をまとめていきます。一般的に要件定義フェーズというのは本来構築サイドで仕上げるというよりは、ユーザ側で実施すべき内容とされていますが、システムに強くないユーザはベンダーにお任せで対応したくなります。

この時注意が必要なのが、システム要件はあくまでシステムを構築するためにエンジニアリング的な要件であって、ユーザが業務を行う際の最適解が反映しているとは限らないということです。

ベンダーお任せで、構築した結果、納品されてきたシステムを使い始めたら、確かに機能的には動くが、この業務にフィットしないとか、この帳票が出せないとか、運用上の問題が出てきます。

ユーザは業務が回らなくて使えないシステムに激怒します。

しかしベンダー側は要件定義に含まれていない要件は知りえません。

要件定義通りに構築していると反発します。

結局使われないシステムが一つ増えただけで、ユーザは楽にならず

という悲し状況がうまれてしまいます。

トラブル・クレーム報告書にコミュニケーション不足が起因などと記載し、再発防止をベンダーが報告するという事態になります。

業務要件はどこで確認するべきなのか

上記の例で言うと、ユーザが行う業務へのフィッティングが本当にうまくいくのかというのを検証しているプロセスがないというところです。

俗に受け入れ検証をしっかり行っているユーザもいますが、システムの機能に目が行きがちで本当の業務がしっかり回ってくれるか検証していないことがあります。

受け入れ検証をしてくれていれば、まだましな方です。私が過去経験したユーザさんの中には安く済ませたいので、ベンダーが作ったシステムテストの再実行で受け入れ検証として要件定義フェーズのコストを削減するという荒業に出たユーザさんもいました。システムテストと受け入れ検証は待ってく異なるフェーズです。

人も予算も限られた中で、そこに充てる人材や時間がないとして構築フェーズは十分に予算確保されているのに、重要視されない傾向があります。

受け入れ検証は実際にはとても重要なフェーズなのです。

しかし、システムが出来上がってから検証しても修正できる範囲にはかぎりがあります。実際にはPoC（Proof of Concept）というフェーズをしっかり行い業務への影響度、フィッティング度合いを検証したうえで要件を整理していくことが必要です。

しかしこのPoCも予算の関係上省略されてしまうことが多々あります。

システム構築で端折れるところなんてない

システムで予算の関係上何かを省略しようとすると必ず後で問題が起こります。納得のいく効果のあるシステムを構築するにはそれなりの予算と時間が必要だと思います。

端折って良い工程など一つもないのです。

営業トークでベンダーも受注がしたいためにユーザさんの予算に合わせて提案しフェーズを端折れるみたいなことをします。

ユーザサイドも予算を抑えたいので端折れるフェーズを探します。

結果確認不足、コミュニケーション不足が生まれて使えないシステムが誕生します。

端折れる工程などないのです。

ユーザとベンダーの架け橋

要件定義というのはシステム開発においてはユーザと構築側の「際」の部分と言っても良いでしょう。この「際」というのは何かと漏れやすいのがシステム開発あるあるです。

この「際」を埋める役目として第三者のコンサルを交えながらシステム開発を行うという方法もあります。

ユーザとベンダーの橋渡し役として、プロジェクトに参加する立場です。

ITコーディネータとしてはそのようなフェーズをご支援することもあります。

多くの国内のコンサルティング会社もこのようなフェーズを担当し、構築はベンダーに任せるか自社グループ会社のSIerに引き継ぐようなことをします。

「際」を埋めるというのはとても重要なプロセスなので、

システム構築の発注における受注側・発注側双方の注意点！としてお含み頂ければと思います。

IT構築はこーでねーと

ITコーディネータのさとよでした。