業務のデジタル化・自動化にはITシステムの導入が不可欠ですが、システムは自社で開発せず、べンダーと呼ばれる開発会社に依頼する企業がほとんどなのではないでしょうか。本記事はそのようなユーザー企業のシステム導入ご担当の方へ向けて、実は意外と知られていない、プロジェクトを成功させるために最も重要な工程「要求定義」について解説いたします。
目次
要求定義をご存知でしょうか
そもそも要求定義という言葉を耳にしたことはあるでしょうか。
システムの導入に関わられたご経験がある方は、似たような言葉で要件定義はご存知かもしれません。
要求定義とはシステムを発注するユーザー企業が、システム導入によって何を叶えたいのかを、システム会社に伝わるように定義することです。
非常に重要であり、プロジェクトの肝になるプロセスです。
しかしながらシステム導入に関わったことのある方でも、要求定義を知らないということがあります。
なぜなら、ユーザー企業とシステム開発会社とのIT知識レベルに大きな差があることがほとんどであるため、システム開発会社が要求定義をユーザー企業へのヒアリングで済ませていることが理由として挙げられます。
システム開発会社がユーザー企業の要望を漏れなく汲み取り、それを実現させる力量があるのでしたらそれでも問題はありません。
しかしながらシステム開発会社とは「構築しやすいシステムを考え、構築するもの」です。
ユーザー企業が言わなくても当然わかるだろうと考え、定義しなかった要望はシステムに反映されることはありません。
そのため、ユーザー企業がもっとも成果の出るシステムを導入したいと考えるのであれば、
ユーザー企業が要求定義というプロセスを主導し、システム開発会社と協力しながら進めるのが望ましいのです。
下図は経済産業省所轄のIPA(独立行政法人 情報処理推進機構)の資料で、システム開発プロセスを表したものです。
要求定義は下図の「企画プロセス」に該当します。
IPAも要求定義の重要性を説いています。
それでは次の章から要求定義の内容と、どのように進めればよいのかを解説していきます。
要求定義の成果物とは
はじめにゴールからお話しします。
要求定義は提案依頼書という文書を成果物として完成させることで完了します。
提案依頼書は英語ではRequest for Proposalと表現し、略してRFPと呼ばれます。
提案依頼書(RFP)はユーザー企業が複数のシステム開発会社の中から依頼先を選定する際にも使用します。
候補先である複数のシステム開発会社に提案依頼書(RFP)を提出し、システム開発会社から具体的な提案や見積もり金額などの回答を受け取ります。
提案依頼書に記載すべき内容例を下図に表しました。(※この限りではありません。)
全体概要 | 会社概要 |
システム導入の背景・目的・ゴール | |
詳細概要 | プロジェクト体制 |
対象範囲 | |
スケジュール | |
予算 | |
機能要件 | データの形式・画面・帳票一覧 |
非機能要件 | セキュリティ・保守・運用性 |
提案依頼事項 (提案して欲しい内容) | システムの構成・性能・品質 |
納期 | |
サポート体制 | |
費用 | |
納入物 | |
その他 要求事項 | テスト |
データ移行 | |
ユーザー教育 | |
補足事項 | 窓口・手続き・契約条件 |
要求定義の進め方
それでは要求定義の成果物である、提案依頼書(RFP)を作成するためにどのような手順で進めればよいのか順に解説していきます。
手順としては下記のとおりです。
- 目的の明確化
- 現状把握と課題抽出(業務フロー図の作成)
- 現状課題と理想の状態のギャップ分析
- 課題に対する解決策の立案
1.目的の明確化
提案依頼書を作成する際にいちばん始めに行うことは、「なぜそのシステムを導入するのか」を明確にすることです。
目的を明確にするためのステップとしてプロジェクト憲章を作成することをお勧めします。
プロジェクト憲章とは、プロジェクトの認知・承認を目的として作成される企画書のことです。
下記が一般的にプロジェクト憲章に記載する内容です。
- プロジェクト名
- プロジェクトの背景
- プロジェクトの目的
- プロジェクトの目標
- 予算
- 成果物
- スコープ
- リスク
- タイムラインとスケジュール
- ステークホルダー
- 体制(役割と責任範囲)
2.現状把握と課題抽出(業務フロー図の作成)
システム導入の目的が明確になりましたら、次のステップとして現状業務の把握を行います。
現状業務の把握は業務フロー図の作成によって行います。
業務フロー図を作成することにより、業務の全体的な流れと関係している部署を視覚的に把握することが可能になります。
また、業務の全体を俯瞰して見ることによって無駄な作業に気が付くこともあり、課題の発見に役立ちます。
業務フロー図はシステム開発会社にも共有します。
3.現状課題と理想の状態のギャップ分析
業務フロー図の作成により現状課題を特定しましたら、次のステップとして現状課題と理想の状態のギャップについて分析します。
分析方法は、まず「理想の状態」から書き出していきます。
理想の状態と聞くと、どこまでも夢が広がってしまいそうですが、ここで重要なことはイメージを言語化することにより、実現可能なシステムになるよう具現化させることが目的です。
これは「As-Is To-Be」と呼ばれる分析手法で、As-Isは「現状課題」、To-Beは「理想の状態」を意味します。
As-Is To-Be分析のポイントはTo-Be(理想の状態)から書き出すことです。
To-Beから書き出すことのメリットは、現状から導き出される達成可能な将来像ではなく、本当に達成したい理想の状態をフラットに考えることができる点です。
そしてAs-Is To-Beを両方書き出すことによりそのギャップが明らかになりますが、このギャップが「取り組むべき課題」ということになります。
4.課題に対する解決策の立案
「取り組むべき課題」が明確になりましたら、解決策についての方法・優先順位などの具体的な策を立てます。
その際、関係者を交えて社内レビューを行うことをお勧めします。第三者の目を通すことにより、漏れや偏り、矛盾がないか確認が出来るため、策案の精度が上がります。
ここまでのステップを踏むことにより、提案依頼書(RFP)に記載すべき項目が埋められるようになります。
要求定義のポイントは5W2H
さて、ここまで要求定義の進め方について解説してきましたが、
全ての手順を通して気をつけていただきたいポイントがあります。
- プロジェクト憲章
- As-Is To-Be分析
- 提案依頼書(RFP)
これらの文書は5W2Hを使って表現することが重要です。
システム開発の工程は、はじめは漠然としたイメージであったものを文書→設計書→プログラムへとデータを変換させながら落とし込んでいく作業になります。
導入するシステムの核となるのが上流工程で作成したこれらの文書ですので、明確に定義して失敗を防ぎましょう。
5W | When(いつ) | 課題解決をいつまでに行うか |
Where(どこで) | どこを対象にするのか | |
Who(誰が) | 課題解決に誰の協力が必要か | |
What(何を) | 解決すべき課題は何か | |
Why(なぜ) | なぜ課題解決したいのか | |
2H | How(どのように) | どのように課題を解決するか |
How much(どのくらい) | 課題解決にどのくらい予算がいるのか |
まとめ
システム導入を考えるユーザー企業の方へ向けて、要求定義の重要性と進め方、ポイントについて解説してきました。
システム開発の業界はまだ歴史が浅く、システム導入に関する手法やルールに関しても曖昧な部分が存在しています。
そのような状況の中で、ユーザー企業がプロジェクトを成功させるためには、システム開発会社に任せきりにせず、主導していくことが重要です。
とは言え、システム開発に関する知識に詳しくないユーザー企業がプロジェクトを主導し、システム開発会社と円滑にコミュニケーションをとることは可能なのでしょうか。
それには二つの方法があります。
ひとつは、ユーザー企業の担当者がシステム導入に必要な教育を受ける。
もうひとつはITコンサルタントにサポートを依頼するという方法です。
どちらも費用はかかりますが、理想の状態に近いシステムを導入できることで得られる成果やプロジェクト失敗による手戻りや損失を考慮すると、メリットの方が上回るのではないでしょうか。
さらに教育サービスやコンサルタントによって享受した知識は企業の財産として受け継いでいくことが可能です。
サポート依頼は早期であるほど得られるメリットが大きいと言えるでしょう。
IT人材育成研修QualityRoomは、様々な業界をサポートしてきたITコンサルタントが監修するIT研修をご用意しています。
ぜひご活用ください。
QualityRoomの要求定義講座詳細はこちら↓↓↓
ユーザー側担当者のための
上流工程実践講座
「要求定義講座」
システム開発のための
文書作成講座
「わかりやすい文書の書き方講座」
業務効率化のための
「業務の可視化」がわかる
「業務フローの書き方ガイド」
システム開発における
最上流工程がわかる
「要求定義の進め方ガイド」
製造業で10年ほど品質管理、品質保証を経験したのち、IT業界にキャリアチェンジ。
業務IT化や、IT人材育成についてなど、IT業界以外の方にもわかりやすい記事を書くことを心掛けています。