2023
10/12
![商売っ気がない優しすぎるベンダーを守るのも情シスの役目](https://www.josys-cs.co.jp/wp-content/uploads/2023/10/1174923_s.jpg)
ユーザーに尽くすベンダー
「あのとき、柔軟に対応するって言いましたよね」
「これだと分かりにくいので修正してください」
ある現場で基幹システムの受け入れテストを行っています。
テストを取りまとめる女性ユーザーの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部門・情報システム部門は、時にリスクをとってベンダーを守ることができているでしょうか?
関連コラム
コラム更新情報をメールでお知らせします。ぜひこちらからご登録ください。
![御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか](https://www.josys-cs.co.jp/wp-content/uploads/2022/04/book.png)
情シスコンサルタント
田村 昇平
情シス(IT部門、情報システム部門)を支援するコンサルタント。
支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。
多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。
また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。
「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。
著書の詳細は、こちらをご覧ください。