要件定義とは？詳しく解説させていただきます

TOP
コラム
要件定義とは？詳しく解説させていただ

要件定義の概要について

システム開発における工程は「要件定義」「基本設計」「詳細設計」「プログラミング」「製造」「単体テスト」「結合テスト」「総合テスト」というように細かく分類され、それぞれの工程において決められた役割が存在します。また、要件定義に近いほど上流工程と呼ばれテスト工程に向かうにつれて下流工程と呼ばれる工程になっていくこともシステム開発における基礎的な知識の一つとして抑えておく必要があります。要件定義はシステム開発を行う際に最も上流に概要する部分であり、要件定義の段階で検討する項目が多数存在し、クライアントと打ち合わせを行いながらその項目を決定していきます。要件定義の品質が低いことでシステム開発やプログジェクト全体に悪影響が出てしまうため、正しい知識に基づいて高品質な成果物を目指す必要があります。要件定義の目的としてはクライアントとベンダー側・開発者側双方の認識をしっかりと合わせるという意味があり、プロジェクトが開始された後に認識の相違が起きないように事前に様々な項目を決定していきます。要件定義の目的については詳しくは後述させていただきますが、「誰が何をいつまでに行うか」などを明確に定義して、要件定義書という形の成果物として残します。要件定義はクライアントとベンダー側の担当者やプロジェクトマネージャーが直接やり取りを行いそのうえで作成することになりますので、要件定義に関わる作業者はコミュニケーション能力やITに関する幅広い知識が求められることになります。
昨今ではクラウド化やDX(デジタルインフォメーション）がトレンドとして様々なメディアで報道されておりますが、それらの便利なテクノロジーも単体で成立するのではなく、システム開発がしっかりと行われているという前提の元に成立しております。その土台となるのが要件定義となりますので、その重要さは理解していただけるのではないでしょうか。そのため、要件定義についての概念や考え方はこれからエンジニアになりたい方や若手エンジニアの方はしっかりと学習しておくことをおすすめします。また、要件定義についての考え方は開発エンジニアだけでなくインフラエンジニアやデータベースエンジニアなどITに関連するあらゆる職種についても重要となることはいうまでもありませんので知識がない方は是非学習してみてください。ここからはさらに詳しく解説させていただきますので、参考にしていただけましたら幸いです。

要件定義の目的について

独立行政法人情報処理推進機構（IPA）は経済産業庁の管轄下にある組織であり、IT産業の振興を目的として開発者に対して様々な支援やルールを示している団体かつ、日本国内のITにおける一つの標準的なルールを整備している組織とも言えます。 IPAは要件定義について「ユーザーのための要件定義ガイド」「高品質のための超上流工程における企業の課題・取組み事例集」にその目的と考え方などを示しているため、本文ではそれに従った形で要件定義の目的を説明させていただきます。
「高品質のための超上流工程における企業の課題・取組み事例集」においては「他者とコミュニケーションを図る際、相手に伝えるべきポイントを Who, What, When, Where, Why, How で整理するとよいとよく言われる。ビジネスにおいては How much を加えた 5W2H がよく引き合いに出される。これに、超上流工程における“基本的な”検討事項を当てはめてみると、以下のようになると思う。」と記載されております。その内容については「Who 組織・体制」「What 解決すべき課題」「When 計画・納期」「Where 対象範囲」「Why 目的・目標（効果）」「How 実現方法・手段」「How much 投資額」となります。これらの7つの項目に従った形で要件定義を作成する形を推奨されており、それぞれについて詳しく解説させていただきますので参考にしてみてください。

誰が行うかを明確にする

要件定義の目的の一点目として誰が行うかを明確にするということが大切となります。「高品質のための超上流工程における企業の課題・取組み事例集」における「Who 組織・体制」に該当する部分です。システム開発を行う際にどういった体制を作り業務を担当するかという点は予算やスケジュールとの兼ね合いで慎重に検討しなくてはいけないポイントの一つとなります。 ITエンジニアの一人月の作業量というのは決まっておりますので、体制作りに失敗してしまうとプロジェクトの失敗や赤字の原因となりかねません。

何を行うかを明確にする

要件定義の目的の二点目として何を行うかを明確にするということが大切となります。「高品質のための超上流工程における企業の課題・取組み事例集」における「What 解決すべき課題」に該当する部分です。クライアント自身がどのような課題を解決したいのかはっきりわからないまま開発に入らないようにしなくてはいけません。特に問題が複数存在する場合は注意が必要となります。全ての課題を全て完璧に解決できる方法があれば問題ありませんが、現実はなかなかそうもいきません。そのようなケースは優先順位をつけて課題解決に取り組む必要があります。

いつまでに行うかを明確にする

要件定義の目的の三点目としていつまでに行うかを明確にするということが大切となります。「高品質のための超上流工程における企業の課題・取組み事例集」における「When 計画・納期」に該当する部分です。納期の時期を決定し、そこから逆算してスケジュールを立てることはプロジェクトマネージャーにおける重要な役割の一つとなります。それを実現するためのは見積もりの精度や正しいプロジェクト運用や管理能力など様々な能力が必要となることはいうまでもありません。

どこで行うかを明確にする

要件定義の目的の四点目としてどこで行うかを明確にするかということが大切となります。「高品質のための超上流工程における企業の課題・取組み事例集」における「Where 対象範囲」に該当する部分です。これは体制作りと同時に、例えばオフショア開発・ニアショア開発などの判断やその業務範囲などを明確にする必要があるという内容です。

何故行うかを明確にする

要件定義の目的の五点目として何故行うかを明確にするということが大切となります。「高品質のための超上流工程における企業の課題・取組み事例集」における「Why 目的・目標（効果）」に該当する部分です。これは簡単に説明させていただくと、システム開発の目的をしっかりと定義しクライアントとベンダー側で認識をあわせるということになります。システム開発をスタートしたものの、システムを開発することそのものやトラブルを解決することが目的になってしまってはいけません。大きな予算を投じてプロジェクトを組む場合、途中で方針を変更するとなった場合大きな損失がでてしまうケースも少なくありませんので、「何故このシステムが必要なのか」という根本をしっかりと理解しておく必要があります。

どうやって行うかを明確にする

要件定義の目的の六点目としてどうやって行うかを明確にするということが大切となります。「高品質のための超上流工程における企業の課題・取組み事例集」における「How 実現方法・手段」に該当する部分です。プラットフォーム（ネットワーク、ハードウェア、OS、ミドルウェア等）の検討や、必要な機能（機能要件）の整理、求められる性能等（非機能要件）の把握やアーキテクチャーの設計など課題を解決するためのテクノロジー面の選定を行っていく必要があります。また、予算やシステム要件との兼ね合いから最適な組み合わせを選ぶことも重要なミッションと言えるでしょう。

予算を明確にする

要件定義の目的の六点目として予算を明確にするということが大切となります。「高品質のための超上流工程における企業の課題・取組み事例集」における「How much 投資額」に該当する部分です。当然ながらプロジェクトは予算がなくては運営することができません。適切な予算を設定することが健全なプロジェクト運営には必須となるため、正しい見積もり能力が必要となってきます。

要件定義の際のフローと決定事項

要件定義の目的を理解したうえで、クライアントと打ち合わせやヒアリングを行い具体的な要望を細分化し、要件定義書に落とし込んでいくというのが要件定義における業務フローとなります。それでは、実際にどのような要望をヒアリングし、決定事項とするべきなのかという点について詳しく紹介させていただきますので参考にしてみてください。

業務フローを作成

要件定義の決定事項の一番目として業務フローを作成することとなります。現在の業務フローを作成し、クライアントとベンダーベンダー側・開発者側双方の認識をしっかりあわせることが大切です。そのうえで課題が解決されたあとの業務フローを作成し、比較することでこれからの作業の目的などをクリアにする必要があります。これを行うことでクライアントが解決しようとしている課題に対してベンダー側で様々な提案を実施することが可能となります。また、クライアントが解決したい課題が実は部分的にしか解決できないなどということが判明するケースもありますので、リスクヘッジを行い目的に対して最善のアプローチを見つけるための業務フローを作成することになります。

業務要件を作成

要件定義の決定事項の二番目として業務要件を作成することとなります。業務要件一覧はクライアントが必要としている機能を記載する形になります。業務要件はクライアントからの要望とするシステムとなりますので、クライアント社内のどの部署からの要望なのか、あるいは懸念事項や返答事項などの情報をもらい精査する形となります。また、クライアントや概要担当者と打ち合わせを実施して深堀するなどの対応が必要となります。業務要件は目的や課題を明確にし本当に必要であるかという点などをしっかりと精査し業務要件一覧を作成する必要があります。業務要件一覧を作成した後にシステム機能要件一覧などに落とし込んでいく形となります。

システム機能要件を作成

要件定義の決定事項の三番目としてシステム機能要件を作成することとなります。システムの稼働環境であるプラットフォームを決定していくこととなります。ハードウェア構成図・ソフトウェア構成図・ネットワーク構成図・アプリケーション機能構成図などを作成していきます。ハードウェア構成図ではサーバーの構成図を作成してCPU、メモリなどの情報も記載します。ソフトウェア構成図ではOSやミドルウェアの構成を記載します。ネットワーク構成図ではネットワークの構成を記載します。アプリケーション機能構成図ではシステム機能が階層的にわかるように図解を行います。

画面要件を作成

要件定義の決定事項の四番目として画面構成を作成します。画面名、階層、説明、機能名などを一覧として記載します。また、ツリー型にしてサイトマップのような形でわかりやすく記載するケースもあります。画面遷移図で画面の表示順や各画面の関連性を表示します。また、画面レイアウトを作成し画面のイメージを共有します。

帳票要件を作成

要件定義の決定事項の五番目として帳票要件を作成します。帳票一覧、帳票概要、帳票レイアウトなどを作成しクライアントとイメージを共有します。

外部システム連携図

要件定義の決定事項の六番目として外部システム連携図を作成します。データ形式やネットワーク・プロトコル、連携のタイミングなど既存システムとの連携について明確に定義します。

非機能要件

要件定義の決定事項の七番目として非機能要件を作成します。非機能要件はクライアントの希望する機能以外であり、 IPAの推奨する非機能要求グレードの考え方を参考にして、カテゴリーごとに検討するといいでしょう。 IPAではユーザー視点から要求の実現レベルを見える化するため、段階的に詳細化しながら「早期に」「誤解なく」「漏らさずに」確認できることを推奨しており、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーに分類されます。

要件定義に必要なスキルについて

要件定義に必要なスキルについて説明させていただきます。ポイントを絞り紹介させていただきますので、参考にしていただけましたら幸いです。

コミュニケーション能力

要件定義に必要なスキルの一点目がコミュニケーション能力となります。要件定義を行う際にはクライアントと打ち合わせを行い、ヒアリングを行う必要があります。クライアントからの要望をしっかりと引き出すためにはコミュニケーション能力が必要となります。また、ベンダーや開発者として技術的な話をわかりやすく説明する際にも、相手の担当者にあわせた説明能力が必須となりますのでコミュニケーション能力が求められるでしょう。プロジェクトマネージャーの立場で参画する場合は利害関係者の間に立ち調整する必要がありますので、そういった場合ももちろんコミュニケーションは必要とされます。

システム開発全般の知識

要件定義に必要なスキルの二点目がシステム開発全般の知識となります。要件定義書の作成に必要である業務要件・機能要件・非機能要件をしっかりと把握するためにはシステム開発全般の知識が必要であり、クライアントのシステムを俯瞰的に理解する能力が必要となります。非機能要件においてはクライアントがイメージすることが難しい課題や機能、あるいはビジネスに直接は直結しないリスクなどを打ち合わせやヒアリングを通じて把握していく必要があります。そのため、要件定義を高い品質で実行するためにはシステム開発全般の深い知識やITエンジニアとしての高い専門性が求められます。

ドキュメント作成能力

要件定義に必要なスキルの三点目がドキュメント作成能力となります。要件定義書はクライアントの多くの関係者が閲覧することになり、その中には非エンジニアも含まれます。専門的な内容をよりわかりやすく表現するドキュメント作成能力も要件定義には必要なスキルと言えるでしょう。また、複雑や業務フローを図解するケースも多々ありますので大規模システムや複雑な業務システムの場合はドキュメント作成能力だけでなくフロー図などの作成能力も重要となってきます。

要件定義書に記載する内容について

要件定義書に記載する内容について説明させていただきます。要件定義書に記載する内容についてはシステムの規模や業種などによりケースバイケースであり、クライアントと打ち合わせをして決定していくケースも多いです。ネットなどで検索すると要件定義書のテンプレートを確認することができますので、興味のある方は調べてみてもいいでしょう。ここでは、ポイントを3つに絞り紹介させていただきますので、参考にしてみてください。

システム化の狙いと業務要件

要件定義書に記載する内容の一点目がシステム化の狙いと業務要件となります。そもそも何故システム化するのか？という点の説明とシステム化する前、もしくはシステム化したあとの業務フローなどについて説明を行います。業務要件とはシステム開発において対象となる業務の流れを明確にしたものとなります。ビジネスプロセス・業務フロー・業務機能構成表などを利用すると視覚的に理解しやすくなります。大規模なシステムや多くのシステムが関連しながら構成されている場合、しっかりと全体像を把握できるように要件定義書に記載しておくといいでしょう。

機能要件

要件定義書に記載する内容の二点目が機能要件となります。機能要件とは「実装する機能」に関する要件のことであり、クライアント（発注）を行う側が盛り込んでほしい機能となります。システム方式・画面要件・帳票要件・バッチ要件・外部テーブルやファイル要件・インターフェース要件などが代表例となりそれぞれについて構成図などを用いて説明を行います。

非機能要件

要件定義書に記載する内容の三点目が非機能要件となります。非機能要件とは、クライアントが機能面以外で求める要件のことであり性能面やセキュリティ面等において顧客が潜在的に持っている「隠れた要件」のこととなります。そのため打ち合わせを綿密に行うことやヒアリングを行うことで非機能要件を整理することが可能となります。要件定義の工程においてクライアントの満足度を高めるために非機能要件は重要な役割を占めており、いかにクライアントのニーズを理解しシステムの課題やリスクを理解できるとかという点は要件定義を行う担当者やベンダーの能力と関連性が高い部分でもあります。 IPAの推奨する非機能要求グレードの考え方では、システム基盤に関する非機能要求を6項目に分類しそれぞれの確認結果に基づき、実施する対策例を提示しておりますので興味のある方は参考にしてください。

システムアーキテクト試験について

要件定義に関連する資格としてシステムアーキテクト試験（Systems Architect Examination）というものがあります。 システムアーキテクト試験は情報処理技術者試験の一区分に該当しており、試験制度のスキルレベル4として高度情報処理技術者試験に含まれます。システムアーキテクト試験は要件定義、外部設計など上流工程に携わる上級エンジニアが取得する資格として比較的難易度の高い資格として知られております。 IPAの定義によりますと「高度IT人材として確立した専門分野をもち、ITストラテジストによる提案を受けて、情報システム又は組込みシステム・IoTを利用したシステムの開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計し、情報システムについては開発を主導する者」と定義されております。
「応用情報技術者試験に合格すること。」「いずれかの高度情報処理技術者試験に合格すること。」「情報処理安全確保支援士試験に合格すること。」「いずれかの高度情報処理技術者試験の午前Iに基準点以上を得ること。」「情報処理安全確保支援士試験の午前Iに基準点以上を得ること。」に該当する受験者は2年間、午前Iの科目免除を受けることが可能となります。
システムアーキテクト試験は、午前I・午前II・午後I・午後IIの4項目から構成されております。午前は4つの選択肢から1つの回答を選択する多肢選択式、午後は記述式の試験が行われます。それぞれ、午前I：50分で多肢選択式で30問、午前II：40分で多肢選択式で25問、午後I：90分で記述式で4問中、2問を選択して回答、午後II：120分で記述式で3問中、1問を選択して回答、となります。

まとめ

いかがでしたでしょうか？要件定義について解説させていただきましたので、参考にしていただけましたら幸いです。