『みんなの転職「体験談」。』
『みんなの転職「体験談」。』

『みんなの転職「体験談」。』は、20~50代社会人男女の、 「転職したいけれど、迷いや不安で行動を踏み出せない」を 解決し、
より良い将来を目指した一歩を踏み出していける為の、 生々しい体験談情報やナレッジを提供するWebサービスです。

MENU

SEの「要件定義」を適切に作れるようにするには? 進め方のコツを解説

[最終更新日]2021/11/29

SEの「要件定義」の進め方 顧客にフィットするシステム作りに大切!

システム開発において、要件定義は重要です。

この業務に初めて携わる方のなかには、どのように進めればよいかお悩みの方も多いのではないでしょうか。また設計とどう異なるのか、違いを知りたい方もいることでしょう。

目次

1)そもそも、「要件定義」とは?

まず要件定義とはなにか、2つの観点から確認していきましょう。

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

要件定義とは…システムに対する顧客の要望をまとめる作業

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

  • 顧客の要望に矛盾や無理がないか
  • 実務において本当に必要な機能か
  • 希望する納期までに本稼働が可能か

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

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

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

要件定義と基本設計の違い■基本設計は、要件定義の情報を元に行う ■要件定義は実装する機能を選ぶ工程 ■基本設計は実装する方法やUIなどを決める工程

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

  • 基本設計は、要件定義の情報をもとにして行われる
  • 要件定義は実装する機能を選ぶ工程。性能やスケジュール、セキュリティなども議題となる
  • 基本設計は操作方法や表示内容、画面の遷移など、実装する方法やUIなどを機能ごとに決める工程

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

2)要件定義での決定を要する5つの項目

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

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

システム化の目的

POINT1 システム化の目的 「顧客からの要望の高い、新しい業務に対応する」「業務を30%効率化する」など

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

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

システムの概要、構成

POINT2 システムの概要、構成 ■業務要件:システムを活用するエンドユーザーの視点で作る ■システム要件:ITエンジニアの視点で作る

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

要件の種類 説明
業務要件 業務を遂行する立場で、必要となる要件を決める。システムを活用するエンドユーザーの視点で作る
システム要件 業務要件を満たすうえで、システムが備えるべき要件を決める。ITエンジニアの視点で作る

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

実装する機能(機能要件)

POINT3 実装する機能(機能要件) 顧客と合意を取ることが必須。顧客の要望すべてを実装する必要はない。

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

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

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

POINT4 求める性能やセキュリティ(非機能要件) スピードなどの性能面や保守・運用面 情報セキュリティに関する事項など

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

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

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

POINT5 導入・移行計画、スケジュール、人員体制 システムを納期通りに完成できる根拠を示す

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

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

◇ ◇ ◇

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

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

3)要件定義を進める3つのステップ

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

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

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

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

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

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

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

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

STEP2 要求の細分化

STEP2 要求の細分化

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

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

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

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

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

STEP3 要件定義書の作成

STEP3 要件定義書の作成

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

  • システムの目的
  • システムの概要
  • 搭載する機能
  • 機能要件や非機能要件
  • スケジュール
  • 開発体制

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

4)要件定義に必要な3つのスキル

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

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

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

SKILL1 顧客の意図を読み取るヒアリング力・提案力 ■顧客は要望を100%伝えきれない場合も多い。・要望を文字にする際に表現しきれない部分が生じる ・より簡単に課題を解決できる方法を知らない

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

  • 要望を文字にする際に、どうしても言葉で表現しきれない部分が生じてしまう
  • より簡単に課題を解決できる方法を知らない

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

スケジュールの管理能力

SKILL2 スケジュールの管理能力 無理をせず、リスクを考慮したスケジュールを組むことも重要

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

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

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

SKILL3 要件をドキュメント化するスキル ・開発内容をプロジェクトメンバーに正確に伝えられる ・顧客とトラブルになった際にプロジェクトを守れる

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

  • 開発すべき項目や内容を、プロジェクトメンバーに対して正確に伝えられる
  • 顧客とトラブルになった際に、開発プロジェクトを守れる

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

5)要件定義の遂行において意識しておくべき3つのポイント

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

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

「5W2H」を明確にする

POINT1 5W2Hを明確にする Why:システム化が必要な理由 What:システム化によって表現したいこと Where:システム化の対象となる業務や部門 Who:システムの利用者 How:システムに必要な機能 When:本稼働させたい時期 How much:顧客の予算

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

5W2H 説明
Why システム化が必要な理由
What システム化によって実現したいこと
Where システム化の対象となる業務や部門
Who システムの利用者
How システムに必要な機能
When 本稼働させたい時期
How much 顧客の予算

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

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

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

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

POINT2 要件定義書は専門知識のない人でも理解できるように。相手レベルに合わせ、なるべく平易な用語を使うように心がける

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

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

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

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

POINT3 多少時間がかかってでも丁寧に行うことが重要。要件定義に誤りがあると、完成したシステムも誤りが生じてしまう

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

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

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

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

まとめ)ポイントを押さえて、顧客に貢献する要件定義の作成を

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

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

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

「ITエンジニアの転職」に向けてのお役立ち情報

分野 お役立ち情報記事(未経験者におすすめ)
PG・SE SE(システムエンジニア) / プログラマー / ネットワークエンジニア / インフラエンジニア / フロントエンドエンジニア / Webアプリケーションエンジニア / サーバーエンジニア / データーベースエンジニア / クラウドエンジニア / iOSエンジニア / アンドロイドエンジニア / テストエンジニア / 半導体エンジニア / 組み込み系エンジニア / セールスエンジニア / QAエンジニア / 社内SE / Salesforceエンジニア / フルスタックエンジニア / AWSエンジニア / SESエンジニア / セキュリティエンジニア / UI/UXエンジニア / ヘルプデスク / デバッガー     
PM・PL プロジェクトマネージャー / プロダクトマネージャー / テックリード(リードエンジニア) / ITスペシャリスト    
コンサル ITコンサルタント / ITアーキテクト / SAPコンサル    
ディレクター Webディレクター / Webプロデューサー / ゲームプランナー / Webデザイナー    
マーケティング データアナティスト・データサイエンティスト / マーケティング / SEOコンサルタント    
開発言語 PHP / Java / C/C++ / C# / R言語 / Python 機械学習エンジニア / Perl / Ruby / Go / Scala / Java Script / Kotlin / COBOL / VBA / Html / Unity    
業界 SIer / ゲーム業界 / VR / FinTech / ブロックチェーン / Edtech / EC/ DX推進 / 外資系IT    
その他 コミュニケーション / スクラムマスター / オブジェクト指向 / アジャイル開発 / 自己PR(SE) / 要件定義 / 職務経歴書 / ポートフォリオ / 資格 / キャリアアップ / テレワーク    
<>