こんにちは。コスッキーといいます。
7/29(月) にGotanda.EM #3でLTをしてきました。 その内容について補足しながら書いていこうと思います。 今回は、自分が所属しているチームのオンボーディング（新しく加入した人に手ほどきを行い慣れさせること）についてLTをしました。 新卒の人たちが入ってくる際に、未整備だったフローからやることを考え準備し、一ヶ月ほど運用した後で振り返りを行いもらったフィードバックを元に作った資料です。
今までの課題
今まではチームに新しい人が加入する時、過去数年の先輩たちの動きを振り返ると、「コールドリーディングやドキュメント確認のための勉強時間を用意」「メンターを同じチームから選出してある程度その人におまかせ」という事をしていました。 迷った時は歴史に学ぶということでやってきましたが、歴史が長くなってきたこともあり、チームとして何をすればいいのか？何を教えればいいのか？など整備の必要性を感じました。
特に、以下のような課題を感じました。
コードやドキュメントを読むだけで身につくものだろうか？
学校でも教科書を1回読むだけでテストで100点を取れる人はまれですよね？コーディングでも同じでリポジトリのコードを読んだだけですべてを把握できるような人はいないと思いました。 あと目的もなくただコードを読んでいるだけでは飽きやすいのでは？とも思いました。
自信がつくにはどうすればいいか？
自信がないと行動ってできないと思います。特に初めて社会人として働く新卒の人は。なので自分から行動するために自信をつけてほしいと考えました。
相談しやすくするにはどうすればいいか？
何が分かってないのか？どこに躓いているのか？を知っているのは困っている当人だけです。我々はエスパーではないので、相談されないと困っている状態という事すら分かりません。
実際にやったこと
上記の課題をなくすためにいくつかの事を行いました。 ここでは、一例を紹介したいと思います。
上長交えて期待値のすり合わせ
一番最初の顔合わせの時に、期待値のすり合わせも行いました。 何故かというと、半年後や1年後の目標となる姿をイメージして欲しかったからです。 特に、どのような成長をして欲しいのか？チームとしてどのような期待をしているのか？というのを話しました。
また、これらの事は自分からではなく、上長から話してもらいました。 いちメンバーである自分よりも、実際に評価を行う上長からの方が説得力もありますし、新しい方も身が引き締まるかなと考えたからです。
タスクや課題を用意
新しい方用のタスクを用意しました。 内容としては管理画面雨やデバッグメニューなど最悪壊れても問題ない部分のタスクを用意しました。
タスクの達成という目的があるなかでコードに触れることで「読んでいるだけでは飽きる・身につかない」という課題を解消できるのでは？と考えたからです。 また、要件定義・実装・レビューのやり取り・反映といった、これから何度も行うであろう作業を最初のうちから慣れてもらいたかった、という考えもあります。
反映して問題を解決したら「ありがとう」とか「お疲れ様」と行った言葉やslackのリアクションがつくので、そこから自信をつけてほしいという期待もありました。
相談の窓口を用意
相談しにくい原因として、誰に聞けばよいのか分からないという事があると思います。 なので、とりあえずメンターを相談の窓口にしてもらうようにしました。
また、質問すること自体がハードルが高い・怖いという事もあるかもしれません。 しかし、時間や締切を守る・遅れそうな場合は早めの相談が社会人としては当たり前な中、ずっと分からないまま迷っている時間がもったいないので「10分考えて分からなかったら質問」という時間的な区切りをつけてみました。 それでも、できなかった場合をケアするために、最初の一ヶ月のうちは朝会・夕会の後でメンターが「進捗はどう？」「困っている事はない？」とヒアリングも行いました。
振り返りをしてみて
以上のようなチームとしての受け入れフローを用意して、一ヶ月働いてもらった後で、新卒やメンターを交えて振り返りMTGも行いました。 GoodやBadだったことをいくつか紹介たいと思います。
Good
最初に全体像の話があった
期待値のすり合わせを最初に行ったのは良かったという意見がでました。 また、新卒のエンジニアからはディレクトリ構成やアーキテクチャ、フロント・サーバーでの処理の流れ、歴史的経緯などを、レポジトリを見ながらホワイトボードを使って説明してもらえたのが良かったという意見ももらいました。
人やチームの役割・目的・タスクとしての全体像だけではなく、実際に触っていくことになるコードの全体像を最初に説明してあげるのは良さそうでした。
開発作業の流れを一通り体験できた
ひとえに開発作業と言っても、完璧な仕様書が降りてきて、それを元に動くものを作ればいいというものではありません。 チケットの報告者と解決したい問題や解決方法の要件定義、実際のコーディング、コードレビュー、動作確認、反映、報告。 ここまでやって、ようやく開発作業が終わったと言えます。
それを最初に小さいサイクルで何度も体験できたのは良かったという意見が出ていました。 また、反映後は「お疲れ様」や「ありがとう」といったリアクションがslackでつくので、それが自信ややる気に繋がっていそうにも見えました。
相談先が決まっている
相談先も決まっているので声をかけやすいとう意見でGoodだと言ってくれました。
メンター側からは、内容によって窓口を分けるとさらにGoodという意見が出てきました。 すべての相談をメンターにしていたので、新卒とチケットの報告者しか知らないような仕様や要件について相談してきたり、開発者全員に知ってほしい・他の開発者が詳しいジャンルの質問を個別で相談したりという事もありました。 仕様や作業内容の相談はslackのディレクターチャンネル、開発や作業中に困ったことはslackの開発チャンネル、相談先がはっきりしないなどその他な質問はメンター、など相談内容によって窓口を分けると良さそうという意見も出てきました。
Bad
業務で使っているツールの使い方が分からない
今回の振り返りで出てきたのは普段から業務で使っているslackとJIRAについてが話題に上がりました。 どちらかといえば、使い方というよりは、前提やフローの共有漏れという意味のほうが教訓としては近いと思います。
slackについては、他の人の目にも入るように「DMといったクローズなチャンネルではなく、オープンなチャンネルを利用しよう」という前提で運用していました。 DMを使うのは個人情報が入っている場合などに限って運用していました。 しかし、その運用前提を伝え忘れていたので、個人DMで仕事の相談をしたり、相談内容がチグハグなチャンネルで行われたりもしました。
JIRAについては、口頭やチャットでの報告やJIRAのチケットにコメントもなく、チケットが閉じられるという事態が起きました。 JIRAの運用フローを伝えてなかったという側面の他にもホウレンソウができてないという側面もありますが、JIRAの使い方については事前に教えてなかったので、こういう事態も起きたのかなと。
ドキュメントが古い
今のプロジェクトは長いこと運用していることもあって、ドキュメントが現実と乖離していたり、同じ内容の記事が複数存在したりしていました。 現在のチームでは暗黙的に「気づいた人がドキュメントを修正する」という状況でした。（大量のドキュメントを常に最新に保つなんて無理だと思っていますし、その状況自体は問題ないと思います。） ただ、暗黙的な状況を伝えてなかったので、新卒の人がドキュメントどおりに進めていてもちゃんと動かず、いろいろと試したり調べたりする内に時間が経ってしまったという事も起きてしまいました。
また、記事が大量にあるため検索しにくい、どこから手をつけていいか分からない、という問題もあります。 先も書きましたが、大量のドキュメントを常に正しく保つなんて無理だとは思っています。 しかし、内容によってドキュメントの分類や配置といったインデックスの整備は人がやるしかない（技術的に賢くできれば嬉しいのですが…）ので、その辺の整備はしていく必要があるなと感じました。
これから
いくつか試してみてよかったこと・まだ課題が残ることいろいろとあります。
- 最初に全体像を掴ませる
- 小さいサイクルで何度もタスクの成功体験を経験させる
- 相談先やドキュメントの整備
といった事は今後も続けたいと考えています。 しかし、これだけで十分とは思っていないので、
- チームの現状の問題の把握
- 受け入れフローの明文化
- チームとして教えること、新人として知りたいこと
なども取り組んで行きたいと考えています。
読んだ方で、もしオンボーディングでやってみて良かった事や教訓などあれば共有してほしいと思っています！
