要件定義とは?重要なポイントから項目まで、わかりやすく解説します



ある日突然上司から、「例の案件の要件定義を、至急作成してくれ」と頼まれたらどうしますか?

まずすべきことは、お客さんの要望を把握する「要求分析」とそれをベースにシステムの全体像を決定する「要件定義」の2つのステップがあることを把握した上で、そのプロセスを上司と共有し、顧客ニーズに関する資料を集めるべきです。

そして顧客(エンドユーザー)は何をしてほしいのか、そのためにどのような機能を実装し、どのように進めていくのかをヒアリングし、決定することです。それを文書に落としたものが、要件定義書です。

IT分野で発生するトラブルの実に40%は、要件定義の不十分さに起因すると言われています。

要件定義は、文章を作成する時の「5W1Hの法則-Who(誰が)、When(いつ)、Where(どこで)、What(なにを)、Why(なぜ)、How(どのように)」に似ています。

本記事では初心者の方向けに、要件定義の大事な視点、要件定義に入れるべき項目、失敗しがちなパターンまで、できるだけわかりやすく解説します。

 

【目次】
1. 要件定義とは
1.1. 要件定義に求められる経営視点とシステム開発視点
1.2. まず最初は現状把握から
1.3. 要件定義書はシステム開発の台帳になる
1.4. 要件定義に求められるスキル
2.要件定義書の書き方
2.1. 基本的な要件定義書の型とは
2.2. 要件定義書に入れる項目
2.3. 良い要件定義書の条件とは
3.要件定義のありがちな失敗パターン
4.要件定義に関するQ&A
5.まとめ

 

1. 要件定義とは

要件定義とは、“顧客(エンドユーザー)の要望を、具体的にどうシステム化するのか”を決める作業です。いわば要件定義は、システム開発のルール作りであり、シナリオになるものです。

要件定義には、経営視点とシステム開発視点の2つの視点が必要です。詳細は後述しますが、構築したシステムが機能し、経営貢献し、依頼主である顧客の顧客満足を実現することが重要です。

要件定義は、クライアントの課題をいかに解決する内容にできるかが重要

 

1-1. 要件定義に求められる経営視点とシステム開発視点
要件定義には、経営視点とシステム開発視点の大きく2つの視点が必要です。

まず経営視点とは、顧客企業のサービス競争力強化という本質的視点とシステム構築にかかるコストに対するリターンの最大化という2つの視点があります。この部分は、営業が担当します。

システム開発における顧客企業のサービス競争力強化とは、システム構築投資が今は重要な経営テーマということです。ユーザーにとって魅力的なサービスを実現する上でシステムは重要な役割を果たしており、システムの機能や使い易さは企業の成長に直結するからです。

コストに対するリターンの最大化とは、システム開発プロジェクトのコストパフォーマンスです。顧客としてはできるだけ安く、早く、高機能でできる方がありがたいのは当然です。

次にシステム開発視点とは、顧客の要求にある機能動作やそれによって引き起こされるユーザーの誤動作までをプロの見地でシミュレーションし、正確なプログラム動作でイメージすることです。この部分は、システム開発者(SE)が担当します。

要件定義には、経営視点とシステム開発視点の2つの視点が重要

 

1-2. まず最初は現状把握から
システム開発案件は、通常営業担当が受注し、依頼主の担当窓口にヒアリングをすることから始まります。下記の「システム開発工程の全体像」を見て頂くとわかると思いますが、リリースまでには長い道のりがあります。

その長い道のりをスムーズに進行できるかどうかは、①の事前情報収集が非常に重要なのです。担当窓口の方が認識されていない経営課題が見つかるかもしれない営業企画書や社内資料などを集めていきます。

そうすることで要件定義ミーティングで提案という形で先手を打って、機能設計の漏れや事後修正トラブルを回避できます。

システム開発工程の全体像
【上流工程】
①事前情報収集(資料集め、ヒアリング他)
②要求の細分化
③要件定義書の作成-要求を実現する機能、予算、人員、スケジュールの共有
④外部設計-ユーザー視点でのユーザーインターフェース設計(画面デザインなど)
⑤内部設計-開発者視点でのプログラミング設計
【下流工程】
⑥プログラミング
⑦単体テスト―個々のプログラミングが要件定義の基準を満たしているかを検証する
⑧結合テスト―複数のプログラムを組み合わせた状態で機能するかどうかを検証する
⑨総合(システム)テスト
⑩運用テスト
⑪リリース(システム移行)
⑫運用・保守

最初にいかに顧客のニーズの全体像を正確に捉えられるかどうかがポイント

※参照コンテンツ/要件定義の進め方

 

1-3. 要件定義書はシステム開発の台帳になる
要件定義書は、システム開発者(SE)によって作成された「システム開発概要」です。本格的にシステム構築作業に入る前に、顧客(エンドユーザー)に提出される最終書類になります。

その目的は、システムに詳しくない顧客が見ても、システムがどのように開発されていくのか、どんな機能が付くのか、わかりやすく理解してもらえることです。

システム構築中の修正や納品後のトラブルを防止するためにも、要件定義書では顧客の要望だけでなく、開発を担当する企業の知見やノウハウ、業界の最新トレンドなどが反映したものが理想です。

 

1-4. 要件定義に求められるスキル
質の高い要件定義は、トラブルを防ぎ、顧客満足を向上させる布石になります。それほど、最上流工程である要件定義は重要です。ここでは、質の高い要件定義を実現するためのスキルについて解説します。

①顧客とのコミュニケーション能力
先述しました通り、まずは顧客の要望を具体的にヒアリングすることが求められます。

②情報収集力
会話による情報収集とは別に、企業Webやパンフレットなどの広報物、営業企画書や社内の打ち合わせ資料など、要件定義に役立つ情報が掲載されている文書を幅広く集め、分析します。

③顧客の要望を可視化する能力
システムは、インターフェイスが非常に重要です。使い易さは機能や正確性と同じぐらい、システムの生命線です。“顧客はどんなシステムを望んでいるのか”、“そのシステムの具体的な使用シーンはどんなイメージなのか”をすり合わせるためには、類似例や画面遷移イメージデザインなどの活用能力が重要になります。

 

2. 要件定義書の書き方

要件定義書には、「業務要件」と「システム要件」の2つの情報群が記載されます。ただ下記の「要件定義書に入れる項目」一覧にあるように、混乱や誤解を回避するために細かく記載するケースが結構あります。

2-1. 基本的な要件定義書の型とは
要件定義書は、システム初心者の方にとっては、難易度の高いものです。ここでは、官公庁などで使用された信頼性の高い要件定義書の実例やサンプルをご紹介します。

農林水産省 動物検疫支援システム オンライン連携機能構築 システム要件定義書
国土交通省 建設キャリアアップシステム 要件定義書
総務省 パッケージソフトに対する要求仕様書(サンプル)
札幌市 文書管理システム再構築に係る設計・開発業務 要件定義書

 

2-2. 要件定義書に入れる項目
要件定義書に入れる項目の典型的な例を、以下に記します。参考にして下さい。

◆要件定義書に入れる要素
【概要】
・背景&目的
・開発概要
・カバーする範囲
・リリース希望時期
・用語定義
【システム要件】
・業務とシステムの関連性
・ハードウェア構成
・ソフトウェア構成
・使用言語、OS他
【性能要件】
・処理能力/ターンアラウンドタイム、スル―プット
・データ量/データ連携日時
・端末台数
・信頼性/サーバ多重化、切替・復旧時間
【インターフェイス】
・システム間インターフェイス
・接続端末インターフェイス
・マンマシンインターフェイス
【機能要件】
・システムが実現する機能一覧
・起動条件
・終了条件
・エラー処理の方針
【運用要件】
・起動/停止の方式
・稼働監視の方式/ジョブ管理システム、障害通知
・システム間接続制御
・セキュリティ/https、SSL
・バッチ/Hulft暗号化
・バックアップ・リカバリの方式/対象、媒体、間隔他
・運用スケジュール/タイムテーブル、計画停止手順、障害時運用
【試験】
・どんな目的のために、どんな試験を、どう行うか
・関係者の役割
【データ移行・リリース】
・移行対象
・データクレンジング

 

2-3. 良い要件定義書の条件
良い要件定義書とは、顧客と開発会社双方が誤解なく、システム開発の全情報を共有できる文書です。特に装備すべき機能項目は漏れなく網羅することが重要です。ポイントを、以下に記します。

①情報カテゴリーごとに、ポイントは箇条書きでわかりやすく表記されている
②ITに詳しくないクライアントでも、わかりやすい表現になっている
③顧客の課題が、システムを活用することで、具体的にどのように解決されるかがわかるように表記されている

 

3. 要件定義のありがちな失敗パターン

要件定義は一番最初の仕切りフェーズであり、その後の工程にも大きな影響を及ぼします。要件定義におけるよくあるトラブルパターンを事前に把握しておくことで、事前に手を打って回避できたり、ダメージを最小限に抑えることができるというメリットがあります。

【要件定義で陥りがちな失敗】
◆目指すべき最終形が正確に共有できていない
◆納期が先に決まっていて、要件定義に十分な時間が取れない
◆要求が過剰に大きくなってしまっている

◆目指すべき最終形が正確に共有できていない
要件定義という作業においては、IT初心者にとっては難しい言葉がたくさん出てきます。例えば「スマホ画像投稿機能」という言葉があったとしても、その画面イメージや操作イメージが共有されていないと、その後に出てくる技術用語がイメージできないことがよくあります。

要件定義作業および要件定義書とは別に、その開発案件のビジネススキームやインターフェースの画面遷移といった補足資料を用意することで、プロジェクトに関わる全員が同じ認識を持てるようになり、スムーズにプロジェクトを進行させることができるようになります。

 

◆納期が先に決まっていて、要件定義に十分な時間が取れない
ある日上司から、「今回の会計システムのリニューアルは3月末までに完成させ、4月にはリリースできるように頼む」といったような依頼が来たら、あなたはどうしますか?

このような話は、日本のビジネスの現場ではよくあることです。ただ納期優先で要件定義を疎かにすると、その後の工程で混乱が生じる可能性が高まります。通常、要件定義にかけるべき時間は全体工程の3分の1と言われています。1年のプロジェクトであれば、理想は4ヶ月かけるべきなのです。

そうはいっても現実には緊急性の高い案件も数多くあり、そういった場合、要件定義はしっかり実施し、その後の開発を多方面に展開する工夫をすることで納期を間に合わせるパターンもあります。

 

◆要求が過剰に大きくなってしまっている
顧客(エンドユーザー)が、予算と機能装備の相場感やITエンジニアの人月によるコスト計上を知らないとよくあるパターンです。システム開発における要件定義段階で、ドキュメント資料だけでなく、似たシステムの開発プロセスや他社先行事例のコスト事例を提示するのは効果的です。

ちなみに、システム業界での有名なトラブル事例を以下記します。

ワークスAPに対する14億円訴訟と情報誌の「経営不振」指摘、その深層を牧野CEOに聞く
IBMに74億円の賠償命令、スルガ銀行裁判の深層
なぜNTT東日本は旭川医科大学に逆転勝訴できたのか。判決文から分かる教訓とは

 

◆顧客のITリテラシーが低い
これは依頼する企業がシステム開発が初めてだったり、その企業の窓口担当者及び上司があまりITに詳しくないパターンです。システム開発に関係する用語には、普段聞き慣れないものも多数あります。そうした時、開発企業にとっては慣れ親しんだ用語でも、顧客企業(エンドユーザー)にとってはほとんど理解されていないという事態にもなりかねません。

ここで一番重要なのは、“なぜその顧客企業は、大金をかけてシステムを構築する必要があるのか?”という動機を正確に把握することです。そして、“今回のシステムが完成することで、今まで○○○だったものが○○○に改善され、○○○という効果を生み出すことがGOALですね”と言えるようになることです。

どんな機能を装備するか、どのプログラミング言語を活用してバグらないソースコードをどう書くかは、その先の話です。極論言えば、初期フェーズは技術用語は顧客企業には見せなくてもいいかも知れません。それよりもビジネススキーム図やインタフェースの画面遷移デザインの方が、顧客企業とGOALをコミットする上で有用なケースが多々あります。

 

4. 要件定義に関するQ&A

ここでは、要件定義に関する代表的なQ&Aを取り上げたいと思います。

・具体的な要件定義のプロセスを教えて下さい
要件定義を行うにあたって、具体的な実務のポイントはどういったものでしょうか。

→要件定義は、顧客とコミュニケーションを図り、これから構築するシステムやソフトウェアについてその機能な仕様をまとめる作業です。その文書が、要件定義書です。その作業に入る前に、発注する顧客側から要望や必要条件をまとめたRFPが出されることもあります。要件定義の作業として、以下が重要なポイントになります。

・構築する業務
・システム仕様
・システム化の範囲と機能の明確化
・実現すべき要件

・要件定義の費用について
システムを開発する前段階の要件定義には、費用がかかるのでしょうか?費用がかかるとすれば、相場はどれぐらいでしょうか。コミュニケーションに時間がかかると、要件定義のコストが上がるリスクを感じています。

→要件定義は、基本的に無料です。要件定義ではリソースも確定させるので、開発会社にとっては精緻な金額見積もり作業的な側面もあります。システム開発に関する売上は、普通人/月(にんげつ)で計算されます。月80万円のITエンジニアを4人で3ヶ月稼働させた場合、80万×4人×3ヶ月で960万かかることになります。こういった人的リソースのシミュレーションも、要件定義の重要な要素です。ここで問題になるのが、その人的リソースのクオリティです。この場合ですと、月80万支払う価値のあるスキルを保有しているエンジニアかどうかを、顧客企業側が事前に面接したりして確認することが結構あります。

 

5. まとめ

要件定義は、多くの人が関わるシステム開発の“仕切り”であり、その案件をベストな状態に導くためのプランニング工程です。特に顧客(エンドユーザー)がしてほしいことを、可視化も含めてブレなく共有できているかどうかが、その後の工程の生産性を大きく左右します。

そのためには、競合企業情報、社内ニーズ、今までの経験値などあらゆる知見を駆使し、顧客にとって価値の高いシステムを実現するための地図になる必要があります。このシステム開発の上流工程である要件定義こそが、開発プロセスの心臓部分なのです。

 

※参考コンテンツ
【要件定義とは】
要件定義とは何?スムーズな進め方や成果物(要件定義書)についても解説
要件定義って何をするの?基礎知識から、具体的な流れまで分かりやすく解説します!
「要件定義」って難しい!?その必要性について考えてみました
【地雷だらけ】“要件定義”とはそもそも何をすることは?【5分で理解】

【要件定義書の書き方】
要件定義書サンプル・書き方|若手プロマネの羅針盤
[Doc]要件定義書テンプレート・要件定義書の書き方-Qiita
「要件定義書」の書き方とは?目的や機能要件・テンプレートも紹介

カテゴリー
企画書用語集
おすすめ記事一覧