なぜシステム構築の現場では同じようなトラブルが繰り返されるのか（後編）

「ビジネスゴールが不明確なままプロジェクトがスタートしてしまう」理由

　前編では、筆者のプロジェクト立て直しの2つのケースを挙げながら、トラブルプロジェクトの傾向についてみてきた。ここでは、その経験の中から、よく起きる現象とそこに横たわる本質的な問題について考えてみたい。

IT部門とITベンダーでとりあえず構想策定してしまう

　プロジェクトのステップの王道は、構想策定→要件定義→設計→開発→テスト→導入だ。プロジェクトに関わる人間は、このステップを当然のこととして踏みながら進行する。だが、粛々と手順を重ねながらも、「成果物は作っているものの、本当にこの要件は定義すべき要件なのか？」「要件があふれすぎ。なんのためのプロジェクトなんだか……」というもやもやとした思いが渦巻くことはないだろうか。

　この「もやもや」こそが、後半戦でのプロジェクト大爆発の予兆なのだが、原因は、前工程である構想策定でビジネスゴールが明確化されていない、そしてそれを再確認しながら要件定義を進められていないことにある。ではなぜビジネスゴールの設定がされないまま進行してしまうのか。

　大型システムプロジェクトは、大きく「IT部門主導型」と「ユーザー部門主導型」に分けられる。IT部門主導型の場合、多くはシステムの老朽化対策、ハードやソフトの保守期限切れ対応や事業継続計画（BCP）対策、といったことが目的で、ユーザー部門主導型の場合は、さらに「現行業務改善型」と「業務改革実行型」に分かれる。構想策定でビジネスゴールが不明確なまま走ってしまうのは、多くの場合、IT部門主導型と、ユーザー部門主導＆現行業務改善型のタイプだ。

　まず、IT部門主導型は、放っておくと「しかたなくやるもの」「インフラコスト」として扱われるため、ユーザー部門はそもそも興味を持たないし、経営からも「できるだけ手間もコストもかけずにやれ」と言われる。ユーザー部門主導&現行業務改善型も、全社視点で構想を立てられるキーマンの確保がままならないのが普通だ。

　現行業務に引きずられることなく、全社最適化の視点で新しいシステムのあり方を描けるレベルの事業部の人材（人財）は少ないうえに、いたとしても売れっ子だし自分の職務で忙しい。そもそも事業部門とIT部門は互いに距離があり、コラボレーションしようというモチベーションが低いという問題もある。

　何より、「それでも大事な仕事だからやってくれ」とトップマネジメントや役員が社内のキーマンを任命するほど、「システムプロジェクト」は社内で重要視されてもいない。

　人財がいないとなれば、外部の経験豊富なコンサルタントの力を借りたいと思うが、企画構想フェーズは実行稟議を通す前の段階なのでIT部門は予算がとれない。となると、ここで頼れるのは、自社商品やサービス営業を念頭においたITベンダーたちの提案だ。結果的に、IT部門の技術的視点とITベンダーの営業的提案を組み合わせて最初のフェーズの成果物、「基本構想」がなんとか作り上げられる。

　こうして、せっかくの時間と予算の投資をする機会にも関わらず、次世代の事業に資するビジネスゴールが一切議論されぬまま、要件定義フェーズにコマが進められていくのだ。これでは、本質的な要件定義ができるわけがない。