概要
ITプロジェクトの失敗例がマスコミを含めて問題化されています。多くのITプロジェクトが予算内でスケジュールどおりにカットオーバーできないのはなぜでしょうか。その主な理由は、ユーザーからの情報が無い、要求が不完全、要求が変わる、というものです。つまりユーザー自身、自分の要求を把握できていないのです。要求が決まらないままシステム開発をしてしまうことの必然的結果といえます。これはUMLやDFDなどの技法以前の問題です。
要求定義フェーズでの人的側面を考慮し、あいまいさを排除し、効果的な要求定義書を記述し、後工程のメンバーに正しく伝えられる能力・スキルを強化するために開発されたコースです。
失敗しない要求定義
■キーワード
・
顧客のビジネスの理解 ・要求決定のルール
・
ファシリテーションとインタビュー ・あいまいさの排除
・
ソフトウェア品質特性 ・相手に正しく伝えるコミュニケーション
■プログラムの焦点: 何を修得するか?
顧客の要求を理解するため、ビジネス背景を明確にし、当該プロジェクトが顧客ビジネスの成功に、本当に寄与できるものなのかを確認できるようになります。そして顧客に真の要求(RFPに書かれていない部分まで)に気付いてもらえるようになります。インタビュー/ファシリテーションを通じて、さまざまな要求の重要度を明確にできるようになります。機能以外の要求として品質特性も検討します。それらを正確に反映し、あいまいさを排除した要求定義書を記述し、それをメンバーに正確に伝えられるようになります。
■
プログラムの方法論: どのように修得するか?
要求定義プロセスの流れにそって学習を進めます。講義だけでなく、演習、ロールプレイを交えて、実例に近い形で学習ができますから、効果的な学習ができます。
■プログラムの構成
標準開催期間: 2日間
形態 : 16名以下の少人数によるセミナー
教材 : ワークブック、ケーススタディ
参加対象者 : コンサルタント、システムアナリスト、プロジェクトマネジャー
ITSSレベル3もしくはレベル4
参加者が新人(もしくはシステム開発に不慣れなエンジニア)の場合は、3日間もしくは4日間でコースを実施することも可能です。
■
プログラムの展開
1. 顧客のビジネスを知る |
ビジョン/スコープ記述書の基となるビジネス背景を理解し、顧客の真のニーズを明確にする |
2. 要求を引き出すファシリテーションと
インタビュー |
効果的な要求引き出しのワークショップとインタビューのやり方を修得する |
3. 要求を決定するルール作り |
異なるニーズを調整する方法を身につける |
4. 要求を記述する |
曖昧さを排除した、メンバーに理解できる要求定義書を記述できるようになる |
5. 品質を記述する |
非機能要求の代表である品質特性を検討する |
6. 正しく伝える(コミュニケーション) |
作成した要求定義の内容を後工程のメンバーに正しく伝える |
■期待される効果
・
仕様/要求定義フェーズで発生する欠陥の減少
・
開発手戻りの減少
・
不要な機能の減少
・
機能拡張コストの低下
・
開発期間の短縮
・
コミュニケーション不良の減少
・
スコープクリープの減少
・
システムテストの見積もりの正確化
・
顧客とメンバーの満足度の向上
ひいては赤字プロジェクトの減少につながることが期待できます。
■参加者の声
−PDU取得のためにPMBOKの座学研修を受けるくらいなら、
実務にも役立つこの研修を受けて、一石二鳥をすすめたいです。
−業務から離れ、改めて学ぶことで自分の悪さ(当然と思っていた)を
みつけられたこと。
−演習と通して実体験ができたこと。座学では分かったつもりで終わっていたと思う。
−要求定義を書けるつもりでいる人が多く、演習を通して反省してもらいたい。
経験レベルでとしてはマネージャクラス、またはマネージャ候補の人たちには
是非参加していただきたい。
−演習を通すことで、ティーチングで言われたことを実感でき、なおかつ
頭で分かっているつもりで実際には理解していないことに気がついた。
−ラーニング中心形式なのが非常に良く、多くの「気付き」「納得」が得られた。
−他受講者の意見に触れることや、講義中に自由に意見を言いあえる雰囲気が
よかった。
|