要件定義って何するの？
要件定義では何をするのか、改めて考えてみようと思う。
本投稿ではクライアントから依頼のあるシステムを例にして考える。
まずは要件定義ですべきこととは何だろうか。以下に示すことが大まかに当てはまると思う。
- ニーズ分析
- 現状分析
- as-is to-be分析
- ステークホルダーマネジメント
- 非機能要求整理
- 制約・前提条件の明確化
- 要件の合意・契約
要件定義≠御用聞
要件定義で考えるべきことは、これらと考えるとシステムエンジニアはある種コンサルタントに近い業務を担う必要があるように感じる。ニーズ分析やas-is,to-beなどは構築するシステムの業界知識・業務知識を持って行かなくてはならない。
しかし筆者が経験してきた要件定義では、恥ずかしながらおよそコンサルタントとは程遠く、ただの御用聞になっていることばかりだった。
客：「こういうシステムが欲しいんだ」
筆者：「そうなんですね。じゃあ、どういう機能が欲しいんですか？」
これじゃいけない・・・。
理想はこうだ。
客：「こういうシステムが欲しいんだ」
筆者：「このシステムを構築してどのような改善を狙うんですか？では、これは必要ですが、これは要らないですね。」
このように進めていくのが望ましいよね。
ステークホルダーマネジメントの重要性
理想は理想であるのだが、ここで直面するのがステークホルダーマネジメントだと思う。
よくパワーのある役職者がいる会社のシステム構築を行う場合に、権利者の一存で要件定義が進んでしまうということがある。これは、激しく失敗に向かう第一例である。
要は、構築するシステムに関わる人物をまるっきり無視してしまうのだ。
役職者は、システムなんか触らないのに口は出す。そして仕様を決めていくのだが、現場がやりたいこと困っていることをわかった気になって本当のニーズというものを満たせない。
要件定義を行うにあたっては、システムに関わる人物・部署を洗い出しそれぞれの重要度を定義してどこに話を通していくのかをしっかりと管理していく。上記で役職者の批判のようなことを書いてしまったが、決裁者は役職者なので現場・役職者を巻き込んだトータル的な落とし所を見つけていくことも必要なことだと思う。
コメント