AWSに関わる長期案件のプロジェクトマネージャーが引き継ぎ時に大事にしていること

PS課佐竹です。2年間携わっていたプロジェクトの引き継ぎを完了したため、その記念にブログを投稿したいと思います。今日は「プロジェクトマネージャ（PM）」という役割の引き継ぎに関して記載します。

はじめに
引き継ぎ開始時に大事にしていること
引き継ぎ期間中に大事にしていること
引き継ぎ後に大事にしていること
まとめ

はじめに

皆さん、「引き継ぎ」をしたことはありますか？引き継ぎとは、「携わっている案件(プロジェクト)の自分の役割を、同僚に入れ替わって以後対応してもらう」ことです。「相手にバトンを渡す」ようなことですね。この引き継ぎ、一見簡単そうに見えますが、実は引き継ぎは非常に難しいものです。社内でモメ事が起きたり、お客様からクレームを貰ったりする要因の一部に「引き継ぎがうまくいっていないこと」があげられたりもします。今回はこの「引き継ぎ」に注目してみたいと思います。

引き継ぎ開始時に大事にしていること

今回、私は2年の間プロジェクトマネージャとして携わっていたプロジェクトを同僚に引き継ぐことになりました。引き継ぎ期間は「3か月」です。長いように思われるでしょうが、この期間も重要な点となります。それでは早速、引き継ぎ時に大事にしていることを紹介していきます。

1-1. 連絡手段を共有する

まずは連絡手段です。連絡手段とは具体的には「メール」や「電話」などを指します。連絡手段は、お客様とをつなぐ生命線です。これをまずは最初に伝えます。昨今コミュニケーションツールが増えており、仕事に利用されるのは電話とメールだけではなくなりました。お客様とLINEするなんてこともあり得る状態です。以下、私が引き継ぎで過去経験したことを記載します。

電話：お客様によっては頻繁に利用されるが文字として残らないため、後で書き起こしをして認識合わせが必要なツール。また個人携帯を教えてしまうと業務時間外でも連絡がきてしまい使いどころを見極める必要がある。ただし感情に配慮する必要がある話や、詳細な説明が必要な物事を伝えるときは重宝する。お客様によっては電話がNGな場合もあり、その場合は緊急連絡先としてのみ電話が機能する場合もある。引き継ぎ時は、電話の利用頻度を伝え、かつお客様には後任担当者の電話番号を伝えるのが良い。後述するメールに記載する場合が多い
メール：最も代表的な連絡ツール。ただし昨今SNSの利用が増えてから利用頻度は下がっている傾向にある。メールは場合によっては「件名ルール」がある場合や「メーリスをCcに含むこと」など特殊な運用ルールが存在する。引き継ぎ時にはそのようなローカルルールがある場合は伝えることと、もしメーリングリストを利用している場合はその変更を行う必要がある。メーリングリストは、いきなり変更ではなく、後任担当者を追加した後、一定の期間をもって抜ける方が良い。メーリングリストはお客様ドメインの場合と、自社が払い出している場合があるので、前者の場合はお客様に依頼することになる
Slack：ここ最近、お客様のSlackに参加することが増えてきている。お客様管理のSlackではお客様管理のSlackに招待していただく必要がある。反対に、自社管理のSlackに参加している場合はそのチャンネルに後任担当者を招待する必要がある。Slackはワークスペースを自由に切り替える機能を有するので、複数のワークスペースに参加しても切り替えが楽なのが特徴
Backlog：サーバーワークスではBacklogを利用してプロジェクト管理をすることがデフォルトとなっているため、多くのやり取りはBacklogを介して行われる。電話、メール、Slackをお客様との連絡ツールとして利用することは稀である。Backlogには複数のプロジェクトを作成しているため、お客様によっては10以上のプロジェクトに参加する必要が出る場合がある。Backlogのプロジェクトは参加し続けていても特に問題がないため、明示的にお客様から消すように依頼されない限り、前任担当者はそのプロジェクトに残ることが多い。メールでくる更新通知はOFFにすることが可能
カスタマーポータル：お客様によってはプロジェクト管理や連絡手段に、独自のポータルサイトを利用している場合もある。この場合、後任担当者のためにカスタマーポータルの登録申請を出す必要があり、また前任担当者がカスタマーポータルから退出する申請を出す必要がある。カスタマーポータルはBacklogを主軸としているサーバーワークスではかなりイレギュラーな存在であるため、利用がある場合はその運用方法等も綿密に引き継ぎを行う必要がある
Facebook：稀にFacebookのメッセンジャ－で連絡を行うのが好きなお客様がいらっしゃるが、基本的にFacebookのメッセンジャーでは仕事の話や、何らかのコミットは避けるべきと考えている。これはそのやり取りが他人からは全く見えないためで、メールのように転送するようなこともないため、いつどこでコミットされたのか追いかけるのが大変なため。Facebookの引き継ぎを行うのではなく、引き継ぎを機に利用を終了した方が良い場合もあるため、引き継ぎ時に要相談となる

上記の通り、連絡手段1つとっても、考えることはとても多いものです。連絡手段はお客様と今後ひたすら使い続ける要の存在ですため、これを軸に引き継ぎを開始しています。

1-2. 会議体を共有する

長い間プロジェクトを進めていると、週次会議や月次会議がお客様と固定されていることが多いでしょう。前任担当者は、後任担当者をまずはこの会議体の中で紹介することになりますが、その会議には後任担当者が今後常に参加することになります。もし後任担当者が「毎週のXX曜日は別のプロジェクトの定例がある」場合、その曜日や時間の重複があるかどうか確認が必要です。お客様によっては何ヵ月も先まで会議室の予約が決まっている可能性もあり、お客様にスケジュールを調整頂くか、自分が調整するかという話になることがあります。この点を蔑ろにすると「1回目の定例に後任担当者が不在」となったり「無理やり来たので他のプロジェクトの定例を欠席してしまいクレームになった」ということが起き得ます。特に月次定例はステアリングコミッティと言われ、役職の高い方が参加されることも多いため、たかが定例と思わずしっかりとスケジュールを調整して挑みます。加えて引き継ぎの期間中は、常に後任担当者とこれらの会議に参加します。会議の参加によって、以下で説明します「体制図と役割」についてもキャッチアップが進みます。

補足すると、長く続く会議の中では「進行表」ができている場合が多いため、進行表をベースに打ち合わせの流れも事前に共有しておきます。

1-3. 体制図を作成して共有する

体制図を作成し、共有します。これも非常に重要な点となります。体制図を作成すると同時に、PMが主にどのような役割を持つものか説明を行います。このお客様では社内定例を毎週3種類、お客様との定例は毎週2種類、そして月次のステアリングコミッティが1回ありました。これら6回の中でPMが担う役割は1つではありません。会議進行のファシリテーターをする場合もあれば、議事録を取る係になる場合もありますし、改善提案を出していくという重要な役割を担うこともあります。そして可能であれば、ここ半年間程度の体制図の動きは合わせて図解し、共有しておいたほうが良いでしょう。具体的なところとしては「お客様の中で重要な異動や退職」や「社内での担当の入れ替え」があげられます。これらを把握しているか把握していないかで、PMとしての判断力が変わってきます。なお、運用プロジェクトの場合はお客様側で別途体制図や連絡網を記載されている場合がありますので、その点については修正を依頼しましょう。自社の修正は完了したものの、お客様側で変更がされてなく電話がかかってきた、というのは稀にある話です。

補足ですが、この体制図の説明時には「お客様の特徴」も合わせて伝えることがあります。例えば「何度か端数の計算誤差がありご指摘を頂いているので、特に見積もりの数字やAWS利用料の数字はPM側でも確認すること」であったり「お忙しい方なので、なかなか連絡が取れない事もあるため、定例会議の前後等で対面にてお話する機会を設けるようにして進めると良い」、「とても親身に教えてくださる方なので何か困ったらその方にまずは相談すると良い」など、プロジェクトを安定して続けるために必要なエッセンスとしてこれも可能な範囲で引き継ぎをします。

1-4. AWS環境構成図を作成し共有する

AWS環境構成図は必ず作成して引き継ぎ時に利用します。AWSのマネジメントコンソールを追いかければ、ある程度の構成は判明しますが、正直その作業は困難を極めます。特に構築途中の案件を引き継ぐ場合は、「現状」と「将来像」を合わせて構成図として用意し、そのギャップを説明しておく必要があります。AWSの案件で最も重要なのはこの環境構成図の存在有無だと私は確信しており、どのような案件でもAWS環境構成図を記載し引き継ぎ時に利用しています。サーバーワークスではこの構成図作成のツールにCacooを利用しており、今やCacooはAWS環境構成図作成のデファクトスタンダードとなっていると言っても過言ではないでしょう。さらに、同時に「お客様がAWSを利用し始めた背景・理由」や「それによって成し遂げたいこと」も共有しておくことで、お客様の想いも引き継ぎたいところです。お客様にとってAWSは「手段」ですので、それによって「成し遂げたい目標」を引き継いでいくことで今後のお客様への提案の角度が違ってきます。例えばコスト削減を求めているお客様にはReserved Instanceの提案が刺さることになります。

1-5. 契約もしくはSOW/スコープを共有する

プロジェクトマネージャの責務となる場合もあれば、ならない場合もあるのが、契約関係の取り決めです。しかし、間違いなく契約内容は把握しておく必要があります。営業担当を含め、契約条件の再把握をしたいところです。プロジェクトによってはSOW(作業範囲記述書)を取り交わしていることもありますので、SOWがある場合は読み合わせや質疑応答、過去の修正点についても共有を行います。また導入途中のお客様では「スコープ」の範囲を取り交わしていることがあります。スコープ範囲は検収を行うタイミングで非常に重要な資料となりますので、スコープがある場合はそれも確実に連携をします。

1-6. 利用しているサービスを共有する

ここ最近は、サーバーワークスもそうですが、様々なSaaSを組み合わせて利用するお客様も増えました。特に頻度が高いのは、先に記載したSlackに加えてGithubです。お客様管理のGithubリポジトリにコミット、なんてこともよく見る後景です。他にもGoogleのツールを利用することもありますし、WebEXやSkypeも登場することがあります。お客様によってはboxをご利用されている場合もあります。これらは「コミュニケーションツール」ではないため先の連絡手段には存在していませんでしたが、ステアリングコミッティの資料提出先がboxであったりもするため、利用しているサービスの把握は重要です。特にWeb会議システムはセットアップに初回手間取ります。それを回避するために前もって時間を取り、接続テストを行っておく必要があります。念のために記載しますと、パワーポイント、エクセル、ワードの利用有無も、サービスの1つとして確認しておきます。

1-7. 提出済資料を共有する

特に過去ステアリングコミッティで提示した資料を半年分か、場合によっては1年分全て読み合わせを行います。ステアリングコミッティではパワーポイントやpdfを利用して資料を提示することが大半なため、それらの資料を有効に活用します。またステアリングコミッティ用の資料は予め「引き継ぎを想定して」作成していくことが好ましいと考えています。私の場合は、ステアリングコミッティのすべての資料に必ず「その時の体制図」を入れています。そうすることによって、その当時のステアリングコミッティで話題になっていることを今現在の誰が理解しているのか、ということが判別できるためです。長期のプロジェクトとなると、自社メンバーも入れ替えが何度か発生することもあるでしょう。それに備え、体制図を常に挟むことは有用です。なおAWS構成図も定期的に提示することで、お客様が歩んできたAWSの歴史が把握できます。特に「過去一度でも使ったことがあるサービスかどうかを把握すること」はPMをする上で重要なポイントとなります。

引き継ぎ期間中に大事にしていること

ここまでは引き継ぎ開始時に大事にしていること、を記載しました。次に引き継ぎ期間中に大事にしている点について記載いたします。

2-1. ステアリングコミッティで組織の厚みを見せる

具体的には、ステアリングコミッティで後任担当者を紹介するタイミングで、普段来ない上司や役員に参加して貰うようにします。さらに可能であれば、前任担当者がいなくなった直後のステコミでも、同様に上司や役員が参加することで、お客様に「安心感」を与えることができます。一時的に人が増えたことにより、案外お客様はそれに対して安心されるものです。また実際問題、こういう場合に不安なのは後任担当者であったりもするのですが、その不安がお客様にも伝わってしまうことで、お客様の不安を煽ってしまうこともあります。それを避けるためにも、このような重要な場面では上司や役員のサポートを行う調整をして挑みます。

2-2. 引き継ぎ期間に余裕を持つ

前任担当者の後のスケジュールを重視するあまり、引き継ぎを強制的に短期間で終わらすことはよくありません。特に長い案件は、それに沿って長い引き継ぎ期間が必要です。今回は「四半期」を目安に3ヵ月間の引き継ぎ期間を設けました。3ヵ月あれば凡そのイベントは一周するため「引き継ぎの漏れ」はかなりの確立で予防できます。また3ヵ月あればステアリングコミッティも3回経験ができます。3回経験すれば引き継ぎに十分な経験と言えると考えています。ただし、引き継ぎ期間が長いということは、プロジェクトマネージャがその間にダブルコストとなってしまうので、プロジェクトの利益を圧迫する場合があります。引き継ぎ期間を無意味に長くする必要はないため、プロジェクトにより適切な期間を選択してください。ここで伝えたかったのは「短期間で無理に終わらせたりしない」ということです。

2-3. 過去の経緯を大事にする

会社によって文化は異なります。その文化を理解するには時間を要することが大半でしょう。お客様の文化を理解していないために、良かれと思ったやったことがクレームに繋がってしまう、ということも場合によっては起き得ます。ある意味、この文化の理解が引き継ぎの醍醐味、と言っても良いかもしれません。例えば「電話NG文化」という会社も存在します。そういう会社に良かれと思って電話を頻繁にかけるのはクレームに繋がる行為となってしまいます。このようなことが起きないように、過去クレームを頂いた障害報告レポートがあればそれを共有しておきます。サーバーワークスでは、障害やクレームが発生した場合は障害報告のレポートを提出することを会社のルールとして定めていますが、引き継ぎでもこのレポートは有効に機能します。

引き継ぎ後に大事にしていること

最後に、引き継ぎをした後にアフターフォローとして大事にしていることを記載します。

3-1. 現場メンバーが後任担当者のキャッチアップに協力する

PMの立場のメンバーが引き継ぎとなった場合、どれだけ綿密に引き継ぎをしたとしてもPMは間違いなく現場メンバーより知識量が劣ります。しかしPMは最終的には現場メンバーを引っ張っていく存在にならなくてはなりません。そこにPMが到達するまでの間は、現場メンバーによるフォローが不可欠です。前任担当者は、後任担当者が現場メンバーとうまく連携できるよう、チームビルディングにも配慮する必要があります。

3-2. 引き継ぎが終わった後も連絡が取れるようにする

引き継ぎを完了した後も、場合によっては前任担当者にしか判断できない自体が起こり得ます。そのような場合があっても良いように引き継ぎを完了した後も、2週間から1ヶ月程度は連絡を取り合えるようにしておきます。サーバーワークスではSlackを利用し業務を行っておりますので、引き継ぎ完了した後も適宜Slackを利用して連絡を取り合います。Slackは過去のやり取りを検索することもできるため、当時のやり取りをサルベージして後任担当者に連携するのにも適しています。

3-3. 任せたら関わり過ぎない

お客様によっては、前任担当者に引き続きメールをしてくる方もいらっしゃいますが、そのような場合でも前任担当者は後任担当者に連携をし、後任担当者からメールの返信をしてもらうべきです。前任担当者は後任担当者に引き継ぎを終え、仕事を任せたのですから、後任を信頼して任せるのが礼儀だと考えます。引き継ぎ後も、変に前任担当者がでしゃばってしまうと「いつ引き継ぎが完了したか」の判別も難しくなってしまいますので、「この日に引き継ぎを完了とする」と決めたらそれを守ります。今回は「ステアリングコミッティを後任担当者のみで実施する」ことをポイントとしていましたので、それをもって引き継ぎを完了としました。

まとめ

いかがでしたでしょうか。
以上がサーバーワークスのプロジェクトマネージャがPJの引き継ぎ時に大事にしていることでした。
私はIT業界に10年ほど在籍しているのですが、引き継ぎというのはいつでも難しいと感じます。引き継ぎがうまくいかないことで、先に書いた通りクレームを頂くことはもちろん、社内の空気を悪くしてしまう危険もあります。引き継ぎをうまく実行することができればこのようなリスクを回避できますので、上記の内容を参考に文化を形成して頂ければ幸いです。