ビジネス+IT

ビジネス課題別で探す

ITジャンル別で探す

IT導入支援

公認会計士中川充事務所提供コンテンツ

2015年12月10日

システム開発は要件定義前の“構想”で決まる! 経営者が知っておくべき3つのポイント

部門単体システムが全盛の頃は、情報システム部(情シス)がシステムのあり方を考えるのが当たり前でした。しかし、今はビジネスが多様化・複雑化し、それに伴いシステムが複雑化・大規模化しています。情シスの知見だけでは、経営や業務のしくみを適切に反映したシステムをつくれません。では、どうすればよいのか? システムのあり方・構想づくりが、うまくいかない3つの原因を明らかにして、プロジェクトが成功するための方法を説明します。

執筆:公認会計士中川充事務所 代表 中川 充

photo

なぜ、情シスがシステムのあり方を決めようとするとプロジェクトは失敗するのか?

繰り返されるシステム開発の失敗

 66億円――。これは、上場会社の2年間の有価証券報告書、適時開示を検索して、「システム開発中止」と判断したことで被った損失額を筆者が算定した結果です。表に出てこないもの、不具合がありながら使用しているものを含めれば、おそらく金額はこの何倍にもなるでしょう。たった2年で、少し調べただけでこんなにあるのですから、日本全体でいったいいくらのお金がシステム開発によってドブに捨てられてきたのでしょうか? 考えただけでも背筋が凍ります。

 もちろん、企業もお金を捨てたくて捨てているわけではありません。経営や業務に役立つシステムをつくろうと真剣に取り組んでいます。それなのにドブ捨て現象はいまだ後を絶ちません。

 よく、「システム開発を成功させるには、要件定義をうまくすることが大事だ」と言われます。要件定義は、「この画面でこれができるようにしてほしい」「これとこれを集計して印刷したい」など、ユーザーのきめ細かな個別の要求をかなえる、重要なプロセスなのはまちがいありません。しかし、システム構想や業務改革のように、大胆に業務や組織のしくみを変え、新しいことや斬新なアイデアを考えだすところではありません。

 もし、要件定義でそのレベルの議論を始めてしまえば、収拾がつかなくなります。たとえれば、それは新婚夫婦が建設途中の新築マンションを購入してから「やっぱり戸建てがいい」と言いだしたり、2階建ての戸建ての基礎部分ができたあとに「2世帯で住むことになったから、悪いけど3階建てにしてよ」と注文したりするようなことなのです。

システム開発を成功させるカギとは何か

 事前に決めておくべきことが決められていない、ダメな構想の下では、いくら要件をしっかり定義したところで意味がないのです。システム開発を成功させるカギは“システム構想”にあります。

 実際、筆者がシステム実務者に「システム構想をどう思うか」アンケートをとったところ、システム構想を「とても重要」と回答した人が9割、「まあまあ重要」と回答した人が1割でした。回答者全員がシステム構想を重要だと答えています。

なぜ、システム構想がうまくいかないのか?

 システム構想が重要なことは、ユーザー企業もベンダーもわかっています。でも、うまくいかないのです。それはなぜか。原因は大きく次の3つです。

原因1:経営層と業務部門が主体的に参加してくれない
システム構想は、言ってしまえばシステムのデザインではなく、ビジネスそのもののデザインです。経営層と業務部門の主体的な参加が欠かせません。しかし、往々にして、経営層と業務部門のスタンスは次のようなものです。「自分たち(経営層と業務部門)は全面的に協力する。会議に出席して意見も言う。

でも、システムのことだから、情報システム部が責任を持って考えるのが当然だろう」 経営層と業務部門には、「システム開発は、情報システム部の仕事」という強い固定概念があります。どうしても当事者意識が低いのです。


原因2:十分な予算と期間が取れていない
構想づくりは難しく、時間がかかります。それなのに、システム構想はシステム開発の単なる「前座」のような扱いです。システム開発の期間が足りないと、犠牲になるのはいつもシステム構想です。多くの場合、システム構想に十分な予算や期間が確保できていません。

筆者がシステム実務者を対象におこなったアンケートによると、「システム構想にどれくらい期間をかけるべきか」との質問に、「6カ月以上」と回答した人が3割、「3カ月程度」が5割、「1カ月程度」が2割でした。 企業システムに理解がある人たちでも、70%が3カ月以下と答えています。これが、今のシステム業界やユーザー企業の現実です。構想づくりに大胆に予算や期間をかける文化が定着していないのです。


原因3:プロジェクトの体制がシステムに片寄っている
ビジネスが多様化・複雑化したことで、システムは複雑化・大規模化しています。全社一丸となり、最高の布陣でのぞんで、やっとシステムや業務の変革がうまくいくのです。

にもかかわらず、プロジェクトの多くはそれにふさわしい体制になっていません。従来のシステム開発体制と同じです。責任者は情報システム担当役員(CIO)、リーダーとメンバーの大半は情報システム部員です。 誤解してほしくないのですが、決してシステム部中心の体制がダメだと言っているわけではありません。しかし、情報システム部が戦略部門ではなく保守サービス部門のままなら、正直なところその責は重すぎます。

 このような事態を防ぎ、優れたシステム構想をつくるためには、どうしたらいいのでしょうか? それは、システム開発プロジェクトから「システム構想」を完全に切り離すこと。つまり、システム構想を経営の単独プロジェクトにするのです。

【次ページ】システム構想を「経営の単独プロジェクト」に切り離せ

見える化・意思決定 ジャンルのトピックス

一覧へ

見える化・意思決定 ジャンルのIT導入支援情報

一覧へ

PR

注目のIT導入支援情報

一覧へ

注目のイベント・セミナー情報

一覧へ

イベント・セミナー情報の登録(無料)

記事アクセスランキング

イベント・セミナー情報アクセスランキング