なぜメンターにならないといけないの！？
Qiitaを読んでるみなさんおはこんばんわ。
Qiitaを読んでいるということはITのお仕事をされている方なのかなと思いますが、なぜITのお仕事を選ばれたのでしょうか？
「プログラムが好きだから！」
いいですね、ワクワクしますよね！ちょっといい感じのプログラムを書いて「オレ最高！」とかパソコンに向かって独り言を言っていたいですよね。
「給料がいいから！」
ストレートですね！他の業種よりはいいみたいですねが、実際のところは諸説あるみたいですね？
「リモートワーク！リモートワーク！」
そうですよね！面倒な通勤から解放されたいですよね！家の作業環境を整えるとモチベーション上がったりしますね。
…さて。
おそらくですが 「人が大好きで後輩の面倒を熱心に見たくてメンターになりたいから！」 という理由でIT業界を志望された方はあんまりいないと思いますがいかがでしょうか？
少なくともわたしは違いましたし、プログラムが好きで一日中プログラム書いてられるなんて素晴らしい仕事だなと妄想で胸を膨らませていました。
…が、現実はそうではありませんでした。
業務で必要なプログラムを書くために勉強をする傍ら、企画やらPMやらの仕事もしながら新人の面倒も見なければいけませんでした。自分の成長だって手一杯で忙しいのに、人の面倒なんか見ている余裕なんかあるかいな、と思ったこともあったりしました。
それでも、AIに取って代わられにくい超重要業務ではないかと最近は思えていますし、やらないといけないことだと思うので、そんな話をしようと思います。
プロジェクトと柿の種
柿の種、おいしいですよね。
おやつで出された柿の種を食べ終わってしまい、袋の中の柿の種を１つ２つくすねて食べた経験はあるでしょうか？１つ２つぐらいなら食べてもバレないかなと。実際１つ２つならバレないんですが、１つ２つを繰り返していると、取り返しが付かないぐらい減ってしまって大変なことになるんですよね。
突然なんの話かというと、プロジェクトの人員のたとえ話でした。
-
予算が潤沢な昭和のプロジェクト
なんとなく１人２人いなくなっても大丈夫そうに見えますね？
-
予算が少し削られた平成のプロジェクト
予算を削られてプロジェクトの縮小を余儀なくされました。そこでリーダーを引っこ抜いてチームを割って、２案件目を取りに行くことにしました。
-
予算がとても削られた令和のプロジェクト
人月商売のSESでは、人数がいればモノができると信じられています。いや、信じるしかないのでしょう。
この変化が緩やかにしかし確実に行われていったのでした。
お母さんは、柿の種の袋の中身に違和感を感じるも放置していたら、子どもたちを怒鳴り散らす以外の選択肢がない程度に柿の種が減っていたという状況です。怖いですね。
人月の神話とかスタープログラマーとか
さて、先程のプロジェクトの登場人物に戦闘力を記入してみましょう。
- 戦闘力 3人月のリーダーと、1.2人月のサブリーダーと 0.2 ~ 0.8 人月のメンバー
SESは人月商売なので、戦闘力が一人あたり1.0ないといけませんが「未経験新人歓迎」などと求人を行っていると、いきなり1.0の戦闘力を揃えられることは考えにくいです。
そこで戦闘力3.0のようなリーダーの下に戦闘力1.2のサブリーサーを2人つけて8人で8人月となるようにチームを編成して帳尻を合わせることにしていたのです。
昔は技術の進歩が遅く一度覚えた技術が長く使えたため、本気を出せば3人月ぐらいのアウトプットを出せる スタープログラマー 1が数多くいたと感じています。また、プロジェクトの規模も大きく期間も長かったため、少々ボヤ騒ぎになっても、スタープログラマーが本気を出せば取り戻せるというスタイルが横行していたようにも思えます。
このスタープログラマーが大活躍するスタイルは一見華やかですが決定的な問題をはらんでいました。
スタープログラマーに仕事が集中し、チームが育たないという問題です。
チームが育たないと、プロジェクトの規模や期間が縮小した時に、対応できなくなります。
不景気においてプロジェクトの規模や期間の縮小は免れません。また、スタープログラマーもいい年になって定年を迎えたり技術の刷新によってスター性が失われることもあるでしょう。
より条件の厳しい案件に対応していくには、チーム全体を成長させることが必須であり、チームを抜けるためには人を一人以上は育てなければいけないという、鉄の掟が暗黙的に存在していたのです。
メンターとして若手を育成していくことで、不条理に誰かに仕事を集中させずに、持続可能な組織に近づけるかもしれませんし、チームや組織を強化していくことで終身雇用への漠然とした不安を解消できるかもしれません。
チーム運営とよきメンター？
以下、チーム運営で留意している点を記載します。
戦闘力 1.0 を意識してタスクを決める
「新人だから」「未経験だから」という理由で与えるタスクを絞らない方がよさそうです。
プロジェクト内で必要な作業を、「１人月の戦闘力であればこれぐらいの期間でできてほしい」という説明をして、それに対して何ができて何ができないかを会話しながら切り出して決めて行くのがよいでしょう。
戦闘力 0.2 を 0.8 にしよう
戦闘力 0.2 を 0.8 にする方が、1.0 を 1.6 にするより効率的です。2
SESでは毎回チーム構成はガチャで決まります。小さなチームで最初にすべきことは、各メンバーの戦闘力の把握です。全員が戦闘力1.0を超えるSSRばかりのデッキはガチャの排出率的にもコスト的にも組めないはずです。
コストも戦闘力も低いメンバーを入れて、案件が終わるまでにそのメンバーにいかに経験を積ませて戦闘力を上げるかが持続可能な組織を作る上では重要です。
戦闘力が高くコストも高いメンバーは、同じ様な製造を繰り返していると得られる経験値は減ってくるので、メンタリングのスキルやプロジェクト運営の経験値を取りに行くのがよいでしょう。
オンラインゲームであれば、メンティーに敵を一撃攻撃させて後はメンターが敵を倒せば経験値が分配される、メンティーにとどめをささせてボーナス経験値を渡すなどがありますが、現実世界では目に見える形で数値化されていないので難しいところです。
『Javaエンジニア』などの相場は決まっているため、単純に『Javaエンジニア』としての戦闘力を5.0に上げても売上は5倍にはならないですが、0.2 を 0.8 にしたエンジニアを５人育成できれば売上が5倍になる可能性が出てきて、それがあなたの給与に反映される可能性が出てきます。
課題とレビュー
知識を一方的に伝えて「分かった？」と聞いてみて、なんとも言えない表情で「分かった」と言わせてもあまり意味がないです。
伝えたいことを課題形式にして伝えて、その結果をレビューするようにすると伝わったかどうかを確認することができます。
観察力や知覚力を上げたり、適切なフィードバックを行う力を上げることもできるかと思います。何より、伝わらなくてガッカリしなくてよいです。
また、課題には必ず期限を設定しましょう。報連相や締切を守るといったことをたえず意識することは重要です。
1回で伝えられるとしたら、それは洗脳
相手に伝わるように説明することはとても難しいです。なんなら伝わらないことの方が多いです。
自転車の乗り方などを思い出してもらうと分かりやすいかもしれません。よいコードの書き方など習得にトライアル＆エラーが必要なことは、一度の説明では伝わらないです。
締切がある中で会話していると温度が上がることもあるかもしれませんが、最初から「伝わらないものだ、伝わればラッキー」ぐらいに思って話をすると意外とうまくいくかもしれません。
AIにはできない観察
同じ様な質問を何度もされると思ったら、「なぜなぜ分析」を相手ではなく自分の脳内でやってみましょう。
「なぜ、その質問をしてくるのか？」を考えると、観察の解像度を上げることができ、実はもっと別の課題が必要かもしれないなど気づきがあるかもしれません。
相手をよく観察して、適切な課題を導き出すことは今のところはAIにはできないような気がしています。
効率的な努力をしてもらえるようにうながすことが大事です。
北風と太陽
ITは現役でいる間は勉強をし続けなければいけない厳しい職業です。
それゆえ厳しさは絶対的に必要ですが、北風の様に接っすると色々問題になります。
心理的安全性を確保すべく、とにかく話をよく聴いて太陽の様に接してみるといいかもしれません。
成功するプロジェクトのメンバーはいつもニコニコしていないといけないのです。
おわりに
プログラムは、一人で学習することができ学んだ分だけのスキルが身につきます。
この様な性質のものは、一人で夜も寝ないで黙々と学習を続けるAIには勝てないでしょう。
一方、メンタリングは、人と関わらないと学ぶことはできません。また、学んだ分だけのスキルは身につくけれども、相手によってよりよい選択肢が変わってくるため、スキルが身についたと実感し辛いです。
この様な性質のものは、現在の「質問に答える」形式のAIにはフォローできない業務と言えるでしょう。
また、メンタリングは、対話や相手のことを慮ることをベースに色々な施策を実施する行為であるため、設計や要件定義等、相手の考えていることを感じ取ったり共通のゴールを目指したりする能力が必要な業務でも役に立ちます。
つまりは「よきメンターでいること」は難しいことですが、本人のキャリア形成や、組織および業界を維持するために必要なことなので取り組んでみてはいかがでしょうか？
おまけ０
おまけ１（新卒エンジニア向け手紙）
おまけ２（新卒エンジニア向け記事）
おまけ３（...は難しいシリーズ）
おまけ４（営業A短編シリーズ）
おまけ５（エンジニアのためのお仕事問題集）
2030年にIT人材が最大79万人不足するとのことで、学習用の資料をgitで無料公開してます(不定期更新)。
よろしければどうぞ。