プロジェクト途中の体制変更の事例

はじめに～プロジェクトで急な体制変更が起こった時にやること～

• 急な体制変更が起きた時はどうする？
  体制変更が起きた際には、業務の引継ぎや方針転換、これまでのプロジェクトの振り返りやノウハウの蓄積など様々な観点を考慮したうえで、プロジェクトのパフォーマンスを維持しつつ進行していく必要があります。
  状況によっては、体制変更が起きた背景も考慮して慎重な対応が求められるケースがあります。
  本記事では、急な体制変更が起きる背景やその時の具体的なステップ、タスクの進め方なども含めてPMOの観点を中心にご紹介していきます。
• プロジェクト概要
  このプロジェクトではクライアントとなる担当者が二人（Aさん、Bさんとします）おり、Aさんがプロジェクトから外れることとなりました。
  プロジェクトを進めている中で、何らかの事情により体制変更を余儀なくされるケースがごくまれに存在します。
  責任者がプロジェクトにおいて人間関係のトラブルにより離脱を余儀なくされたり、責任者本人の転職に伴う退職、あるいは続投が不可能になるほどの事故に巻き込まれることや様々な事態が考えられるでしょう。
  本来は責任者が不在になった場合でも円滑にプロジェクトは進行するように想定した運営が求められるものの、プロジェクトの全体の進行を鑑みて属人的な構造で運営せざるを得ないこともあります。
• PMOにおける体制変更時のノウハウ
  まずは体制変更を決めるキーパーソンと状況を共有し、関係がある人に残タスクや定常的に発生している業務などの引き継ぐべきことの収集を進めていきます。
  この時に残タスクや定常的な業務を表形式で整理していくと円滑に進められますし、簡潔な文言で背景をすぐに理解できるよう工夫することも必要でしょう。
• その他気を付けるべきポイントなど
  プロジェクトを全体で統括する人など、関係する人が多岐にわたるメンバーを体制変更する場合、関係する人に不安要素などは事前に収集しておく必要があります。
  また体制変更時を節目として振り返りを行うことで、収集した課題やリスクなども同様に表で管理していき、課題やリスクが顕在化するか？顕在化した場合は今後解決の見込みがあるか？解決されたか？といったことをタイムリーに監視していくことが必要でしょう。

体制変更における担当者変更のTips

体制変更を行う時にはどういった背景により起こるかは様々です。
ここではその背景として考えられる理由の一部を取り上げていきます。

• 別プロジェクトのひっ迫
  参画しているプロジェクトよりも影響度の大きいプロジェクトが難航していることから、ノウハウのある人材やマンパワーの増強が求められることがあります。
  背景は様々であるものの、難航している課題の解消のために一時的に離脱して、解決次第すぐに戻るケースもあれば、部門間で人員の調整を行ったうえで異動した人材がそのまま残るといったケースもあるでしょう。
  
• 担当者のキャリアアップ
  担当者がより多く人を巻き込む仕事をしてもらうために、別のプロジェクトに移ってもらうケースも存在します。
  こういった場合は、担当者は今後上位の立場で業務を進めることになるので同じ役割で戻る可能性は低いですが、代わりになる人材に引き継げるように調整するなど対応することが必要でしょう。
• 人間関係のトラブル
  ごくまれにですが、人間関係のトラブルやハラスメント（セクハラ・パワハラなど）により関係者を離脱させざるを得ないケースが存在します。
  このような場合はハラスメントを受けた人の精神的なケアを最優先して、ハラスメントをした人との接触を避けるなどの配慮が必要です。

体制変更のステップ

• 体制変更時期の調整
  体制変更の必要があるからと言ってすぐに体制変更に取り掛かるかといえば、そうではない場合があります。特にAさんは担当する分野に長く変わっていたこともあり、異動して頂くにあたって相応の準備が必要でした。
  具体的には以下の通りです。
  1. スタッフの増員時期の調整
     これまでAさんがほぼ主導となって運営してきた背景もあり、Aさんがもっていた作業をBさんだけでこなすことは困難でした。
     そこで社内で新たにスタッフをプロジェクトに加入させる必要があり、その人材の選定と加入時期の調整が必要で、新たに加入して頂くスタッフ（Dさん、Eさんとします）を迎え入れていくことになりました。
  2. 通達時期の調整
     通達時期を調整します。
     またプロジェクトの状況もめまぐるしく変わる中で、通達が難しいと判断して通達の時期を再調整することもあるでしょう。

• 体制変更の通達
  実際に体制変更を行う旨を担当者に伝えます。
  スムーズに体制変更ができるように、調整を進めます。
  異動する場合はどこに移るのか、その後の引継ぎのために必要な期間など関係者で調整を進めます。
  一般的には退職や異動などによる引継ぎ期間は1～2カ月程度ですが、異動する人の事情により期間は様々で、１週間もないケースも存在します。
  どうしても期間が足りない場合は、期間を延長ができるかどうか関係者で交渉することも視野に入れておく必要があるでしょう。
• 体制変更の実施
  体制変更の通達がなされ、今度は社員が入れ替わるフェーズに突入します。
  1. プロジェクトの残務処理
     通達が完了してから、限られた期間でできる業務を処理する必要があります。
     一部どうしても期間内に終えることができないものは、PMOとＢさんなど残されたメンバーで調整のうえでどこまで進めるかを調整していくことになります。
     業務によっては不都合が生じない程度の落としどころ（何をやるべきで、やるべきでないかなど）をすり合わせておくなども効果的でしょう。
     またこれらの決定事項はPMOで取りまとめおき、スムーズにプロジェクトが再開できるよう、タイムリーに共有していきます。
  2. プロジェクト再始動
     改めてプロジェクトを再開するフェーズです。
     事前にPMOとＢさんでやりとりを進めていたものの、改めてどういったタスクが残っているか、出席が必要な会議体なども整理していきます。
     この時は別チームの担当者の人（Ｆさんとします）とＢさんと、そしてPMOで連携しつつ進めていきました。
     なおタスクは膨大な数に上ったため差し迫ったタスクであるか、優先度が高いタスクであるかなども整理したうえで、責任者であるBさんの意思決定を段取り良くできるよう配慮することも必要でしょう。
     何を見て良いかわからない形で膨大な情報を突き付けられても、何を見て良いかわからず、ただでさえ限られている時間をさらに無駄にしてしまい、プロジェクトの進行に支障が出る恐れがあります。

タスクリストの一例

プロジェクトの振り返り

• KPTフレームワーク
  KPTのフレームワークとは、振り返りに使われるフレームワークの一つです。
  プロジェクトなどを振り返るにあたって、「Keep（うまくいっており継続すること）」「Problem（課題）」を分析し、具体的な改善策として「Try（今後検討すべきこと）」を整理する流れで実施されます。
  これらの頭文字であるK・P・TをとってKPTと呼ばれているのです。
  日本語では、「ケー・ピー・ティー」または「ケプト」と呼ぶこともあります。
  もともとシステム開発の領域で使われているフレームワークであり、現在は開発プロジェクト以外でも活用されていることもあり、広く使われている手法と言えるでしょう。
  体制が変更された段階であらためてプロジェクトについて振り返ってみると、タスクを依頼する関係者の間でいくつか課題がみられました。
  例えば管理リストの役割が曖昧であることや、関係者との相談の機会が少なく急ぎの課題に対応しづらいこと、要求されている仕様の理解に時間がかかるなどの課題が指摘されました。
  下記はその時に実施したKPTの振り返りを行った一例です。課題が発覚して、今後検討すべきことも出てきた一方で、うまくいっており今後も継続すべきこともでてきました。一般的な振り返りでは、問題となっていることばかり目立ってしまいそれらを修正することばかりに気を取られてしまいますが、KPTのフレームワークでは継続すべきことも漏らさず書き出すことができるため、今後のプロジェクト推進には役立つ手法と言えるでしょう。

KPTフレームワークによる抽出結果の一例

• KPT後の管理について
  KPTのフレームワークにより抽出した項目を実際のタスクとして書き出していきます。
  これらは先ほどのタスクリストに追記していき、実際に対策が進められているかどうかを定期的に確認します。
  プロジェクトを再始動する段階では、多くの課題が残されたまま始まってしまうこともあり、大量のタスクリストを管理することになります。
  また最終的な判断は限られた人で捌き切らなくてはならず、可能な限り簡潔な内容にする一方でどのようなトピックスのことかが思い出せるような内容でないと「これは何の話だ？」と読み手に混乱を与えてしまいます。
  このため、本件に限定される話ではありませんが、タスクリストでは余分な情報は可能な限り省きつつも、取り上げられた内容を一目で把握できるようにする工夫も必要でしょう。
• KPTによる振り返り後には…
  振り返りの作業はこれまでプロジェクトの中にたまっていた膿を出す作業でもあります。中には非常に困っていたことを思い返すことにもなるでしょう。
  そんな様々な感情を抱えていたことをスタッフ一同で振り返った後には、懇親会を開いてさらに社内のコミュニケーション活性化も見込めます。
  これまでのプロジェクトの中でつらかったことも笑い話として語り合うことができ、非常に有意義な機会になるでしょう。
  とはいえ人数が多くなるとそれだけスタッフの中でも様々な都合があり調整が大変になってしまうこともありますが、できるだけたくさんの人を集めて開催してみてはいかがでしょうか？

体制変更とナレッジの蓄積

担当者を変更するにあたっては、異動する人のナレッジを効果的に伝えていく必要があることから、密接な関係があります。ここではそういった問題について取り上げます。

• プロジェクトにおいて知見のある人は？
  Aさんはこれまで長く開発に関わってきており、クライアントの会社の中では深い知見のある方でした。
  Aさんのように知見のある人が抜けてしまったことに対して、ナレッジを改めて蓄積し直す領域は少なからず存在するでしょう。
  今回のプロジェクトでは、幸い長年プロジェクトに関わって頂いたGさんがナレッジの蓄積や技術の継承を買って出て頂いたおかげで、これらをスムーズに進められるようになりました。
  どうしても知見のある人がプロジェクト内でいない場合、異動することになったＡさんと改めて連携しつつ進めるか、過去にプロジェクトに参画していた経験のある方を改めて招集するといったことも検討する余地があります。
  いずれもどうにもならない場合、例えば異動する人が海外の部署へ移ることになるなどでタイムリーな連携が困難なケースがある場合は、上層部にエスカレーションしたうえで外部からノウハウをもつ人材を探すか、あるいは大幅にペースダウンすることは承知の上で地道に過去のノウハウを収集していくといったことになる可能性もあるでしょう。
• ナレッジの蓄積ができない理由は？
  これはものづくりの世界においてしばしば発生する課題ではありますが、自分にしかない技術を誰にでも実践できるよう標準化したうえで公開したり誰かに伝えたりしてしまうことで、自分の仕事がなくなってしまうのでは？と恐れてしまい、ナレッジの蓄積や技術の継承をしたがらないことがあります。
  確かに自分がこれまでやっていたことをやる必要がなくなることは、ビジネスでは死活問題であり、自分にしかない技術を守る権利は誰にでもあります。
  だからといっていつまでも技術を独り占めし続けることは、将来的に新しい技術に立場を脅かされることになりますし、技術を継承していくことでその技術をさらに発展させることができます。何より経験の浅い人材にとって、新しい技術を正しく理解し実践することは、本人のモチベーションアップにもつながるでしょう。
  また技術を誰にでもできるように標準化させたり、技術を継承できるような形で教えたりすることができる人材は、また新しい技術を身につけた時にそれらができ、優秀な人材として評価されていくことになります。その一方でナレッジを蓄積せず独り占めしようとする動きがあると、周囲から問題視されることもあります。

まとめ

体制変更は企業にとっては必要なものですが、関係する人に大きな負荷がかかる側面もあります。その一方で潜在的な課題/リスクやナレッジの蓄積について、改めて考える機会になる側面もあります。
体制変更を実施する時には、関係するメンバーに可能な限り影響が大きくならないように確実に進めつつ、節目としてそこまでの状況をしっかり振り返り、効率的にナレッジを蓄積できる仕組みづくりも進めていくことがPMOとして重要な責務なのでしょう。

 

【参考】

• 経理ドリブン「人事異動や転職の前に！経理担当者の引き継ぎに重要なポイント」
• SHIFTASIA「振り返りのフレームワーク「KPT法」とは｜そのメリットや進め方、実施のポイントについて」