Skip to content

Instantly share code, notes, and snippets.

@SpringMT
Forked from noto/1on1.md
Created March 24, 2020 08:27
Show Gist options
  • Save SpringMT/62d8694110118690db29c595e541b9ba to your computer and use it in GitHub Desktop.
Save SpringMT/62d8694110118690db29c595e541b9ba to your computer and use it in GitHub Desktop.

これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。

概要

  • 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか? マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。
  • 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。
  • グループ/チームでのミーティングを補完するためのものです。
    • みんなの前では話しづらい、込み入った内容を話します。
    • チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿っていません。
  • 基本、「メンバーの時間」と捉えてください。メンバーが話したいこと、上長に質問したいこと、相談したいことを話す時間です。
    • ですので、上長は相手の話をさえぎらず、聞くことに徹してください (話すのが得意な人、好きな人がマネージャになっている可能性が高いというバイアスに注意しましょうw)。
    • 人は話すことで自分の頭を整理して、おのずと何かに気づく、あるいは答えを見つけることがあります。それは 1 on 1 の目的のひとつです。
      • なので、上長の中に答えの仮説があっても、なるべく言うのは後回しにしたほうがいいです。むしろ「どうするのがいいと思いますか?」「どうしたいですか?」と聞くほうが良いです。
      • ただ、突き放したいわけではないので、「いっしょに考える」というスタンスでいきましょう。いくつかの案を出してあげて、どれがいいか考えてもらうのも手です。
  • ただ、30 分のうちの 5 分くらいだけは、上長としても言いづらい、もしかしたら厳し目のフィードバックをしたほうがいいです。詳しくは後述します。

1 on 1 の他の目的

  • 心理的安全性の構築: 「この場では本音で話せる」という感覚を両者で共有するということです。
  • 本音で話した時に見えてくる、チームの課題を上長が把握する。
    • 複数の人が同じ問題・課題を指摘している時は、それが本当に問題・課題であることの確度が高いです。問題解決につなげましょう。
  • 「ちゃんと見てもらっている」という感覚を持ってもらう。
    • 「自分がいてもいなくてもどうでもいい」「自分が成長することに何も期待されていない」と感じる状況だと、そういう組織にいる意義が薄れ、退職につながります。
      • 上長としてはそんなつもりがないのは重々承知していますが、メンバーに伝わってなければ無いも同じなのです。
    • 「ちゃんと見てもらっている」実感を常に感じられる会社の方がうまくいくことが多いです。
  • まじめな人ほど自己評価が低いことが多いので、そういう傾向が見える時は、できていることを指摘して励ましてください。
    • これもチームで仕事をすることの意義だと思います。
  • 「やめます」の前に「やめたいと思うことがあります」が言える、さらにその前段階として「これが気になっています」「これが問題だと思います」を健全に言えるチームにしましょう。
    • 上記のような「心理的安全性」「本音で話せる」「ちゃんと見てもらっている」「励ましてくれている」という感覚を持っているなら、何か違和感がある時、声を上げられる関係になっていると思います。
    • 先述の「問題解決につなげましょう」をマネージャー (≒サーヴァント) が実践することで、人が定着する、組織に愛着を持てる会社をつくりましょう。
    • 現在の仕事とアンマッチであれば、社内で異動することでより活躍できるようにしましょう。

5 分程度の上長からのフィードバックについて

  • 定期的に、個人目標に沿った取り組みができているか、確認できるとよいです。
  • ここまで書いたことがうまくできていると、メンバーはかなり自己肯定感を持って仕事に取り組めると思います。ただ、何も課題がない、変化しなくていいということはまれだと思います。
    • この状況で何もフィードバックしないと「何も問題がない、変化しなくていい」という暗黙のメッセージが出てしまいます。
  • そこで、今、メンバーにどんなことをフィードバックする必要があるかは、上長として考えておき、定期的にフィードバックするようにしましょう。
  • 上長にとっても「言いづらいことを言える場」にすることが重要です。メンバーに遠慮しすぎないように。

頻度について

  • 両者の必要性によって、毎週〜隔週〜毎月で変化させるのがよいと思います。
    • 自走性が高い方、自分で問題解決できていて相談事項が少ない人は少なめでよいと思います。
    • 極端なことを言うと、新卒であれば毎日の終わりに 15 分やるくらいでもいいです。
    • 話す内容がないから、忙しいからとスキップしすぎると、なんとなく「あなたと話す価値はない」という雰囲気が出るので、気をつけましょう。頻度を調整する方がベターです。
  • 全エンジニア、最低限毎月実施されている状態を維持したいです。

ちょっとしたテクニック

  • 話したことはメモしておくと、相手とどんな話をしたか記録が残っていくのでよいです。当然ですが、話したことをちゃんと覚えていてくれる、というのは心地よいものです。
  • 「なんでも話していいですよ」「あなたの時間です」と言っても「特にありません」という人もいます。そういう場合は、雑談っぽいことも含めていいので、相手に興味を持って聞きたいことを聞いてみてください。
    • 前回のメモを見て、気になっていることに関して、「あの件その後どうなりました?」と聞くのもありです。
    • 面接と同じですが、質問しながら相手が困っていることや、この話題だとどっと話し始めるポイントを探っていってください。
  • やりたいこと、どういう人になっていきたいかはっきりしていない人については、粘り強く「どうしたいですか?」と聞き続けてください。
    • 自分としてどうしたいか、何が譲れないかはっきりしていない人ほど、ちょっとしたことでメンタルを崩して退職を考え始めたり、パフォーマンスが落ちたりする傾向があります。
    • 自分としてブレない軸が何かをいっしょに探っていくのは、強い組織の基盤になると考えています。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment