ユーザーとベンダーの認識のギャップ

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

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

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

ユーザー側の言い分

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

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

利用するユーザーも新しいシステムに戸惑い、ようやく使い慣れて落ち着く頃には、すでにシステムが古くなり、市場にはもっと使いやすいシステムが出てきて、使っているシステムが古臭く感じて徐々に不満を感じてきます。そのためようやくシステムがこなれてきた時期に上層部からシステムの更改を検討させられ、新しいシステムの検討が始まり、検討後にシステムを導入すると、また新しいシステムと格闘して・・・という負のスパイラルに陥ります。

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

ベンダーは、ユーザーが思い描いているようなすべての課題を解決するような夢のようなシステムが存在しないことを認識させましょう。大なり小なり、「トレードオフ」は存在するため、ユーザーの課題に対して優先順位を付けて、本当に解決したい課題を優先的に解決するようにしましょう。また、ベンダーは実際に使い、運用するのはユーザーであることを認識し、むやみに最新機能を導入するのではなく、利用者や運用者にやさしいシステムを導入することを認識しておこう。

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

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

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

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

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

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

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

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

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

ユーザーはプロジェクトの途中で要求が変わるのは当たり前だと考えています。ビジネスの動向は日々変わるため、システムに導入したい機能の追加や変更は当然のこと。もちろんベンダーに期日までに仕上げてもらうのも当然の権利であると考えています。ユーザーの立場で考えてみれば至極当然のことで、高いシステムを導入するのだから妥協はしたくないと考えるのは理解できます。しかしベンダーにとっては、スケジュールや稼働人員は決まっていて、これ以上の機能追加や変更を受け入れるということは、収支が真っ赤っかになるか炎上覚悟のデスマーチを開始するかしかありません。

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

ベンダーはユーザーの言いなりになるのではなく、プロジェクトが開始する前に、契約条件に追加や変更要件に関する事項を盛り込んでおくこと。さらに可能であれば、スケジュールのバッファをしっかりと確保しておきましょう。もし、大掛かりな仕様変更が発生した場合は、その仕様変更で
発生するリスクと追加費用が発生する旨をしっかりとした根拠と一緒に
ユーザーに説明し、期間の延長や追加費用の交渉をすることも重要です。

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

プロジェクトの進行途中、特に終了間際の仕様変更は大きなリスクがあることを認識しましょう。途中で仕様が変わっても、ベンダーにお願いすればなんとかなると思うのは危険です。

ベンダー側の言い分

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

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

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

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

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

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

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

プロジェクトは往々にして、スケジュールと予算が決まってしまえばモヤモヤした状態でスタートしてしまいます。本来であれば要求を明確にしてから、プロジェクトは走り出すのですが、そうではないプロジェクトも少なからず発生します。ベンダーにとってはゴールが曖昧のまま走りだすプロジェクトほど怖いものはありません。なんせプロジェクトの炎上が目に見えているのですから。

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

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

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

曖昧なゴールを設定したプロジェクトは必ず炎上します。ユーザーから明確な要件が出てこない場合、出来る限りプロジェクトのスタートを送らせてでも、要件事項の明確化に力を注ぎましょう。

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

ユーザーによっては、要件定義でさえもベンダーに丸投げすることがあります。「ベンダーに金払ってるのだから、要件定義も当然ベンダーが考えるべきだ」とお考えのかたもまだまだ多いです。しかしこれはプロジェクト失敗の第一歩です。ベンダーはユーザーが解決したい課題をすべて解決していないですし、場合によってはベンダーの都合の良い要件定義になってしまい、ユーザーにとっては使いづらいことこの上ないシステムが出来上がってしまう場合もあります。

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

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

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

もしユーザーが要件定義の作成を丸投げしてきたときは、要件定義の重要性を説明し、ユーザーに主体となってもらうように説得しましょう。無理であっても、必ずユーザーを巻き込みながら要件定義をまとめていくように努力すること。決して、これ幸いとベンダーの都合の良い要件定義にしようとしないこと。短期的には得をしたとしても、長い目で見ると、会社のブランド価値低下や信用の低下を生み、長期的には大きな損失になることを認識しましょう。