最後はお詫びのマネジメントとなります。プロジェクトや保守運用の中で何かまずいことがあったときの対応ということで、お詫びマネジメントと名付けています。
お詫びというものにクローズアップされているということも珍しいのではないかと思いますが、さらにお詫びマネジメントというのはいささか大げさではないかと思われるかもしれません。
お詫びと言っても、ただ会って誤ればいいというものでもありません。ビジネスで利用されているシステムはそのような単純な影響では済まされないことが多いです。そのことを意識せずに目の前の発生事象にのみに捕らわれていると、謝罪のつもりが、逆効果になることだってあります。
お詫びは、常に起きるものだと考えていないと、スムーズに行動できないのが普通です。
お詫びに慣れてしまうのも問題はありますが、リスクマネジメントの一環という意味でも、お詫びに備え、さらにその次に繋がるようにしましょう。
プロジェクトおよび保守運用でのお詫びとは
ビジネス上、重要なコミュニケーションであるお詫びについて説明していきます。
ＩＴプロジェクトでのお詫びの場面とは
プロジェクトの場合は誰に対するお詫びとなるでしょうか。プロジェクトにはプロジェクトオーナーが存在します。よって、オーナーへのお詫びが最終的な相手となるでしょう。
しかし、プロジェクトは複雑な体制になっていることもありますし、受発注の関係もありますので、単純に誰が誰に、という構造ではないかもしれません。
誰が誰に、がわからない時こそ、実はお詫びマネジメントが必要なのかもしれません。
というのは、お詫びとは謝る、謝罪するということですので、お詫びするほうは何か相手に悪いことをしたことになります。しかし、誰が誰に、というのがもしはっきりしていなければ、そもそも悪いことが起きていることが認識されていないかもしれません。
また悪くないのにお詫びを入れたら、悪いことを認めていることになってしまいます。プロジェクトにおいては、特にそういう場面になることが多いです。というのは、例えば仕様変更でプロジェクトが遅延しているとして、それは誰が悪かったのでしょう。
仕様変更の原因によりますが、仕様変更は一概にだれの責任と言えないこともあります。よって、安易にお詫びすればいいということではありませんが、お詫びに関して構えておくことは必要となります。
プロジェクトにおいては、お詫びは明らかな瑕疵があった場合を指すことにします。
ＩＴ保守運用におけるお詫びの場面とは
保守運用においては、実際に運用されている状態ですので、事業影響に直結します。よって、障害が発生したのであれば、お詫びに該当します。
仮に悪いことを起こしていなくても、実運用上障害が発生し、事業影響が発生したのであれば、誰かに迷惑が掛かっていることが明らかなので、お詫びは発生します。
ただ、誰から発信するのかというのが、はっきりしないこともあるでしょう。というのは、誰もコントロールし得ないOSの障害等によるものもあるからです。
しかし、だからこそお詫びのマネジメントがなされないといけないということになります。
ＩＴ保守運用においては、確かに明らかに保守においてミスを起こしたり、運用手順漏れを起こしたりすることはありますので、直接的なお詫びもあります。誰も悪いことを起こしていなくても、結果影響が出ているものもお詫び対象です。
プロジェクトおよび保守運用でのお詫びマネジメントとは
ＩＴプロジェクトにおけるお詫びのマネジメントとは
プロジェクトにおいては、何等かの問題があり、遅延であったり、コスト超過であったりといった問題が顕在化する場面があります。
受注側に見積漏れがあって、後から追加コストがかかるというのは、お詫びに相当します。
コスト追加の場合、さらに最初の予算よりオーバーしてしまうので、オーナーに対するお詫びでもあります。
オーナーはプロジェクトマネージャではないことが多いです。よってプロジェクトマネージャやプロジェクト責任者がオーナーにお詫びすることになります。
お詫びに関しては、このような報告ルートがあるのであれば、その先を考えたお詫びの仕方が必要となります。これをマネジメントすることが重要となるということです。
ＩＴのプロジェクトにおいては、入り組んだ技術的な問題により、問題が顕在化することが多いです。それにより遅延に繋がったとして、だからと言って、技術的な問題が解決しないことだけをお詫びしても、ビジネス部門とオーナーには理解できません。
よって、事業面への影響やプロジェクト全体への影響を予め考えておきます。
予め考えておくプロジェクトお詫びの段取り
何に対してお詫びしているのか、直接事象、影響、原因、対応方法といった順であればいいですが、影響がよくわからないまま原因を突き詰めてしまうことがあります。
その後、経緯を振り返り、根本原因を捉え、根本的な対策を講じるというのが、わかりやすい流れです。
根本的な対策を示さないまま、お詫びと言っても、また何か起きるとしか思えません。しかしそこまで辿り着かないこともあります。
時間も重要ですので、まだ根本原因がわからないときは、途中経過で報告するべきでしょう。
プロジェクトを計画した時に、お詫びのマネジメントを計画することはあまりないでしょう。お詫びする場面は、普通に考えるとあってはならないことなので、元々計画することなど考えもしないでしょう。
しかし、実際は結構な頻度で起きます。よって備えるに越したことはありません。
どういうルートで、どのようなタイミングで、どういう内容で、どの場で報告するかは準備できていたほうがいいです。
会議体が決まっていれば、その場を活用してお詫びということもできますので、計画して対応していきましょう。
ＩＴ保守運用におけるお詫びのマネジメントとは
プロジェクトと違うのは、実際に本番運用されているため、何か起きたときに即座に実運用に影響し得るということになります。
実運用は、ユーザの業務に影響することもありますが、最悪は実事業に影響を与えるものにもなります。
グリコのチルド品出荷停止のように、システムの問題がかなりの事業影響を及ぼすことがあります。
すなわち、お詫びでは済まされない問題にもなります。よって、お詫びマネジメントがなされる必要があります。
直接の段取りは、プロジェクトの時と同じですが、波及影響が対外的なアナウンスにも及びますので、そこまで考えたマネジメントにする必要があります。
何に対してお詫びしているのか、直接事象、影響、原因、対応方法、経緯、根本原因、根本的な対策という段取りに加え、対外的なアナウンスのための発信先について予め整理しておきます。
セキュリティ事故についても近年は多くなっています。誤ってメールアドレスを晒してしまうという事故もよくありがちです。
そのような対外的に影響があるものについては、責任者のもとで、発生したらすぐに対処できるように準備が必要です。
その場で、お詫び文を考えていると時間が経ってしまいます。理想的には訓練により予め決めたことを定期的に実行することです。
影響が不特定多数の消費者等に影響することもあります。そうであればなおさら準備がいることになるでしょう。
お詫びのタイムマネジメント
システムの運用中に障害発生となると、初めは何が起きているのかがわかりませんので、原因を探りに行きます。ある程度何かがわからないと影響範囲も特定できないからです。
しかしある程度影響があることがわかったら、お詫びマネジメントに入ります。
原因究明と対策系の作業はエンジニアが実行しているでしょう。しかしお詫びマネジメントも始めないと、影響を受けている人がどんどん混乱してきます。
顧客影響の問題であれば、さらに急ぎ対応していかないといけません。
よって、通常はお詫び用体制を別に立てないと間に合わなくなります。誰も手が取れなければ経営者が立つこともあるでしょう。
障害に対しては、その場で対応していかないといけない場面が多いです。
影響を見極めるとともに原因や対処についても、状況を都度監視します。状況を見て、発信できるタイミングで発信していきます。
発信した際に、まだわかっていないことが多い場合があります。したがって、確定した情報がアップデートされれば、再度発信していくことになります。つまり逐次発信していけるよう、マネジメント体制が組まれていることが必要ということになります。
お詫びのマネジメントにおけるありがちな問題とは
お詫びではない内容だと遅れてしまう
明らかにお詫びに値する原因であれば、誰しもが構えると思います。
しかし、原因から言って、何かよくないことをやらからしたわけではなく、不可抗力的なものであったとします。
そうすると初動が遅れがちです。
何等かの問題は起きているのは確かで、対処をしているのも確かです。しかし、お詫びについては、後手に回してしまいます。
確かに、事象を解決するのが先決なのは当然です。しかし、少しでも影響が発生してしまっていたら、お詫びとして構えておいたほうが無難なはずです。
予め準備した報告に意がない
予め準備すべき、という話をしました。
予め準備されていているからと言って、機械的に報告されていては、お詫びの意味をなさなくなってしまいます。謝罪の意を示すことが本来の目的ですから、形式的に報告がなされてしまうのもよくはありません。
しかしスピードも大事ですので、準備は有効です。準備されたものに加えて意を込めることも大事です。
うまく進んでいると思ってしまう
お詫びをするような場面が発生したということは、自分の側に何等か問題があったということです。そういう時は、最悪は経営者やかなり上位の責任者がお詫びする可能性があります。
しかし、そのような事態なのかどうか初めはわからないことがあります。結果的に大きな事態だったとしても、最初はわからないので、現場でうまく進めていると思いこんでしまうことは多いです。
うまく対処されて問題が収まればいいですが、事態が大きいこともありますので、やはりお詫びマネジメントの構えは常に必要でしょう。
計画の保険を考えおくべきであったが考えられていなかった時
プロジェクトの切り替え・移行した際に、もしうまくいかなかったら被害を最小限にするように計画に保険を掛けておくべきです。
実際うまくいかない事象が起きたら、保険のほうの計画に切り替えます。
しかし、何も考えられていないことがあるのも確かです。そうであればお詫び一直線なわけですが、保険の計画が立てられていない時点で、お詫びの計画があるわけがありません。
このような時は、かなり悪い状況に陥るでしょう。
すべてを悲観的に考えるのもどうかとは思いますが、楽観的でいることのほうが多いのではないしょうか。というのは、ちょっとしたことであればそんなにしょっちゅう問題は起きません。しかし、ここぞという時は、何かが起きます。
お詫びのマネジメントとして本当にやるべきこととは
やっておきたいこと
お詫びをするようなことは、できれば起こしたくはありません。しかし、常に何かを営み提供している立場であれば、常にお詫びと裏腹な関係にあります。
したがって、起きることを想定して、起きた場合に何をすべきかを考えておくことは、重要です。また、起きてしまったとしても確実にお詫びできるために、段取りをマネジメントし、着実に前に進めるようにしていきたいです。
誰に影響があり、原因が何で、いつ対処されるのか、次は起きないのかといったことを、誰に伝え、その先に何を伝えるのか、計画しておくことで、対応していけます。
もちろん、お詫びの事態に陥らないよう、そもそも計画しておくことも大事です。
お詫びはチャンス
お詫びするような事態は、悪いことが起きたからこそしているわけですが、一連のお詫びをすることで、確実に改善が施され、前に進みます。
よく問題になるのは、詫びられる側と詫びる側との温度差です。
詫びられるほうは迷惑を被っているので、怒りがちです。しかし詫びるほうが本当に悪かった、と思っていることもありますが、そうでもなく、何等かの問題がたまたま起きてしまったぐらいに思っていることのほうが多いのではないでしょうか。
実際、迷惑と言っても大したことがないこともたくさんあります。たいしたことのないことに、大袈裟に詫びるのもわざとらしいです。
そこで、お詫びマネジメントで、ある程度論理的に説明し、結果的に意を込めることで、温度差は埋まっていきます。
まずは、問題と直接の原因となった事象への対処ができていることを示します。対処は進んでいないと問題ではありますので、確実に進めてください。
そして、さらに問題が起きた関係事象を経緯として並べます。経緯の中から、根本原因となりうることをピックアップします。
場合によっては、原因同士が関連しあって、結果大きな問題への繋がることもあります。
そのような複合要因も時系列的に追っていくことで、一つひとつ見えるようになってきます。
中には、どうしようもなかったと思えることもあります。
例えば、元々作業員が体調不良であり、代わりを頼んだがその作業員は別な作業で忙しかった。その場には他に誰もいなかったので、体調不良ではあったものの作業を続けた。結果ミスが起きてしまった、、、とった経緯を見れば、問題があったのはわかるが、実態も見えているため、今後の反省点も残すことができます。
今までコントロールしきれていなかったことも、問題の原因となりうるのであれば、コントロール対象にする、といった前向きな改善点が見えるようになり、顧客との関係が良くなることもあるでしょう。
コメント