「ユーザのための要件定義ガイド」（以下、ガイド）の74ページに「要件定義の位置付け」という項目があり、その中でシステム開発の上流工程を下記のように定義されています。
要件定義は、システム開発の初期に実施される工程であり、前後に企画、基本設計(外部設計)という工程がある。一般的にはこれらの工程を総合して上流工程と表現する。
企画工程では、一般的に経営上のニーズ、課題を実現、解決するための新たな業務の全体像と実現に向けたシステム構想を立案する。この工程では、システム化構想を具現化するために、運用や効果等の実現性を考慮したシステム化計画、プロジェクト計画を具現化し、ステークホルダの合意を得る。
要件定義工程では、企画工程で立案したシステム化計画をインプットに、ステークホルダのニーズ、要望、課題を分析し、利用者や他のステークホルダが必要とするサービスを提供するシステムに対する要求を定義し、ステークホルダと合意して、要件とする。
基本設計(外部設計)では、要件定義で合意した要件をシステムの技術的要件やソフトウエアの構成要素の要件に詳細化する。
図3.1に企画工程、要件定義工程、基本設計(外部設計)工程の主な目的を示す。
上記の中で企画工程について「企画工程では、一般的に経営上のニーズ、課題を実現、解決するための新たな業務の全体像と実現に向けたシステム構想を立案する。」とされていますが、ガイドを通して残念なことは、上流工程における業務分析（ビジネスアナリシス）のへの関心が薄いと感じられることです。
システム開発を行う状況とは、組織が何らかの「課題」を抱えている状況であり、企画段階において必要とされる行動は、
1. ありのままの現状を把握する。
2. そこにある「問題」「課題」を明らかにする。
3. それらを解決する枠組みを見定める。つまり何をどう変えるかを決める。それらは以下の項目を含んでいます。
(1) 組織や人の配置を変える。
(2) 組織や人の役割を変える。
(3) 業務プロセス（ビジネスプロセス）を変える。
(4) 業務プロセスの中にあるシステムを変える。
ＩＴ系の方々は、プロジェクトのコンテキスト（領域）の中心にシステムを置いていることが多いと思います。このことは、ネットで「コンテキスト図」と検索するとシステムを中心に置いたものが多く抽出されてくることでも分かります。
しかし、ユーザが捉えるコンテキストは中心がビジネスモデルや業務プロセスになります。私の考えるシステムはあくまで業務プロセスの一部であり、課題解決プロジェクトの主役ではないと思っています。現実問題、書籍やネットの情報を紐解くと「業務改善」を語る方は「システム」をあまり語らず、「システム」を語る方はあまり「業務改善」を語っていません。残念ですが・・・日本では「業務」（ビジネス）と「システム」の間に深い「谷」があるように感じられます。
アメリカなどでは「ビジネスアナリスト」という業種・業務が広く認知されており、ネットで調べるとビジネスアナリストとしてのプロフェッショナリティ向上のための多くの教育サイトがあります。
日本でもＩＩＢＡ日本支部が中心となってビジネスアナリシスの聖書であるＢＡＢＯＫ（Business Analysis Body of Knowledge）の普及に努めていますが、今一つ盛り上がりに欠けています。
確かに、ＢＡＢＯＫはＡ４版500ページに及ぶ大著であることに加え、「何を（What）するか」は描いてありますが「どうやって（How）」は書かれていません。この辺が日本で広がらない原因かもしれません。アメリカなどでは、このHowについては各組織の独自の方法論を採用して実行するものと考えられているためです。
（このブログではHowについても綴って行き、皆さんに業務分析（ビジネスアナリシス）に関心を持って戴きたいと思っています。）
ユーザ主導の要件定義（ひいては、システム開発）を実現のために、これから要件定義に携わる日本のユーザ部門の方々に是非「業務分析」（ビジネスアナリシス）に馴染んで戴きたいと思います。
ガイドの57ページに、執筆されたワーキンググループのメンバーから提示された「要件定義の問題」27項目が列挙されています。内容を吟味してみると27項目のうち、12項目が企画段階における業務分析を行わないと解決できない、または、業務分析をしっかり行えば解決できる内容だと思われますので掲載いたします。
|
|
業務分析 の不足 |
要件定義の問題 |
内容 |
|
１ |
○ |
現状把握の問題 |
現行業務やシステムが分からない |
|
２ |
○ |
問題課題抽出の問題 |
真の問題・課題が抽出できていない |
|
３ |
○ |
ゴール明確化の問題 |
経営要求が不明確 経営に貢献する要求にならない |
|
４ |
△ |
要求の体系化の問題 |
要求間の整合性がとれていない |
|
５ |
○ |
要求の具体化の問題 |
要求に基づき新らたな業務としてうまく具体化できない |
|
６ |
|
優先順位付けの問題 |
要求が膨らみ、捨てる判断が難しい |
|
７ |
○ |
要求の交渉の問題 |
各ステークホルダに対し要求の合意形成が難しい |
|
８ |
△ |
要求の仕様化の問題 |
成果物に抜け・漏れ・あいまいが存在する |
|
９ |
|
要求の検証の問題 |
要件定義の不具合を抽出しきれない |
|
１０ |
○ |
妥当性確認の問題 |
システム化仕様が経営や業務にどう貢献するか分からない |
|
１１ |
○ |
立ち上げ時の問題 |
要件定義前の構想や企画が不十分 開始前に必要なステークホルダが洗い出されていない |
|
１２ |
△ |
要件定義プロセス 計画の問題 |
要件定義で何をどこまで実施すれば良いのか分からない |
|
１３ |
○ |
スコープ定義の問題 |
そもそも開発スコープがあいまいである |
|
１４ |
|
見積りの問題 |
要求件数では開発規模の膨らみが分からない |
|
１５ |
|
品質計画の問題 |
要件定義ドキュメントの品質の確保方法が分からない |
|
１６ |
|
体制・チームビルディングの問題 |
要件定義の体制が不十分である |
|
１７ |
|
契約の問題 |
要件定義の契約形態がパラパラである |
|
１８ |
|
コミュニケーション計画の問題 |
コミュニケーションが不十分である |
|
１９ |
|
リスク認識の問題 |
リスクを把握できていない |
|
２０ |
△ |
要求・スコープコントロールの問題 |
要求調整・規模調整のコントロールができない |
|
２１ |
|
品質の監視の問題 |
要件定義の品質を監視できない |
|
２２ |
|
コミュニケーション監視の問題 |
コミュニケーションかうまくいっているか分からない |
|
２３ |
|
リスクの監視の問題 |
課題やリスクか放置される |
|
２４ |
|
トレーサビリティ管理の問題 |
ドキュメント間の整合性がいつの間にか失われる |
|
２５ |
|
要求評価の問題 |
要件定義完了時期に未決定要求が残る |
|
２６ |
|
完了判断の問題 |
要件定義の完了を判断できない |
|
２７ |
|
要件定義ドキュメント記載上の問題 |
要件定義ドキュメントのサンプルや書き方のコツが欲しい |