プロジェクトの終盤で、ベテランが立て続けに退職しました。リリース品質が悪化し、上司からはメンバーへの管理強化と退職に備えた精緻な文書化を指示されました。現場の負荷を考えると避けたいのですが、ほかによい方法がないか悩んでいます。

(SIベンダー/運用保守マネジャー)

 管理強化による束縛、ノウハウの精緻な文書化は今となってはよい方法ではないと思います。2つの面で「強いチーム」を目指した方がいいでしょう。1つは退職などの突発事態に耐えられる組織、もう1つは退職したいと思われない組織です。

 まず、暗黙知を生かすと、トラブルに強い組織を作れます。

 1つめは「意図の共有」です。運用保守の現場で避けたいのは致命的なオペレーションミスです。一般的には、手順化の徹底やダブルチェックといった対策がよく行われますが、私の経験では根本原因は別のところにあります。担当者が、目的を理解しないまま作業していることが意外に多いのです。こうした現場では、致命的なミスにつながる重要なコマンドもそうでないコマンドも同じ感覚で打ち込んでいます。

 オペレーション本番に臨む前に「何の目的で、システムのどこをどう変更するのか」「クリティカルなオペレーションはどれで、どんな処理を行うのか」を担当者に直接伝えるようにしましょう。人は、意図を共有すると、正しい方向に自律的に修正できるものです。もし、これまで伝えていなかったのなら、これだけでもトラブル発生率は想像以上に下がるはずです。

 2つめは「暗黙知の共同化」です。ベテランのノウハウは感覚的な部分も多く、文書による形式知化には限界があります。文書として表現可能な知識は、全体の10~20%にすぎないという調査もあります。

 暗黙知の知識移転は、伝統的な方法ではOJTがあります。近年はより戦略的に、個人の暗黙知を組織全体の暗黙知として定着させる試みが増えています。具体的には、2人1組でオペレーションを行う「ペアオペレーション」といった共同作業の実施です。ベテランの作業を学ぶとともに、「なぜこのコマンドなのか」といった意図を伝承します。開発現場ではペアプログラミングがそれに当たります。

 組織全体にベテランの知識が伝承されるよう、組み合わせを変えながらペアオペレーションを続けます。ノウハウを身に付けたメンバーには、知識を伝える側に回ってもらいます。他人に教えると理解が深まるため、知識を定着させる効果が高まります。知識移転と同時に、人間関係が強固になる点も大きなメリットです。

 これを続けることで、文書化できないノウハウを含め、ベテランの知識が組織の知識として共同化され、予定外の病欠や退職といった組織面でのトラブルに耐えられる強い組織が形成されます。

 退職したいと思われない組織にするには「個人へのリスペクト」が必要です。ベテランを放ったらかしにしていないでしょうか。もしかすると、それが退職の原因かもしれません。私も含め、日本人は褒めるのが苦手な傾向があります。結果として、優秀な人ほど放置されがちです。