顛末書とレスポンススピードと顧客満足度の話

MacBookとサヨナラして幾許かすぎた。だんだんiPadにも慣れてきて、周囲のMacBookはそんなに必要？って問いに対してなんて答えるべきか再度考えさせられてる毎日。

掲題の話

今週は顛末書を書くのが僕のミッションだった。もうさ、アレ疲れるよね。個人ならいーんだけど、そういう規模でもなくて。

ただ個人としては、今回の件ををダメとは言いたくない。いや、ダメなんだけど、ダメなんだけどさ、顛末書コースのプロジェクトを走らせちゃったのは 良くないことだけど、ただ言いたいのは今回の顛末書の背景。そこには、至らなさはあるけど、その環境に燻ってる人たちの挑戦があったってこと。色々変えたかったの、現状から次のステップに進めようとしてたのよ。ご迷惑をお掛けした各所には謝るしかすることないけど、事業をドライブさせるには、これも必要なきがして。

人が集まれば

大きなことを行うには、何人もの人を集めることは必要不可欠だ。そうじゃなきゃ、今のスケール・スピード感についていくなんて無理。とはいえ、人が集まれば厄介なことも起きる。各所の責任範囲を決めなきゃモノゴトは動かないし、だけど各所に役割を分担させてもプロジェクト全体の視点で見れば漏れる可能性が多分にあるのが実際のところ。誰一人として悪意を持っていなくても、全体視野で動ける器用な人なんてそうそういないんだから、インシデントが起きれば自分の担当の無実をまずは主張したくなるのもしょうがない話。

綺麗に分けたつもりでも、どこかで宙に浮いてしまった重要タスクがあって、それがドカンと落ちてくる瞬間はプロジェクト進行の中で必ず出てくる。

誰だって持っている時間は1日24H、プラスその人の特性を考慮すればやれる範囲を拡張させるにはそれ相応の工夫がいるし、役目を見出せないタスクをやりたがる人なんてそうそういない。経験則だけど宙に浮くタスクは、やりたがる人がいない仕事な気がしていて。

顛末書レベルのインシデントが起きた時こそ

インシデントは必ず発生する。それを防ぐのは必要だし、起きない方が良いに決まっているけど今の外部環境変化とビジネススピードを考えれば、そうも言ってられない。インシデント0を最優先にしたプロジェクト進行じゃ、せっかくオーナーから勝ち取った投資をペイ出来る気がしない。これ、インシデントどころじゃ無いよね。

インシデントは必ず発生する。それは、多くの人が、お客さんも含めて認識してる事実だと思う。だからインシデントが起きた時一番大切なのは、責任回避のスペックじゃなくって、各所を追い詰めずどれだけ中立かつ建設的な話を引き出すか。そしてそれをすべての関係者に説明できるか。

お客さんはインシデントなんて望んで無い。でも、絶対に起きないなんて思ってない。これ、提供側は忘れがち。

お客さんもどこかで分かってる、起きた時にどう対応するかも提供するサービスの一部だとして捉えてるんじゃ無いかな。

提供側は、起きたら最後って思いがち。だって、お客さんはすごい剣幕だし、仲間は責任回避に動こうとするし、そりゃ自分の明日を考えれば最後って思うのもおかしくない。

でも、インシデントは終わりじゃない。その時にどう動けるか、最後を見誤らずに動くのが非常に大事。