1.ユーザーとベンダーの立場の違いと役割責任の分担を
明確に認識しているか

ユーザーとベンダーの立場の違いをはっきりと意識しよう

　ITベンダー（供給側）にとって、IT供給はビジネスそのものである。ITユーザー（調達側）が支払う費用が、供給側の売上となる。しかしIT調達側は、ITを活用することによって本業で効果を発揮して、調達費用を回収しなければならない。その費用を回収できるほどの効果を発揮できないIT調達は失敗なのだ。

　供給側が提供するものはITシステムであって、調達側の求める「効果」そのものではない。供給側の責任は、ITシステムという構造物を提供することで終わる。調達側にこそ、その構造物を「活用」して、業務機能を発揮させ効果を達成する責任があるのだということを強く意識しよう。

　ベンダーが構造物を構築するという「作る」難しさは、技術的な難しさである。それに対して、提供された構造物の業務機能を発揮させるとは、例えば「利益率を2割アップする」、「キャッシュフローを改善する」、「在庫を半減する」などだが、ユーザーがこれらの機能を実現させる「IT活用」の難しさは、すなわち経営的な難しさになる。この違いもしっかりと認識しよう。同じシステムでもユーザーの使い方によって効果は違うのだから。

　ユーザーにとって「ITは難しい、ITは分からない」。だから「ITのことは専門家に任せ、ベンダーから企画提案をもらって判断するしかない」というユーザーも多い。これは、「作る」技術的難しさと「使いこなす」経営的難しさを混同した結果、ユーザーの果たすべき発注者責任までも、ベンダーに丸投げしているということではないだろうか。

2.IT調達プロセスは標準化されているか

調達者の責任としてRFPの位置付けと役割をしっかりと理解しよう

　ユーザーが、効果を発揮するであろうと想定するITシステムとは、どんなものなのかを、誰がどうやって決めればよいのか。ベンダーは、何に基づき見積もり提案をし、何を約束して、何に対して責任を持ち、システム構造物を提供するのか。

　これらが、提案依頼、発注仕様、要件定義、要求開発、要求仕様などと呼ばれる問題領域である。ここではこれらの言葉を全部ひっくるめて「RFP」と呼ぶことにする。そしてRFPをきちんと作成して、それに基づいてITシステムを導入し、運用・保守を通してIT活用効果を評価することになる。この一連の次のようなプロセスを「IT調達管理プロセス」と呼ぶ。

IT調達管理プロセスの不具合・未成熟がIT調達の失敗をもたらす

　IT調達の失敗とは、大きく分けて次の2つの意味がある。

• 納期が守れず、予算はオーバーし、品質が悪く、積み残しが続出する

これは上の「? 調達実施フェーズの失敗」。その責任はベンダーが負うべきでシステム開発プロジェクトの失敗といえる。しかし、プロジェクトが失敗する原因の40％は、あいまいな要件定義、要件の手戻りにあるといわれているので、それは「? 業務改革＆RFP作成フェーズ」に本来の原因があることになる。

• 調達したITシステムが、使われない、役に立たない、効果を発揮していない

これは、「? 企画構想フェーズ」と「? 業務改革・RFP作成フェーズ」および「? 運用フェーズ」に原因がある。効果を発揮するであろうと想定するITシステムとは、どんなものなのかを、明確にしないままベンダーに発注しまうこと、つまり明確なRFPの不在が、IT調達失敗の根本原因なのだ。

3.IT調達プロセスを標準化マニュアルに沿って管理しているか

業務改革を伴うIT調達ではトップ、ミドル、現場で知恵を出す

　ITを使って業務効率を上げたい、業績効果を上げたいという経営要求のためのRFPは短期間に単純に決まるものではない。１経営戦略、2組織設計、3業務設計・業務フローなどの業務改革を伴うからである。では業務改革をどのように進めるのか。

　ベンダー主導の要件定義手法としては、いろいろある。EA：エンタプライズアーキテクチャ（業務・システム最適化計画）やオブジェクト指向をベースにした業務の抽象化・モデリング思考やドキュメントツールが花盛りである。これらの手法は、対象業務を可視化・見える化・文書化・抽象化・モデリングすることをおおいに強調している。しかしモデリング手法自体が、可視化された業務の問題点や価値や全体最適性を評価できるわけではないのだ。業務の仕組みが、経営目標を効果的に実現できるかどうか、そもそもの価値を評価できるのは、実際にITを活用するユーザーであるという当たり前のことが、もっともっと重視されてしかるべきではないのか。

　ユーザーといっても現場担当者だけには限らない。トップ経営者もミドル管理職もITユーザーである。情報活用能力という面から見れば、トップとミドルこそが主要なユーザーであるべきなのだ。ベンダーから見えるユーザーの情報システム部門だけがユーザーであるわけではない。

• 「調達したITシステムが、効果を発揮していない、役に立たない、トップが評価しない」という調達失敗を避けるには、トップとミドルが知恵を出すべきである。
• 「納期が守れず、予算はオーバーし、品質が悪く、積み残し仕様が続出する」失敗プロジェクトを避けるには、情報システム部門が知恵を出すべきである。

業務改革＆RFP作成はベンダーへ発注前の「細く長く」がポイント

　トップ、ミドル、現場は、それぞれの忙しい本業を持っている。本業のかたわら、業務改革＆RFP作成に参加しなければならない。専念して時間を割くわけにはいかないのだ。トップ、ミドル、現場、情報システム部門それぞれに矛盾する立場の要件をすり合わせ、合意を形成していくには一定の時間がかかる。だから細く長く時間をかけて進める必要がある。少なくとも半年ぐらいは必要だろう。

　この作業を、ベンダーに発注してから専任者を決め、決められた要件定義工程の期限内に行うとすれば、失敗するのは目に見えている。現に「時間がない」という理由による工程進捗の見切り発車が、必ずといってよいほど発生しているではないか。ベンダーは、システムを作る立場から、入出力画面や帳票のユーザーインタフェイス、データモデル、データ処理ルール等の業務要件に最大の関心がある。だから「早く決めてください、早く仕様凍結をしてください」と懇願するか、「納期に間に合いませんよ」と脅かすしかないのである。

業務要件の実現性やITコスト削減の視点からのシステム要件定義

　IT調達のRFPは、業務要件だけを記述すればよいわけではない。既存システムとのデータ連動や現行システムからの移行要件や、他の既存システム全体との整合性やシステム運用保守担当者の立場からの要件なども忘れてはいけない。また、何よりも各ユーザーからのばらばらな要件や、実現が無理な要件や、コストがかかりすぎる要件など、実装者の視点からの業務要件の検証も重要だ。ここに情報システム担当者の出番がある。もし情報システム部門がなければ、ベンダーから独立したIT経験者であるITコーディネータやRFPコンサルタントが登場する。

　以上のようにIT調達プロセスは、さまざまな立場の登場人物たちによる合意形成プロセスであることをしっかりと認識しよう。けっしてIT専門家たちに任せて済むことではないのだ。そのためには、IT調達プロセスが、標準化マニュアルに沿って、誰が、いつ、何をすべきかが、きちんと管理されなければならない。

4.IT調達管理能力成熟度モデルにより自己評価をしよう

　IT調達管理プロセスに関与するユーザーの調達能力成熟度モデルを次のように作ってみた。ユーザー企業ITマネージャとして、自社の成熟度モデルにカスタマイズして自社のIT調達能力レベルを評価してみてほしい。