IT調達プロセスにおける社内コミュニケーションの全体像

　社内コミュニケーションとは、自社のIT調達に関して利害関係（要望）を有する者たちの合意形成プロセスである。利害関係者とは、トップ、ミドル、担当および情報システム部門である。RFPは、それぞれの登場人物たちの合意形成プロセスの結果として作成されるものであり、決して情報システム部門の専管事項にあらず、ということを第1回で強調した。この合意形成プロセスの全体像は、次のように(1)調達プロセス、(2)登場人物、(3)合意内容の3組で整理できる。

　それぞれの立場の要望をRFPにまとめるにあたっては、特に下記の業務フローと業務要件とシステム要件が主たる合意内容となる。

(1)情報化企画フェーズにおける合意形成プロセス概要

　このフェーズの合意内容は、IT調達の必要性、費用対効果、達成目標などの目的価値に関する経営トップの意志である。この目的価値をどのような手法で可視化していくか？

　このテーマについては､書店に経営戦略手法の本があふれている。例えば「ハーバード・ビジネス・レビュー」誌（ダイヤモンド社）などが海外の知見を次々と紹介してくれる。それらの中で筆者は、「バランススコアカード（BSC）」と「強み弱み・順風逆風」（SWOT）分析を実践的に参考にしている。なぜかといえば、この手法は関係者参加による合意形成に向いているからである。具体的には、ポストイット紙などのカードを使って体を動かしながらワイワイ、ガヤガヤとブレーンストーミングを行い、カードを整理し、壁などを利用して合意内容をビジュアルに可視化できるのがよいと思う。

　バランススコアカード（BSC）について、筆者の理解を以下に示す。

組織の目的価値を次の4つの視線からバランスある指標として設定する。

(1)財務諸表の素晴らしさ

(2)顧客満足の向上

(3)業務フローの合理性

(4)社員の成長

この手法を適用するにあたっては、次のように2つの異なる考え方がある。

　A：(1)から(4)に向かって目的・手段展開として考える……トップダウンに近い

　B：(4)から(1)に向かって、原因・結果展開として考える……ボトムアップに近い

　筆者は、原因・結果展開としての考え方が好きである。(4)社員が成長して智恵を出して工夫すれば、(3)仕事の仕方に無駄や重複がなく効率的で、(3)仕事が合理的であれば顧客に提供する機能効果が向上して顧客満足を得て、(1)そうすれば利益もキャッシュフローも素晴らしい数字になる、という考え方である。

　次に「強み弱み・順風逆風」（SWOT）分析について、筆者の理解を以下に示す。

　普通は「機会・脅威」と呼ばれるが、直訳すぎるので筆者は「順風・逆風」という用語を好む。この手法でも関係者が参加して自己分析（強み・弱み）と環境分析（順風・逆風）をブレーンストーミングする。その結果を、強み・弱みと順風・逆風それぞれ3つくらいに可視化する。そして、強み・弱みと順風・逆風の2×2のマトリックスの組み合わせで4つの領域ができる。例えば、自己の強みが時代の順風追い風に乗れる事業領域は、強気でそれいけドンドンの業務改革を進め、IT投資も積極的に行うアクションプランとなるだろう。ほかの組み合わせそれぞれの領域についてもブレーンストーミングを行うことによって、業務改革の方向性と情報化の方針を定めることができる。

(2)業務改革＆RFP作成フェーズにおける合意形成プロセス概要

RFP作成手法にいまだ標準的なものはない。

　その最大の理由は、これまでは圧倒的にベンダー側の「システム開発方法論」しかなかったからである。ベンダー主導の「開発方法論」だけが我が物顔でシステム業界を席巻し、ユーザー視点の「調達方法論」が存在しなかった。「効率的なシステム作り技術論」偏重で、「効果的なシステム使い経営論」の不在である。

　確かに経営戦略や情報化企画では、経営コンサルタントなどが指導する豊富な手法と実践がある。しかしそこで作成され、トップも承認した企画書のレベルは、システム開発プロジェクトの実装仕様書としては、その精度があまりにかけ離れている。「要望」と「仕様」の間の大きな溝である。

　コンピュータは、言葉による情報処理はできない。言葉による情報処理機能は実装できない。厳密にデータ項目処理レベルで仕様を定義しなければ、SE、プログラマたちはプログラムを実装できない。コンピュータは、厳密に定義されたデータ処理しかできない。意味や価値を内包する情報処理は、コンピュータではできないのだ。人間同士が分かり合える言葉から、コンピュータ向けに厳密にデータ処理規則を析出させる必要がある。情報処理とデータ処理の記述様式と精度には、本質的な溝が存在する。

　その溝を埋める手法はベンダー側に求められてきた。それが、データフローダイヤグラム（DFD）であり、実体関連データモデル（ERD）であり、UMLなどのモデリング手法などである。政府がすすめるEA（エンタプライズアーキテクチャ）でもそうである。

　最近、ユーザー側が主体的にその溝を埋めるユーザー主導方法論といえば、その問題意識がようやく顕在化してきたという状況である。「IT調達」「RFP」という用語がその現象例である。筆者は、この潮流に加担すべく、ユーザー主導によるRFP作成手法としてライブスペックメソッド（LSM）を提唱している次第である。その概要を以下に記す。

ライブスペックメソッド（LSM）によるRFP作成手順概要

(1)準備

1.情報化企画書の存在を前提にユーザー主導プロジェクトを立ち上げる

2.対象業務に関連する利害関係者を決める（全員が兼務）

3.トップの経営方針と情報企画の達成目標などを紙や壁に張り出す

4.業務改革＆RFP作成プロジェクト実施計画書を作る（期間は6カ月前後）

(2)現状認識（可視化）と問題点抽出に関する合意形成

ユーザーそれぞれの仕事について現状3点セットを作成する

(A)職務環境図 (B)職務分掌（問題点・課題も含む） (C)業務フロー　

• 本業のかたわら、週に4時間前後、月に20時間前後、1カ月から2カ月で可能

(3)課題分析と解決方向に関する合意形成

1.ユーザーそれぞれが抽出した問題点と課題をすべて集めて課題一覧表に集約する

2.すべての課題を大分類、中分類、小分類に分類する

3.すべての課題を(A)すぐ対応する、(B)長期的に対応する、(C)検討対象外に分類する

4.すぐ対応する課題につき(A)業務改革で対応する、(B)IT活用で対応するに分類する

5.すぐ対応する課題につき、大分類単位で、解決方向、解決策を決める

6.それぞれの解決策の効果を定性的、定量的に可視化する

7.以上の作業をブレーンストーミング方式で実施しトップおよびミドルに報告する

(ブレーンストーミングの回数は、半日、3回前後)

(4)新業務設計に関する合意形成

1.解決方向を反映した新3点セットをトップダウンで作成する

(A)新職務環境図　(B)新職務分掌　(C)新業務フロー（新IT利用インタフェース）

2.ドキュメントだけでは決めにくい業務要件を業務シミュレーションで確認する

　・パッケージデモ、プロトタイピングツールによる機能実装など

3.入出力画面や帳票など業務要件RFPを編集作成する

(5)システム要件RFPの作成

この作業は、上記のユーザー主導と並行して、情報システム部門主導で行う。(RFPコンサルタントや外部のIT専門家の支援を受ける)

以上、RFPの目次構成については、第2回目に記述した。

LSMの3つの特徴

(1)要件定義をいつ行うか　→　ベンダーに発注する前に行う

(2)だれが書くか　→　SEではなくユーザー自身が書く

(3)プロトタイプの目的は　→　実装確認ではなく業務設計と業務要件確認のため

　（ITプロトタイピングではなく業務設計のための業務シミュレーションである）