2021.05.19

要件定義とは?正しい仕様書の書き方や注意点、基本設計や要求定義、RFPとの関係についてわかりやすく解説

要件定義とは?正しい仕様書の書き方や注意点、基本設計や要求定義、RFPとの関係についてわかりやすく解説

要件定義は、デジタル化が進むIT社会において、どんなビジネスマンでも理解しておきたいキーワードの1つとなっています。

どの企業でもDX推進が叫ばれる中、ITシステム開発やソフトウェア導入がチームプロジェクトとして行われることが多くなりました。その際、システムの機能要件を明確化し、基本設計や作業のワークフローを整理する”要件定義”が必要不可欠になっています。また、調達・購買活動においても要件定義をすり合わせることは重要です。

この記事では、要件定義書の作成方法やプロジェクト進行中の注意点についてわかりやすく解説します。

TEXT BY Leaner Magazine編集部

    

要件定義とは

要件定義とは、製品の制作・開発をスタートする前に、「顧客の要望・要求に基づいて実装する機能要件や性能仕様などを定め、プロジェクトを具体的にどのように進めていくかを決めた」一連の流れを指します。

まずは、ユーザー側の要望を引き出し、整理することから始まります。そこから、具体的な開発工程を設計するために業務フローや業務のシナリオを作成していきます。

要件定義の設計は、企業のマネージャーやディレクター、リードエンジニアなど制作・開発プロジェクトを指揮する人間が中心となり、プロジェクトの進行に必要な項目・機能要件を列挙するところからはじめます。

その内容を“要件定義書”と呼ばれる仕様書に落とし込み、開発者や利用者などのステークホルダーと共有、内容を推敲していきます。

     

要件定義の目的や効果

要件定義はもともと、システム開発領域で発達してきた設計方法・メソッドです。クライアントの要求を聞き出してから詳細な機能を設計するまでの工程、いわゆる上流工程、の作業効率化・透明性の向上が主な目的としてあります。

システム開発など複雑なワークフローが存在する大規模な制作・開発作業においては、仕様書によってワークフローが体系化され、チーム内の役割分担が明確化されることで業務を効率化することができます。加えて、要件定義書をしっかりと作成することで、社内と社外での”共通言語”が形成され、ユーザーや顧客の要求を関連部署に対して共有しやすくなります。

一方で、要件定義が正しく行われないと、それぞれのチームの主観的な判断で作業が行われてしまうケースもあります。作業全体のワークフローが乱れ、時には制作・開発が終わった後に差し戻しが起こることもあります。

常に、満足度の高い製品やプロジェクトを生み出すためにも要件定義の手続きを正しく踏むことは必要不可欠です。

     

要件定義・基本設計・要求定義それぞれの違いとは?

基本設計は要件定義の一連の流れに組み込まれているケースも多く、混同することが多々あります。しかし、一般的に基本設計とは、要件定義が行われプロジェクトの詳細が明らかになった段階で追加的に作成されるもののことを指します。

基本設計書には、多くの場合、商品の具体的な仕様、例えばシステムのUI/UXにあたる部分が記載されます。具体的には業務フロー、機能一覧、画面レイアウト、画面遷移、インターフェース一覧などがあたります。

基本設計書は、商品の内容を明文化するだけでなく、視覚的に明示・共有できる役割を持っている点が特徴です。セキュリティ面の管理や運用規定といった重要項目も、この時点で決定されます。

また、要件定義と似た言葉に「要求定義」というものがあります。要求定義とは、顧客の要望をまとめることを指します。それら顧客の要望としては「デザインの中で特に重視してほしいメッセージや加えてほしいロゴ」「プログラム構成において社内の既存ITシステムとどのように連携してほしいのか」などが記載されます。

    

要件定義を進める上での注意点

要件定義を進める上では、以下の3点について注意することが必要です。

  1. 顧客視点と開発者視点の使い分け
  2. 顧客との共通認識を深めるために視覚化を行う
  3. 仕様書の変更に備える、進行に柔軟性を持たせる

     

顧客視点と開発者視点の使い分け

開発者の視点から見た際、要件定義は「本格的な開発工程の前段階で、顧客の要求を集約し、具体的な進め方を決めること」を指します。一方で、顧客目線から見た際、要求定義というのは「顧客自身が何を必要としているかを定義するもの」になります。どちらの視点から要求・要望するかで要件定義書への見方も変化するので、注意しましょう。

開発開始段階でゴールが不明確だと、どのように進んだら良いかが分からないため、要件定義はプロジェクトの成功に必要不可欠だと言えます。また、開発途中で仕様が変わることもありますが、最低限崩してはならないコンセプトを事前に顧客と合意しておくことも大切です。

    

顧客との共通認識を深めるために視覚化を行う

ワークフローを大雑把に書き出して、必要な作業工程を箇条書きで無造作に並べるだけでは、各々の判断に具体的な作業が委ねられ、認識に齟齬が生まれる可能性が高くなります。そこで、事前にマネージャーやディレクターが共有する内容を、文章だけでなく図式などに視覚化されたワークフローを用意することがスムーズな作業には必要となります。

たとえば、図表やフローチャートを通じて各タスクのつながりを表現する手法は、視覚化の手段としてよく用いられています。それぞれのチームが互いに担当する役割の関係性や補完関係を理解することで、完成品の品質や精度を高めることができます。

    

仕様書の変更に備える、進行に柔軟性を持たせる

要件定義の仕様書は、発注する製品の性質に応じて、求められる細かさが異なります。例えば、買うものの図面が決まっている機械(工場設備など)は、ある程度のテンプレートが社内一律で用意されていて、それらテンプレートに沿って発注が行われることが多いです。

一方でITシステムによっては、社内の既存システムとの相性を試しながら、導入する必要がある場合もあり、その際には作成途中で要件定義に変更が加わることを見据えて作成されることもあります。

特にシステム開発では、状況に応じて大きく分けて2つの開発アプローチ、ウォーターフォール開発とアジャイル開発の2つがあります。

ウォーターフォール開発とは、システムの機能要件や仕様の詳細をすべて決めてから開発がスタートする開発手法です。このアプローチでは、開発が一度スタートすると、「前の工程には戻らない」ことを前提に各工程を完了させ、一気通貫で開発を終えます。

この手法のメリットは、それぞれの工程のスケジュールが明確なため、どのタイミングで、どれくらいの人的・技術リソースを投下すべきなのかを判断しやすい点があります。一方でデメリットは、企画や要件定義を入念に行ってから開発を行うため、開発を始めるまでの作業期間が長期化しやすいという点が挙げられます。

アジャイル開発とは、作りたいシステムを大まかに決めた後すぐに開発工程に移り、「計画、設計、実装、テスト」を繰り返しながら開発を進める手法です。これは、ウォーターフォール開発よりもスピーディーに開発を行い、システム導入や市場投下を行いたい状況に適しています。但し、アジャイル開発は各工程を細かく切り分けることが少ないため、スケジュールや進捗管理が難しいという欠点があります。

ウォーターフォール開発はこれまで王道とされてきた手法であり、アジャイル開発はよりスピーディーな手法として近年注目されています。しかし、そのオペレーションには高いマネジメント能力を持ったマネージャーの存在が不可欠となります。

     

要件定義・仕様書の作成方法・手順について

要件定義の仕様書は、大別すると「業務」と「システム」の2つの項目に分かれます。前者は、プロジェクト概要や目的、納期、指標が主な内容になります。補足事項としては、クライアントの現状、進捗まで随時記載されている場合もあります。

後者は、機能面と非機能面、それぞれに言及します。開発チームが手がける管理画面やインターフェース、データなどは「機能面」に該当します。

一方、「非機能面」は主にユーザビリティや満足度をはじめ、クライアントのITリテラシーや引継ぎ情報などソフト面の情報が多くなります。現状のOSやバックアップ体制、今後の保守やメンテナンスについてもしっかり記載することが大切になります。

実際の要件定義書は以下の4つの内容で構成されることが多いです。

    

1. システム概要や背景・目標

顧客のニーズを開発者との認識の相違が生じないように再確認します。ここでは、顧客の具体的な要求定義を行い、明文化することが求められます。

例えば、システム化の背景としては「システム化が未着手の○○業務の効率化」「○○システムと基幹システムとのデータ連携」などが想定されます。

さらにシステム導入によって達成できる目標やメリットを詳細に示すために、「ビジネスフロー・業務フロー図」の作成を通じて、システム完成時に、関係部署やシステム関係がどのように配置されるのかを図示することがお勧めです。その際には、各チームの細かい業務手順まで盛り込めるとさらに良いです。

     

2. システムの具体的な機能

次に、ユーザーから求められている機能を説明します。主に機能要件が記載されます。機能要件としては、「システム方式」や「バッチ要件」、外装部分の「画面要件」「外部インターフェース要件」なもが含まれます。

「システム方式」とは、システムの稼働環境を整理した図表の総称であり、ハードウェア構成図、ソフトウェア構成図、ネットワーク構成図、アプリケーション機能構成図の4つをまとめたものです。

また、「バッチ要件」は見積もり時に非常に大事にあるため、事前に正しく合意することが大切です。処理の複雑度は、見積もり価格を大きく左右するため、想定される入出力ファイル数や項目数について、開発側・ユーザー側でお互いに概算についてすり合わせておくと良いでしょう。

     

3. システム導入後のフォロー・非機能要件

システム導入後、ユーザの業務変化に対応するためのフォロー・非機能要件についても要件定義では明文化することになります。具体的には「拡張性」「運用・保守」「セキュリティ」「システム環境・移行性」など非機能要件について記載されることが多いです。

    

要件定義の参考となる資料

要件定義の際に参考となるのが、その前段階として作成されるRFPやRFQです。RFPは日本語で提案依頼書、RFQは見積もり依頼書と訳されます。また、企業によってはRFQが要件定義の仕様書と同じような位置づけで扱われている場合もあります。

企業はITシステム等の導入を行うにあたって、事前に、RFP・RFQを通じて開発先事業者の選定を行います。そのため、これら資料にはシステムの目的や概要、要件や制約条件など顧客の要望や、その後の合意ポイントが記されています。

RFP・RFQの詳細については、こちらをご参照ください。

RFQ(見積依頼書)は調達・購買戦略に欠かせない!RFIやRFPとの意味の違いやテンプレート、書き方のポイントとは? | Leaner Magazine|リーナーマガジン

さらに、官庁やJPAが公開しているシステム仕様書を参考にするのもお勧めです。これらには、業務要件・機能要件・非機能要件が細かくまとめられています。

国土交通省『建設キャリアアップシステム 要件定義書』

IPA『システム開発調達仕様書(ひな形)』

   

近年、調達・購買活動においても”要件定義”が重要になっている

これまで、要件定義はITベンダーへのシステム発注において行われることが多かったです。

しかし、近年日本企業のコスト意識が上がり、調達業務がより戦略的に行われるようになりつつあります。

調達活動において、”要件定義”と言われる作業は、ユーザー部門が出してきた要求に対して仕様やコスト面、オプションなどもろもろ含めた条件を決めることを指しています。

この場合、条件・オプションを考察する作業は、ITシステムに限らず、見積を取るすべての費目に対して発生します。また、購買部門が直接要件定義を担当する場合もあれば、現場の人間が個別で担当することもあります。

これら日常業務に関わる様々な費目に対する要件定義は、状況によって要求する仕様が変わることが多々あるので、柔軟に対応することが大事になります。そのためにはサプライヤーと頻繁にコミュニケーションを取ったり、社内のユーザー部門とのコミュニケーションが重要となります。

その際、調達、購買部門で実施する要件定義をベースとしつつも、QCDの観点で最も自社に最適なものを調達できるように雑務を減らし、比較検討の時間を作ることが大事になります。

調達業務全体の手順や戦略策定については、以下の記事をご参照ください。

調達とは?意味や購買との違い、企業における調達の重要性やコスト削減に繋げるノウハウを紹介 | Leaner Magazine|リーナーマガジン

またその際に、業務コストを減らす目的で調達活動をデジタル化するソリューションの導入も検討すると良いでしょう。

   

キャディ株式会社

キャディ株式会社では、製造業の受発注プラットフォーム「CADDi(キャディ)」を提供しています。このプラットフォーム上では、金属加工や産業機械の装置一式など様々な品目の自動見積や最適な価格での受発注を行うことができます。

QCDという観点でも、良品率・納期遵守率ともに99%以上の高い数値を記録しており、見積を最速2時間で取ることが可能です。特に製造業の調達コスト削減に貢献しています。

    

モノタロウ

株式会社MonotaROでは、事業者向け工業用間接資材・工場で使用する消耗品をインターネットを通じて販売する「モノタロウ」というサイトを運営しています。

多種多様な間接資材のニーズに応え、間接資材の流通の最適化を図るサービスとなっています。

    

Leaner

総金額の約8割を占めるMROや事務消耗品以外の間接材を最適な状態で調達するには、見積業務が必要不可欠です。

見積業務は工数が多く、属人的なものとなっていることが多いのですが、そのような業務を一括で管理してくれるのが、株式会社Leaner Technologiesの支出管理サービスLeanerです。

見積業務を含む調達活動全体を、一括でデジタル管理してくれるシステムです。詳しくはこちらから公式ホームページをご覧ください。

     

終わりに

企業のDXが進む中で、システム開発やソフトウェア導入を始め、要件定義書の作成する機会は著しく増加しています。

DX戦略の推進や、ITシステム・ソフトウェア等、複雑なワークフローが伴う製品を発注する際には、ぜひこの記事を通じて要件定義に対する理解を深め、業務に活かして頂けたら幸いです。

RECOMMEND

こちらの記事も人気です。