目次
システム開発の成功を左右するともいわれる重要な工程、「要件定義」。この記事では要件定義とはどのようなものなのか、具体的な流れ、要件定義をスムーズに行うコツを紹介します。
受注側だけではなく、発注側はどのようにすればスムーズに要件定義ができるのかもまとめました。この記事がお役に立ちましたら幸いです。
要件定義とは
要件定義とは、開発するシステムに求められる機能要件を定めることです。何をシステムに実装して、何をシステムに実装しないかを明確に定義していきます。システムの完成イメージに大きくズレがないかを定義する、システム開発のスタート地点となる重要な工程です。ウォーターフォール型の開発では逆戻りをしないため、特に重要な工程となります。
通常は要件定義の内容に沿って見積もりを作成します。要件に定義されていない要求は実装されません。要件定義は、受注側（システム開発会社側）だけではなく、発注側の協力が必須のフェーズです。
要件定義の具体的な流れ
要件定義はどのように進むのか、具体的な流れを紹介します。
目標設定
要件定義ではまず、システム導入をした結果達成されるべき目標を設定していきます。達成されるべき内容は、システムの種別によって異なってきます。
業務システムの場合、大半の目的はコスト削減であるため、人件費や通信費の削減が目標として設定されることが多いです。
Webサービスの場合、大半の目的は売り上げアップであるため、コンバージョンの獲得やLTV（顧客生涯価値）、解約率、受注数、受注金額、利益率にフォーカスして目標が設定されることが多いです。
ヒアリング
システムを実装する際に、何が必要で何が必要ないかをヒアリングをして明確にしていきます。問題解決や事業促進のお手伝いができるように、システム開発依頼の背景も確認していきます。
業務システムの場合、課題解決の対象となる業務の流れを把握するところから始めることが多いです。Webサービスの場合、業務の流れに加えて競合調査や顧客の動向などの把握から始めることがあります。
いずれの場合でも、現在抱えている課題をシステムに関することだけではなく、人やモノに関する問題を含めてヒアリングを進めていきます。例えば以下のような課題を洗い出していきます。
- 現状のシステムで誰も見ていない情報が出力されている
- システムの情報は利用せずに、個人個人がExcelで情報を管理しており、またその情報が共有されていない
- 請求書をプリントアウトして封入して郵送する作業に2日かかっている……など
要件定義書の作成
目標設定とヒアリングが終わったら、要件定義書を作成していきます。この段階で要件定義書、サーバー構成図、業務フロー図を作成することが多いです。
要件定義書
システム化する機能、システムを利用するアクター（＝ユーザーの種別）を定義し、アクターごとに求められる機能要件を記載します。
運用するドメイン、サポートブラウザ、SSLの要否、外部システムとの連携有無、必要なライセンスなど決定できる事項は決定していきます。この時点で決定できない事項は次のフェーズに持ち越します。
サーバー構成図
システムを設置するサーバーの構成を記載していきます。要件定義のフェーズでは決定しないこともあります。
業務フロー図
システムを導入した後の業務の流れについて、人の動きとシステムの動きを含めて図式化していきます。
要件定義で決める事項
具体的には以下のものを決めていきます。
- システム化の背景・目的
- システムの概要
- システム化する範囲
- システム構成
- システムの全体像・概念図
- 開発スケジュール……など
要件定義の段階では決めない事項
要件定義の段階ではなく、後の段階で決められるものは以下になります。
- 運用・保守
- 品質管理
- インフラ要件の一部
システムに関することは、ほとんどが要件定義の段階で決定していきます。
機能要件と非機能要件
重要となる機能要件と、非機能要件について詳しく説明していきます。
機能要件について
機能要件とは、要件定義のうち必ず搭載すべき機能のことを指します。発注側の要望の中で必ず機能化すべき要件のことで、要件定義書に詳しく記載していきます。
非機能要件について
ざっくりというと「機能化しない要件すべて」を指します。そのため、非機能要件は広範囲にわたります。
代表的なものとして、
- パフォーマンス
- 保守性
- 可用性
- 効果目標
- ユーザビリティ
などがあります。詳しく見ていきましょう。
パフォーマンス
システムに求められる性能要件を指します。例えば、予約照会ボタンを押してから結果が出るまで3秒以内にすること、同時接続数1000ユーザーでシステムのパフォーマンスが低下しないようにすること、などです。
保守性
保守に求められる要件を指します。例えば、メンテナンス時に許容される停止時間は夜間〜早朝で最大2時間にする、システムを自動監視し異常発生時に人が対応する/自動復旧する、データのバックアップを毎日取得し3年間保存する、セキュリティーアップデートを毎月実施する、などがあります。
可用性
システムを障害（機器やパーツの故障・災害・アクシデントなど）で停止させることなく、稼働し続けることを指します。システムを停止させることなく稼働し続ける時間の割合が高いことを「可用性が高い」、割合が低いことを「可用性が低い」といいます。
例えば、システムが1台のサーバーで運用されている場合に、そのサーバーが停止したらシステム全体が停止する状態は「可用性が低い」状態といえます。「可用性が高い」状態を具体的に説明すると、以下のようになります。
- システムが1台のサーバーで運用されているが、予備のサーバーが停止状態でスタンバイしている（コールドスタンバイ）
- システムが1台のサーバーで運用されているが、予備のサーバーが稼働状態でスタンバイしている（ホットスタンバイ）
- システムが常時2台以上のサーバーで分散処理されて稼働しており、どれかが停止しても即停止にならない
- システムが常時2台以上のサーバーで分散処理されて稼働しており、異常が発生した場合自動復旧する
1〜4に進むにつれて、より可用性の高い状態となります。可用性を上げるほど運用コストが高くなるため、要件としてどのレベルの可用性にするのかを決めておく必要があります。
効果目標
システムを導入した結果、達成されるべき効果目標を指します。例えば、業務システムの場合、月末請求処理にかかっている人的コストが40％削減されていることや、Webサービスの場合、月間のコンバージョンが導入前の120％を達成していること、などです。
ユーザビリティー
システムの使い勝手のことを指します。他の非機能要件に比べて数値化しにくいため、ガイドラインを定めてシステム内の使い勝手の標準化を図ることで実現することが多いです。
非機能要件は発注側のニーズや背景を理解し、適切なものを盛り込んでいきます。発注側があらかじめ決めていることもあれば、受注側が必要なものを提案することもあります。
要件定義をスムーズに行うコツ
要件定義をスムーズに進めるにはどうしたらいいのか、受注側、発注側、アクシアの考えの3つに分けてご紹介します。
受注側
依頼者の業務や社内の事情、業界の商習慣などを深くヒアリングして理解を深め、問題を解決するためにはどのようなシステムが望ましいかを提案できる能力が求められます。
言われたとおりにやる、言われていないからやらないというスタンスではなく、表面化している事象の本質的な問題を見つけ、システムのプロとして依頼者だけでは発想できない提案をできるのがベストです。
発注側
受け身の姿勢ではなく、システム導入で解決したい問題について、はっきりとシステム会社に伝える必要があります。自社の関係部署を巻き込み、必要な情報の提供に協力を得る調整力が求められます。
アクシアでの考え
発注側、受注側でどうしても上下関係が発生しやすい中、課題解決に向けては両社ワンチームで、同じ目線で同じ目標をもって取り組んでいくことをお伝えしています。また、課題解決に向けてワンチームで行う雰囲気づくりをアクシアでは重視しています。
受託開発というビジネスの特性上、初期開発時の売り上げが大きくなるため、作って終わりになりがちです。その後の運用保守を敬遠する業者も多いと聞きます。
アクシアでは、お客様に接するメンバーには「本番稼働してからが本番」というスローガンを徹底してもらっています。要件定義時でもその後の運用負荷やシステムの継続性を意識した保守・運用の提案を行っています。お客様からの信頼だけでなく、システム導入効果を最大に引き出すことを重視しています。
システム開発の重要な工程「要件定義」とは？まとめ
- 要件定義とは、開発するシステムに求められる機能要件を定める工程
- 要件定義は目標設定、ヒアリングを経て要件定義書などの書類が作られる
- 機能要件とは、要件定義のうち必ず搭載すべき機能のこと
- 非機能要件とは、パフォーマンスなど機能化しない要件すべて
- 要件定義をスムーズに行うには、受注側は深くヒアリングして理解を深め、問題解決するにはどのようなシステムがいいか提案できるのがベスト。発注側は解決したい問題を情報収集し、はっきり伝えられるような状態にするのがベスト
要件定義は、システム開発の完成イメージの大枠を作る重要な工程です。発注側は事前にシステム開発で解決したい課題を洗い出しておき、受注側は深くヒアリングを行うことで、スムーズに要件定義の工程が進みます。
この記事によってシステム開発成功のお手伝いができましたら幸いです。最後までお読みいただき、ありがとうございました。