本記事はどんな方に読んでほしいか
・システムエンジニアリングを学びたい方（特に全体をざっくり把握したい方）
・新規事業開発担当者でシステム開発を考えている方（例：ITサービスを作りたい方）
・ITスキルを増やしたい方（例：プログラマーや営業でスキルを増やしたい方）
読んで頂いたあとどんな状態になっていてほしくて書いているか
・要件定義が自分にとって学習するべきかどうかを判断できる
・サービスを作る上でマーケティングからシステム設計への流れが分かる
・要件定義工程で何をすべきか分かる（Howの部分は別記事へ）
本記事ではシステム開発における要件定義の役割と何をするのかについてご説明していきます。
要件定義の理解度クイズ｜みなさんは要件定義についてどのくらい知っていますか？
みなさん要件定義という言葉はご存じでしょうか？
この記事を見てくださっている方々は聞いたことがあるという方が多いのではないかと思いますが、具体的に説明しろと言われると結構言葉が出てこないと感じるのではないでしょうか。
例えばですが、以下のような問題を少し考えてみていただけませんか？
- Q. 要件定義とシステム設計の違い
- Q. システム開発の中に要件定義は入りますか
- Q. 要求定義、機能要件、要件定義の違いは何ですか？
確かに実際には定義が複数あるものも存在しますが、本記事では上記の内容にもお答えしていきます。
本記事の構成
構成は以下の5つの項目に分けてご説明していきたいと思います。
- 要件定義の重要性
- 新規事業における要件定義
- システム開発における要件定義の位置づけと役割
- 要件定義の目的とアクション
- 要件定義を進めていくためのマネジメント
なぜ上記の5つにしたかといいますと
- まずは全体の流れを把握して頂くために役割と位置づけを知っていただきたかったからです。また、今回はシステム開発の要件定義と限定させていただきます。要件定義は、システム開発時に必ず行われる工程であり、全体の半分近くを占める場合もあるため、ニーズも事例も多いからです。
- 次に「要件定義の重要性」としてのは、要件定義を軽んじるとシステム開発のプロジェクト全体が失敗するからです。実際に、IPAの調査では、システム開発の失敗の原因の約50%が要件定義の問題となっています。本記事で重要性についてしってもらい、実際に行う際はしっかりと人的・財的リソースを配分して進めていっていただきたいと考えました。
- 新規事業での要件定義は、少し一般のSIerの開発とは異なります。顧客の要望をシステムに落とし込むのではなく、お客様に売っていくことになるのでマーケティング要素が必要となります。そして、マーケティングの要素をシステムにいかに落とし込むかは要件定義工程で行います。また、新しく事業を始める上で初期投資を抑えやすい事業形態の一つだとも思いますので、覚えておいて損はないと考えました。
- １～３をご理解いただいた上で、要件定義のアクションとアウトプットについてご説明していきます。そのほうが自分の状況に即した事例を思い浮かべながら、アクションとアウトプットの具体例を想像しやすいと考えました。
- そして最後に要件定義が何たるかと、何をすればいいのかを理解していただいた上で全体をどう動かしていけばよいのかをご説明します。
今回は要件定義とは何かの全体像を把握していただくために、目的や流れを重点的にご説明しています。
もし要件定義の詳細な納品物や知りたい方は別記事で説明しますのでそちらをご確認いただければと思います。
要件定義の必要性｜システム開発の失敗の主要原因
まずは要件定義の必要性をご説明させてください。
システム開発ではついコーディングの工程を重要視しがちですが、リソース配分でいうと要件定義に半分を割くことも多いです。また、システム開発は失敗が多い案件の一つです。IPA（独立行政法人 情報処理推進機構）の調査では43.9%のシステム開発の案件で納期の遅延が発生しています。理由の半分は要件定義の甘さです。以下にIPAの工期遅延の原因分析表を示します。
こちらを見ると要件定義の問題として以下の項目があげられます。
- システムか目的不適当
- RFP内容不適当
- 要求仕様の決定漏れ
- 開発規模の増大
しかし、それ以外のプロジェクト管理の問題として挙げられている「自社メンバーの選択不適当」や「構築チーム能力不足」、「テスト計画不十分」などは要件定義が明確でなければ発生してしまう問題です。
また最上工程の要件定義が不明確だとその後の工程も進められなかったり、複数の選択肢が発生し開発メンバーが動けなくなってしまいます。
このように、要件定義をうまく行えていないとお客様や開発側のエンジニアから不満が出てしまいます。
しっかりと要件定義を行い、顧客側、自社の開発側との認識ずれが発生するのを防ぎます。これによりその後の設計工程や実装工程がスムーズに進みます。
新規事業における要件定義
次に、新規事業開発における要件定義についてご説明します。なぜなら、新規事業でシステムを作る場合には、システム開発の受託とは大きく異なるからです。
新規事業開発ではユーザーの購買までの流れも設計する
受託開発では顧客の要望を満たすことが売れるかどうかは要件定義が大きく左右します。
しかし、新規事業での自社システム開発を行う場合は、最終的なシステムのユーザーがコンバージョンするまでの流れを組み込む必要があります。
そのためには認知やコンバージョンなど、受託システムとは違う視点も必要になります。
いわゆるマーケティングの視点でシステム全体の設計が必要となります。
販売方法や認知させる方法（広告など）や競合との差別化要素などを設計します。
カスタマージャーニーマップやSTP分析などを用いて設計していきます。以下の記事で説明しておりますので、ご確認ください。
開発の流れも受託と新規事業では異なる
新規事業では、マーケティングの視点での設計が必要なのに加えて、開発の方法も受託開発とは異なります。
結論から申し上げますと、受託開発がクライアントとの合意ベースで進めるのに対して、売れるまでトライ&エラーを繰り返すのが新規事業です。
受託開発ですと決済者が最終的に1人に集約されるので、その人を見抜いて合意を取って行く必要があります。どちらかといえば事前に全体の設計図を形にするウォーターフォール型の開発の方が後のずれが発生しにくいです。
それに対して新規事業開発では、顧客の反応は試してみるまでわからないので、なるべく小さく始めて徐々に顧客の反応に合わせて拡大していく方がマッチしているでしょう。
ここでポイントとなるのはMVP（Minimal Valuable Product：最小の価値ある商品）という考え方です。
自分たちの商品の中で価値発揮が出来る最小単位のものを作ってとにかく市場に出す。そして市場の中で改善を繰り返す。という発想です。
逆に言うと、最小の開発工数で最低限の売上を立てるためには何が必要かを考え、それ以外の条件分岐が発生するポイントや仮説に関しては、実際に顧客に試してもらうまでやらないということが要点となります。
構造化すると、
- MVPが何かを定義する
- その後にどんな分岐がありそうかを分析する
- それぞれの分岐に対して最低限の検証方法・決断方法を定義しておく
となります。
分岐後の行動については、先に定義しておかなければ、後々チーム内で決断や行動に時間がかかってしまいますので、先に決定し周知しておくことをお勧めします。
新規事業開発担当者が行うべきことは｜要求定義と要件定義の概要
では新規事業開発担当者は何を行うべきなのでしょうか。新規事業開発担当者は要求定義を行います。そして、そのためには要件定義の概要くらいは知っておく必要があります。
もちろんシステムのことはシステムの専門家じゃなければ分からないことも多いです。しかし、新規事業開発担当者がシステムに対して全く関与しないと、システムと事業に乖離が発生し、うまくいきません。
そこでシステム開発者に対してのシステムに求めることをまとめた要求定義を行います。
しかし、要求定義を行うと言ってみてもいきなりは出来ないのではないでしょうか。
そこで要件定義について知る必要があります。
もしあなたが新規事業でシステムを用いることを検討している場合は要件定義について学習した方が良いです。
システム開発における要件定義の位置づけと役割
さあここからは「要件定義とは何か」からご説明していきます。本章では位置づけや役割、周辺の単語についても説明していきますので、要件定義の前後に何を行うか、何の目的で要件定義を行うのかを把握していただければと思います。
要件定義とはシステム開発の設計工程のファーストステップ
結論から申し上げますと要件定義はシステム開発の設計工程の最上流工程部分にあたります。
ここでシステム開発の全体像についてご説明します。以下に図示します。
今回はあくまで全体を理解していただくために概要の説明にとどめます。
システム開発の全体構成をより詳細に理解したい場合は別記事で説明しておりますのでそちらをご覧ください。
- 企画｜目的と課題を明確にする
システムで何がやりたいかを明らかにします。何をしたいのかの目的や現状の課題（システムでの課題も含める）などを定義します。提案依頼書（RFP）や要求仕様書を作成する工程がこちらに入ってきます。提案依頼書や要求仕様書はクライアント側が作成する場合も多いです。 - 設計｜システムに落とし込む工程
次に顧客の要望をシステムに落とし込む設計を行います。- 要件定義
クライアント側の目的や課題感の整理をします。業務フローの整理とシステムに必要な機能要件と非機能要件を明らかにします。 - 基本設計
ソフトウェア、ハードウェア含めた実現すべきシステムを明らかにします。 - 詳細設計
実現すべきシステムの各機能の繋ぎこみや、インフラ環境等を含めた設計をします。この設計書を参考にプログラマーが実装を行います。
- 要件定義
- 開発｜実際のコーディングを行い、形にしていく工程
実装工程です。詳細設計書を元にコーディングを行います。 - テスト｜実際に動くかを確認する工程
実装したシステムが問題なく動くかを確認します。また、元々の目的が実装したシステムで果たせるかを確認します。 - 導入｜クライアント組織の全員に使ってもらえるように説明とサポートをしていく
経営陣が求めているシステムが実現されていてもそれを全員が使ってもらえるとは限りません。そこで導入のサポートをしていく必要があります。 - 保守運用｜問題発生時の対応とアップデートしていく
導入後も問題発生時に対応する保守や運用をして最後まで伴走していきます。
クイズの答え｜要件、要求、機能の違い
前項でシステムの全体像をご説明してきました。ではここでクイズの答えを確認していきましょう。
Q. 要件定義とシステム設計の違い
A. 要件定義はシステム設計の一部。上流工程（システム設計）の中でも最上流工程。
Q. システム開発の中に要件定義は入りますか
A. 入ります。システム開発＞システム設計＞要件定義という包含関係となります。
Q. 要求定義、機能要件、要件定義の違いは何ですか？
A.
- 要求定義：顧客の要望を設計に落とすための方針。設計の前段階で行う。要求をまとめて開発側へ依頼するための資料としたのが提案依頼書（RFP）。
- 機能要件：システムとして実装すべき機能を定義したもの。対をなすのが非機能要件であり、ユーザビリティやUI/UXなどを定義したものです。
要件定義の目的とアウトプット例｜課題の定義と解決方法を示すのが要件定義
ここからは要件定義書にどんなことを記載すべきかについて説明していきます。あくまでここでは全体像を把握することを目的としていますので考え方とアウトプット資料例をご説明します。実際に要件定義書を作成したい方はこちらで考え方を把握した後に別記事をご覧ください。
それではまず一般的なアウトプットに記載する内容を以下に示します。
一般的な要件定義のアウトプット例
- 課題の整理
- 目的と解決策の定義
- 業務フローの整理
- 機能要件（画面、データ、帳票など）
- 非機能要件（ユーザビリティ、セキュリティ、運用、保守など）
（最上流工程）課題の整理とシステム導入の目的を整理する｜AsIsToBe分析
まずはシステムを導入する目的と現在の課題を定義します。今がどんな状態で（＝AsIs）、何を目指すのか（＝ToBe）、そしてその解決策（＝How）を定義します。
以下にAsIsToBeの例を示します。
このように現状の課題を整理し、それに対して達成したい姿を定義し、解決策をシステムによらず検討します。
AsIsToBe分析の例
| フェーズ | 項目例 |
|---|---|
| 現状の分析｜AsIs | ー業務の分析 ー現行のシステム構成 ー現在の課題 |
| 目標の設定｜ToBe | ーなりたい姿 ー達成したい数値目標 |
| 解決策｜How | ー新しい業務フロー ー組織や制度 ーシステム構成 |
AsIsToBeは何度もブラッシュアップし続ける
AsIsToBeの分析を行い、その後システムの要件定義を行っていきます。その際、具体的なシステムの定義を進めていくとシステム側での整合性を取るためにAsIsToBe分析で明らかになった本質の課題の解決と繋がらなることが発生しがちです。
しかしシステム導入の目的はあくまで組織の改善なので、常にこのAsIsToBe分析に立ち戻り、システム要件と連動させる必要があります。
これが本当に難しいです。なぜならチームで進める上でタスクを切り出した時に、全員が組織目線で考えることが難しいからです。したがってPMがしっかり各タスクの品質管理をしていかなければ実装やテストのときに問題が発覚し、下手すると設計まで手戻りが発生してしまうこともあります。
業務フローの整理と新業務フローの定義
次に今の業務フローを分析し、目的達成のための新業務フローを定義します。
この時は可能であれば、実際の様子を見させて頂いたり、ヒアリングをさせてもらうと良いでしょう。自分にコネクションが無く、難しい場合は、今ならWEBやSNSを駆使して情報収集するか、新しく業界の方にアプローチする必要があります。
この時、職位や部署ごとに認識が違ったり、指示と実際が異なったりする場合が多いので、なるべく全ての職位・部署の方にお話を伺うようにしましょう。
こういったテンプレートもあるので是非ご活用ください。
無料UML 図テンプレート – Word・PowerPoint・PDF
最終的には現業務フローと新業務フローを対比する形で図示します。
機能要件の定義（画面、データ、帳票など）
課題や目的と業務フローの整理が出来たら次に機能要件を定義します。
機能要件とは「人が行っている業務を代替、もしくはサポートするもの」です。すでにシステムを導入している場合はそのシステムが行っている場合もあります。
反対に非機能要件とは「性能や操作性など機能以外で求められる要件」です。
なのでシステムにどんな業務を行わせるかを定義していきます。
アウトプットは
- システム機能階層図
- 画面要件
- データ要件
- 帳票要件など
です。
システム機能階層図｜システム全体の階層マップ
システム機能階層図はシステム全体の階層マップです。表形式かロジックツリー形式で整理します。最初は表形式でブラッシュアップしながら、最終的にはロジックツリー形式でまとめると見やすいでしょう。
画面要件｜ユーザーが見る画面の項目と動きの定義
次に画面の中身を検討していきます。画面内に必要な入力項や表示項目と、各画面の関係性を定義していきます。画面遷移図などにまとめます。
帳票要件｜出力する表等の定義
次に出力するべき帳票について定義していきます。
データ要件｜保存するデータの関連性やテーブルの定義
画面を定義した後は画面から入力したデータの保存される場所や引き出し方（何と一緒に見せるかなど）を定義していきます。データ要件は画面要件や帳票要件を定義してからの方が良いでしょう。なぜかといいますと、ユーザーが触れるのは画面や帳票なのでユーザー目線でのシステムになるからです。反対にデータを先に定義すると、作り手によったシステムになってしまいます。
最後に後のフェーズのスケジュールとタスク設計します
要件定義の最終工程として、設計や開発工程のタスクとスケジュールを分解して手分けして全体の管理を行う必要があります。
この時WBS（Work Breakdown Structure）というフレームワークが有効です。
作り方は単純です。
- ①タスクを分解
- ②各タスクの期限を設定する
以上です。
ポイントはボトルネックとなるタスクから期限を設定していくことです。
例えば、いつまでにテストを終えたいか、そのためには実装をいつまでに終えるべきか、そのためには設計を・・・といった順番です。
また、データ側と画面側を繋ぐタイミングやまずは1つの業務に沿って開発～テストまで試したいという場合もあるかもしれません。
ここは経験の部分やチーム体制も大きく影響するので一概には言えませんが、チーム全体が動いてもらうためには必須となります。
まとめ
今回は要件定義の概要について説明しました。いかがでしたでしょうか。要点をまとめます。
今回のまとめ
- システム開発の失敗原因の約半分は要件定義フェーズで発生する
- 新規事業開発者も要件定義に関しては学習したほうが良い
- 要件定義は業務、画面、帳票、データの要件を定義するものである
最後まで読んでいただきありがとうございました。
本記事が少しでも皆様のお役に立てれば幸いです。
