OJTで僕のチームが伝えたかったこと

OJT

今年入社の新卒の方が大阪支社に配属になって「いきなりどっかのチームにどっぷり入るより、色んなチーム見て回る方が面白い?」ってことで、いくつかのチームを渡り歩くことになりました。

んで、僕のチームが2番目で、7月から1ヶ月間くらい一緒に仕事してました。

「このチームで学んだのはMind」

各チームを渡り歩く中で、毎回「成果発表会」って感じで、その1ヶ月で何を学んだかをみんなの前でプレゼンするんですけど、そこで

「今回、このチームで学んだのはMindでした。技術も学んだのですが、それよりも、Mindの重要さと難しさを学びました」

と言ってくれたので良かった٩(ˊᗜˋ*)و

何をやったか

プロジェクトに参加

失敗しても大丈夫な小さ目のタスクを渡してそれで学んでもらう、というのは1番目のチームでやってたので。

今回はチームが実際にやってるプロジェクトにメンバーとして参加してもらうことにしました。失敗したらあんまり大丈夫じゃないです。ま、その方が面白いよね。

ペア開発

うちのチームはペア開発をしてるので、彼もペアを組んで開発することになりました。

ここでペア開発って言ってるのは、ペアプロだけじゃなくて、開発のタスク全部をペアで相談して進めてるってことです。

ペアは毎回チェンジ

全部で3スプリントあったかな。チームは毎回ペアを変えてるので、それに合わせて組むメンバーは変わりました。色んな考え方に触れる方が面白いかなと。

役割も変わりました

最初のスプリントは「テスト」が中心のスプリントでした。次のスプリントは「開発とUT」がメイン。最後のスプリントは「プレゼン準備と運用」かな。

デイリーレトロスペクティブ

開発プロジェクトとは別で、彼のメンター(相談役)の提案で夕方に彼個人のための振り返りをしてました。

  1. 今の気持ちを一言で
  2. 今日やったこと
  3. 明日やること
  4. プロジェクト外のやること
  5. 気づいたこと•相談したいこと
  6. チームメンバー側が気づいたこと
こんな感じ。このレトロスペクティブのおかげで、日次でアドバイスして、つぎの日には改善されてたからすごい。

伝えたこと

技術面は、次のチームが教えてくれそうだなーって思ったので、主に姿勢とかそういうののアドバイスをしてました。

新卒なので、知らなくて当然なので「なんでこんなことも知らないの?」とか「なんでそんなことしてるの?」じゃなくて「それは、こうした方がいいよ」って言うだけのことね。

返事

何かを質問された時には、答えを調べてから返事をするんじゃなくて、まず返事をする。じゃないと、質問に気づいてるかどうか分かんないから。「調べて今日中に返事をしまーす」とかでいいので。

笑わない

自分が知ってることを、相手が知らなかったときに、笑わない。相手が何かミスをしたときに、笑わない。

幹から枝

まずは、話の幹を伝える。結論から伝えて、そのあと枝葉を伝える。

詳細まで調べたことを伝えるときに、まずその詳細の部分を説明したくなるけど、全体をざっくり伝えたうえで詳細に入る方が相手が聞きやすいよ。

相手の視点

何かを伝えたい時には、相手の視点で考えると伝わりやすくなるよ。あなたが理解しやすい順番で喋るんじゃなくて、相手が理解しやすい順番で喋るん。

全体理解とアウトプット

全体を理解しないと目の前のタスクを進められないって思うかもだけど、他のメンバーはそんな状態でもアウトプットがだせるん。そこは学べることがあると思う。

逆に、あなたが全体を理解しようとして、片っ端から勉強していってる姿勢は、メンバーにとって刺激になってると思う。

理解を深めることも、今の力で出せるアウトプットをしっかり出していくことも、両方とも大切だから、バランスに気をつけてね。

Get Things Doneは品質を下げてでも間に合わせるということではないよ

間に合わないからって工程をとばすのはダメね。一歩ずつが結局一番近道だよ。

間に合わないなら早目に謝ろう。

知らないことを知らないと言えること

知らないことなのに「あーまぁ大丈夫だと思います」とか言っちゃうと「じゃ手伝わなくても大丈夫そうだね」って思われてしまうし。

「どちらかというと知らないかもしれない」とか言うと「結局どっちなん?YesかNoがいい」って言われちゃうよ。

知らない事自体は全然問題ないから、「知らない」ってはっきり言ってくれた方が嬉しい。

自分で調べるか質問するか

分からないことがあったら、まずはペアに相談してね。1人で調べるのに時間をかけるより、誰かに教えてもらう方が早かったりするから。

これはどうしても自分で調べたいってのがあったら、ペアに「気になるし調べるわー」って言ってから調べたら良いし。

他のチームだと「まず自分で調べて」って言われるかもだけど。うちのチームでは「まず聞いて」ってことでよろしく。

議論

うちのチームでは、何かあるとすぐみんなで議論を始めちゃうのですが。

「この項目をユーザーがどう使うのか分かんない」とかのビジネス側の話だったり。開発側だと「この設計だとパフォーマンスでなくない?」とか「なんでこのメソッドこの名前なん?」とか「このテストケースで何を確認したいん?」とか。色々。そういう場にも参加してもらってました。

ブーメラン

とかMindについてはそんな感じのことを伝えたのですが。ブーメランで刺さるものもあって、なかなか自分の心が痛かったです。

チームにとっては

色々と質問してもらえるし、新鮮な視点で疑問をもってくれるので、色々とチーム内の暗黙知が耕されて良かった。僕らの中でも曖昧だった部分が分かったりしてね。

それと、少しでもキャッチアップしていこうと前向きに一生懸命勉強してる姿に、刺激を受けたなー。頑張ろっと。