「あの人がいないと、今日のリリース判定ができない」
「このソースコードの仕様は、〇〇さんに聞かないと誰も分からない」

あなたのチームで、こんな会話が日常茶飯事になっていませんか？

優秀な「シゴデキ（仕事ができる人）」に依存し、その人が抜けた瞬間に全ての仕事がストップしてしまう──これは、「勝てるチーム」としての前提条件が整っていない「属人化」の状態です。

そして属人化しているチームは、遅かれ早かれ崩壊の道を辿ります。

なぜ、優秀な個人がいながらチームは崩壊へと向かうのか。PMOはどう介入し、属人化という「呪縛」を解いていくべきなのか。

シリーズ第2回となる今回は、個人の経験知を「組織の共有知」へと変換し、誰が欠けても揺るがない最強のチームを作るための「仕組み化のハック」を公開します。

株式会社office Root（オフィスルート）
代表取締役社長
甲州　潤（こうしゅうじゅん）

国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』（‎ビジネス教育出版社）

ギクッとしたら赤信号。あなたのチームの崩壊が始まるサイン

「現状で仕事はしっかり回っているし、特に誰も困っていないから自分には関係ない」

こう思う読者の方もいるかもしれません。ですが実際は、この「“現状は”うまく回っている」「“現状は”誰も困ってないから大丈夫」という“現状”に満足しているチームにこそ、崩壊のサインが隠れていることが多いです。

詳細に入る前に、まずはどのような状況が「属人化」なのか、改めて確認しておきましょう。

＜属人化の二つのパターン＞

属人化には、大きく分けて以下の二つのパターンがあります。

どの属人化のパターンでも、それぞれのシゴデキメンバーが業務をしっかり「こなせている」間は、チームとして成果が出ているように見えるので、特に問題がないように感じます。

しかし、その「シゴデキ」が体調不良で急に休んだり、退職したりするとどうでしょうか？あなたのチームは、このシゴデキがいなくなったとしても、プロジェクトを遂行できるでしょうか？

ここでギクッとした場合、あなたのチームは、崩壊の崖へと落ちる一歩手前で踏みとどまっている状態にあります。誰もその人が何をやっていたのか、どう進めていたのかを把握しておらず、昨日まで動いていたプロジェクトが突然ストップしてしまう──これは、崩壊チームの典型的な姿です。

仕事の体系化ができないチームは、遅かれ早かれ崩壊する

崩壊チームの致命的な欠点は「仕事の体系化」を疎かにしている点にあります。

本来、業務は抽象化され、分類されるべきものです。
「Aというパターンならこの手順」「Bならこの処理」という、チームメンバー全員に通じる共通言語が必要です。

しかし崩壊チームの場合、仕事の体系化がきちんとされないまま進んでいくため、「A社は◯◯で対応」「B社は△△で対応」と、全てが個別対応としてまとめられてしまいます。

その結果、「10社あれば10の個別対応がある」というような、再現性のない非効率な状態に陥ります。

このように、仕事が体系化されない状態でプロジェクトが進んでいくと、一人のシゴデキが不在となった瞬間、チームは一気に崩壊の道を辿ります。

PMOの介入：勝てるチームへと導く「仕事の仕組み化」

属人化を防ぎ、勝てるチームとしての前提条件を整えるために最初に行うべきは、仕事の仕組み化です。具体的には、それぞれの業務を言語化し、メンバー全員に通じる共通言語としてまとめていく作業です。

ところが、多くの現場では「自分の仕事を言語化できない」人が意外にも多いです。そこで、私がPMOとしてプロジェクトに参加する際には、以下のステップで仕事の仕組み化を進めるようにしています。

STEP1：業務の可視化──「問診票」によるヒアリング

まずは業務内容を書き出すための「ヒアリングシート」を配布します。内容としては、病院の受付時に記入する問診票のようなイメージです。可視化したい業務の性質に合わせ、あらかじめ項目を整理したシートを用意することがポイントです。あくまでも参考ですが、具体的には以下のような内容を盛り込みます。

こうすることで、一人一人に口頭で聞くよりも効率的に情報を収集することができます。そしてその回収したシートを読んでいく中で、内容が抜けていると感じた部分や抽象的すぎる表現を洗い出し、誰が見ても分かるような共通言語としてまとめる、という作業を繰り返します。

この「問診」を通した業務の徹底的な可視化こそが「個人の頭の中にある経験知を組織の共有知に変える」大事なプロセスとなります。

仕組み化を行う上での注意：心理的安全性の確保

業務を可視化しようとすると、「自分の仕事やチーム内での価値が奪われるのではないか……」と保守的になり、情報を出したがらないメンバーが現れることがあります。

このような場面に遭遇した場合、単に言語化が苦手なだけなのか、心理的な抵抗によるものなのかを注意して見極める必要があります。私の場合は、なるべく本人に直接ヒアリングを行うようにしています。

単なる言語化への壁であれば問題ないのですが、心理的な抵抗が見受けられた際には、メンバーの存在価値を否定せず、安心して情報を出せる「心理的安全性の構築」を意識して対話するようにしています。

具体的には、「業務の可視化はあなたの仕事を奪うのではなく、結果的にあなた自身も楽になること（安心して休める、自分の業務により集中できるなど）につながる」ということを丁寧に説明しています。

チーム内での「心理的安全性の構築」については、本シリーズ第一回の記事で詳しく解説しているので、ぜひ参考にしてみてください。

沈黙する会議、表面的な議論……「崩壊チーム」の兆候を断つPMOの介入術 type.jp

STEP2：社内Wikiなどの「生きている場」への集約

Step1で可視化した情報を保存する場所も重要です。 WordやExcelの「マニュアル」は、作成した瞬間に風化が始まります。

私はいつも、社内Wikiやポータルサイトのような「生きている場」に情報を集約するようにしています。チームでよく使っているのがNotionやConfluence、あるいはGitHub / GitLabのWikiならそれでもいいと思います。大事なことは「更新性が高く、全員の目に触れる場」ということ。

Google ドキュメントのようなシンプルな形式でも、URL一つで全員が即座にアクセスでき、コメント機能で「ここ、手順変わりましたね」と双方向に修正できる状態にできていることが、勝てるチームの条件です。WordやExcelがダメかというとそうでもなく、オンラインでリアルタイム編集ができたり、共有できるような場が構築できれば問題ありません。

そして私の経験上、このようなプラットフォームを用意すると、不思議と「チーム全員の更新意欲が上がる」と感じています。さらには、「何かあったらここを見ればいい」というチームの共通認識も育まれていくのです。

STEP3：確認サイクルを回し、共通認識をアップデートし続ける

STEP2で用意したプラットフォームについて、「定期的に確認する場」を設けることも心がけています。「実態とズレていないか？」「なぜこの更新が行われたのか？」などを週一のMTGなどで確認し、チーム全員がフォローアップできている状況を維持することが目的です。

チーム内の共通認識をアップデートし続けるサイクルを定着できて初めて、属人化から脱し、「勝てるチーム」としての前提条件が整ったと言えるでしょう。

実践ヒント：「個人」ではなく「仕組み」を主語にして会話する

共通認識の場ができて運用が始まり、「勝てるチーム」としての前提条件が整った後でも、「体調不良による欠員」「手順が難解で理解がズレていた」といった問題は必ず出てきます。

ここで重要なのは、休んだりミスをした「個人」を責めるのではなく、「仕組み」を主語にしてどこに不備があったのかを会話することです。
「どうすれば誰も間違えない仕組みになるか」をチーム内で議論し、社内Wikiやポータルサイトなどの手順を改善していきます。

これは、一つ一つの業務を「個人の頑張りへの依存」から「チームとしての仕事の流れ」として主軸を移していく作業です。この地道な積み重ねによって、誰かが抜けても揺るぐことのない、仕事が体系化された「勝てるチーム」を作ることができます。

PMOという存在が、チームに「自由」をもたらす

ここまで見てきたような仕組み化を自律的に行えるチームが理想ではありますが、日々の業務に追われるスペシャリストたちが、本来の業務に集中しながらこうした環境を整えるのは容易ではないでしょう。

また、自分の仕事を客観的に「問診」することも、当事者だけではどうしても「埋もれる情報」が出てきてしまいがちです。

だからこそ私は、PMOという「第三者の視点」を持った存在が必要だと思っています。

PMOは、プロジェクトの渦中に身を置きながらも、一歩引いた視点でいわば「チームの健康状態」をチェックできます。

問診票（ヒアリングシート）を配り、Wikiなどの生きた知恵の場をメンテナンスし、エラーが起きたときには「仕組み」に矛先を向けて議論をリードする存在なのです。

PMOの介入によって属人化を排除したチームは、知恵が積み重なることで日々強くなっていくと実感しています。一人のシゴデキに頼るチームから、仕組み化によって全員で勝つチームへ。その変革を根底で支えるのが、私たちPMOの真の価値だと信じています。

書籍紹介

『DX時代の最強PMOになる方法』
著：甲州潤

▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい

【目次】
第1章　一番稼げるIT人材は誰か
第2章　これからはPMOが1プロジェクトに1人必要
第3章　SEとPMOの仕事は何が違うか
第4章　稼ぐPMOになる７つのステップ
第5章　優秀なPMOとダメなPMOの見抜き方
第6章　PMOが最低限押さえておきたいシステム知識とスキル
第7章　システムは言われた通りに作ってはいけない
第8章　どんな時代でも生き残れる実力をつけよう

>>>詳細はこちら