SIで働いてたときはどこかの会社で働くことが多かったので、自然と仕事の手離れについて考えるようになった。今年で社会人10年目になるが、「仕事の引き継ぎ」はとても難しい仕事だと思う。成功率は低い。そもそも引き継ぎなんてやろうとすることに無理があるのかもしれない。今日はふとそういうことを考えてみた。
なぜ引き継ぎがうまくいかないのか？
引き継ぎで一番に浮かぶのがドキュメント作成。これの問題点は
- ドキュメントにまとめることができるのは単純作業が多い
- システム図やクラス図といった図を作ると、以後メンテナンスコストが発生してしまうので仕事が増える
- たくさんの知識をまとめてもすぐ覚えられないし、あとで見ることも少ない
などがある。どうも費用対効果が弱い気がする。
また、何を引き継げばいいかわからない問題もありえる。こういうときは、逆に「教えてほしいこと教えて」という謎な質問が発生して混乱を招く。これってとてもずるい質問で、「教えてほしいことってなんだろう？」って考えているうちにタイムリミットが訪れてしまう可能性が高まる。
前のプロジェクトメンバーから電話がたえない人をたまに見かけたが、それはお互いハッピーじゃない。
じゃぁどうすればいいんだろう？プロジェクトごとにメンバーが入れ替わり、働く場所も違ってくる仕事だったのでそんなことをよく考えた。すっきり仕事にけりをつける技術も、生きていくために必要な技術なんじゃないかなぁなんて。
引き継ぎをしない作戦
人の入れ替わりで苦労する現場の場合は、引き継ぎが極力発生しない方法を色々考えた。以下はそんな中でもけっこううまくいった案になる。
例えば、全部のPCには全員がログインできるようにしたり（今考えるとセキュリティ的な問題とかはあるかもしれないが、会社のPCにプライベートな情報が入っているはずはない、とか特定の作業は個人を特定出来るようにするとかはしていたからセーフかな？）、すべての情報を簡単にアクセスできる何かに蓄積することで、個人に暗黙知がのこらないようにする作戦。
前者は何かと便利で、「全員がログインできる」になった途端に、情報をローカルに置かなくなる傾向があった。後者にはWikiとかRedmineのようなトラッキングシステムが有効で、あとは情報が漏れない/勝手に貯まるプロセスを作ればある程度防げることがわかった。引き継がないためのプロセスを定義し、プロセスごと引き継ぐようにすればやることもやる内容もうまく引き継げる。
さらに、仕事の終わりに引き継ぎをさせるのではなく、仕事のはじめに引き継ぎをするのも結構有効。ソースコードやプロセスを学ぶためには一緒にやるのが一番早い。ペアプロやペア運用はそういった効果があった。はじめに教えることで、早く覚えようとがんばるモチベーションが生まれたり、後でやるよりも期限で困ることも少ない。
引き継ぎが意味すること
引き継ぎしやすい仕組みというのは、逆に言えば歯車と一緒で取り替えがきくという意味も生まれる。これだとやる側はモチベーションは生まれないかもしれないなぁと最近思う。
効率良くできることはするとして、個性を発揮するところはあってもいい気がする。例えば引き継げるような作業以外の部分は各個人のスキルに委ねるとか。そのスキルを周囲に伝搬できるのであれば伝搬し、そういう人はリスペクトされるような存在になっていくようなイメージ。社会人としても、人としても。
ソフトウェア開発はクリエイティブな仕事だけど、組織で働いていると残念ながらそうでもない作業も生まれてくる。チームやサービスを育てなければならない我慢の時期もあるし、新入社員育成など定期的なイベントは毎年やってくる。そこらへんをうまいことマネジメントできないかが最近のテーマでもある。
手離れのよい仕事
手離れのよい仕事をする必要があって、こういった仕事の仕方を考えるようになったけど、最後まできっちり仕事をすることは難しい。自分も悩むことが多いし、これを相手に伝えることは更に難しい。理解してくれない人もいるし、「俺はできている」と言う自分視点しか考えない人も少なくない。
ただ、手離れのよい仕事ができない人を見ていて思うのは、最期まできっちり仕事ができないという評判はすぐに広がるし、いつかはその人に返っていくんじゃないかなぁという出来事もよく見かける。去り際ってその人のパーソナリティがでるよね。
やっぱりみんなそういう人と一緒に働きたくないんだろうねって思うと、自分自身もそうならないように気をつけないとなぁって思う。手離れが悪い仕事は無責任ってことかもしれない。逆に手離れのよい仕事って、いい仕事のことをさすのかもしれない。
旅と子育てとアジャイルコーチのブログ「世界」 