システム開発の「要件定義」とは
システム開発で言う「要件定義」とは、どんなシステムの開発を依頼するかを定義した文章のことです。システム開発における最上流過程で行う作業であり、お客さまがシステム構築に望むことや条件等をまとめるためのものです。システム開発という性質上、使用するスキル・付加する機能・仕様等についてお客様側から指定することが難しいため、通常は開発業者がお客さまにヒアリングを行った上で、要件定義書にまとめます。
要件定義を行う意義・目的とは
要件定義書はシステムという無形の商品を作り上げるために「どんなシステムをオーダーするか」を詳しく表した注文書だと言うことができます。要件定義は、依頼者側が何を欲しているのかという認識を、開発者と依頼者の間でズレを起こさないようにあらかじめ定義しておく重要な工程です。認識のズレをなくすことで、業者とお客さまが一体となって、同じ目標に向かって開発を進めることが可能になります。
要件定義が重要だと言われている理由
システム開発において要件定義は最重要工程だという言い方をされることもあります。それぐらい重要だと言われる理由は何なのでしょうか。
それは、システム開発における要件定義が甘いと、開発そのものが失敗に終わる可能性が高いからです。
要件定義が不十分だと起きること
要件定義の内容に漏れがあると、ニーズに合ったシステムを構築することができなくなります。やりたいことができなかったり、使いにくかったり。時短のためのシステム導入を狙っていたはずが、かえって時間がかかるようになったり。システム開発の目的を見失った状態で開発を行えば、当然、目的を果たすシステムは手に入りません。
さらに、要件定義が不十分だった場合、後になってから「こうしておけば良かった…」という箇所が出てきて、工程を後戻りすることになったり、余計な追加開発の費用と時間がかかるようになります。
要件定義に問題があると生じる問題
ビジネス課題を解決可能な
質の高いシステムが手に入らない
開発に時間がかかる
追加開発費など
無駄な費用が増える
要件定義で絶対に含めておきたい5項目とは？
本システム開発の目的
システムの利用目的や、システム開発によって解決したい課題についてを明らかにします。システム開発を行うことで何を実現するか、どのような問題を解消するのかというゴールを明確にします。
ユースケースの概要
システム利用者がシステムをどのように使用するのか、またどのような結果を得られる事が望まれているかを整理します。
機能要件
ユースケースを元に、システムが実現するべき具体的な機能要件を取りまとめます。システムが提供すべき機能や操作性、処理速度など、システムの機能面に関連する要件です。
非機能要件
システムに関連する性能や制約条件、品質要求など、機能以外の要件を定義します。例えば、セキュリティ要件、パフォーマンス要件、拡張性要件、互換性要件などが含まれます。
実際の開発の進め方について
スケジュール、予算、開発者は誰か、コミュニケーション手段など、実際の開発の進め方について定義します。
要件定義書の作り方
ヒアリング
お客さま（ユーザー)にヒアリングを行い、システムを通じて実現したいことを具体的に聞き取っていきます。そして、その内容をシステム要件に変換していきます。この時、システム会社の腕次第でヒアリングでお客さまの要望をどこまで引き出し、どこまで正確に要件定義に落とし込めるか？に差がつくことがあります。
要件を細分化して、機能要件をまとめる
ヒアリングによりお客さまのご要望を引き出したら、次はそれらを細分化して、システムの機能としてまとめていきます。お客さまが求めていることに対して漏れがないように、要望を機能として実現していくよう一つ一つ想定していきます。要件定義の後工程で行われる設計の工程で業務フロー図が描けるよう、システムの機能と大まかな動きをイメージできるようにします。
非機能要件をまとめる
可用性・拡張性・スペック・セキュリティ・運用・保守など、機能ではない部分の定義づけを行います。非機能要件をまとめる際のチェック項目として有効なのがRASISというフレームワークです。
まとめるためのチェック項目
- Reliability（信頼性)
システムが正しく動作するか。メモリ容量やCPUのスペックなどは十分か。 - Availability（可用性)
稼働率は高く、一定に保てるか。電源やネットワーク速度は確保できるか。 - Serviceability（保守性)
障害発生時の復旧体制や、障害対策にかかる時間の予測、監視方法など。 - Integrity（保全性)
データが矛盾せず一貫性を保てるか。 - Security（安全性)
機密性が高く、不正アクセスなどのリスクがないか。
要件定義書にまとめる
最後に、STEP3までの内容を要件定義書としてまとめます。この次に行う設計段階で不都合が出ないように、システムの全体像から細分化された一つ一つの機能まで、すべての要件を見落とさずに表していくことが大切です。書きあがった要件定義書は必ず漏れがないかを確認するとともに、顧客にも開示して内容を説明しながら間違いがないことを確認していただきます。
要件定義で失敗しない３つの方法
受託開発に強い開発業者を選ぶ
システム業界は多重下請け構造になっていることを知っていますか？日頃から下請けの仕事をメインで行っている業者の場合、お客さまの要望を要件定義書にまとめるという経験値が低い可能性があります。開発業者のスキルはまちまちのため、要件がきちんと含まれているか正しく機能に反映されているか注意しましょう。
しっかりとこちらの話を聞いてくれる開発業者を選ぶ
こちらの要望をメインでヒアリングするのではなく、自社のお勧めの方向に開発の流れを持っていこうとする業者には注意が必要です。自社開発のスキルやソフトを強く推奨してきたり、「これは出来ません」とお客さまの要望を突っぱねるのは、その企業（担当者)に開発スキルが不足しているからかもしれません。また、メーカー系・ベンダー系など自社のシステムサービスを導入前提で提案を行うシステムインテグレーターも存在しますので、公平な立場から最適な提案をし、要件定義を行っているか確認する必要があります。
おかしいと思ったら、立ち止まる勇気を持つ
要件定義でもしも不安な面があった場合は、「まぁいいか」と流すのではなく、必ず開発業者側に質問をしてください。そして、必要があれば要件定義後でも構いません。不明点やコミュニケーション不足を感じたり、要望がシステムに反映されていないと感じたら、すぐ声かけをしましょう。手戻りは時間とコストのロスになりますが、最悪の事態を避けるためにもできるだけ早く行動することが大切です。
要件定義にズレが生じていると感じたら
当社までお気軽にご相談ください。
もっとこんなシステムにして欲しいのに、開発者と意思疎通が上手く取れない、思ったより見積もりが高い、システム連携や運用方法など、こちらの希望を「できません」と言われてしまった。そんな時は、当社までお気軽にご相談ください。
シースリーインデックスの要件定義なら
プライム（直請け）案件100%の受託開発会社として15年の歴史のあるシースリーインデックスでは、お客さまの立場に立った親身なヒアリングを心がけています。独立系システムインテグレーターとして、しがらみなく様々なスキルやソフトから最適なご提案をすることが可能です。パッケージソフトやクラウドサービスの導入実績も多数。他社でできないと言われてしまったシステム連携などの相談を受けることも多いのが特徴です。
お気軽にご相談ください。
