「ユーザのための要件定義ガイド」P42に「経営者が意識すべきこと」という一節があり、紹介します。
その１
【良き構想なくして良き要件定義はない】
経営や業務に貢献するシステムを作るためには、十分な予算と期間を取ってビジネスの構想やシステムの構想を立案し、それを要件定義につなげていく必要かおる。要件定義は構想立案の結果をもとに実施する工程であるが、ダメな構想のもとではいくら要件定義をがんばっても意味がない。単なるシステム置き換えプロジェクトでなければ､業務や組織の仕組みの変史が伴う。ビジネス構想が人前提になっているはずである。要件定義が始まる前に構想立案の確認を行うことが重要であり、不備があったら整備の時間を設けるべきである。
私の考えでは、ここで言うところの「ダメな構想」とは、どういうシチュエーションで「ダメ」の烙印を押せるのだろうかと疑問がわきます。「構想立案の確認」とありますが「確認方法」はどのようなものでしょうか？「議論を尽くしていない思いつきレベル」と言う意味であれば、経営者が思いついたのでしょうか？よくあるのは、経営者が業界団体の会合などで聞きかじってきて「SFAをわが社でも検討しろ。」なんて言う話しはありそうです。
しかし、私は「構想」がどんなものであれ、出された瞬間から「要件定義」は始まっていると考えています。つまり、その「構想」のフィージビリティ検討が既に「要件定義」の一部だと考えています。
「構想」が出されたと言うことは、「どこかの」「何か」を「どうしたい」について漠然とした背景の表明があるはずです。と、言うことは・・「どこか」は部門・部署、「何か」は業務またはシステム等、そして「どうしたい」は対象が業務であれば「変えるか作る」、システムであれば「導入する」になります。まさか、表明されただけで決定されるはずもないのではないでしょうか？当然、表明された「どこかの」「何か」と「どうしたい」を検討するはずで、「最も高い次元（大きい粒度）での要件定義」と考えられます。この工程はフィージビリティ検討と呼べますが、内容は要件定義であり、「構想」の不備（ダメ出し）はこの検討で明らかにされるのです。
その２
【経営層の参画、リーダーシップ】
経営層は、ビジネス構想やシステム構想を要件定義プロジェクトに浸透させる必要がある。業務部門中心での体制を作ったからといって、構想に従ったシステムかできあがるとは限らない｡業務部門(特に現場)の基本的思考は現状作業のムダ､ムラ、ムリの改善であり、今行っていることの大きな変化を嫌う保守的な傾向を示すこともある。紙の上に構想を書いただけでは、経営層の思ったとおりのビジネスプロセスやシステムにならないことがある。システム化によって、経営として何を目標にするか明確にすることか重要であり、要件定義後に要件定義で実現することが､本来の目標をクリアできるか､確認しなくてはならない。そのレベルの目標にすることが重要であり、数値レベルの具体的な目標あるいは、達成状況が確認できるレベルの目標設定が必要である。この経営目標を達成できないのなら、再度要件定義の見直しが必要になる。経営層は積極的に要件定義プロジェクトに参画し、ビジネス構想、システム構想を伝達し確認しともに考える。また、業務変革の権限を業務部門に委譲するなどビジネス改革の強い意志を明確に示す必要がある。なお､経営層という表現は必ずしも社長や事業担当役員のみを意味するものではない。経営者の意を汲んだ企画担当スタッフなどが代替して参画することもケースによっては可能である。
経営層の参画とリーダーシップが成功のカギを握っている。
その２も、ちょっと変ですね。「業務部門中心での体制を作ったからといって」とありますが、「構想」が固まらない内に体制を作るのでしょうか？それに、業務部門（現場）が反旗を翻すのは「構想」に対してであり、当然「納得」が得られてから「体制」は整備されるべきだと考えます。
結論としてまとめると、「構想」が出された時にはしっかりとしたフィージビリティ検討を行い、その価値を認識したうえで、社内のコンセンサスを醸成し体制を組んでスタートするのが王道だと思います。
少々、重箱の隅をつつくような、また、揚げ足取りなことを書きましたが、実際に「一部の役員の暴走によるシステム開発とその失敗」とか「経営者の関与の低さによるプロジェクトの失敗」などの両方の失敗事例も世間には存在しています。経営層と言うときには、一人の人間を指すのか、組織としてのものを指すのか、経営のリーダーシップとは具体的にはどのような行動を指すのか・・・等考えておく必要があると思います。
大成建設のCIOとして大成建設のIT施策を統括された木内 里美氏のコラムを載せておきます。
ICTを学ばない経営者は職務放棄だ