トラブル対応のときに最初にやること

あのトラブルを何とかしてくれ、と言われたときからあなたは当事者である

「あのトラブルを何とかしてきてくれ、頼む」

と言われたその瞬間からあなたは当事者である。

そのプロジェクトで過去に何があろうが、過去に誰が何を言っていようが、それらをすべてひっくるめて、これからは自分の責任とする覚悟を持たなければならない。それが火消しリーダーになるということだ。

過去のことでお客様に何を言われても、文句は言えないし言ってはいけない。全てを受け入れて自分ごとにしなければ始まらない。 その覚悟がない人にはトラブルを対処することはできない。

いつまでも第三者的、評論家的な発言をしていてはいけない。メンバーもついてこない。

その瞬間が「トラブルの火を消す」というあなたのプロジェクトの開始である。

そして、あなたは火消しとして期待されていると思っているかもしれない、だが、そうとは限らない。次のような人たちが次々と出現してくる。

  • 期待する人
  • 煙たがる人
  • お手並み拝見と評価する人
  • 足を引っ張る人
  • 裏でロビー活動をする人

こういった人たちとも戦っていかなければならないのだ。

「初動」はありったけの資料を集めること 

手ぶらでトラブルに突っ込むのは愚の骨頂である。最初にやるべきことは資料を集めることだ。

だが、これまでのプロジェクトメンバーにプロジェクト資料を全部くれ、というと、「綺麗整理されてないので渡せません」とか「渡すために綺麗にするのに時間がかかります」と言われるのが関の山である。

それこそトラブルプロジェクトであり、トラブっているプロジェクトに綺麗な資料を期待してはいけないし、そのような回答に愕然としてはいけない。

そんなもんだ、と思って、資料があるだけマシだと思っておくくらいでちょうどいい。

資料を収集したあとにすることは、資料の存在網羅性と質の確認である。

システム開発の設計書であれば、開発フェーズごとに作るべき設計書とその質をわかっているので、ざっとサンプリングで見れば網羅性と質の確認をすることができる。

プロジェクトメンバーの全員が歓迎してくれるわけではない

  これから一緒に火消しをしていく仲間となるであろうプロジェクトメンバーがすべて味方とは限らない。いや、敵もいるものだと思っておこう。

  これまでプロジェクトをやってきたメンバーからすれば、突如やってきたあなたはいわば外部の人間である。それを受け入れられない人は必ずいるものだ。だからこそ、それを認識しておく必要がある。これから情報収集などで話をしていく人たちが敵なのか味方なのか、その品定めをしながらトラブルプロジェクトに入っていかなければならない。

  敵視されているならば、当然、出てくる情報は限られてしまうし、情報が曲げられる可能性もある。

  同じ会社のメンバーなのに、とか、同じプロジェクトのメンバーなのに、なんで敵視するんだよ、と思ったとしてもそこに意味はない。トラブルリカバリーに入るということは、そのような状態の中に突っ込んでいく、ということなのだから。

  そのように割り切っておかなければいちいちストレスがたまってしまい、とてもじゃないけど持たないのだ。

聞きたいことは100個は作っておけ

これから現場に入ってメンバーや関係者にヒアリングをしていくが、質問リストは事前の準備として100個は作っておこう。質問なんて、現場に入って状況を見て臨機応変にすればいいんだよ、と言っていてはダメなのだ。臨機応変な質問ももちろん必要だが、それは周到な準備をした上でのオプションである。

なぜ事前に質問のリストアップが必要かというと、課題や要因などを漏れなく聞き出すためである。現場での思いつきや会話の流れで質問をしていくと、必ず情報収集に漏れが発生してしまう。その時点であなたのトラブルリカバリーは失敗の第一歩を踏み出していることになる。重要なのは聞くべきことを漏らさない、ということだ。

100個も無理だよ、と思うかもしれない。100個洗い出せ、と言われれば難しいだろう。 だが、簡単な方法がある。

品質、コスト、スケジュール、などといったカテゴリをまずは10個洗い出してみよう。そして、そのカテゴリごとに10個の質問を考えてみよう。そう考えるとできそうな気がするだろう。そして、実際にやってみてもできるはずだ。

これで100個の質問ができるのである。

そして、カテゴリレベルで漏れがなければ、たとえ100個の質問を洗い出せなくとも質問の洗い出しとしては合格である。100に意味があるのではなく、聞くべきカテゴリに漏れがないことに意味があるからだ。

また、100個の質問が出来上がること以外の効果がある。あなたの頭の中が整理されるのだ。そのプロジェクトで考慮すべきことが網羅的に整理されるので、こからヒアリングをしたりいろいろな物を見聞きしたときの理解度が格段に高まるのだ。

あなたの懐刀を手に入れよう

これからトラブルの鎮火を開始するが、いくらあなたが優秀であってもあなたひとりでは鎮火することは不可能である。ひとりで局面を変えることはできない。

なぜならば、プロジェクトメンバーのほとんどはこれまでのプロジェクトメンバーであるからだ。これまでトラブルの流れを食い止められなかったプロジェクトメンバーにあなたひとりが入っただけで変えられることはできない。

そのために必要なのは懐刀である。懐刀とは、知識や技術に長け、上司・主君に対し忠実であり、なおかつ上司・主君から絶大な信頼を得ている部下・家臣のことをいう。右腕とも参謀ともいうこともある。これから火消しに入るにあたり、頼りになる有能なメンバーを巻き込んでおくことだ。

そのような人材は、すでに他の仕事やプロジェクトで活躍していることがほとんどだ。だから、欲しいと言ってもなかなか調整が難しいが、ここが最初の頑張りどころである。

1ヶ月後からならOKとか、兼務であればOK、ということもある。欲は言えない。そのような条件であったとしても譲歩して参画してもらおう。どうせトラブルプロジェクトの方が優先度があがり、いずれはどっぷり入ってもらうことになるからだ。

自分自身の仮説を立てよう

事前に収集した資料や、これまでに聞いてきた情報から仮説を立てる必要があるが、仮説は自分自身で立てておこう。

ここで立てるべき仮説とは、なぜトラブルになってしまったか、という原因と、どのように立て直すべきか、というこれからの対策の仮説である。

ここで立てる仮説がバージョン1.0であり、これから現場に入っていってその仮説の確からしさを検証していくものである。 なぜ自分で立てるべきなのだろうか。

すでにいろいろな資料を見て、いろいろな人からの断片的な情報も入ってきている。そして懐刀ともディスカッションをしていることであろう。それらはもちろん仮説の参考にしていい。だが、「これが仮説だ」というのは自分で最終結論を出そう。

この先、さらに多くの情報が入ってきて、さらに多くの人と会話することになる。そのときに、だんだんと振り回され始めてくることになる。もちろん、いい方向に軌道修正することはすべきである。だが、単に振り回されてはダメだ。

そうならないためには軸をもつ必要がある。自分の仮説に自分の意志を込めておくのだ。そのために自分自身で仮説をつくるのだ。 恐れることはない、仮説は仮説なのだ。間違っていてもいい。だが、最初の仮説づくりから、自分自身の軸を持って進んでいくことが重要なのだ。

f:id:vekitomo-0:20210127014546p:plain