こんにちは。Koglenです。
今回は自分が今まで携わってきたオンラインシステム開発案件にて感じた、要件の確認フェーズと確認すべき内容を話題にしてみようと思います。
要件を確認すべきフェーズは以下の3つに分類でき、それぞれで確認すべき内容が変わってくると思います。
1.）プロジェクト発足時
このタイミングではプロジェクト発足の背景を理解し、要件を確認すべき部署を確認しておきます。
可能であればその部署に担当者をたててもらいプロジェクトの課題・要件の確認先を明確にしておきます。
2.）プロジェクト計画時
上記で確認が必要となった部署に対して現状の業務フロー(Asis)とゴールとする業務フロー(ToBe)をヒアリングし業務フロー図を作成します。
できれば関連する部署が全て1つの図に収まることが望ましいですが、業務毎に連携先が異なるのであれば業務毎に作成した方が規模感が把握し易いと私は思っています。
この時にどれぐらい細部までヒアリングして図に落とせるかでブレない見積りが作成できるためヒアリングは慎重に行いたい作業です。曖昧な点はクリアになるように注意しましょう。
こちらは可能な限り担当者から直接ヒアリングを行い、完成した新旧の業務フロー図に認識の齟齬が無いかを相互で確認しましょう。
業務フロー図から業務変更ポイントを洗い出し業務観点のテストケースを作成することができるように、時系列を含めた図になっていると尚良いでしょう。
3.）プロジェクト開始時（詳細要件確認時）
このフェーズは要件定義のメインフェーズです。
新業務フローで変更・作成することとなった機能単位で画面デザイン、項目（入力タイプ、サイズ、必須、初期値などの要件含む）、業務チェック、エラー処理などをヒアリングし要件定義書を作成しましょう。
本来は前フェーズで確認できれば良いのですが、概ねこのタイミングでシステム的にエラーハンドリングすべき点と業務で吸収すべき点が見えてくることが多いように思います。
既にプロジェクトのスケジュール・予算は決まっているフェーズなので認識齟齬が発生した場合はどこまでを本プロジェクトのスコープとすべきかをよく検討しましょう。
また、要件が変更となった場合はその変更内容を要件定義書に反映させ担当に確認してもらうようにしましょう。もちろんエラーハンドリングの方針などで業務フローが変わる場合は業務フロー図の更新も忘れずに。
最後に
いかがでしたでしょうか？要件と一言で表現すると漠然としていますがそれぞれのフェーズで切り分けると確認すべきポイントがそれぞれ違うのがお分かりいただけると思います。
私は要件の確認をどこまで掘り下げられることができるかが顧客にとってより良いシステムが実現できるかがかかっていると思っているため、今回はこのような話題に触れてみました。
少しでも読んでいただいた方の参考になれば幸いです。
