要件定義の前の要求定義ができないと炎上する確率が上がる

スポンサードサーチ

企業の経営課題を解決する際に、今ではITを使わないケースはほとんどありません。

また、単なるソリューション導入では経営課題を解決することはできませんので、必ずと言っていいほどシステム開発が必要になります。

どのようなプロジェクトでも、まずは要求定義を行い、その後に要件定義に進みます。

しかし、プロジェクトの進行に慣れていない場合には、この要求定義と要件定義の違いがよくわからない、という方もおられると思います。

そこでは、今回はこの要求定義と要件定義について見ていきたいと思います。

要求定義と要件定義の違いとは？

要件定義という言葉は、様々なプロジェクトに関わった経験があれば、一度は聞いた事があると思いますが、要求定義という言葉はどうでしょうか？

これらの二つの言葉は、語感は似ていますが、以下のように全く異なるものです。

• 要求定義：「クライアント」がプロジェクトで「解決したい課題とゴールを定義」するもの。
• 要件定義：「ベンダー」が「クライアント」の「要求定義」の内容を解決する「方法」を定義するもの。

つまり、要求定義と要件定義では、「誰」が「なんのために」というのが全く異なっており、要求定義は、課題を抱えている「クライアント」が「やりたい事」を決め、要件定義はクライアントの課題を解決する「ベンダー」が「やるべき事」を決めます。

たとえば、「クライアント」があなたに「カレーを作って欲しい」と頼んだとした場合、どのようなカレーを「クライアント」に作ってあげたら良いでしょうか？

カレーを作ると言っても作り方だけで以下のような事が想定されます。

• レトルトカレーをレンジで温めて提供する。
• 野菜と肉、カレールーを買ってきて、調理をして提供する。
• 香辛料から配合して調理して提供する。

これに加えて、提供人数や提供日数、またシーフードカレーやグリーンカレーといったカレーのバリエーション、ライスで食べるのかサフランライスで食べるのかナンで食べるのか、ただ単に単発の食事として提供するのか、業務として提供するのかでも大きく変わります。

このように、要件定義の前に要求定義が必要な理由は、「自分の本当に欲しいものを、他人に正しく伝えることは難しい」からなのです。

要求定義で決めるべきことは？

このように、「自分の本当に欲しいものを、他人に正しく伝えることは難しい」ため、要求定義では以下の3つの項目を決める事が重要です。

プロジェクトで「解決したい課題とゴール」を明確にする

Webサイト構築からSFA導入、ERP導入、CRM導入、ECサイト構築、デジタイゼーション、デジタライゼーション、DX（デジタルトランスフォーメーション）まで、どんなプロジェクトでも「なぜそのプロジェクトを実施するのか」という「解決したい課題とゴール」を明確にしておかなければなりません。

「解決したい課題とゴール」としては、Webサイト構築やECサイト構築による新規顧客の獲得、SFAやERP、CRMの導入による業務改善や業務効率化など、様々なものがあります、ただ単にシステムやソリューションを導入しても改善や効率化は実現することはありません。

また、プロジェクト実施前とプロジェクト実施後に、「何が」、「どうなることで」、「どういった結果が得られるのか」といった具体的な評価軸である「ゴール」を要求定義で決めることで、プロジェクトの成功率があがります。

業務改善や業務効率化といった現状を改善するプロジェクトでは、As-Is（現状）の業務フローを図に起こして課題を特定することで、To-Be（あるべき姿）を導き出して「実現したいゴール」を設定する「As-Is/To-Be分析」も有効です。

非機能要件も必ず明確にする

要求定義で「実現したいゴール」を明確にする事は必須ですが、その際に必ず非機能要件も明確にする事は大変重要です。

非機能要件とは、文字通り機能以外の全ての要件を指します。

例えば、衣料品を店舗で販売している企業が、ECサイトを新規に構築することで、既存顧客だけでなく新たな顧客を獲得して年間売上1億円を目指す、という「実現したいゴール」をプロジェクトのゴールとして想定したとします。

年間1億円の売上と言っても、商品単価が高い商品を販売する場合、リピートユーザーが多い場合、BtoBでの発注が多い場合など、条件により構築するシステムや機能は大きく変わってきます。

また、セキュリティ面における期待値により、システムやインフラで求められる要件が変わってきます。

そのため、要求定義においても非機能要件を必ず明確にする必要があります。

品質と予算、納期を明確にする

プロジェクトを進めるうえで重要なのが、品質と予算、納期を明確にすることです。

理想的なのは、品質を上げ、予算は最小にし、納期も最短にすることです。

しかし、この3つは同時に最大化はできません。

• 予算を最小=品質と機能も最小
• 品質を向上＝予算と納期が増加
• 納期を最短＝予算増加や品質低下を招く

そのため、自社にとっての優先度を見極めて決定をすることが求められます。

要求定義をやらないことによる炎上リスク

要求定義は、プロジェクトを成功に導くために重要な役割を担っていますが、要求定義をやらないことで発生するリスクを理解していないために、要求定義を行わずいきなり要件定義に入ってしまって炎上する、という事が多く発生しています。

解決すべき課題を要求定義に落とし込めずに炎上

上流工程でよくある失敗としては、クライアントの曖昧な要求をそのまま要件定義してしまって、「思っていたものと違う」となる炎上です。

要求定義に求められるのは、「クライアント」が解決したい「明確なゴール」を設定することです。

その際に注意すべきなのは、SIerなどのシステム会社では、システム構築を行う担当者が要求定義も行うことが大半だと思いますが、その担当者がそのシステムを構築することで解決すべき課題や満たすべきゴールを理解していないと、クライアントの言葉を自分勝手に咀嚼して、「システムを作るための要求定義」としてまとめてしまうことがあります。

こうして進められた要求定義は、既にクライアントの希望からずれてしまっているため、その後の要件定義や基本設計、詳細設計ではおおきなズレとなってしまいます。

このズレを放置すると「思っていたものと違うシステムになった」、「システムがいつまでも完成しない」といった事になりかねません。

また、要求定義とは「解決したい課題とゴール」を決めることだと上で書いたように、クライアントとベンダーとで共通認識を持って課題の解決をし、実現したいゴールを目指すことが必要です。

そのため、クライアントとベンダーで決まった内容は、要求定義書に必ず落とし込んで、「解決したい課題とゴール」にプロジェクトが正しく進んでいるのかを、常に確認することが求められます。

利用シーンにマッチしない要件定義で炎上

要求定義と要件定義の違いを理解していない担当者が要求定義を行う事で、クライアントが望んでいない機能を持ったシステムになる可能性もあります。

例えば、ECサイトの注文管理システムにおいて、クライアントは「管理者が管理画面から一括で注文ステータスを注文受付から完了に変更できるようにしたい」とベンダーに伝えたとします。

これに対し、要求定義を行う担当者が要件定義の感覚で「管理者が管理画面でCSVファイルをアップロードし、ステータスを一括更新できる仕様とする」と要求定義書を作成してしまう場合があります。

しかし、一括で注文ステータスを変更するのに、10件程度であればわざわざCSVファイルを使わなくても、管理画面上で一括変換できる方が楽です。

一方、更新したい件数が100件となるとCSVアップロードで行う方が楽な可能性があります。

実際の利用シーンを想定した場合には、「管理画面でも一括更新ができ、CSVアップロードでも一括更新ができる」という事が必要だというのがわかります。

そのため、要求定義段階では、「管理者が管理画面で対象データの注文ステータスを一括更新できる」ことだけを記載し、実現方法については要件定義で検討をする事が必要です。

このように、要求定義と要件定義の違いを理解していない担当者が要求定義を行う事により、実際の利用シーンにマッチしない要求定義を行うと、炎上してしまうリスクが高まります。

クライアントに主体性がなく共通認識ができずに炎上

最初に書いたように、要求定義とは「クライアント」がプロジェクトで「解決したい課題とゴールを定義」するもの、です。

そのため、要求定義ではクライアントが主体性を持って自ら解決したい課題と伝え、ゴールを定義する努力をベンダーに対して行う必要があります。

しかし、クライアント側にシステム発注やシステムに対する専門的な知識がないことで、ベンダーに丸投げをしてくるケースがありますが、これは必ずといっていいほど炎上するリスクが高まります。

ベンダーは、システムの専門家ではあっても、クライアントのビジネスについてはクライアントの方が詳しいのは当たり前ですし、同一業界のシステムを作った事があっても、企業によって業務フローやビジネスルールが異なる部分があるため、全く同じように作ったから問題がない、と言う事は決してありません。

そのため、ベンダー任せにすることで楽にシステムができあがるということはなく、逆に「思っていたものと違うシステムになった」、「システムがいつまでも完成しない」という炎上リスクは高いものになります。

システム発注やシステムに対する専門的な知識がない場合には、ここからサポートをしてくれるベンダーやコンサルタントを頼るのも重要です。

そうした上で、自分たちの要求をきちんと伝えて、課題をどのように解決するのか、またゴールとしてどこを目指すのかをベンダーと共通認識を持って、要求定義から並走していく事が重要です。

「わからないから丸投げする」は、一番、炎上してしまうリスクが高いと考えるべきです。

要件定義を行う前の事前準備

そうは言っても、システム発注やシステムに対する専門的な知識がない場合、自分たちの要求をまとめることすら難しい、という方もおられると思います。

そこで、要求定義を行うための事前準備として、以下をまず行う事をお勧めします。

現状とあるべき姿の比較

「As-Is/To-Be分析」とは、現状と理想像を書き出して課題を特定し、課題を解決するためのアクションプランを策定する分析方法ですが、日本語にすると「現状」と「あるべき姿」を指します。

要求定義は、「クライアント」がプロジェクトで「解決したい課題とゴールを定義」するもの、です。

そのため、「解決したい課題」はどんなものであり、「ゴール」としてどういった「あるべき姿」をイメージしているのかを言語化することが求められます。

この際に、まずは「あるべき姿」を想定し、その後、「現状分析」を行います。

「あるべき姿」から書き出す目的は、現状の延長線上にある達成できそうなゴールを書くのではなく、本当に達成したいゴールを想定するためです。

「あるべき姿」と「現状」を書き出したら、双方を比較して、「あるべき姿」に到達するためにはどういった課題があるのか、「あるべき姿」になるためには何を解決すべきなのか、を検討することで解決すべき課題が見えてきます。　

現状の業務フローの作成

要求定義では、現状の業務をどのように改善する事で課題を解決するのか、というのが必要です。

そのためにはまず、現状の業務を正確に把握する事が必要であり、業務の流れを図式化した業務フロー図の作成は必須です。

営業が見積書を作成して売上が入金されるまで例に考えると、会社としては以下のような業務フローが想定されます。

見積書作成→発注書受領→納品書作成→請求書作成→入金確認

このように、１つの業務であっても、一人の担当者や一部署で完結する事はありません。

そのため、業務フロー図では、業務に対して関係している部署や関係者を明記し、業務の全体像の流れと共に、業務に関係する人を記載する事が求められます。

また、業務フロー図を作成することで、なぜその業務を行なっているのか、なぜその手順でその業務を行なっているのか、本当に必要な業務なのか、というように、業務の棚卸しをすることで業務改善に繋げることもできます。

経営サイドが要求定義に積極的に参加する

要求定義は、システム開発をおこなうためのものではありますが、最終的なプロジェクトのゴールは「クライアントの課題を解決する」ことです。

そのため、要求定義では必ず経営サイドのメンバーが積極的に参加することが、成功への近道です。

システム発注やシステムに対する専門的な知識がなくても、自社の個別業務の課題についてはクライアントの方が良く理解をしています。

これは、クライアントの担当者に担当業務の話を聞くと、その課題点を山ほど答えてくれる事からも明らかです。

しかし、クライアントの担当者は、個別業務の最適化については話ができるのですが、会社全体の業務最適化については話す事はできません。

つまり、企業としての課題解決をするのであれば、部分最適化ではなく、経営サイドのメンバーが全体最適化を想定して課題を明確にする必要があり、経営サイドのメンバーが要求定義に積極的に参加することは必須要件です。

そうでないと、プロジェクトは部分最適化に固執してしまったり、向かうべき方向が違ってしまったりと、失敗する可能性が高くなってしまいます。

コンサルタントに並走してもらうことも検討すべき

要求定義と要件定義の違いから、要求定義で決めるべきこと、要求定義をやらないことによる炎上リスク、要件定義を行う前の事前準備についてみてきました。

プロジェクトを成功に導くためには、要求定義が非常に重要だと言うのはお伝えできたのではないでしょうか？

しかし、自社で要求定義を行う事や、ベンダーとのやりとりに不安がある、というような方もおられると思いますので、そういった場合には、弊社のようなコンサルティング会社を利用することも一手です。

我々は、要求定義だけ、ベンダー選定まで、システムがローンチするまで、ローンチ後の運用も含めて、というように、どの段階でも入って、クライアントが最適な形で課題が解決できることを目指して並走するコンサルティングを行っております。

システム開発において、不安がございます場合には、ぜひ弊社にご相談いただけますと幸いです。

スポンサードサーチ