はじめに
社会人になって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倍 (バッファ)
- 予実から自分の力量を把握し、バッファをタスクに合わせて調整できるようになる
- 不確実性の低いタスクは少なく、高いタスクは多く
- オーバーした要因は記録して、改善へ繋げる
- 見積もりをレビューしてもらう
- 言われた期日に合わせにいかない
- 間に合わなければチームに迷惑がかかるし、品質が落ちればユーザに影響が出る
- ●●すると工数は■■減る、という提案をできるようにする
- 自分で言った見積もりは死守する
- 互いの信頼で成り立っている。約束は守ろう
- 進捗はこまめに上長に報告し、遅れの発生を早めに検知して調整する
- 「工数一日」は「明日できる」じゃない！エンジニアと非エンジニアのギャップとは
- エンジニアが知っておきたい工数見積もり術！
- プログラミングで一番難しいのは「見積もり」だと思う
▼キャリアっぽい話
- 変化が激しい業界なので絞り過ぎない
- 大掴みでこのくらい、で悪くないと思う
- 明確にしすぎると「これは関係無い」とか考えてしまいがち
- ロールモデルを見つける
- 好きなこと、楽しいことはそれだけで武器
- 苦手を補う
- 苦手だから上手く人を頼る、も一つの解決策
- ここを意識しすぎると良くない。割り切り大事
- スキルの掛け合わせが価値になる
- デザインもできるエンジニア
- 企画もできるエンジニア
株式会社自分を経営している、という視点で自分を俯瞰すると良いと思っている
自分というキャラクターを育てる育成ゲームをプレイしている感覚もアリ
■エンジニア
『コードを書くだけがエンジニアじゃない』
▼全般
▼実装
- 方針は複数考え、比較検討する癖をつける
- 工数
- 影響範囲
- 保守性
- 拡張性
- ✕作りながら考える ◯考えてから作る
- 2割アテは様々なことに有用
- 別にパソコンがなくてもプログラミングはできるよ
- 「意図(なぜ)」を説明できるようにする
- コピペは悪
- 読みやすいコードを書く
▼コードレビュー
- コードの品質を高め、チーム内で良いコードの共通認識を作っていくのが目的
- コードに対する指摘は人格否定ではない。人格否定しない
- 「〜かも」や絵文字などを活用してみるとか
- コードレビューの極意。それは「自分のことは棚に上げる」こと！！
- 良いところや質問も全然OK
- 他人の実装から学ぶ
- クラス設計
- 関数の分け方
- 命名
- 「自分ならどう作るか」と考えてから比較しつつ読む
- 漫然と読むと経験値を取りこぼす
- 指摘を貰える = レベルアップのチャンス
- 指摘されたところはメモしておく
- 同じ指摘を何度もされないように
■組織活性化
- 【大前提】向き不向きは確実にあるので無理しない
- やってみると意外と、というケースがあるのでチャンスがあったら食わず嫌いしないのをオススメ
- 組織施策に関わる際は上長、周囲に共有する
- メリット
- 開発とは別種のタスク/チームで動くのでタスク管理や頭の切り替えがうまくなる
- 名前と顔を覚えてもらえる (情報やチャンスがまわってくる)
- デメリット
- 忙しい
- 環境によっては周囲の理解が得にくい
損得勘定で始めるのもアリだけど、「自分たちの組織を自分たちで良くしていく」という想いに至ってくれると嬉しい