プロジェクト開発によるシステム開発を行う時、「要件定義」を作成することが必須です。

「要件定義」とはシステム開発を行う上で必要な上流工程にあたるもので、作業方法を理解していないと重大なトラブルやミスを起こしてしまうことになります。

この記事では、初心者でも理解できる「要件定義」の意味や必要性、必要な基礎知識からスムーズな進め方など徹底解説しています。


要件定義とは

要件定義とは、システム開発などを行う上で必要な機能や性能などを明確に決定する作業のことです。

クライアント側から「こういうシステムを実装してほしい」と要望を受け、双方の認識に間違いがないように打ち合わせを行います。

打ち合わせの中でクライアント側からの要件をまとめ、確認し、要件定義書を作成します。


要件定義の必要性

要件定義がないと、最初にクライアント側から受けた要望と違う成果物を納品してしまう事があるのです。

その結果、違う成果物を納品されたクライアント側から、クレームとして叱責を受けてしまう事になるでしょう。

このようなトラブルを防ぐために、顧客と納得いくまで認識のすり合わせを行うことが重要です。

認識が1つでも違っていたら、顧客が本当にしてほしいシステムが作れません。1つ1つ明確に間違いのないように打ち合わせを行いましょう。

最終的に顧客との認識が合い、要望がまとめられたものを文書化することで「要件定義書」ができます。


要件定義を行うための必要な基礎知識

要件定義を行う前に必要な基礎知識を学びましょう。しっかり学ぶ事で、要件定義の作業がスムーズに進めることができるようになります。

要件定義を行う時、必ず要求定義書の確認を行いましょう。

要求定義とは、クライアント側から「この機能を実装してほしい」などといった要望、どういったものが必要なのかという要求を確認し、まとめたものです。

この要求定義を文書化したものが「要求定義書」といいます。

求められた内容がそのままだとクライアント側からの要求で作業担当の開発者が「できる」、「できない」がまとまっていません。

クライアント側から要求された内容を確認し、実装可能か、本当に必要な機能か、不要な機能かを選別し、整理することが要求定義の作業工程です。

ここで失敗するとクライアント側とのトラブルが起きますので、本当にできるのかをきちんと明確にしておきましょう。


要件定義は4つの工程で構成されている

要件定義は、要件定義・設計・製造・検査の4つの工程で構成されています。プロジェクト開発などのシステム開発を行う上で、とても大事な工程です。

その中でも要件定義は後に続く3つの工程に大きく影響を及ぼしますので、間違ってしまうとすべての工程が無駄になってしまいます。

それぞれの工程は次の通りです。


要件定義

前述した通り、クライアント側からの要求定義書を確認し、打ち合わせなどによるヒアリングで双方の認識が合っているかどうか確認しましょう。

双方の合意でまとめて要件定義書を作成してください。


設計

要件定義書ができたら、設計の工程です。システム化に必要なシステム全体の設計を行います。


製造

システム全体の設計ができたら、この設計を元にプログラミング等で製造を行います。


検査

製造を終えたシステムを不備がないかどうか、検査やテストを行いましょう。要件定義書に沿って、満たしているかどうかをチェックしてください。


要件定義を行うために必要なスキル

要件定義といった上流工程を行うために必要なスキルがあります。

必要なスキルはヒアリング力・ドキュメント作成力・設計書作成スキル・マネジメント力の4つです。

対人での交渉が必要になる場面が多く、書類作成や、明確な設計書作成といった重要なスキルが必要になります。スキルの解説は次の通りです。


ヒアリング力

まずはヒアリング力について解説しましょう。

ヒアリング力はとても重要なスキルで、クライアント側へのヒアリングがうまくできないとしっかりとした整理、決定ができません。

クライアント側からの要求定義が決まった後、要件定義書を作成するためにクライアント側との打ち合わせを行います。

打ち合わせの中でクライアント側が本当に求めている要望を1つ1つ丁寧に聞き出し、システム化にあたって、どういうシステムの形になるかまとめていきましょう。

ヒアリングしていく上で、クライアント側の要望からシステム化が可能かどうか、内容をわかりやすく説明する能力が必要になります。

開発者による専門性の高い説明ではなく、誰でもわかりやすい表現で説明することが大事です。


ドキュメント作成力

要件定義を行う時、要件定義書を作成するためのドキュメント作成が必要になります。プロジェクト開発などのシステム開発現場では最重要書類の1つなのです。

要件定義書を作成する時に、注意することは誰が見てもわかりやすいように曖昧な表現を避けます。また見出しをつける時、多すぎないように注意しましょう。


設計書作成スキル

要件定義書ができあがり、次に行うのは基本設計です。要件定義書をもとにプログラミング等に必要な基本設計書を作ります。

この基本設計書がわかりやすく書かれていない、要件定義書とは違う設計になっていると次の製造工程で大きな影響を及ぼしてしまうことがあります。

さらにプロジェクト開発が失敗する原因になることもあるのです。

そのため、要件定義書としっかり見比べながら、わかりやすく丁寧に設計書を作成するようにしましょう。


マネジメント力

要件定義書などの上流工程を担当する時、プロジェクト開発などのチームリーダーを務めることが多くなります。

責任が大変重くなりますがその分、チームメンバーをまとめる力が必要です。

要件定義書や基本設計書がどれだけわかりやすくまとめられていても、メンバーとのコミュニケーションがきちんと取れていないと失敗しやすくなります。

問題が起きた場合、的確な指示を円滑に行うためにも日頃から定期的な打ち合わせ、メンバーの個別面談を設けましょう。

そうすることで、それぞれのメンバーの状態を把握できるようにしておくのです。


要件定義工程での進め方

要件定義工程には、大きく分けて要件定義の計画作成・業務要件の整理・システム要件の整理・見積りという4つの作業があります。

ここでは4つの作業の流れについて解説していきます。


要件定義の計画作成

クライアント側からの要求定義書をもとに、システム化の方針を明確にしていきましょう。

システム化にあたって、クライアント側との打ち合わせ・現状調査を行います。

その前に、いつから・どこから・誰が・どんな情報が・なぜ必要かの理由・どのくらいで・どうしたいかの再確認を行ってください。

ここがしっかりできていないと、次の工程に進めることができないので徹底した確認をしておきましょう。

情報を整理した上で、要件定義のスケジュールや体制図などをまとめて要件定義計画書を作成します。


業務要件の整理

要件定義の作業の最初に、業務要件の整理を行います。

この時点では、クライアント側も開発者も「どういうシステムの機能が必要なのか」が想像することができません。

そのため、クライアント側の業務を整理していくことが重要です。

細かく分けて、現行業務の整理・ヒアリング実施と課題分析・新しい業務の検討・システム化範囲の検討の4つの作業があります。

4つの作業については次の通りです。


現行業務の整理

クライアント側の業務で、理想の業務と現状の業務の違いを「業務課題」といいます。

この課題をしっかり洗い出すために、現行業務の整理が重要です。

現行業務の整理を行うとき、業務フローを作成し、業務フローの詳細を記載した業務処理定義書を作成してください。

現行業務の整理にあたり、現行業務に使われているシステムがある場合、調査を行い、システム機能について業務フローに追記していく必要があります。


ヒアリング実施と課題分析

クライアント側の業務部門にヒアリングしながら、課題を分析し、対策を検討します。


ヒアリングの実施

業務上に問題がある箇所について、クライアント側に詳しくヒアリングを行ってください。

業務を行う上での問題、それに伴う影響や原因、望ましい解決策などといった重要な項目をしっかり確認し、ヒアリングした結果の一覧表にまとめていきましょう。


問題の分析

ヒアリングの結果から、問題や影響などを整理します。

どうしてこうなったのか、問題を確認し、疑問点を出していきましょう。

業務に影響を及ぼす業務プロセスやシステムなどあらゆる分野から考えていき、解決策を検討できるように整理します。


解決策の検討

問題の分析で出てきた原因についての解決策を検討します。


新しい業務の検討

現行業務での対策を検討したものから、新業務フローを作成しましょう。


システム化範囲の検討

新業務フローを作成した後、システム要件の整理のための要望を受けた内容を確認してください。

システム化範囲が最初に確認した範囲と変わっていることがあるため、確認する必要があります。


システム要件の整理

システム化の範囲、プラットフォームの変更の有無を再検討し、システムの機能要件と非機能要件の整理を行ってください。


プラットフォームの検討

システム機能を提供するためのプラットフォームに対し、システム化範囲の検討の結果からプラットフォームの変更がないかを再検討します。


機能要件と非機能要件の整理

新しい業務を実現するため、システム要件を整理しましょう。

業務を代行、支援してくれる機能のことを機能要件といい、性能や操作性などを除く要件のことを非機能要件といいます。


要件定義のまとめと見積り

要件定義書の作成、基本設計以降の計画作成、見積りの算出を行います。


要件定義書の作成

これまでの業務要件の整理からシステム要件までのまとめとして、要件定義書を作成しましょう。

業務要件の定義・機能要件の定義・非機能要件の定義の大きな見出しに分けて整理します。


基本設計以降の計画作成

基本設計以降の作業を整理し、スケジュールを組み、計画書を作成してください。


見積り

システム開発の見積もりを算出します。

システム化に必要な予算額をオーバーしていないか、確認しましょう。

見積の算出には、パラメトリック見積りがよく使われています。パラメトリック見積りは機能数や画面数などに係数をかけて見積りを算出する方法です。

この方法はクライアント側から信頼度が高く、理解が得られやすい方法なのです。


要件定義を行う上で重要な3つのポイント

ここまで要件定義について解説してきましたが、プロジェクト開発の成否に重要なポイントが3つあります。


現行業務フローと現行システム設計書を把握する

要求定義書を元に要件定義書を作成する時、重要になるのが現行業務フローと現行システム設計書です。

クライアント側が現在使っている業務フローとシステムの設計書がしっかりしていないと、要件定義がスムーズにいかないため、必ず確認しましょう。

もし情報の中身が雑だった場合、業務フローとシステム設計書の実態を知るために関係者にヒアリングを行い、説明してもらう必要が出てきます。


打ち合わせ回数をどのくらいするかを決める

クライアント側の都合を知らずに打ち合わせ回数を決めてしまうと、打ち合わせ回数が足りず、要件を決める事ができないといったトラブルが発生します。

そういったトラブルを防ぐため、クライアント側と調整し、業務や機能を分析した上で打ち合わせ回数を決めることが重要です。

業務や機能を分析していくと疑問点があがることがあるので、そういった問題や手間を考えて打ち合わせ内容を決めていくと、打ち合わせ回数を決めやすくなります。


役割分担を決める時は遠慮しない事

本来、開発者が担当しないはずの役割をクライアント側から受けてしまい、進めるべき仕事ができなくなるケースがあります。

そういったケースを避けるため、役割分担を明確にし、文書化しておく事が重要です。その上で、本来担当すべき開発者に作業の割り当てを行ってください。

もしクライアント側からどうしても頼みたい役割が発生した場合は、開発者のスケジュールへの影響を必ず考慮し、割り当てましょう。


まとめ

要件定義は数多くの開発者にとって、難しい工程です。

上流工程ということもあり、1つのミスが重大なトラブルを起こす要因になります。

しっかりとした要件定義の基礎知識を身に着け、クライアント側とうまく進めるための手順を学んだ上で要件定義に活用しましょう。

また、要件定義を進める上でチームメンバーと綿密なコミュニケーションを取ってください。

クライアント側とうまく打ち合わせしていくことで、要件定義がスムーズに進むことができます。

きちんとした手順でクライアント側、開発チームで確認、修正、作成を繰り返すことで満足度の高い要件定義書ができあがるのです。

是非、徹底的なヒアリング・計画・対策を行ってみてください。