現在、僕が仕事で携わっている案件のタスクの中に「自部署の業務を他部署へ引き継ぐ」というものがあります。
想像以上に引き継ぐ業務が大変なのと、自分自身手探りでこの仕事をしていることから、仕事で学んだことをアウトプットしていきたいと思います。
自分と同じように「自部署の業務を他部署へ引き継ぐ」プロジェクトを担当されている方の参考になれば嬉しいです。
はじめに：だやの業務について
ITコンサルタントとして、お客様先（＝事業会社）に常駐して業務をしています。
だやの業務：システム開発案件のPMO
僕が所属している部署は、半年後にリリースするシステムの開発管理を担当しています。
主な業務は、お客様へのプロジェクト進捗報告やQAやり取り、そのための資料作成や打ち合わせです。
システムのアプリやインフラの開発はベンダーに委託しており、実際に手を動かしてプロダクトを開発しているわけではありません。
他部署へ引き継ごうとしていること：開発案件リリース後の保守対応
僕が所属している部署は、どちらかというと開発がメインの部署なので、開発が完了したらそれを保守担当の部署へ引継ぎすることになります。
保守担当の方たちに向けて「どんなシステムを開発してきたのか」「保守の方にこれからどういうことを対応していただくのか」を説明し、作成した資産やドキュメントを引継ぎしていきます。
開発部署⇒保守部署への引継ぎをしておりますが、これがなかなか難しいです(笑)
開発から保守への引継ぎの方法
マイルストーンと紐づけてタスクを書き出す
引継ぎ先が対応しなければならないタスクを、マイルストーンと紐づけて書き出します。
例えば「〇月に××社向けのシステムをリリースする」というマイルストーンがあるのであれば、〇月までに以下のタスクを引継ぎする必要があります。
・障害、問い合わせ対応など業務タスク
・予防保守などシステムタスク
自社で開発したシステムをお客様が利用開始した後、お客様からの問い合わせや障害対応などが発生することが予想されます。障害を起こさないために、パッチ適用など予防保守もする必要があります。
ポイントは「引き継ぐかどうか」は気にせず、まずは考えられるタスクをすべて洗いだしてみること。
「他にも引継ぎが必要なタスクがあるのではないか」という指摘を回避する意味でも、まずは考えられるタスクを書き出します。
書き出したタスクの中から何を引き継ぎたいかを整理する
洗い出したタスクのうち、引継ぎ先にお願いしたいタスクは何になるのでしょうか。
全てを引き継ぐのか、一部タスクを引き継ぐのかでも変わってきます。
・業務に必要なドキュメントの作成からお願いするのか
・手順は引継ぎ元ですでに作成済みだから作業だけをして欲しいのか
上記のような観点で、引継ぎしたいタスクのスコープを明確にします。
引き継ぎ開始
プロジェクトタスクの全量を確認し、その中でも引継ぎ先に担当して欲しいタスクを洗い出せたら、引き継いだタスクを保守に引き継いでいきます。
主な引継ぎ手順は下記の通りです。
①引き継ぎたい資料を引継ぎ先に連携し、読み込みをしてもらう
②引継ぎ内容を説明するための勉強会を開催する
③①、②の中で出てきたQAのやり取りをする
③について補足をすると、引継ぎ先は①で連携された資料を読み込んでみたり、②で打ち合わせをした結果、「ここがよくわからない」「これってどういうこと？」みたいな疑問が湧いてくると思います。
「引継ぎ先が引き継がれた内容を確認する中で生じた疑問点をフォローする」イメージです。
引継ぎの難しいところ
他部署への引継ぎをしていく中で、自分が難しいと感じていることを記します。
自分が作成してないプロダクトの説明が求められること
自分の今のポジションはITコンサルタントであり、実際にソースコードを書いてシステムを開発している立場ではありません。
そのため、システムの細かい内容について熟知しているわけでもないのです。
とはいえ、「ベンダーが開発したものなので委託している僕たちは何も知りません」という責任回避は許されません。
・他部署に開発したものを説明するための資料作成
・資料作成するためにベンダーが作成した設計書の読み込み
こうした準備をしたうえで、引継ぎ先と引継ぎの打ち合わせをすることになります。
とはいえ、「過去に起きた障害と同じ障害が発生しないように考慮がなされているか」「テーブルデータは削除する運用はあるのか」「APサーバの運用の仕方は現行サーバと同じ運用で問題ないか」など、細かい仕様まで全部把握できているわけではありません。
引き継ぎする部署に０から説明すること
引き継がれる側は引継ぎされるシステムについて知らないことから、0ベースで説明をして、理解をしてもらうことになります。
理想は「小学生でも理解できるように具体的に話すこと」です。
ただ、それをするためには自分自身、引き継ぐシステムのことを深く理解することが求められます。
QA対応含めて、引継ぎ先には丁寧な対応をしていきます。
開発側で作成したドキュメントの場所を引継ぎ先に連携して「こういうことをして欲しいから後はよろしくね～」とはできないのです。
自分にはない目線で質問が飛んでくること
システム開発のPMOとして案件に携わっていることから、説明する内容や知っている知識が開発目線になりがちです。
引き継がれる保守チームの方は、開発チームの僕たちが普段携わらない保守運用をしている方たちです。
障害対応や問い合わせ対応、予防保守の対応それぞれ、保守運用目線で質問が飛んできます。
正直、「そんなこと知らないわ」みたいな内容も質問が飛んでくるので、そういう内容の質問を頂いた場合はQA表などに起票し、後日改めて確認し回答する形になります。
ポイント：関係部署との事前調整を怠らない
・「キーマンは何を求めているのか」を考えて仕事する
・関係部署への根回しは事前にきちんと行う何かと社内調整の業務が多い中でこのツイートを発見。
大変勉強になりました。 https://t.co/wKeToL5KNt— だや (@__usadaya__) July 14, 2023
自分たちの思いを一方的に伝えるような、独りよがりな仕事の進め方はダメです。
「上司はどのような形で引継ぎタスクを進めて欲しいのか」「引継ぎ先の部署が何を求めているか」を意識しながら仕事をする必要があります。
今回経験した引継ぎ業務で、僕はたくさん失敗もしています。
もう一度、同じ業務をするなら次のようなアクションは絶対にします。
・上司と「引継ぎの進め方」「何を引継ぎタスクとするのか」を認識合わせする
・引継ぎ先部署がタスクを引継ぎされるにあたり気にしているポイントをヒアリングする
ITコンサルタントはたくさんの案件を抱えており、やることがたくさんあります。少しでも効率よく仕事を勧められるように、工夫して引継ぎ業務も進めていきたいです。
まとめ
今回は「他部署への引継ぎってどうやるの？【開発チームから保守チームへの引継ぎ】」というテーマで記事を書きました。
他部署へ引継ぎをするときのステップは下記の通りであることを学びました。
①マイルストーンと紐づけてプロジェクトのタスク全量を洗い出す
②①で洗い出したタスクの中から、引継ぎ先に引き継ぐタスクを明確にする
③引継ぎを開始する
タスクを洗い出すときのポイントは、マイルストーンと紐づけること。（①の部分ですね）
いきなり思いつくままに粒粒のタスクを洗い出すのではなく、「UAT」「リリース」「クライテリア」など「各マイルストーンまでに何をしないといけないのか」考えながらタスクを洗い出すと抜け漏れが減ります。
自分と同じように、他部署へタスクの引継ぎをしようとしている方、引継ぎの仕方に困っている方の参考になれば嬉しいです。
今回は以上です。
コメント