前回、「動かないコンピュータ」の話に触れましたが、雑誌「日経コンピュータ」の2012年8月16日号の読者アンケートに面白い結果が載っていました。アンケート回答者96人中71人の方が、「動かないコンピュータ」に陥る原因として「仕様が固まらない、曖昧」を挙げていることです。このアンケートにおける動かないコンピュータの定義ははっきりしませんが、動かないコンピュータをプロジェクトの費用や期間の予算超過と考えれば、この回答数は十分にありえそうな値です。

　しかし、よく考えるとこの回答は少しピントがずれています。仕様が固まらないからプロジェクトがうまく進まないということですが、企業の基幹業務システムの仕様はそんなに簡単に固まるものではありません。システム開発プロジェクトにかかわった経験者であれば、次のような状況に遭遇したことがあるのではないかと思います。本番直前になっても仕様が固まらないというのはよくあることです。

  • 利用者から「設計書を見るだけではシステムイメージを把握することなどできない」といわれた
  • 利用者が属人的に処理してきたことや手作業、メモ作業は業務ヒアリング時に話に出ないで隠されることが多い
  • テストをしてみてはじめて不足しているデータやマスター情報が分かることがある
  • 経営管理用の集計分類は実際に管理する人が集計画面を見てから追加要求が頻発する
  • ロジックは設計段階では勘違いしているケースもあり、動かして検証しないと正確に動くかどうか分からない
  • 利用者が前からやりたかった追加機能ほど最後になっておそるおそる出てくることが多い
  • 最終段階になってはじめて利用者から当然あるべきと思っていた機能が抜けていたと指摘されることがある
  • せっかくシステムができたと思ったら、監査法人からダメだしをされた

　企業の現場業務をサポートする基幹業務システム開発においては、いくら設計段階で緻密に仕様固めを行ったとしても、利用者の要望を100％取り入れることはできません。業務を熟知している人が設計段階でシステム開発に関与さえすれば仕様を確定できるといわれることがありますが、それも現実的にはあり得ません。

　日本の企業経営の世界では、業務内容を知っている人と実際に業務処理を行う人は異なります。そのため、日本のシステム開発ではいくら業務を知っている人が設計にからんだとしても、それで十分ということはありません。テスト段階もしくは本番後、業務処理を行う人が実際にシステムに触りはじめたときに、今までの打ち合わせ内容が覆され、このままでは使えないといった意見が出てくることもよくあります。

　欧米のように経営者に直接雇われたプロジェクトマネジャーがシステム開発を仕切っている場合は、現場による追加仕様要求の発生を無理やり押さえ込むことも可能です。しかし、日本のシステム開発の場合は、プロジェクトマネジャーは顧客側ではなく請負業者側にいることが多く、プロジェクトマネジャーの判断だけで現場の要求を押さえ込むことは困難です。

　また、日本企業では米国の企業経営者のように当事者としてシステム開発にかかわる経営者もほとんどいません。CIOといっても名ばかりの存在も多く、システム仕様決定においては現場業務に精通した従業員の意見が最も重視されます。

この先は日経クロステック Active会員の登録が必要です

日経クロステック Activeは、IT／製造／建設各分野にかかわる企業向け製品・サービスについて、選択や導入を支援する情報サイトです。製品・サービス情報、導入事例などのコンテンツを多数掲載しています。初めてご覧になる際には、会員登録（無料）をお願いいたします。