前回、システム化を構想・企画するときに、最低限の認識が必要ではないかということで、“要求”に関して認識を一致することを提案した。ただし、最終的に抜けのない、きちんとした企画書を作るためには、構想・企画フェーズのプロセスや技法、成果物が決まっていることが望ましい。

　しかし、現状はそうなっていない。情報システム部門の年度計画の時点で記述されている大まかな情報システムの構想書から、事業部門およびシステム部門の担当者が中心になって、できる範囲で提案依頼書（RFP）を作成する。そして、RFPに基づいて提案を提出してくれたベンダーの中から、最も良いと思われる開発提案を選び、選んだベンダーと一緒にシステム開発を行うことが一般的な進め方である。

　このような進め方で、本当にビジネスに役に立つ情報システムを構築することができるのだろうか。構想・企画のフェーズにおいて、各担当者の進め方に任せてしまうと、どうしても投資対効果の視点が薄れてしまったり、コスト、時間の制約で十分な検討を行えず、ベンダーの提案を丸呑みしてしまったりすることになってしまう。これでは、本来構想・企画フェーズで実現するべき以下の目的を達成できない。

＜構想・企画フェーズの目的＞
（1）企画する情報システムの投資対効果を明確にする。
（2）企画した情報システムの実現可能性（計画通り開発することができるか）を検証する。
（3）スポンサーを含む関係者の合意を得て、企画の承認を得る。

　構想・企画フェーズの進め方を個人に任せたり、場当たり的に決めているようでは、目的を達成できない。では、構想・企画フェーズをどのように進めたらいいのだろうか。ビジネスに貢献する情報システムを作るという観点で、目的や狙いから順次決めていくことが正しい。

　同業他社が導入しているから、あるいは導入コストが安いからという理由で、ERPなどのパッケージソフトウエアを前提に企画することは、目的を深く考えるより、手段が先行してしまっている。そのような進め方をすると導入プロジェクトで問題が発生したときに、原点となる目的・狙いがはっきりしていないため、的確に意思決定ができず、プロジェクトが混乱する。

　そこで、どのような目的ために（Why）、どのような業務・システムを（What）、どのように実現するか（How）、という順序で構想・企画フェーズを進めるべきだと考えている。構想・企画フェーズのプロセスの例を、図1に示す。このプロセスは標準的なIT方法論や弊社の経験に基づき、整理したものである。

図1●構想・企画フェーズのプロセス

[画像のクリックで拡大表示]

　このプロセスは（1）要求の取りまとめ（Why）、（2）業務・システムの概要定義（What）、（3）実現シナリオの策定（How）の3段階に大きく分かれており、各段階での作業概要は以下の通りである。

（1）要求の取りまとめ（Why）
　ビジネス上のニーズ、課題をトップダウン視点で引き出すと共に、ボトムアップの視点で現状の問題、課題を収集し、要求としてまとめる。そして要求を実現するためのソリューションと結果として実現される効果を想定して、想定される投資対効果から、企画作業を深堀りすることを決定する。

（2）業務・システムの概要定義（What）
　想定されるソリューションの中でも主にITの施策に関するスコープを決定する。情報システムとして実現する対象業務、機能、及び運用時の業務イメージ、ITアーキテクチャー、移行などについて検討する。

（3）実現シナリオの策定（How）
　（2）で決定されたスコープを対象とする情報システムを構築するための、実現シナリオ（スケジュール、体制、コスト、開発方法など）を決定した上で、最終的な投資対効果を算出して企画書としてまとめる。企画書は関係者の合意を得た上で、最終的にスポンサーの承認を得る。

能登原 伸二（のとはら しんじ）
アイ・ティ・イノベーション 取締役 兼 専務執行役員

株式会社ジャパンエナジー（現 JX日鉱日石エネルギー株式会社）の情報システム部門において、長年、情報システムの企画、開発、運用までの幅広い業務に携わり、ITによる業務改革、収益向上を支援してきた。現在は、プロジェクト管理標準導入、PMOの運営、及びITプロジェクトにおけるプロジェクト管理支援コンサルティングを幅広く手がける。日経SYSTEMSにおいて「のとはら先生」シリーズを連載し、大好評につき「プロジェクトマネジメント現場マニュアル」を出版。PMP。名古屋工業大学 非常勤講師。