Microsoft Accessでシステム開発

システム開発に関するコラム集です。

28．要件定義とは？

あまり聞きなれない言葉と思いますが、システム開発では、最も重要なプロセスです。
この要件定義をおろそかにするとシステム開発プロジェクトは失敗します。

システム制作失敗とは

ひとからげに失敗と抽象的な言葉でまとめてはいけません。
システム開発での失敗とは、システムを作ってもらいたい人が思っている様なシステムが納品されなかった事を指します。もっとハッキリ書くと、全く業務を管理できない、つまり、使い物にならない物が出来てしまうという事です。
当然ですが、制作してもらった側は、使い物にならないからお金は払いたくありません。また、制作した側は、言われた通りに作ったのだからお金を払ってもらいたいはずです。いわゆるトラブルですね。

これは、要件定義とその後のプロセスである設計でシステム化の要求や設計に関して入念に打ち合わせが行われていないために発生します。
システムを作ってもらいたい人の思っている事が十分に伝わっていないため発生します。

失敗の原因

この場合、システムを作ってもらいたい人とシステム制作する人とどちらに否があるのでしょう。一概にどちらとも言えない事が多いようです。

システムを制作する側の人に否がある場合は、要件定義、設計の段階で

• ヒアリングする能力がない。
• ヒアリングした内容をまとめる力がない。
• 勝手な想像で要望を決めてしまっている。
• ヒアリングを省略してしまう。

システムを制作してもらいたい人に否がある場合は、

• 要望が会社内で十分にまとめられていない。
• ヒアリングで内容が十分に伝えられない。ヒアリングを省略してしまう。
• ヒアリングを面倒くさがる。
• 担当者の勝手な独断で要望を伝えてしまった。

システム担当者専任

例えば、コンピュータの事を少し知っているからシステム担当にされた様な人にありがちなのが、コンピュータの事を少し知っているため別の部署から連れてこられてシステム担当にされたが、システム化したい業務を全然知らなかったり、
システム担当者になりたくないのに無理に任命させられたためシステム化業務を積極的に推進できず要件が正しく伝わらなかったり、
コンピュータを知らなくても業務や何を管理したいのか等を提示できる人を担当者にすると良いでしょう。
また、システム担当としては、コンピュータを少しばかり知っている程度では何の役にも立ちません。我々からしてみるとコンピュータを知らない人とさほど違いはありません。

また、入力作業が発生したり、システムで管理しやすくするために一部の業務プロセスを変更したり、ルールを変えたり、例外的な業務の処理方法をどうするか等の決断や指導が必要になってきます。
それなりの決定権と指示が出来る方が担当となるとプロジェクトの進行が非常に早くなります。

システムを作るのは依頼者

時々、システム制作者に向かって「システムを作るのは、そっちでしょ。そっちで勝手にやって」と言って要件を伝えて頂けない方や、 「御社を信じているから」と言って要件をほとんど伝えずにシステム制作を進めさようとする方もいますが、これは、まず失敗する可能性が高いです。
コンピュータやシステムの事は知っていても、依頼される方の業務は全く知りません。また、信じてもらっても、制作者は要件は分りません。
システム開発は、懸けではありませんので、要件をしっかり伝えないと思った通りのシステムは出来あがってきません。

どんなシステムを作りたいのか、業務はどうなっているのかを知っているのは、依頼される方の方です。システム制作依頼を受ける側は、何を作りたいのかは、全く知りません。
オーダーメイドのスーツを作るのに、どんなデザインにしたいか、どんなボタンにしたいか、丈の長さはどのくらいかを知らなければスーツは完成しないのと同様です。
制作会社は、あくまでも依頼者の代わりにシステムを作る事をするだけです。

要件定義書

そもそも要件定義とは何でしょう。
要件定義の時にまとめられる要件定義書とは、システム開発を依頼されてくる方からヒアリングした「何をしたいか」をまとめた書類です。
実は、この要件定義書は、たった一文あるだけで要件定義書になってしまいます。
例えば、

「製造工程を業務化したい。」

時々、この様な要件定義書を書くシステム開発会社が存在しますが、たった、これだけ書かれていても、れっきとした要件定義書となってしまいます。ちょっとビックリしますよね。
実際、この場合は、この後の設計工程でお客さんの要望を組み込んでいく様になるので心配は無いはずです。
しかし、システム開発プロセス上では、設計書は、要件定義書を基にして作るため、これだけの文章では設計は行えません。
そして、要件定義書は、ヒアリング時の要望の伝え忘れ、及び、伝えた内容をシステム制作者に正しく理解されているか、間違えた把握をしていないかを確認するための議事録的な役割もします。
一般的には、要件定義書は、設計工程に入る前にシステム制作依頼者へ提出されます。
この要件定義書をよく読んで確認する事もシステム開発失敗を回避するためのひとつの手段として覚えておきましょう。

最も失敗する依頼

システム化するだけを目標としてシステム制作を依頼してくる会社様がいますが、これが一番失敗しやすいと言えます。
まず目標が「業務のシステム化」と抽象的な依頼なので、何を見たいのか、何を管理したいのかが不明確です。そのため要件定義でも、ハッキリとどうしたいという内容が出てこず。ヒアリング時も抽象的な要望が出てきて、釈然としないまま進んでしまいます。

システム化とは、業務上で不便なところ、労力や工数がかかるところをシステム化する事により業務が自動化され、作業が容易になること、もしくは、工数削減することで、その意味が発生します。
負となっている部分をプラスへ転換させるのがシステム化の意義です。

しかし、特に不便を感じてもいない業務を、時代の流れだからと言ってシステム化すると入力作業が増えるだけで何も有益なものへは発展しません。
この場合、ゼロとなっている部分を入力作業が増える事によって逆に負となってしまっています。
これは、システム化失敗と言えます。

成功させるには

システム化するしないにかかわらず、社内で、不便と感じている個所、労力がかかりすぎている個所をよく話し合い洗い出します。そして、その業務の工数を軽減する方法を検討して下さい。 その業務の負荷が軽減できる要因として「システム化」が含まれているのであれば、そこで初めてシステム化する事を検討して下さい。

システム制作を依頼したならば積極的にシステム制作会社と打ち合わせの機会を持って会社の要望を十分に伝える事が重要です。
システム制作会社は、業務軽減のためのシステムを検討、制作してくれる事でしょう。

全業務のシステム化を検討されていたとしても、まず、この手法で一部の業務のシステム化を依頼されても良いと思います。 システム化でどの様な効果があるのかを理解してから全業務をシステム化するかしないかを検討されても遅くは無いと思います。