要件定義の成果物は何か？という問いに「要件定義書です」と答える人は危険です。
社会人としてSEの端くれになった頃いつか要件定義をやりたい、やれるようになりたいと思っていたことを懐かしく思います。大学卒業後に入ったシステム開発会社でプログラミングや設計をやった後、実際に要件定義に携わっていくのですが、しばらく要件とは何かという明確な答えがないままにやっていたと思います。
要件定義は難しく、決めるべきことを決められない、あるいは細かいことまで決めようとして時間切れになることも多いです。
要件とは何か、要件定義の成果物は何か、を明確に答えられるかはとても重要で、ここが曖昧なまま要件定義に着手すると、その後の工程で手戻りが発生する可能性が高まってしまいます。
今回は、要件定義についてお話します。

こんな要件は嫌だ

要件定義でよく起こる問題が、実現困難な要件や検討に値しないことまで要件としてしまうことです。現行システムより操作方法が劣るとか見た目がいまいちとかユーザーが言い出すことがありますが、この発言の大部分は慣れが解決してくれます。
数時間見ただけの新しいものに慣れていないのは当然で、慣れてしまったら多少の不満があっても使いこなせるようになるのはスマホでも車でもパソコンでも同じです。
また、ひとりのユーザーが言っていることがシステムを使う全員が求めることではないかもしれません。全国の営業所や工場など順次導入するシステムでは、最初の拠点で言われたことと次の展開先のユーザーに言われることが全く真逆の場合もあります。
単に「こうして欲しい」をそのまま受け入れるのではなく、「なぜ、こうして欲しいのか」という”なぜ”の部分を明確にして要件とすることが大切です。

①ガラケーでLINE

②左ハンドル車のウィンカー

③左利き用の自動改札

④赤は嫌い、黒が好き

要件定義の種類と成果物

システム開発の工程の中で最重要と言っても過言ではない要件定義。言葉の通り要件を定義することであり、その後のシステム開発を行う上での前提になることを決める重要な工程です。
この重要性を誰もが理解しているにもかかわらず、要件ということ自体が曖昧になりやすく、粒度が粗すぎたり細かすぎたり、漏れが発生して設計や開発工程になって要件が十分に定義されていないと発覚することもよくあります。
一般的な理解として要件定義の成果物は「要件定義書」だとは思いますが、この要件定義書に書かれるコンテンツが何で、その具体的な何を要件とするかを明確に理解していなければ漏れなく定義することは難しいです。
システム開発の要件定義には2種類あります。厳密には作るシステムにもよりますが、業務システムの場合には、業務要件定義とシステム化要件定義を区別することで、何を定義すべきかが分かりやすくなります。

・業務要件定義
その名の通り、業務要件を決めることなので、この工程の成果物で代表的なものは業務フローです。経験がないと、いきなり業務フローを作ろうとしてしまいがちですが、その前に業務一覧を決めることの方が大切です。
業務要件定義のスコープとも言え、どの部署までを対象とするか、どの役職の仕事まで含めるか、緊急時のレアケース、月次や年次など管理業務を対象とするかなど業務の種類を洗い出し、各業務のスタートポイントとエンドポイントを決めて、業務フローの作成対象となる業務一覧を最初に作ることが重要です。
この業務一覧の各業務に対して新業務フローを作っていきます。新業務フローの各ステップで何をやりたいかを要件として抽出し、その要件を一覧化したものが業務要件一覧となります。
したがって「業務一覧」「新業務フロー」「業務要件一覧」の3つがここでの成果物となります。
要件を実現する手段には、システム化だけではなく、業務プロセスの変更やルール改定も含まれるため、この業務要件一覧の一部がシステム化の要件となります。
なお現行業務フローがない場合には、まず現行業務を整理して、その後に新業務フローを作成していく流れを取ることもあります。

・システム化要件定義
業務要件定義で作成した業務要件一覧の中でシステムを活用して実現するものがシステム化要件であり、その実現方法を定義することがシステム化要件定義です。
実現方法と言っても、画面イメージやワイヤーフレームを定義する場合もあれば、画面の主要項目まで決めたりとプロジェクトによって様々です。主要項目とは何かとクライアントに問われ、答えに困るのも、あるあるのやり取りのように思います。
システム化要件定義の成果物に、画面遷移図を含めたり含めなかったり、論理ER図があったりなかったり、パッケージソフトを使う前提の場合にはFit＆Gapを含めることもあるかと思いますが、システム化要件定義の目的は、簡単に言ってしまえば基本設計以降の見積り諸元を確定させることです。そのためには、事前に見積り手法と見積るために必要な諸元情報が何かを理解していないといけません。
機能の本数で単純に見積りをするのであれば、機能一覧だけあれば良いですし、各機能の難易度を付けて見積もるのであれば、CRUDや場合分けのケース数など難易度を決める条件も定義する必要があります。
つまりは基本設計以降の見積りでインプットとなる諸元情報がシステム化要件定義のアウトプットであり成果物になります。逆に言うと見積り手法が決まっていなければ、システム化要件定義の成果物を決めることは出来ません。

業務と機能の紐づけの重要性

設計や開発、ひどいと総合テストにまでなっても「この機能は誰が使うの？」「どんな目的で使うの？」という会話は、システム開発で度々登場します。
業務要件定義で業務を決めて、システム化要件定義で機能を決めますが、機能がどの業務の誰にとって効果のあるものかは、後々の工程でことごとく重要です。総合テストで障害が検知されて、その障害対応に時間も工数もかかる場合には、業務への影響度合いによって対応方法と優先度がきまります。クリティカルでなければワークアラウンドで凌ぐことも検討すべきですが、機能と業務要件との紐づけが出来ていないと業務影響がわからず困ります。
業務要件定義で要件を抽出する時には、先の工程で利用することを考えて、この要件が誰にとってどれくらいの効果があるかも定義しておくことが重要です。

実際の画面を見せることの良し悪し

ショッピングサイトなどコンシューマ向けシステムでは業務という概念がないため、業務要件定義をせずにシステム化要件定義からはじめることもあります。誰が何をしたいかの明確な要件がないため、実機に近い姿でUIを見せつつ機能要件を抽出していく進め方です。業務システムでもパッケージ製品を導入することが前提の場合には、要件定義の前後でパイロットやCRP、モックアップなどと言って実際のシステム画面を見せていくアプローチをとることがあります。
この実機を見せるアプローチは、目的を明確にしないと無用な要件を拾い集めることになり危険です。
業務要件への適合性を評価するのであれば、業務要件定義とシステム化要件定義の間にソリューション選定を目的として行うべきです。
特定のパッケージを導入する前提でシステム化要件定義を行うのであれば、製品の変更は何があっても受け入れられないことをユーザーと合意したうえで進めないと、見た目や操作方法なども含め製品そのものの不満が噴出して推進が停滞しかねません。
早めに慣れてもらうため、抵抗感を早めに洗い出すためという中途半端な優しさなら、実機を見せずに開発を進めて、後戻りは出来ない状況となるユーザー受入テストではじめて実機に触れてもらう方が潔く覚悟を決められて良いのかもしれません。
プロジェクトの経緯や状況によって、どのタイミングでどういう目的で実機を見せるかは考えるべきだと思います。

まとめ

「システム理解の無い人が要件定義をやるのは良いのか」という事がよく議論されます。
システムありきではなく新業務を作りたいのであれば、システム理解のない人の方が良いと思います。システム理解があると、その人の開発知識や技術力に引っ張られて大した変化のない業務になってしまう可能性があるからです。
一方でシステム導入ありきの要件定義では、システム理解のある人の方が良いと思います。特にERPなどパッケージを使う場合には、そもそもできないこともあるのです。
パッケージ製品の導入は、車の購入と同じで、標準装備があって、それにオプションを付けるか、それでも気に入らなければ外注品、外注品もなければ特注で作ってもらわないといけません。この理解がない中で要件定義を行ってしまえば、もはや原型の車種がわからない車を作り上げることになります。

要件定義は難しいものだとは思います。プロジェクトによって背景や前提が異なるため正解を言い切ることは出来ませんが、できるだけシンプルな考え方で解説したつもりです。実際も、一つひとつの要件に対して、やるかやらないか、いるかいらないか、常に2択を追求するくらいの考えで挑んだ方が良いと思っています。

効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！