プロマネなら簡単には謝罪するな〜情シス目線のプロジェクトマネージメントTips#47

世の中にプロジェクトマネジメントに関するコンテンツは非常にたくさんあるのですが、よく見てみるとどうしてもSIer目線のものが多いように思えます。SIer目線の場合だと、どうしても利害が一致しないせいか事業会社というか情報システム部門目線から見るとピンとこないものも多く、ちょっと腹落ちしないことが多くあります。
というわけで無いなら作ろうということで「情シス目線のプロジェクトマネジメント」なるものを書いてみようかと思い不定期だとは思いますがシリーズ的に書いていこうと思います。

今回はプロジェクトの話に戻って「謝罪」。プロジェクトマネージャーや開発リーダーは簡単に誤ってはいけないという話です。

ついつい謝ってしまいがちだけど

ITシステム開発プロジェクトでは「謝る」という場面に度々出会います。大抵の場合は障害が発生したりして、被害にあったユーザー側がカンカンに怒り開発者側がひたすら謝る・・・・といった場面です。

かつての時代には「お客様は絶対」という風潮が強くあり、理由はともあれ発注者側が一方的にシステム開発側を糾弾するという図式がほとんどでした。そりゃぁ超ボッタクリ価格で超高価なメインフレームを売りつけていた時代にはいくら無罪でもとりあえず謝ってしまったほうがお得と言うか、どうせ詐欺られている被害者が喚いているだけだったのですが、いまやそんな馬鹿みたいな利益もないのに、理不尽な怒りに付き合う必要もなくなってきている。

しかも、最近の優れた開発環境やテストの自動化により、かつて大量に起きた「メモリケスの忘れてた」とか「ループがおかしい」みたいな「純然たるバグ」というのはものすごく発生しにくくなっています。「バグ」と言われてよくよく調べてみたら、実は要件の漏れだったとか、急な変更があって影響の考慮が漏れていたとか・・・・そんな理由が多いものです。

本当に謝る必要があるのか？

後ろにいるメンバーの事を考えよう

たしかに怒り狂った相手には謝ったほうが圧倒的に楽なのは確かです。どうせ何をどう説明したところで感情的になった相手が簡単に納得したりしないのだから「とりあえず謝る」ほうが精神的なコストとしては正しい判断なのかもしれません。

でもプロジェクトマネージャーや開発リーダーの貴方は開発者たちの代表なのです。自分がした作業に問題があって起きたことならさっさと謝ったほうがいいのですが、あなたの「謝り」は開発者たちの替わりに行う行為なのです。原因がわからないのにそんなに簡単に謝るというのは彼らのプライドを大きく傷つけることになります。

プライドが傷ついた開発者たちは果たして今後も良いパフォーマンスを発揮できるでしょうか？健全な心理的コンディションで仕事を続けられるでしょうか？あなたを信用して、無理を聞いてくれるでしょうか？

おそらくはパフォーマンスは落ち、無理も聞いてもらえなくなる事態に陥るでしょう。長期的な利益を考えたら、プロジェクトマネージャーとして簡単に謝るのは正しい判断とは決して言えません。

情シスこそ謝るべからず

そうは言ってもSIer（ベンダー）の立場だったら、そんな事はできません。相手は何と言ってもお客様です。気分を害されたら次の契約はないかもしれません。どうしても謝らざるを得ないのです。

でも、情シスは違います。怒り狂っているのはお客様ではなく、所詮同じ会社の「同僚」でしかありません。しかも大抵は自分に対する人事権のない「ユーザー部門」の人間です。

情シスこそ簡単に謝ってはいけません。そして簡単に謝らせてはいけません。よく謝るSIerを横目で眺めていたり、酷いときには一緒に攻めていたりする事があるようですが、そんな事をしても自社のメリットは全く有りません。一時的な怒りは収まっても長期的には良いことは起きません。

他社のSIerのメンバーは情シスの所属する会社の利益に対するモチベーションは下がって良い仕事が続かなくなりますし、下手をすると次回の契約の見積もりにはたっぷりと「リスク費」が積まれるだけです。長期的な自社の利益を考えれば一時的な感情に流されてはいけないのです。

情シスこそ冷静になって謝らない、そして割って入ってでも謝らせてはいけないのです。

まずは応急処置に集中する

では、どうすればよいのか？

まずは応急処置です。血が出ているままの状態であればまずは止血することが第一です。怒ったり謝罪している暇があるなら、冷静に「まず必要な処置をしましょう」と伝える事が大事です。「怒るならその後にしましょう」と言ってまず棚上げする事です。

事態が収拾できたら、次は原因をしっかりと調査することです。怒っても謝らせても、土下座させたとしても発注者側にはビジネス上のメリットはありません。今の法律ではどうせ返金させる事は難しいのですから、マウントを取ったところで何も得はないのです。ちゃんと原因を確認し、再発防止策を行うしか新たな利益を生むことができません。

まぁ大抵の人であれば、間が空けば興奮は収まっているのが通常です。（この段階でも興奮がやまないような異常者ならなおさら謝るのは良策ではないですが・・・）

そしてしっかりと原因を確認する

ここで気をつけないといけないのは一般的な開発者、まともな人であればあるほど「自分のミスです、すみません」と言いがちです。しかし以前にも書きましたが「本当のミス」なんてそうそうありません。誰かをかばっている場合もあります。ここは徹底的に確認する必要があります。

過去の例ではリリース直前になってから、正式な変更プロセスを経ずにユーザーが開発者に修正を指示していた事もあります。その時は顧客であるそのユーザー部門の人をかばうため「自分のせい」と言っていたケースも有りました。またインフルエンザでダブルチェックの体制が取れないのにリリース作業を強制されていたケースもあります。

だいたい受入テストをしていた場合は、受け入れた側にも責任があるはずです。開発のどこがまずかったのか、テストのどこが拔けていたのかをしっかりと調査・評価する事が大事だと思います。

そして本当に開発者の問題であるならば、明確になってからきちんと謝ればいいし、そうでない場合は発注した会社全体で反省して会社の代表としてとして開発者側に謝って見せればいいのです。きっと怒り狂っていたユーザー部門の人はあやまらないケースが多いですがバツは悪いと思います。いっそのこと「感情的になって怒り狂ってすみません」と替わりに謝ってしまうと立つ瀬はなくなるでしょう。

大事なのはチーム

プロジェクトマネージャーであるならば、守るべきはチームだと思います。チームの価値やパフォーマンスを既存するような安易な謝罪はそのチームを自ら傷つける行為です。

プロジェクトマネージャーは開発者の代表でもあるのです。

下げる頭はそんなに安くはないと思います。