SEの「要件定義」を適切に作れるようにするには？ヒアリング・ 進め方のコツを解説

まずSEの業務である「要件定義」とはなにか、2つの観点から確認していきましょう。

システムに対する顧客の要望をまとめる作業

要件定義は、顧客からシステムに関する要望を聞き取ったうえで、盛り込むべき機能やスピードなどの性能を決める作業です。
単に顧客の要望をまとめるだけでなく、以下の事項も踏まえた検討が必要です。

要件定義で決定された内容は、設計や実装、テストなど、システム開発におけるすべての工程の基準となります。

要件定義の段階で、顧客としっかり認識を合わせておくことが重要です。これにより手戻りやトラブルを防ぐだけでなく、顧客満足度を高める効果も期待できます。

要件定義と基本設計（システム設計）との違い

要件定義と似た言葉に「基本設計」があります。
基本設計や要件定義の一部分であり、以下の相違点があります。

要件定義では、システム全体が議題となります。
一方で基本設計では、単一または複数の機能ごとに打ち合わせを進める場合が多いです。

要件定義での決定を要する項目には、以下の5点が挙げられます。

いずれも開発プロジェクトを成功に導くだけでなく、現場や業務効率化に役立つシステムをつくるうえでも欠かせない項目です。各項目について、詳しく確認していきましょう。

システム化の目的

システムの導入によって解決できる課題や、実現できる要望などについて触れていきます。「顧客から要望の高い、新しい業務に対応する」「業務を30%効率化する」などは、代表的な例です。

システム化の目的は、プロジェクトにおける羅針盤のような役割を担います。目的をあいまいにすると、良いシステムにはなりません。可能であれば数値も活用し、なるべく簡潔・明快に記述するよう心がけましょう。

システムの概要、構成

システムの概要や構成を決めることは重要です。これらは、業務要件とシステム要件の2つに分けられます。

上記をしっかり決定することは、後々のトラブル防止に役立ちます。

実装する機能（機能要件）

機能要件とは、システムに実装される機能を指します。最低限開発すべき機能となるため、顧客と合意を取ることが必須です。

もっとも、顧客が求めるすべての機能を実装する必要はありません。ときには顧客の要望自体が、矛盾を含んでいるかもしれません。要望を整理したうえで、実装する機能を決めましょう。また短期間での開発を要する場合は、機能の優先順位をつけることもあります。

求める性能やセキュリティ（非機能要件）

顧客が求める事項は、機能だけにとどまりません。スピードなどの性能面や保守・運用面は、代表的な項目です。また近年では情報セキュリティに関する事項も、要件に含まれるようになりました。

これらの事項も、要件定義の時点で決める必要があります。もし顧客が認識していない場合はSEから適切な内容を提案し、顧客の納得を得ることがトラブルを防ぎます。

導入・移行計画、スケジュール、人員体制

顧客がIT企業に発注するシステムには、必ず本稼働させたい時期があります。その目標に向かって確実に開発業務を進め、無事にリリースしなければなりません。顧客はシステム開発を任せてよいか、確証を持てる情報が欲しいと思うことでしょう。

このため開発を担当する企業は、システムを納期通りに完成できる根拠を示す必要があります。導入や移行の計画、スケジュール、人員体制は、その裏付けとなるもの。根拠のある情報を記入することで、貴社の信頼も高まります。

◇　◇　◇

ここまでの内容をお読みになられて、「今ひとつイメージが掴めない…」という人は、以下の実際に公開されている要件定義資料も見ておくと良いでしょう。 イメージの形成に役立てられると思います。

要件定義書には、決まったフォーマットや見出し構成というものはありません。
依頼元の顧客、そして開発チームと開発要件をしっかり共有して齟齬のないようにしていくことを第一目的に、どのようなフォーマットにしていくかを上記「5つの項目」を参考に定めていくと良いでしょう。

SEが要件定義をスムーズに進めるには、3つのステップを確実に実行することが重要です。

いずれも顧客にフィットしたシステムをつくるうえで、重要なポイントです。
各ステップで何を行えばよいか、詳しく確認していきましょう。

STEP1 顧客の要求を詳しくヒアリングする

要件定義の仕事はシステムに求める項目を、顧客から詳しくヒアリングすることが第一歩となります。
顧客は利用中のシステムに関して、さまざまな不満を持っていることも多いでしょう。新しいシステムへの要望も含めて、じっくり聞き取りましょう。

もっとも顧客が語らなかった項目であっても、重要な事項が隠されているケースは多いです。加えて聞き取りした内容をそのまま受け取るのではなく、「根本的な問題は何か？」という点を意識しながら解決策を考えることも重要です。

SEはシステム開発のプロとして積極的に質問し、疑問点を解決する姿勢も求められます。

このため、顧客との打ち合わせは必須です。但し事前にヒアリングシートに記入してもらうことは、密度の濃い打ち合わせにできるため有効です。

STEP2 要求の細分化

顧客から要求事項を聞き取った後は、利用中のシステムにおける課題や新しいシステムに求める要求事項を整理し、機能の実現に向けて検討します。

システム化が難しい場合は代替案を、業務プロセスの改善を要する場合は適切なアドバイスを行えるとよいでしょう。

またシステム開発の現場では、追加の要求やスケジュール遅延などの事態もよく発生します。
顧客から提示された要求事項に対して順位付けをすることも、この事態に備えるうえで重要です。

少なくとも「必須の機能」と「あれば良い機能」の2つに分ける作業は、この段階で実施しておきましょう。

これにより要望事項が追加された場合でも「あれば良い機能」の一部を後回しとすることで、顧客のニーズに対応できます。

STEP3 要件定義書の作成

要求のヒアリングと細分化が終了したら、打ち合わせ等で合意済の事項を要件定義書に記し、記録に残しましょう。以下の項目は、記すべき主な事項です。

要件定義書は、後工程の基礎になる書類です。もし誤りや抜けがあると、プロジェクトが失敗する原因となりかねません。
ときには膨大な量になる可能性もありますが、細部まで漏れなく正確に記すよう心がけましょう。

要件定義で得た情報を顧客にフィットしたシステムづくりに活かすためには、以下に挙げる3つのスキルが必要です。

いずれもコミュニケーションスキルやプロジェクトマネジメントなど、IT技術以外のスキルが問われています。上記に挙げたスキルが必要な理由を、順に解説していきます。

顧客の意図を読み取るヒアリング力、提案力

要件定義の段階で顧客の要望を丁寧に聞き取ることは重要ですが、それだけでは不十分です。
なぜなら顧客の側には、以下に挙げる理由で要望を100%伝えきれない場合も多いためです。

満足してもらえるシステムをつくるためには、顧客が持つ真の意図や要望を読み取ることも必要です。
ときには要望の詳細を深堀りする、より良い提案をするといった積極的なアクションも求められます。

スケジュールの管理能力

スケジュールの管理能力も、必要なスキルに挙げられます。なぜならシステム開発には、必ず締め切りがあるため。開発プロジェクトの期間や人員は有限ですから、開発できる項目にも上限があります。

もし顧客の要望をすべて受け入れた場合、スケジュールから大きく遅れ、顧客に迷惑をかける事態となりかねません。
このような事態を防ぐためには、要件定義の段階でどこまで要件に組み込めるか、慎重な検討が必要です。また無理をせず、リスクを考慮したスケジュールを組むことも重要です。

要件をドキュメント化するスキル

当事者間で決定した要件は、しっかりドキュメントに残しておくことが必要です。このことにより、以下に挙げるメリットが得られます。

ドキュメントは読みやすく誤解を生まないこと、誰が見ても同じように解釈されることが重要です。
このため簡潔かつ明快な表現を心がけましょう。表やグラフ、イラストも、適宜取り入れると読みやすくなります。また数値で表せる指標は、できるだけ数字で表記することもおすすめです。

スキルがある人でも、良い要件定義を作成できるとは限りません。要件定義を遂行する際には、以下に挙げる3つのポイントをしっかり意識する必要があります。

いずれも要件定義の成否を決める、重要な項目です。それぞれの項目がなぜ重要か、順に確認していきましょう。

「5W2H」を明確にする

要件定義では、以下に挙げる5W2Hを明確にすることが重要です。いずれも、開発プロジェクトを成功させるうえで欠かせない項目です。

上記のうち「Why」は前項でお伝えした「システム化の目的」にあたります。
「What」は「システムの概要・機能要件・非機能要件」などが該当します。
「How」については、詳細の内容を基本設計で詰めていきます。

それ以外は、要件定義の段階で決める必要があります。

また皆さまのなかには、「予算は営業交渉で決まるものだから、要件定義に関係ない」と思う人もいるかもしれません。
しかしプロジェクト管理においては、顧客の予算の範囲内で完成させることが求められます。プロジェクトの収支を黒字にするためにも、あらかじめ予算を知っておくことは重要です。

要件定義書は専門知識の無い人でも理解できるよう工夫する

SEなどのITエンジニアが陥りやすいポイントに、ITの専門用語を記したいという点が挙げられます。
完成した要件定義書にITの専門用語が多く記されていると、いかにも専門家がまとめた、かっこいい文書に見えるかもしれません。

しかし顧客が読んで理解できなければ、せっかく良い内容が書かれていても顧客には伝わりません。その結果どのようなシステムが完成されるかわからず、プロジェクトの終盤になってトラブルの原因となる可能性もあります。

本当の専門家は相手のレベルにあわせて、なるべく平易な用語を使うように工夫しています。誰が読んでも同じように受け取られるよう表現を工夫しつつ、わかりやすい文書にするよう努めましょう。

多少時間がかかったとしても、丁寧に行うことが重要

要件定義では顧客の要望が膨らみ、想定していた以上に時間を要する場合もあります。
開発要員を確保している場合はスケジュールに遅れを出したくない一心で、要件定義を適当に終わらせて設計・開発のフェーズに進めたくなります。

しかしスケジュールの遅延を理由に、要件定義をおろそかにすることは避けるべきです。
顧客としっかり合意しないまま開発を進めると、納品の段階で顧客から「思っていた内容と異なる」といった苦情が寄せられかねません。

その結果開発をやり直すことになれば、大きな時間と費用のロスにつながることでしょう。

要件定義に誤りがあると、出来上がるシステムも誤ったものになってしまいます。多少時間がかかったとしても、丁寧に進めることが重要です。

要件定義は開発プロジェクトの成否を決める重要な項目であり、顧客との会話が中心となるプロセスです。
コミュニケーションが苦手なSEの人は、不安に感じるかもしれません。

しかしポイントを押さえて顧客としっかり向き合う姿勢があれば、役割を担うことは可能です。
これまでの開発経験を活かし、より良いシステムを提供する意欲を持って対応しましょう。

顧客の真の意図を引き出せれば、プロジェクトが成功する可能性は大きく高まります。まずは本記事の内容を実践するところから始めてみましょう。