ひとり情シスの退職と引き継ぎ（2/3）
本記事は全三回の内、第二回目(引継ぎ資料の作成)となります。
前回の記事はコチラからどうぞ。
では、第二回「引継ぎ資料の作成（スケジュールは作るもの。マニュアルは作ってもらうもの）」を始めていきます。
さて、スケジュールはMUSTとして、マニュアルは作らんの？と思うかもしれませんが、可能なものは作ります。ルーチンワークの作業とか。
スケジュールは
引き継ぎ日数 ＝ [引き継ぐ作業数] × [作業時間]+[講習時間] ± [バッファ]
で立てていきますが、新メンバーの作業時間は分からんので、マニュアルを作成して、ゴールまでの時間をざっくりで予測します。
が、引き継ぎ資料を作り始めて数日。
一部作業のマニュアル化が無理ゲーな事に気づく。
城作りに例えます。
１人目の社内SEとして入社した３年前。
そこから、オフィス移転にサービスリプレース、
絶えずスクラップ＆ビルドを繰り返し、増員・増床に耐え抜いた、我が城。
今日も難攻不落で豪華絢爛にそびえ立つ・・・
現実に帰って、冷静に第三者視点で見てみます。
・引き継ぎ先はアウトソーシング
何もかもが０からスタート。コミュニケーションも１から構築。
さっき声掛けて来た人、誰だっけ。このサービスについては、誰に聞けば良いんだ・・・。
・スタートアップ
風化する社内規定、優先されるオリジナルルール。
人の入れ替わり(担当者の変更)は、体感マッハ３。 ※当社比
・ひとり情シス
上長・同僚・部下 不在。頼れるモノは己の拳のみ。
襲い来る社内政治、繰り返すプランB。属人化は今日も順調です。
これはヤバい。イレギュラーが多すぎる。
トラップポイントや、困った時のセーフハウス。
目を瞑っていても、私は回避出来る（出来てない）。
が、
第三者から見れば忍者屋敷であり、ラビリンス。
The魔窟。
用意するはMAPとマスターキー
という事で、マニュアル化が無理そうなものは、
・出来る、出来ないの取捨選択
・プランBを発生させないための、仕組み化の徹底
・属人化している作業は、新メンバーに自分用のマニュアルを作ってもらう
形で進めていく事にします。
こちらは第三回の「いざOJT」にて書いていきます。
自分の言語で、自分が作ったマニュアルは忘れにくく、作業に対しての理解度が見える。
差違があれば、その都度こちらで訂正できるし。
とりま、私と相手、双方の認識を擦り合わせて、事故発生率を減らすのだ。
では、方向性は決まったので、ざくっとスケジュールを引いて
マニュアル作りに必要な資料を整えていきます。
用意するものは２つ。
１：全ての扉を開ける事が出来るマスターキー（Admin権限のあるID,PW）
２：MAP
マスターキーを作る
マスターキーとは、SaasやNW機器などのAdminID、PWを指します。
兎にも角にも、管理者としてログイン出来なければ作業になりません。
重箱の隅をつつく様に、一回だけ利用したサービスであっても残していきます。
今回引き継ぐ作業範囲は「インフラ／ファシリティ」、「各種SaaS」
インフラは固定なので問題なしですが、SaaSは情シスの一元管理ではなく、
「情シス」「情シス＋他部署」「情シス外（部署管理）」と分かれるため、
１：全SaaS一覧リストを作成
２：引き継ぐサービスのリスト＆アカウント表を作成
の順で進めていきます。
まずは全SaaS一覧リストの作成から。
ヒアリングとか無理ゲーなので、お金の流れ（ランニングコスト）と稟議から逆算して、サービスとID管理者（利用申請者）を割り出します。
会計データは間違いない。経理のSさん、ご協力ありがとうございました。
そこから情シスが持つデータと突合して、下図の様な形式でリスト化。
次にID管理者（稟議申請者）へ確認を取り、今後の管理と情シス対応範囲（上図のC列、D列）を相談して決めます。
最後に、上の様なフォーマットを作成、転記して担当範囲の管理者アカウント表を作成します。
MAPを作る
次にMAP。
これは作業における、ゴールまでの道筋が予測出来る資料を指します。
例えば探索型のロールプレイングゲーム。まずはMAPを開放しますよね。
ゼルダの伝説「ブレスオブザワイルド」とか、（分からない人にはすみません）多くの人はシーカータワーを起動してエリアMAPを開放してから、探索を始めると思います。
これを目指したい。
色々なルートがあるとしても、MAPを見ながらであれば、最終的にゴールにたどり着ける様に。
まず、OJTでAルートは教えます。
が、スキルやナレッジがある人は、APIとか私の知らない抜け道を使って、
Bルートを行くかもしれません。
はたまた、未開のCルートを開拓していく人もいるでしょう。（クオリティが下がらなければ良し）
いずれにせよ、自分に取って最善のルートを見つけ、必要なら自分のマニュアルとして作ってもらいます。
では、「インフラ、ファシリティ」「SaaSサービス」のMAP作成に取り掛かります。
インフラ、ファシリティのMAP
ざっくり
・全体図
・パラメータシート、最新のconfig
・基本設定手順書
の３つを用意します。
パラメータシート（※）は漏れが無い様に、緻密さ、正確さを重視して。
基本設定手順書はメーカーが作成した最新のものを。
※パラメータシートは自分が作るより、ナレッジやノウハウが詰まったベンダー謹製のフォーマットを利用した方が良いです。餅は餅屋。
最後に全体図。そもそも、これら資料は日常的には見ない資料です。
引き継いでも３日で頭から消えていることでしょう（自分比）。
が、必要になった時は大抵、障害が起きている時。
ピリピリする現場、襲い来るクレーム。平常心ではいられません。
ですので、パニック状態でも
・パッと見で全体図が分かる（＝障害報告の説明にも利用できる）
・各レイヤー資料へ即座にアクセス可能
を重視した全体図を目指しました。なので一般的な物理図や論理図とはちょっとズレます。tiripiri式はこんな感じ。
この図の下に、それぞれのアルファベットに合致したパス（各セクションの関連資料が格納されたフォルダパス）が記載してあり、クリックすると飛んでいく感じ。
SaaSのMAP
続いてSaaSサービスのMAP作成をやっていきます。
SaaSは
・他SaaSとのデータ連携可能
・アップデートに伴い、UIの変更が発生する
・標準機能に加え、APIを利用した操作がある
という特徴があります。
また、全機能を使っている訳ではなく、ビュッフェの様に使いたい機能のみ利用している事が殆ど。
ですので、更新、変更作業を行う時に、
・抜け、漏れが無い
・設計の土台を理解してもらう
事を目的として、フロー図と運用ルールの２つを用意します。
マニュアルについては、UIがコロコロ変わるし、サービス提供側が用意している＋いざとなれば、サポートサイトで聞ける ので作成しません。
フロー図
複数サービスを横断する、データ連携やフローに限定して作ります。
サービスの繋がりと、流れが分かるイメージ図であれば、ヨシ！
その上で、サービス毎の専用フォルダを作成し、各種資料（※）を格納していきます。（困ったらサービス毎のフォルダ内を探してね、の精神）
※「サービス説明資料」「契約資料（基本契約書、利用規約）」「API関連資料」等々・・・
運用ルール
どの機能を利用していて、どんな構成になっているか
が分かる様にします。
既存のルールを外れて齟齬が発生、統制が取れなくなる事態を防ぐ目的です。
例：弊社ではAttalacianの、”JIRA”と”Confluence”を利用しているので、運用ルールは以下の構成でConfluenceに載せてます。
・ライセンス、オプションの一覧
→ライセンスを貸与する社内・社外メンバーの条件や追加済みオプションの内訳
・コスト
→社外へのライセンス貸与時の見積作成用
・管理権限の一覧、付与ルール
→情シス以外のメンバーに貸与する、管理権限の一覧と付与ルール
・アクセス権限とセキュリティグループ一覧
→全社共通や役割毎に区切って作る。特に社外メンバーは隔離する形で。
・スペース、プロジェクトの管理ルール
→上記のアクセス権限を標準化させるための仕組み（スペース作成は情シスが行う、申請者には付与するセキュリティグループのみ指定してもらい、閲覧制限を徹底する、など。）
スケジュールを作る
という感じで、引き継ぎ資料としてマスターキーとMAP、それから定型化された作業のマニュアルを作りました。
最後に第一回で作成したマインドマップをベースに、引き継ぎチェックシートの作成＋引き継ぎ計画を立てます。
今回、引き継ぎ先としてお願いしたユナイトアンドグロウ様は、対応していただける範囲が広いけれども、一応優先度を
高（必達）・中（出来ればやって欲しい）・小（情報共有レベル）
として付け、OJT時間を入力。
それぞれの作業タイミング（入社作業＝月末、退社作業＝退職者の最終出社日）を加味して、Googleカレンダーへ登録し準備完了としました。
このOJT時間が甘すぎて、ちょっと大変だったのですが・・・
それはまた次回で。
ここまでお読み頂きありがとうございました。
この記事が気に入ったらサポートをしてみませんか？