自社プロダクトや社内システムを作るためエンジニアへ作りたいサービス概要を伝える時に必要になるのが要件定義（開発したいサービスの機能などの概要をまとめたもの）を記した要件定義書と呼ばれるものです。本記事ではシステムをあまり理解していない方向けに要件定義の基礎から作り方のポイントをご紹介します。
要件定義とは
まず初めに要件定義についてご説明します。要件定義とはシステムをどう実現するかを開発者に伝えることです。といっても、分かりにくいと思いますので、簡単な例でお伝えするレシピのようなものです。
ハンバーグを作るには、
①どの調味料や食材を使うのか？
②その調味料や食材をいつ使うのか？
③調味料や食材をどうやって使うのか？
④完成イメージはどういうものなのか？
⑤どのくらいの時間で完成するのか？
⑥食材費は何円するのか？
ということを考えるかと思いますが、これをシステムに当てはめたというようなイメージでしょう。
例えば、顧客管理システムを作るには
①システムは誰が使うのか？
②システムはいつ使うのか？
③システムはどのような流れでどんな機能が必要なのか？
④完成イメージはどういうものなのか？
⑤どのくらいの時間が必要なのか？
⑥開発費はいくらするのか？
といった内容を開発者に伝えお互いのイメージや機能についてすり合わせ実現するためのプロセスを要件定義と言います。
要件定義の構成
では、より具体的に要件定義の構成はどのようなものにすればいいのでしょうか？
まず、構成を伝える前に要件定義作成の前提として、要件定義は一方的に開発者に自社の開発イメージを押し付けるのではなく、イメージしている機能は開発可能なのか？（システム的に再現できない機能などがありその場合は代替案で対処などをします）を開発者と共に話し合い、目的や想定イメージを実現するために共に開発を行うプロジェクトというイメージを持つといいと思います。
以上を踏まえた上で、どんな要件定義でも必要となる重要なポイントとなる構成を確認していきましょう。
概要
まず初めに記す必要があるのは概要です。
概要とは
・開発背景と目的（なぜこのシステムを作るのか？そしてその目的は何なのか）
・システムイメージ（どんなシステムを作りたいのか）
・リリース希望時期（いつ頃リリースしたいのか）
・希望言語（どの開発ツールを使って欲しいか）
※言語によって開発したサービスデザインや機能に差が出ることがあるため
など開発に当たっての基礎となる情報をまとめたものです。
この概要が要件定義で最も重要といっても過言ではないくらい大切なポイントです。
特に目的は明確にしておく必要があります。なぜならこの後出てきますが、選んだ開発ツールでは実現できないケースなどが多く発生すると思います。
というのも、特定のユーザーはこのボタンを押したらBのページへ移動。それ以外のユーザーはAへ移動。などができないということがあります。その時、目的がしっかりしていれば、別の手段が提案できたりするからです。そのため、開発の自由度と再現性をあげるために目的はしっかりと記入しましょう。
機能要件
システム要件とは開発したいシステムのイメージを具体的に伝えるための要件です。このシステム要件も初めてシステムを触る方からすると分かりにくいと思いますので簡単な例として「ガンプラ」作りに合わせてご紹介します。
ガンプラ作りでは
①ベースとなる機体を選ぶ
②どんな武器やガードなどのパーツが必要？
③色やパーツごとのデザインはどうする？
④自分用か人に見せる用なのか
などを基礎となる機体をどうアレンジしていくかを考えると思います。
この考え方とシステム要件は似ていて
①どんなサービスなのか
②必要な機能（決済機能や検索機能など）
③画面デザイン（何色にするのか、文字の大きさ）
④パソコンからログインできるものか、携帯からもできるものか（ターゲットユーザーの生活サイクルに合わせる必要があるため）
⑤どんな情報をユーザーからもらうのか（住所や年齢など）
など実際ユーザーが使う機能をベースに加えていくのがシステム要件という認識で相違はないと思います。
また、かっこいいデザインのガンプラを作るためにはガンダムに関する知識が必要なようにシステム要件も、全くの初心者が行わないことが大切です。腕がくっつかない！というミスがあるようにシステムにも、エラーが発生しますしデザインも見にくかったりすることがあります。
そのため、システム要件はエンジニアやプログラマーの意見を聞きながら作成することをお勧めします。
運用要件
運用要件では、開発したシステムをどのように管理し運営していくのかを伝えます。これにより、より運用側が利用しやすいデザインを実現することができます。こちらも初めての方には分かりにくいと思うので、お化け屋敷の運営を元にご紹介しようと思います。
あなたがお化け屋敷を運営することとなり、お化け屋敷の内装やお化けの衣装はすでに決まっています。しかし、これをどう運営していくか？はまだ決まっていません。そのため運営をどうするか？を考える必要があります。
①お化け屋敷の営業時間と開店と閉店のやり方
②お化けの配置やお客様の案内ペースはどうやって把握するか
③スタッフ入り口、お客様入り口などのセキュリティはどうするか
④全員の情報を管理できるリーダーは誰なのか？
などを決める必要があると思います。これと似ていて
運用要件の内容は
①起動と停止の方法（ボタンなどがあるのか）
②運用者がどう稼働状況やユーザー情報を管理するか（どんな手段で顧客情報を管理するのか）
③セキュリティについて（侵入者が入ってこれないようになっているか）
④マスターアカウントについて（全てのログイン、管理権限がある人はどうするのか）
を運営にあたって決める必要があります。
お化けが着替えているところにお客様が来てしまう！などのエラーがないようにお客様の進み具合や入場ペースを管理するのと同様に、サービスもお客様が快適人利用してもらうための運用の仕組みを決める必要があります。これが運用要件です。
ご紹介した3点はあくまでも、システム初心者が初めに理解するべき内容をまとめたものです。実際にはこの他にも構成に入れ込む必要がある情報がありますがまずはこの3点を理解することが重要でしょう。
最後に、要件定義のイメージを添付します。
こちらを参考に構成を考えてみてはいかがでしょうか。
参考：農林水産省 動物検疫支援システム オンライン連携機能構築 システム要件定義書
要件定義から開発までの流れ
では、要件定義はどのような流れで作成をしてくのでしょうか？
実は要件定義は会社を設立する。そのくらいの時間と工数がかかります。中途半端な気持ちで取り組んではいけないということ念頭において流れをご覧ください。
解決課題の確認
まず前提として、システムは課題を解決するために作成するケースがほとんどです。例えば、
◆社内システムの場合
・社内のメールを管理するコストが大きい
・出勤簿をオンライン化したい
・リモートでもコミュニケーションをとりやすい環境を作りたい
◆toCサービスの場合
・飲食店の混雑状況を可視化できるサービスがほしい
・使っていない車をシェアできるようにしたい
・民泊をオンライン化したい
などです。
この課題をどう解決するか？の手段がシステムなのです。
ユーザーヒアリング
解決するべき課題を明確した後行うのは、ユーザーのヒアリングです。
ヒアリングで解決するべきポイントは
・定義した課題は本当に課題になっているのか？またその度合い
・既存のサービスにどんな不満があるのか？
です。
自己満足なサービスにならないように課題の定義を確認する。そして、そんなシステムにすればユーザーが求める機能を実現できるのかを確認するためにユーザーヒアリングを行います。
要件定義と要件定義書の作成
では、解決するべき課題とどんなシステムにしてどんな機能を搭載すればいいのかが決まれば次に要検定義書を作成します。
これは先ほどご紹介した
・概要
・機能要件
・運用要件
を軸に記入していきます。この段階ではまだ要件定義を開発者に渡す必要はなく、社内のエンジニアや知り合いのシステム会社、エンジニアの方と相談しながら要件定義の内容をブラッシュアップしていくといいと思います。
要件定義書の共有
続いては、作成した要件定義書を開発者に渡す必要があります。
要件定義は使う言語や機能によって、実現できるエンジニアを選ぶことがあります。そのため、要件定義書は自身の想定するシステムを実現してくれるエンジニア探しの指標にもなります。
また、要件定義書を共有し代替案の提案や機能をこうした方がいいなどより実現するための前向きな議論のきっかけにもなります。
ここできちんと、自社の
・予算
・納期
・システム
を実現してくれるエンジニアを選びましょう。
開発の開始
最後はここで開発の開始となります。
いかがでしょうか？
要件定義と聞くと、とりあえず想定イメージを共有しエンジニアの方に作り込んでいってもらうと思いがちですが、市場調査からサービス作り、開発者探しとまるで起業するかのような業務を行う必要があります。
また、すでに伝わったかと思いますが、要件定義は起業でいう事業計画書のようなものでサービスの一存をになう非常に重要な書類です。要件定義の質＝システムの質となるのでいいサービスを作るために要検定義の質にはとことんこだわるようにしましょう。
システム初心者向け要件定義作成のポイント
では最後にシステム初心者向けに要件定義作成のポイントをご紹介します。
重要なポイントは2点です。それぞれご紹介します。
過剰に機能を詰め込みすぎない
これは、オーバースペックと呼ばれるもので、利用者はきっとこんな機能があったらさらに喜んでくれるだろうなという思いから機能をどんどん加えていくことで起こります。
その原因としては
・解決するべき課題が不鮮明でサービスありきの課題になっている
・顧客ではなく開発者が必要だと思う機能を選んでいる
・色んな人からアドバイスを聞きすぎて軸がブレている
などです。
特に、よくあるのは開発者が必要だと思う機能を入れていく事象です。これがあったらもっといいサービスになるというサービスの質を高めることばかりを気にしてしまい肝心の課題をどう解決するかが後回しになっていることがよくあります。
こうならないためには、しっかりと課題の定義を明確にし、課題の解決にフォーカスした設計を適宜確認する必要があります。できるだけシンプルに顧客視点でシステム開発を行うための要件定義を心がけましょう。
納期ありきの要件定義にしない
これは、社内システムを開発する際によくおこるケースです。いついつまでにこんなシステムを作って欲しいと社長から言われるなどがその例です。
納期ありきで要件定義を作成すると
・搭載できる機能の選択肢が狭くなりサービスの質が下がる
・開発者がなかなか見つからない
・エラー処理などに時間をさけずエラーやバグが多発する
ということが発生します。
大抵がタイトな納期での開発スケジュールのため開発者が見つからないことはもちろん、もし開発者が見つかったとしてもエラー確認などに時間を避けずバグが発生しまくるサービスになっているなんてことも…
これを防ぐためには、納期ありきではなくサービス内容から納期を逆算すること。
そして、それが不可能であればエラー処理にも時間を避ける機能に絞り込むことが重要となります。
まとめ
いかがでしたでしょうか。
要件定義は事業計画書と同じくらいシステム開発には重要であること。
これを理解するだけで取り組み方が変わりますしシステムのクオリティも変わると思います。ユーザーが喜んでくれるサービスを実現するためにぜひ本記事をご参考にしていただけると幸いです。
