要件定義書の作り方 - 要件定義の進め方

要件定義書の書き方がわからない、要件定義って何やればいいの？という方もいると思うので、発注側としての要件定義書の作り方をまとめておく。

要件定義書に書くべき内容の図による表現
手順①：[作業]あるべき姿の確認
手順②：[作業]現状の把握
手順③：[作業]問題(あるべき姿と現状の乖離)の中から、問題点を特定する
手順④：[会議]あるべき姿と現状と問題点の認識に関する合意をとる
手順⑤：[作業]問題点をどこまで解決するかの目標を決める
手順⑥：[作業]問題点の真因を分析する
手順⑦：[会議]目標と真因分析結果に関する合意をとる
手順⑧：[作業]真因に対する対策を検討する
手順⑨：[作業]対策の中から、システム化対象のものを明確化し、要件化しておく
手順⑩：[会議]対策、システム化対象課題、要件に関する合意をとる
手順⑫：[会議]要件定義書の内容に関して合意をとる
手順⑬：[作業]要件定義書に承認印をもらう
成果物：出来上がった要件定義書の目次のイメージ
結論：プロセスを決めて進めれば、要件定義書は勝手に出来上がる

要件定義書に書くべき内容の図による表現

下記の図は、要件定義書に書くべき内容を図で示したものだ。要件に関することが右隅にちょっとだけ書かれていて、そのほかはシステムに関係ないことを記載していることに注目してほしい。この点は非常に重要だ。顧客にとってシステム化というのは、特定の問題に対する対策の一つにすぎない。通常の問題解決プロセスにおいて、対策が間違っていそうなら、さっさとやめてしまうであろう。同じようにして、システム化という対策が意味なさそうなら、さっとやめたり、対策内容を変更しようという動きが起こる。システム屋からしたら「いきなりそんなこと言われても・・・」となるが、やむをえないことなのだ。だからこそ、対策を検討するまでの過程をしっかり要件定義書に書いておき、みんながその妥当性を把握できるようにしておくことが重要なのだ。要件を定義するために実施することはかなり面倒で、問題の明確化から初めて、真因を分析して、対策の検討というステップを踏んでいく必要がある。今回は、その手順を説明していく。

f:id:req-definer:20220123155654j:plain — 要件定義書に書くべき内容

要件定義書を作成していくうえでの大まかな手順は下記となる。　

手順①：[作業]あるべき姿の確認
手順②：[作業]現状の把握
手順③：[作業]問題(あるべき姿と現状の乖離)の中から、問題点を特定する
手順④：[会議]あるべき姿と現状と問題点の認識に関する合意をとる
手順⑤：[作業]問題点をどこまで解決するかの目標を決める
手順⑥：[作業]問題点の真因を分析する
手順⑦：[会議]真因分析結果に関する合意をとる
手順⑧：[作業]真因に対する対策を検討する
手順⑨：[作業]対策の中から、システム化対象のものを明確化する
手順⑩：[会議]システム化対象課題に関する合意をとる
手順⑪：[作業]要件定義書を作成する
手順⑫：[会議]要件定義書の内容に関して合意をとる
手順⑬：[作業]要件定義書に承認印をもら

以下、順番に説明する。

手順①：[作業]あるべき姿の確認

まずは、対象業務におけるあるべき姿の確認を行う。通常は、業務の担当にヒアリングを行えば出てくるが、出てこない場合もある。自分たちはどんな状態になっていけないといけないのか？という問いに対する回答はだいぶ抽象的な表現になるものだ。「効率的に〇〇ができている」といったような表現だ。対象業務の捉え方の大きさ次第で、あるべき姿は変わる。会社レベルだと「人々の暮らしの豊かさ向上に貢献できている」などの表現になるが、特定の業務の場合は「〇〇という業務が効率的(指標は〇〇)に行えている」などの表現となる。システム化の検討を始めた段階で、ある程度対象業務が明確化できているはずなので、あるべき姿に関しては後者のような表現となる。注意が必要なのは、担当が思うあるべき姿と、担当の後ろにいる人たちが思うあるべき姿が異なる場合だ。この場合、終盤になってシステムへの要件がひっくり変える可能性がある。そうならないよう、会社としてコンセンサスをとりながら進める必要がある。

手順②：[作業]現状の把握

次に、対象業務における現状の把握を行う。通常、システムを導入する目的は、人手による作業を機械に置き換えることである。そのため、人手による作業の現状を実際の担当からヒアリングをしていくこととなる。

この作業は一筋縄ではいかない。システム化の目的が、面倒くさい作業を効率化するような類であればよいが、そもそも当人の仕事をなくすような類の場合は、担当者は抵抗勢力になりうる。効率化の宿命ではあるが、効率化をすると人は不要になる。経営者はうれしいが、給料をもらっている従業員はうれしくない。そんな状態で、いきなりよくわからないやつに現状を説明しろと言われても、面倒くさいなと思うだけである。

そういうわけで、仮に抵抗勢力に対して現状把握を行う場合、「丁寧な背景説明」と「仲間意識の醸成(こっちも仕事でやむを得ずやっていることを理解いただく)」を意識するとよい。

手順③：[作業]問題(あるべき姿と現状の乖離)の中から、問題点を特定する

あるべき姿と現状のギャップを明確化したらば、次は、問題点(問題の中でも重要なもの)を特定する。問題を全部解決する必要はない。問題を全部解決しようとすると、やるべきことは肥大化する。問題の中にはしょうもない問題もいっぱいあるので、しょうもない問題は無視しよう。このフェーズで大事なことは、ギャップを発生させている事象の中で最も致命的な事象を探し出すことである。

このあたりの、問題とは何かについては、以下の記事も参照されるとよい。

req-definer.com

手順④：[会議]あるべき姿と現状と問題点の認識に関する合意をとる

苦労して情報を集めたら、今度は、関係者を集め、社内でシステム導入の提案[仮提案]をする。提案の承認者は、たいてい決裁権を持っている者である。決裁者が首を縦にふれば、次のフェーズに進んでよい。この会議の目的は、あるべき姿、現状の認識、問題点の認識に相違がないことを確認することだ。これらを説明し、「ここは問題点だよね」となった場合は、次のフェーズに進んでよい。ここで、「あるべき姿はこうだし、別に問題じゃないのでは？」となった場合は、仕事は終了だ。システムを開発する必要はない。

参考として、会議でやるべきことを整理した記事を張り付けておく。

req-definer.com

手順⑤：[作業]問題点をどこまで解決するかの目標を決める

問題点の特定がすんだら、その問題点をどこまで解決するのかの目標を設定する。ここの目標は、定量的な表現となる。システム化を意識した問題解決ならば、「コスト削減」に関する言及は必要であろう。

手順⑥：[作業]問題点の真因を分析する

問題点の特定がすんだら、問題点を問題点たらしめている要因を分析する。いろいろな切り口で検討することが必要だ。このあたりの作業においては、別の専門書に任せることとする。

真因の分析は、やり直しとなることがよくある。原因は「深堀の甘さ」だ。深堀が甘いと対策が場当たり的になってしまい、対策の効果はでない。対策が有効に作用するために、よく考えないといけないのだ。難しいのは、どこまで掘れば正解か？という基準が不明確な点である。システム導入意思決定者が納得するまで掘るしかない(から、コンサルという職種は激務だったりする)。

手順⑦：[会議]目標と真因分析結果に関する合意をとる

真因分析を行い、真因(複数あったりする)を特定したら、関係者間で再び合意をとる。

一回でOKをもらおうと思わないことだ。そんなすぐに問題の真因がわかるなら、そもそも問題は表面化していないし、誰かが問題に気付いてさっさと解決しているはずだ。

手順⑧：[作業]真因に対する対策を検討する

真因分析結果についてOKをもらったら、次は対策の検討だ。真因をどうやって解決するのかを考えていく。

このフェーズで大事なことは、なるべく多くの対策案を出すことである。実現手段はいろいろある。いろいろある中で、メリットデメリットを比較して、この案でいく、というように決めるのである。システム化ありきで検討を進めてしまうと、いらないものも作ってしまうので、システム化を意識せずに、あくまでも手段の一つとして検討をしよう

手順⑨：[作業]対策の中から、システム化対象のものを明確化し、要件化しておく

真因毎の対策を決めたら、改めて、どの対策がシステム化対象なのかを明確にしよう。その際に、システム化する根拠(例：具体的な嬉しさ)を記載しておこう。この作業を行うことで、要件に優先度をつけることができる。

システム化対象を明確化したら、下記のように要件化しておこう。システムを使うのは人なのだから、人が使うことを意識して記載することが大事だ。

○○業務について、○○が、○○のときに、○○できること
○○業務について、○○が、○○のときに、○○できること

システムを使う人とシステムとの関係性については、以下記事を参照するとイメージが掴めると思う。参考に記事を張り付けておく。

req-definer.com

手順⑩：[会議]対策、システム化対象課題、要件に関する合意をとる

ここまでの作業が終わったら、対策、システム化対象課題、要件に関する合意をとる。おそらくこの段階で「いくらぐらい？」と言われるであろうが「要件定義書作成後、お見積りしてから」と答えておけばよい。

この段階で、スコープ(システム化対象)という概念が出てくる。スコープと言うのは極めて重要な概念で、ぜひ理解しておいていただきたい。下記記事を参考に張り付けておく。

req-definer.com

手順⑪：[作業]要件定義書を作成する

システム化対象課題に関する合意がとれたら、要件定義書を作成する。やることは単純だ。これまで進めてきたことをまとめるだけだ。

手順⑫：[会議]要件定義書の内容に関して合意をとる

要件定義書の内容に関して合意をとろう。これは、会議の方が好ましい。取説を読まない人がいるように、要件定義書を読まない人はたくさんいる。要件定義書は公式なドキュメントとして発行されるものであるので、「うちは聞いてない」となるとややこしくなる。目次レベルで概要を説明し、要件定義書を発行する旨を関係者に伝え、合意をとろう。