最新記事公開時にプッシュ通知します
2025年10月22日
株式会社ビットキー エンジニアリングマネージャー
パウリ(岸田 篤樹)
新卒でWEB・iOSエンジニアとしてキャリアをスタート。マネージャーを経て、2社目ではスクラムマスターやエンジニアリングマネージャーの育成も経験。
現在は株式会社ビットキーのエンジニアリングマネジメント室(EMO)に所属する。組織開発、技術広報、採用をミッションに掲げるEMOでは、スクラムマスターとしてのチーム支援、技術広報の評価・計画・業務プロセスの立ち上げ、開発者採用の推進、業務改善、評価指標の作成など、その時々で組織の成長に最も貢献する役割を柔軟に担う。
「最初からこの情報がまとまっていれば、もっと早く成果を出せたのに…」
あなたもこんな場面に遭遇したことはありませんか?
「あの仕様って、デザイン、ドキュメントと実装のどれが正しいんだろう?」
「この組織内で、マネージャーやテックリードへは何が期待されているんだろう?」
「このポジションの採用基準って、何を元に判断しているんだろう?」
特に新しい役割やタスクを担うたび、言語化されていない業務プロセスを解き明かしてきた方ほど、そのように感じるのではないでしょうか。その後オンボーディング担当者や上司に質問をすると、「ここは〇〇さんしか知らないところだね」とたらい回しにされるなんてことも…。
ただ、私の観測範囲では、業務を「引き継がれる」側としては多くの人が先述のような体験をしているものの、「引き継ぐ」側に回ったときに意識的に引継ぎを進める人は多くないように思えます。
そこで今回はこれまで様々な業務を引き継いできた経験を活かし、引継ぎのノウハウについてお届けします。本稿ではまず、「なぜ引継ぎは難しいのか」を紐解いていきます。続く第2回では引継ぎの具体的な手法、第3回では後任者の自走を支えるサポート方法についてまとめていきます。
先述の通り、引継ぎは組織内で求められている重要な業務でありながら、「丁寧で体系的な引継ぎ」はなかなか行われません。
ではなぜ、引継ぎは不完全なまま終わったり、そもそも着手すらされないのか。以下によくある3つのケースをあげてみます。
重要なはずの引継ぎに時間を確保できないのは、すでに前任者の業務量がパンク状態になっているからではないでしょうか?
このパンク状態の正体を理解するために、まずアプリケーション設計におけるアンチパターンとして知られる「巨大な泥団子(Big Ball of Mud – BBoM)」という概念を紹介します。
これは、無秩序に拡張・修正が繰り返された結果、全体像の把握や部分的な変更が極めて困難になったシステムを指します。そして、特定の個人に業務や期待が集中してしまいパンクに至るプロセスは、このシステムが形成される過程と驚くほどよく似ています。
※注釈:先に申し上げておくと、巨大な泥団子についてはシステム設計としてのアンチパターンではありますが、社員としては期待する成果を出し続けている点で素晴らしい方であるということは断言できます。引継ぎされない課題への説明として、便宜上このような表現としていることご了承ください。
引継ぎを阻む「パンク状態」は、引継ぎ元がこの「役割の巨大な泥団子化」に巻き込まれることから始まります。ここからは、泥団子化が進む流れを以下の3段階に分けて辿っていきます。
情報と専門性の偏在とは、組織内で、技術や事業関連の情報、経営情報など、その人しか持ち得ない情報が集中してしまう状態を指します。
この問題は特に組織や事業の拡大フェーズで顕在化しがちで、立ち上げ期を支えた特定の「できる人」に業務を任せ続けてしまうことが主な原因です。
結果として、業務に必要な情報も自然と一人に集まるようになり、他のメンバーは重要な業務から取り残され、成長機会を失ってしまいます。その人自身は組織が拡大した後もプレイングマネージャーとして多忙を極め、自身の業務内容や業務に必要なスキル、事業の知識などを言語化する機会を逃し続けます。 当然、情報や専門性は他のメンバーに共有されないため、属人化が一層進みます。
情報と専門性が偏在している「バス係数1」(その人がいなくなると業務が停止する状態)の人には、過去の重要な技術選定の背景やアーキテクチャ設計の意図といった、重要な意思決定の背景情報が集中しています。
そのため上司や他のメンバーは、その人に無意識のうちに期待を寄せ、頼らざるを得なくなります。たとえば、リリース作業依頼、マージの最終意思決定、開発方針の決定などの重要な業務や、不具合や仕様確認の問い合わせなどの細かな業務が集中します。その結果、こうした不具合や仕様確認など細かな問い合わせも一手に引き受けることになり、まとまって集中する時間がなくなることで業務効率は低下していきます。
情報と専門性が偏在し、なおも依頼・業務が集中した結果、当然その人の時間は枯渇します。この状況で新しいメンバーを採用しても、引き継ぐ時間が与えられません。結果として、引継ぎ作業は後回しにされ、特定の人の業務量がさらに増えて深夜残業が常態化するか、あるいは、何とか最低限の引継ぎを行うために、半ば強制的に価値提供のための業務量を減らさざるを得なくなります。
このようにして、引継ぎをしたいと思っている本人でさえ、引継ぎができないという負のスパイラルが完成します。
1.の「巨大な泥団子」状態ではない、あるいは近しい状況だが頑張れば工数を捻出できるような環境であっても、引継ぎがなされない場合があります。
それは、いざ時間が取れたとしても、その限られた時間の中では何から手をつければ良いかわからず、結果として仕掛かりのまま放置してしまうことです。
そうこうしている内に、引継ぎをする側は潜在的にある現在志向バイアス(目先の業務を優先してしまう心理)が勝ってしまい、後任側は実践の中でなんとなく業務に慣れていき、引継ぎが不要であるかのように見えてしまいます。(しかし、これが後々大きな問題に繋がることは少なくありません…)
そもそも業務において何かしらの課題解決をする際、まず「世の中ではこの課題にどう対応しているのか」を調べるのが一般的です。
しかし、この「引継ぎ」というテーマにおいては、確立されたデファクトスタンダードが見つかりづらいのです。その結果、引継ぎ業務への心理的ハードルが高くなり、着手されないままになってしまいがちです。こうした課題を解消するための具体的な引継ぎ手法は、後続する第2、3回の記事で具体的にご紹介します。
これまでに説明した「工数が割けない」「手法が見つからない」といった要因とは別に、組織構造そのものが引継ぎを阻害している場合があります。
本来、引継ぎのゴールは、後任者が業務に早く慣れ、能力を発揮できる状態のはずです。しかし、前任者が引き継ぎ業務に前向きになれないとき、実は引き継ぎ自体を拒みたくなるような組織構造が根源的な要因となっているケースがあります。
この構造的な問題が、現場では具体的にどのように現れるのか。代表的な2つのケースを見ていきましょう。
たとえば、部長 1人、課長 3人、社員 10人のようなピラミッド型組織で、役職と評価基準が結びついているような場合、部長や課長など席数が限られている役職の方にとっては、自分の持つ知識や権限を明け渡す引継ぎは、自身の立ち位置を不安定にする行為と見なされがちです。
さらに成果による評価で、降格することが制度上ほぼ不可能な場合、「現状維持」が最も安全な選択肢となります。
本来、引き継ぐ側の上司がチーム全体の士気や生産性を向上させるためメンバーの成長を促すことが理想です。しかし「現状維持」が上司にとって最も安全な選択肢となっているのであれば引継ぎが積極的に行われなくなるのも無理はありません。
これは、ピラミッド型組織に限らず、「フラットな組織」であっても、実質的な評価制度など組織の仕組みとしてこの問題に取り組んでいないと、同じことが起こり得ます。
こんな現場に、心当たりはないでしょうか(あってほしくないですが)。
これだけならまだマシですが、その後、「やっぱりAさんじゃなきゃダメだよね!」「さすがAさんは頼りになる!」と引継ぎをしなかったAさんがさらに評価され、「Bさんはストレス耐性がない」「Bさんはまだ能力不足」と、逆に挑戦したBさんの評価は下がってしまうということもあります。
これら2つのケースは、経営や人事関連の情報など、意思決定時に必要な情報が暗黙知化し、偏在している状況で起こりやすくなります。
いずれも「情報の非対称性」をつくり出し、自分の地位を守ることが容易になり、またその行為にメリットがある環境となってしまいます。つまり、引継ぎはしない方が「自分の地位が確保できる」という歪んだインセンティブが働いてしまうのです。
ここで強調したいのは、たとえこのような振る舞いをしている人がいても「その人が悪い!」と全面的に否定をしてほしいということではありません。あくまで組織の構造として、結果的にそういったマインドセットや振る舞いをする人がその役割を担うという、自然な出来事でしかないのです。(なので、「あなたはダメだ!」と糾弾するような材料としてこの記事を使ってほしくはありません。)
いかがでしたでしょうか。本稿では、引継ぎが実践されない3つの理由を解説しました。
引き継ぎの難しさが、単なる個人の意識や能力の問題ではなく、組織の構造に深く根差した課題であることが見えてきたかと思います。「時間の枯渇」「後回し」こそ、私たちが個人として、チームとして最初に取り組むべき突破口となります。「時間の枯渇」には「引き継ぎを前提とした業務の進め方」という新たな習慣づくりで対策します。「手法がわからない」という悩みには、具体的なノウハウそのものが解決策となるはずです。
次回は、引継ぎのロードマップづくりとスキルの体系化をテーマに、引継ぎを始めるための具体的な第一歩を解説します。ご期待ください。
関連記事
人気記事