プロジェクトにおける可視化（見える化）の必要性(1)

適切なIT化には，経営，現場，ITのバランスが必要

2007.04.12

　各企業は，金食い虫でとらえどころのないITをなんとか自身のコントロール下に抑え込んで，企業活動の中枢に組み込もうと奮闘している。こうしたITのガバナンスが効いていない典型として槍玉に上がっているのは，ベンダー主導によるIT化である。

　オープン系のシステムが普及して，技術分野が複雑かつ高度に発展するにつれて，各企業ともそれまでのように自前でそれぞれに新技術を追って，ベストのシステムを構築，運用するのは難しくなってきた。本業に注力して，それ以外をアウトソースする流れの中で，IT化の多くの業務をベンダーに任せてしまうようになった。今となってはRFPさえも書かない，あるいは書けない企業も多いと聞く。

　しかし，これを担うべきベンダーのビジネスモデルは，ユーザー企業の望むような役割に応えるものではない。できるだけリスクが少なく，売上のかさの大きいシステム開発だけをやっていきたい。結果として業務に立ち入ることを避けて，言われたことだけを確実にやるという役割に徹する。

　ユーザー企業が適切なところまでコントロールしなければ，システムありきのIT化が横行する。ベンダーは，業界標準やオープン性をうたいつつも，こてこてのシステム開発に持ち込み，いつの間にか他のベンダーが入り込めない状況を作り出してしまう。こうなるとベンダーロックイン状態で，保守・運用は競争抜きの商売になる。

　新規開発は競争が激しく，いくら値切っても手をあげるベンダーがいるおかげで，単独では商売になりにくくなっている。体力のあるベンダーは，そこの採算を度外視してでも，保守，運用でリベンジするという戦略をとる。

　悪気はなくても，今の情報サービス産業のビジネス構造で素直に利益を追求すると，そういう動きにならざるをえない。ユーザー企業からすると，言葉は悪いが，ベンダーにいいようにやられてしまったという被害者意識が残る。

　しかし，痛い目に会ったからといって，いまさら自前でプログラムを書くところまで戻るというのも現実的ではない。餅は餅屋であり，今となっては素人が手を出すべきでないところも多い。コントロールを取り戻さなければならないのは確かだが，どこまでを手元に引き戻し，どこからは任せるべきなのか，企業の悩みは深い。

　ユーザー企業が主導的に進める場合，経営からのトップダウンで，主体としては，経営企画や改革推進，情報システム部門などが進めるタイプのプロジェクトと，現場，エンドユーザーが主導となるボトムアップのタイプのプロジェクトがある。

　前者の場合，全社的なプロジェクトとしてぶち上げられ，予算も大きくとられることが多い。そこで陥りがちなのは，全体最適の名のもとに現場置き去りでことが進み，後になって現場から総すかんを食うというパターンである。

　普段からギリギリでやっている現場は，慣れ親しんだ仕事のやり方を変えることや，新たにデータ入力作業で余計な手間が増えることには当然ながら前向きにはなれない。特に，日本の製造業などは，現場の力が非常に強く，自らの改善能力にもプライドをもっている。最終的に現場が抵抗すると，使われないシステムになってしまう。

　一方，現場主導でやらせてしまうと，全体最適という観点に乏しく，多少手が楽になる程度のシステムで終わってしまうことがある。また，一般に現場はITの最新情報にも疎く，その力を十分に引き出せず，短命なシステムにしてしまいがちだ。その時々の旬の技術や場当たり的なアーキテクチャの採用など，一貫性の欠如からトータルの保守コストが増大する懸念もある。

　こうしたことからわかるように，いずれの立場に偏っても適切なIT化は図れない。経営サイドからの全体最適の視点，現場業務の視点，IT専門家の技術の視点がバランスよく維持されなければ，投資効果の高いシステムの導入には至らないのである。

全体を見渡す地図が必要だ

　それでは，立場の違う視点を持つメンバーがどのように役割分担をすれば，バランスの取れたIT化が行えるのだろうか。

　それを決めるためには，IT化を進めていく過程において，そもそもどのような作業や検討を行っているのか，行うべきなのかを棚卸しすることが必要である。これらが明らかになって初めて，個々のアクティビティは誰がやるべきかの議論をすることができる。

　活動の内容が不明確なまま，「企画は経営企画・情報システム部，作るのはベンダー，使わせるのは現場」といった大ざっぱな切り分けでは，それぞれが押し付けあう真ん中の部分で大落球してしまうことになる。

　しかし，今まで述べてきたように，多くの企業では，要求開発にあたるところは試行錯誤で進めているのが実情で，適正な粒度での作業に落とされていない。Openthologyは，その標準的なアクティビティを定義したベースラインとして，こうしたところで大変お役に立てるはずである。

　プロジェクトが失敗する原因は，「決めるべきときに決めるべき人が決めるべきことを決めていない」ことだというのは，同僚である要求開発アライアンス理事の安井昌男氏の言葉である。まさに至言だと思うが，であれば，「いつ，誰が，何をもとに，何を決定すればいいのか」を決めておくことが肝要だ。また，それぞれの決定の根拠が明確にされることや，その決定が次の決定にどのようにロジカルに連鎖していくのかのシナリオがバックボーンとして必要である。

　大掛かりなプロジェクトは，立場の違う利害関係者が多数かかわるので，その調整は困難を極める。「各立場のキーマンをプロジェクトに巻き込め」とはよく言われることであるが，キーマンとよばれる人ほど，時間的に余裕はない。ものが決まらない会議に毎度毎度，巻き込まれているわけにはいかない。

　キーマンに参画してほしければ，プロセスの全体を見せた上で，いつ，どこの決定にかかわってほしいのかを明確にして，そのときまでに判断に必要な情報を整理した形で提供できるようにしておかなければならない。参加する意義が明らかであり，その決定がどのように反映されるのかが明確になっていれば，いかに忙しいといっても，キーマンと冠される立場にあるならば，そのときぐらいは対応せざるを得ないはずだ。

　現場のユーザーへのヒアリングもそうだ。位置付けがあいまいなままに，「とりあえず出てくれ」といっても協力は得がたい。準備不十分なまま，時間をとらせて，その結果がうまくまとめられず，再度仕切り直しとなると次は厳しくなる。同じような質問の繰返しに，ユーザーもいい加減うんざりしているのである。

　まず，推進側が仮説的であっても自分たちとしての全体のモデルを作ったうえで，要点を絞った聞き方をするべきである。さらには，事前に「プロジェクト全体の流れがどうなっていて，ここでの結果がどう使われるのか」その意義を正しく伝えておかなければならない。要求決定までの全工程とその中でのポジションを事前に示しておくことが，関係者を巻き込む手立てなのである。

プロジェクトの成功とは

　キーマンに限らず，多数の利害関係者の合意を得ることは，プロジェクトの成功のための必須条件である。「システム開発」という「決められたものを作る」という範囲に限定すれば，要件定義書にあるシステムをQCD（Quality，Cost，Delivery）を守って作りあげられればプロジェクトは成功といえるだろう。

　その基準でみると，成功率は4分の1ぐらいと言われているので，「システム開発」だけでも容易ではない。ただ，QCDという成功の指標は明確である。しかし，すでにご存じのように，企業はシステムを作りたくて作っているわけではない。

　「システム開発」は成功して，予定通り稼働したとしても，本来のビジネス上の目的が果たせていなければ，企業としてのプロジェクトは成功とはいえない。そのための指標として，最近は，どの企業でもプロジェクトの実施に先立って，ROI（Return On Investment）を算定するというのが一般的になっている。

　しかし，ROIのような指標を導入して，投資効果を少しでも目に見えるようにしようとする努力は重要だが，実際のところ，それが期待ほどの客観性や精度を備えた指標として機能しているかというとはなはだ疑わしい。投資（Investment）は，かかった直接費用や工数が主なので，比較的算出しやすいが，その効果であるReturnとなると，評価手法は決め手に欠ける。

　例えば社内ポータルなどは，その導入効果をどのように測ればいいだろう。社内の情報を即座にアクセスし，共有できることのメリットは，定性的には理解できる。しかし，直接の金銭的価値に変わるわけではないので，定量化しようとすると，間接的に引き起こされた様々な派生効果を様々な仮説の元に算定することになる。鉛筆のなめ方によっては，桁が容易に変わってしまい，「風が吹けば桶屋がもうかる」的な理屈で決裁が通っていくことになる。

　そこで，筆者はプロジェクトメーキング（Openthologyの準備フェーズ）の段階で，要求分析ツリー（図1）などを使って，今回のプロジェクトと因果関係の明確なKPI（Key Performance Indicator）を導き出し，それをゴール記述（図2）としてプロジェクトの成功指標にすることをお薦めしている（これについては，別途機会を作って詳しく説明したい）。