これまでも何回か実施させていただいております「要件定義研修」を久しぶりに実施させていただきました。
利用部門が望むシステムを構築するためにはシステム部門が、利用部門の要求をしっかりと聞き取って、要件定義に結び付けていく必要があります。要求を出す側の利用部門も自らの問題認識に基づいて、ニーズを明確にして要求を出していく必要があります。
利用部門とシステム部門がお互いの考えを理解して、共有しないと要求と要件にずれが生じたり、抜けが生じたりします。そうすると相互の信頼関係が失われていき、利用部門からはシステム部門は実際の業務を理解してくれず、使いにくいシステムを作ってくるという不満がたまります。逆にシステム部門は、利用部門は自分の都合でどんどん要求を増やしてくる。また様々な利用部門で相反する要求が上がり、相互に調整をしてくれないので、システム部門が調整をすべて引き受けないといけないので大変だといった不満が膨らむことになります。
また、すべてのニーズを要求や要件にできればよいのですが、現実には予算や時間の制約もあり、優先的に行うべき要求があります。これらも利用部門とシステム部門が共通の場で認識し合って、優先順位をつけていく必要があります。
これらの活動をスムーズに進めるには、別々に作業を進めるのではなく、お互いが早い段階から一体となって、かつ段階的に進めていく必要があります。
この研修では、現状の把握(現状の業務フロー)から、問題の記述、要求の記述、業務のあるべき姿の検討(新業務フロー)、そして要件の記述と段階を追いながら、業務フローや箇条書き、リッチピクチャーなどを活用して、可視化と情報共有を進めるプロセスを修得いただきます。
ニーズを特定し、要求から、要件を決定する。
■ニーズ… さまざまな要求の裏に隠れているもの。要求の原因になっているもの。
■要求 … 利用部門が、経験の中から導き出した具体的に実現したいこと。
■要件 … 要求を精査して、組織の目的に合致すると認められたもの。
▼ニーズ、要求、要件
要件を検討する上で、情報処理推進機構がまとめている「超上流から攻めるIT化の原理原則17か条」はとても参考になります。(出典：超上流から攻めるIT化の原理原則17か条（IPA/SEC)）
原理原則1 ユーザとベンダーの想いは相反する
原理原則2 取り決めは合意と承認によって成り立つ
原理原則3 プロジェクトの成否を左右する要件定義の先送りは厳禁である
原理原則4 ステークホルダ間の合意を得ないまま、次の活動に入らない
原理原則5 多段階の見積もりは双方のリスクを低減する
原理原則6 システム化実現の費用はソフトウェア開発だけではない
原理原則7 ライフサイクルコストを重視する
原理原則8 システム化方針・狙いの周知徹底が成功の鍵となる
原理原則9 要件定義は発注者の責任である
原理原則10 要件定義書はバイブルであり、事あらばここへ立ち返るもの
原理原則11 優れた要件定義書はシステム開発を精緻にあらわしたもの
原理原則12 表現されないままの要件はシステムとして実現されない
原理原則13 数値化されない要件は人によって基準が異なる
原理原則14 「今と同じ」という要件定義はありえない
原理原則15 要件定義は「使える」業務システムを定義すること
原理原則16 機能要求は膨張する。コスト、納期が抑制する
原理原則17 要件定義は説明責任を伴う
問題プロジェクトの原因分析をすると、よく出るのが、「要件定義が遅れた」、「追加要求が出た」、「コミュニケーション不足」などです。上流段階で、利用部門とシステム部門が協力して、要件を定めることの重要性をいつも実感しております。
0コメント