システム発注のキモ「要件定義」の重要性

システム開発は「要件定義」から始まります。

なんて言われても、システム屋じゃないと「要件定義」の意味もわからないし、何をすれば良いのかわかりませんよね。いきなり「要件定義を作れ」なんて言われても、何をどうすれば良いの？

要件定義はシステム発注のキモ。要件定義の出来次第でシステム導入が成功するかが決まってしまうと言っても過言ではありません。

システム導入担当者の仕事は「要件定義」をまとめることから始まります。

簡単に言うと要件定義書は「やりたいこと、実現したいこと」をまとめた文書です。要件定義がなければ、システム屋は何を作れば良いかが分からず、設計すらできません。つまりシステムの開発ができません。

僕はプログラマ、SEとして働いていた20年間で多くのシステムを開発、導入をしてきましたが、システム導入の成功率はよく言って３割程度、体感的には１割くらいです。ほとんどのプロジェクトは失敗に終わっています。その原因はシステム屋のスキル不足も否めませんが、失敗する原因の多くは要件定義にあります。

要件定義書はシステム屋からするとバイブルで、要件定義に書いてあることを理解してシステムを組んでいきます。しかし発注者側は要件定義の重要性が分かっていません。なので、曖昧な要件定義しか上がってきません。

システム屋は、それまでの経験や知識で「他の会社はこんなことをやってます」などのアドバイスはできますが、何をするかは決められません。システムで何をするかを決めるのは発注者、使う人です。そして、システムで何をするか、何がしたいかをまとめるのが要件定義です。

システム屋は、発注者のやりたいことを実現するためにプログラミングをしてシステムを組むのが仕事。要件定義からシステムの設計に落とし込み、プログラミングします。

この記事では「要件定義」の重要性を解説します。

要件定義には２種類ある

要件定義と簡単に言いますが、要件定義には２種類存在します。システム屋でも意識をしている人が少なく、２種類の要件定義に明確な名称はありません。ここでは分かりやすいように、発注者が用意しなければならない「業務要件定義」とシステム屋と一緒に作る「システム要件定義」と呼びます。

要件定義はシステムの「あるべき姿」を発注者とシステム屋で意識合わせをするために必要なものです。家を建てるときも同じですが、住む人（発注者）は「こんな家にしたい」と言う希望を伝えて、建築事務所（受注者）が設計図を書き、家を建てますよね。

「こんな家（システム）が欲しい」と言うのをまとめるのが要件定義です。

家だとリアルな建物なので、目で見て分かりますが、システムはプログラム（命令）とデータの集まりで何がどうなっているのかが分かりません。なので発注者側からすると途中経過や進捗が分かりにくい。なので「システムのあるべき姿」をお互いに共有することが必要になります。

その「システムのあるべき姿」をまとめるのが「業務要件定義」になります。システムに求めるものをまとめます。

業務要件定義は発注者が作る

業務要件定義書はシステム屋に任せてはいけません。システム屋はあくまでもシステムを作るのが仕事で、発注者や使う人がどうやって使うかは決められません。システム導入で失敗する原因は、システム屋に丸投げをしてしまうこと。業務は会社が変われば、手順が変わります。

「普通」の業務でも、会社が変わると手順が変わるんです。会社内での「当たり前」「普通」が、一般的には普通ではないなんてことは多々あります。仕事柄、色々な企業の業務をみていますが、似たような手順の企業はありますが、同じ手順の企業は、ひとつとしてありません。

業務手順、必要なデータは企業によって変わってきます。システム屋に丸投げすると「システム屋が使いやすいシステム」になってしまい、結果、使いにくいシステムが導入されることになってしまいます。入力するデータ、入力するタイミング、必要のない機能、必要なのにない機能など、ムダなシステム。システムを導入して合理化、効率化を目指しているのに余計に手間がかかるシステム。

システムを動かすために余計な手間が増えるなんて本末転倒ですよね。そうならないためには、発注者、使う人が「こんなシステムが欲しい」と伝える必要があります。

業務手順を見直す

システムを導入する場合に必要な「業務要件定義」はどうやって作れば良いのでしょうか。

業務要件定義は、システム導入後のあるべき姿をまとめたものです。そのためには現在、行っている業務の手順を洗い出すことが先決です。

システムを導入する目的は、合理化、効率化だと思います。現在の業務手順を洗い出し、どこをシステム化することで効率化が図れるかを考えることが一番の近道です。システム導入後にどんな業務になるかを決めるのは発注側です。

システム導入後のあるべき姿（To-Be）をまとめるのが「業務要件定義」です。と言っても、いきなりTo-Beをまとめることは難しい。なので、現在の業務手順（As-Is）を洗い出し、自社の弱点や今後の方向性を明らかにして、今後の業務を決めていきます。

システム要件定義は誰が作る？

本来は、システムの要件定義も発注側が作りますが、システムの知識がないと作れません。大手の企業であれば情報システム部門が対応できますが、情報システム専門の人材を確保できていない企業が多いのが現実です。

「システム要件は誰が作るか」と言う話ですが僕の経験上、発注するシステム屋と一緒に作るケース、ITコンサルタントと一緒に作るケースが一般的だと思います。

システム要件定義とは、セキュリティ対策はどうするか？ とか、ハード（サーバの容量とかスペック）をどうするかなど専門的な話をまとめることです。素人知識では到底まとまりません。非機能要件とも呼ばれるのですが、システムを動かすためのバックボーンの部分です。なので専門家に発注することで失敗する確率が低くなります。

ただ、システム要件定義を作る前には、業務要件定義がないと進みません。業務要件定義を作り、システム屋に見積を取る段階で、非機能要件定義（システム要件定義）について相談をするのが良いと思います。

システム開発は要件定義から

システム開発を行う場合、一番最初に行うのは要件定義です。要件定義とは「システム導入後の『あるべき姿（To-Be）』をまとめる作業」

システム導入で上手くいかない原因の多くは、要件定義をシステム屋に丸投げしていることです。システム屋が行える要件定義は「システム要件定義」で「業務要件定義」は発注側、使う人が行うべきです。

業務要件定義は、システム導入後にどんな手順で業務を行うかをまとめる作業です。

業務要件定義は情報システム担当者で決めると言うよりは、実際にシステムを使う部署を巻き込んで作る必要があります。システムを導入する目的や使用する手順、必要なデータはシステム担当者が決められることではありません。現在の業務手順、問題点、あるべき姿は、実際に作業を行っている人にしか分かりません。

そして、社内の担当者が分からないことは、外部のシステム屋はもっと分かりません。そのシステム屋に「丸投げ」なんて考えただけでも上手くいくはずありませんよね。