About us 情シスのじかんとは？
About us 情シスのじかんとは？
INDEX
「システムの要件定義ってなに？」
「システム要件定義と要求定義の違いはある？」
上記のような疑問をお持ちの方がいるのではないでしょうか。
システム要件定義とは、システム開発を行う際に実施するべき業務内容を想定して、文書化したものです。また、要求定義は「ユーザーが出したシステム化の要望（要求）の整理」を指しますので、要求定義はシステム要件定義の「最初のSTEP」と考えられます。
本記事では、システム要件定義と関連語句との違いや重要性、要件定義を進めるための方法を紹介しています。システム要件定義を円滑に進めるための事前準備についても解説していますので、ぜひ参考にしてください。
要件定義とは、システム開発において実施すべき業務内容を事前に想定し、わかりやすく文書化するプロセスです。システム開発プロジェクトを進める上で、目的や内容だけでなく、スケジュールや予算、関係者など、考慮すべき要素は数多くあります。
これらを具体的に想定し、文書化しておくことで、プロジェクトを計画通りに進める可能性が高まります。計画通りにプロジェクトを進めることができれば、事業の成功につながります。つまり、要件定義の成否が、プロジェクトの進行や事業の成否に影響を与えるということです。
要件定義の担当者は、一般的にはシステム開発プロジェクトの経験が豊富な人が担当します。開発内容を理解していない人が要件定義を行うと、予想外の問題が発生し、計画通りにプロジェクトが進まず、システム開発が失敗する可能性があります。
要件定義と似た意味を持つ言葉に、要求定義があります。要求定義とは、ユーザーがシステム化を希望する内容を整理することです。要求を整理した後に、システム化の要件定義を行うことで、ユーザーの求めるシステムや事業結果とのズレを抑えられます。
つまり、要求定義は、システム要件定義の最初のSTEPといえるでしょう。
システムの要件定義とソフトウェアの要件定義は、多くの人が混同していることがあります。ソフトウェア要件定義とは、開発するシステムの中で、ソフトウェアに関連する要件を定義する部分を指します。
最近の情報システムでは、特に詳細な要件を確定させる必要があるのは、ソフトウェアです。ソフトウェアには、ユーザーが操作するためのインターフェースやデータを保存するためのデータベースなど、さまざまな要素が含まれています。
つまり、システム要件定義の中でも、最も重要な工程がソフトウェア要件定義と言えるでしょう。
業務要件とは、システム化したい業務の手順や担当者、全体の流れを明確にするために、要件定義の最初の段階で定義されます。
具体的には、業務の詳細な手順や担当者、業務全体の流れなどを明確に決めていきます。ビジネスの要件を明確にすることで、システム化するための基盤が整い、効率的な業務の実現が可能となります。
要件定義をしっかり行わないと、以下の問題が起こる可能性があります。
これらのトラブルを避けるためにも、要件定義は重要です。要件定義は、システム開発の成功にとって鍵となる段階です。また、発注者は開発会社との話し合いを通じて、自分では思いつかなかった必要な機能が明らかになることもあります。
システム要件定義を円滑に進めるための事前準備を紹介します。
それぞれ見ていきましょう。
まず、システム要件定義を担当する人には、一定のITスキルを身につけることが重要です。開発予定のシステムが顧客の業務課題を解決するためにどのような動作や機能を持つのかを理解する必要があります。そのためには、システム開発の経験を積み、システムの設計ができるレベルのスキルが必要です。
もし、担当する人のITスキルが不足している場合は、実際の開発現場を体験させるのが効果的です。一度システム開発プロジェクトに参加することで、開発の進行過程や成果物の作成方法を学ぶことができます。また、システム開発を行っている会社に相談して、どのように開発を進めていくかを聞いてみるのも良いでしょう。
システムの要件定義を行う際には、顧客との対話を通じて、具体的な業務課題の解決策について話し合います。そのため、担当者だけでなく、開発の意思決定権を持つ責任者も、事前に顧客の業務を深く理解しておく必要があります。
例えば、顧客が製造業であれば、工場内の設備や加工技術など、さまざまな業務知識が必要になります。また、生産管理に関する知識や行程管理、資材管理なども必要です。一方、顧客が流通卸売小売業であれば、店舗やECサイトでの販売手法を理解する必要があります。
さらに、受発注業務や電子商取引など、販売管理に関する業務知識も必要になるかもしれません。ITスキルだけでなく、顧客の業務知識を深めることは、要件定義を進める上で不可欠です。業務知識を深めるためには、中小企業診断士の国家資格の学習が効果的です。
また、顧客企業との関係を築いて、業務について教えてもらうことも有効です。現場の実際の声を聞くことで、効率的な学びにつながるからです。営業にコミュニケーションを任せず、開発現場のエンジニア自身が積極的に関係を深めるのが重要です。
要件定義には、ITスキルと業務知識が必要ですが、それだけではトラブルが発生しないとは限りません。実際には、要件定義の漏れによって開発途中で追加要件が発生し、追加予算が必要となり、当初の予算を大幅に超えることや、大幅なスケジュール遅延が起こることがよくあります。
要件定義の漏れを防ぐためには、問題が発生する可能性のあるケースを先読みし、問題が起こらないようにする必要があります。そのためには、要件漏れを防止するためのフレームワークである非機能要件のRASISなど、さまざまな手法を把握しておくことがおすすめです。
本章では、システム要件定義の進め方を紹介します。
順に見ていきましょう。
システム開発プロジェクトが始まる際には、通常、解決したい業務上の問題が存在します。システムがなぜ作られるのか、どのような問題を解決するために開発されるのかを明確にすると、プロジェクトが進行する中で目的を見失うことを防げます。
また、目標が共有されていると、開発中に内容を調整・変更する場合でも、意思決定の際に合意形成に役立ちます。
次に、システムの全体的な構成を明確にしましょう。 「システム」という言葉には、さまざまな意味があります。ウェブサーバー上で動作するウェブシステムもあれば、パソコン上で動作するクライアントシステムもありますし、特定のデバイス上で動作する組み込みシステムもあります。
システム全体の構成として、どのような役割を果たす要素（ユーザーが利用するパソコンやアプリケーションを動作させるウェブサーバーなど）が登場するか、要件定義の段階で詳細に決めておきましょう。
この工程で見落とされたシステム構成要素があった場合、要件外の見積もりとして計上されます。ハードウェアの調達を含む要件の見落としの場合、大きな費用がかかる可能性があるため、全体の構成について十分に検討し、要件定義の見落としを未然に防ぐ必要があります。
システムの全体的な構成が明確になったら、詳細な部分に取り組んでいきましょう。システムの要件定義は、一般的に「機能要件」と「非機能要件」の2つに分けて定義されます。
機能要件は、システムの機能に関する要件を指し、本章ではまずは機能要件の定義について説明します。
それぞれ見ていきましょう。
機能要件は、業務効率に直結するものであり、業務の具体的な改善方法が含まれています。そのため、まずは現在の業務フローを明確にし、システム開発後の理想的な業務モデルを作成します。
現在の業務モデルは「AsIsモデル」と呼ばれ、システム開発後の業務モデルは「ToBeモデル」と呼ばれます。これらの業務モデルを考えることにより、システム開発の効果の予測が容易になります。
業務フローを予測するためには、要件定義の後の設計段階で現在の業務モデルをフローチャートに描くことが行われます。業務フローチャートを作成すると、問題が発生している箇所を特定する際に役立ちます。
要件定義の段階では、業務フローの詳細まで細かく詰めることが理想ですが、最低限、重要なポイントを文書や図表で予測しておくことが良いでしょう。
業務の手順が明確になったら、次は業務に関連する「概念」について整理します。この「概念」とは、情報（データ）を抽象化したもので、主にデータベースの構造（スキーマ）を定義するために使われます。
概念整理には、ER図（ERD、Entity Relationship Diagram）という図表があります。ER図を作成するためのツールもたくさんありますので、使う言語やフレームワーク、データベースの種類によって使い分けるのが一般的です。
概念が明確になったら、業務の流れとは別にデータの流れを定義する場合もあります。具体的には、「どの画面でどの操作をした時に、どのデータがどのように処理されて保存されるか」というデータの流れを描いた図をデータフロー図（DFD、Data Flow Diagram）と呼びます。
設計段階では、データフロー図を詳細に詰め込んで、実際に実装できるレベルまで具体化しますが、要件定義段階では要点を押さえて、プロジェクトの成功に必要なシステムの開発方法が理解できる程度で十分です。
ユーザーとシステムの接点をユーザーインタフェース（UI）と呼びます。情報システムにおけるUIは、主にシステムの画面やデバイスを指します。設計の段階では、画面内にどのような要素があるか、どのようなレイアウトをしているか、どのようなデバイスにするかなどを定義。
ウェブシステム開発では、画面設計のためにヌーラボ社のCacooやAdobe社のXdなどのツールが一般的ですが、昔ながらの方法としてMicrosoft社のExcel（エクセル）も利用できます。要件定義の段階では、存在する画面を想定し、各画面の開発に必要な工数を見積もります。
また、各画面やデバイスがどのようなシチュエーションで利用されるか（ユースケース）の定義も重要です。ユースケースの定義には、UMLを構成する図表のひとつである「ユースケース図」が利用されます。
設計段階では、ユースケース図などを描くことで、ユーザーがシステムとどのように関わるかの詳細を詰めていきますが、要件定義では、大まかな使われ方が想定できる状態であれば十分です。また、ユーザーが直接利用しない「UIが存在しないシステム」もありますので、ユーザーだけでなく、システムと関係する要素との関わり合いを詳細に考える必要があります。
前章の「機能要件」は、具体的に業務をどのように改善するかを示していますが、システム要件には機能要件だけでなく、「非機能要件」と呼ばれる要件も存在します。
「可用性・性能・拡張性・運用・保守性・セキュリティ」など、機能ではない重要な要件が非機能要件に該当します。
これらの非機能要件も、事前に明確にしておきましょう。たとえば、「性能」要件を見落としたせいで処理量が増えすぎ、タスクが永遠に溜まり、最終的にはマシンがクラッシュするというケースがあります。
また、「可用性」要件を見逃した結果、マシンの性能が低くて負荷に耐えられず、サーバーがクラッシュするというケースもあります。
最近では通信回線の安定性やマシンの高性能化により、このような問題は少なくなりましたが、過去には頻繁に起こっていたようです。機能要件だけでなく、非機能要件にも注目し、想像力を働かせてシステム開発上の問題を見つける努力をしましょう。
非機能要件を定義するためには、RASIS（信頼性・可用性・サービス性・完全性・セキュリティ）というフレームワークを使用すると、見つけやすいです。
非機能要件に関しましては、下記記事にて詳しく紹介していますので、ぜひ参考にしてください。
最後に、システム開発プロジェクト全体の予算とスケジュール、メンバー構成やコミュニケーションの取り方について定義します。予算は、これまで詰めてきたシステム要件を基に、必要なハードウェアの調達費用や作業時間を算出し、技術的な難易度や人材の単価を考慮して設定します。
予算を算出するためには、プロジェクトメンバーの人数やアサインする人物なども要件定義段階で決めていかなければなりません。また、プロジェクト推進上必要な事項として、窓口担当者などもできるだけ含めると、プロジェクトの進行がスムーズになります。
人ベースで要件を詰めておくことで、「この人がプロジェクトメンバーとして参加していないため、今回のシステム開発は困難」のような問題を事前に回避できます。
また、作業時間を算出したら、それを基にスケジュールの作成が可能です。要件定義段階では、大まかなスケジュールを作成するのが一般的であり、要件定義が完全に完了した段階で詳細な見積もりと合わせて詳細なスケジュールを作成します。
要件定義書を作成する際には、前述した【STEP1】〜【STEP5】の内容を順番に並べて進めます。要件定義書には、システムの内容からシステム開発プロジェクトの推進に必要な情報、予算まで、さまざまな情報が盛り込まれる予定です。
要件定義書を読むことで、どのようなシステム開発プロジェクトになるのかの概要が一目で分かる状態になっていれば理想的ですが、要件定義書作成のスケジュールによっては、内容が粗いものになることもあります。
要件定義書の品質は、システム開発プロジェクト全体の成功に直結するため、できるだけ正確な内容の要件定義書の作成を心がけましょう。
要件定義には、基本的な知識から具体的な進め方、成果物の項目や失敗しないためのポイントなどが含まれます。要件定義は、システム開発の上流工程であり、システム開発の土台となる重要な工程です。
プロジェクトの成功には、自社の目標を明確に定め、要件定義にしっかりと反映させることが不可欠です。要件定義の進め方や項目の内容を理解し、システム開発を成功に導きましょう。
30秒で理解！フォローして『1日1記事』インプットしよう！
