More than 3 years have passed since last update.

新卒のトレーナーをするときの個人的まとめ

Last updated at 2020-07-21Posted at 2019-10-15

はじめに

社会人になって5年以上経過し、トレーナーを担当することも増えたので、
自分の新卒時代やトレーナーをやっている中で大事だなと思ったことまとめ。
働き方とか多め。技術系は良記事が多数存在しているのでリンク辿る形。

業界でいうとソーシャルゲーム系。

自分はこの内容をトレーニーにも共有して、週次の振り返りの際に、遭遇した事例と関連付けたりする形で使用している。

■トレーナーの心得

『やってみせ、言って聞かせて、させてみて、ほめてやらねば人は動かじ。
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。
やっている、姿を感謝で見守って、信頼せねば、人は実らず』(山本五十六)

トレーナーの役割は覚えさせることではない、トレーニーが1人で成長していけるようにすること
自分は自分、相手は相手。自分のコピーを作るのではないし、型にはめるのも違う
相手をよく見て、関わり方や教え方を変える
- 背中を見せる / 1歩先で手を引く / 隣で一緒に歩くなど
- 先に知識が欲しい / 体験とセットで覚えるなど
弱みは目に付きやすいが、それに囚われてはいけない
コーチング(引き出す) / ティーチング(教える) / フィードバック(伝える)

■職種共通

『「結果を出すから黙って見てて」みたいな働き方は違う。ビジネスは結果が全てだけど、それと同時に組織で働くということは上司からの期待や信頼、仲間からの理解や共感があって成り立っていることだから。自分だけの力でやっているなんて思うのは驕り』

▼1年目の四箇条

新卒特権を活かす
- 注目度：高
- いろんな人から話を聞きやすい
- 出来なくて当たり前、成果にはボーナス付き
自分の型を作る
- タスク管理
- 頭を切り替えるルーティーン
- リフレッシュ方法
- 苦手なことのカバー方法
- モチベーションコントロール
- セルフマネジメント
  - セルフマネジメントのレベルと欠かせないスキル
自分のキャパを知る
- 仕事はマラソン
  - 無理をして体調を崩すと、周囲への影響も大きい
  - 年次が上がるほど無理はできなくなるので早めに把握しておく
- 人への頼り方を早めに覚える
信用残高を貯める
- 期待値を超える
- 信頼を裏切らない

▼仕事のしかた

敵を知り己を知れば百戦殆うからず
- 自分のことをよく分析する
- 自分のことを知ってもらう
- 人のことをよく知る
  - リスペクト大事
よくわからないまま仕事しない。納得して自分事として働く
- 納得しないままでは中途半端になりがち
- 結果を他責にしがち
自己完結しない
ベクトルの摺り合わせ
- 2割アテ
- 後からズレに気づくと大変
15分悩んだら、人に聞く (相談)
- 若手の質問を受けるのもトレーナーの仕事の内
- 質問/相談のレベル
  - Lv1 : 問題提起のみ
  - Lv2 : 問題提起と解決案
  - Lv3 : 問題提起と複数の解決案 (メリ/デメ付き)
  - Lv4 : 問題提起と複数の解決案 (自分なりの評価済み)
  - Lv5 : Lv4を踏まえて承認をもらうだけ
- 前提知識が不足していると暗中模索になりがち
- 「質問の仕方」で、自分のアタマで考えているかどうか分かる
- 【Amazon】報・連・相の技術がみるみる上達する!
仕事の進め方イテレーション
- 朝に1日の作業予定を組み立てる
- 作業進捗に合わせて、都度調整
- 帰社前に予実を検証し、翌日以降に改善する
逆算思考を身につける
- ゴールを設定し、プロセスを明確にする
- 逆算するためにも現状把握は重要
緊急度と重要度から優先順位をつける
- タスクを実行に移す時は”緊急度”と”重要度”で４つに分類する（前編）
問題を構造化する
- 問題解決能力の高い人と、そうでない人の本質的な差異はどこにあるのか。
仕事を分解する
- エンジニアなら「要件定義」「調査」「認識合わせ」「見積もり」「実装」「検証」が大項目
工数の見積もりをする
- 見積もりは技能職だけのものではない
- 詳細は「見積もり」の項を参照
時間で話す癖をつける
- 今日中っていつ？
- 「◯時」の共通認識をちゃんと取る
進捗は必ず共有する
- 漏れに気づいたり、他の人の作業との競合に気づいたりするため
- 突然体調不良で休んでも問題なく引き継げるようにする
- 相手がどんな情報を求めているか想像して内容を考えると漏れにくい
見える化
- 自分が何をしているのか他人に分かる/見えるようにする
- 思考の整理にもなるので頭の中を書き出しておくのはやっておくと吉
人に依頼する際の重要項目
- 目的
- 期日
- なにをすると完了なのか
- リマインド
人に訊く際は「要件と概要」「相手の状態」「相手の理解の進行」に注意
- 自分のメモリの状態と相手のメモリの状態は違う
  - 自分はその問題をメインに考えているけど、相手は数ある内の1つ
- IT業界でありがちな説明下手について
改善案は努力目標ではなく行動まで落とし込む
- 気をつける、では変わらない
完璧を求め過ぎない
- 残り1割の罠 (90%→100%にするには0%→90%と同じくらいコストがかかる)
- 理想と現状を踏まえて、どこを目指すラインとするか周囲と認識をあわせる
アラートを上げる
- 恥ずかしいことではない。早めの「ヤバそうです」が多くを救う
- 時間が経過するほど被害は増える
仕事の遅れは2倍のロス
- 「遅れた仕事の分」と「次の仕事の開始が遅れる分」
報告は論文の書き方が役立つ
- PREP法
情報を発信すると、情報が集まってくる
- アウトプットは知識の整理、知見の深化にも役立つ
- 周囲の力も活用して成長する

▼見積もり

1日は6hで考える (業務時間8h)
- MTGなどで実作業できるのはこのくらいと見ておく
- 残業前提で見積もらない
  - それは「いざというときの切り札」
なんとなくで見積もらない
- タスクを分解し、個々を見積もる
見積もりの単位の目安
- 0.5h
- 1h
- 2h
- 4h
- 4hを超えるならタスクを分解
合計見積もりが出たら1.5倍 (バッファ)
予実から自分の力量を把握し、バッファをタスクに合わせて調整できるようになる
- 不確実性の低いタスクは少なく、高いタスクは多く
- オーバーした要因は記録して、改善へ繋げる
見積もりをレビューしてもらう
言われた期日に合わせにいかない
- 間に合わなければチームに迷惑がかかるし、品質が落ちればユーザに影響が出る
- ●●すると工数は■■減る、という提案をできるようにする
自分で言った見積もりは死守する
- 互いの信頼で成り立っている。約束は守ろう
- 進捗はこまめに上長に報告し、遅れの発生を早めに検知して調整する
「工数一日」は「明日できる」じゃない！エンジニアと非エンジニアのギャップとは
エンジニアが知っておきたい工数見積もり術！
プログラミングで一番難しいのは「見積もり」だと思う