内容の薄いマニュアルを残す前任者は、後任者への配慮が欠けている - 社会を変化させる社会心理論・組織心理論の考察記
うーん。環境が整っているにも関わらずって事であればそうかもね。でも現実の社会では引き継ぎ時間なんてほぼ取られないし、そのための準備期間もほとんどもらえない。下手すりゃ異動前から準備に入らされる始末。
2015/05/07 09:49
よんだ。
内容についての意見はコメント通りなんですが、気になるのは、ブコメの方。
特に「マニュアルなんて自分がやっている間に自然と準備されて然るべき」って意見。
まず、私は一世代（数世代？）前の技術者なので、例えばサーバ立上げなんてkickstart書いとけば別に起動時のキックのみで何台でもどんどんいけるし、その後の設定も数発のスクリプトを実行すれば、フロントやミドルあたりは手間いらずじゃねーか、みたいな人間です。
そういう人間ですと、マニュアルがないわけではありませんが、どこからマニュアルとすべきか、という問題が残ります。
サーバの実装からでよいのか、ミドルレベルの設定からとすべきか、いやいや、選定根拠から始まり、評価結果、ヒストリー等、ありとあらゆることをマニュアルにて随時追記し説明すべきなのか、等。
私の場合、大抵の作業履歴はEvernoteとdropbox内のファイルに残っている。
新しい技術を試す時も、すべて手順を残しているし、というか、SSH経由の作業なんぞログをとって、手続きに沿って、過去の手順のブロックを差し替えながら新しい手順を作るみたいな。
さて、このような作業は断片的な情報の集まりで、この断片だけで理解できるのかと問われるとそうではないでしょう。
おそらくはこのアカウントごと譲ったとしても、渡された側は、「は？」となるでしょうし、この私流の秘伝マニュアルは相手にとってのマニュアルとは言えないでしょう。
いや、私のは比較的丁寧だと思いますよ。
手順毎にコマンドから、必要に応じて参照リンクや関連情報もまとめてあるので、おそらくそこらへんの本よりも私のメモの方が詳しいし、細かい設定の意味まで書かれていますからね。
（そしてたいていはコピペで行くように整形済み）
こういう話をすると、技術系だからだろ、的な声も聞こえてきそうだが、そんなことはないでしょう。
レジ打ちにしても、在庫管理にしても、それぞれ特徴的な作業や特殊な操作はあるでしょうし、経験者にはわかっても未経験者や経歴が大きく異なると理解できないようなこともあるでしょう。
いくら自分が理解できるマニュアルや手順が存在しても、相手がそれをそのまま理解できるとは限りませんし、理解できない＝相手が悪いわけでもないでしょう。
結局のところ、引き継ぎを行うというのは、まずは相手を知る必要があるのだと思います。
誰に何を引き継ぐのか。
その相手は、どの程度この業務や関連する知識を有しており、この作業を理解してもらうにあたり、作業の説明で事足りるのか、それとも前提知識から入るべきなのか、すべては相手がわかってから段取りを整えるべきなのだと思います。
当然、日常業務をドキュメント化しておくことは重要で、説明するにも自分が正しい内容を把握し、もれなく説明できないと意味はありません。
ただ、引き継ぎというのは、あくまでも相手に理解してもらい、業務を問題なく新しい担当者に移行することが目的ですから、極論言えば、事前準備が不足しているか否かは、引き継ぐ時点で上司と合意すべき条件に過ぎず、成功・失敗の要因にはならないかと思います。
この事を引き継ぐ担当者、それを管理する上司、引き継がれる側、そしてその業務に関連する周囲の人間のすべての関係者が理解できれば、だいぶトラブルから離れることはできるのだと思います。
ですから、ブコメにあるような、うまくいかないのは日ごろの準備が悪いとか、時間が不足するような準備が必要とか段取り悪すぎとかいう意見は、相手により準備するというもっとも重要な部分を見落としているのでは？と感じます。
当然、スーパーな人はその程度の事をすべてパーフェクトに熟したうえで、おっしゃられている可能性もありますが、世の中、いろいろな条件がありますからね。
その点は理解してあげてもよいのではないかとも思います。
