はじめに
本記事では、ITベンダーに発注する企業がしてしまいがちな、過度な品質管理要求とこれに伴う弊害について記載をしております。特に非IT企業にとっては、ITベンダーがやっていることはよくわからないことも多く過度な品質要求をしてしまいがちです。要求をするなとは言いませんが、適切な管理をできるように心がけていきましょう。
ケース例
実際のケース例に沿って記載を進めていきたいと思います。
問題例
１．あるシステム開発Aにおいて、ベンダー担当者の引継ぎが発生した。
２．システム自体も品質も低く、担当者依存度が高いものであった。
３．しかし引継ぎが十分にできていなかった。
４．結果として、システムリリース後にバグが発生（デグレード）が判明し、切り戻しを行うこととなった。
上記のような問題が発生した場合、当然に原因の究明と対処を求める必要があります。しかし、この原因の究明と対処が行き過ぎるケースをよく見ます。
NGケース
NGケースについて記載していきます。これはあくまで発注元企業の立場としてのNG例とお考え下さい。
- デグレードの発生原因や、バグ混入経緯の細かな原因分析・報告書作成を要求する。
- 今後の改善活動依頼にとどまらず、改善の監督を行おうとしている。
- 証跡を残すため、リリース管理の詳細なドキュメント作成などを過剰に要求する。
- リリース失敗をつるし上げ、減額や無償対応を迫る。
上記のようなことを要求されているベンダーも非常に多いのではないかと思います。
NGケースで発生する問題
しかし、上記のようなことを行ってしまうと以下のような事象が発生します。
- ベンダー側の人員が疲弊する。
- 信頼されていないと感じ、心理的安全性が下がる。
- 無駄なドキュメント作成に時間を取られ、対応工数がひっ迫する。
こうなると、負のスパイラルが発生します。ベンダー人員が疲弊し、対応工数がひっ迫すると当然やれる対応は限られます。その上、心理的安全性が下がるとなると、以下のような対応になります。
- ベンダー側は”言われたことだけやろう”というスタンスになる。
- 主体性が下がり、要求事項しかやらなくなり提案をもらえない。
- 見積時もバッファを多く積んだ高額見積もりを出す。
- 何を言われるかわからないので、報連相がおろそかになる。
NGケースを行ってしまう理由
なぜ上記のような要求をベンダーにしてしまうのでしょうか？
「上役に怒られたくない、自分の責任を回避したい」
と考えているからではないでしょうか？
今回のNGケースにおいては、「引継ぎ不足」が原因と考えられます（当然原因は違うかもしれないので会話していく必要があります。）そうであれば、やるべきことは引継ぎのバックアップ・知見の増強であり、精緻な品質管理ではないのではないでしょうか？
人間誰にでもミスはあります、それが引継ぎ直後のシステムリリースとなると当然発生しうるのではないでしょうか？問題が発生したときに、ベンダー側から問題報告を受けた後、やるべきことはベンダーをたたくのではなく、ベンダー側の人と共に対処方法を考え、上役に頭を下げてチームを守ることではないでしょうか？
社内の部下であればこれができても、社外となると急にできなくなる人が多いと感じます。システム開発ベンダーを含めて1つのチームです。その窓口を担当した人間はベンダー含め全員を自分のチームだと思い、育て・守る必要があると考えます。自分事として一緒に解決してくれる人がいて初めて、人は心理的安全性が高まり、よりよい提案をしてくれるようになるのではないでしょうか？
NGケースを行わないために心がけること
ベンダーをワンチームというのがあるべき姿とは言え、やはり社会人であるが故に自社の利益を尊重している姿勢を見せないと怒られます。出世にも影響するでしょう。では、どのように行動するのが良いでしょうか？
解は1つではないと思いますが、私は社内と社外での報告に、バッファを持てるようにしておくというのが大事ではないかと考えています。
例えば以下のような体制だったとします。
情報システム部としてベンダーコントロールを行っている立場であり、事業部が要求者・ビジネスオーナであると考えてください。
この場合にシステムの1つの機能の改修にかかるコストを下記のように報告していたとします。
すると、仮にベンダー側の見積もりが甘く予算（50万円）をオーバしたとしても、要求者には75万円で済んだと報告することができます。ベンダー側としても＋25万円になったのに、うまく調整してくれた！と映ることでしょう！
上記の例は非常に極端ですが、このように間に立つ業務PMは、双方の期待値をうまくコントロールし、問題発生時にバッファを自分で持てるようにすることが重要です。金銭面だけでなく、品質やスケジュール面でも同様にバッファを持てるように立ち回ることが重要です。
ある意味社会人の基礎であり、自然と実践する人が多いと思いますが、技術畑出身の人がPMになる場合、正しいことを伝えることの重要さを身に染みている方が多いため、正直に答えてしまうことが多いのではないなか？と思います。
おわりに
本記事では、ユーザ企業がしてしまいがちな、ITベンダーへの過度な品質要求について記載しました。
NGケースを交え、何をしてしまうのか？するとどうなるのか？なぜそうしてしまうのか？の観点から記載をしました。
最後にこのような問題を発生させないための心構えや、対策の1つを記載させていただきました。
上記のようなコントロール業務はPMに求められるヒューマンスキルの一つだと思いますので、ぜひ磨いていっていただければと思います。
コメント