システム開発の「要件定義」とは？意味・目的・進め方＆そもそもだれがやるの？を解説

と言った疑問に答えます。この記事を読むことで、
・要件定義とは何か？意味
・要件定義の進め方
・要件定義に必要成果物
・要件定義推進で気を付ける事
・要件定義の一般的な役割分担
を理解する事が出来ます。

Sier目線と事業会社目線では、要件定義の目的や進め方が異なります。多くの要件定義に関して解説している書籍やウェブサイトは、Sier　SE目線での解説が殆どです（理由：IT人材の８割はSierに所属し、２割が事業会社等に所属している為、事業会社の社内SEはマイノリティーの為です）。本記事では、事業会社・Sier両目線の両方の目線で要件定義を解説します。これにより、要件定義の進め方は分かったけど、そもそも要件定義って誰がどの部分をやるの？と言った疑問にも答えていきます。

本記事で解説する概要

本記事は、以下の社内SE基礎講座の「システム要件定義の目的・進め方」の記事です。

IT初心者・社内SE向け｜システム開発の【基礎講座】関連記事一覧

要件定義とは？の概要を理解しよう

要件定義の目的を以下の３つの観点で解説していきます。

Sierの考える要件定義と社内SEの要件定義の違い

まとめると以下です。

一般的にネット等で見かける、プロジェクトにおける要件定義（上図のように）は、システムで何を作るかを決める工程と言われています。間違ってはいません。むしろ、Sierがお客様となる事業会社からシステム開発やパッケージ導入の案件を受注した段階では適切です。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

しかし、事業会社における要件定義はこれだけではありません。その理由は、要件定義とはシステムの要件だけを決めるわけではありません。プロジェクトでは、ビジネスや業務上抱えている課題を解決し、それを何らかの手段で解決を狙います。そのプロジェクト成功の為に何を具体的に解決するのか、システムでの解決要件だけではなく、業務等その手段で解決する要件を決めるのが要件定義です。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

プロジェクトで解決したいビジネス課題を特定し、その沢山のどの課題（WHAT）をどうやって（HOW）解決するのか方向性を決めていきます。そのWHATの中で、いくつかはITシステムで開発したり、ITソリューションで解決します。

したがって、裏返しとし、幾ら、社内SEやSierが上手く要件（WHAT)に基づきシステムを上手く構築（HOW）しても、そもそも定義した要件で、ビジネス課題を解決出来なければ、結局ビジネス課題を解決する事は出来ません。

このように、システム構築以前に、上流工程でプロジェクトの成否が決定づけられます。この重要な要件定義の目的・意味を更に詳しく理解する為に、異なる視点で深堀します。解説する観点は以下です。

要求定義、要件定義と基本設計の違い

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

要求定義は、お買い物リストの様なものです。解決したいビジネス課題を解決するために必要な要望を定義します。その要望から、何をどのように解決するか検討を進めます。要求を元にその要件を定義します。システムやシステム以外に何を求めるかを決めていきます。基本設計以降では、その要件をどう実現するかのHOWを検討します。

要件定義って誰がやるべきなの？

広義で要件定義といっても、業務要件の洗い出しとシステム要件の洗い出しにわけて考えるべきです。業務要件を洗い出した後の業務要件事態の責任は業務部門にあります。しかし、その洗い出し作業を社内リソースの不足等を理由に、外部リソースに依頼し作業を実施してもらう選択肢もあります（以下図の②③の例）。

一方、システム要件定義は社内ＳＥとＳｉｅｒで実施するのが一般的です。外部Sierにシステム要件整理を依頼していたとしても、自社の既存システムとの連携等必ず発生する為、⑤の丸投げのケース以外は、社内SEが関与します。

このような様座な要件定義を誰がやるのか？といったパターンは以下の５つに集約出来ます。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

どのようなプロジェクトの編成で要件定義を推進するか？やどの部分に外部コンサルタントやSier　SEに依頼するかであなたの担当するプロジェクトの要件定義を誰が実施するのかは異なります。又、企業の文化やプロジェクトの規模によってもどの要件定義の部分を外部リソースに支援してもらうかが異なる点も認識が必要です。

しかし、いずれの場合でも（⑤の丸投げを除き）、業務要件の責任は業務部門であり、その部分まで社内SEで責任を取ってはいけません。これは、家を建築家に依頼したのに、何も要求を言わず建築家の言われるがままの家を建ててしまうのに等しいです。家が出来上がってから、実はバリアフリーがよかったや、お風呂が大きい方がいい、トイレは和式より洋式がいいといっても後の祭りと同じです。作業支援を頂いてもしっかりとレビューし合意形成前に指摘し必要な修正をすることが重要です。システム開発も同じです。

要件定義の目的・重要性

要件定義の目的や重要性は１つではありません。よく言われている目的や重要性を解説します。

業務・事業部のニーズを把握する

要件定義を通して、業務や事業部が何のビジネス課題を解決しようとしているか理解します。これによりITでどのようにその課題を解決できるか検討を進める事が出来ます。もし、この要件定義中にビジネスの課題解決の手段としてITが妥当でないと気づいた場合エスカレーションが必要です。

時々、システム導入自体が業務や事業部のプロジェクトの目的になってしまっている場合があります。ITや社内SEがよりビジネスの目的何を解決したいか注意してヒアリング・理解し検討を支援する必要があります。

プロジェクトの開発スコープを明確にする

要件を明確化する事で、プロジェクトのスコープを明確にすることができます。ビジネスのゴール達成に貢献しない範囲や費用対効果があまり期待できない領域は要件定義で議論しビジネスに効果的に貢献できるようにドライブが必要です。

開発のスケジュール・コストの精緻化する

要件定義によりスコープが精緻化されることにより、開発の期間と必要コストを精緻化する事が出来ます。要件定義を実施するまでは、占いやベンダーからの超概算の数字・期間で見積もっている精度を上げる事が出来ます。

デリバリーの品質を上げる

スコープを精緻化することにより、まだ基本設計に移る前の段階ですが、技術的に難しい要件やコストのかかりすぎる若しくは期間のかかりすぎる要件をそぎ落とす事が可能です。もし効果があまり変わらなく業務・事業的に許容できるのであれば、積極的に現実的に実装可能な要件に絞りデリバリーの品質を上げる事が可能です。

要件をFIXする

要件定義の目的は、ディスカッションをなんとなく重ねる事ではありません。要件をFIXする＝決定する事です。誰も何も決めない要件定義は時間の無駄です。しかるべき決定が出来るように、成果物・役割・体制を定義し要件を固めに動く必要があります。

要件定義の内容や役割｜更に詳しく要件定義を理解しよう！

要件定義の内容を理解する為に押さえておきたい観点は３つの以下です。この３つをふまえ、記事後半で要件定義書に関して解説します。

システム開発における要件定義フェーズとは

システム開発プロジェクトにおける要件定義を理解する為に要件定義フェーズはどの工程なのか？から解説します。基本的には、要件定義フェーズは、要求定義と基本設計の間のフェーズです。要求を掘り下げ、何をシステムに期待するかをディスカッションし文章化していきます。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

ただし、（ここが厄介で）プロジェクトによっては要件定義が複数回登場する場合がある点です。例えば、自社内で一度業務部門とハイレベルな要件定義を実施し、SierにRFPを依頼し、Sier選定をしSierと契約後、Sierがもう一度要件定義を実施する場合等です。こうなってくると、IT初心者の方等は混乱します。しかし、覚え方は簡単です。要件定義は要件を定義する工程の為、その目的によってはプロジェクトで複数回要件定義が発生する場合もあります。

要件定義＝要件を固める工程
要件定義の目的＝システム開発の基本設計に繋げる場合、次の工程は基本設計
要件定義の目的＝RFPを実施する為のハイレベルな要件を固める場合、次の工程はRFP
上記二つの要件定義では、要件の具体化具合は異なります。

要件定義を進める為に必要な成果物

要件定義で最終的に必要な成果物は要件定義書です。まず初めに、要件定義書を作る為に、必要なインプットとなる成果物の一覧と後ほど要件定義書には含まれるべき内容を分けて解説します。

業務系の検討内容がインプットなりシステムにどんなことを求めるのか定義していきます。以下の図は、企画書に必要なインプットとなっていますが、基本要件定義フェーズでも同様です。企画フェーズなどから例えばTo-Be業務フローは検討が開始されます。この段階ではハイレベルな業務フローのTo-Beです。要件定義フェーズでは、これらのインプットを元により具体化しシステム化要件へと落とし込んでいきます。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

要件定義書に含まれるべき内容

要件定義書と一言で言っても、以下の要件定義で決められる要素別に１つづつのドキュメントとして定義したり、１つのドキュメントの中に全ての要素を含む巨大なドキュメントと管理したりと、企業文化やシステム開発を依頼するSierによってドキュメントの整形が異なる場合があります。

しかし、基本的に要件定義書に含まれるべき要素＝要件定義中に決めるべき要素は同じです。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

機能要件・非機能要件とは何か？どのような内容を記述するべきは？は【社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール】の１７１ページで解説しています。ご興味のある方はご参考ください。

要件定義書の書き方＆テンプレート/サンプル７選|すぐに使えて便利

要件定義書ってどう書くの？書き方と直ぐに使えるテンプレートやサンプルも欲しい！ と言った疑問・要望に答えます。 本記事で、「システム要件定義書」ってどう準備して...

itinfoshop.com

2024.05.29

要件定義書作成までの流れ

要件定義書を作成する際には、基本業務検討が活性化しTo-Beの業務検討が進んでいく必要があります。このTo-Be業務検討の進め方も、システムを業務要件に合わせて開発する場合と、業務をパッケージなどに合わせて進める場合でアプローチが異なります。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

事業会社はIT企業ではない為、システム開発能力も有限です。その為、システムは餅は餅屋でシステム屋さんに構築してもらい、そのシステムやソリューションやサービスを使いビジネスの改題を解決するアプローチが増加しています。このシステム導入では、既にそのシステムで想定される業務プロセスのモデルがあり、その業務プロセスにどう自社業務を合わせていくかがポイントです。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

作る場合、使う場合いずれのモデルでも、To-BEの業務プロセスを描きそこから必要な機能要求を一覧化し、その業務要求に基づき業務要件の一覧を作成していきます。

そうして出来上がった要件を更にディスカッションや取捨選択を重ね、要件定義書に落とし込んで成果物を完成させます。

要件定義の進め方のコツ

要件定義を上手く進める為に、必要だなと感じたポイントやコツを解説します。

要件定義のフェーズを理解する

ここまでの解説でご理解いただいたように、「要件定義」の定義は様々です。企画段階の要件定義もあれば、システムの実装する為の要件定義もあります。参画するプロジェクトにおける要件定義の定義を理解する必要があります。その上で、その期待にそったアウトプットを狙っていく必要があります。

例えば、まだ企画段階のハイレベル要件定義を実施しているにも関わらず、詳細の業務フローを業務部門に期待するのはミスマッチです。一方、実際のシステム実装の為の要件定義を実施している段階にも関わらず実際のTo-Be業務フローの検討が進んでいない場合要件を固める事は出来ません。

要件定義のベンダーの使い方を理解する

各社各様の要件定義の進め方があります。要件定義まで自社で実施し、システム構築を依頼するパターンや、要件定義もSierなどに支援してもらうパターン等です。自社若しくは参画するプロジェクトにおけるSierの使い方を理解し貢献する必要があります。

要件定義に必要な成果物を理解する

成果物を進める為に、何の成果物が必要か？理解すべきです。又、参画するプロジェクトで誰がどの成果物を作成するのか合意する必要があります。成果物一覧を作成し、役割分担を握る必要があります。

成果物に関しては、（特に一度もお仕事をしたことが無いSier等の場合、成果物の一覧で握りだけでは成果物の完成イメージで大抵認識齟齬が発生する為、サンプルで最終イメージの確認がお勧めです。

要件定義の役割分担を理解する

どの成果物を誰が作るのか？は重要です。システムの要件定義の作成には、様々なインプットが必要です。必要な検討が実施されインプットとなる成果物が出来上がることでシステム要件定義書が完成します。インプットとなる成果物の役割分担を明確にしないと、インプットとなる成果物の遅延のせいで要件定義が遅延したとしても全ての責任を社内SEやSierにかぶせられたりします。適切な役割分担と進捗管理で健全にプロジェクトを実施する事が可能です。

自分にできる貢献にフォーカスする

システム開発プロジェクトは大抵一人で推進しません。チームで役割を分業し協力してプロジェクトを推進します。チームで健全に役割を分担した後は、自身のやるべき範囲に集中すべきです。ついつい、他の担当領域が気になったり、支援したくなったりします。最大限貢献する為には、まずは自分の責務を全うしチームに貢献すべきです。その上で、余力があれば他の領域の支援をしましょう。

大規模プロジェクトでは、いくら個人が頑張っても上手くいかずストレスに感じてしまう場合もあります。その際にも、自分に出来る事・すべき事にフォーカスする事でストレスレスに貢献する事が可能です。

楽しむ

要件定義でも何でもやはり楽しんだもの勝ちです。失敗してもたかが仕事です。もし、上手く機能しないシステムを作ってしまった場合、今の業務を続ければいいだけです。ビジネスは続きます。又チャンスもあります。あまり、気を張らずリラックスして要件定義を楽しみましょう。

必要維持にナーバスになってしまう場合は、あなたの作った仕組みで業務やお客様を快適にして喜ばれるシーンを想像し、ワクワクして要件定義を進めましょう。

システム開発の「要件定義」とは？意味・目的・進め方＆そもそもだれがやるの？を解説まとめ

要件定義に関して、記事前半では要件定義の概要を解説しました。

ポイントは以下です。

記事後半のまとめ