チームがイザというときに高速で作業を出来るように成るには当たり前の作業を当たり前にできる訓練が必要なのは当たり前すぎて

「チームが、イザと言うときに確実に、求められるスピードで対処できるようになるにはどのようにチームビルディングすればいいと思う？」

以前、とある大型プロジェクトの1チームを預かっていたときの話なんですが、全体のプロジェクトマネジメントはちょっと変わっていて、いや、あまり褒められたプロジェクトマネジメントではないと言わざるを得ないくらいコントロールされていないプロジェクトがあって、それはも、急に予定が調整されて作業が入ったりしていたんですね。

これはとっても困りますね。だって、計画も予想も立てにくいんですから。とはいえ、何も対策をせずにチーム運営なんてやっていられません。チームの作業が成り立たないし、何時どれだけの作業の計画が立たないということは何時どれだけコストが必要なのかという予算面にも影響するし、大体、コントロールされていない上から「振り回されるのはごめんだ！」なわけです。

初めは全体がそんなプロジェクトマネジメントになっているなんて思ってもみませんでしたから、振り回されたんです。その回は。でも、それでは「アカン！」と思って、チームに「こうあってほしい」というイメージをワタシ自身が持つことに。どういったイメージを持ったかと言うと、最初の段階は、

「自分たちが確実にできる時間を確保して、その時間以内で確実に作業を完了できる。」

これ、割と目標としては高いレベルです。自分たちの作業時間を作業ごとに把握していなければどれだけ時間を必要とするか見立てられないし、確保した時間でやろうとするとプレッシャがかかるし、確実にやったかどうかは手順を明示的にして曖昧さを排除しないといけないし、作業がこれで完了した、と言えるような有効なエビデンスを識別し確実に且つ最小限の手間で取ることが出来ないといけないんです。

じゃあ、どうしたか。もう、基本のキ、からですね。

作業を明示的な手順として文書化するために手順書を作ったら検証環境を作ってこれでもか！ってほどに突っ込みをさせるし、実作業中に判断の必要が無いように排除させることを目的に段階を踏んで洗練させるんです。

全員に一度は検証環境を使わせて手順書を確認させるんですが、それは作業自体に慣れさせる訓練もありますけど手順書を誰が見ても損作業ごとに判断が必要のない記述レベルにしておく必要があるからです。手順書を見ながら作業する際に、いちいち作業者が判断の必要な手順になっていたら判断するためのデータを確認するというムダな作業が必要になるし、

何より、作業者の理解レベルで破断結果が左右される可能性があるのがとっても危険なんですよね。そのリスクを受容できないからチームのメンバに慣れさせる環境を作って手順を確認させるコストを掛ける、と。

で、これで手順が標準化されるので、チームメンバなら誰がやっても同じ結果をえられるようになるんです。そう、誰がやっても。これは大きいです。そして、手順が洗練されるし、一人ひとりが検証をするので最初は不慣れでもどのくらいの時間が必要か実測できるんですね。

勿論、最初は時間がかかるし、手順書を見ながらだから操作が覚束ないけれど、習得できていないなら環境はあるのだから何度もリトライできるわけです。で、そんなこんなで標準作業時間のモデルを実績から作れるんです。手順書を揉むということは、作業品質のエビデンスを取るにしても闇雲に取るとか、肝心なところで取らないとかはメンバが喧々諤々として見直してくれるようになります。

そして、作業品質のエビデンスの取り方も、取った後の資料整理も考えるようになるんですね。後工程も自分たちでやるのですから、後にツケを回すことは止めようとする。だから、取るときのひと手間で後工程の二つ、三つの手間を減らそうと頭を使うようになるんです。

こうしたことの積み重ねが、確実に、自分たちの持ち時間で、高速に作業を想定した品質で確保できるようなチームビルディングすることが出来るんです。ここまでたどり着くには相応の時間もコストもかかるけれど、何時でも期待する品質が得られるから先の不確実性のある作業から解放されるんです。

急に割り込もうとしても、「これだけ時間が必要。」と手順を示して整然とロジカルに説明できるので時間を確保できるし、その時間でやらないといけない作業を確実にできるので、信頼もされるわけです。なにより、作業品質を確保しているので手戻りがないし、周りのチームがいくら急なスケジュールのプレッシャを掛けられていてもワタシのチームメンバは思考停止しないし確実にexitできるのです。