要件定義後に追加要望が出ない為の方針

Jetzt loslegen. Gratis!
oder registrieren mit Ihrer E-Mail-Adresse
要件定義後に追加要望が出ない為の方針 von Mind Map: 要件定義後に追加要望が出ない為の方針

1. Quality

1.1. システム観点

1.1.1. 要件定義に抜け漏れが無いか確認する

1.1.1.1. 過去にあった要件の抜け漏れを纏めた 表を作成し比較する

1.1.1.1.1. Job Grade

1.1.1.1.2. スキップルール

1.1.1.1.3. 同席者情報

1.1.1.1.4. 金額

1.1.1.2. 機能一覧表を作成しユーザーと認識を合わせる

1.1.1.3. 過去にあった追加要望の一覧を纏めておく

1.1.2. 要件定義がシステムで実現できるか確認する

1.1.2.1. コンカー社、ユーザーと要件定義の内容を確認する場を設ける

1.1.2.2. 過去にシステム設定出来なかった事例を纏めておく

1.1.2.3. 複雑性や難易度についてチェックリストとして纏める

1.2. プロセス観点

1.2.1. プロセス面で問題が無いかCFO統括部と協議する フェーズを設ける

1.2.2. 過去にあったプロセス観点での注意点を纏める

1.3. ユーザー観点

1.3.1. 要件定義のフォーマットを見直す

1.3.1.1. Job Gradeを全て記載しておく

1.3.1.2. 過去に出た追加要件を考慮したフォーマットに組み替える

1.3.2. コンカーのシステム理解を深める

1.3.2.1. マニュアルを確認しておく

1.3.2.1.1. 不明点を本店に聞く

1.3.2.1.2. 不明点をコンカー社に聞く

1.3.2.2. ウェビナーを受ける

1.3.2.3. テストユーザーを用いて画面・機能を確認する

1.4. ルール観点

1.4.1. 要件変更管理プロセスの策定

1.4.1.1. ①明文化

1.4.1.1.1. 変更管理一覧表の作成

1.4.1.2. ②要望理解

1.4.1.2.1. 背景や理由の妥当性について確認

1.4.1.3. ③影響調査

1.4.1.3.1. クリティカルパス上のタスクについて影響がないか確認

1.4.1.4. ④受け入れ判断

1.4.1.4.1. 受け入れ不可の場合は代替案を提示する

1.4.1.5. ⑤変更作業

1.4.1.5.1. コンカー社で設定

1.4.1.5.2. 本店で設定

1.4.2. プロジェクトスコープ表の作成

1.4.2.1. スコープ内、スコープ外の内容の明確化

1.4.3. 要望受付期限の明確化

1.4.3.1. マイルストーンとしてスケジュール表に明示し、 ユーザーとプロジェクト発足時に合意する

1.4.4. AGL対応のルールの事前作成

1.4.4.1. AGL対応の理由の明文化

1.4.4.2. AGL対応のボリューム決定

1.4.4.3. AGL対応の難易度の確認

2. Cost

2.1. 体制増強

2.1.1. 内部体制

2.1.1.1. プロジェクト期間、一時的にITMS要員を増加し 役割を明確化した体制を確保する

2.1.1.1.1. プロジェクト管理

2.1.1.1.2. 設定・技術管理

2.1.2. 外部体制

2.1.2.1. コンカーのコンサルタントを活用する

2.1.2.2. 経費保守チームなど、ベンダーにコンカー設定に関する業務を委託する。 (ITMSがコンカー設定に関するベンダー業務を兼任している状況を踏まえ)

2.2. コンカー社 契約体系

2.2.1. 1契約、設定共有

2.2.1.1. 1拠点導入(Single Country Expense Configurations)として 契約するが、3拠点で設定を共有利用する

2.2.1.1.1. 契約は1つなので1プロジェクト、設定するWF,ポリシーが1つなので 個別設定に比べて安価

2.2.1.1.2. 設定が複雑になる可能性やプロセスを見直しする可能性が高い。 (中国店の場合など)

2.2.2. 1契約、個別設定

2.2.2.1. 3拠点別々のWF,ポリシー導入(Multi Country Expense Configurations)として契約するが、1プロジェクトとして導入を実施する

2.2.2.1.1. 契約は1つ、プロジェクトも1つだが、WF,ポリシーは3つなので 設定共有より高額、1プロジェクトなので基本的にリリース時期は同時 (インド・パキスタンの場合など)

2.2.3. 3拠点別契約

2.2.3.1. 各拠点ごとに1拠点導入(Single Country Expense Configurations)としてConcur導入を実施

2.2.3.1.1. 契約とプロジェクトが分かれるので導入時期は別々、 WF,ポリシーは3つなので設定共有より高額

3. Delivery

3.1. フェーズ変更

3.1.1. 要件定義のフェーズを今までの期間よりも長めに確保しておく

3.1.2. 要件定義フェーズ後に、 要件定義チェックフェーズを設ける (修正期間なども考慮しておく)

3.2. 開発方式の変更

3.2.1. アジャイル開発に切り替える

3.2.1.1. 初回は必要最低限の機能でのリリースとする (1stリリース、2ndリリースを事前に見込む)

3.2.1.2. コンカー社と開発の進め方について確認する

3.3. 導入プロジェクト以外の対応

3.3.1. 並行してプロジェクト対応を行わないようにする

3.3.1.1. 海外店導入プロジェクト(SA対応含む)

3.3.1.2. 国内プロジェクト