More than 1 year has passed since last update.

【自分メモ】Udemy「【入門】システム要件定義と基本設計」のアウトプット3

Posted at 2023-08-13

背景

昨年から会社でWeb開発の手法を学んできましたが、開発技術面がある程度理解できてきたので、設計面での勉強を開始しました（開始させられました）。Udemy「【入門】システム要件定義と基本設計」を視聴して、理解したことをアウトプットしていこうと思います。

要件定義には、要望、要求、要件という段階があり、それに検討と提案を含めた5つのフェーズで進められる。

上記に加えて検討と提案を含めた5つのフェーズで進められる
要望→要求→検討→提案→要件

まずは要望フェーズで、現状とゴールを把握し、ギャップから「こんなシステムがあったらいいな」という要望を洗い出す。
このフェーズではPMがユーザーにヒアリングを行い、ユーザーが抱える課題や問題点を抽出し、それを解決するための要望を明確にする。

ユーザーから部分最適な要望しか抽出できない
それらが実装、反映されなかった時の反発の可能性がある

次に要求フェーズでは、要望フェーズで出された要望をもとに、PMがエンジニアに「こんなシステムを作りたい」と伝える。
このフェーズでは、数値目標や受け入れ条件を明文化し、業務フローや機能・非機能などを定義する。
PMは立場の違いによる意見の食い違いを収拾してまとめることが必要。

要望をそのまま記載するののはNG
どんな課題を解決するかを明確にすることが求められる。

検討フェーズでは、SEがITの目線で企画の実現性を検討する。
要求の中で特に何を開発するか、すべて開発するのか、何からするかなどを検討し、必要な機能がそろっているか、技術的に可能か、予算算出、納期・スケジュール感などを明確にする。

PMからの要求そのままに機能を実装するのはNG
トレンドなどから本当にこの要求で問題ないかを検討するべき。

提案フェーズでは、ビジネス側にヒアリングしつつエンジニア側が検討したことをフィードバックする。
代替案を出したり、実装する機能しない機能を明確にすることが求められる。
実装が難しくても「できません」といった断り方ではなく代替案や困難な理由を提示するなどビジネス側が納得できる根拠を提示する。

このフェーズではエンジニアが伝えても伝わらないことがあるため、画面サンプルを作ったり、変更点や当初から変わったことはしっかりと伝える必要があることがある。

ビジネス側とエンジニア側で決定事項を協議し、共通認識とすることが目的

要件フェーズでは、ビジネス側とエンジニア側で決定事項を協議し、共通認識としする。
機能一覧や実装の順番、実装しない機能、業務フローの最新版などを明確にすることが求められる。

机上の空論になりやすい。
ユーザーにとって使いやすいように業務フローに沿って確認すること。

各フェーズで明確にすることや失敗例などがあるが、要件定義にはシステム開発において重要なポイントが多くある。
要件定義が不十分だとシステムの開発プロセス全体が混乱し、コストや時間の浪費、開発成果物の不備といった問題が生じるため、正しい要件定義を行うことが求められる。