• スペシャル
  • 2015/12/10 掲載

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

  • icon-mail
  • icon-print
  • icon-hatena
  • icon-line
  • icon-close-snsbtns
会員になると、いいね!でマイページに保存できます。
部門単体システムが全盛の頃は、情報システム部(情シス)がシステムのあり方を考えるのが当たり前でした。しかし、今はビジネスが多様化・複雑化し、それに伴いシステムが複雑化・大規模化しています。情シスの知見だけでは、経営や業務のしくみを適切に反映したシステムをつくれません。では、どうすればよいのか? システムのあり方・構想づくりが、うまくいかない3つの原因を明らかにして、プロジェクトが成功するための方法を説明します。
photo
なぜ、情シスがシステムのあり方を決めようとするとプロジェクトは失敗するのか?

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

【次ページ】システム構想を「経営の単独プロジェクト」に切り離せ
関連タグ タグをフォローすると最新情報が表示されます

    PR

    PR

    PR

処理に失敗しました

人気のタグ

投稿したコメントを
削除しますか?

あなたの投稿コメント編集

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

通報

このコメントについて、
問題の詳細をお知らせください。

ビジネス+ITルール違反についてはこちらをご覧ください。

通報

報告が完了しました

コメントを投稿することにより自身の基本情報
本メディアサイトに公開されます

必要な会員情報が不足しています。

必要な会員情報をすべてご登録いただくまでは、以下のサービスがご利用いただけません。

  • 記事閲覧数の制限なし

  • [お気に入り]ボタンでの記事取り置き

  • タグフォロー

  • おすすめコンテンツの表示

詳細情報を入力して
会員限定機能を使いこなしましょう!

詳細はこちら 詳細情報の入力へ進む
報告が完了しました

」さんのブロックを解除しますか?

ブロックを解除するとお互いにフォローすることができるようになります。

ブロック

さんはあなたをフォローしたりあなたのコメントにいいねできなくなります。また、さんからの通知は表示されなくなります。

さんをブロックしますか?

ブロック

ブロックが完了しました

ブロック解除

ブロック解除が完了しました

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

ユーザーをフォローすることにより自身の基本情報
お相手に公開されます