「なぜ使えないシステムが納品されるのか?」(その2)

要件定義をきちんと作るという方向性

さて、それではどうやってもシステム開発は失敗する宿命のものなのでしょうか?

そんなことはありません。システム開発を成功させる方法にはいくつかの方向性があります。

1つには、「要件定義をしっかり行う」ということです。

システム開発は要件定義で決められた内容をゴールにして行われるのですから、時間をかけてそのゴールを定義すればよいのです。
通常、要件定義書というのは文字(文章)で書かれていますが、重要でかつ文字ではイメージしにくい画面などはモックアップ(サンプル)を作ってもらい要件定義の補助資料として別添してもらいます。画面の表示される速度なども、「4秒以内に表示されること」など具体的な数字でスペックを保証してもらいます。

その上で見積りをもらって契約を行えば、その要件定義を満たさない部分はすべて瑕疵(不良箇所)となります。瑕疵は納品後に発覚すれば無償にて修繕をさせることができますし、もし「直せない」となれば料金を払わないと主張することも可能です。

しかしながらこの方向性でシステム開発の成功確度を高めようというのは現実にはかなり難しいです。

まず、やはりどんなに頑張っても全ての要件を事前に書き出すことは困難です。また書き出せば書き出すだけ、「それ以外のことは考慮しなくて良い」ということになっていきます。実現する内容を細かく定義すると言うことは、同時に実現しなくてもよい内容を定義することになります。

子供に「部屋を掃除しなさい」と全体的かつ曖昧に言うのと「机の上と、本棚と、ベッドの上を掃除しなさい」と具体的に言うのと、どちらがよいか、、、それは微妙なところがあると思います。

「要件定義を精緻に作る」という方向性にはもう一つ大きな問題が存在します。

それは「保証できない要件は、リスクを見て見積りが高くなりがち」ということです。

たとえば先に挙げた「画面は4秒以内に表示されること」という内容を要件定義に織り込んだ場合、開発会社としてはそういう要件は「将来的にリスクになる」と判断し、高めの見積りを出してきます。

さらに何かちょっとした仕様変更(たとえばこの画面にこういう情報も出せますか?等)を依頼した際にも「(表示スピードに影響が出るかも知れないので)出来ません」という回答になってしまいがちです。

要件定義を精緻に作るというのは、リスクを開発会社に押しつける効果がありますが、見積りはその分高くなってしまいますし、融通も効かなくなり、プロジェクトにあまりよい効果を生み出さないと私は思います。

しかしながら第一話でお話ししたように、オーソドックスなシンプルなシステムであり、技術的にもロジック的にも不確実性がない内容であれば、その方向性は大いにありです。要件定義をキチッと作り、見積りを取り、納品してもらうことがもっともコストが安く、確実です。

そのような開発方法をウォーターフォール型開発と呼び、昨今業界では批判の的になることが多いですが、私は一概にその開発手法を前近代的で不合理な開発手法だとは思いません。
(続く)

他のシステム開発の基礎知識 の記事も読む

システムの価格はどう決まるのか?(2/2)

システムの価格はどう決まるのか?(1/2)

「なぜ使えないシステムが納品されるのか?」(その3)

「なぜ使えないシステムが納品されるのか?」(その1)