要件定義って言われても、何を決めればいいのか良く分からない。どんなドキュメントを用意するのが正解なの？
要件定義は超大事。システム開発に関わったことのある人なら、耳にタコができるくらい聞く言葉です。
しかし、要件定義って本当のところは何をすれば良いのでしょう？
どういう資料を用意すればクライアントに喜ばれ、システム開発がスムーズに進められるのでしょうか。
今回は要件定義で失敗しないために、絶対に作るべき資料をご紹介いたします。
要件定義は、クライアントの「要求」を「システム要件」に変換する作業
要件定義とは、「これから作るシステムの要件を洗い出し、クライアントと合意を取るためのフェーズ」です。
クライアントは「自分たちがやりたいこと」しか話してくれません。
例えば、次のような感じです。
会員向けのサポートサイトを作りたいんだよね。よくある質問コーナーとか、お問い合わせの受付とか、そんな感じで作ってくれないかなぁ。
この「～したい」という要求を「こうすればできる」という、システムで実現可能な形に落とし込むのです。
この例で言えば、会員向けサイトには次の要件が必要になりそうですね。
- ログイン/ログアウト
- アカウント発行機能
- 管理者用画面と会員用画面は別にする
さて、こうやって考えていくとクライアントの要求にはあいまいな点があることに気づきます。
- 管理者向けに必要な機能はなんでしょうか？
- 会員用画面は一種類で良いのでしょうか？
- 実は会員にはグレードがあって、受けられるサービスを変えたいということはないでしょうか？
このように要件定義では、要件を作る→あいまいなところをつぶす→という作業を繰り返します。
実際に議論を重ねていくと、クライアント自身イメージできてなかったことや、検討不足だった点が明らかになってきます。
その結果、方針がブレまくって、クライアントも本当は何をやりたいのか分からなくなってしまうことがあるのです。
要件定義は、システムの方向性を決定づける非常に大切なフェーズですが、その分迷いやすく間違えやすい作業です。
そうならないよう、クライアントの目的をしっかり見据えてシステム化の舵取りをうまく進めていく必要があるでしょう。
要件定義で絶対につくるべきドキュメント
要件定義を成功させるためには、次のドキュメントを用意しましょう。
これらをまとめて、「要件定義書」とひとくくりにすることもあります。
- 業務要件
- 業務フロー
- 画面イメージ
- 要件リスト
業務要件
業務要件とは、システム化対象のクライアントの業務内容をまとめたものです。
例えば、次のような内容を記載します。
- なぜシステム化が必要なのか？
- システム化によって何を実現したいのか？
- ビジネスモデル、ビジネス上のゴール（目標）
- 利用規模（利用者数やデバイスの台数など）
- 業務時間（システムを使う時間帯）
一見、仕様に結びつかないような内容ばかりですが、要するに「これからこういうことを実現するために、こういう前提でシステム化していきますよ」という宣言です。
明文化することでお互いの認識が間違いがないか確認し、さらには道に迷った時の道標にするのです。
例えば、クライアントが「24時間、絶対にシステムを止めたくない」と言い出したとして、業務時間が9:00-17:00であることが分かっていれば、それはオーバースペックであるという指摘ができます。
業務フロー
業務フローとは、業務の流れを図式化したものです。
このシステムは、「いつ、誰が、どの機能を使うのか」を関係者で共有するために必要です。
システム導入後の全体像を把握することができるため、過不足なく要求を仕様化するのに役立ちます。
またクライアントに運用イメージを持ってもらい、運用の障害となる個所を発見したり検討してもらうためにも使います。
画面イメージ
画面イメージは、システムの操作画面を絵に描いたものです。
WebサイトやWebシステムの場合は「ワイヤーフレーム」と呼ばれます。
精巧な絵である必要はなく、「この画面にはこんなボタンや情報を表示しますよ」といった情報を共有するために使います。
Excelでも十分なものが作れますが、Adobe XDのような専用ツールを使う人もいます。
実際にその画面を使う人に見てもらい、運用イメージを膨らませてもらうとともに、使いにくい点や不足情報などの意見をもらいます。
ただシステムの場合、静止画だけではなかなかイメージが伝わらないケースもあります。
そんなときはモックアップが有効ですが、モックアップは制作に時間と工数がかかるのがネックです。
そこでオススメしたいのが、「ペーパープロトタイピング」という手法です。
静止画を何枚も用意し、「（紙上の）このボタンを押してみてください」「そうすると、この画面になります」みたいな感じで、クライアントの操作に応じて、紙芝居の要領で画面を差し替えていくのです。
ワイヤーフレームを作るのと同じくらいの手間で、簡単に複雑な動作を説明することができます。
ペーパープロトタイピングの勉強には、こちらの書籍がオススメです。
要件リスト
要件リストは、クライアントの要求をシステム要件に落としたものを明文化した資料です。
「要件定義書」というと、この要件リストだけをイメージする人もいます。
書き方は各社各様で、自社の色が一番出る部分だと思います。そして、一番仕様に直結し、品質を左右する要素でもあります。
機能要件と非機能要件を記述し、システムの全体像を定義します。
要件リストを作るコツは、「そのシステム要件が出てきた背景（クライアント要求）を一緒に記述すること」です。
こうすることで、その要件が本当に必要なものであるかが判断できます。背景がうまく書けない要件は、不要な要件か、ベクトルがズレているものである可能性が高いです。
そして、要求と要件を合わせて管理していける、USDMという便利な記法があります。
仕様変更にも強く、変更管理しやすい記法であるため、私は愛用しています。
USDMの勉強にはこちらをどうぞ。USDMの提唱者であるシステムクリエイツの清水さんが執筆された良著です。
※USDMでは、システム要件のことを「要求仕様」、要件リストは「要求仕様書」という呼び方をしています。
まとめ
要件定義は考えることが多くて大変ですが、基本は上述した４つのドキュメントだけあればOKです。
まずは、順番に一つずつ完成させることを意識してみてください。
一つずつクライアントと共有し内容を詰めていくことで、要件が徐々に出来上がっていくのが時間できると思います。
そして、慣れてきたら、さらに次のようなドキュメント作成にも挑戦してみると良いでしょう。
おすすめの書籍も合わせて載せておきますので、よろしければ挑戦してみてください。それでは！
ペルソナ
Webサイトなど、クライアントが不特定多数の場合にターゲットを明確にするために使います。
ユースケースシナリオ
新商品開発など、そもそもの使われ方が分からない場合、想定する運用シーンをイメージするために使います。
課題管理表
要件定義の障害となっている点を明確にし、解決策を検討するために使います。
※コンサル向けの本ですが、課題管理の基礎が学べます。