はじめに
※ この記事は tech kayac advent calendar 1日目の記事になります
技術ネタを期待していたみなさん1日目からこんなネタですいません｡ @Konboiです
ここでのメンターは
同じプロジェクトに配属された新卒氏のスキル向上と会社/チームに馴染めるようにサポートする
ぐらいのイメージです
告知
12/6 (日) にクックパッドさんをお借りして 師弟登壇2015 というイベントが開催されます｡
- 新卒研修でどのような事をやったのか
- 新卒研修の内容にはどのような意図があったのか
- 新卒側からどうだったか
- などなど
を話す予定です｡
もう一般枠の抽選は終わっておりますが学生枠の方はまだ､枠があるようなので是非参加してみて下さい！
今日の記事では､当日話しきれないであろう
- 新卒研修以前
- 新卒研修以降
に会社としてというよりはメンターになった自分がどういう風に約8ヶ月指導してきたかを記録として残す意味でも書きたいと思います｡
併せてカヤックに入ったらどういう風に仕事をしていくんだろうというのが垣間見れば嬉しいです｡
よっしゃトップバッターもらったぜ あれ､でも技術ネタ仕込む時間がないからイベント近いし丁度いいネタだ という理由ではありません｡
事前にやったこと
初めてメンターになるので 参考になりそうな本 過去読んでよかった本を読みなおしました｡
自分の中ではザ・コーチが目標の立てるのに参考になっているので後輩にも薦めました｡ 他はどういう風に新卒氏と接したらいいかの参考程度にとどめいています｡
メンターとは関係なさそうな本もありますが､自分より上の立場の人が新卒をどういう目線でみるのかとかざっくり知っておこうと程度に読んだ気がします｡
プログラミングの課題等は入社してコードを見てみないことには､実力が分からないので新卒研修の様子を見てという感じだったと記憶しています｡
入社から配属されるまで
今年の技術部配属の新卒は新卒研修を以下のようなプログラムで受けました｡ メンター側としては､新卒研修で行ったことはすべてではなくともある程度の知識を身に着けているという共通があったのでそういう意味でも新卒研修はいいですね｡
配属後
自分が新卒のときに聞けばすぐ分かることでずっと悩んでいたことがあったので早めに質問するようにと念押しておきました｡
社内には自分よりも素晴らしいエンジニアがたくさんいるので､issueで見える化していると最初の方は口頭でも説明しますが､issueやircを使うように意識していました｡
4月中旬､5月中旬
比較的大きなサービス規模が大きめということもあり全体像を掴んでもらうための意味を込めて
- デバッグツールの機能追加/改修
- QAの補助ツールを中心に担当
並行して すぐわかる オブジェクト指向 Perl と Webエンジニアが知っておきたいインフラの基本 通称 子鹿本 を課題図書として設定しました｡
これは新卒研修はGoでしたが担当するサービスではPerlなので理解を早めるために､ リファレンス､デリファレンスが分かりやすく書かれている本書を課題図書にしました｡
また 子鹿本は実サービスでどのような数字を先輩エンジニアはチェックしてるかをざっくりと理解してもらうために読んでもらうことにしました｡
など課題図書に書いてあることの理解を深めるためにもなんとなく使っている文法についてpr上で質問して理解してるかを確認したり
何故そのようなツールを使う必要があるのかなどをpr上で質問したり｡
最初は気を使って絵文字を多めに使っていました｡
高校生のときのメールを思い出しますね
こんな感じで配属直後は比較的丁寧に質問をしていました｡
5月中旬, 6月,7月
- Botや既存の機能改修
- 簡単な新規機能開発を任せ始める
- どういう風な機能改修をするのか
- どこにどのような変更が必要か
- その変更で既存の機能にどのような影響があるか
をissueにまとめそれをレビューしてから実装に入ってもらう
- 本番化をできるようになる
- 責任を与える
- 実際に自分の書いたコードを自分でリリースするというアレな感じ
の経験を積ませるためです 更には､リリース前のCIでマスターデータのテストがこけていたら担当の人に確認するためエンジニア以外と必然的にコミュニケーションをとらせるためという狙いもありました｡
この頃になるとある程度のことはできるようになってきているのでpr上での質問も難易度を上げて質問しています｡
とはいえ､まだまだ細かいところでの指摘は続いていた気がします｡
8月, 9月, 10月, 11月
大きめな改修のタスクを担当させ始める
- 引き続きissueにレビューしながらではあるが､関係者や開発工数が大きめのものを担当してもらうようになった
インフラ周りも少しずつ担当してもらうように
- chefでのnginxのconfigの変更
- dockerの開発環境の改善
自主的にチームに必要なツールに開発
- 自分が担当した機能でチームチェックとかをする時に不便を感じ自主的に作るなど
理解してないかもしれないなということには､答えを教えず問題解決の方法や手段を知ってもらえるように意図的に質問するようこ心掛けるようにはしていました
実プロジェクトだとインフラ寄りのタスクがそこまで無いので個別課題として自分が最低限知っておいて欲しいなというスキルを課題にだしてやってもらっていました
また､この頃になるとタスクのスケジュールリングも自分でやれるようになっているのでPR上で他の社員と同等に扱ってます｡
その他 業務以外にやったこと諸々
- 配属後にどういうエンジニアになりたいかの面談
2回ほどご飯を食べながら半年､1年でどういうエンジニアになりたいかをヒアリング
- 月1回の面談
最近どう？ からメンターからもう少しこうしたほうがいいよというアドバイスや 本人からの最近困ってることや悩んでいることのヒアリング
- 時々の飲みニケーション
とっても大事ですね (？)
メンターやってて困ったこと
- 障害対応の機会がなかなかない
これは運用している身としては嬉しいことですし､障害を0にするように最善を尽くしているのでなんとも矛盾しているのですが､担当しているプロジェクトで障害が合った時に､原因の究明から解決までのスピードや原因のあたりを付ける感覚をなかなか体験させる機会がないのはどうしようかなと思っています｡
これから
- インフラ周りの知識も身に付けつつ､緊急時にも対応できるエンジニアしていく
- 別チーム/別会社 にいっても問題ないスキルセットを身に付けさせる
がんばるぞ！！！
さいごに
4月からどのような風に接してきたかのいい振り返りになりました｡
これからメンターになる人の参考になれば幸いです
そして､そんな人達におすすめな素晴らしいイベントが今週日曜日にあるんですって奥さん！
ということで､以上1日目の記事でした！！
2日目は Goオールスターズな@shogo82148です お楽しみに！！
