企画書作成.COM

※0円で無料コンサルあり！公式サイトと求人サイトを兼ねたホームページ制作
最近、ホームページの重要性が増しています。特に自社のサービス紹介だけでなく、新卒・中途の人材採用に効果のあるホームページが注目されています。リクルートで長年ノウハウを積んだプロが、無料でコンサルします。
☞ホームページの無料コンサルはこちら

要件定義とは、システム開発プロジェクトなどで、クライアントの要望を実現するための機能や要求をまとめていく作業です。この作業の成果物が、要件定義書になります。IT分野のトラブルの40％は要件定義の不十分さに起因するといわれるほど重要です。本記事では、要件定義の重要性や書き方、進め方や失敗パターンを、詳しく解説します。

① 要件定義はなぜ重要なのか？
② 要件定義書の作成プロセスとは？
③ 要件定義書には何を書けばいい？
④ ありがちな失敗パターンを知っておこう

 

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

そもそも、システム開発などで、なぜ要件定義という作業を行うのでしょうか？ここでは、なぜ重要なのかを解説します。

1-1. 全員の共通認識がブレないために

 

要件定義とは、“顧客（エンドユーザー）の要望を実現するために、具体的にどうシステム化するのか”を決める作業です。

ITシステムの開発は、「内製」と「外注」という2つの方法があります。上の図のように外注で大規模なシステム開発の場合、クライアントと一次請け、二次請け、三次請けが関わります。その場合、関わる全員が「システムの目的」「装備すべき機能」「納期」といった重要事項を共有するために、要件定義書はとても重要なのです。

1-2. FIX後の横暴な修正を防止する

 

IT業界の開発現場の常識として、疲弊の原因となる象徴的な言葉があります。それは、「丸投げ」と「無茶振り」です。漠然とした無謀な指示が下りてきて、現場のメンバーが決められた納期を守るために徹夜が続く…。システム開発業界において、そんな現象が当たり前だった時代がありました。

しかしコンプライアンスの順守が求められる今、そういった常識は通用しなくなりつつあります。要件定義の作業を経て作成された要件定義書は、そういった混乱を防止する役目を果たしてくれます。なぜなら要件定義書以降に発生した事項に関しては、追加料金と追加リソースの補填、スケジュールの修正の必要性を明示しやすいからです。

1-3. システム開発の全体像

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

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

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

1-3-1. 上流工程

① 事前情報収集（資料集め、ヒアリング他）
② 要求の細分化
③ 要件定義書の作成－要求を実現する機能、予算、人員、スケジュールの共有
④ 外部設計－ユーザー視点でのユーザーインターフェース設計（画面デザインなど）
⑤ 内部設計－開発者視点でのプログラミング設計

1-3-2. 下流工程

⑥ プログラミング
⑦ 単体テスト―個々のプログラミングが要件定義の基準を満たしているかを検証する
⑧ 結合テスト―複数のプログラムを組み合わせた状態で機能するかどうかを検証する
⑨ 総合（システム）テスト
⑩ 運用テスト
⑪ リリース（システム移行）
⑫ 運用・保守

1-4. 要件定義書はシステム開発の台帳になる

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

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

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

1-5. 求められるスキル

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

1-5-1. 顧客とのコミュニケーション能力

先述しました通り、まずは顧客の要望を具体的にヒアリングすることが求められます。

1-5-2. 情報収集力

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

1-5-3. 顧客の要望を可視化する能力

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

 

2. 要件定義の進め方

では、要件定義はどのように進めればよいのでしょうか。ここでは、具体的な進め方を説明します。

2-1. 顧客の状況を把握するためにヒアリング

① 顧客企業の階層別にインタビューする
② 顕在化している課題と潜在的な課題を見つける
③ おさえるべき機能要件や非機能要件を細かく確認する
④「顧客のシステム完成イメージ」と「システムのあるべき姿」は異なることがある

2-2. 顧客のニーズを整理する

① 顧客の言い分を鵜呑みにするのではなく、現象面としての事実を重要視する
② 顧客が認識している問題点を全て列挙し、解決策を模索する
③ 問題の発生原因を全てテキスト化し、文書化していく
④ 特に問題点が数字化されている場合は、深く掘り下げて解決策パターンを作成する

2-3. 要件定義を作成する

① ITにあまり詳しくない顧客企業の経営陣が見ても、スピーディに理解できるように表記する
② 今回構築するシステムの概要と目的
③ システムが装備する機能
④ システム構築の全体業務フロー
⑤ ユーザーの要求と必須要件
⑥ 具体的な機能要件詳細と非機能要件詳細

 

3. 要件定義書の書き方

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

3-1. 基本的な要件定義書の型とは

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

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

 

3-2. 入れるべき項目

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

3-2-1. 概要

① 背景＆目的
② 開発概要
③ カバーする範囲
④ リリース希望時期
⑤ 用語定義

3-2-2. システム要件

① 業務とシステムの関連性
② ハードウェア構成
③ ソフトウェア構成
④ 使用言語、OS他

3-2-3. 性能要件

① 処理能力／ターンアラウンドタイム、スル―プット
② データ量／データ連携日時
③ 端末台数
④ 信頼性／サーバ多重化、切替・復旧時間

3-2-4. インターフェイス

① システム間インターフェイス
② 接続端末インターフェイス
③ マンマシンインターフェイス

3-2-5. 機能要件

① システムが実現する機能一覧
② 起動条件
③ 終了条件
④ エラー処理の方針

3-2-6. 運用要件

① 起動／停止の方式
② 稼働監視の方式／ジョブ管理システム、障害通知
③ システム間接続制御
④ セキュリティ／https、SSL
⑤ バッチ／Hulft暗号化
⑥ バックアップ・リカバリの方式／対象、媒体、間隔他
⑦ 運用スケジュール／タイムテーブル、計画停止手順、障害時運用

3-2-7. 試験

① どんな目的のために、どんな試験を、どう行うか
② 関係者の役割

3-2-8. データ移行・リリース

① 移行対象
② データクレンジング

2-3. 良い要件定義書の条件

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

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

 

3. 要件定義の進め方

では、要件定義はどのように進めればよいのでしょうか。以下、具体的な進め方を説明します。

3-1. 顧客の状況を把握するためにヒアリング

① 顧客企業の階層別にインタビューする
② 顕在化している課題と潜在的な課題を見つける
③ おさえるべき機能要件や非機能要件を細かく確認する
④「顧客のシステム完成イメージ」と「システムのあるべき姿」は異なることがある

3-2. 顧客のニーズを整理する

① 顧客の言い分を鵜呑みにするのではなく、現象面としての事実を重要視する
② 顧客が認識している問題点を全て列挙し、解決策を模索する
③ 問題の発生原因を全てテキスト化し、文書化していく
④ 特に問題点が数字化されている場合は、深く掘り下げて解決策パターンを作成する

3-3. 要件定義を作成する

① ITにあまり詳しくない顧客企業の経営陣が見ても、スピーディに理解できるように表記する
② 今回構築するシステムの概要と目的
③ システムが装備する機能
④ システム構築の全体業務フロー
⑤ ユーザーの要求と必須要件
⑥ 具体的な機能要件詳細と非機能要件詳細

 

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

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

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

4-1. 目指すべき最終形が正確に共有できていない

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

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

 

4-2. 納期が先に決まっていて、要件定義に十分な時間が取れない

ある日上司から、「今回の会計システムのリニューアルは3月末までに完成させ、4月にはリリースできるように頼む」といったような依頼が来たら、あなたはどうしますか？

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

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

 

4-3. 要求が過剰に大きくなってしまっている

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

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

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

 

4-4. 顧客のITリテラシーが低い

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

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

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

 

◆YouTube解決アドバイス／『出来るエンジニアは要件定義でコレを聞く』

① 要件定義とは、開発に入る前に「どういうものを作りますよ」と合意するためのもの
② プロジェクトが遅れる理由は、4割が要件定義が原因
③ システムの完成形が本当に決まるのは、プログラムが完成したとき
④ 全ての炎上は「期待のすれ違い」から起こり、「期待値」を明確にするのが「要件定義」
⑤ 要件定義は全員が持つべき必須の技術で、センス良い要件定義ができる人材は貴重
⑥ 要件定義から開発まで一貫してできる人は、独立がしやすい
⑦ 要件定義が上手い人がチームに多いと、サービスの成功率が一気に上がる
⑧ 要件定義の上手い人は、発注者に「背景」を丁寧にヒアリングしている
⑨ 仕事はいい悪いではなく、モテるかモテないか、トラブルになった時点で全員負け
＜開発の背景を聞くコツ＞
① 相手に本当に興味を持って、勉強したいという気持ちで聞く
② プロジェクトに対して真剣で、みんなを成功させたいという姿勢を見せる
③ 何でも話せるような良好な関係を築くために、雑談をする

 

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

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

5-1. 具体的な要件定義のプロセスを教えて下さい

要件定義を行うにあたって、具体的な実務のポイントはどういったものでしょうか。

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

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

5-2. 要件定義の費用について

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

→要件定義は、基本的に無料です。要件定義ではリソースも確定させるので、開発会社にとっては精緻な金額見積もり作業的な側面もあります。システム開発に関する売上は、普通人／月（にんげつ）で計算されます。月80万円のITエンジニアを4人で3ヶ月稼働させた場合、80万×4人×3ヶ月で960万かかることになります。

こういった人的リソースのシミュレーションも、要件定義の重要な要素です。ここで問題になるのが、その人的リソースのクオリティです。この場合ですと、月80万支払う価値のあるスキルを保有しているエンジニアかどうかを、顧客企業側が事前に面接したりして確認することが結構あります。

 

6. まとめ

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

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