[ad#ad-link]

ユーザーもベンダーも同じベクトルを向いて取り組んだプロジェクトほど
素晴らしいことはありませんよね。
ステークホルダー全員が同じ目標に向かって取り組むわけですから、
認識のズレによる作業遅延など皆無。
おもしろいほど順調に作業が進んでいきます。
でも、そんなプロジェクトは現実的には非常に少ない気がします。

得てしてステークホルダー間の認識のギャップはつきもの。
特にユーザー側とベンダー側は、立場が違うので認識のギャップは
少なからず発生してしまいます。
その認識のギャップからプロジェクトが炎上する、なんてことも
少なからずあるわけで。。。

そこで今回はそんな認識のギャップを上げながら、どうすれば
「その認識のギャップを埋めて、プロジェクトをスムーズに
進めていけるのか？」という難題について考えてみたいと思います。

認識のギャップについては、「ユーザー側の言い分」もあれば、
「ベンダー側の言い分」もあります。
今回は、「ユーザー側の言い分」に焦点を当てて考えていきたいと
思います。

[toc]

ユーザー側の言い分

「ITの効果に満足したことがない」

ベンダーがどんなに素晴らしいシステムや製品を導入したとしても、
ユーザー側はその効果に満足することはありません。
実際に使い始めると、見えてこなかった部分が顕在化してきて
導入当初の満足感が薄れて、徐々に不満感が高まってきます。

また、使う人によって使いやすい尺度は違いますので、人によっては
以前のシステムのほうがよかったと思う人もいるでしょう。

さらにシステムの運用に関しても満足感よりも不満感が高まる要因が
潜んでいます。
システムの運用担当者は、導入当初は新しいシステムの使い方や
運用方法に手間取り、使用マニュアルや運用マニュアルの整備に
明け暮れます。

利用するユーザーも新しいシステムに戸惑い、ようやく使い慣れて
落ち着く頃には、すでにシステムが古くなり、市場にはもっと
使いやすいシステムが出てきて、使っているシステムが古臭く感じて
徐々に不満を感じてきます。

そのためようやくシステムがこなれてきた時期に上層部から
システムの更改を検討させられ、新しいシステムの検討が始まり、
検討後にシステムを導入すると、また新しいシステムと
格闘して・・・という負のスパイラルに陥ります。

ベンダーが心得ておくこと。

ベンダーは、ユーザーが思い描いているようなすべての課題を
解決するような夢のようなシステムが存在しないことを認識させよう。
大なり小なり、「トレードオフ」は存在するため、ユーザーの課題に
対して優先順位を付けて、本当に解決したい課題を優先的に
解決するようにしよう。

また、ベンダーは実際に使い、運用するのはユーザーであることを
認識し、むやみに最新機能を導入するのではなく、利用者や運用者に
やさしいシステムを導入することを認識しておこう。

ユーザーが心得ておくこと

すべてにおいて満足するシステムは存在しないことを認識しよう。
ベンダーの言いなりになるのではなく、何年も使い続けるシステムで
あることを認識し、プロジェクトの検討の段階から積極的に参加しよう。

「ビジネスに集中したい」

ユーザーはシステムや製品に興味があるのではありません。
そのシステムや製品を使うことで、本来のビジネスの効率化や、
成長がドライブすることを望んでいるのです。

どんなにベンダーがそのシステムや製品についてユーザーに
熱く語ったところで、ユーザーとしてはシステムや製品の特徴なんかに
興味はありません。
知りたいのはそのシステムや製品は我々のビジネスに良いインパクトを
与えてくれるのかどうかを知りたいのです。

ベンダーが心得ておくこと

ベンダーは製品の特徴を並び立てるのではなく、ユーザーが真に困っている
課題に対して、このシステムや製品を使えばどのように解決できるのか
について考え、提案しよう。

ユーザーが心得ておくこと

ユーザーはベンダーから提示される大げさな機能一覧に
惑わされることなく、「この提案は我々のビジネスをより良くするために
本当に必要なシステムなのか？」という点に注目し、その課題を
解決できるシステム導入に取り組もう。

「要求は変わって当たり前」

ユーザーはプロジェクトの途中で要求が変わるのは当たり前だと
考えています。
ビジネスの動向は日々変わるため、システムに導入したい機能の追加や
変更は当然のこと。
もちろんベンダーに期日までに仕上げてもらうのも当然の権利であると
考えています。

ユーザーの立場で考えてみれば至極当然のことで、高いシステムを
導入するのだから妥協はしたくないと考えるのは理解できます。
しかし、ベンダーにとっては、スケジュールや稼働人員は決まっていて、
これ以上の機能追加や変更を受け入れるということは、
収支が真っ赤っかになるか、さもなくばお決まりの炎上覚悟の
デスマーチを開始するかしかありません。

ベンダーが心得ておくこと

ベンダーはユーザーの言いなりになるのではなく、プロジェクトが
開始する前に、契約条件に追加や変更要件に関する事項を
盛り込んでおくこと。

さらに可能であれば、スケジュールのバッファをしっかりと
確保しておこう。
もし、大掛かりな仕様変更が発生した場合は、その仕様変更で
発生するリスクと追加費用が発生する旨をしっかりとした根拠と一緒に
ユーザーに説明し、期間の延長や追加費用の交渉をすること。

ユーザーが心得ておくこと

プロジェクトの進行途中、特に終了間際の仕様変更は
大きなリスクがあることを認識しよう。

途中で仕様が変わっても、ベンダーにお願いすればなんとかなるでしょ？
とか甘すぎる。
納期もリソースも厳しい中での成果物はたいていロクなものはなく、
多くのバグが潜んでいるものです。
[ad#ad-box-big]

ベンダー側の言い分

「必要な時に必要な情報を提供してくれない」

　プロジェクトが進むにつれて、当初は予想だにしなかった情報が
　舞い込んでくることがあります。
　当然認識していなかった情報ですので、仕様には盛り込んでいない。
　仕様に盛り込むためには、大幅な変更が必要になりあえなく炎上、
　なんてことが普通に起きることがあります。
　これは、ベンダーの立場で考えるとユーザーが必要な時に必要な情報を
　出してくれないからだと主張します。

　このようなことが起きてしまう理由は、ユーザーが社内の情報は
　当然熟知しすぎているからかもしてません。
　「知っていて当然」と思っているため、ベンダーも知っているはずで
　わざわざ説明するまでもないと考え、情報の提供を怠ってしまうためです。

ユーザーが心得ておくこと

　ユーザーは、プロジェクトに関連するものはもちろん、
　関連してそうな情報はとにかくすべてベンダーに提供しよう。
　ユーザーが情報の必要性の有無を取捨選択する必要はありません。
　それはベンダーに任せておこう。

ベンダーが心得ておくこと

　ユーザーからの提供される情報を決して鵜呑みにしないこと。
　表に出てこない情報が存在することを前提に、事前にあらゆる情報を
　ユーザーから引き出すことに全力を尽くそう。

「要求を明確にしたためしがない」

　プロジェクトは往々にして、スケジュールと予算が決まってしまえば
　モヤモヤした状態でスタートしてしまいます。
　本来であれば要求を明確にしてから、プロジェクトは走り出すのですが、
　そうではないプロジェクトが多いんです。多すぎる！

　それは、ユーザー自身が「何がしたいのか」が、明確にできていないため。
　人間というものは、何となくこうしたいなぁ〜という曖昧な状態でも、
　俺なら何とかなるかぁ！という間違いを犯しやすい生き物なのです。

　しかし、ベンダーにとってはゴールが曖昧のまま走りだすプロジェクトほど
　怖いものはありません。
　なんせプロジェクトの炎上が目に見えているのですから。

ユーザーが心得ておくこと

　決して曖昧な状態でプロジェクトをスタートさせないこと。
　待っているのは納期遅延と追加費用しかありません。
　プロジェクト開始前に何を実現したいのか、優先順位はどれで、
　必須要件は何か、目的やねらい、価値を洗い出し、必ず要求事項を
　要件事項に仕上げるようにしよう。

ベンダーが心得ておくこと

　曖昧なゴールを設定したプロジェクトは必ず炎上します。
　ユーザーから明確な要件が出てこない場合、出来る限りプロジェクトの
　スタートを送らせて、要件事項の明確化に力を注ごう。
　あるいは要求事項が決まっている部分や、追加/変更が
　起きにくい部分から作業を進めていき、随時要求を固めていけるように
　調整しよう。

「要件定義を丸投げしないでほしい」

　ユーザーによっては、要件定義でさえもベンダーに丸投げすることが
　あります。
　「ベンダーに金払ってるのだから、要件定義も当然ベンダーが
　考えるべきだ」とお考えのかたもまだまだ多いです。

　しかしこれはプロジェクト失敗の第一歩です。
　ベンダーはユーザーが解決したい課題をすべて解決していないですし、
　場合によってはベンダーの都合の良い要件定義になってしまい、
　ユーザーにとっては使いづらいことこの上ないシステムが
　出来上がってしまう場合もあります。

ユーザーが心得ておくこと

　要件定義は必ずユーザーが主体となってまとめること。
　面倒臭がっていてはいけません。
　納品されたシステムを使うのはユーザー自身です。
　ここでしっかりと要件定義をあとめておかないと困るのは
　自分自身であることを肝に命じましょう。

ベンダーが心得ておくこと

　もしユーザーが要件定義の作成を丸投げしてきたときは、
　要件定義の重要性を説明し、ユーザーに主体となってもらうように
　説得しよう。
　無理であっても、必ずユーザーを巻き込みながら要件定義を
　まとめていくように努力すること。

　決して、これ幸いとベンダーの都合の良い要件定義にしようとしないこと。
　短期的には得をしたとしても、長い目で見ると、会社のブランド価値低下や
　信用の低下を生み、長期的には大きな損失になることを認識すること。