イベント・ニュース

情シス部門での業務引き継ぎノウハウ

Written by aki(あき)

ネットワークエンジニア
大手Nierでネットワークエンジニアとして最前線で戦う傍ら、個人運営のサイト「ネットワークエンジニアを目指して」を運営し、読者を「ネットワークトラブルに恐れることなく立ち向かえるネットワークエンジニア」へと導くことを信条に、ネットワーク技術の解説と自身のノウハウを広めている。著書に「見てわかるTCP/IP」など。Twitter:itbook

仕事の引継ぎについて


簡単なようで実際にやってみると意外に難しいことが仕事の引継ぎです。
特に情シスの引き継ぎは、会社の根幹システムの情報を引き継ぐことになるため、慎重に実施する必要があります。

私も過去に何度か引継ぎをする立場も、引き継がれる立場も経験がありますが、どうしても引き継ぎに漏れや認識齟齬が発生してしまいます。
その度に「確実に次の担当者に引き継ぐにはどうすればよいんだろう?」と反省することしきりでした。仕事が出来る人ほど引継ぎが抜群にうまいですし、後任がトラブルに見舞われるのは、前任者の引継ぎが間違いなく悪いとも言えます。

そこで今回は情シスでの引き継ぎ業務ノウハウについて書いてみたいと思います。ぜひ実際に引き継ぎをするときに参考にしていただければ幸いです。

情シスの引き継ぎ

情シスで行われる引き継ぎには次のようなものがあります。

* 担当者の交代による引き継ぎ
* システムの保守ベンダー変更による引き継ぎ
* 情シス業務を外部ベンダーにアウトソースすることによる引き継ぎ

まずは現状確認


引き継ぎを行う前に、漏れを無くすために現状の確認から始める必要があります。確認は次のような項目に沿って行います。

関係者の洗い出し

どのような体制で業務を行っているのかを洗い出します。
もちろん社内だけでなく、社外の関係者やその連絡先も洗い出しておきます。

ドキュメントの洗い出し

現在、どのようなドキュメントがあるのかを洗い出します。
ファイルがどこに保管されているのかも洗い出しておきます。

ドキュメント例
* ネットワーク論理構成図
* ネットワーク物理構成図
* ポート収容表
* IPアドレス一覧
* ネットワーク設計書
* サーバ設定一覧
* セキュリティポリシー
* ソフトウェア構成図
* データベース設計書
* アプリケーション設計書
* 機能仕様書
* 操作マニュアル
* 保守契約一覧
* 障害時対応マニュアル
* その他

業務内容の洗い出し

仕事の進め方や進捗状況など、ドキュメントに残らない内容も漏れなく引き継ぐ必要があります。
通常業務はもちろんですが、「目に見えない経験(暗黙知)」の部分もしっかり引き継ぎましょう。「あの人は~な性格だから、会議のときは~な感じで」とか、「このシステムは○○なクセがあるから、□□の方法で対処して」など、
ドキュメントに残らない暗黙知は意外に多く存在します。不具合の関係で特別な設定をしていたり、フロアの関係で一部のケーブルの配線状況が異なるなど、細かいことですが重要です。

引き継ぎ時にやってはいけないこと


引き継ぎの際に「やってはいけないこと」についても理解しておきましょう。
引き継ぎにはさまざまなパターンが存在しますが、ここで説明する「やってはいけないこと」はどのパターンの引き継ぎにも当てはまります。

「分からなかったら聞いて」

引き継ぎを口頭で済ませたり、簡単な引き継ぎで終わらせて、「分からなかったら聞いて」で済ませてしまうパターンです。
前任者は楽ですが、引き継がれる後任者にとっては迷惑でしかありません。聞きたいときに前任者がいなくなっていたり、聞いたときには前任者がすでに忘れてしまっている場合もあります。

文章だけの引き継ぎ

口頭で説明をしないで、引き継ぎ資料だけを渡して引き継ぎを終わらせてしまうパターンです。
前任者は、当然すべてを理解しているため、引き継ぎも簡単に終わらせてしまう傾向があるようです。しかし、引き継がれる方は、それが当たり前ではないことが多々あります。対面で会話しながら引き継ぎを行うと、前任者が「当然と思って記載しなかった内容」に関する質疑もでることがよくあります。必ず書面だけではなく、対面で引き継ぎを行うようにしましょう。

手順だけのドキュメント

「文章だけの引き継ぎ」よりも悪いパターンで、業務の概要や進め方などは引き継がず、手順だけを引き継ぐパターンです。
引き継ぎは手順だけではなく、その業務の目的や経緯、関連情報も含めて引きつがなければいけません。手順だけを引き継いた場合、業務変更があった場合に手順のどの部分を変更すればよいか分からなくなりますし、全体像を把握していないため手順変更の効率化もできません。

私もよく分からない

一番最悪なパターンです。
そもそも私もよく分からないので引き継げないというパターンです。この場合はたんに前任者が引き継ぎ業務から逃げているだけで、もっともやってはいけないパターンです。「よく分からないので頑張って!」という引き継ぎとは言えない引き継ぎをされた新任者は、次に引き継ぎをする場合も同様に「私もよく分からない」という理由で引き継ぎから逃げるという負のスパイラルで、ずっと引き継ぎが行われないなんてことにもなりかねません。
引き継ぎをされていなかったとしても、担当者の期間は業務をしているはずなので、しっかりと引き継ぎは行うようにしましょう。

引き継ぎの進め方

基本的な引き継ぎの進め方には、次のような流れになります。

業務内容の共有

どのような業務があるのかを、目的や経緯、関連情報も含めて共有します。
定型業務や今後の作業予定などがある場合、スケジュールを共有して、いつどのようなイベントがあるのかも含めて共有しておきます。
また、社内調整に手間の掛かる業務や事前準備に時間がかかるような業務については、効率的な社内の調整ノウハウや事前の段取り方法なども併せて共有しておきましょう。

管理しているシステムの説明

管理している社内システムについて説明します。システムに関するドキュメントが多い場合は、理解すべきポイントの概要を説明しつつ、どのドキュメントがどこに保存されているかを含めて説明しておきます。
また、システムのトラブル事例なども共有しておきます。過去にどのようなトラブルが発生したか、そしてどのような対応を行ったのかといった暗黙知になりがちな内容も忘れずに共有するようにします。

引き継ぎ書に記載する内容


引き継ぎ書には最低限次の内容を含めるようにしましょう。

* 業務概要
* 社内システム概要
* ドキュメント一覧
* 関係者一覧(社内、社外含む)
* 業務手順
* 現状の課題やトラブル内容

業務概要

大枠の業務概要を記載します。
あまり細かい内容は記載せずに、業務の目的や要件と作業内容などを記載します。特に「なぜその業務やシステムが存在するのか?」という業務の目的は必ず記載します。目的を理解していないと、今後どのように業務の改善やシステムの改修をしていけばよいのかが分からず、いつまでたっても課題を残したままになってしまうことも考えられます。

また、業務内容は次のように何らかの軸で分類して記載すると、引き継ぎを受ける側の理解が早くなります。

* 定型業務か非定型業務か
* 作業ボリュームが多いか少ないか
* 定期的な業務か臨時的な業務か
* 急ぎの業務か時間に余裕がある業務か

社内システム概要

社内システムの要件や概要を記載します。
詳細な内容というよりも、システムの要件や概要、導入目的など大枠を記載します。詳細な内容については別途ドキュメントの一覧を記載して、必要な時に何を見ればよいのかが分かるようにしておきます。特にシステム構築時のノウハウや、今後の改修予定、システムの課題など暗黙知になりがちな内容も記載しておきましょう。

関連者一覧(社内、社外含む)

業務に関連する関係者の一覧を記載します。
特に業務やシステムで分からないことがあったときに誰に確認すればよいのかは、不慣れな新任者にとってはありがたい情報です。関連者一覧には社内だけではなく、社外のベンダーの担当者なども記載しておきます。システムでトラブったときや、機器の仕様を確認したい場合などに重宝します。

業務手順

日々の業務手順を記載します。
特に定型的な業務は手順化されていることが多いため、手順は必ず共有しましょう。また、なぜその手順なのか、なぜその作業をしているのかということも含めて記載します。

現状の課題やトラブル内容

引き継ぎ時に残っている課題や、トラブルについても一覧化して記載します。
各課題には優先度や重要度が記載して、新任者が何から手を付ければよいのか分かるようにします。

泥臭い部分もしっかりと共有すること


関係者の正確やグループ内の派閥など、泥臭いけど重要な情報も共有することを忘れないように。
「あの人は知ったかぶりで全然分からないから質問するならこの人にすべき」とか「○○部長から承認をもらうためには、□□のように進めるとよい」などのポリティカルな情報は、新任者にとっては一般的な引き継ぎ事項よりも重要かもしれません。

仕事が出来る人は、今まで対応してきた内容や設定に関するTips的なことなど、ちょっとしたことをメモとして残しておいてくれます。
もしメモを残しているのであれば、それも引き継いでおきましょう。以前、ローカルにWikiをインストールして、何かあるたびにそこに書き残してくれている方がいました。引き継ぎ書と一緒にそのWikiも併せて引き継いで、「とりあえずWikiに残しておいたから、なんかあったらWikiを検索してみて」と言って去っていった凄腕の先輩もおりました。

また、ITスキルがない人に引き継ぐ場合は、勉強用にお勧め参考書やWebサイトなどを引き継ぎ時に共有するのもよいかもしれません。

まとめ


会社や情シスの業務内容によって、引き継ぐ内容は変わりますが、引き継ぎの基本的な内容について書いてみました。

今や社内システムが安定して稼働するかどうかは、会社の業務に大きく影響するようになりました。担当者が変わって、「社内システムのトラブルが多くなった」とか「情シスの業務が遅延している」といった問題が発生しないように、引き継ぎはしっかりと行うようにしましょう。去る者後を濁さずが基本です。

前任者は、「引継ぎが適当でも困るのは後任者さんだから適当でいいや」などとよからぬ考えが頭をよぎるかもしれません。遠足は家に着くまでが遠足なように、業務も引継ぎを終えるまでが業務ですからしっかりと作成しましょう。
逆に後任者さんも「こんな仕事引き継がれてないよぅ…」なんて泣きを見るのは自分ですので、引き継ぎ時には遠慮せずがんがん突っ込みを入れましょう。