今回は「ユーザのための要件定義ガイド」第4章（４・１・３）「ゴールの抽出」から要件定義に当たっての「（２）業務レベルでの目的・目標を抽出する」について考察してみたいと思います。
ガイドでは以下のように述べられています。（抜粋）
⑵ 業務レベルの目的・目標を抽出する
【解決したい問題】
■経営に貢献するためのサブゴールである業務レベルの目的・目標が明確でない
・業務として目指すものが不明確
・システム化要求が経営レベルの要求にどのように貢献するかが不明確
・システムの操作性要求が多くなる
経営やビジネスに貢献する要求が抽出できない原因として業務レベルの目的・目標が不明確であることがある。経営レベルの目的・目標を最終ゴールとすれば業務レベルの目的・目標はサブゴールに当たる。サブゴールを設定せずに手段、施策を検討するとややもすると経営を意識し過ぎて業務に貢献しない要求になったり、逆に意識が薄れて経営に貢献しない要求になったりする。経営レベルの目的・目標と業務レベルの目的・目標の双方を整合性を持って設定することも一つの解決方法である。
勘どころ① 目的と手段の違いを意識する
目的と手段は異なるものであるが、それらを正しく使い分けられていないことがしばしば見受けられる。このガイドでは、「目的」と「手段」を以下のように定義する。
●目的：状態の変化、「〜を改善したい」「価値を上げたい」といった経営や業務で何らかの価値を
上げたい、得たいという要求であり、目指すところ、達成したい結果
●手段：どんな手を打つか、「〜を実施したい」「〜を実行したい」目的・目標を実現するために
施すべき対策を実行可能な内容で定義したもの
（中略）
上記は、用語の定義をこうするべきだと述べているわけではなく、この違いを意識して要求の抽出をして欲しいということが主旨である。
勘どころ② 目的と目標の違いを意識する
目的と目標を本書では以下のように定義する。目的は目指すべき方向でありゴールである。目標とはその目的を達成するためのマイルストーンである。目標は、今はこのくらい (現状値)だが、いつまでに (達成時期)、どのくらいの効果 (目標値)を目指すのかを示す具体的な時期と指標を持っている。このように定義すると整理しやすい。目的に対して目標を設定することが重要である。目的と目標の関係を図4.9に示す。
ここも用語の定義をこうするべきだと述べているわけではなく、この違いを意識して要求の抽出をして欲しいということが主旨である。
勘どころ③ 目的・目標にはレベルがあることを意識する
要件定義には、経営者、業務部門の長、業務のリーダー、業務の担当者、システムのオペレータ、ITシステムの利用者など価値観の異なるステークホルダが多数存在する。各ステークホルダにはそれぞれの目的・目標がある。経営やビジネスに貢献する要求を見極めるためには、ステークホルダそれぞれの異なる目的・要求を図4.10のように関連付ける必要がある。
図 4.10に示すように、「売上を伸ばす」という目的は、各ステークホルダの活動を関連付けた結果であり、より上位レベルの目的となる。仮に売上が未達成だったときに、営業部門は商品が悪いから、商品開発部門は売り方が悪いからと目標未達の原因が他のステークホルダの影響を受けることになってしまうので、「売上を伸ばす」という目的は、営業部門や商品開発部門の目的より、上位レベルの目的になる。
勘どころ④ 業務レベルの目的・目標を抽出する
経営レベルの目的・目標や施策は、抽出というより要件定義への与件の確認であった。経営や業務に貢献するITシステム化要求を抽出するには、経営レベルの目的・目標を目指した下位(業務レベルの目的)の目的・目標に相当する要求を獲得しなければならない。
業務レベルの目的・目標の抽出には2つのアプローチがある。経営レベルの目的・目標に沿って部門長などが決めるトップダウンアプローチと、現場の意見を聞いて現場の課題や要求を実現するために設定するボトムアップアプローチである。経営レベルと現場の双方の要求を満たしたものにしたいという思いから、両方のアプローチを併用して抽出することも多い。
経営レベルの目的とシステム機能レベルの要求(手段)だけがあり、業務レベルの目的がない中抜けの要件定義を見かけることがある。この場合、完成したシステムは経営層の意図とは異なるものや、業務プロセスの変わらないものになりがちである。
経営層の意識とシステム開発を有機的につなげるためにも業務レベルの目的の抽出・設定が重要になる。
「ユーザのための要件定義ガイド」をここまで読み進めて来て、筆者が感じるところは、「ガイド」（第4章）の著者は「ダメな要件定義」をたくさん経験して、そのダメな点をガイドにまとめておられるようだ・・・と言うことです。上記の引用部分における指摘も本来要件定義工程に入る前工程である「企画工程」で「経営の要求」が十分に分析されておらず、また更に「企画工程」の検討成果が「要件定義工程」に引き継がれていない・・・と（言い換えれば）仰っているように感じます。
また、「ガイド」を通じて残念なことは、要件定義のプロセスが「ガイド」の中ではっきりとは示されておらず、著者の皆さんが過去のプロジェクトで接した「ダメな要件定義」を是正する・・・と言うトーンに終始していると言うことです。
その原因として筆者が主に考えるところは以下の通りです。
1. 日本では、ビジネスプロセス・マネジメントが広く認識されておらず（ビジネス・アナリストも不在）、システム開発を含めた業務改革のプロセスが確立していない。
2. システム開発が要件定義も含めてＩＴベンダーに丸投げされ、要件定義を担ったＩＴベンダーのＳＥは、ユーザーの経営レベルへの関りがなかなか持てず、その結果ＳＥは仕方なくユーザーの現場担当者からのみヒアリングを行って要件定義を行ってきた（従って、現場レベルの要求だけしか抽出出来なかった）歴史があること。
3. ２の結果、業務要求は軽視され、システム要求だけにフォーカスされていた。
4. ユーザーに「要件定義」はユーザーの責任であるという認識が薄い。
上の理由を踏まえ、せっかく、ユーザに「要件定義」はユーザの責任と言うことを認識してもらい、ユーザの担当者が要件定義をするために500ページの大著を執筆されたのですから、ベストプラクティスを示す内容にして戴きたかったと思います。