● 価値ある要件定義書の成果物を創るために
|
【ページ構成】 ■ 要件定義書の失敗事例と原因
■ 目的達成へと導く「要件定義書」
■ 価値ある成果物を創るための条件
■ 要件定義作業でのベンダ力量のチェックと判断
情報システムの検討を意味するパッケージ導入(クラウド導入)プロジェクトの失敗の多くは、要件定義書(FIT&GAP/要求定義含む)の成果物に起因しています。その原因は「対象範囲のカバー漏れ、具体性の欠如、曖昧表現、スキル不足、ストーリの無いまとめ方」など多岐に渡っています。また、ユーザとベンダ共に企業環境の変化に対応すべき情報システムの活用方法を提示できない成果物の内容にもあります。システム要件が経営方針、取引条件、業務効率、管理内容及び情報技術などが関連しあって決まるという中堅・中小企業の経営ニーズへの基本的な理解不足です。
失敗した要件定義書の成果物事例を通して、どこに問題点と原因があるかを明らかにします。つぎに、あるべき要件定義書の構成サンプルの提示とコンテンツの整理をしました。最後に、良き要件定義書を創るための条件をまとめました。
価値ある「要件定義書」とは
良い要件定義書の成果物は次のような条件を満たす必要があります。
① 目的達成のために必要な「システム要件・作業・稼働環境・運用」を整理。
② ユーザ要求・ベンダ提示・社会的ニーズを基に、「アイデア・ノウハウ・問題
解決」を加味。
③ 「保留・未解決・後作業工程での決定」事項を整理し、ユーザとベンダとの
納得できる合意。(ユーザテストなど後工程で決まる要件もありえます。)
④ 稼働までの作業スケジュール、ユーザとベンダの役割分担などの作業図式
の具体化。
⑤ ユーザが分かり易く、理解できる「具体性・言葉・構成・体系」を持った文書。
■ 価値ある要件定義書を創るためには、作業の進め方と成果物作成に関する
スキル、技法及び知識が必要です。このことに関心のある方は次ページを!
(参考) 「要件定義に必要なスキルと技法」ページ
|
● 要件定義書の失敗事例と原因
|
経営者の意思決定で行うパッケージ導入(クラウド導入)での要件定義書の持つ意味は大きいです。単なるドキュメントでなく、稼働する情報システムのあり方と作業工程を決めます。失敗が許される作業では決してありません。
要件定義書の成果物の失敗事例を通して、どのような内容が失敗にあたるかを理解し体得することは要件定義書の作成担当者にとっては大事なことです。「他山の石」とします。価値のある成果物を創るためには、経営管理・業務改善・マネジメント・情報技術の適用・整理力など多様な実践力が不可欠です。
(参考) 「要件定義・FIT&GAP作業」におけるのトラブル現象

|

失敗事例を基に「どこが駄目なのか、どこに欠陥があるのか」を列記します。これらの欠陥は、
失敗したプロジェクト案件に共通に見られます。 是非、下記のダウンロード資料を手元におい
て読んで下さい。
【参考】 ダウンロード資料<152「要件定義書」の悪い事例>
対象 |
内容 |
目的達成 |
- 目的達成のための必要項目が網羅されていない。
- 必要なシステム要件、業務ルール/管理内容の改善が明記されていない。
|
網羅性 |
- 目的、導入方針、期待効果、前提条件など要件定義書の主旨説明がない。
- ユーザの事業環境、取引形態、扱い商品などの事業に関する基本定義がない。
- 実現に必要な稼働までの作業「現行システムの取扱、移行処理、タスク」が整理されていない。
|
実態把握 |
- 業務フローのみで、経営管理・マネジメント・管理ポイントを具体的に押さえていない。
- データ・情報量などの件数をピーク・総数・平均という観点から把握していない。
- 各種伝票・データの締め(日次・月次・・・)などに関する運用状況が捉えられていない。
- 取引先との例外処理、個別処理、特殊処理などが明記されていない。
- 上記内容を踏まえた条件整理、定義がない。
|
分かり易さ |
- 文章表現が羅列で、要件表現に乏しく誤解を生む解釈が可能になっている。
- 図解表現がなく、整理されていない。
- 論理性を考慮した定義がされていない。
- ユーザから見て具体性に欠け、どのようなシステムになるのか見当がつかない。
|
課題解決 |
- 課題を狭いシステム要件のみに整理し、経営・マネジメント・業務要件からの課題が見当たらない。要件定義において、これらの視点からの課題無しはあり得ない。
- 未解決の課題もあり得るし、次作業以降での解決すべき要件の整理がされていない。
|
● 目的達成へと導く「要件定義書」
1.対象範囲
対象範囲の事業基盤をしっかり把握することです。その事業領域が複数の要素(例:小売と
卸)を持っている場合、その「広さ」が大きくなり要件定義作業に負荷がかかってきます。
また、情報連携や管理レベルの緻密さが要求されると、その要求に応じて複雑性を増すのが
一般的です。
対象 |
内容 |
広さ |
- 目的達成のための業務、経営管理、取引先などの領域
- 現行システム/外部とのインターフェイス、他業務などの関連領域
- 生産、小売、卸売、商社、加工、修理などの事業領域
- 扱い商品の形状、価格、流通経路などの取引条件
- 締め/日次などの運用条件、情報量、顧客サービスの条件
|
深さ |
- 収益、原価、予算などの経営管理の緻密さ
- 生産、小売、卸売などの事業領域間の業務/情報連携
- 商流、物流、生産流、情報流の相互関連性
- 活動場所、組織の階層レベル
- 取引先要望、伝票訂正、データ訂正などの変更管理
- 業務プロセスの自動処理と手作業の関係
|
2.まとめ方
成果物のドキュメントは、それなりの分かり易さと説得力を持つ構成が必要です。目的を達成す
るためのシステム要件を含む全ての作業、準備事項、プロジェクト関連です。また、その内容が
「システム全体を矛盾なく無駄なく、実務として機能させる」という論理性です。
【参考】 ダウンロード資料<156「要件定義書」構成のチェックリスト>
(参考) 「要件定義・FIT&GAP」ページの「検討作業への姿勢と要点」
対象 |
内容 |
構成 |
- 目的、期待効果、方針、対象範囲、前提条件などの主旨
- 現状、基本数字、課題、解決策などの事実確認
- 取引条件、定義の対象、画面提示、インフラの具体化
- 費用(予算)、スケジュール、プロジェクト体制
|
論理性 |
- システム要件、業務ルール、管理基準の一体化
- 「人と作業と管理」の仕組み(システムは道具・素材なり)
- 目的達成に必要な課題解決策と改善点の明示
- 「構成」内容が誰でも納得し理解でき実現する文書
- 次作業工程以降の作業内容と要件確定タイミングの現実性
|
3.分かり易さ
ユーザが要件定義書の成果物を理解し納得できるかがプロジェクト成否につながります。その
成功のためには要件定義書が見易く、分かり易く、理解し易いが絶対条件です。「まとめ方」を踏
まえた「考え方と図解表現」が軸になります。
【参考】 ダウンロード資料<155「情報整理と図解の技法>
対象 |
内容 |
考え方 |
- システム要件は最低限2つの要素の条件で成り立っており、マトリックス表現が可能
- データ処理は業務処理を反映させるのが筋ですので、ユーザが使用する言葉で表現
- 取引条件、定義の対象、画面提示、インフラの具体化
- 費用(予算)、スケジュール、プロジェクト体制 の根拠
|
図解表現 |
- ブレーンストーミング、KJ法、グルーピングなどによる情報の収集と整理
- フロー、マトリックス、 フレームワークなどによる図解
- 数字を使用した事例、計算方法、基準値の具体的明示
- 使用予定のプロトタイプ画面の提示(入力・更新・検索照会)
|
● 価値ある成果物を創るための条件
|
価値ある成果物とは、パッケージ導入を成功に導く要件定義書ということです。要件定義書の重要性を正しく認識し、目的達成のための要件と条件を押さえ全ての関係者が合意できる内容にすることです。また、ユーザとベンダが協力し困難を乗り越える土壌を作ることです。

1.「要件定義書」重要性の認識と行動
- プロジェクト案件の失敗の多くが、この要件定義書の作業内容に起因しています。
- プロジェクト稼働まで多くの時間と期間があるという油断と甘さがあります。
- 「無→有」「カオス→システム」「不明→明確」「不安→解消」の側面がある作業であり、それに応じた作業スタイルと体制が不可欠です。
- 「情報システムは道具・素材」という理解の基に、作成したドキュメントなり成果物をチェックすることです。目的達成は可能かというチェックです。
2.基本要件と基本手順の明確化
要件定義作業を行うための基本情報と条件を整え、関係者で理解し合意します。その整理
された内容に沿って、作業の基本手順を決めます。
【 基本要件 】
・ 目的、期待効果、稼働時期の明確化
・ 前提条件の整理(予算、現行システムの取扱、経営者の指示事項・・・)
・ 課題の整理とその課題解決策の具体化と実現策
(参考) 「課題解決の簡単な進め方」ページ
・ パッケージ商品への適合性の確認(パッケージ前提の作業か否か)
(参考) 「パッケージ商品の選択方法」ページ
・ 成果物の範囲、構成、内容
【参考】 ダウンロード資料<156「要件定義書」構成のチェックリスト>
・ プロジェクト体制(責任者、メンバー、役割分担)、スケジュール
【 基本手順 】
ユーザの実情に合った基本手順を作り上げることです。この手順の組み立ては重要
です。ベンダ提案をしっかり見極め、納得することです。
上記「基本要件」に加えて、基本手順を決める要因を考慮します。
・ 要件定義対象の広さと深さ
・ 課題の量と質、その解決策
・ 中間チェックレビューの設定
(参考) 「基本手順とパターン選択」ページ
3.(ユーザ・ベンダ)体制と役割の確立
【 ユーザ 】
・ 経営者の参画、実行責任者の権限、メンバーの選出
・ 要件に関する意思決定の手順とメンバー
・ プロジェクト体制の組織的位置付け
・ メンバーの作業時間確保と責任範囲、役割分担
【 ベンダ 】
・ ユーザ要件に応じた業務知識、スキル要員の選抜
・ プロジェクトマネジメントができる責任者の配置
・ 要件定義作業のリーダシップ発揮(準備、基本要件の点検、基本手順の提示)
・ 最終成果物の構成と内容の提示
【 共同 】
・ 作業環境(セッション、中間成果物のチェック、情報共有、資料・・・)の決定
・ 進捗管理、問題管理の基準と手順
・ レビュー開催のルール(時期、参加者、やり方、中間成果物)
|
|
コンピュータは「道具」でなく「素材」である。・・・・この表現は、与えられたソフトウェアを鵜呑みにしてコンピュータを使うのでなく、数字によって構築されたこの新たな素材によってどのような知の世界が開拓できるかを深く精密に考える必要があるという示唆を含んでいる。・・・・ある素材が優れた素材となるためには、まず素材特性を極限まで純化するプロセスが必要である。
(参考:「デザインのデザイン」 原研哉著 岩波書店)
|
要件定義作業でのベンダ力量のチェックと判断
|
要件定義作業を通して、ベンダ担当のプロジェクトマネジャーとSEの力量を把握することがユーザの仕事でもあります。成果物はベンダ力量に比例して、その内容に正直に反映されます。その結果、システム稼働まで担当者として任せられるか否かの判断をユーザとして行います。このチェックと判断はユーザにとって大事な行為です。
この行為をしないで、稼働時期が迫って「何かおかしい、不安だ」と気付いたときには後の祭りです。プロジェクト案件の成否はこのプロジェクトマネジャーとSEの力量に関わっている面が大きいです。次のような現象が要件定義作業の中で複数発生していると、担当者(又はベンダ)としては適格性を欠いていると想定されます。改善のためのアクションをベンダに対して早急に行うことです。最悪のケースはベンダの交代を考えることも必要になります。
|
