40代からのフリーランスエンジニア向け・案件検索サイト【SEES】
システム開発の最初の工程(プロセス)「要件定義」。ITエンジニアの仕事において、重要性が高く、キャリアを重ねた後に自分も携わりたいという方も多いでしょう。本記事では、要件定義の概要から手順、流れ、進め方、必要なスキルなどを解説します。
<業界実績18年>
ミドル・シニアフリーランス専門
エージェントSEES
40~60代以上のシニアエンジニア案件探しは、私たちにお任せください!
ご登録者様限定で、Webに公開していない非公開案件をご提案いたします。
目次
「要件定義とはどんな工程?」
「要件定義では、具体的にどんなことをするの?」
「要件定義をする人に必要なスキルは?」
ITシステムの開発過程において、最初に置かれることが多く非常に重要な工程(プロセス)が「要件定義」です。上流工程にあたり設計や開発、運用保守などを主に行うエンジニアの場合、具体的内容や目的、方法などに触れる機会が少ないかもしれません。
要件定義に携わるには、エンジニアには多くのスキルや知識が要求されます。その一方で、要件定義工程を含む案件は単価も比較的高い傾向があり、フリーランスエンジニアの活躍も見られます。
この記事では、要件定義とは何か、概要から手順と進め方、重要なポイントなどを解説します。また、要件定義を担うために必要なスキルも紹介していますので、上流工程を担当するシステムエンジニアを目指す方はお役立てください。
「要件定義」とは、ITシステムの開発プロジェクトやシステム導入プロジェクトの発端となる工程(プロセス)です。非常に大まかに言えば、そのプロジェクトでいつ、誰が、何をする(作る)のかを決めます。
システムのユーザーが持つ課題をどのような仕組み(システム)で解決するかを、課題を持つユーザー側とシステムの設計、構築を行う側で十分に検討、整理し、以降のプロジェクトでの実施内容を決定づけます。後の工程への影響も大きく、プロジェクトのトラブルは要件定義での不十分な検証が起因していることも多いため、極めて重要なプロセスであると言えます。
システム開発における要件定義に関して、詳しく見ていきましょう。
ITシステム開発において最初に取り組まなければならない作業が「要件定義」です。実際に開発作業をはじめる前に、「何」を「どんな目的」で「いつまでに」作る(する)のかを明確に定めます。
要件定義ではシステムに組み込むべき要望を顧客から聞き取り、その詳細を整理しながらまとめていきます。
その後、要件定義で決定されたゴールや目標に向けて、WBS(Work Breakdown Structure)というタスクリストを洗い出し、プロジェクトを完結させるまでの各工程で1つ1つクリアしていくことで、計画的に開発が進められます。いわばプロジェクト全体のゴールまでを定めるため、プロジェクトの成否が決まるといっても過言ではないでしょう。
要件定義はシステム開発の「上流工程」に含まれ、プロジェクトの成否やシステムの品質に関わる重要な役割を担っています。
要件定義以降の工程では、要件定義で定めた内容をベースに設計・構築・テストを進めます。したがって、すべての工程が要件定義での仕様を基にするため、後の工程に与える影響が大きいです。
万が一、不十分な要件定義のまま開発が進むと、要件の誤り、漏れなどにより下流工程で大きなトラブルが生じる可能性があります。すると、納期に間に合わない、コストが予算を超過する、顧客の信頼を失うなどの事態を引き起こすでしょう。
そのため、プロジェクトの大切な基礎部分である要件定義は重要視されます。
システム開発で広く用いられる技法として、ウォーターフォールが挙げられます。ウォーターフォールでの開発で一般的に定められる工程は下記の通りです。
要件定義が先頭であることに注目しておきましょう。なお、アジャイルなどのシステム開発技法でも、これらの工程とリリースが短い期間でサイクルするため、要件定義のような工程の重要性は変わりません。
※詳細な工程の定義は所属組織やプロジェクトなどによって異なることがあります。例えば、IT戦略の策定、システム企画の立案などが要件定義の前に置かれる場合やシステムテストの後に運用テストを実施する場合などです。
要件定義では、基本的にシステムの開発を行うエンジニアは主体とはなりません。主体となって実施するのは、クライアントやユーザーの仕事となります。「どのようなシステムが欲しいか」は常にクライアント、ユーザー側にあるためです。
ただし、クライアントやユーザーはシステム開発について知見をもっているわけではありません。「何がしたい」「どんなシステムが欲しい」という点が明瞭になっていないことが多いです。そこで、エンジニアはクライアントやユーザーを支援するという形で要件定義に携わることが通常です。
要件定義では顧客が求めるものを理解し、しっかりと意思疎通を図ることが重要です。そして、どのようなシステムを開発するのか、どのような計画で開発を進めるのかなどを定めます。
システム開発における要件定義の手順と進め方を、ステップ別に紹介します。
課題と目的、ゴールを抽出できたら、目的を達成するためにどのような要素(パソコンやサーバー、アプリケーションなど)を組み込むか、システムの全体的な構成を明確にします。
「何」を実現させるかが業務要件にあたり、「どのように」実現するかをシステム要件として定めます。この段階で要件漏れがあった場合は高額なコストアップに繋がる可能性もあることから、システムの全体像には十分な検討が必要です。
「機能要件」とは、顧客の要望を実現するためのシステムに実装する機能を決めることです。このステップでは顧客が必ず組み込みたいと望む、システムにおいて必要最低限の機能を決めます。
具体的にはシステム開発の目的、入力や出力手段などの入力処理・制御・出力処理、通信方式などを定義します。画面や内部処理、帳票などの機能もこの段階から検討が始まります。
なお、ここで削減せざるを得なかった機能については代替案の検討などが必要となります。
機能要件を定義した後は、使用感や操作感、システム性能などの「非機能要件」を定義します。非機能要件とは、その名のとおり機能以外の要件のことです。
例えば、性能や運用・保守性、可用性、セキュリティなどが非機能要件に挙げられます。システムの開発はいくら顧客の要望に沿った機能を実装したとしても、処理性能や可用性が低い場合、セキュリティが甘い場合は運用しづらくなります。
そのため、非機能要件も機能要件と同様、それぞれを入念に定義することが重要です。
機能要件、非機能要件が出揃ったら、これらの要件を実現する開発の具体的な実行計画を立てます。リリースまでの作業を全て挙げ、WBSを作成。WBSの各タスクごとに必要な工数を計算し、予算やスケジュールなどをプランニングします。
また、予算やスケジュールなどに加えて作業者の人数や使用する機器、コミュニケーション方法など、実行計画にはさまざまな内容が含まれます。プロジェクトの成否に大きく関わる内容であり、このパートも重要な工程です。
業務用件、システム要件、機能要件、非機能要件、プロジェクト実行計画など、ここまで定義したものを要件定義書としてまとめます。要件定義書にはシステムの概要や目的、業務フロー、顧客の要求と必須要件(機能要件・非機能要件)なども記載が必要です。
この要件定義書は、プロジェクトの以降の工程で開発作業者がチェック事項を確認するための重要な書類です。また、顧客への説明資料にもなるため、ITに関する知識がない顧客にも理解しやすい内容にする必要があります。
要件定義は、システム開発の最上流工程にあたり、下流工程への影響が大きい重要な工程です。顧客と開発者の間で齟齬のない情報共有や、要件の漏れが発生しないように細心の注意を払ってトラブルを防ぐ必要があります。
以下では、要件定義において重要なポイントを紹介します。
要件定義においては、やるべきこととやるべき人、その締め切りを明確に定義することが重要です。そして、その認識を顧客と開発者の間で齟齬なく共有しなければなりません。顧客内にステークホルダーが多数存在する場合には、全てのステークホルダーとの情報共有を行います。
要件定義に起因するトラブルは、開発側と顧客における認識の齟齬から発生するケースが少なくありません。やるべきことに対する認識、もしくはやるべき人の認識が、両者間で乖離している場合が考えられます。システム化について、クライアントの情報部門と現場部門での認識の齟齬もよく発生する問題です。特にDXの推進を目的としたプロジェクトでは、目的と手段が混同してしまうケースも見られます。
そのため、「MUST」と「WANT」の違いも含めてやるべきことを明確にしておき、それを誰がすべきかまでもはっきりさせておきましょう。全てのステークホルダーに、いつまでに各タスクが終わっていなければプロジェクトの完了が延期するという認識まで共有しておくことがのぞましいです。
「要求定義」と「要件定義」は、厳密に言えば異なります。開発者はこの違いを認識して取り組むことが重要です。
要求定義は要求分析とも呼ばれ、顧客の要望や要求に対して何をどのようにするか、またしないかを明確にします。つまり、顧客の実現したいことを聞き取り、取捨することが必要です。
一方、要件定義では要求定義の枠組みを実現するために必要なものを具体化し、明文化していきます。目的が異なる両者を同じ工程で扱うとしたら、まず要求の枠組みを決め(要求定義)、枠組み内で必要なものを定義する(要件定義)ことになります。
要件定義を実行する際は、事前に誰がどのレビューを担当・承認するのかを決定したのち、レビュープロセスを確実に履行することが重要です。
特に要件定義の推進を支援する立場のエンジニアの場合は、ステークホルダーを集めて重要な決定が共有されるようレビューの場を開催・運営することも大切な仕事となります。
要件定義が誤りなく定義されていくには、正しく判断できる業務担当者や運用担当者などが確認する必要があります。誤って要件定義され、次工程に進んでしまった場合、運用テストや受入テスト、もしくは納品後にそれに気づくことになります。その結果、要件定義に起因したプロジェクトの失敗を引き起こします。
要件定義を行うためには、システム開発についての深い知識とスキル、そして経験が求められます。
例えば、要件定義では顧客との接点が多いため、他の工程よりさらにコミュニケーション能力が重要になります。また、ITエンジニアとしてシステム全体を構成するための広範なスキルを持つことは前提として必要です。
本項では、システム開発の要件定義で求められるスキルを解説します。これらのスキルは一朝一夕で身につけることは難しいため、普段の業務の中で向上させることを日頃から意識しておきましょう。
顧客の中にはITに関する知識がまったくない人や、理路整然と要望を説明できない人もいます。そのような顧客とのヒアリングの中から、相手の意図をくみ取り要望を的確に把握できる能力が不可欠です。
さらには、曖昧な形である要望を言語化し、共通認識とするところまでが要件定義で必要とされます。
また、要件定義を支援するエンジニアはシステム側だけの視点でなく、ユーザ―目線に立って顧客が説明しきれない部分の補完や、顧客自身が気づいていない問題点を浮き彫りにすることも重要な仕事です。実際に利用する現場とも共通像を作れる言葉選びも大切です。
顧客の要望のすべてをシステム開発で実現できるわけではありません。まずは、要求内容が実現可能であるか明確にイメージする必要があります。そして、そのためにはシステム開発に関する技術と知識、経験が求められます。
より具体的には、技術的な実現性の確認とコストや納期などの物理的な制約内での実現性を確認する必要があります。
なお、要件定義は重要な工程であるものの、時間をかけすぎることはできません。プロジェクト全体のスケジュールやリスク管理を考えて動ける想像力も大切です。
要件定義では、システム開発に取り組む関係者や顧客が同じ共通認識を持って取り組めるようなドキュメント(要件定義書など)の作成が必要になります。
特に要件定義書については専門知識がない人も理解できるように、要件を正確に数値化、または言語化して具体的に文章に落とし込める能力が求められます。ドキュメントの作成は手間がかかりますが、要件定義の質に関わる大切な作業です。
要件定義に求められるスキルと知識を習得する方法として、下記が挙げられます。
一般に流通している書籍にも、要件定義に関するものが多数存在しています。実際の自分の業務上で利用することができるかは場合に寄りますが、事例などを見ることで一定の知見を得ることができます。IPAの「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」はPDF版は無料で参照が可能です。
企業や組織に所属している場合、所属先ごとの作法、手順などは実務において学ぶしかありません。出来るだけ上流工程に携われるよう行動することが必要です。また、設計や構築などにおいて要件定義のドキュメントを見ることができる機会をもとめ、触れておくことを推奨します。
要件定義が終了すると、システム開発プロジェクトは設計、実装、テスト、リリース、運用保守と工程が移り変わっていきます。しかし、その過程で要件定義レベルの想定外の問題が見つかる場合もあります。
そのような不測の事態にも、変更を受け入れる柔軟な姿勢で取り組むことが重要です。必要に応じて要件定義の内容を変更しますが、その際には再度ステークホルダーの了承を得るプロセスもやり直します。
40代からのフリーランスエンジニア向け・案件検索サイト【SEES】にて掲載中の案件より、要件定義を業務に含む例を紹介します。このほかにも、要件定義の案件が多数ございますので、ご参照ください。
金融機関向け、業務要件及びシステム要件整理支援
稼働期間:長期
単価:~80万円
求められるスキル・経験:
業務システム向けの上流工程リード経験
チーム内外とのコミュニケーションスキル
製品販売営業事務Webシステム開発(要件定義、設計、開発、試験)
稼働期間:長期
単価:~65万円
求められるスキル・経験:
Webシステム開発における上流工程業務の経験
Next.js、React.js等のフレームワークを用いたフロントエンド開発経験
RestAPIの開発経験
採用管理システムリニューアルに向けた要件定義
稼働期間:中長期
単価:~80万円
求められるスキル・経験:
Webシステムの要件定義経験
Webシステム上流工程~運用までの一連の工程経験
SEESで要件定義関連の案件を探す
要件定義について、よくある質問と回答をまとめました。これから要件定義工程でも活躍したいと考えているエンジニアは、キャリア検討にお役立てください。
要件定義は、システム開発プロジェクトの一番最初の工程となることが多く、何を、どのような目的で開発するのかを定めます。プロジェクトのゴールを定める工程ともいえます。
システムのユーザーや依頼元のステークホルダーからでてきた要望を整理し、システムや機能に関する要件の共通認識を作ります。この際には、ステークホルダーの了承を得ることもポイントです。
プロジェクトのゴールとなる要件が定まったら、必要な作業をタスクレベルで洗い出してWBSを作成し、プロジェクト全体のスケジュールや見積なども実施します。
要件定義工程の成果物は要件定義書と呼ばれるドキュメントです。必要となるドキュメントはケースによって異なりますが、下記に一例を挙げます。
要件定義には、システム構築に携わる広範な知識とステークホルダーとのやり取りのためのヒューマンスキル、柔軟な対応を行うための実務経験などが必要となります。
要件定義に必要となるスキルや知識はすぐに身につけるのは難しく、エンジニア業務を行いながら身につけることが一般的です。
ITシステムの開発において要件定義は重要な工程です。要件定義をしっかり実行することで、下流工程での変更やトラブルのリスクを最小限に抑えられ、かつ円滑にプロジェクトが進められるために開発時間とコストも抑えられます。
40代~60代向けミドル・シニアフリーランスエンジニアの案件サイト『SEES』
40代~60代でエンジニアとして活躍したいと考えている方におすすめなのが、株式会社Miraieが運営する、ミドル・シニアエンジニア向けの案件サイト『SEES』(https://miraie-group.jp/sees/)です。
SEESとは-Senior Engineer Entrustment Service-の略称で、40代~60代エンジニア向けの案件紹介サービス。
エンジニア業界は、40代以上の転職はなかなか厳しい市場だと言われています。
転職ではなくフリーランスとして案件を獲得することを視野にいれてみてもいいかもしれません。
SEESの場合、掲載している案件は主に年齢不問ですので、年齢制限に関係なく、純粋にスキルや希望条件での案件を探すことが可能です。
会社員よりも個人事業主としてプロジェクトを請け負う形であれば、働き方としても選べる立場にありますよね。
給与の支払いサイトは30日で統一されています。
また、取引社数が5,000社以上と多く、新しい案件が集まりやすくなっています。
さらに、SEESに登録をすると最新・未公開案件を獲得することができます。
独立してフリーランスになっても仕事が途切れる心配はありません!
『SEES』(https://miraie-group.jp/sees)を利用して新しい働き方を手に入れてみては…!?
皆さまから選ばれてミドル・シニアエンジニア向け検索サイト三冠達成しております!
株式会社Miraieが運営する『SEES(https://miraie-group.jp/sees)』は、 「シニアエンジニア向け検索10サイトを対象にしたサイト比較イメージ調査」のなかで、
上記3項目においてNo.1を獲得ししております。
株式会社Miraie
2007年設立のシステム開発会社。首都圏を中心にWeb・IT関連事業、コンサルティングサービス、人材派遣サービスなどを展開。 SES事業や受託開発などを中心にノウハウを蓄積しながら、関連事業へとビジネスの裾野を広げています。
監修者インフォメーション