システム開発における要件定義の進め方―失敗しないための注意点を解説

要件定義とは

要件定義とは、端的に言えばシステム開発における発注側のリクエストを開発者としての観点からまとめる作業のことで、システムを開発する工数において20％程度を占める重要な工程です。

発注者の要望を一点一画おろそかにせず開発者である受注側が把握して、テクニカルな知識を活用することによって、全部の機能としてまとめて要件定義書を創出します。

システムを必要としているのは発注側であり、どういったことをシステムで解決したいかといった要望は発注側でしか分かりません。

発注側は、その要望を分かりやすく受注側に知らせて要件定義を進捗させていかなければなりません。このようなわけで、テクニカルな知識やスキルがない発注側がシステムに何を要望しているかといった仕様の定義を「要求定義」といいます。

要件定義は要求定義を基礎としてシステム開発の第一歩を踏み出すために、どんなことがあっても絶対にする必要がある過程で、受注側と発注側の両者がやるべきことをやらなければなりません。

一方、要件定義は発注側の要求定義を充足しなければならないため、受注側は要求定義を余すことなくきっちりと把握します。受注側は発注側の要望をきっちりと把握して、テクニカルな知識や技術を活用して要望を具現化できるシステムを開発するために要件定義を進めていくのです。

開発の成功を左右する発注側の最も重要な仕事

要件定義は開発の完遂を方向づける重要度が最も高いプロセスと言っても大げさな言い方ではありません。

要件定義を取りこぼすことなく決定していることで、作業が進行中における変更を必要最低限にできるため、時間とコストが抑制され納期に間に合うようにプロジェクトが進められるのです。

発注側が誤解を招きやすいケースとして、要求定義を渡せば受注側に要件定義を任せきりにすればいいと思い込んでいるケースがあります。

要件定義に関してこのような認識であった場合、受注側にきちんと伝わっていると考えていた要望が伝わっていないため、問題が表面化した時点で初めて後悔することになるのです。

要件定義の手違いによって、仮に最初からやり直すことになった場合はコストと時間が必要となります。

要件定義と要求定義・基本設計との相違点

要件定義と考え違いをしがちな用語として要求定義と基本設計があります。要件定義との相違点はどういった点であるかを確かめておきましょう。

• 要件定義と要求定義の違い

  要求定義とはシステム開発において発注側の希望を確かめる作業のことです。要件定義が発注側の要求を前提として具体的な仕様が決定される作業であるのに対し、要求定義は発注側がシステム開発において要求していることをまとめ上げる作業を指しています。

• 要件定義と基本設計の違い

  基本設計とは要件定義の内容に基づいて、機能ごとにどういった開発を進めていくのかを決定する作業のことです。

要件定義の進め方

システム開発を外部へ発注する場合であったとしても、要件定義の手順を発注側で押さえておくことは重要です。手順を押さえておくことによって、現在どういった段階であるのかを理解でき、何の心配もなく受注側に任せられることになります。

システムについてテクニカルな知識が足りないことを自覚している発注側は、要件定義において受注側に一任してしまう可能性があるため注意が必要です。

基本的な取り組み姿勢で要件定義をこなしていくわけですが、実際の作業における要件定義の手順も発注側と受注側で自分が行うべきことをこなしていく必要があります。

実現したいことをヒアリング

要件定義で手始めに行動へと移されるのが受注側による要求のヒアリングで、受注側は発注側の明確でない要求にもう一歩踏み込むことを目的として実施します。このフェーズで満足のいく意見調整を行い、内容をコーディネートしていくことが重要となるでしょう。

ヒアリングはテクニカルな知識をもっている受注側から発注側に対して実施されますが、発注側は受け身ではなく共同で進めているという意識が重要です。システムの必要性を有しているのは発注側であるため、要求定義の情報を与えるためのヒアリングであることを強く意識して作業をおこないましょう。

発注側としては要求を受注側に伝えられるよう、理想的なゴールをイメージしておくことが大切です。ヒアリングにおいての基本姿勢も、受注側と発注側が協力して取り組みを進める作業であるという点においてぶれない軸があります。

実現したいことの細分化

次にヒアリングによってまとめられた要求を細分化して要件・内容を決定して、リクエスト通りのシステムとして動作させるために必要不可欠な機能を考証する工程です。

この工程では、現状の懸念材料について詳しく追求して解決手段をじっくりと考えることによって、機能の絶対必要な要件をきめ細かにまとめ上げる作業を行います。

発注側としてはヒアリングの時点で要求を伝えたからと安心せずに、細分化された要件にも目を通して見落としが無いかしっかりと確認する必要があります。ただし、全ての要求を必ずしもシステム化できるわけではないといった点を考慮した上で進めていきましょう。

要望の細分化は受注側がメインとなりますが、要件定義を行う上での基本となる姿勢である受注側と発注側が協力して取り組みを進める作業であることを忘れてはなりません。

要件定義書の作成

最終的に受注側がこれまで発注側からヒアリングして、細分化された要求をシステマティックに問題点の洗い出しをして要件定義書を作成します。発注側としてはシステムに求めている要求事項とそれに対して必要となる要件について、納得がいくまで確かめることが大切です。

受注側は単に発注側の要求だけを整理するのではなく、ビジネスを取り巻く環境を含めてそのシステムで解決したいゴールを理解し、提案する必要があります。発注側はビジネスに理解がある受注側を選定すると、企画の壁打ちが進むことでより理想とするサービスになります。

発注側における注意点

要件定義において発注側がやるべきことの基本原則は受注側への要望のアナウンスです。受注側との不整合がフォローされないまま気づくことなく、プロジェクトが進捗してしまうと場合によってはシステム開発の見直しが発生してしまいます。

また社外の受注側だけでなく社内においても注意が必要です。現状の業務フローのブラッシュアップをリクエストしている社内の要望とは異なった方向性で、システム開発が進捗していたといったミスが発生しないように、社内の見解を統一することで要件定義する前に問題点を明らかにしておくことも大切です。

システムについての価値判断を統一

システム化する目的やどこまでの業務範囲をシステム化するのかといった、社内における主義主張を統一しておく必要があります。要件定義では受注側から機能要件と非機能要件の提言を受けたうえで見極めをつけていく局面も生じることがあります。

社内における主義主張は要件定義における判断のバロメーターとなりますので、主義主張を統一しておくことが重要となります。

解決すべき問題の明確化

現状における情報収集活動は多大な労力がかかってしまうため、業務フローと業務要件の整理は要件定義より前にしておくのがベストです。提案依頼書（Request for Proposal）を作成するのも良いでしょう。

現場における必要性を正確に把握

現状把握には現場のデータや意見が重要です。現場の現状調査やデータ分析にもとづいて、現状を正確に把握することが大切です。また実務的な問題点や課題を感じているのは現場担当者であり、必要に応じてヒアリングやアンケートを実施しましょう。

現場のニーズを事細かに汲み取ることによって、要件定義で受注側に伝える際に情報が歪曲しないようにします。

受注側における注意点

要件定義において基本的に受注側がなすべきことは発注側を考慮しておくことです。受注側はシステムについての知識が豊かですので、どういった問題点が存在しているのかといった点については専門的な立ち位置で解決手段を測り知れます。

しかし、事前調査における想定はあくまでも想定であるため、発注側の要望と必ずしも合致するとは限らないからです。

本当の要望をピックアップ

発注側は専門家でない場合が多いため、自分自身で理解することが可能である領域でしか要望を思い付かないことがあります。それゆえに現行システムなどは事前に調査しておく必要があるのです。

事前調査において抜け落ちがある場合はヒアリングで知りたいことを聞いてさぐり出すことが必要となります。発注側における本来の要望を聞いてさぐり出すためには、要望を聞くだけでなく要望を導き出すスタンスで要件定義することが大切です。

具体化することが可能であるかを判断

発注側のありとあらゆる要望をひとつの構図に当てはめられるとは限りません。また、システム化がマネジメントにとって最適解ではないこともあります。

受注側は発注側の要望を何から何まで実現させようとするのではなく、コスト・時間・技術的な側面から発注側と判断しながら要件定義していくといった取り組み姿勢が重要です。

要領を得たドキュメントの作成

要件定義書やワイヤーフレームといった関係者全員の理解にボタンの掛け違いが生じないよう要領を得た資料を作成することが大切です。発注側と受注側が要件定義をする際に限られた時間を有効利用するために、意見調整などの日程管理も重要となります。

担当者を明らかなものとする

要件定義をする際の発注側と受注側のやるべきことや、誰が何を準備するかといった担当者を明らかにしておきましょう。たとえば現行システム業務の整理・将来のキャリアビジョンをあれこれ考えて定めることは、受注側ではなく発注側がしなければいけない作業となります。

また発注側の担当者をしっかり把握しておかないと、作業を進行している際に二度手間となってしまい、本来必要とされていない作業と時間を無駄遣いすることになります。受注側は発注側の担当者を明らかにするとともに、受注側の担当者についても発注側へ明確に伝えておきます。

失敗しないためのポイント

要件定義の工程において、どういったことに意識を傾けておくべきかについて、ミスをしないために鍵となる重要な点をまとめてみました。

システム開発で実現したいことを明らかに

システム開発が必要な理由は何なのか、システムを導入する目的を誰の目にも明らかにしておくことが大切です。そうすることによって、どういった機能を搭載するべきかといったシステム開発の優先順位が明らかになります。

発注側と受注側における共通した認識

発注側と受注側でお互いの認識を統一することも大切にしたいポイントです。開発途中や開発後に思っていたのと違ったと後悔しないよう、システムに期待することを共有することで意見の食い違いがないように話し合いましょう。

スケジュールやロードマップの共有

要件定義においてミスしないためには、日程管理やスタートアップ後の体制についてのプランニングも大切です。必要不可欠な要件や機能に基づいて、あらゆるプロセスにスケジュールを作成して、スタートアップ後の体制を整えておきましょう。

開発の経験が少なく行動が洗練されていない場合、システムが前もって想定していた使用方法であることだけを考えていくことが多くなってしまいます。要件定義の際にシステムにおけるエラー対応を、前もって想定して準備しておくことが重要です。

なぜならば、想定されていない使われ方がされてしまうこともシステムであるからです。

まとめ

要件定義における具体的な進め方・失敗しないために注目すべき点を紹介してきました。プロジェクトを成功させるためには、目標とするゴールをはっきりと定めることによって、要件定義に一点一画おろそかにせず、具体的なフローを工程に適用することが大切です。

発注側はシステムに関するエキスパートでない場合が多くなりますが、受注側へ任せきりでは思ったとおりに要件定義を進めることはできません。発注側と受注側のコラボレーションであるといった姿勢が、要件定義を至適に進めていく基本となる姿勢になります。

発注側と受注側がやるべきことを遂行していくことによって、要件定義を至適に進めてシステムの導入を成功へと導いていきましょう。

自社にぴったりのシステム開発会社を探すには？

システム開発会社選びでお困りなら「比較ビズ」が解決します！

• 費用相場がわからず不安...
• 発注先選びを失敗したくない…
• 忙しくて探す時間がない...

今年で運営17年目の「比較ビズ」は、仕事を”依頼したい人”と”請けたい人”を繋ぐマッチングサービスです。これまでWEBシステム、スマホアプリ、業務システムの開発など多くのご相談を頂き1万社以上もの企業様の発注をサポートしてまいりました。

まずは下記のボタンより、お気軽にご相談ください。

代表取締役 日向野卓也

監修者

株式会社GeNEE

東京工業大学環境・社会理工学院卒業。慶應義塾大学大学院経営管理研究科修了。MBA（経営学修士）取得。国内最大手SIerの株式会社NTTデータで大手法人領域（大手流通企業、大手小売企業）の事業開発、事業企画等の業務に従事。米国スタンフォード大学への研修留学を経て、システム/モバイルアプリ開発会社の株式会社GeNEEを創業。

この監修者の記事一覧