伝えすぎない勇気と、知らないまま始める力
はじめに
私が所属する組織では、最短で3ヶ月でチームの約半数を入れ替える チームシャッフル や、1週間だけ他のチームで仕事をする レンタル移籍 といった仕組みを採用し、属人化防止や知識の最大化に取り組んでいます。
チームシャッフル や レンタル移籍 に興味が出た方は以下の記事をご覧ください。
◆ チームシャッフル
アジャイルリーダーシップとはなにか？ どう実践するか？ 権力ではなく影響力でアジャイルな組織をつくるために【対談】
◆ レンタル移籍
短期間だけ別チームで仕事をする「レンタル移籍」でソフトウェア開発の知識共有を促進！ ユーザベース独自のチーミング制度を体験ベースで紹介する
この記事ではそのような、チームを移動し続け、チームの新人であり続ける私が思った、新人は何をどこまでキャッチアップすべきなのか についてまとめてみます
私が所属する組織ではXPを採用しており、ユーザーストーリー単位で仕事を進めていっていますが、この記事では一般的な話として仕事の単位をタスクとして話します。
読者の中でアジャイルを採用している方は、タスクをバックログや、ストーリーと読み替えていただければ幸いです。
結論
まずは結論です。
- タスクに関する最低限だけを知る
- 運用・リカバリーは起きた時に携わりながら知っていく
それぞれについて掘り下げていきます。
1. タスクに関する最低限だけを知る
例えばあなたのチームはとある画面の開発をしているとします。
その場合の最低限とは、このタスクでは どこからデータを取得しどこに出したいのか であり、過去開発してきた内容や、次に開発する内容、このチームが持っている運用を最初に知る必要はありません。
やっていく中で思想やカルチャーは知っていけばいいのです。
2. 運用・リカバリーは起きた時に携わりながら知っていく
「このチームでは〜〜という運用があって〜〜」という説明を最初にしている場面に遭遇したことがあります。
正直、最初に説明されてもよくわからない ことがほとんどです。
大体の運用はハイコンテキストなことであり、キャッチアップする内容が多すぎます。実際に運用作業が発生した時に ドライバーを取っていき、やりながらキャッチアップしましょう
よくある伝え過ぎパターン
チームに長くいる側として、私がよくやってしまう伝え過ぎのパターンをここで紹介します
全体のアーキテクチャの説明
プロダクト全体の複雑なアーキテクチャを映しながら細かく伝えるパターンです。
これを伝えている時の私の心境としては、「全体のことを知ると、なんとなくこのチームのことを知ってもらえるかな？」でしたが、これは間違いでした。
全体のアーキテクチャはすぐ使う知識にならず、キャッチアップコストをあげてしまうだけでした。
直近触るようなスコープに絞ったアーキテクチャを紹介する程度にすると良いでしょう。
過去の開発内容
過去の開発内容を知ればプロダクトの思想に沿った提案ができるのではないかと思い、伝えてきました。これはメリットもあると思っていますが、今の開発内容に親和性が高いもの以外は必要がないでしょう。
あまり関係がないプロダクトの説明はキャッチアップコストのデメリットが大きくなるでしょう。
やらない方がいいさらに詳しい説明は後でするとします。
知りたがる新人へ：安心感よりも小さく始めよう
ここまで読んで、伝えている側は「そりゃそうだよね」と感じたかも知れません。
そこで、何人かの新人に話を聞いて、なぜ知りたいのか、知る必要がない理由をまとめてみました。
まず、知りたい理由にはざっくり3パターン存在していました。
- 全体像が掴めてないから不安
- 知らないから手を挙げるハードルが高い
- 良い提案が自分の知らなかった領域から出ると悔しい
それぞれに対して 知る必要がない理由 を解説していきます
1. 全体像が掴めてないから不安
全体像が把握できないと動き出せないタスクは大きすぎるのではないでしょうか？
ここで言う大きすぎるとは、複数のタスクが絡み合って巨大化している状態を指します。
例えば、「データを取得し、フィルタリングして画面に表示する」と言うタスクは「データを取得する」「画面に表示する」「フィルタリングする」と3つのタスクに分解することができます。
それら3つ分のキャッチアップをするのには時間がかかってしまうでしょう。
「データを取得する」にフォーカスすれば、説明する内容は少なくて済み、新人は少ない量のキャッチアップで動き出すことができるでしょう。
全体像が掴めないと動き出せない時は、タスクが大きすぎていないかを考えてみると良いでしょう。
2. 知らないから手を挙げるハードルが高い
「知っている。」「知らない。」は手を挙げるための指標ではありません。
「知っていることに手を挙げる」のではなく、「知らないけどやってみる」と言うメンタルセットの問題です。これが組織・チームとして起きていないのであれば、組織の心理的安全性が保たれているのか考えてみるといいでしょう。
問い合わせや障害を事前に把握しておくことは不可能です。
どんなに強いエンジニアでも嗅覚が鋭いだけで、事象が発生した時のスタートは似たようなものです。全く見当がつかない時も「エンジニアで確認します」の一言を発声することはできますし、強いエンジニアにヘルプを求めながらドライバーをすることはできるでしょう。
また、「知らないから手を挙げられない」の癖をつけると、常に誰かの後ろを追いかけることしかできなくなります。特に新人は傍観者にならず、積極的にドライバーを奪って行きましょう。
3. 良い提案が自分の知らなかった領域から出ると悔しい
ここで伝えたいのは、「前職/前チームでのあなたの経験から出る素晴らしい提案がきっとある」と言うことです
確かに、自分の提案が却下され、相手から良い提案が出たら悔しいでしょう。
しかもそれがまだ聞いていない、チームの内容であったらなおさらです。
しかし、そういった領域はあなたにも存在します。
一つ図を書いてみました。
この図では、Aさんが持つ知識と、Bさんが持つ知識、そして共通の知識を集合を用いて表現しています。
今回はAさんが持っている知識から出た提案が採用され、Bさんは悔しい思いをしたかも知れません。
果たして、共通の知識を増やすことにどれだけの意味があるのでしょうか？
たくさんのことを伝えて、共通の知識の集合を大きくしたら以下の図のようになります。
ここで知識を広く共有したことで「共通の領域」は増えましたが、Aさん・Bさんのそれぞれのユニークな知識はむしろ薄れています。この状態ではAさんからいい提案が出るか、Bさんから良い提案がでるかわかりません。しかし、大事なのはどちらから良い提案が出たかではありません。
コストを払って共通の知識の集合を大きくしたのに、知識の総量は変わっていません。
知識の共有には「伝達コスト」がかかります。
教える側・学ぶ側ともに、理解のための時間や労力を使うことになりますし、使わない知識を増やしてしまうリスクもあります。共通の知識を広げることは一見良いことのように思えますが、そこにかかるコストと、得られるリターンのバランスを見極める必要があります。
それでも「もっと知りたい」と強く思ってしまう時、それは本当にプロダクトのためでしょうか？
時には、「良い提案をしたい」という思いが、自分が評価されたいというエゴにすり替わってしまうこともあります。
各々の持つ知見を結集し、プロダクトを全員でよくしていくことが本質です。
あなたの知見はきっと役に立ちます。自信を持って発言して行きましょう。
説明したい先輩へ：与えすぎは成長を阻む薬
とはいっても新人は不安であり、これまでの私は「なるべく不安は少ない方がいい」と思い、新人が求めるならばと、必要以上に伝えてきました。
説明することは新人にとって良いものなのでしょうか？
それを続けるとどうなるか考えてみます。
説明がないと動けない人間を育ててしまう
あなたが新人を迎えた際に、まずたくさんの説明をして迎えたとします。
その新人が他の組織・チームに行った時どうなるでしょうか？
おそらく同じくらいの説明を求めてしまうと思います。(特に新卒は)
「前のチームでは全部説明してくれました」
「このチームは説明がすくない」
と前を基準に過剰に知識を求めてしまうでしょう。
必要最低限のキャッチアップと、これまでの経験から多くの価値を生み出すことができる人間こそ重宝されます。
説明をたくさんすることで、短期的にはその人の成長につながるかも知れませんが、中長期的には全てを説明するのではなく、理解してもらうことのほうが大切ではないでしょうか？
※ 必要最低限の量は新人には把握できません。これは伝える側が判断する必要があります。
まとめ
知りたい人
- タスクに関わる最低限を知ろう
- 運用やリカバリーはやりながら知ればいい
- あなたの経験・知識から生まれる素晴らしい提案はきっとある。自信を持って発言しよう
伝える人
- 全てを伝えるのがその人のためになるとは限らない
- キャッチアップしていく姿勢も含めて伝えることを意識しましょう
Discussion