「要件定義」の重要性と基本的な進め方

要件定義の重要性

2018年に経済産業省が発表した「DXレポート」の中では、日本国内企業がデジタル変革（DX）を推進しなければ、彼らの競争率は低下し、2025年からの3年間で約12兆円の経済損失が出ると予測されている。その理由としては、日本企業が保有している基幹システムやソフトウェアが「レガシーシステム」となり、新たなビジネスモデルを創出することが困難であることなどがあげられる。デジタル変革に対応・順応するため、DX化に向けたITシステムの刷新やIT人材の育成・確保に向けて取り組みを進めている企業も多いが、ITシステム開発の際に、品質不備、予算超過、納期延期の問題が発生している。問題の根本をたどると、システム開発の上流工程とされる「要件定義」でのユーザーとシステム開発担当者との認識齟齬が、下流工程のシステム開発に影響を及ぼしていることが原因の1つである。「要件定義」の段階で十分な検討と合意形成を行うための時間とリソース確保が、システム開発プロジェクト成功のカギである。

今後、ITシステムの刷新に向けた動きが加速することが予測されるが、システム開発の実践経験が少なく要件定義を基礎から知りたいという方に、改めて「要件定義」の重要性と進め方をお伝えしたいと思う。

要件定義とは

一般的にシステム開発工程の最初に行われる工程であり、プロジェクトの成功に大きくかかわる要因の1つである。要件定義では、ユーザーの要望を実現することをゴールとしており、以下3つの要素が要件定義成功のカギとなる。

1. 1. プロジェクト関係者間で共通認識を持つ
   2. プロジェクトの方向性を明確化し、計画的に実施する
   3. 開発・設計前に要求実現に向けた潜在的な問題を認識し、対策する

特にプロジェクト関係者間での共通認識を持つことは、日本のシステム開発方法を鑑みると非常に重要である。欧米諸国では、システム開発を内製（ユーザー企業）で実施することが比較的多いが、日本では、「守りのIT」（ビジネスモデルを変えずに、ITによる作業効率化やコスト削減）が主流であるため、ユーザー企業がSI(System Integrator)企業にシステム開発・運用を委託する場合が多い。その結果、「重層下請構造」が形成されていき、案件関与人数が多くなる傾向にある。

システム開発関与者が多くなるにつれて、共通認識の統一化がしにくくなってしまう。案件関与者間での認識齟齬からの手戻り工程が発生し、品質・コスト・納期に影響がでてしまう。

一方で、日本独自のシステム開発を刷新すべく、DX化と併せて「内製化」に着目し、自社でシステムを開発できるような人材育成制度や環境を整え始めている企業も多くある。内製的にシステムを開発することで、「重層下請構造」を回避することは可能である。また、自社にシステム開発の知見を蓄積しつつ、外部委託コストを削減できるため、非常に注目されつつある。しかしながら、「内製化」にシフトしたとしても、システム開発工程の進め方は大きく変わらない。ユーザーの要求実現に向けたシステム化を予算・計画通りに推進するためにも、「要件定義」はシステム開発工程の中で非常に重要なフェーズであることは忘れてはならない。

要求と要件の違い

システム開発においてそれぞれ異なった意味を持つ「要求」と「要件」の明確な違いを理解する必要がある。様々なシステム開発方法がある中で、V字モデルを例にシステム開発工程を見てみたい。

 

一般的にシステム開発は上流工程から開始される。前述のとおり、要件定義はユーザーの要求を実現させることがゴールであるため、まずは要求定義フェーズにてユーザーの要求を抽出・整理し、その上でシステム化により要求が実現可能になるように要件として落とし込む。そのため、要求と要件は一致させる必要がある。

・要求：ユーザーの希望「～がしたい」を抽出、整理する

・要件：ユーザーの要求実現手段「～が必要」を定義する

要求定義と要件定義は前後関係にあるため、混在しやすいが上記定義を踏まえた上で各フェーズを進める必要がある。

要件定義の進め方

一般的に、要件定義は以下の図のように進める。

 

要件定義は大きく業務要件とシステム要件に分けられることが多く、それぞれを進める上で最低限必要なタスクを説明したい。

業務要件

• 現状分析

ユーザー要求実現に向けて、現状業務とのギャップを明確化するために、現状分析のヒアリングを実施する。

• 要求分析

ユーザーの要求をQCD(品質、費用、期間)の観点で整理し、実現可能なシステム化の範囲を決定するために、要求に優先順位をつける。

• 施策検討

現状業務とあるべき姿のギャップをどのように埋めれば、ユーザー要求を実現できるかを検討する。

システム要件

• 機能要件検討

新システムに対して、ユーザーが必ず搭載すべき機能の実現方法を検討する。機能要件はユーザーにとって必要最低限の機能であるため、システムに搭載出来ない場合は代替案を提案する必要がある。

• 非機能要件検討

ユーザーが必要とする機能以外のすべての要件を検討する。非機能要件は技術要素が強いため、システム開発側が機能実装時の具体的な影響をユーザーに伝え、予算等も考慮しながら必要項目を検討する。特に非機能要件は、ユーザーと共通認識を持つことが難しいため、一般的にはIPA（独立行政法人情報処理推進機構）で考案された「非機能要件グレード」を活用して、重要な項目からユーザーと認識合わせを実施する。「非機能要件グレード」は、大きく6つの項目に分かれる。

• • • 可用性

システムを継続的に利用可能とするため、運用スケジュールや災害時の稼働目標を検討する

• • • 性能・拡張性

システムの性能・拡張のため、業務量（ピーク時、通常時など）を検討する

• • • 運用・保守性

システムの運用・保守のため、運用中の稼働レベルや問題発生時の対応レベルを検討する

• • • 移行性

新システム移行のため、移行期間や移行資産の種類・量を検討する

• • • セキュリティ

システムの安定性を確保するため、利用制限や不正アクセス防止を検討する

• • • システム環境・エコロジー

システムの設置環境やエコロジーを要求するため、騒音などや消費エネルギーを検討する

• 運用要件検討

システム運用時の要求事項（運用スケジュール、適用範囲等）を、運用コストの概算が出来るレベルまで要件を詳細化する。また、運用時に発生する可能性のあるトラブルの対処法を事前に検討する必要がある。（コンティンジェンシ―プラン）

• 移行要件検討

移行に際し、追加工数やコスト、緊急事態が発生しないように移行計画を検討する。移行要件として、3つの観点（データ、システム、業務）での検討が必要である。

• • • データ移行

現状システムからの移行データの検討

データのレコード数（データそのもの）やテーブル数（データを入れておく箱）の件数把握

• • • システム移行

現行システムと新システムの切替タイミングの検討

他社との接続がある場合の切替方法の検討

• • • 業務移行

業務変更点の確認

要件定義における作成成果物

成果物の作成は「共通認識化」と「作業のエビデンス」として必要不可欠である。作成する成果物はプロジェクトの内容により判断する必要があるため、成果物判断には複数回の要件定義実践経験が必要とされる。以下は、一般的に要件定義フェーズにて作成される成果物の一例である。

業務要件での成果物

• • システム開発の概要
  • ステークホルダー関連図
  • 業務一覧
  • 業務フロー

システム要件での成果物

機能要件

• • 機能構成図・機能記述書
  • 画面・帳票一覧
  • 画面・帳票イメージ
  • I/F一覧
  • バッチ処理一覧
  • 非機能要件
  • 非機能要件書（IPA項目グレード参照）
  • HW、NW構成図

運用・移行要件

• • 業務運用要件書
  • 全体移行計画書

要件定義に必要なスキル

要件定義を実施するには様々なスキルが必要であるが、ここでは大きく４つに分けて説明していきたい。

コミュニケーションスキル

＜ヒアリングスキル＞

ユーザーより様々な意見を聞き出すための、効果的・効率的なヒアリングスキルが非常に重要である。また、ヒアリング準備をしておくことも大切である。網羅的にヒアリングをするためには、5W２Hをベースにヒアリングすることが効果的である。

What：何をシステム化するのか

Why：なぜシステム化したいのか

When：いつまでにシステムが必要なのか

Where：システム化の対象業務・範囲はどこか

Who：利用者は誰なのか

How：どのような機能をどのように実現したいのか

How much：予算はどれぐらいなのか

＜ファシリテーションスキル＞

要件定義フェーズではステークホルダーに応じて会議をコントロールするスキルが必要である。機能要件では、システム化に向けた専門用語等をユーザーにも理解できるように認識合わせをする必要がある。システム開発側のみが参加している会議のように進行してしまうとユーザーの理解度が追い付かなくなってしまう。会議参加者に合わせて会議を進めることで、認識齟齬が発生しにくくなる。会議中に認識齟齬がないかの確認をしながら会議を進めることもポイントである。

＜提案力スキル＞

課題に対するや対応案/代替案を提示できるスキルは、ユーザーの満足度と関係する。ユーザーの要求実現の妨げとなる課題の解決策の提案が重要である。

イメージを具体化できるスキル

＜システム化イメージを具体化できるスキル＞

ユーザー業務をシステムに落とし込んだ際の業務イメージを具体化し、ユーザーに説明できるスキルが必要である。ユーザーがシステム化のイメージがしやすくなると、システムが開発されてからイメージと異なるといった問題が発生しにくくなる。イメージを具体化するためには、ユーザーの業務やオペレーションを深く理解している必要がある。

ステークホルダー・リスク管理スキル

＜ステークホルダー管理スキル＞

システム開発プロジェクトに関わる職位や部署によって目的が異なるため、ステークホルダー間での共通認識化が必要である。以下、ステークホルダー間での目的の違いを理解した上で、コミュニケーションの仕方を変える必要がある。ステークホルダーのマネジメントスキルは、プロジェクトを遂行する上では欠かせない。

1. 1. 経営者：経営目的・戦略とプロジェクトの目的との整合性観点でKGIを意識している
   2. 業務部門：業務が効率化の観点でKPIを意識している
   3. PM/PMO：期間/予算内の観点でQCDを意識している
   4. システム部門：運用/保守のしやすさ観点でSLAを意識している
   5. SI企業：予算内に収まるかの観点で、見積を意識している

＜リスク管理スキル＞

予算や納期が決められているシステム開発では、何か問題が発生してから対応していると後手となり、予算・納期・品質のどれも担保できなくなってしまう。そのため、リスクとなりうることをあらかじめ予測するスキルが必要である。

ドキュメンテーションスキル

＜ドキュメント作成スキル＞

要件定義フェーズでは様々なドキュメントを作成する必要があるため、作成目的を明確化することが重要である。成果物一覧を紹介した際に述べたが、ドキュメントは「共通認識化」と「作業のエビデンス」を目的として作成する。基本的にはドキュメントをベースに議論・合意がなされるため、ドキュメントには「分かりやすさ」が求められる。読み手が理解できなければ議論が進まない。例えば、業務フローに記載されている業務のワードが不統一、業務の粒度が不揃いの場合、読み手は非常に読みづらく理解できない。ドキュメント作成の際には標準的なルールを設定することがまずは重要である。

失敗例

要件定義の失敗事例をいくつか紹介したい。各失敗の原因を理解することで事前に講じるべき対策をイメージできるため、一例をみていきたい。

・SI企業にシステム開発を丸投げ

上流工程より、SI企業にシステム開発を丸投げしてしまうケースがある。SI企業は、ユーザーの要求実現に向けたシステム化を予算内に納期することを目的としているため、ユーザーからの要求が抽象的であると、システム開発後にユーザーのイメージと異なったシステムが開発されることも発生してしまう。要件定義の内容に責任を取るのは、ユーザー企業であるため、丸投げは非常に危険である。ユーザーとシステム開発側の認識齟齬による手戻りは下流工程に行けば行くほどコスト・工数がかかってしまうため、十分なコミュニケーション・ヒアリングが必要である。

・過剰にニーズを受け入れてしまう

ユーザーの要求を全て実現しようとしては、ユーザーが予想している予算・期間での納品が出来ない可能性が大きくなってしまう。要求をすべて実装する場合に掛かる費用、納期を明確にし、想定内で収まらない場合は導入目的を考慮して、優先順位をつける必要がある。

・工数の見積不足

プロジェクトには必ず納期が定められているため、要求・仕様変更が発生した場合、対応すべき事項に優先順位をつけて対応しなければ、要件定義にて遅延が発生し、後工程に影響が出てしまう。WBS等を作成してスケジュールを詳細レベルで工数を管理する必要がある。

まとめ

「要件定義」とはシステム開発において上流に位置する工程であり、プロジェクト関与者間での話し合いを重ねながら、最終的にユーザーの要求を実現させられるようなシステム化の手段を定義することを目的としている。案件関与者間での認識齟齬からの手戻り工程はシステム開発において大きな損害(コスト/工数)となるため、システム開発初期の時点で共通認識の取れた要件を定義できるスキルは非常に重要である。本稿では、その第一歩として、システム開発経験の少ない方向けに要件定義の進め方も併せて記述した。

本稿が皆様のご参考となれば幸いである。

 

【参照】

• DXレポート「～ITシステム「2025年の崖」の克服とDXの本格的な展開～」
• 日経XTECH「ITプロジェクト実態調査2018」
• 日経XTECH「ベンダーと「ズブズブ」だけど「自律」したい、1000人調査で見えたDXの実態」
• AMELA「システム開発における要件定義の失敗事例を紹介！失敗しないコツも解説！」
• IPA「非機能要件グレード2018 改訂情報～初版との差異～」
• PRONIアイミツ「システム開発における要件定義とは？進め方や注意点、必要なスキルを紹介」
• 東洋経済「システム開発の肝｢要件定義｣はなぜ失敗するのか」

• 【UiPath Orchestrator】少ない工数でロボットを安定的に運用するための管理ツール