【ページ構成】　■ 要件定義書の失敗事例と原因
　　　　　　　　　　　　　　　　　 ■ 目的達成へと導く「要件定義書」
　　　　　　　　　　　　　　　　　 ■ 価値ある成果物を創るための条件
　　　　　　　　　　　　　　　　　 ■ 要件定義作業でのベンダ力量のチェックと判断　　　　　　　　　　

パッケージ導入（情報システムの構築）プロジェクトの失敗の多くは、要件定義書（FIT&GAP/要求定義含む）の成果物に起因しています。その原因は「対象範囲のカバー漏れ、具体性の欠如、曖昧表現、スキル不足、ストーリの無いまとめ方」など多岐に渡っています。また、ユーザ・ベンダ共に情報システムを活用する企業環境の変化についていけない面もあります。システム要件が経営方針・取引条件・業務効率・管理内容・情報技術などが関連しあって決まるという中堅・中小企業ニーズへの理解不足です。

失敗した要件定義書の成果物事例を通して、どこに問題点と原因があるかを明らかにします。つぎに、あるべき要件定義書の構成サンプルの提示とコンテンツの整理をしました。最後に、良き要件定義書を創るための条件をまとめました。
　　（要求定義書の成果物も同様と考えます。ユーザ要求のみをまとめた要求定義書は、中堅・
　　　中小企業では作業効率から見て、非効率になり易いです。）

　価値ある「要件定義書」とは　

　　　　良い要件定義書の成果物は次のような条件を満たす必要があります。
　　　　　　　　① 目的達成のために必要な「システム要件・作業・稼働環境・運用」を整理。
　　　　　　　　② ユーザ要求・ベンダ提示・社会的ニーズを基に、「アイデア・ノウハウ・問題
　　　　　　　　　　解決」を加味。
　　　　　　　　③ 「保留・未解決・後作業工程での決定」事項を整理し、ユーザとベンダとの
　　　　　　　　　　納得できる合意。（ユーザテストなど後工程で決まる要件もありえます。）
　　　　　　　　④ 稼働までの作業スケジュール、ユーザとベンダの役割分担などの作業図式
　　　　　　　　　　の具体化。
　　　　　　　　⑤ ユーザが分かり易く、理解できる「具体性・言葉・構成・体系」を持った文書。　　　　　

経営者の意思決定で行うパッケージ導入（情報システムの構築）での要件定義書の持つ意味は大きいです。単なるドキュメントでなく、稼働する情報システムのあり方と作業工程を決めます。失敗が許される作業では決してありません。
要件定義書の成果物の失敗事例を通して、どのような内容が失敗にあたるかを理解し体得することは要件定義書の作成担当者にとっては大事なことです。「他山の石」とします。価値のある成果物を創るためには、経営管理・業務改善・マネジメント・情報技術の適用・整理力など多様な実践力が不可欠です。
     　　　　　　　　　　　　　　　  （参考） 「要件定義・FIT&GAP作業」におけるのトラブル現象 

1. 目的達成のための必要項目が網羅されていない。
2. 必要なシステム要件、業務ルール/管理内容の改善が明記されていない。

1. 目的、導入方針、期待効果、前提条件など要件定義書の主旨説明がない。
2. ユーザの事業環境、取引形態、扱い商品などの事業に関する基本定義がない。
3. 実現に必要な稼働までの作業「現行システムの取扱、移行処理、タスク」が整理されていない。

1.  業務フローのみで、経営管理・マネジメント・管理ポイントを具体的に押さえていない。
2. データ・情報量などの件数をピーク・総数・平均という観点から把握していない。
3. 各種伝票・データの締め（日次・月次・・・）などに関する運用状況が捉えられていない。
4. 取引先との例外処理、個別処理、特殊処理などが明記されていない。
5. 上記内容を踏まえた条件整理、定義がない。

1. 文章表現が羅列で、要件表現に乏しく誤解を生む解釈が可能になっている。
2. 図解表現がなく、整理されていない。
3. 論理性を考慮した定義がされていない。
4. ユーザから見て具体性に欠け、どのようなシステムになるのか見当がつかない。

1. 課題を狭いシステム要件のみに整理し、経営・マネジメント・業務要件からの課題が見当たらない。要件定義において、これらの視点からの課題無しはあり得ない。
2. 未解決の課題もあり得るし、次作業以降での解決すべき要件の整理がされていない。 

投資に応えるためには「要件定義書」を生きたドキュメントとして作成することです。生きたドキュメントとは出戻りすることなく、情報システムの要件に自信を持ち、、次作業以降に使えるドキュメントです。そのような内容を備える要件定義書の作成ポイントをまとめました。
価値ある要件定義書は間違いなくユーザとベンダの絆の強い活動につながります。
                          【参考】 ダウンロード資料＜154「要件定義書」作成の要点＞
            　　　　　　【参考】 ダウンロード資料＜153「企業の仕組みと取引条件」＞

• 目的達成のための業務、経営管理、取引先などの領域
• 現行システム/外部とのインターフェイス、他業務などの関連領域
• 生産、小売、卸売、商社、加工、修理などの事業領域
• 扱い商品の形状、価格、流通経路などの取引条件
• 締め/日次などの運用条件、情報量、顧客サービスの条件

• 収益、原価、予算などの経営管理の緻密さ
• 生産、小売、卸売などの事業領域間の業務/情報連携
• 商流、物流、生産流、情報流の相互関連性
• 活動場所、組織の階層レベル
• 取引先要望、伝票訂正、データ訂正などの変更管理
• 業務プロセスの自動処理と手作業の関係　

• 目的、期待効果、方針、対象範囲、前提条件などの主旨
• 現状、基本数字、課題、解決策などの事実確認
• 取引条件、定義の対象、画面提示、インフラの具体化　
• 費用（予算）、スケジュール、プロジェクト体制

• システム要件、業務ルール、管理基準の一体化 
• 「人と作業と管理」の仕組み（システムは道具・素材なり）
• 目的達成に必要な課題解決策と改善点の明示
• 「構成」内容が誰でも納得し理解でき実現する文書
• 次作業工程以降の作業内容と要件確定タイミングの現実性

• システム要件は最低限２つの要素の条件で成り立っており、マトリックス表現が可能 
• データ処理は業務処理を反映させるのが筋ですので、ユーザが使用する言葉で表現 
• 取引条件、定義の対象、画面提示、インフラの具体化　
• 費用（予算）、スケジュール、プロジェクト体制 の根拠

• ブレーンストーミング、KJ法、グルーピングなどによる情報の収集と整理
• フロー、マトリックス、 フレームワークなどによる図解
• 数字を使用した事例、計算方法、基準値の具体的明示
• 使用予定のプロトタイプ画面の提示（入力・更新・検索照会）

価値ある成果物とは、パッケージ導入を成功に導く要件定義書ということです。要件定義書の重要性を正しく認識し、目的達成のための要件と条件を押さえ全ての関係者が合意できる内容にすることです。また、ユーザとベンダが協力し困難を乗り越える土壌を作ることです。

１．「要件定義書」重要性の認識と行動

• プロジェクト案件の失敗の多くが、この要件定義書の作業内容に起因しています。
• プロジェクト稼働まで多くの時間と期間があるという油断と甘さがあります。
• 「無→有」「カオス→システム」「不明→明確」「不安→解消」の側面がある作業であり、それに応じた作業スタイルと体制が不可欠です。
• 「情報システムは道具・素材」という理解の基に、作成したドキュメントなり成果物をチェックすることです。目的達成は可能かというチェックです。
   

２．基本要件と基本手順の明確化
　　　要件定義作業を行うための基本情報と条件を整え、関係者で理解し合意します。その整理　
　　　された内容に沿って、作業の基本手順を決めます。
　　　【 基本要件 】
　　　　　　　・ 目的、期待効果、稼働時期の明確化
　　　　　　　・ 前提条件の整理（予算、現行システムの取扱、経営者の指示事項・・・）
　　　　　　　・ 課題の整理とその課題解決策の具体化と実現策
                                 （参考）　「課題解決の簡単な進め方」ページ
　　　　　　　・ パッケージ商品への適合性の確認（パッケージ前提の作業か否か）
　　　　　　　　　　　　　　  （参考）　「パッケージ商品の選択方法」ページ
　　　　　　　・ 成果物の範囲、構成、内容
                                  【参考】 ダウンロード資料＜156「要件定義書」構成のチェックリスト＞
　　　　　　　・ プロジェクト体制（責任者、メンバー、役割分担）、スケジュール

 　　　【 基本手順 】
　　　　　　　 ユーザの実情に合った基本手順を作り上げることです。この手順の組み立ては重要
　　　　　　　　です。ベンダ提案をしっかり見極め、納得することです。
　　　　　　　 上記「基本要件」に加えて、基本手順を決める要因を考慮します。

　　　　　　　　　　・ 要件定義対象の広さと深さ
　　　　　　　　　　・ 課題の量と質、その解決策
　　　　　　　　　　・ 中間チェックレビューの設定
　　　　　　　　　　　　　　　 （参考）　「基本手順とパターン選択」ページ

３．（ユーザ・ベンダ）体制と役割の確立
　　　【 ユーザ 】
　　　　　　　・ 経営者の参画、実行責任者の権限、メンバーの選出
　　　　　　　・ 要件に関する意思決定の手順とメンバー
　　　　　　　・ プロジェクト体制の組織的位置付け
　　　　　　　・ メンバーの作業時間確保と責任範囲、役割分担
　　　【 ベンダ 】
　　　　　　　・ ユーザ要件に応じた業務知識、スキル要員の選抜
　　　　　　　・ プロジェクトマネジメントができる責任者の配置
　　　　　　　・ 要件定義作業のリーダシップ発揮（準備、基本要件の点検、基本手順の提示）
　　　　　　　・ 最終成果物の構成と内容の提示
　　　【 共同 】
　　　　　　　・ 作業環境（セッション、中間成果物のチェック、情報共有、資料・・・）の決定
　　　　　　　・ 進捗管理、問題管理の基準と手順
　　　　　　　・ レビュー開催のルール（時期、参加者、やり方、中間成果物）　　　

要件定義作業を通して、ベンダ担当のプロジェクトマネジャー・SEの力量を把握することがユーザの仕事でもあります。成果物はベンダ力量に比例して、その内容に正直に反映されます。その結果、システム稼働まで担当者として任せられるか否かの判断をユーザとして行います。このチェックと判断はユーザにとって大事な行為です。
この行為をしないで、稼働時期が迫って「何かおかしい、不安だ」と気付いたときには後の祭りです。プロジェクト案件の成否はこのプロジェクトマネジャー・ＳＥの力量に関わっている面が大きいです。次のような現象が要件定義作業の中で複数発生していると、担当者としては適格性を欠いていると想定されます。改善のためのアクションをベンダに対して早急に行うことです。

• ユーザが日常使っている言葉（取引、社内向け、業界、事業）を正しく理解できない。
• ドキュメント（図表・文章）でなく、口頭でのやり取り・説明・質問回答が多い。
• 業務処理・経営管理からの発想が少なく、データ処理（言葉・説明）の発想が多い。
• 質問内容がどうでもよいことが多く、本質・ポイントをついた質問が少ない。
• 「出来ない」ことの回答が多く、提案・代案・提示なりの行為が欠けている。
• 「運用での対応」という回答がたびたびあり、要望への具体的対応を欠いている。
• 決められた約束事項を守らない、忘れているケースが見受けられる。
• 事例・経験など具体性を持った説明が少なく、一般論・机上論・講釈に終始している。
• 一つのテーマを議論しているとき、他テーマとの関連性是非の指摘が見られない。 
• ストーリ・論理性・具体性に欠け、分かりにくい打合せ・セッションが多い。
• 作業の進め方が、ユーザの考え・状況を踏まえた内容になっていない。
• パッケージのシステム機能の押し付けが多く、問題解決策の提示が少ない。
• 最終成果物への道筋が分かりにくく、リーダシップが感じられない。
  　　（参考）　パッケージ導入から稼働ページの「ベンダの作業品質のチェックポイント」
  
  【 要件定義作業に必要なスキル 】
  　　　・ 上記図表の３つのスキルがあって、要件定義作業が可能です。この１つが欠ける
  　　 　　と価値ある要件定義書はできません。要件定義書作成は、最も難しい作業であり
  　　　　 スキルの総合力が要求されます。 
  
  ■ 要件定義作業との関連で、業務のルールと仕組みの改善に関心のある方は
  　　次ページを！

                          　　　（参考） 「業務改善への情報システムの活用」ページ 
  ■ 要件定義作業と並行、又は事前に行う必要性のある課題解決作業に関心の
  　　ある方は次ページを！
  　　　　　　　　　　　　　　（参考） 「課題解決の簡単な進め方」ページ
  ■ 要件定義作業の成果物に対して、情報システムの導入価値を高めることに
  　　関心のある方は次ページを！
  　　　　　　　　　　　　　　（参考） 「企業情報システムのあり方」
  　　　　　　　　　　　　　　（参考） 「企業活動を支える情報活用の見方」