なぜ、莫大な投資をしてもDXは成功しないのか。その答えは、最新の技術力不足ではなく、プロジェクトの最上流である「要件定義」と「品質ガバナンス」の欠如にあります。

そこで本記事では、ITプロジェクトの成功率がわずか34%という過酷な現実を突破し、貴社を真のデジタル勝者へと導くDXコンサルタントの選び方を解説します。2026年の最新トレンドである「エージェント型AIの実装」から「内製化の具体策」まで、QualityCubeの知見を交えてその正解を明らかにしていますので、ぜひ最後までご覧ください。

【注釈】

• 自律的な実行（Agentic AI）のフェーズ：人間の指示を逐一仰ぐのではなく、AIが自ら目標達成のための推論をし、外部ツールやAPIを駆使してタスクを完遂する段階。
• エージェント型AIの実装：自律的な推論、計画、行動、および自己修正のサイクルをビジネスプロセスに組み込み、高度な業務代行を実現する仕組みのこと。

2026年DXコンサルの新基準：エージェント型AIが変える「実行」の定義

受動的な生成AIから「自律実行するAIエージェント」への転換

2026年のDXにおいて、AIはもはや「副操縦士（Copilot）」ではなく、特定の任務を完遂する「エージェント」へと進化しました。従来の生成AIがテキストの生成にとどまっていたのに対し、エージェント型AIはビジネスルールを解釈し、APIを介してERPやCRM、SaaSを直接操作します。この「推論（Reasoning）」と「行動（Action）」の統合が、業務自動化の限界を打ち破る鍵となっています。

ビジネス実装を阻む「PoCの壁」と誤りの累積（Error Accumulation）

しかし、多くの企業が「PoCの壁」を越えられずにいます。自律的に動作するAIエージェントは、一つの判断ミスが次工程のミスを誘発し、指数関数的にエラーが増大する「Error Accumulation（誤りの累積）」のリスクを孕んでいます。この微細なハルシネーション（幻覚）を抑制し、AIの行動に堅牢なガードレールを敷けるかどうかが、現代のDXコンサルタントに問われる真の技術力です。

2026年のコンサルに求められる「AI Factory」構築支援の役割

NVIDIAが提唱するように、現代の企業にとってAIは「購入するソフトウェア」ではなく「製造する資産」です。膨大なデータを入力し、価値ある知性を出力し続ける「AI Factory（AI工場）」を自社内に構築することが、2026年の競争優位性の源泉となります。有能なコンサルタントは、単なるツール導入ではなく、このデータパイプラインと計算リソース、そして品質管理が三位一体となった「工場」の設計図を描けなければなりません。

【注釈】

• AI Factory：コンピューティングリソース（GPU等）とデータ、AIモデルを統合し、原材料（データ）からインテリジェンス（知性）を生産し続ける次世代のデータセンターおよびインフラ概念。

ITプロジェクト成功率34%の衝撃：失敗の真因は「技術」ではなく「要件定義」にある

Standish Group「CHAOS Report」が示す、30年変わらない失敗構造

Standish Groupが長年発行している「CHAOS Report」は、ITプロジェクトの非情な現実を突きつけています。最新の調査によると、ITプロジェクトが予算・納期・品質のすべてを満たして成功する確率は約31〜34%に過ぎません。Standish Groupの「CHAOS Report」では成功率31%、PMI（プロジェクトマネジメント協会）の2024年報告書では34%とされており、30年以上変わらない停滞が続いています。驚くべきは、30年以上前から失敗の構造が変わっていないという点です。AIという魔法の杖を手に入れても、基礎的なプロジェクト管理が欠落していれば、成功への道は閉ざされたままです。

失敗要因のトップは「不完全な要件」と「ユーザー関与の欠如」

同レポートによると、プロジェクトが頓挫する最大の要因は「不完全な要件定義」と「不明確な目標」です。「最新のAIエージェントを導入したい」という手段の目的化が進む一方で、そのAIが「具体的にどの業務を、どの程度の精度で、誰の責任のもとに代行するのか」という定義が疎かになっています。技術的な難易度よりも、合意形成の不備がプロジェクトを崩壊させるのです。

技術力不足（5位）を懸念する前に見直すべき「上流工程」の重要性

「最新技術を使いこなせるエンジニアがいない」という悩みは、失敗要因のランキングでは常に下位です。真の問題は、最上流で「何を、なぜ作るのか」を言語化できないことにあります。「Garbage In, Garbage Out（ゴミを入れれば、ゴミが出てくる）」の原則通り、曖昧な要件から生まれたAIエージェントは、企業に甚大なリスクをもたらす“ゴミ”を量産します。2026年のDXコンサルタント選びでは、技術スタック以上に、貴社のビジネス要求を精密な「仕様」へと昇華させる要件定義能力を重視すべきです。

【注釈】

• Standish Group「CHAOS Report」：ITプロジェクトの成功・失敗事例を統計的に分析した世界的な報告書。要件の不備が失敗の主要因であることを一貫して指摘している。
• Garbage In, Garbage Out：「不適切な情報を入力すれば、不適切な結果しか得られない」という格言。AI時代においては、低品質な指示やデータが低品質なAIの行動を招くことを指す。

「シフトレフト」がもたらす破壊的ROI：品質をプロセスに組み込む品質工学の実装

下流のバグ潰しから「上流での品質作り込み」へのパラダイムシフト

開発の最終段階で不具合を発見・修正するコストは、要件定義段階で修正する場合の100倍に達することもあります。この経済的損失を回避するために提唱されるのが「シフトレフト」です。テスト工程を開発の「左側（初期段階）」へ移動させ、企画や要件定義の段階から品質保証（QA）の視点を介入させることで、手戻りを最小化し、ROIを劇的に向上させます。

V字モデルの左側にQAが介入する「要件定義代行」の破壊力

QualityCubeは、このシフトレフトを極限まで追求した「品質工学（Quality Engineering）」を実践しています。単にコードをチェックするのではなく、仕様書が書かれる前から参画し「要件の漏れ」や「論理的な矛盾」を科学的な手法（IEEE標準等）に基づいて排除します。この「要件定義代行」とも言える徹底した上流介入が、2026年の複雑なAI実装プロジェクトを成功へと導く最短ルートです。

2026年の実装に不可欠な「検証ループ（Verification Loops）」の構築

エージェント型AIにおいては、外部情報の検索を行う「RAG」や、AIが自己修正をする「エージェンティックループ」の挙動を常に監視・検証する必要があります。QualityCubeは、内側のループ（推論・行動）と外側のループ（評価・改善）を統合した「検証ループ（Verification Loops）」を設計段階から組み込みます。これにより、AIが自律的に動きながらも、常にビジネス上の許容範囲内に収まる「信頼できるAI」の実装が可能となります。

【注釈】

• 検証ループ（Verification Loops）：システムが要求を満たしているかを確認し、偏差があれば即座に修正・フィードバックをする循環的な品質保証プロセス。
• シフトレフト：開発プロセスの初期段階にテストや検証を前倒しすること。セキュリティや品質を設計段階から組み込む手法として重視されている。
• 品質工学（Quality Engineering）：製品開発の全工程において、ばらつき（不具合）を抑え、効率的に高品質を実現するための工学的アプローチ。
• RAG：検索拡張生成（Retrieval-Augmented Generation）。AIが外部ナレッジベースから信頼できる情報を検索し、それを踏まえて回答を生成することで、ハルシネーションを抑制する技術。
• エージェンティックループ：AIが「計画→実行→結果の観察→再計画」という自己改善プロセスを繰り返す実行構造のこと。

2026年に選ぶべきパートナー：QualityCubeが実現する「自走する組織」の作り方

IPA「デジタルスキル標準（DSS）」準拠のQualityRoomによる法人教育

外部コンサルタントに依存し続ける構造は、企業のスピード感を削ぎ、コストを増大させます。QualityCubeが提供する「QualityRoom」は、IPAの「デジタルスキル標準（DSS）」に準拠し、現場のDXリーダーを育成する教育支援サービスです。単なる知識の習得ではなく、2026年のDX現場で即戦力となる「要求定義」や「QCD管理」のスキルを体系的に提供します。

企業の課題に最適化されたカスタム研修と「QualityAdapt」による人材供給

QualityRoomのカリキュラムは、企業の業務特性に合わせて柔軟にカスタマイズ可能です。さらに、教育された人材を「QualityAdapt」を通じてプロジェクトへ供給することで、理論と実践のギャップを埋めるエコシステムを構築しています。自社の社員がQualityCubeのメソッドを直接学び、実践するプロセスを通じて、組織全体のデジタル・リテラシーを底上げします。

支援ではなく「卒業」：18ヶ月で内製化と自走力を確立する伴走モデル

私たちのゴールは、クライアントが私たちを必要としなくなる「卒業」の瞬間にあります。標準的な支援期間として約18カ月を設定し、その間に要件定義のノウハウ、品質ガバナンスの体制、および内製開発の文化を貴社へ定着させます。DXコンサルタントとして伴走しつつ、最終的には貴社が自ら「AI Factory」を運営し、自律的に変革を続けられる「自走する組織」へと導きます。

まとめ

2026年、DXは「最新技術を語る」段階から「品質を担保し、確実に実装する」段階へと移行しました。統計が示す通り、プロジェクトの成否は技術ではなく、最上流の「要件定義」と、それを支える「人」の質で決まります。

QualityCubeは、エージェント型AIがもたらす複雑な課題に対し「品質工学」と「要件定義代行」という確かな解を提供します。単なる外注先ではなく、貴社がデジタル変革を自らリードできる「内製化」のゴールまで、私たちはひたむきに伴走します。 「これ以上、PoCの壁に足踏みしたくない」とお考えのDX推進責任者様。まずは、貴社のプロジェクトの成功率を科学的に見極める「内製化・品質診断」から始めてみませんか。

システム開発において要件定義はもっとも重要なプロセスで、業務要件とシステム要件を明確に定義することが求められます。まず業務要件を定義し、その後にシステム要件を具体化しますが、システム要件は機能要件と非機能要件に分けて、それぞれ異なる視点からシステムを捉えます。

機能要件はユーザーのニーズに直接応える要素であり、システムが提供する具体的な機能やサービスのことを指します。一方、非機能要件はシステムの動作に関する特性や制約を定義し、システム全体の品質やユーザー体験に大きな影響を与える要素です。

本記事では、システム要件の一つである非機能要件にスポットを当て、非機能要件の定義やその重要性、国際標準等のフレームワークについて深く掘り下げていきます。また、非機能要件の抜け漏れに顧客が気づかないことが多い背景や、非機能要件がシステムにとってなぜ重要であるのかといったことも採り上げて、IT初心者にもわかりやすい内容を心掛けて解説していきます。

非機能要件とは？

非機能要件とは、機能以外の、システムの動作に関する特性や制約に影響するシステム全体の品質に対する要件のことですが、簡単に言えば、「システムがユーザーにとって“よい状態であること”に関わる要件」ということになります。

例えば、システムがユーザーにとって使いやすいこと、わかりやすいこと、誰かと同時に使っても一定の速度で動作すること、障害が起きにくいことなど、機能そのものではなくシステムそのものの「品質」に焦点を当てたものです。

要するに、「ユーザーがシステムで何ができるか」を定義する機能要件とは異なり、非機能要件では「システムがユーザーにとってどのようによいか」を定義します。

非機能要件はなぜ重要なのか？

非機能要件は、システム全体の品質及びユーザー体験を左右する重要な要素であることは先にお伝えしたとおりですが、このセクションでは、非機能要件がシステムにとってなぜ重要であるのかを詳しく解説します。

ユーザー体験の向上
非機能要件は、システムがどのように動作するかを決定するため、ユーザー体験に大きな影響を与えます。例えば、応答速度や可用性（システムやサービスがどれだけ利用可能であるかを示す指標）、使いやすさといった要件は、ユーザーがシステムを利用する際の満足度を大きく左右するものです。スムーズで快適な操作感が得られることで、ユーザーはシステムを継続的に使用し、ポジティブな評価をする可能性が高くなります。

信頼性と安定性の確保
システムがビジネスに与える影響は大きく、特に信頼性や安定性は極めて重要です。非機能要件を適切に定義することで、システムのダウンタイムを最小限に抑え、安定したサービスを提供することができます。これにより、顧客の信頼を得ることができ、長期的なビジネス関係を築くことが可能になります。

セキュリティの強化
現代のシステムでは、データの保護が不可欠です。非機能要件には、セキュリティに関する要件も含まれます。この取り決めにより、データ漏洩や不正アクセスを防ぐための対策が講じられ、顧客情報や機密データの保護が強化されます。安全なシステムは、顧客に対して安心感を提供し、企業の信頼性を高める要因となります。

パフォーマンスの最適化
システムのパフォーマンスを最適に保つことも重要です。特に、処理速度や負荷に対する耐性などは、システムが高負荷に対応できるかどうかを決定づけるため要注意です。パフォーマンスを最適化することにより、ビジネスの成長やトラフィックの急増に対しても柔軟に対応できるシステムを構築することができます。

メンテナンスの容易さ
非機能要件は、システムの保守性にも影響を与えます。この保守性や拡張性といった要件を考慮することで、将来的な改修や機能追加が容易になります。これにより、システムのライフサイクル全体にわたってコストを抑え、効率的な運用が可能になります。

法規制や業界標準の遵守
多くの業界では、特定の非機能要件が法規制や業界標準として求められています。これらの要件を遵守することは、法的な問題を回避し、企業の信頼性を維持するためにも不可欠です。適切な非機能要件を定義し、実装することで、リスクを軽減し、安定したビジネス運営が可能になります。

非機能要件はシステムの全体的な品質、つまり、ユーザー体験、信頼性、セキュリティ、パフォーマンス、メンテナンス性、さらには法規制の遵守に至るまで、多岐に影響を及ぼします。システム開発において、非機能要件は決して軽視してはいけない重要な要素であることがお分かりいただけたでしょうか。

非機能要件が顧客から出てこないこれだけの理由

機能要件は顧客が直接的に必要とするものですので、顧客からの要求という形で確認がしやすい一方、非機能要件は今まで見てきたとおり、システムの全体的な品質とユーザー体験に関わるものであるため、顧客自身が気づいていなかったり、わざわざ口にしなくてもわかっているはずぐらいの感覚になっているケースが非常に多く見受けられます。
このような状況は、実にさまざまな要因によって引き起こされますので、以下に、その理由と背景について詳しく解説します。

理由１：日常的に意識されていないから
顧客は、システムを使用する際、主に機能的な側面に焦点を当てることが多く、例えば、アプリケーションの使いやすさや機能の豊富さは明確に意識していますが、「応答速度」や「システムの安定性」といった特性は、顧客にとって直接的でなく、また目に見えないこともあり、日常的に意識されていません。このため、顧客が非機能要件について具体的な要求を持たないケースが多くあります。

理由２：経験則に基づいた期待だから
多くの顧客は、過去の経験から「当たり前」とされる非機能要件の基準を持っています。例えば、「Webサイトはすぐに開くべき」という認識はありますが、その具体的な数値（例えば2秒以内に表示されるなど）を示すことはあまりありません。このような期待は、言語化されずに暗黙の了解として存在するため、開発者側も顧客の具体的なニーズを把握しづらいといった側面があります。

理由３：言語化が難しいから
非機能要件はしばしば抽象的であり、明確な基準があるようでない（ここまでやればよいというものがない）ため、顧客が自分の要望を具体的に言語化することが難しいことが挙げられます。たとえば、「システムが速くなければならない」といった要求は、実際には「どの程度の速さが求められているのか」といった具体的な数値に落とし込む必要がありますが、多くの顧客はその数値を把握しておらず、結果として曖昧な表現に終始してしまいがちです。

理由４：ステークホルダー間で期待や要件が異なるから
プロジェクトに関与するステークホルダー（開発者、経営陣、ユーザーなど）によって、非機能要件に対する理解や期待が異なることがままあります。たとえば、開発者は技術的な視点から要件を評価し、経営者はビジネスの観点から要件を考慮しますが、実際のユーザーは利用時の体験から非機能要件を評価します。そのため、それぞれの立場で異なった期待があるのはもちろんのこと、それぞれのニーズが対立したり、矛盾したりするケースも発生します。このように、顧客自身も何が重要なのかを把握できないといった状況が生まれます。

理由５：後回しにされがちだから
要件定義では機能要件が優先されがちな傾向にあるため、非機能要件は後回しにされることが多く、顧客もその重要性を認識しづらいといった状態が発生します。そのため、機能が実装された後に非機能要件の不足が明らかになるケースが多く、顧客はその時になって初めて気づくといったことが、頻度高く起こります。

このような状況に対処するためには、開発者が積極的に顧客とコミュニケーションを取り、具体的な非機能要件を顧客から引き出す努力が必要不可欠となります。

非機能要件の基本的な項目

このセクションでは、非機能要件の基本的な項目をいくつか採り上げて、イメージできるように例をあげながら解説します。
（※国際標準のISOや、国内基準のIPA、デジタル庁が発行している定義については、「9. 非機能要件の様々なフレームワーク」のセクションで採り上げます）

性能要件
システムの応答時間や処理能力に関する要件です。例えば、ユーザーがボタンを押してから結果が表示されるまでの時間が短いことが重要な要件となります。

信頼性要件
システムが安定して動作し続けるかどうかを定義します。例えば、システムがダウンしないことや、障害が発生してもすぐに復旧できることが含まれます。

拡張性要件
将来的にシステムが利用者やデータ量の増加に対応できるかどうかを示す要件です。たとえば、ユーザーが増えてもパフォーマンスが低下しない設計が求められます。

セキュリティ要件
システムがどの程度安全であるかを示す要件です。たとえば、外部からの不正アクセスを防ぐことや、データを暗号化して保護することが含まれます。

保守性要件
システムのメンテナンスや修正がどれだけ簡単に行えるかを定義します。将来のバグ修正や機能追加に対応しやすい設計が求められます。

移植性要件
システムが異なる環境（例えば、別のOSやサーバー）に移行しても問題なく動作するかどうかを示す要件です。

機能要件と非機能要件の違い

このセクションでは、機能要件と非機能要件の違いを再度、確認します。機能要件は「ユーザーがシステムで何ができるか」を定義するのに対し、非機能要件は「システムがユーザーにとってどのように良いか」という点に焦点を当てています。以下に例を挙げます。

例えば、ログイン機能を例にすると、機能要件では「ユーザーがログインできる」という具体的な動作を定義しますが、非機能要件では「ユーザーが1秒以内にログインできる」「ログインが常に安全である」など、パフォーマンスやセキュリティに関する要件を定義します。

非機能要件の考慮不足によるリスク

このセクションで、機能要件の考慮不足により、どのような問題を引き起こす可能性があるか、について確認しておきましょう。

性能要件の考慮不足
ユーザーがシステムの操作に対して反応が鈍いと感じることにより、そのサービスから離れてしまう可能性がある。

セキュリティ要件の考慮不足
十分なセキュリティ対策がなされていないと、システムがサイバー攻撃を受けるリスクが高まる。

信頼性要件の考慮不足
信頼性要件が不十分であったため、システムが頻繁にダウンし業務に支障をきたす。

非機能要件を明確に定義するための流れ

このセクションでは、非機能要件を定義するための具体的な流れをSTEPに沿って解説します。

STEP1：プロジェクトの目的と範囲を理解する
プロジェクトの目標やビジネスニーズを把握し、どのようなシステムやサービスが提供されるか、また、システム化の範囲について明確にします。

STEP2：ステークホルダーにヒアリングを実施する
ステークホルダー（ユーザーや開発チームなど）からのニーズを収集します。ユーザーに対してはヒアリングを実施し、非機能要件に関連する期待や懸念事項を把握していきます。

STEP3：非機能要件の項目を定義し、項目ごとに考慮する
性能、信頼性、可用性、セキュリティ、拡張性などの非機能要件の項目を定義し、項目ごとに具体的な要件を考慮していきます。この時、ISO25010やIPA非機能要求グレードなどのフレームワークを活用すると抜け漏れが少なくなります。

STEP4：各非機能要件に対し、具体的な数値目標を設定する
各非機能要件に対して、可能な限り測定可能な数値目標を設定していきます。
例：レスポンスタイム2秒以内、稼働率99.9%以上など。

STEP5：非機能要件の優先順位付けを行う
非機能要件が満たされない場合のリスクを評価し、優先順位付けを行います。評価する際は特に、影響を受けるビジネスプロセスやユーザーへの影響度を考慮します。

STEP6：非機能要件をドキュメントに起こす
定義した非機能要件をドキュメント化し、明確で理解しやすい形式にまとめます。この時、テンプレートがあれば非常に便利です。

▲図１：非機能要件（サンプル）
https://www.ipa.go.jp/archive/files/000072715.pdf
P.65（1）共有基盤の項目例（データセンタあり、ネットワーク構築済）より抜粋

非機能要件の様々なフレームワーク

このセクションでは、非機能要件に関する国際標準や国内基準のフレームワークについて、わかりやすい説明を加えながら３つご紹介します。

非機能要件の抜け漏れを防止するためには、これらのフレームワークを導入するのが一番の近道となりますので、よく内容をご確認ください。また、実際のプロジェクトへの導入については、開発対象の製品やサービスの特性を考慮したうえで、最適な基準を選択するようにしてください。

ソフトウェア品質特性（ISO/IEC25010）（※機能適合性以外）

非機能要求グレード（IPA）

デジタル・ガバメント推進標準ガイドライン実践ガイドブック（デジタル庁）（※中分類は代表的なもののみピックアップしています）

非機能要件に関するよくある質問 (FAQ)

このセクションでは、本記事で記載しきれなかった非機能要件に関する事柄について、Q＆A形式で回答していきます。なお、この質問は、実際のコンサルティングのなかで、クライアントからよく頂戴する質問をまとめたものでもあります。

Q：非機能要件はどうやって計測しますか？

A：パフォーマンス要件や信頼性要件などは、具体的な数値目標を設定し、それに基づいて定期的にモニタリングすることで計測できます。
［パフォーマンス要件の目標例］
・レスポンスタイム：ユーザーのリクエストに対する応答が２秒以内であること
・スループット：１秒間に100件のトランザクションを処理すること
［信頼性要件の目標例］
・稼働率：サービスの稼働率が99.9％以上であること
・障害復旧時間：障害発生から復旧までの時間が30分以内であること

Q：小規模なプロジェクトでも非機能要件は重要ですか？

A：はい。小規模でも非機能要件は重要です。どのようなシステムでも、ユーザーの期待に応え、長期的に信頼されるためには、適切なパフォーマンスと信頼性が必要です。

Q：非機能要件を満たすためにどのようなテストが必要ですか？

A：パフォーマンステスト、負荷テスト、ストレステスト、セキュリティテストなどが必要となります。これらのテストにより、システムが非機能要件を満たしているかどうかを確認できます。ちなみにこの類のテストはシステムテストフェーズで実施する場合が多いです。

Q：どのようにして非機能要件の優先順位を決めるべきですか？

A：プロジェクトの目的からビジネスへの影響度を評価して決める方法と、ユーザーのニーズから狩野モデルを活用して決める方法の2通りがあります。ビジネスへの影響度が高い要件であること、あるいはユーザーが必須と考えている要件であることを確認しながら、実際の優先順位を決めていきます。

Q：顧客が非機能要件を明確に示さない場合、どうすればよいですか？

A：顧客とコミュニケーションを取り、非機能要件の重要性を説明することが第一歩です。具体的な例や過去のプロジェクトでの影響を示すことで、理解を促進していくことも重要です。

Q：顧客から非機能要件を引き出すためには、どのような質問をすればよいですか？

A：以下のような、具体的な質問が有効です。
・「どの程度の応答時間でしたら許容されますか？」
・「システムのダウンタイムについて、どのくらいの時間が許されますか？」
・「データセキュリティに関する特別な要求はありますか？」

Q：非機能要件を後から追加することはできますか？

A：可能ですが、後から追加した場合はプロジェクトが進行した分の手戻りが発生しますので、プロジェクトの進行やコストに影響する恐れがあります。
非機能要件は、最初の要件定義の段階でしっかりと確実に定義しておくことが重要となります。

さらに詳しく知りたい方へ

要件定義についての記事を複数アップしていますのでご紹介します。それぞれの目的に合わせて必要とする時にご一読いただければ幸いです。

▼要件定義で定義する３つの要件（業務要件・機能要件・非機能要件）を体系的かつ網羅的に解説したブログ

ブログ

合わせて読みたい要件定義とは│業務要件・機能要件・非機能要件を徹底解説

システム開発やソフトウェア開発のプロジェクト成功の根幹である要件定義について、体系的に把握できるよう品質コンサルタントの視点から網羅的に解説しています。...

▼要件定義の成果物に焦点を当て、例を挙げながら特に書き方についての詳細を解説したブログ

ブログ

合わせて読みたい良い要件定義書を書くには？重要ポイント・コツを伝授

システム開発成功の鍵は上流工程の要件定義。QualityCubeは要件定義スペシャリストとして、要件定義代行サービスを提供します。要件定義は発注者の要望を基にシステム要件へと落とし込み過程で詳細要件を定める工程です。　...

▼要件定義の要件の不備について詳しく解説したブログ

ブログ

合わせて読みたいシステム開発の要件定義とは│成功のもとは要件の不備をゼロにすること

要件定義では、知らず知らずに顧客の思い描いている絵と異なった絵を描いてしまうことがあります。これを本文では「要件の不備」として説明しています。本記事ではシステム開発の最初の入り口で躓かないための要件定義の基本について解説していきます。...

▼要件定義をサラッと復習したいときに読むブログ

ブログ

合わせて読みたいIT要件定義の実践入門 │ ポイントをやさしく解説

要件定義はITプロジェクトの成功において最も重要なステップですが、難易度が高く苦手とする方も多いのではないでしょうか。 本稿では、ITの要件定義を進める上で大切なポイントについて、初心者目線でやさしく簡潔に解説していきます。...

▼要件定義の前フェーズで定義する要求定義について網羅的に解説したブログ

ブログ

合わせて読みたい要求定義│要件定義との違いや品質を高める進め方・書き方まで網羅的に解説

システム開発の要求定義について、要求定義書と要件定義書・RFPとの違いから品質を高める要求定義の進め方・書き方、記述内容に至るまで網羅的に解説します。よいシステムを開発するには、考え方や進め方も含め、目的に合わせて変化していく必要があります。...

まとめ

非機能要件は、システムの性能、信頼性、セキュリティなどに関わる重要な要素であり、ユーザー体験やシステム運用に大きな影響を与えるものです。これらの要件が明確に定義されていない場合、システムはユーザーの期待に応えられず、結果としてプロジェクト全体に大きなリスクが及ぶ可能性があります。この点はご理解頂けたことと思います。

また、顧客が非機能要件を明確に示さない（示せない）理由には、理解不足やその重要性が軽視される傾向を挙げ、この問題の解決に向けては、「顧客を理解したうえで、顧客に対して開発側から非機能要件の重要性をわかりやすく説明し、具体的な項目を提示すること」が、もっとも効果的な進め方となることも、お伝えしてきたとおりです。

さらに、非機能要件を抽出するためのフレームワークや、明確に定義するための具体的な流れを取り入れることで、プロジェクトの成功確率を高めることができること、また、最後のFAQのセクションを通じて、一般的な疑問を解消するなかで、非機能要件に対する理解をより深めていただけたのではないかと思います。

結論、非機能要件はシステム全体の品質を左右するものであるため、堅実な要件定義とその実装が求められます。今後のプロジェクトにおいて、ここまで本記事でお伝えしてきたことをご活用いただき、今まで以上に非機能要件を考慮し確実に抽出することで、より高品質なシステム構築を目指していただければと思います。

QualityCubeでは、最上流の企画/要求定義工程から下流のテスト工程まで、プロダクト分析とプロセス分析による現状分析や品質コンサルティング、更にはDXコンサルティングも行っております。開発製品やサービスの品質向上や品質改善、その他DXに関することでご課題やご検討中のことがございましたら、ぜひお気軽にご相談ください。

ご相談は無料で承っております！

要件定義代行支援サービスは、こんな課題をお持ちの方をサポートします！

・要件定義工程の外注を検討している
・要件定義のできる経験者のリソースが不足している
・要件定義がうまくいっていないと感じている
・要件定義の担当者が少ないため、プロジェクト受注を断念するケースがある

なお、ブログの最新リリース情報につきましては、当社メルマガでリアルタイムにご確認いただけますので、本記事がよかった、ためになった、という方はぜひ、メルマガ登録もお願いします。

最新IT情報やお役立ち情報をコンサルタントが配信中！

企業の業務改善や効率化といえば、まずは業務フロー図の作成が思い浮かぶ方、また実際に作成経験がある方も多いのではないかと思いますが、せっかく手間暇をかけて作っても何故か分かりづらかったり、実態に合わず使えなかったりといった問題が起こりがちです。

本記事では、業務フローの基本的な作りかたを知りたい方や、初めて業務フローを作るが何から始めたらよいか分からないという方へ向けて、どのようなステップを踏み、どのようなポイントを押さえて作成するのがよいか、やさしく解説していきます。 

業務フロー図とは

業務フロー図とは、業務の流れを図で表したものです。例えば、コンビニで商品を買うときの流れを考えてみましょう。 
まず商品を選び、レジに持っていきます。 次にレジで値段を確認し、お金を支払います。 最後にレシートと商品をもらい、お店を出ます。これをおおまかに図に起こしてみると以下のようになります。 

このように、ある仕事のステップを図形や矢印で図式化したものを業務フロー図と呼びます。業務フロー図を作ることで、業務の流れがひと目で分かるようになるだけでなく、手順に無駄や問題がないかチェックするのにも役立ちます。 

なぜ業務フロー図が必要なのか

業務フロー図を作成する目的は企業によって様々ですが、業務の流れや関係を図で表すことで、業務の理解や共有、改善などを促進できるというのは大きな利点です。業務フロー図作成のメリットとしては、主に以下が挙げられます。 

• 業務の全体像や課題が分かりやすくなる 
• 業務の効率化や品質向上のための改善策が見つけやすくなる 
• 業務の標準化や統一化が進めやすくなる 
• 業務の責任や権限が明確になる 
• 業務の教育や研修が効果的になる 

業務フロー図は、業務の可視化や共有のツールとして、業務改善や改革の推進に大いに役立つほか、業務の効果や成果を測定し、評価することもできます。また業務の目的や意義を明らかにすることで、仕事のモチベーションや満足度を高めることにも寄与します。 
したがって、業務フロー図を作成することで様々な恩恵を受けることができると言えます。 

業務フロー図の作成ステップ

それでは実際に業務フローを作成するにあたって、どのような手順で着手していくのがよいでしょうか。
想像でなんとなく作ることはおすすめできません。作成者本人にしか理解できなかったり、実態と異なるものになってしまったりする可能性があるからです。
以下のような大まかなステップに沿って進めることで、効率的かつ分かりやすい、実態に即した形に作成することができます。順番に見ていきましょう。

STEP1　目的を明確にする

最初に目的や論点を明確にすることで、業務フロー図の作成範囲や方向性を決めることができます。目的や論点を明確にするためには、関係者の意見や要望を聞くこと、業務の現状や課題を分析することが有効です。 

STEP2　業務の調査・関係者の洗い出し

目的が決まったら、業務に関係する担当者や部署、クライアントなどの利害関係者を洗い出します。そしてこれらを、スイムレーンと呼ばれる軸に分けて図に配置します。スイムレーンは、業務フロー図の枠組みを作るための重要な要素です。 

STEP3　作図ルールを決める

業務フロー図の記号や線の意味や使い方は統一してください。 ルールを設定することで、業務フロー図の見やすさや分かりやすさを高めることができます。 
ルールを設定する際には、特に以下の点に注意しましょう。 
 
・記号の種類は最低限にする 
・矢印は上から下、または左から右に進むようにする 
・線は重ならないようにする 
・記号と記号の間に一定の間隔をあける 
・正しい記号を使う

ルールを設定することは、業務フロー図作成の前提となる重要なステップです。 ルールを設定することで、業務フロー図の可視化や共有、課題の洗い出し、改善策の検討などがスムーズに進められます。 

STEP4　作図

まずはざっくりとでも良いので全体像を書き出してみて、その後、徐々に細分化していくのが良いでしょう。そのうえで、どの作業を業務フロー図に記載するかを決めていきます。 
タスクや処理を時系列に並べ、各タスクや処理に適切な図形を割り当て、矢印で繋げて業務の流れを表現していきます。

STEP5　レビュー（検証、修正）

作成後に、適切なレビューを行うことで業務の改善や品質向上につながります。フローに誤りや不備、無駄なプロセスがないかを確認し、結果を分析することで問題点や改善点を洗い出し、必要なアクションを明確にします。修正を行った後は、レビュー結果のフィードバックが反映され、問題が残されてないことを再度確認してください。 

STEP6　公開・共有

作成して終わりではなく、完成した業務フローをメンバー間に公開・共有することも忘れてはいけません。 
関係者全員がいつでも閲覧できる場所に格納し、関係者に共有しましょう。 

なお、業務フローのさらに詳細な作り方や、使用する記号などの具体的な作図方法については、無料のダウンロード資料で解説しておりますので、ぜひこちらをダウンロードし参考にしてください。 

作成時に気を付けたいポイント 

業務フロー図の作成時に気を付けたいポイントもご紹介します。この4つのポイントをおさえることで、業務フロー図の完成度がぐっと高まります。 

POINT1　シンプルに 

良い業務フローの最大条件とは、パッと見て内容が分かりやすいということです。 
そのためには、できる限りシンプルに作ることを心がけてください。複雑なフロー、長いフローは1ページにおさめるよう、業務を区切りのいいところで分割して作図しましょう。

POINT2　プロセス（開始・終了・分岐）を明確に 

業務の流れを分かりやすくするために、開始・終了・分岐の条件は明確にしましょう。なにをきっかけとして開始するか、どうなることで終了するか、作業の分岐の発生条件は何かを明記することで、迷いのない業務フロー図になります。 

POINT3　適切な粒度で

 目的や用途に合わせた適切な粒度で作成しましょう。細かすぎても複雑になり、見やすさが損なわれます。逆に粗すぎると抽象的になってしまい、内容や関係性が分かりづらくなります。適切な粒度に統一するには、たとえば担当者や使用する媒体ごとに図形を分ける、一連の入力作業は1つの図形にまとめるなどの工夫が効果的です。 

POINT4　変更管理を徹底 

一度完成した業務フロー図も、プロセスや業務の変更に伴って更新が必要になることがあります。そのため、変更履歴を管理し適宜フロー図を修正・改訂することが大切です。常に最新の情報が反映できていれば、実態に合わず使えないといった問題を防ぐことができます。 

さいごに

さて、ここまで業務フローの作り方について解説してきましたが、いかがでしたか？ 
良い業務フローを作成するには、ご紹介したようなしかるべき手順を踏み、重要ポイントを押さえておくことはもちろん、基礎的なものから自社の業務にあわせた形にカスタマイズする必要があるかと思います。 
 
弊社QualityCubeでは、複雑な業務フロー図の作成にお困りの企業様に向けて、以下のサービスをご用意しております。 

◆業務フロー作成代行サービス 

QualityCubeでは、業務フロー作成代行を承っております。
プロのコンサルタントがていねいにヒアリングさせていただいた上で、貴社の業務改善やシステム導入をサポートいたします。 
まずは無料相談からでもお気軽にお問い合わせください。 

◆Web講座：業務フロー作成コース

QualityCubeが運営するIT人材育成プラットフォームQualityRoomでは、 eラーニングを用いて業務フロー作成の実践的な研修を開催しております。受講お見積り等、お気軽にお問い合わせください。 
 

要件定義とは

　いきなりですが、問題です。

要件定義とは、読んで字のごとく「要件」を「定義」することではありますが、何の要件をどのように定義するのでしょうか？

・・・・・

・・・・・

・・・・・

「顧客が要求する事柄を、「業務要件」「機能要件」「非機能要件」として定義する」 これが正解です。

　要件定義では、顧客が要求する事柄を「業務要件」「機能要件」「非機能要件」として定義するうえで、さまざまな情報を整理するだけではなく、決まっていないことを決めることが重要です。

要件定義は「理想」

　要件定義の前工程では要求定義を行い、後工程では基本設計を行いますが、それぞれの工程で行うことを以下のように捉えると、要件定義の理解が深まります。

要求定義＝「夢」
要件定義＝「理想」
基本設計＝「現実」

　つまり、要件定義はまだ「理想」の域を出ておらず、システム化に向けて実現可能性の検討はするものの、システムでは実現できない内容も多分に含まれている可能性があります。

なぜ要件定義は重要なのか

品質は要件定義を含む上流工程が決め手となる

　上図は開発手法の一つであるウォーターフォールモデルをＶ字で表したもので、通称「Ｖ字モデル」と呼ばれるものです。

　このＶ字モデル左側の上流工程で品質が作り込まれることより、品質の良し悪しの9割は上流工程に委ねられます。
その中でも要件定義工程で作成した要件定義書は開発の起点となるインプット情報となるため、要件定義の出来栄えがシステムの品質を決定づけるのです。
　
　では、なぜそれほどまでに要件定義を含む上流工程が重要になってくるのでしょうか？
その重要性については、以下の2点に要約されます。

大幅な手戻りを防ぐため

　要件や仕様の不備や考慮もれは、発見が後工程になればなるほど修正コストが増大します。
よって、要件定義での不備や考慮もれをなくすことに注力することは、プロジェクト成功に直結します。

認識齟齬によるトラブルを防ぐため

　「何のために」「誰が」「どのように」使うのかを明確にしないままシステム開発を進めてしまうと、顧客の要求を満たすことができないうえ、場合によってはクレームやトラブルにまで発展してしまう恐れがあります。
　よって、要件定義で顧客の要求を十分に引き出し、要件を適切に決めて顧客と合意し、認識齟齬をなくすことが、なにより重要なこととなります。

COFFEE BREAK：考慮もれを防ぐ3つの視点

　「繰り返し何回も確認をしているのに、なかなか考慮もれが防げない・・・」そのような場合は、以下の3つの視点で自問自答してみてください。

「本当にそうなのか？」と事象を疑う視点
「どうしてそうなるか？」と理由や要因を探る視点
「つまりどういうことか？」と整理・要約する視点

　ついついその物事や事象自体に囚われてしまいがちになりますが、「ほんとに？」と事象を疑い、「どうして？」と理由や要因を探り、「つまり？」で整理・要約することで、物事の本質に迫ることができ、結果的に考慮もれを防ぐ手立てとなります。
ぜひ実践してみてください。

不具合修正コストからみた要件定義の重要性

さて、以下のグラフを見たことはありますか？
このグラフは、「1：10：100の法則」と呼ばれ、不具合の発見が遅れれば遅れるほど、プロジェクトのコストは高くなり、時間も浪費してしまうことを表しています。

　このグラフからも、早期に不備や考慮もれ（＝不具合）を発見しておくことが大切であることがわかり、品質のよい要件定義を作成することの重要性が示されています。

システム開発における要件定義の位置づけ

　システム開発では、進捗状況の把握や成果物を明確にするため、工程を分けて段階的にプロジェクトを進めていきます。
下図を利用して、ウォーターフォール型開発手法のＶ字モデルで要件定義の位置づけを示します。

　各工程で、それぞれ目的に沿った成果物を作成していきますが、要件定義の工程で作成する成果物が要件定義書です。
なお、要件定義書のインプットとなるドキュメントは一つ前の工程で作成する要求定義書（要求仕様書ともいう）です。

要件定義の全体像

　要件定義は、「業務要件」「機能要件」「非機能要件」で構成され、この3つの要件が揃うことで初めて「要件が網羅的に定義できた」ということになります。
まずは、要件定義の基本的な流れから見ていきます。

【目的・背景】
なぜ必要なのか？誰が何をしたいのか？ということを「WHY」「WHAT」「WHO」に着目して目的・背景を明確にしていきます。

【業務要件】
業務やサービスの「HOW」に着目し、「誰に対してどのように使われるか？」という問いが顧客の要求に対応できていることを確認します。
この部分を明らかにするために、システム化の対象となる業務を洗い出し、業務フローなどで分かりやすく表現していきます。

【機能要件、非機能要件】
業務要件をインプットとして、システム化に必要な機能や性能等を洗い出し、「どの部分をどのようにシステム化するか」といったシステムで実現するための具体的な手段を「機能要件」および「非機能要件」として定義していきます。

要件定義のプロセス

　「よいプロセスからはよいプロダクトが生まれる」といわれるように、要件定義にも基本となるよいプロセスがあります。
詳細については、後ほど「要件定義の基本プロセス」の章で各ステップに分けて解説します。

要件定義のポイント

　要件定義を成功させるうえで、必ず押さえておくべきポイントとなる部分があります。
この章ではそのポイントに焦点を当てて解説していきます。

要件定義のポイント①　背景の詳細化

　背景については、詳しければ詳しいほど要件定義を進める上でのヒントとなりますので、できるだけ詳しく調査し、詳細化しておくことが望ましいです。

また、背景の調査と同時に環境分析を行っておくことも重要です。
業種業界を理解せず、要件を決めることはできないと心得ましょう。

要件定義のポイント②　目的の明確化

　目的は、より具体的に、より明確にしておきましょう。
要件定義で迷ったとき、わからなくなったとき、悩んだときのブレない軸となります。

要件定義のポイント③　スコープの明確化

　システム化の対象となるスコープ（範囲）が定まらなければ、システム開発というプロジェクトは定めようがありません。
しかしながら、スコープが曖昧なまま要件定義を進めてしまっているケースが意外と多いのが事実です。
　スコープは要件定義を始める前に明確に決めること。この点も必ず押さえましょう。

要件定義のポイント④　ヒアリング

　要件定義ではヒアリングスキルも重要になります。
ここでは幾つかの実践方法をご紹介します。

業界特有の業務フローに対しての理解を深める

　先に説明しました①背景の詳細化で、顧客の業種業界の理解の重要性に触れましたが、ヒアリングにおいても同様のことが言えます。
　業界によってはその業界特有の業務フローがありますので、それがわかっているとヒアリングがとてもスムーズに進みます。　

　業務フローがその業界特有のものであったとしても、顧客はそのように感じていないことが多いため、わざわざ口にしないことがあります。
その理解が不足していた場合は考慮のしようがなく、後々になって不具合として発覚するといった 事態に陥ります。
　そのようなことにならないよう、事前に業界特有の業務フローに対する理解を深めたうえで、業務上の特性を丹念にヒアリングできるように準備しましょう。

インタビューをしてはいけない

　ヒアリングをしているつもりで、実はインタビューをしてしまっている場合があります。
この場合、情報収集はできているかもしれませんが、真に必要とする情報が収集できていない可能性があります。
　まずは、インタビューとヒアリングの違いから見ていきましょう。

　 
　要件定義では顧客から情報収集することが重要であるため、質問をする機会が多くなります。
その質問ではインタビューではなくヒアリングができるように、「目的に沿った質問になっているか」「目的を明らかできたか」といったことに注意を払いましょう。

 オープン・クエスチョンとクローズド・クエスチョンを組み合わせる

　ヒアリングでは多くの質問を投げかけますが、状況や聞きたい内容に合わせて質問方法を使い分けることができるようにもしましょう。
質問方法には以下の2つの方法があります。

5W2Hのフレームワークで抜けもれをチェックする

　5W2Hはあらゆるビジネスシーンで使えるフレームワークですが、何かを解決をしたい場合の抜けもれチェックに使うことができます。
要件定義では、ヒアリングや要件を決める場面で用いることで、抜けもれの防止効果が見込めます。

例えば、要件を決める場面にて、

WHEN＝いつ使うのか？（タイミング）
WHO＝誰が使うのか？（使用者）
WHAT＝何に使うのか？（目的・用途）
WHERE＝どこで使うのか？（環境・状況）
WHY＝なぜ使うのか？（理由）
HOW＝どのように使うのか？（使い方）
HOW MANY＝どのくらい使うのか？（頻度・数量）

というように、5W2Hのフレームワークを活用して要件の抜けもれチェックを行うとよいです。
ちなみに使い方として、「WHAT（目的・用途）」「WHY（理由）」「WHO（使用者）」を確実に押さえてから、残りの「W」と「H」を考えるようにすると、より効果的です。

ヒアリングは最低でも2回は実施する

　ヒアリングは最低でも、現状の姿（As-Is）を確認するヒアリングと、あるべき姿（To-Be）を導き出すヒアリングの2回は実施することです。
　現状の姿（As-Is）とあるべき姿（To-Be）の確認を1回のヒアリングでまとめようとすると、現状（As-Is）の話とあるべき姿（To-Be）の話が、どのときの話であったかがわからなくなったり、必要な情報を聞きもらしてしまったりといったことが起こり得ますので、ヒアリングは必ず 現状の姿（As-Is）とあるべき姿（To-Be）に分けて行いましょう。

1回目のヒアリングで現状の姿（As-Is）を確認する

　1回目は、現状の姿（As-Is）についてのヒアリングを実施します。
このヒアリングを行う目的は、現状の業務や課題の確認がメインとなります。
確認したのちに「現状の業務フロー（As-Is業務フロー）」と「課題一覧」を作成します。

2回目のヒアリングであるべき姿（To-Be）を確認する

　現状（As-Is）の確認が終わったら、2回目ではあるべき姿（To-Be）についてのヒアリングを実施します。
このヒアリングを行う目的は、あるべき姿の業務と要求の確認がメインとなります。
確認したのちに「あるべき姿の業務フロー（To-Be業務フロー）」と「要求一覧」を作成します。

要件定義のポイント⑤　間接的ステークホルダを見極める

　ステークホルダ（利害関係者）として、プロジェクトに影響を与える対象を洗い出す際、直接的には関係しないステークホルダの見極めが重要になります。
　そのステークホルダを間接的ステークホルダと呼んだりしますが、間接的であるが故、範囲が広く見極めが難しくなります。
　間接的ステークホルダを見極めるポイントとしては、プロジェクトに与える影響範囲を広い視点で捉え、プロジェクトへの影響度合いを考慮することです。

　また、直接的ステークホルダに関しても抜けもれがないか、注意深く確認を重ねることも重要です。
ステークホルダに抜けもれがあると要求の考慮もれが発生してしまいますので、ステークホルダの洗い出しと見極めについては、細心の注意を払って行いましょう。

要件定義のポイント⑥　業務フローは目的に適したレベルで作成する

　業務フローにはレベル感があります。業務フローを作成する時は、その作成目的や意図に応じてどのような粒度で業務フローを作成するか、といったレベル感を決める必要があります。

レベル0：最も粗いレベル。全体業務を俯瞰できるよう外部との相関も表現できるとよい。
レベル1：事業主が特定できるレベル。部署間の業務をフローで記載する。
レベル2：部署が特定できるレベル。業務担当者間の業務をフローで記載する。
レベル3：業務担当者が特定できるレベル。レベル2よりも更に詳細な作業（プロセス）を記載する。
レベル4：プロセスが特定できるレベル。各アクティビティ（詳細作業手順）を記載する

　例えば、業務効率を目的に作成するのであれば、これまでムダとなっていたタスクや短縮できる作業などを洗い出す必要がありますので、詳細作業手順までを記述するレベル4の粒度まで掘り下げるといった具合になります。

要件定義のポイント⑦　「要件」と「仕様」を確実に区別して整理する

まずは要件と仕様の違いから見ていきましょう。

例えば、家を建てることを例にすると、「2世帯なので玄関と水回りが2つ欲しい」といった要求を叶えるための間取りが「要件」で、コンセント数や棚の位置を決定する設計図面が「仕様」になります。
　顧客からは、「これが要件で、これが仕様です」といったように整理された状態で情報が出てくるわけではありませんので、顧客から獲得した要求は、確実に「要件」と「仕様」とに区分して整理する必要があります。

要件定義のポイント⑧　「業務要件」「機能要件」「非機能要件」のトレーサビリティを確保する

　要件定義を構成する要素は、「業務要件」「機能要件」「非機能要件」の3つであり、 それぞれを明確に定義することが要件定義においてもっとも重要なことです。
そして、「業務要件」と「機能要件」、「業務要件」と「非機能要件」との間にはトレーサビリティが確保されていることが重要です。
　もし、トレーサビリティが確保されていなければ、要件がもれているということになりますので、細心の注意を払いながら確実にひとつずつ確認しましょう。

要件定義のポイント⑨　第三者でもわかるように記載する

　要件定義書の読み手は顧客側であるため、専門用語や開発者しかわからない高度な内容になっていると読み手に正確に伝わりません。
よって、要件定義書は第三者でもわかるように記載方法を工夫する必要があります。

　専門用語は使わない、箇条書きにする、図表を多く用いる、文章ではなくUMLでまとめるなどといった手法を用いてわかりやすく記載するよう心がけましょう。
まずはわかりやすくするための様々な方法の理解から始めましょう。

要件定義のポイント⑩　顧客との合意形成を重要視する

　要件定義書はシステム開発の根幹となる、システム開発でもっとも重要なドキュメントです。
要件定義で顧客と合意できていない部分があれば、その箇所からボタンの掛け違いが起こり、後々大きな手戻りとなるリスクを抱えた状態となります。
よって顧客との合意はもっとも注力すべき重要なポイントです。
　また、「要求として抽出したが、機能要件の対象外となった機能」「要件の変更管理に関する方法」「要件定義の制約条件・前提条件」「要件定義では未決で先送りとなった申し送り事項」といった内容についても、顧客と認識を共有し合意をしておきましょう。

要件定義のポイント⑪　変更を管理し、常に最新状態を維持する

　要件定義作成後も、様々な理由で要件の変更や追加が発生します。また仕様の変更に伴い要件が変わるといったこともままあります。

　例えば設計に変更があった場合、設計書への反映はもちろんのこと、要件定義にまで遡って変更を反映（修正）する必要があります。
また、変更を反映するだけではなく、変更を管理することも重要です。
変更管理を行うことで、変更の履歴を追うことができたり、変更の矛盾点に気づくことができたりします。

　ここまで11の要件定義のポイントについて述べてきましたが、いかがでしたか？
2010年に情報処理推進機構（IPA）から公開された「超上流から攻めるIT化の原理原則17ヶ条」は、タイトルに原理原則が入っているだけあり、要件定義の初心者にも参考になる部分も多いため、この章の最後に紹介しておきます。

超上流から攻めるIT化の原理原則17ヶ条

要件定義の基本プロセス

　さて、ここからは要件定義の基本となるプロセスについて、順を追って解説していきます。

ステップ①　現状把握

　まずは、業務内容、目標、課題、問題点など現状を把握したうえで、顧客の要求を精査していきます。
具体的には、以下のような事項をまとめていきます。

・どんな業務規則、制約事項があるのか？
・現行の業務およびデータの流れはどのようになっているのか？
・現行の業務にはどのような問題点があるのか？
・目標達成のためにどんな課題があるのか？

ステップ②　ステークホルダの抽出

　ステークホルダとして、対象となる業務やプロジェクトの始まりから終わりまでのあいだに利害関係が生じる人や組織をすべて洗い出します。
また、ステークホルダには直接的な関わりを持つ人や組織と、間接的に影響を受ける人や組織に分けることができ、それぞれを「直接的ステークホルダ」「間接的ステークホルダ」と呼びます。
　具体的には、ビジネスプロセスに直接あるいは間接的に関与している人や組織をすべて洗い出し、ビジネスプロセスに依存したステークホルダを抽出していきます。

　ステークホルダの抽出や取り纏めについては様々な方法がありますが、ここでは代表例を２つあげておきます。

ステークホルダマトリクス

ステークホルダマトリクスとは、事業やプロジェクトを取り巻く人や組織が事業やプロジェクトに与える重要度と影響度を整理するための二軸図です。

オニオンモデル

　オニオンモデルとは、ステークホルダを階層レベルで捉え、そのレベル間の関係を説明するための概念モデルです。
REBOKの要求獲得技術によるステークホルダ識別を行うための技法としても知られています。
 この場合、中心にはソフトウェアを置いて中心から外側に向けて影響を与えるステークホルダを可視化していきます。

ステップ③　要件ヒアリング

　ヒアリングでは「この業務に関わる方はどの部署ですか？」「この業務の処理はどのように進んでいきますか？」というように、第三者の視点で過不足がないかを確認していきます。
　ヒアリング後は、5W2Hの視点で「想像」⇔「箇条書き（まとめ）」のループを繰り返して要件を整理していきます。

ステップ④　要件と仕様の整理

　前章で「要件」と「仕様」について、「要件」は、要求を実現するための条件で、家を建てる場合の「間取り」、そして「仕様」は、要件を満たすための詳細な条件で、家を建てる場合の「設計図面」と説明しました。
上記のことから、「要件」を詳細化したものが「仕様」であり、「仕様」には設計の観点が含まれていることがわかります。
　この関係を認識せずに「要件」なのに「仕様」として識別したり、逆に「仕様」なのに「要件」で括ってしまったりする場合がありますので、「要件」と「仕様」の整理は注意深く行う必要があります。

ステップ⑤　要件の細分化

　要件を細分化するとは、「要件」と「仕様」を構造的に捉えることです。
先ほど「要件」と「仕様」の整理について述べましたが、構造として「仕様」に対する「要件」が不足している、あるいは、「要件」として捉えていたものが実は「要件」ではなく「仕様」で、その「要件」に対する「仕様」が考慮できていないといったことがあり、要件の細分化についても注意深く行う必要があります。
「要件」と「仕様」を区別してそれぞれを適切に構造化する、仕様に対する要件を考慮する、要件に対する仕様を考慮する、といった非常に重要かつ綿密な作業となりますので、時間をかけてでも確実に行うようにしましょう。

ステップ⑥　業務要件の定義

　開発するシステムは「誰がどのように使うか」といった顧客の要求を新業務として示す必要があります。その新業務の内容や運用方法をまとめ、業務要件として整理していきます。
　業務要件を整理する方法として、システム化の対象となる業務を洗い出し、業務フローを作図して分かりやすくまとめて業務一覧に落とし込むまでの一連の作業を行います。

業務要件の定義は、システム化の目的に対する根拠となるように業務要件を整理してまとめることです。
上記の4つのポイントに従って、確実に業務要件を押さえるようにしましょう。

ステップ⑦　機能要件の定義

　先に定義した業務要件から、人の手で実施する業務と、システム化の対象となる業務をそれぞれ定義したあと、機能間のデータの流れを明確にしていきます。

機能要件では以下のポイントを押さえるようにしましょう。

・どの業務をシステム化するのか明確にする
・各機能の役割、データの流れを明確にする
・システムが処理を行うデータ同士の関連性について図式化 する

ステップ⑧　非機能要件の定義

　先に定義した業務要件から、機能要件以外の要件を非機能要件として整理していきます。
このときにもれなく整理できるようIPA発行の「非機能要求グレード」を活用するとよいでしょう。

参考URL：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html

　次に、「どのような内容を非機能要件として定義しまとめていけばよいか」について、具体例をあげておきますので、参考にしてみてください。

次に、もし「非機能要件に抜けもれがあった場合にはどのようなリスクがあるのか」についても記しておきます。

・「可用性」の抜けもれ・・・頻繁に停止するなど、使いたいときに使えないリスク
・「性能・拡張性」の抜けもれ・・・レスポンスの遅延や、リソースが増強できないリスク
・「運用・保守性」の抜けもれ・・・システム運用や保守に対して、多大な時間を要するリスク
・「移行性の抜けもれ」・・・移行が思い通りにいかず、想定外の時間を要するリスク
・「セキュリティの抜けもれ」・・・ウイルスに感染するなど、機密情報が漏洩するリスク
・「システム・エコロジーの抜けもれ」・・・法令違反となり、課徴金の支払いが発生するリスク

ステップ⑨　要件の調整

　「業務要件」「機能要件」「非機能要件」のそれぞれの定義が終われば、最後に各要件の調整を行います。
この際、対応優先度に沿って要件を調整しますが、その優先度は開発プロジェクトの「コスト」「スケジュール」「技術」といった制約 、目的やビジネス価値によるインパクトを考慮した要件の「緊急度」「重要度」といった視点から、事前に指標を決めておくとスムーズに事が進みます。

申し送り事項の作成

　要件を調整する際、要件定義内では結論が出ないといったことが起こる場合があります。
その際は「申し送り事項」として確定しなかった事項をとりまとめて、以降の工程に影響が出ないように解決する期限と担当者を設定して管理するようにしましょう。

業務要件を定義する

　システム化する目的は、「業務効率化」もしくは「業務改善」にほぼ集約されます。
業務要件は目的を達成するための要件でなければならないため、常に目的に立ち返りながら一つずつ定義していきます。

　業務要件の定義においては、まず業務フローをインプットに「業務一覧」を作成します。
「業務一覧」とは、業務を体系的に大分類・中分類・小分類という形式で上位から下位までを一覧にまとめたものです
。詳しくは下図をご参照ください。

　業務とは、ビジネス（事業）を成り立たせるためのパーツのようなもので、「業務一覧」はビジネス（事業）を成り立たせるために必要なパーツを全て揃えることと捉えることができます。
この時に必要なパーツとして、イレギュラーパターンや想定し得るシチュエーションにまで幅を広げて揃えるといった考え方ができれば、考慮もれが少なくなるのと同時に、顧客にとって価値ある提案が可能となります。

機能要件を定義する

　「機能要件」とは、業務要件を実現するために必要なシステム化対象の機能に関する要件です。
業務要件を定義したのちに、「この業務を実現するためにシステムとして何ができなければならないか」をシステム要件として定義するのですが、このうちシステムが備えるべき機能について定めたものを「機能要件」といいます。
「機能要件」には、「システム化により何が実現できるのか」を記載していきますが、具体的には、データおよびシステムの種類・構造、システムの処理内容などが該当します。
　この際、単に要求を要件化するのではなく、「実現可能性が低い」、あるいは「ビジネス上のインパクトが弱い」といった機能要求を、よりビジネス価値を高める代替案を想定しつつ、新たな機能要件として定義できるように取り組みます。このような対応ができるか否かが要件定義の胆になります。

非機能要件を定義する

　非機能要件とは、業務要件を実現するために必要となるシステム化対象の機能以外の要件です。
例えば、エンタープライズ系のシステムであれば、情報セキュリティやBCP（事業継続計画）の実現のための可用性や信頼性に重きをおいて非機能要件を定義し、Ｗｅｂサービス系のシステムであれば、使いやすさやわかりやすさ（ユーザビリティ）、応答時間などの性能面を重要視した非機能要件を定義するといった具合になります。
　非機能要件を定義するタイミングは、業務要件と機能要件の定義が終わってからになります。
なぜなら非機能要件を考える際、業務要件はもちろんのこと機能要件もインプットとなるため、実装する機能により非機能要件が変わるからです。
　非機能要件の定義において気をつけたいことは、顧客からは非機能の要求はなかなか出てこないという点です。
非機能要件は、開発側から顧客に対して提案することを前提として進めましょう。

要件定義の成果物

　要件定義では成果物として、基本的に以下に示す項目やドキュメント（別紙）を作成します。但し、プロジェクトの対象や特性によって必要とするドキュメントは変わりますので、その都度必要なものを選択しましょう。

１．業務要件
　１－１．システム化の狙い（目的・背景）
　１－２．用語定義
　１－３．ステークホルダ一覧
　１－４．ステークホルダ関連図
　１－５．ビジネスプロセス関連図
　１－６．業務一覧
　１－７．Aｓ－Is業務フロー
　１－８．課題一覧
　１－９．To-Be業務フロー
　１－１０．要求一覧
　１－１１．システム化業務フロー
　１－１２．遵法性

２．機能要件
　２－１．機能に関する事項
　２－１－１．機能一覧
　２－２．画面に関する事項
　２－２－１．画面一覧
　２－２－２．画面概要
　２－２－３．画面出力イメージ
　２－２－４．画面遷移図
　２－３．帳票に関する事項
　２－３－１．帳票一覧
　２－３－２．帳票概要
　２－３－３．帳票出力イメージ
　２－４．情報・データに関する事項
　２－４－１．情報・データ一覧
　２－４－２．情報データ処理要件
　２－４－３．データ構造
　２－５．インターフェースに関する事項
　２－５－１．インターフェース一覧
　２－５－２．インターフェース定義

３．非機能要件
　３－１．ユーザビリティ及びアクセシビリティに関する事項
　３－２．システム方式に関する事項
　３－３．システム規格に関する事項
　３－４．性能に関する事項
　３－５．信頼性に関する事項
　３－６．拡張性に関する事項（主に新規の場合）
　３－７．上位互換性に関する事項
　３－８．中立性に関する事項（主に新規の場合）
　３－９．継続性に関する事項（主に新規の場合）
　３－１０．情報セキュリティに関する事項（主に新規の場合）
　３－１１．システム稼働環境に関する事項（主に新規の場合）
　３－１２．テストに関する事項
　３－１３．移行に関する事項
　３－１４．教育に関する事項
　３－１５．引継ぎに関する事項
　３－１６．運用に関する事項（新規開発/既存開発）
　３－１７．保守に関する事項

高品質な要件定義を作成するための実践テク

　ここからは、より高品質な要件定義を作成するためのテクニック的な要素をお伝えします。個人のスキルアップやチームビルディングのベースとしてお役立ていただければ幸いです。

背景と目的は具体的であればあるほどよい

　背景と目的からシステム開発で必要なことが導き出しますので、背景と目的は具体的であればあるほどよい、ということになります。
背景と目的が具体的であることにより、システムを活用するシチュエーションを明確に想定することができ、より顧客に喜ばれる要件を定義できることにつながります。

常にシステム化の目的に立ち返って考える

　要件定義を進めていくなかで、議論が錯綜したり、要件の優先順位に迷ったりすることがあります。
そのような場合は常にシステム化の目的に立ち返って考えなおすことが重要です。

USDMのフレームワークを活用する

　要求仕様を定義するための使用するフレームワークにUSDM（Universal Specification Describing Manner）があるのですが、このフレームワークはもちろん要件定義でも活用することが可能です。
ここではUSDMの特徴から、要件定義での活用方法をお伝えします。

・「業務」と「機能」を階層構造で捉える
要求を「業務」、仕様を「機能」と置き換えて考えることにより、「業務」と「機能」および「非機能」を階層構造的に捉えることが可能となります。
階層構造で捉えることで、「機能」や「非機能」の考慮もれや「業務」との不整合をカバーします。

・「理由」を付けることにより要求を支える
要求に「理由」を付けることによる以下のメリットを活用します。

　・「理由」があることで、要求（＝業務）の意味が理解しやすくなる
　・「理由」を書くことで、その要求（＝業務）に根拠がないことに気づくことができる
　・「理由」があることによって、仕様（＝機能（非機能））が引き出しやすくなる

　以上のことより、要件定義でUSDMの考え方を取り入れることにより、業務と機能の紐づけの抜けもれの防止につながるとともに、ステークホルダの認識齟齬が起きにくくなるといった効果も期待できます。

業務要件と機能要件・非機能要件のトレーサビリティを確保する

　それぞれ要件として定義した「業務要件」と「機能要件」、「業務要件」と「非機能要件」のあいだでは、トレーサビリティを確保し考慮もれがない状態にすることが重要です。
特に「業務要件」から「機能要件」の抽出は難易度が高く、集中してより注意深く見ていく必要があります。
また、「非機能要件」は考慮もれが発生しやすいため、その点にも注意が必要です。

　また、「業務要件」と「機能要件」、「業務要件」と「非機能要件」の関係性は「１：１」といった単純なものではなく、「N：N」となるため、何度も見直しをすることをおすすめします。
ちなみに、要求と要件のフェーズ間におけるトレーサビリティの確保もとても重要ですので、この点も押さえておきましょう。

ソフトウェア品質特性（ISO/IEC25010）も活用する

　非機能要件の抽出においては、先に「非機能要求グレード」の活用をご紹介しましたが、ソフトウェア品質特性に焦点を当てているISO/IEC25010を参考にすることも有効な手段となります。
ISO/IEC25010にはソフトウェア品質特性として、8つの品質特性と31の品質副特性を定義していますが、品質特性のなかの「機能適合性」以外が非機能要件に該当します。
　非機能要求グレードと合わせてISO/IEC25010を活用することで、より網羅的に非機能要件を検討することができます。

UMLを活用する

　文章による記述はどうしても曖昧さや誤認識が排除できず、正しく伝わらない可能性があります。
よって、出来るかぎり図や表を使用することが望ましいのです。
中でもUMLは全世界共通ですので、積極的なＵＭＬの活用をおすすめします。

UMLとは

　UMLとはUnified Modeling Languageの略で、日本語では「統一モデリング言語」と呼ばれています。
システムの構造や振る舞いに対して図を用いることにより視覚的に把握できるようになり、効果的なコミュニケーションの手法として活用されています。
2005年にISOで国際標準化されて以降、ソフトウェア業界では国際的な業界標準のグラフィカル表記法として広く普及しています。

機能要件は「MUST」「WANT」「NEVER」で整理する

　機能要件を決める段階においては、「MUST」「WANT」「NEVER」の視点を用いると、要件の整理や優先順付けをする際にとても効果的です。
なかでも「NEVER」の視点は抜けやすいため、考慮もれがないように注意しましょう。

「MUST」＝できなければならない
「WANT」＝あったらいいな
「NEVER」＝あってはならない

業務の「時間」「頻度」「量」を確実に押さえる

　業務の中でも「時間」「頻度」「量」に関連する情報は、システム化のポイントとなる重要なポイントとなります。
「時間がかかっている業務」「頻度の多い業務」「処理量の多い業務」を見つけ出すことにより、システム化による恩恵が受けやすくなりますので、このポイントは必ず押さえましょう。

「正常処理」だけではなく「例外処理」も考慮する

　業務においては正常処理にばかり目が行き、例外処理が考慮できていな場合が多いため、注意が必要でしょう。
また、例外処理のほか特殊処理もある場合がありますので、その点も同じく注意して考慮もれとならないようにしましょう。

数年先のことを想定する

　ソフトウェア自体に経年劣化はありませんが、賞味期限なるものはソフトウェアにも存在します。
それは周辺環境の変化によるもので、例えば、業務の変更や法律の改正などにより、そのままではシステムが使えなくなる場合が起こり得ます。
そのため、先の読みにくい時代ではありますが、最低でも3年先、できれば5年先のことまでを想定した要件を定義できるようにすることが望ましいのです。

顧客との合意形成においては読み合わせを行う

　要件定義は、「これからどういったシステムを作るかについて」を定めた、いわば顧客との合意書という側面があります。
よって合意形成を確実なものにするためにも、顧客と一緒に読み合わせを行うことが、顧客との合意においてもっとも確実な方法となります。

レビューを疎かにしない

　要件定義を始めとする上流工程の品質は、エンジニアのスキルとともにレビューの質にも大きく左右されます。ここではレビューの重要性について確認します。

レビューの重要性

　要件定義を含む上流工程においては、レビューによる不具合摘出比率の向上が重要なこととなります。
レビューでの指摘率が高いプロジェクトでは大きな欠陥を出しているケースはないといった報告もあるぐらいで、上流工程のなかでも特に要件定義工程での効果的なレビューは、とても重要なことであると認識しましょう。

レビュープロセスの重要性

　効率的かつ効果的なレビューを行えるようにするためには、レビューにルールを設けて、そのルール通りに行えるよう、レビュープロセスを整備することがポイントです。

レビュープロセスである「レビュー戦略」→「レビュー計画」→「レビュー実施」→「レビュー結果分析」→「レビュー改善」・・・の各プロセスにおいて定義を行うこと、またレビュープロセスに従ってＰＤＣＡサイクルを回すことにより、レビューの質および効率の改善が可能となります。

レビューアの重要性

　レビューにおいては、レビューアの適切性についても考慮したいところです。
誰がレビューアを担当するかでレビューの指摘件数やその内容に雲泥の差が出ますので、レビューアの適切な選任についても疎かにしないようにしましょう。

レビュー観点の重要性

　レビュー観点については、レビューアの適切な選任とともに、レビューの質を大きく左右する重要なポイントとなります。
　以下に要件定義におけるレビュー観点の例をあげましたので、参考にしてください。

さいごに

要件定義は、以下の5つの特性を備えておくべきといわれます。

・合目的性…システムの目的が明らかであり、すべての要件はその目的に適っていること
・網羅性…システムの目的に必要な要件がもれなく重複なく示されていること
・整合性…各要件が他の要件と整合したものになっていること
・理解性…全ての要件がわかりやすく表現されていること
・追跡可能性…各要件の起源が明確であり、かつ各要件が後工程で参照しやすいよう容易に識別できるように示されていること

つまり、定義された要件が、もれなく、重複なく、各々の要件が整合しており、かつ分かりやすく表現されているもの。それが品質のよい要件定義の条件といえます。

要件定義工程においては、なかなか明確な成果物を定めにくく、例え成果物を定めることができたとしても、その品質を検証することが難しく時間的な制約もあるため、実際には要件定義が中途半端な形で終わることもしばしば起こります。

その結果、下流工程（テスト工程）になってから、さまざまな不備や不具合が明るみとなり、大幅な手戻りによってプロジェクトのQCDバランスが大きく崩れ、結果的にプロジェクトは失敗の道を突き進んでいきます。

要件定義は難易度が高く、知識と経験の両輪がないことにはなかなかうまくいかないのですが、まずは要件定義についての理解を深めることが肝要です。
そして、理解したことを実際の要件定義で一つひとつ試してみることで、経験を積み重ねていっていただければと思います。

ご質問・ご要望

要件定義をうまく進め、良い要件定義書を作成するためにおさえておくべき事項は多岐にわたります。

弊社、株式会社QualityCubeでは、要件定義のスペシャリストとして「要件定義代行サービス」を提供しています。

コンサルタント利用は効率面でのメリットだけでなく、教授したナレッジは成功法則として継承していけるため、企業の資産となります。
依頼には費用が発生しますが、長い目で見ると費用対効果が高いので、できるだけ早い段階で導入を検討されることをおすすめいたします。

より詳細な情報や、貴社の状況に合わせた具体的な提案が必要な場合は、お気軽にご相談ください。
例えば、以下のような課題からお問い合わせを頂くケースが多くなってきております。

• 要件定義のできる経験者のリソースが不足している
• 要件定義がうまくいっていないと感じている
• 要件定義の担当者が少ないため、プロジェクト受注を断念するケースがある
• 要件定義工程の外注を検討している

行き詰まったときは、一度基本に立ち返るのも手です。本稿が皆様のお悩みのヒントとなれば幸いです。

ちなみに今回は実践入門とし、「そもそも要件定義とはなにか？」という説明は省略しますので、要件定義について知りたい方は以下のエントリを参照してください。　

ブログ

合わせて読みたいシステム開発の要件定義とは│成功のもとは要件の不備をゼロにすること

要件定義では、知らず知らずに顧客の思い描いている絵と異なった絵を描いてしまうことがあります。これを本文では「要件の不備」として説明しています。本記事ではシステム開発の最初の入り口で躓かないための要件定義の基本について解説していきます。...

要件定義を進める上でのポイント

それでは、さっそく要件定義を成功に導くポイントについて解説していきます。
我々QualityCube社が、要件定義を進める上で重要と考えるポイントを大きく2つに分け、それぞれ解説していきます。

＜要件定義のPOINT＞
　POINT１.「要件定義を進める上で持つべき考え方」
　POINT２.「要件定義を成功に導く具体的なアクション」

POINT１.「要件定義を進める上で持つべき考え方」

POINT１は、要件定義を進める上で、まず念頭に置いてほしい考え方６つです。
これらを常に意識していただくことが、結果的に要件定義の質を高めることとなります。

(1)コミュニケーションの強化

要件定義の最初の難関は、関係者間のコミュニケーションです。

コミュニケーション不足による認識齟齬がもとで、トラブルに発展する事例は少なくありません。しかしながら、立場の異なるメンバー同士の意思疎通はどこの組織においても、そうスムーズにはいかないものです。

だからこそ定期的にコミュニケーションの場を設け、各ステークホルダの期待や要求を明確に掴み、丁寧にヒアリングすることで、プロジェクトの方向性を共有することを心がけましょう。プロジェクトの目的や要求事項を正確に把握、理解するためにも、ここは乗り越えるべきポイントです。

(2)完全性

要件定義は、システムやプロジェクトに関する重要な側面を網羅した「完全であり理想的な状態」である必要があります。
要件に抜け漏れがあると、後々の工程で問題を引き起こす可能性が高まり、プロジェクトの失敗に繋がりかねません。常に細心の注意を払い、抜け漏れが起こらないように意識しましょう。

(3)一貫性（矛盾の解消と整合性の確保）

要件定義の中で矛盾が生じないようにすることも重要です。

一貫性のない要件定義は、開発途中の大幅な手戻りの要因となり、結果的に時間の浪費やコストの増加といったムダを招くこととなります。とはいえ、要求にそってあれこれと要素を追加しているうちに、少しずつ整合性が合わなくなる…ということは起こりえます。
複数のステークホルダから要求があった場合は、要求同士の整合性が確保できるよう、常に矛盾点はないか意識し、見つけ次第解消しておきましょう。
お互いの妥協案を見つける、あるいは双方の要求を包含する新たな要求を定義するなど、矛盾の解消方法を模索する必要があります。

(4)優先順位の設定

すべての要求事項について加味すべきですが、すべてが同じ重要度を持つことはありません。
よって、絶対に実装する機能と可能であれば実装する機能の切り分けや、どの機能から実装すべきか等、優先順位を明確にするよう心がけましょう。

限られたリソースから価値ある成果物を生み出すためにも、またスケジュールや予算の最適化のためにも、優先順位の設定は非常に重要です。

(5)システム化に向けての実現可能性の検討

システム化に向けて、技術的な制約や実現可能性を検討することも重要です。
様々な条件が要求事項に含まれており実装が困難、あるいはコストが見合わない場合は、議論によって適切な妥協点を見いだす必要があります。
システムの理想像を描くことが要件定義ではありますが、「絵に描いたモチ」にしないための検討は十分におこなうべきです。

(6)長期的な視点

要件定義では、プロジェクトの現段階のみにとどまらず、長期的な視点も考慮すべきです。将来的な拡張や仕様変更に対応できるよう柔軟性を持たせ、システムの持続可能性を確保することが理想です。

顧客のえがく未来のビジョンに合致し、かつ将来的なニーズにも対応できるシステムの構築を目指しましょう。

POINT２.「要件定義を成功に導く具体的なアクション」

POINT２には具体的なアクション７つを示します。
POINT１の要素を意識しつつPOINT２のアクションを取ることで、さらに要求定義の質が高まりますので、ぜひ実行してください。

(1)文書（ドキュメント）化であいまいさを排除

要件定義ではあいまいさを排除し、具体的かつ明確な表記で要求を文書（ドキュメント）化することが重要です。（これは「要件定義書」と呼ばれます。）
要求事項を整理し、客観性の高い要求定義書を作成することで、開発メンバーを含めたステークホルダが異なる解釈をする余地がないようにしておきます。

これにより、開発チームや関係者が共通認識を持ってプロジェクトを進めることができます。

(2)変更管理プロセスの策定

プロジェクトの進行中に要求事項が変更となるケースもよくあります。
その際、混乱や確認漏れ、ムダな作業の発生を避けるためにも、変更管理のプロセスを策定しておきましょう。

変更が発生した際の承認手続きや影響分析、文書の更新手順などを明確に定義し、変更を適切に管理できるようにしておきます。

(3)工程移行判定基準の設定

要件定義を成功させるためには、効果的な工程移行判定基準を設定することが重要です。
工程移行判定の基準次第で、品質確保のレベルが変わるといっても過言ではありません。
プロセスとプロダクト（ドキュメント）の両方の視点から基準を設けることにより、要件定義工程を網羅的に判定することが可能となります。

　　◆参考◆
　　　工程移行判定をサポートするQualityCube独自の品質管理ツール：「クオリティゲート」

(4)承認プロセスの確立

要件定義をスムーズに進めるためにも、ステークホルダによる承認プロセスを確立しておきましょう。
文書化された要求事項の正確さやプロジェクトの目的達成可否について、承認者に確認してもらいます。適切な承認プロセスを経て顧客との合意を取っておくことは、後々のトラブルを避けるために最も重要なことの一つです。

(5)可視性とアクセシビリティの確保

要件定義は開発プロセス全体の源と言えます。そのため、定義し文書化された要求事項は、全てのステークホルダがアクセスしやすく見やすい形で管理することが重要です。
要件定義は、ステークホルダ全員がいつでも取り出せる場所に管理しましょう。

(6)適切なツールの選定

以外と見落としがちですが、要件定義の過程で使用するツールの選択も重要です。
要件管理ツールやコミュニケーションツールなどを必要に応じて活用することで、要求事項の追跡やステークホルダとの効果的なコミュニケーションが行え、円滑な管理が可能となります。
目的達成に最適なツールを選定しておきましょう。

(7)専門知識の活用

要件定義においては、関連する専門知識を活用することも重要です。
業界のベストプラクティスやフレームワークを採り入れることで、成功確率は飛躍的に向上します。また、必要に応じて専門家のアドバイスを積極的に取り入れることも得策です。

さいごに

本稿では、ITの要件定義を進める上でのポイントについて解説してきました。
「かんたんに分かりやすく」をモットーに書きましたので、実践入門としてお役に立てば幸いです。

なお、要件定義のさらに詳細な解説をご覧になりたい方は、以下のエントリをご参照ください。より深い内容に触れていますので、きっとご満足いただけるかと思います。

ブログ

合わせて読みたい要求定義│要件定義との違いや品質を高める進め方・書き方まで網羅的に解説

システム開発の要求定義について、要求定義書と要件定義書・RFPとの違いから品質を高める要求定義の進め方・書き方、記述内容に至るまで網羅的に解説します。よいシステムを開発するには、考え方や進め方も含め、目的に合わせて変化していく必要があります。...

株式会社QualityCubeでは、品質コンサルティングをドメインとした様々なソフトウェア品質改善のソリューションを提供しております。
システム開発において難易度が高いといわれる上流工程の支援を得意とし、「要件定義代行支援サービス」や「DXコンサルティングサービス」等も展開中です。
お困りごとがございましたら、まずはお気軽にお問い合わせ下さい。

• 要件定義代行支援サービス
• DXコンサルティングサービス

本記事では、要件定義をスムーズに進めるためのコツから、「良い要件定義書」を書くための重要ポイントまで徹底解説いたします。

要件定義書・要件仕様書とは？関連ドキュメントの違い

システム開発やDXプロジェクトでは、「要件定義書」「要件仕様書」「要求定義書」「要求仕様書」など、似た名称のドキュメントが数多く登場します。しかし、これらは作成目的や視点、関与する関係者が異なり、同じ意味で扱ってしまうとプロジェクト内で認識のずれが生じやすくなります。

本章では、それぞれの役割を工程視点で整理し、要件定義書がどの位置づけにある資料なのかを明確にします。

要件定義とは何か

要件定義とは、業務上の課題や目的を踏まえ、「システムで何を実現するのか」「どこまでを対象範囲とするのか」を明確にする工程を指します。単に機能を列挙する作業ではなく、業務要件・機能要件・非機能要件を整理し、関係者の合意を形成するプロセスとして捉えることが重要です。

要件定義の段階では、業務担当者・IT部門・ベンダーなど複数の立場が関わるため、専門用語に偏らず共通理解を得られる表現が求められます。また、この工程で整理された内容が後続の設計や開発の前提条件となるため、目的や背景を含めた整理が欠かせません。

要件定義書と要件仕様書の違い

要件定義書と要件仕様書は名称が似ているため混同されがちですが、目的や利用される工程、読み手の視点が異なります。

要件定義書は、業務課題やシステム化の目的、対象範囲を整理し、関係者全体の共通理解をつくるための資料です。一方、要件仕様書は、設計や開発に向けて機能や条件をより具体的に整理するドキュメントとして扱われることが多く、技術的な観点が強くなります。

プロジェクトを円滑に進めるためには、両者の役割を分けて理解しておくことが重要です。

このように、要件定義書は「何を実現するか」を共有する資料であり、要件仕様書は「どのように実現するか」に近づくための整理といえます。実務では両者が一体化している場合もありますが、役割の違いを意識して使い分けることで、関係者間の認識齟齬を防ぎやすくなります。

要求定義書・要求仕様書との違い

要求定義書や要求仕様書は、ユーザー側や業務部門の視点で「実現したいこと」や「期待する成果」を整理した資料として扱われるケースが多くあります。システム要件として具体化する前段階で作成されることもあり、現場の課題やニーズを言語化する役割を担います。

名称は似ていますが、要件定義書とは整理の粒度や立場が異なる点に注意が必要です。

要求定義書や要求仕様書は、あくまで「要求」をまとめた資料であり、その内容をもとにシステム視点で整理し直したものが要件定義書と考えると理解しやすくなります。企業やプロジェクトによって用語の使い方は異なるため、名称だけで判断せず、誰がどの目的で作成した資料なのかを確認することが大切です。

案件定義書との関係

案件定義書という呼び方が使われることもありますが、一般的な開発プロセスで正式な工程名称として定義されているわけではありません。プロジェクトの背景やスコープ、予算感などを整理する初期資料として扱われるケースが多く、要件定義に進む前の検討段階で作成されることがあります。 要件定義書との違いは、システム要件そのものよりも「案件として成立するか」「どのような方向性で進めるか」といった検討内容が中心になる点です。実務では、案件定義書で方向性を固めた後に要件定義書へと落とし込む流れを取ることもあり、両者は連続したプロセスの中で整理される資料といえるでしょう。

要件定義書の作成の進め方

要件定義書は、思いついた内容を書き並べるだけでは実務で使える成果物にはなりません。現状の業務やシステムの前提を整理し、課題や要求を段階的に具体化しながら、関係者の合意を形成していくプロセスとして捉えることが重要です。

本章では、要件定義書を作成する際の基本的な流れを、実務での進め方に沿って整理します。

現状業務とシステムの整理

要件定義の初期段階では、現行の業務構造やシステム環境を俯瞰的に整理し、「どの前提で要件を検討するのか」を明確にします。

既存フローを理解すること自体が目的ではなく、業務の役割分担やデータの流れ、システム間の関係性を整理し、後続の要件検討の土台をつくることが重要です。

整理を通じて、要件定義の前提条件を関係者間で共有できるようになります。業務ヒアリングや既存資料の確認をしながら、構造的な視点で情報を整理しておくことが、後工程の手戻りを防ぐポイントです。

課題・要求の深掘りと優先順位づけ

現状を整理した後は、関係者から挙がった課題や要求を具体的に掘り下げ、優先度を整理していきます。単なる要望の羅列ではなく、業務への影響度や実現可能性を踏まえた判断が求められます。

• 業務上のボトルネックや非効率な作業を洗い出す
• 部署ごとの目的や期待値を明確にする
• 現行システムで実現できていない理由を確認する
• 短期対応と中長期施策を切り分ける
• コストや影響範囲を踏まえて優先順位を決める

要求の背景を理解せずに優先順位を決めてしまうと、本来解決すべき課題から外れてしまう可能性があります。関係者との対話を重ねながら整理することで、実務に即した要件につながるでしょう。

要件の分類と文書化の手順

整理された要求は、業務要件・機能要件・非機能要件といった形で分類し、要件定義書として構造化していきましょう。表現の美しさよりも、要件の粒度や関係性をそろえることが重要です。

• 要求内容を業務要件・機能要件・非機能要件に振り分ける
• 抽象的な表現を避け、条件や判断基準を明確にする
• 重複や矛盾がないかを確認する
• 用語や表現をプロジェクト内で統一する
• 管理番号や変更履歴をつけ、追跡可能にする

要件の分類を意識して文書化することで、設計工程へ引き渡した際の解釈のずれを防ぎやすくなります。要件定義書は単なる記録ではなく、後工程の基準となるドキュメントとして整理していくことが大切です。

関係者との合意形成

要件定義書は作成して終わりではなく、関係者間で認識をそろえて初めて有効な成果物になります。業務部門、IT部門、開発担当者など、それぞれの立場によって重視する観点が異なるため、レビューやディスカッションを通じて意図を共有することが重要です。 合意形成では、細かな仕様の是非だけでなく、「対象範囲は適切か」「優先順位に納得できているか」といった視点を確認します。最終的に承認プロセスを経て確定させることで、後工程の判断基準として活用できる状態になるのです。

要件定義をスムーズに進める３つのコツ

「要件定義は難易度が高い」と言われる理由として、成果物となる「要件定義書」に書くべき内容がはっきりと定義されておらず、プロジェクトによって差異がある、というのがあります。（「要件定義書」については後項で解説します。）

QualityCubeではこれまでのご支援経験から、以下の３つを「要件定義をスムーズに進めるためのコツ」と考えました。

• 既存の業務フローとシステムについて知る
• 要求定義書と要件定義書のすり合わせをする
• 開発担当者を明確にしておく

既存の業務フローとシステムについて知る

発注者の要望は実に様々ですが、システムや業務フローに課題があり、直面している問題を解決したいという要求は少なくありません。
したがって要件定義段階でまず必要になるのは、現在用いられているフローや既に使われているシステムを正しく理解することです。そのうえでどこに課題があり、どのように解決するべきかを明確にします。
なかには、現行システムの設計書通りに業務を行っていないケースもあるので特に注意が必要です。

要求定義書と要件定義書のすり合わせをする

システム開発において、発注者が作成するドキュメント書類を「要求定義書」、この発注者の要求をもとに開発者が作成する書類を「要件定義書」と呼びます。
要求定義書では、発注者が解決したいと考えている課題や、導入したいシステムについての要求をまとめるのに対して、要件定義書では開発者の視点で要件や作業工程を決めていきます。
発注者の描いた夢をもとに、開発者が理想となるシステムの姿を整理していくのです。

しかしながら、プロジェクトによっては発注者が要求定義書を作成していないケースもあり、その場合、発注者に対して開発者がヒアリングを行うことで要求を把握する必要があるので、注意が必要です。

こうして要件定義書が完成したら、漏れがないか発注者と開発担当者とで認識合わせをすることが重要です。
一般的なウォーターフォール型開発では、手戻りが重大なタイムロスになりますから、要件定義の段階でしっかりと作り込みを行うことで手戻りを防いでいきます。

開発担当者を明確にしておく

プロジェクトの開発担当者を明確に決めておくことも重要です。
他のプロジェクトと兼務の開発者は、当プロジェクトにどのくらいの工数を割けるか、明確にしておきます。曖昧なままにしておくと、後々コミュニケーションのすれ違いが増えていく可能性があります。ムダな調整が増えると、本来するべき業務の進行に支障が出る可能性があります。
したがってこの段階で役割分担を明確にしておき、開発担当者が不明確なままの業務をなくします。
開発固定のタスクに関して開発担当者と責任分担が適切に決まっていれば、不要な業務で工数を圧迫する恐れもなくなります。
そのためには、WBS（Work Breakdown Structure：作業分解構成図）を作成し、誰がいつまでに、何を完成させるかを明確にしましょう。

上記の３つをしっかりと守れているかどうかが、要件定義の成否を分けると言っても過言ではありません。
貴社の要件定義はどうでしょうか？照らし合わせてみてください。

要件定義の成果物：「要件定義書」

ここでは、前項で触れた「要件定義書」について解説していきます。
冒頭でご紹介した別エントリでも述べていますが、改めて「要件定義書」とは、要件定義において成果物とされるドキュメント書類の名称です。
前項で「書くべき内容がはっきりと定義されておらず、プロジェクトによって差異がある」ことが難しいと言われる理由と述べましたが、QualityCubeが「要件定義書に書くことが望ましい項目（中身）」として挙げているのは、主に以下の通りです。

要件定義書に記載すべき必須項目

またその中でも、とりわけ必ず記載すべき「必須項目」と言えるものは次の4項目です。

• システム概要：目的や目標を決める
• 業務要件：業務フローを作成する
• 機能要件：必要となる機能を決める
• 非機能要件：システムの裏側を決める

システム概要：目的や目標を決める

システム概要には、「システム開発に至った背景」や「システム開発の目的と目標」の記載が必須です。
目的は、「システム開発によってどのような効果や結果を求めるか」という内容。
目標は、それが「どのような結果になったとき達成されたといえるか」を定義する指標です。
定量的なゴールを定めておくことで、発注者とシステム開発者、また関係者全員の認識に齟齬が発生しないようにしておくことが大事です。

業務要件：業務フローを作成する

システム開発の目的と目標を達成するには、実際の業務はどうあるべきかを考えます。
業務の流れを文書で書くと非常に分かりづらいため、ここでは「業務フロー」を作るのがよいでしょう。
まずは「現状の業務フロー（As-Is）」を作成してから、「システム稼働後の業務フロー（To-Be）」を作れば、システム稼働前・稼働後のフローが明確になります。

機能要件：必要な機能を決める

業務要件で決めた「何をどのように使うのか」ということに対して、「システムがどのような情報を管理したり処理したりすればよいか」を規定するのが機能要件です。
機能要件でありがちな失敗として、「開発者だけで決める方式をとってしまうこと」が挙げられます。
忘れてはいけないのが、発注者の要求こそが開発の大前提であるという点です。
システム課題はもちろん重要ですが、それだけを優先するのではなく、「発注者が実際にどう使うのか」を確認しながら、使いやすさ、必要な機能が備わっているか、を十分検討してください。

非機能要件：システムの裏側を決める

機能要件が「発注者の目に触れる機能」であるのに対し、非機能要件はシステムの品質や性能という「システムの裏側を決めること」です。
どのシステム開発でも、非機能要件で検討すべき内容は同じである場合が多いです。
ここはすでにあるフォーマットを使うことで、資料作成や事項の抽出にかかるコストを削減しましょう。

では、この必須項目のうち「業務要件」「機能要件」「非機能要件」の具体的な洗い出し方法について、さらに詳しく見ていきましょう。

業務要件

業務要件は、要件定義の初期に分析します。
システム化に先立ち、現状の業務がどのように流れているかを分析し問題を抽出した上で、新たに何を実現すべきかを決めていきます。この段階ではシステムはあまり意識せず、あくまで「業務そのもの」に焦点を当てます。
業務要件では、業務に詳しい発注側の関係者に参加してもらい、高いコミュニケーションを図ることが必要です。ここで発注者と開発者間で目的が噛み合わないままスタートしてしまうと、大幅な手戻りが発生して時間とコストの浪費につながるため、丁寧なヒアリングを行うことが肝となります。

業務フローの作成には、弊社がお役立ち資料として無料公開している「業務フローの書き方ガイド」を、ぜひ参考にしてください。

機能要件

システム要件でシステム化の方向性が決まると、システムに必要な機能について検討します。
機能要件とは、システム開発を通して最低限実現すべき機能のことを指し、発注者へのヒアリングを実施することで具体的に固めていきます。
機能要件で洗い出した成果物は、後述の非機能要件と合わせて、次工程の基本設計フェーズでの重要なインプットとなります。
機能要件の主な内容としては以下の5つがあります。（ちなみにこれは、基本設計の際に必要な情報となってきます。）

①画面要件

・画面一覧：開発時の画面を一覧化したもの

出典：IPA機能要件の合意形成ガイド画面編　P17 　

・画面遷移図：画面の流れをあらわしたもの
・画面レイアウト：画面のイメージを共有するためのもの

出典：IPA　工程成果物間の関連　P15

②帳票

・帳票一覧：開発する帳票を一覧化したもの

出典：IPA　工程成果物間の関連　P15 　

・帳票概要：帳票の出力場所や、業務上の用途を記したもの

出典：IPA　工程成果物間の関連P15

・帳票レイアウト：帳票の具体的なイメージを明確にするもの

出典：IPA　工程成果物間の関連　P15 　

③バッチ

・バッチ処理一覧：プロジェクトで開発するバッチ機能を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

④データ

・外部システム関連図：関連システムとのデータ連携を図解したもの
　（システム開発の対象となる部分を色分けし、どのシステムに影響を及ぼす可能性があるのか整理する）

出典：IPA　工程成果物間の関連　P15 　

⑤外部インターフェース要件

・外部インターフェース一覧：関連システムとのデータ連携を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

外部インターフェース定義書：関連システムとのデータのやりとりについて、主要なデータ項目を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

非機能要件

機能要件が発注者にとって必須の機能であることに対して、非機能要件は、機能以外に「あればいいな」と考える要件です。一見必要ではないように見えますが、非機能要件を実現していくことで、発注者の満足を上げることができます。システム画面の切り替え速度などは、よくある例です。

非機能要件の決定は、予算や納期を意識しつつ、発注者と合意を図ることが重要となってきます。発注者の要望を文字通りに捉えるのではなく、ヒアリングによって「なぜそれを要求するのか？」までを引き出すことで、潜在的な要求に気づくことができ、より質の高い成果物のアウトプットにつながります。
IPAの非機能要求グレードに示された６つの特性をもとに、運用方法を検討しましょう。

出典：IPA　非機能要求グレードご紹介　P6

要件定義書作成の際のポイント

要件定義書は、項目を網羅するだけでは実務で活用できる資料にはなりません。読み手の立場を意識した構成や表現、要件の具体性、変更を前提とした管理方法までを考慮することで、プロジェクトの共通認識として機能するドキュメントになります。

本章では、既存の成果物項目と重複しない視点から、要件定義書を実務で使い続けるためのポイントを整理します。

読み手に伝わる構成にする

要件定義書は、業務担当者・開発者・意思決定者など、異なる立場の関係者が参照する資料です。そのため、専門用語を減らすことだけが目的ではなく、「どの順番で情報を提示すれば判断しやすいか」という構成設計が重要になります。

例えば、背景や目的を冒頭で整理した上で対象範囲を明示し、その後に要件の詳細を記載することで、読み手は文脈を理解しながら内容を把握できます。また、章立てや見出しの粒度をそろえることで、レビュー時に確認すべきポイントが明確になります。単なる説明資料ではなく、意思決定を支援するドキュメントとして構成を設計する視点が求められます。

機能要件の具体的な書き方

機能要件を記載する際は、「何ができるか」だけでなく、「どの条件で、誰が、どのように利用するのか」を明確にすることが重要です。既存の機能要件項目では内容の種類を整理しますが、記載方法の観点に焦点を当てましょう。

抽象的な表現のまま記載してしまうと、設計段階で解釈が分かれる原因になります。操作主体、入力条件、処理内容、出力結果といった視点で文章を構造化することで、開発担当者が具体的なイメージを持ちやすくなります。

また、例外処理や制約条件をあらかじめ記載しておくことで、後工程での仕様変更を減らす効果も期待できます。

非機能要件を明確にする視点

非機能要件は、性能・可用性・セキュリティなどシステム全体の品質に関わる要素であり、機能要件と比べて抽象的になりやすい領域です。

要件定義書では、単に「高性能」「安全」といった表現にとどめず、評価基準や前提条件を整理しておくことが重要になります。

非機能要件は後回しにされがちですが、あいまいなまま進めると運用開始後のトラブルにつながることもあるでしょう。関係者と合意できる指標を意識しながら、測定可能な形で整理しておくことが重要です。

変更管理と合意形成の仕組み

要件定義書は一度作成したら固定されるものではなく、プロジェクトの進行に応じて変更が発生することを前提に管理する必要があります。変更履歴や版管理を明確にし、誰がどの判断で更新したのかを追跡できる状態にしておくことで、後から認識の食い違いが起きるリスクを減らせます。 また、変更内容を関係者へ共有する仕組みを整えておくことも重要です。レビューのタイミングや承認フローをあらかじめ決めておくことで、変更が属人的に進むことを防ぎ、プロジェクト全体としての合意形成を維持しやすくなります。

良い要件定義書の必須条件

ここまで、要件定義書に記載すべき項目について具体的に見てきました。
最後に、「良い要件定義書」とはどういうものを指すのか？要件定義を行うにあたって、QualityCubeが考える大事な条件は以下の2つです。
作成した要件定義書が以下の条件に当てはまるかどうか、ぜひ照らし合わせてください。

条件①専門知識がなくても内容が分かる

発注者はIT分野の専門知識に乏しいケースがほとんどです。
そのため、実際にシステムを利用する発注者が理解できる文章で記載されていることは非常に重要です。
書面では、IT分野に関する専門用語や専門知識を極力使わないことを心がけましょう。いくら素晴らしい内容であっても、書面の内容を理解してもらえないことには発注者側で仕上がりがイメージできず、かえって不信感を招いてしまうこともあります。
発注者のみならず、発注者の関係者が読んでも分かりやすい文章になっているか？までを意識するようにしましょう。

条件②課題に対する解決策になっている

要件定義の最終目的は、発注者からの要求をまとめるだけではありません。
発注者が何を求めているかを見定めるのはもちろんのこと、その要求をどのようにして叶えるのかという「答え」＝「課題解決策」にあたる文章を記載し、発注者に理解してもらうことが重要です。
発注者の課題を解決できていない開発は成功とはいえません。
検収時のクレームやムダなコスト増を防ぐため、この「答え」を提案することこそが求められます。

まとめ

本記事では、要件定義をスムーズに進めるための手法や、要件定義書を作成する上でのポイントをご紹介しました。まとめると以下の通りです。

要件定義をスムーズに進めるには？
発注者からヒアリングした内容をもとに、業務フロー・システムフローを把握した上で、必要な機能や非機能をわかりやすくまとめ、発注者・開発者間で認識に齟齬がないかしっかりすり合わせをしましょう。

要件定義書を作成する上でのポイントは？
発注者の要求をもとに「システム開発に至った背景」や「システム開発の目的と目標」を明確化し、そこから業務要件、機能要件、非機能要件を洗い出していきます。
要件定義書を作成する際には、実際にシステムを利用する発注者や発注者の関係者が理解しやすい文章で書くこと、発注者の要求を満たし、課題を解決するための要件定義であることを忘れないようにしましょう。

ご質問・ご要望

要件定義をうまく進め、良い要件定義書を作成するためにおさえておくべき事項は多岐にわたります。
弊社、株式会社QualityCubeでは、要件定義のスペシャリストとして「要件定義代行サービス」を提供しています。

多くの企業様をご支援してきたプロのコンサルタントが、顧客の課題に沿ったヒアリング・調査から要件定義書の作成を代行させていただくことで、QCDバランスを見ながら、プロジェクトの要である要件定義を解決に導きます。ぜひお気軽にお問い合わせください。

より詳細な情報や、貴社の状況に合わせた具体的な提案が必要な場合は、お気軽にご相談ください。例えば、以下のような課題からお問い合わせを頂くケースが多くなってきております。

• 要件定義のできる経験者のリソースが不足している
• 要件定義がうまくいっていないと感じている
• 要件定義の担当者が少ないため、プロジェクト受注を断念するケースがある
• 要件定義工程の外注を検討している

皆様は今までに要件定義工程を経験したことはありますか？
経験がおありの方はどのような感想を持ちましたか？

「難しかった」「うまくできなかった」「大変だった」
などというネガティブコメントが多いのでは？と予想しましたが、実際はどうだったでしょうか？

さて、品質の基本は「顧客満足＝顧客の要求事項を満たしている」ことで、顧客との合意なく先の工程に進むことはできないはずなのですが、要件定義工程でも得てして顧客と合意していない要件に気づかないまま先の工程に進めてしまうことがあります。
このような場合、顧客と未合意のままになっている不確定事項が要件の不備として混入した状態となり、その不備は後で大きな手戻りとなって返ってきます。
皆様が今後に作成する要件定義においては、決してそのようなことにならないよう、最低７回はこの記事を読んでくださいね。７回読めばイヤでも覚えます(笑)

ではさっそく、要件定義の基本について講義を始めていきます。

要件定義とは

講義のはじめですので、まずは、要件定義とは？から確認していきましょう。
さて、システム開発の最初の入り口に要件定義工程がありますが、要件定義工程は具体的に何をする工程でしょうか？
要件を定義する？要件を決めること？何の要件を？どのようにして？・・・要件定義工程はひとことで言えば、『顧客が要求する事項をシステムの要件としてまとめる工程』となります。
それでは、次の章からわからないことを順に紐解いていきましょう。

要件定義で必ず決めること

要件定義では必ず決めることが３つあります。
それは『業務要件』『機能要件』『非機能要件』の３つです。

冒頭で要件の不備の話をしましたが、この３つの要件の中に不備があると、後々に甚大な損失を招いてしまうということで、要件定義で必ず押さえるべきポイントは、実はこの３つのみです。
要件定義には他にも色々なことを書きますが、要件定義の品質はこの３つの要件に左右されるということを、まずは覚えてくださいね。

要件の不備とは

では「要件の不備」とはどのような状態のことを言うのでしょうか？
それは『顧客の要求を適切に抽出できなかったり』『要件の定義が曖昧だったり』といった状態のことを言います。
実は、この状態のまま次工程に進んでしまうことで、システム開発に「要件の不備」が混入した状態となります

要件定義に必要な項目

ではこの章からは、要件定義に必要な項目を確認していきます。
要件定義では、顧客の要求事項について、実現すべき経営目標や業界の動向、現状の問題や目標に向けての課題等を踏まえた上で、抽出すべき要求を実現可能な要件に落とし込んでいきます。
それでは、各要件について一つずつ見ていきましょう。

基本要件の整理

まず、業務内容や目標・課題・問題点等についての現状を把握した上で、顧客要求を精査して、『システム化の目的』や『システム構築方針』を明らかにします。

業務要件の整理

次に*To-Be業務の内容や運用をまとめ、『業務要件』を整理します。

*To-Be＝あるべき姿

機能要件の整理

業務要件の整理が終われば、次に業務要件から人手で実施する業務とシステムを用いる業務に切り分け、システム化の対象となる機能要件を定義していきます。さらに定義した機能間のデータの流れも明確にしていきます。

システム構成と非機能要件の整理

機能要件の整理が終われば、次は機能以外の要件の整理に取り掛かります。
機能以外の要件には『システム構成』と『非機能要件』があります。

要件の合意と申し送り事項の管理

今まで述べてきた顧客の要求から整理した各要件については、確実に顧客との合意を取ることが重要です。
また、結論に至らなかった事項については、『申し送り事項』として管理していきます。
この２点もとても重要なポイントとなりますので、確実に実行するようにしてください。

なお、合意した要件が後々変更となったり、新たに追加要件が発生したりする場合がありますが、その場合は全て『変更管理』として扱うようにします。こちらも重要なポイントですので、しっかりと覚えるようにしてください。

まとめ

以上、要件定義の基本について、要点を絞って解説してきました。
冒頭でも書きましたが、何事もきちんと理解をして自分のものにすることでしか、技術として使いこなすことができませんので、最低７回は繰り返し読んでください。必ずお役に立てることと自負しています。
とはいえ、自分のものになるまである程度の時間がかかるのも事実で、その間はプロに依頼してみるのも一つの手です。

QualityCubeでは、コンサルティング以外にプロジェクトの実務支援も行っており、
要件定義についても代行支援が可能です。（詳細は弊社サイトのサービスページをご覧ください）
また、ほかのお悩みごとに関しても随時、無料相談を受け付けておりますので、お気軽にお問い合わせ頂ければと思います。

最後に・・・我々も日々勉強の毎日を送っています。
皆様のプロジェクトの成功に向けて、これからも共に精進してまいりましょう！

要件定義とは

　要件定義はプロジェクト成功の鍵となる

一般的なウォーターフォール型開発のプロジェクトであれば、要件定義→設計→実装→テスト→リリースの順で進められます。
要件定義は、システム開発者が行う工程です。要件定義をおろそかにすると、プロジェクト自体がリスクを背負うことになると言っても過言ではないでしょう。

要件定義の段階で発注者（顧客）が実装して欲しい機能をヒアリング・調査をしないと顧客の要望がシステム仕様から漏れてしまいます。
要件定義に際して業務フローを作成し、顧客との認識にズレがないか確認しながら進めることが必要です。

対策が練られた要件定義があれば、問題が起きて振り返る際やプロジェクトに新たなメンバーがアサインされたときに、全体を理解できる重要な役割を果たしてくれます。
プロジェクトを始めるときには、プロジェクト全体を成功に導くために、しっかりと要件定義を行うように心掛けましょう。

　成果物は要件定義書

要件定義の成果物は要件定義書と呼ばれる書類です。
要件定義書とは、実装する機能などの整理した情報を顧客に提出し、合意するために開発側が記述するものです。
システム設計する前に作成する書類なので、実装予定の機能についてできる限り詳細に記載しなければなりません。顧客に対する説明と確認のために使用するのも一つの目的です。
そのため、システム開発について専門的な知識がない人に対しても分かりやすいように記述するのも大事です。

最終合意内容は顧客からの要望を考慮し、顧客と協議の上、合意を得たものとなります。顧客と細かく内容についての協議を設けることで、実装後に「イメージしていた機能と違う」などといった不満を避けられます。

要件定義を進める上での注意点や重要ポイント

　 顧客との共通認識を深めるための可視化

要件定義をスムーズに進める際、業務フローを作成します。発注側との認識に齟齬がないかフローを確認しながら進める必要があります。まずは、業務の現状を認識し、課題や問題点について議論しなければなりません。重要になるのが、業務の現状や全体像を把握することです。全体の業務プロセスを把握することで、問題点の洗い出し、その改善策も見つけやすくなります。共通認識を持つことで、発注者・開発側が同じ方向を向いてプロジェクトを推進できます。

業務フロー書き方ガイドはダウンロードしましたか？

初めての方でも業務フローの書き方がわかる、「業務フローの書き方ガイド」を無料でダウンロードが可能です。
是非この機会に業務フローを書いてみましょう。

　 顧客視点を組み入れる

開発者の視点で要求や作業工程を決める要件定義に対して、要求定義は本来、顧客側（発注者）が作成するものです。顧客が書いた内容を参考に、開発者は要件定義に活かすことができます。
顧客からの要求を理解する上で、要求定義書を詳細に精査し要件定義を行っていきます。

顧客が要求定義書を作成していない場合には、顧客に対し開発者がヒアリングを行い、要求を把握する必要があります。

　 要件定義を進める上での必要なスキル磨く

システム開発は、さまざまな人たちとスムーズに連携が取れるように、仕事を円滑に回せる人材が必要です。また、円滑に回せる人材を育てるのも大事です。
日頃から意識してスキルを身につけていけばプロジェクトもスムーズに進めることが可能です。

　 上流工程として要件をまとめる大事な作業

プロジェクトの大元になる工程は「上流工程」です。要件定義は、設計、実装の前工程として行われ、顧客がシステムで何をしたいのか、目的に基づき分析を行うことが大切です。

顧客はシステムに求める要求をより具体化し、開発者はそれを正しく理解します。その要求に対し、開発者は機能や性能といった技術的な要件にまとめていきます。
要件定義の段階で、顧客と開発者がしっかりコミュニケーションをとります。

サービス紹介

要件定義代行

弊社サービス「品質コンサルティング：要件定義代行」についてご紹介します。
要件定義代行とは、要件を取りまとめ、現状の業務フローから、あるべき姿の業務フローを描き要件定義書にまとめます。

現状調査

ヒアリングを行い、現行業務をAs-Isとしてまとめます。

要望ヒアリング

As-Isをもとに要望を抽出し、To-Beとしてまとめます。 現状の姿（As-Is）とあるべき姿（To-Be）に業務フローを描くことで、「Must」「Want」「Never」がまとめやすくなります。

要件定義書作成

To-Be業務フローから業務要件、システムの機能に関する要件（機能要件） システムを運用する上で必要な要件（非機能要件）棚卸します。

導入事例

導入事例を一部ご紹介いたします。

要件定義で起こりがちな問題を解決に導く

要求を盛り込みすぎて要件が固まらない　⇒目的達成のため要件を選別
ユーザー側と開発チームの意思疎通が取れていない　⇒ユーザー側の要件を引き出し表で管理、共有する
必要な要件が漏れてしまい、後から追加することに　⇒定量・定性的な視点から過不足がないか検証

サービスの流れ

弊社サービス要件定義代行は、顧客の課題に沿ったヒアリング・調査から要件定義書作成します。
QCDバランスを見ながらプロジェクトの要である要件定義を解決に導きます。（※お気軽にご相談ください）

まとめ

要件定義を進めるうえでの注意点や、要件定義に必要な重要ポイントをご紹介しました。システム開発を始める段階で、顧客からヒアリングした必要な機能や要求をわかりやすくまとめていく作業が必要です。顧客との認識にズレがないか確認しながら、現状を認識するため業務フローを作成しておくのがスムーズでしょう。

プロジェクトの大元である上流工程の要件定義をきちんと検討しておくことで、顧客が抱えている課題を解決することが可能です。また、要件定義で顧客と開発者がコミュニケーションをとることもプロジェクトの成功へとつながります。

要件定義代行についてお困りのことがございましたら、IT品質コンサルタントである弊社、株式会社QualityCubeにお問い合わせください。