システム開発における要件定義の重要性

【本記事でわかること（読み終えるまでの時間：約5分）】
システム開発契約において最重要の工程ともいえるのが「要件定義」の工程です。要件定義がなぜ重要なのか、要件定義の工程ではどのようなことに気を付けるべきなのか、要件定義をルーズに行うとどのようなトラブルが発生するのかを解説します。

1.　要件定義とは

システム開発契約において、そのシステムに必要な機能などを決定することを要件定義といいます。

要件の中には、具体的には機能要件と非機能要件という二つの要件が含まれています。

機能要件というのは、ユーザーが開発予定のシステムが達成したい目的のために、そのシステムはどのように動く必要があるのか、という動作に関する要件を指します。

非機能要件というのは、システムの処理スピードやセキュリティ対策などの機能要件以外の要件を指します。

システム開発を行う際には、具体的なシステム開発のプログラミング作業に入る前に要件定義を十分に行う必要があります。

というのも、要件定義が不十分な場合、実際に開発工程に入ってから追加の機能が必要であることが判明し開発工数が増加したり、そもそも開発の全体設計から見直す必要が発生してしまう可能性があるからです。

システム開発に関する紛争でよくあるのが

「ユーザーとベンダーが認識しているアウトプットがズレている」ケースです。

これは、開発に入るまでにユーザーとベンダーとの間での認識合わせが十分に出来ないことが原因です。

それが正に要件定義が不十分であったことを示しています。

では、具体的に要件定義は誰が主導して行うべきものなのでしょうか。

2.　要件定義をリードするのは誰？

トラブルの原因にもなる要件定義は誰がリードして行うべきものなのでしょうか。

答えはユーザーです。

ユーザーからすると「なんでシステムの専門家ではないユーザーが要件定義をリードする必要があるの？」と思われるかもしれません。

でもよく考えてみましょう。

開発するシステムを最終的にビジネスに使うのは誰でしょうか。

ユーザーですよね。

最終的な利用者であるユーザーがシステムがどのように機能する必要があるかについて一番詳しいのはある意味当然なことです。

もちろん、ユーザーにはシステム開発を内製化するリソース的な余裕がないから外注しているわけなので、テクニカルな部分やユーザーでは見落としがちな視点についてはベンダーからの積極的なサポートが期待されています。

そのため、ユーザーは、開発予定のシステムをビジネスの現場でどのように活用したいのか、そのためにはどのような機能が実装されている必要があるのか、出来る限り情報を開示する必要があります。

優秀なベンダーであれば、ユーザーの情報開示が不足している部分について事前に指摘をしてくれることもあります。ただ、これはあくまでもベンダーが優秀な場合に限った話なので、そういったベンダーを選定できている「ラッキー」なケースだけにあてはまります。

ベンダーから積極的に必要な提案を受けれると淡い期待はせずに主体的に動く気持ちでシステム開発を発注することがトラブル回避のためには重要になります。

3.　要件定義工程の契約

要件定義の重要性はご理解いただけたと思います。

では、その要件定義の工程を行う際の契約はどのようなものにすればよいのでしょうか。

契約としては準委任契約を締結するのが望ましいと考えられています。

準委任契約では、ベンダーは善良なる管理者の注意をもって業務を遂行する必要があります。いわゆる善管注意義務と呼ばれるものです。

善管注意義務の内容は画一的に定まっているものではなく、業務の性質毎によって異なるものです。

前述のとおり、要件定義はユーザーがリードしつつ、ベンダーがサポートを行う形で行う協働作業になります。そのため、一定の仕事の完成が求められる請負契約とは相性がやや悪いものといえます。

もちろん画一的な答えがあるものではないため、案件毎に契約性質を適切に協議していく必要があります。

また、そもそも要件定義段階で費用が発生するか否かについても明確に合意するようにしましょう。

ユーザーからすれば「具体的なアウトプットが出ていない中で費用は発生しないのが当然」と考えているケースもある一方で、ベンダーとしては「要件定義の検討自体に専門的な知識を元に対応しており費用が発生するのは当然」と考えているケースもあるためです。

4.　要件定義書の作成

要件定義の工程の目標は、システムの要件定義を完成させることです。

要は、開発工程に入るために必要な情報の整理が完了する必要があります。

具体的には、以下のような項目を要件定義書として整理すると良いでしょう。

・新規システムの開発が必要な背景（現行システムの不存在・問題点）
・新規システムにより改善される業務
・新規システムが備えるべき機能一覧
・UI（ユーザーインターフェース）のイメージ（各機能やボタン等の配置イメージや色のイメージなど）

なお、開発工程の中で微修正していくことが想定されている部分（特にデザイン部分）については、確定している部分と未確定部分を併記しておくことが望ましいです。仮に、A案とB案の二つで未確定の場合には、両方の案を記載し、開発段階で両方をテスト開発してみるのも一つの手です。そのような場合には、ベンダー側の工数が増えることになるため、当初の開発費用内で対応可能なのか、別途費用が必要が発生する場合には固定金額なのかエンジニアの人月ベースの変動金額なのか等の協議を忘れないように気を付けましょう。

システム開発契約に関する契約書の作成に関するご相談をされたい方はこちらからお問い合わせください。