この記事はフラー Advent Calendar 2020 の13日目の記事です。12日目は @Gaku07jp さんで「自動レビュー依頼のactionを作成しました」でした。
今年に入り、フラーのサーバーサイドエンジニアも結構人数が増えてきました。 フラーではサーバーサイドの開発を主にGolangで行っています。 今年入ったサーバーサイドエンジニアの中には入社までGolangを触ってなかったという方もおり、 実際の案件に入ってもらうまでの間にGolangの演習問題をやってもらっていました。
私自身Golangを使い始めてまだ1年半ほどですが、今年に入って3人の社員にGolangを教えてきました。 今日はそのトレーニングの中で気をつけていたこと、逆に私自身の学びになったことなどを書いていきます。
フラーで実施しているGolangの課題
フラーのクライアントワークでは、スマートフォンアプリと通信するWeb APIをGolangで開発しており、 データベースはAWSのAmazon Aurora MySQLを利用しています。 ですので、課題においてもGolang+MySQLの組み合わせで開発するWeb APIの題材を与え、 Golangの基本構文はもちろんのこと、MySQLサーバーとの接続、テーブル設計や一般的なクエリ、 レースコンディション対策などを学んでもらっています。
また、発展課題としてGolangのユニットテスト実施や、 クライアントワークで採用しているGoa (v1)フレームワークの導入なんかも盛り込んでいます。
トレーニングを担当する上で気をつけたこと
なるべく指摘の根拠・出典を併記する
コードレビューで何か指摘を入れる際、極力その指摘の根拠を記載するようにしました。
例えば、Golangはコードスタイルを公式が提供しており、Golang独特の書き方・推奨されている書き方といったものは公式のドキュメントがあります。 これらのリンクを併記してコメントすることで、「なぜそのように直さないといけないか」という納得感が大分変わってきます。
情報収集に長けている人は自力でこういったドキュメントに辿り着くかもしれませんが、大抵の人は最初にどこを調べるべきか知りません。 正しい情報に導く手助けはとても重要です。
ちなみにGo Code Review CommentsのDeclaring Empty Slices、 Indent Error Flow、 Initialisms あたりは参照する頻度が多かった気がします。
伝わりやすい文章を書く
課題をやる人は新しい言語、新しい分野、新しい技術の習得のために頑張ってます。 私の書いた文章で混乱や誤解を招かないよう、少しでもわかりやすい文章を書くよう気を付けました。
いくつかポイントはありますが、代表的なところでいうと
- 一文を長くしすぎない(大体50文字前後を目処に)
- 文の主語を明確にする
- 文章内で単語のチョイス・表現を一貫させる
あたりを気をつけながら書いてました。 一文を書くだけでも何度か読み直したり修正をかけたりしたので、全体のコードレビューを返すのに平均で60分程度かかった記憶があります。
聞かれてないことに答えない
相手の質問にピシッと答えるのは当然なのですが、それ以上に聞かれてもいないことをベラベラと喋らないよう気をつけました。
理由は単純明快で、相手にとって不快だからです。 自分がした質問からズレた回答が返ってくるとか、 「ちなみに」から始まる余談が長いとか、隙あらば自分語りとか……質問者からすればストレスでしかありません。
前職の新人教育でも言われましたが、相手が求めているものを汲み取って答えるのが真のコミュニケーションです。 自分がひけらかしたい知識をグッっっっっと奥に閉まって、相手が欲しがってそうな情報だけ返すよう心がけました。
良くできたところは褒める
課題のコードレビューをやってるとどうしても「できてないところ」の指摘が多くなってしまいます。 ダメ出しばかりだと相手もつらくなってきてしまうので、褒めるべきところはきちんと褒めるよう心がけました。
誤りがあれば訂正し、謝る
そのまんまです。人間歳を取ると中々自分の誤りを認めなくなるものです。自分の誤りは素直に認めて謝るよう気をつけました。
トレーニングの中での気付き・学び
結構時間と体力を使う
先も書いたとおり、コードレビューを一回返すのに60分ぐらい使っていました。 それだけでなく、Slackでの質問や相談への回答、議論、トレーニング面以外でのコミュニケーション等々…… 全部ひっくるめると毎日業務時間の内2〜3時間はトレーニングに時間を充てていたのじゃないかと思います。
本業であるクライアントワークの開発スケジュールとの調整はもちろんのこと、 開発とトレーニングのコンテキストスイッチも地味に体力を持っていかれます。 幸い(？)トレーニングを担当している期間にそこまで激しい開発がなかったので滞りなく掛け持ちできましたが、 本業の開発が忙しい時期だったら……ちょっと大変だったかもしれません。
知識が足りない！
教える立場にある人間は、教える相手よりも何倍もの知識を必要とするなと言う気付きです。
例えば、私が担当している案件では、サーバーサイドのコードは古き良き(？)MVCパターンをベースに設計しています。 出した課題の想定解には当然MVCパターンが組み込まれてしまっているので、ここに別の設計パターンの解答がくると混乱してしまうわけです。
あとは私自身がDockerに疎いので、サービス全体をDocker Composeとかで括られたりするとレビューできなくて困ります。 「こんな設定です！」って言われたものに「あ、ふーんそうなんだ。まぁ動いてるからﾖｼｯ」と返してしまったこともありました。反省してます。
私自身の知識不足をかなり痛感させられました。
聞かれたことに答えるのはムズカシイ
先に触れたとおり、「相手が本当に聞きたいこと(論点)を汲み取って、相手が返してほしいであろう回答を渡す」のが真のコミュニケーションです。 これが意外と難しく、意識的に意図を汲み取る努力をしないと中々ズバッと回答を渡せません。
トレーニング期間に限らず常に気を配っているつもりですが、100%実践できているかというとそうではなく、質問の意図を正しく汲み取れないときもままありました。
質問が曖昧な場合や意図を汲み取りづらい場合は、「この質問はAということですか？それともBということ？」と自分なりの解釈を提示した上で、 一緒に質問の意図を明らかにしていくという方法も効果的でした。
コミュニケーションは密にとるべき
フラーではメンバーのコミュニケーションにSlackを利用し、コードレビューなどはGitHubのPull Request上でやり取りをしています。 すると対面に相手がいない分、相手が今何をしているのか把握しづらいことがあります。
例えばGitHubに2時間コミットがなかったとして、そのとき相手がどんな状態なのか(ローカルでガリガリ書いてるのか、手が止まってるのか、何もしてないのか)こちらからは観測できません。 時たまこういう状況に陥って、私自身が結構不安に感じることがありました。
教育する側と教育を受ける側、コミュニケーションのキッカケを作る際にハードルが低いのはおそらく前者です。 私の方からガンガン様子を聞きに行っても良かったかなぁと思います。
まとめ
私がフラーで新入社員のトレーニングをする際に気をつけたこと、また逆に学びになったことをまとめました。
よくよく思い返してみたら、文章やコミュニケーション面で気をつけたことは前職(新卒で入った会社)の新入社員研修で学んだことばかりでした。 丁寧に研修を組んでくれた前職の教育担当に改めて感謝です。ちゃんと身になってますよ！！！
さて、フラーではまだまだサーバーサイドエンジニアを募集しています。 興味を持った方、今の仕事に退屈になってきた方、新潟に移住したいけど職に困ってる方等など、お気軽にご連絡ください。
