プロジェクト失敗の理由、15年前から変わらず

まず業務の構造を整理する

　有効な対策はある。各業務部門の担当者が企業の内外にある業務の構造を整理し、全体の構造を頭に入れてから要件を話し合うことだ。各業務がそれぞれどういう関係にあるのか、各業務でどのような情報が必要なのか、そうしたことが整理されると、業務改革の案がおのずと出てくる。「業務をこう変えよう、そのためにはこういう情報がほしい」という話に進み、システムの要件がまとまってくる。

　全体の構造を整理し、把握しておかないと、各業務部門の担当者が自部門の要求だけを出すことになる。ばらばらの要求を並べただけではシステムの要件定義にならない。そもそも「情報システムを作るから要件を定義せよ」といきなり言われても各業務部門はなかなか答えられない。

　2018年の調査結果を見るとプロジェクトの成功率が低い傾向にあるシステムの分野は「CRM（顧客関係管理）・SFA（営業支援）」と「SCM（サプライチェーン管理）・生産管理・物流管理」であった。後者は複数の業務部門さらには協力会社などが関わるため、全体構造を把握していないと要件を決めづらい。

　一方、前者のCRM・SFAは顧客対応部門や営業部門といった特定部門が使うシステムだが、どちらの部門も多忙であり、要件を決めにくい。やむを得ず、情報システム部門が要件を仮置きして開発を進めると、出来上がってきたシステムを使った途端、現場は「使えない」「入力が面倒だ」などと反発し、要件定義のやり直しや追加開発が発生する。

　CRM・SFAについては「例えばこういうシステムはどうか」と現場に試作品を早めに見せ、意見を求めるやり方がよいとされている。その場合でも、業務の全体構造が整理されていれば「この情報とあの情報を組み合わせると顧客対応や営業活動に役立つのではないか」といった仮説が見えてくるので、より的確な試作品を提示できる。

　「各業務部門の担当者が企業の内外にある業務の構造を整理し、全体の構造を頭に入れてから要件を話し合う」手法は色々あり、日本生まれで実績を上げているものもある。ただし、なかなか普及しない。

　効果が出る手法であっても、業務知識を持つ社員を集め、全体構造を整理、記述していくと聞かされた途端、業務部門は及び腰になるからだ。「業務を説明するから情報システム部門が要件をまとめてくれ」という姿勢の現場部門が多い企業はせっかくの手法を活かせない。

システムに不満を持つ経営者や業務部門がすべきこと

　紹介した3回分の調査において、導入した情報システムの品質や満足度を情報システム部門が主に評価している。本来であれば、経営者や業務部門の声を聞くべきだが、調査の都合上、情報システム部門に代理で回答してもらっている格好だ。

　したがって情報システム部門が「成功」と見なしたプロジェクトを経営者や業務部門が「とんでもない」と批判することが有り得る。仮にそうであるなら、経営者や業務部門は「企業の内外にある業務の構造を整理し」それを「頭に入れてから要件を話し合う」活動にぜひ取り組んでほしい。

　情報システムは業務改革を支えるものだから、業務に責任を持つ人がプロジェクトに参画して要件を取りまとめ、プロジェクトの進行を見守ることが欠かせない。情報システム部門ましてやIT企業に任せきりにする企業はプロジェクトを成功できない。