1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

20代と50代しかいないチームで知識継承をやろうとしたら、教える側が先に折れた話

1
Posted at

はじめに

うちのチームは、年齢構成がかなり極端です。20代が1人、30代が1人、そして50代〜60代が3人。30代後半から40代がまるごといません。
中途採用がうまくいかなかった時期と、その世代がちょうど転職していった時期が重なった結果なんですが、とにかく「ベテランの知識を若手に引き継ぐ」が急務でした。なので僕は「しばらくペアで作業してください」とお願いしました。
3か月後、若手はたしかに成長していました。同時に、教えていたベテランの担当分がまるごと遅れていました。 本人から「正直、自分の作業が全然進んでいない」と言われて、ようやく状況を理解しました。

間違ったアプローチ: 「教えるのも仕事です」で済ませた

当時の会話です。

自分: Aさんの持ってる知識、若手に引き継いでいきたいんですよね
ベテラン: そうですね、必要だと思います
自分: 教えるのも仕事なので、時間使ってもらって大丈夫です
ベテラン: 分かりました

(3か月後)
ベテラン: すみません、自分のタスクがほぼ進んでません
自分: ...そうですよね

「時間使っていいですよ」と言いながら、その時間を工数として引いていなかったんです。担当タスクの量は減らさずに、教育という新しい仕事を足しただけ。こんなの、破綻するに決まっています。
しかもタチが悪いのは、教える側は真面目な人ほど断らないこと。「自分の作業が遅れてるので教えられません」とは言いにくいんですよね。

なぜ継承は失敗したのか

理由は3つありました。
1つ目、教える時間はコストなのに、どこにも計上されない。実装の工数は見積もるのに、教育の工数は誰も見積もらない。見えないコストは、必ず誰かの残業になります。
2つ目、世代が2つ離れると、翻訳コストが跳ね上がる。50代が当たり前に使う前提(昔の開発経緯、当時の制約、業界の慣習)は、20代にとって未知の情報です。1つ教えるのに、背景を3つ説明しないといけない。
3つ目、ベテランは教えるのが下手なのではなく、言語化していないだけ。本人の中では手が勝手に動くので、説明しようとすると止まる。これは本人の責任ではないです。
そして、この状況を一番よく説明しているのが、40年以上前に書かれたこの一文でした。

Adding manpower to a late software project makes it later.
(遅れているソフトウェアプロジェクトに人を投入すると、さらに遅れる)
— Frederick P. Brooks Jr.『The Mythical Man-Month』(1975)

有名なブルックスの法則です。本の中では、増えた人数の分だけ「教育」と「相互のやり取り」の負担が増えることが理由として挙げられています。しかもその教育は、既存のベテランの誰かが担い、その工数は当初の見積もりに入っていない、と。知識継承もこれと全く同じ構造なんですよね。短期的には、必ず遅くなる。僕はそれを「短期的にも遅くならない」前提で計画していました。

正しい理解: 継承は「遅くなる」前提で設計する

やり方を変えたポイントを3つ書きます。

ステップ1: 教育を工数として積む

やったことは単純で、見積もりに「教育」の行を作っただけです。

NG: 実装 5日 (+ 空いた時間で若手に教える)
OK: 実装 5日 / 教育 2日 → 合計 7日として計画する

これだけで、教える側が「自分のタスクが遅れる」という罪悪感から解放されました。遅れているんじゃなくて、最初からそういう計画なので。

ステップ2: 2世代離れているなら、翻訳役を1人挟む

50代から20代への直接継承は、翻訳コストが高すぎました。なので間に30代のメンバーに入ってもらい、一度受けて、かみ砕いて渡す形にしました。

NG: ベテラン → 若手 (前提の差が大きすぎて毎回止まる)
OK: ベテラン → 中間層 → 若手 (中間層が言い換える)

副次的な効果として、中間層のメンバー自身の理解も深まりました。人に説明するのが一番勉強になるやつですね。

ステップ3: 継承の単位を「人」ではなく「作業」にする

「Aさんの知識を引き継ぐ」は無限なので終わりません。なので単位を変えました。

NG: Aさんの担当領域を引き継ぐ
OK: 次の案件で必要になる「Xの処理」だけを引き継ぐ

次の仕事で使うものだけを継承対象にすると、教わる側にも切実さが出ます。使わない知識は、教わっても定着しないので。

おわりに

知識継承って、「ベテランが元気なうちにやっておこう」という話として語られがちなんですが、実際にやってみると継承そのものが立派な1つのプロジェクトでした。工数がかかるし、期間もかかるし、専任に近い体制がいる。
それを「空いた時間でやっておいて」の扱いにしたのが、僕の失敗です。空いた時間は永遠に来ないので、空いた時間でやる仕事は永遠に始まりません。
もし今、チームの年齢構成が飛んでいる自覚がある人は、継承にかかる工数を一度見積もってみることをおすすめします。数字にすると「これ、片手間では無理だな」と分かるので、上に説明するときの材料にもなります。

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?