システム・業務の引継ぎを考える

システムを引き継ぐにあたって受け渡す側、受け取る側双方への心得、作業などを考えてみる。

期間的には、月次で発生する出来事を一巡できるように、最低でも1ヶ月、欲を言えば3ヶ月程度の期間があれば、満足できる引き継ぎができると思うが、経験上、そんな余裕のある引き継ぎなどしたことが無い。
（たいてい「辞めます」からの大慌てでの引き継ぎになるから。そもそも属人化しないようにしていれば、大慌てで引き継ぐ必要ないのだが、会社によって都合はいろいろある。）

引き継ぎ業務は大事

そんなことはわかっている。それなのにとかく後回しにされがちな引き継ぎ業務。渡す側は次の業務に気持ちが行っているだろうし、受け取る側にとっては後ろ向きで気が重い作業なので、心理的な面からいってもお互いギャップがありながら敬遠する方向で一致してしまう。どう乗り越えるかというところだが、現場が盛り上がっている中で頑張る人は多いが、こういう局面で頑張れる人はそう多くはない。真にプロフェッショナルかどうかが問われるところだと思う。

引き継ぎ資料に書くべき内容

渡す側には引き継ぎ資料の作成しなければならない。とはいっても、マニュアルなどが予め用意されていれば問題はないが、期間的な成約で受け渡す側が資料を用意する余裕も無いことがあり、受け取る側で作成することもある。受け取る側の負荷は高くなるが、その方が理解も深まるのでむしろメリットは大きいかもしれない。
どのような構成にするのかは、システムや業務によってブラッシュアップが必要だが、一例としてまとめるようにしている。

１．概要・業務の目的
　何を目的として作られたシステム・業務なのか。まずこれを端的に伝える。
　受け取る側が手順だけ引き継がれた場合、後々の作業者が問題点や改善点に気づけなくなる。

２．システム環境
　使用言語・環境
　サーバ一覧
　バージョン管理

　ほぼ定型だし一箇所にまとめてあるといざという時便利なのだが、担当者の頭の中に入ってるからか、わりと少ない。
　

３．資料、作業手順関連
　設計書やネットワーク図、テーブル定義
　開発環境構築手順
　本番環境リリース手順
　サーバやDBへのアクセス手順
　定期・非定期作業の手順
　
　手順だけでなく作業の意味・目的も記載する。

■連携システム
　相手先のシステム名、管理部署、連携内容や連携方法などを一覧化しておく。

■保守・運用関連
　監視や運用作業など、外部委託している場合は、連絡先を記載。
　契約によって対応可能な作業とできない作業があるので一覧化しておく。
　

■関連会社・部署一覧
　システム利用しているユーザ会社・部署、連携システムや保守など外部の相手先のシステム名システムだったら氏名や連絡先。最近であれば、電話、メールのほかSkypeやslackなどのチャットツールだったりする場合もあるので、連絡方法も明記しておくとよいかも。

■その他
　システム特有、業務特有の注意点や備忘録などがあると、受け取る側の後々の助けになってわりと感謝される。
（逆に何もないと、「何やってたんだ、あいつ」と言われることも。。）

引き継ぐときに書こうとしても、定例化しすぎて無意識にやっている作業は深掘りができなくなっているので、常日頃からメモを書き残しておくと吉。

質問する内容をどう探るか

受け取る側はわからないことを質問する力が必要。何がわからないことなのかがわからなかったり、質問することへの羞恥心があったり、心理的な束縛があるかもしれないが、後々の自分のためにもそこを乗り越えて質問していく。

可能であれば、元の担当者がいる間に一連の作業をやっておくこと。引き継ぎ資料に記載されないことが必ず出てくる。

また、引き継ぎ資料を通して、自分で図を書くのも効果的。
少なくともこのあたりは頭に入れておきたい。
・ビジネスフロー　→　収益構造は？今後の課題は？
・システム全体像　→　連携システムの構成は？クリティカルなのはどのポイント？
・データ構造　　　→　ER図はあるか？構成はどうなっているのか？

このあたりをこなしておけば、質問がないということはないはず。