商売っ気がない優しすぎるベンダーを守るのも情シスの役目

ユーザーに尽くすベンダー

「あのとき、柔軟に対応するって言いましたよね」
「これだと分かりにくいので修正してください」

ある現場で基幹システムの受け入れテストを行っています。

テストを取りまとめる女性ユーザーのAさんは「請求・入金」業務を一手にとりまとめており、現場の信頼も絶大です。

Aさんはマジメで責任感が強く、「現場のためにシステムの妥協を許さない」というタイプです。

ある打ち合わせで、またもやAさんから要望があがります。

「ここに○○○と○○○の項目を追加してください」
「この帳票はレイアウトを全面的にこう変えてください」

それはさすがに「仕様変更」なので止めようとしたところ

「わかりました。対応します！」

と答えてしまう中小ベンダーのプロジェクトマネージャーBさん。

情シスメンバーは唖然とします。でもまあ、タダでやってくれるなら自社にとっては得なので、止めることはしませんでした。

しかし、その光景はその後、何度も続きます。

PMのBさんは土日もいとわず、全力でユーザーに尽くします。

深夜2:00過ぎに「修正しました」と連絡が来ていたことも珍しくありません。それなのに、対応はさも当然とばかりに翌日、細かい指摘を続けるAさん。

その後、ベンダーとの進捗会議で「3ヶ月遅れ」と報告がありました。リカバリー対策として「メンバー全員、休日出勤して対応します」とBさんは宣言します。

情シスはPMOとして、どう対応すべきでしょうか？

情シスの存在意義

まず、情シスがプロジェクトに入る理由は何でしょうか？

もちろん「IT・システム担当」としてITインフラ基盤、非機能要求、他システム連携などは、情シスがやるべきタスクでしょう。

しかし、それ以上に重要なのが「ユーザーとベンダーの橋渡し」です。

「業務」と「IT」の両方を理解し、相互翻訳し、関係調整をする役割です。

プロジェクトとしては、こちらの方が重要です。なぜなら、全体に大きく影響するからです。

情シスは客観的な立場で、間に入ることができるのが強みです。

ユーザーの味方であるべきですが、要求が度を過ぎたなら修正しないといけません。ユーザーをヨイショするだけの腰巾着では、責務を果たしているとは言えません。

また、声の大きなユーザーの味方をすることが、会社のためになるとも限りません。ときには恨まれ役になっても、身を挺して正しい方向に導かないといけない局面もあります。

攻撃する側は自己の正当性しか見えず「むしろもっとプレッシャーをかけないと動かない」と思いがちです。

ベンダーも人間です。あまりにも追い込まれすぎると、精神的にも肉体的にも壊れてしまいます。強そうにみえる人でも、案外もろいものです。

元気そうにみえても、ある日突然、糸が切れてしまうことはあります。一度そうなると復帰は困難となり、それをリカバリーする周囲のメンバーにも無理が生じ、一気にプロジェクトが破綻していきます。

ベンダーが潰れると、ユーザーも共倒れになります。

ユーザー当人は熱くなりすぎて、ブレーキを忘れることがあります。その場合は、情シスが代わりに踏まないと大事故に至ってしまうのです。

発注側が受注側よりも偉い。そんなことは全くありません。ビジネスは対等な関係です。しかし、要求を出すユーザーがそれを勘違いしたとき、プロジェクトを壊していくのです。

情シスは、ITプロジェクト全体を成功に導くのも、重要な役割です。

そのためには「どっち」が正しいのではなく「何」が正しいのかを客観的なモノサシで判断し、介入していく必要があります。

大手ベンダーのマネジメントとは異なる

ちなみに、もしこれが大手ベンダーの場合だと、どうなるのでしょうか？

大手ベンダーは、多くの取引先を抱えており、1つの現場にだけ構っていられません。そのため、社内の「利益目標」や「仕様変更ルール」が厳しく設定されており、ユーザー都合に振り回されない仕組みになっています。

今回でいえば、「仕様変更」で追加費用5000万円は下らなかっただろうと思います。あるいはユーザーの追加要望をまったく受け付けず、「オンスケジュール」で進めたかもしれません。

中小ベンダーだからこそ、1つ1つの取り引きを大事にし、採算性よりも「ユーザーファースト」で進めてくれているのです。

中小ベンダーが献身的に対応してくれているならば、財務的にこれ以上赤字となり倒産危機とならないよう、また過労やプレッシャーで潰れてしまわないよう、ベンダーを守ることも自社にとっての「正義」といえるのではないでしょうか。

情シスもリスクをとる

情シスメンバーは、ベンダーPMのBさんと個別に打ち合わせをしました。

まずは「ユーザーファースト」で要求を最大限に取り込もうとする姿勢に感謝を伝えます。その上で「スケジュール優先」と「仕様変更管理」をお願いしました。

ユーザーに「追加費用」を請求していい、とも伝えました。

そのときのBさんの安堵した表情が忘れられません。おそらく、かなり追い込まれていたのでしょう。手遅れとなる一歩手前だったのかもしれません。

翌週、ベンダーから「仕様変更」の説明をしてもらいました。

ユーザーAさんはものすごい剣幕で反論しましたが、そこに情シスが間に入ってフォローします。情シスもリスクをとりましたが、ここで「線引き」しないとマズイと判断しました。

その後、個別にAさんとも話しましたが、なかなか決着がつかなかったので、最後はプロジェクトオーナーに出てきてもらいます。

「プロジェクトは一枚岩、お互い助け合っていこう」と言ってもらい、何とか決着しました。

情シスにしかできないマネジメント

その話し合いから3か月後、システムは無事にリリースできました。

仕様変更は「23件」に積み上がっていますが、追加の見積もりを受けて、順次対応中です。

相変わらずベンダーBさんは安請け合いして、こっちがヒヤヒヤします。しかし、それもこのベンダーの魅力です。

ユーザーAさんも、相変わらず細かい要求を出し続けています。でも、いったんリリースまでこぎつけたので、今はお互いに「余裕」が感じられます。

Aさんと情シスの関係性は、時間とともに徐々に改善され、今ではAさんから相談を受けることも増えてきました。むしろ、あの一件で一目置かれたように思います。

貴社のIT部門・情報システム部門は、時にリスクをとってベンダーを守ることができているでしょうか？