Mobile Factory Tech Blog

技術好きな方へ!モバイルファクトリーのエンジニアたちが楽しい技術話をお届けします!

オンボーディングと振り返り

こんにちは。コスッキーといいます。

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の使い方については事前に教えてなかったので、こういう事態も起きたのかなと。

ドキュメントが古い

今のプロジェクトは長いこと運用していることもあって、ドキュメントが現実と乖離していたり、同じ内容の記事が複数存在したりしていました。 現在のチームでは暗黙的に「気づいた人がドキュメントを修正する」という状況でした。(大量のドキュメントを常に最新に保つなんて無理だと思っていますし、その状況自体は問題ないと思います。) ただ、暗黙的な状況を伝えてなかったので、新卒の人がドキュメントどおりに進めていてもちゃんと動かず、いろいろと試したり調べたりする内に時間が経ってしまったという事も起きてしまいました。

また、記事が大量にあるため検索しにくい、どこから手をつけていいか分からない、という問題もあります。 先も書きましたが、大量のドキュメントを常に正しく保つなんて無理だとは思っています。 しかし、内容によってドキュメントの分類や配置といったインデックスの整備は人がやるしかない(技術的に賢くできれば嬉しいのですが…)ので、その辺の整備はしていく必要があるなと感じました。

これから

いくつか試してみてよかったこと・まだ課題が残ることいろいろとあります。

  • 最初に全体像を掴ませる
  • 小さいサイクルで何度もタスクの成功体験を経験させる
  • 相談先やドキュメントの整備

といった事は今後も続けたいと考えています。 しかし、これだけで十分とは思っていないので、

  • チームの現状の問題の把握
  • 受け入れフローの明文化
    • チームとして教えること、新人として知りたいこと

なども取り組んで行きたいと考えています。

読んだ方で、もしオンボーディングでやってみて良かった事や教訓などあれば共有してほしいと思っています!

メンター成長のためのふりかえり会

こんにちは。id:kfly8です。7/29(月) にGotanda.EM #3でLTをしてきました。 その内容について、書きます。

speakerdeck.com

メンターのふりかえり会について

弊社の場合、新人の育成のために新人ごとにメンターをつけています。10人くらい新人がいるので、メンターもおおよそ10人います。

メンターをやるにあたり、初めてメンターをするのであれば、どうメンターをすれば良いか戸惑うと思います。 また、人によってやり方がバラバラであるよりも、組織としてベースラインを担保し年を重ねるごとに強くなれるのが理想だと思います。

ではどうするかですが、まずメンターが知識0からはじめるのは困りますし、組織としても期待はあるのでそれは始めに詰め込んでいます。例えば、期待を伝える場や1on1のワークショップなど行ったり、メンターを何回かやっている人はメンターのお仕事に関わるおすすめの本を薦めたりしています。

ただ、頭でわかっても、実践が難しいといった話をよく聞きます。

そんな問題を解決するために、月1でメンター同士で集まって、ふりかえり会をしています。目的は、メンターの内省とメンター同士の関係作りです。メンター自身が深く考え・言語化するのと同時に、同じ目線で話す仲間でサポートしあえる関係ができるといいなと思っています。

具体的には、YWTを使っています。YWTは、Y(やったこと)、W(わかったこと)、T(つぎにやること)を言語化する、ふりかえりのためのフレームワークのひとつです。

進め方は、個人ワークでYWTを書き、内容をシェアする形です。駆け足ですが、1時間で行なっています。

まず、「Y:やったこと」では、1ヶ月の出来事を思い出してもらいます。これを挟まずに「W:わかったこと」を始めてしまうと印象に残った出来事などに偏ってしまい、深い洞察がしにくいです。

# Y: やったこと<個人ワーク>

メンターとして、今日まで何をしましたか?どんなことがありましたか?

いつどんな状況で、どんな言葉を使いましたか?
ヒント1:まずは思いつくままに書いてみましょう!
ヒント2:1on1の議事録を見返してみましょう。
ヒント3:メンティーとどんなやりとりをしましたか?
うまく伝わった、なかなか伝わらなかった、そんなことはありませんか?

次に「W:わかったこと」は、やったことや出来事に対する価値づけを行います。書き出すことを重視して、まずは簡単に「よかった」「わるかった」の価値づけでラベリングしてもらい、そこからどうよかったのか、わるかったのか詳細を言語化してもらいます。 またシェアは、簡潔に話すために「XXXがわかった。YYYという出来事があったから」というようなフォーマットで、一人一つずつ話してもらっています。

このワークがこのふりかえり会の肝です。

# W: わかったこと<個人ワーク、シェア>

やったことから、どんなことがわかりましたか?

いつどんなふるまいが良かったですか?まずかったですか?
ヒント1:まずは良し悪しを見てみましょう!
ヒント2:つまり、一言で言うなら、どういうことでしょうか?(教訓化)

そして、最後に「つぎにやること」です。わかったことが本当に良さそうかどうかの検証や、他の人の話を聞き、試してみたいことなどを書きます。

# T: つぎにやること<個人ワーク、シェア>

わかったことを踏まえ、あなたは次にどんな行動をしますか?

ヒント1:できるだけ具体的にしてみましょう!
ヒント2:わかったことが良さそうか、どうやったら確認できそうですか?

ふりかえってみた実際の内容

実際にふりかえり会をやると、色々な気づきが出てきて面白いです!

例:TIPS

例えば、事前にメンティーに質問回答してもらって1on1するといったTips的な話などは、出やすい話です。

事前に、Google Docsで質問回答してもらい、1on1の時は画面に回答を映しながら議事録を取るスタイルが良い。
メンター、メンティーで意識を揃えながら進行できて、かつ、回答の準備ができる。
シリコンバレー式のテンプレが便利

例:コミュニケーション

他には、コミュニケーションの話が出ます。例えば、メンターが「わかった?」と聞いても、「わかった」と言わざる得なかったりすると思います。あんまり意味のない質問になっちゃうんですよね。どうすればいいか?というと、メンターからは「ケースを提示して、どうするのか説明してもらう。」「わかったという言葉は信じて、話を進めて、もしわからなければつまづくだろう」といった意見が出てきました。似たような質問だと、「大丈夫?」「困ったことある?」なんていうのも同調圧力が生まれがちといった話がありました。

運営として気をつけていること

ふりかえり会の運営、ファシリテーションをしていて気をつけていることがいくつかあります。

  1. HOWよりWHY
  2. 問題解決もほどほどに
  3. 単発より継続

1. HOWよりWHY

TIPSは、目先の問題にすぐ適用出来そうで、話の食いつきがいいんですが、具体的な方法は相手次第、状況次第なところがあるので、意図・意義・理由の方の言語化をしてもらうように誘導しています。その方がポータビリティがあると思っています。

2. 問題解決もほどほどに

隣に困っている人がいればなんとかしてあげたいといった気持ちもあり、問題解決の話題も盛り上がったりするのですが、問題解決もほどほどにしています。現実的な理由として、10人弱のメンバーで一つの問題解決をするのは時間効率が悪いと思っています。また声が大きい意見に左右されるのも避けたいです。

そもそも、ふりかえり会はふりかえりの時間としています。メンター自身がどうした方がいいか自分で考えることが、内省につながると思います。 1ヶ月、メンターとして働き、どんな気づきがあったのか、どんな感情になったのか、など言語化できればと思っています。

3. 単発より継続

まず、現実的な話で言えば、メンター業務をやるような人は忙しい傾向があると思っています。なので準備負担なく、ふりかえり会の時間さえ集中すれば良い形にしています。また参加して、直接コミュニケーションしたからこそ得られたものがあるといいと思っています。参加者からするとそういった形の方が継続のモチベーションが湧くのかなと思っています。

また、そもそも育成って地味だと思っています。人は簡単に変わらないと思います。視座・ものの見方の変容ならなおさらです。 運営として、メリハリをつけるためにすごい本などで影響を受けることはあると思います。必要だと思っています。 ですが、頭だけでなく身につけるためには、地道ですがふりかえりを実施し、経験学習サイクルを回す仕組みを作ることが確実なんじゃないかと思っています。

まとめ

  • メンター成長のために、メンター同士のYWTによるふりかえり会をしている。
  • ふりかえり会の目的は、ふりかえりとメンター同士の関係作り。
  • ふりかえりのために、HOW、問題解決の話はほどほどにする。意図・意義・理由を自分の言葉にすると良い。
  • メンターの育成は長期戦。経験学習サイクルを回す仕組みを作る。

最後になりますが、運営のトレタのikegoriさんはじめ、準備などもろもろありがとうございました! 今回、自分も受付などを急遽*1やっていたのですが、おかげさまで楽しく参加させてもらいました!

*1:運営のコアメンバーが急遽体調不良という事件