エンジニアのチーム開発 〜1on1ミーティング始めました〜

最近、チームリーダーを任されてから、密かにやりたいと思っていたこと。
メンバー同士の1on1ミーティングを、ついに始めることにした。

(最初は新規メンバー向けにやろうと思っていたが、全員でやることにした)

ちょっとした夢が叶った気分だ。
まだ始めたばかりで試行錯誤中だが、途中経過をお知らせしたい。


# 1on1ミーティングの何が良いの？

この本が参考になった。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/89618/6fae3007-2530-19cc-fece-6982b38e191e.png)

( シリコンバレー式 最強の育て方 ― 人材マネジメントの新しい常識 1 on1ミーティング―  )


## 個人の対話が重要

組織において、人の問題が生じるのは個人の対話の不足にある。
つまり、個人同士の対話をおこなうことで、人の問題を改善することが出来る。

この説明が腑に落ちた。

最初は「1on1は、なんだか良い気がする」「でもよく理由は分からない」という状態だったが、必要な理由を言語化して認識できるようになった。

## 問題解決ではなく課題発見の方法

1on1ミーティングは、問題解決ではなく、課題発見の場だ。
つまり、何か問題が生じてからおこなうのではなく、積極的に良い効果を生み出していくことが出来る。

たとえば、体に良いものを食べるのは、病気になってからじゃなくて良い。
たとえば、運動をするのは、足腰が立たなくなってからじゃなくて良い。

むしろ問題が起こる前にやっておいた方が良い。

# 課題. 心理的抵抗

一番のハードルは心理的抵抗じゃないかと思う。
そもそも何を話したら良いのかという。

## 対策. スケールダウンして、とりあえず始めてみる

やりづらいなら、次の方法が良いかもしれない。

- 最初は顔合わせだけにする。
- 最初に話すのは、1分間だけで良いことにする。(馬鹿らしいぐらいがちょうどいい)

(スケールダウンの技術については「小さな習慣」を読んでみよう)

![image.png](https://qiita-image-store.s3.amazonaws.com/0/89618/22e75dfc-4ea1-b677-0582-87ada7d83039.png)

## 対策. 話すトピックを用意しておく

メンバーと話すことを、あらかじめ用意しておく。
「いくら考えても、気になることがひとつもない」ということはまずないはずだ。

トピックの例は後述する。

## 対策. 本を読む

1on1関連の本を読んで、どんなやり方があるか調べておく。

# 課題. メンバーの理解を得る

メンバーの同意があることは大前提だと思う。

嬉しいことに今のチームでは、全員が賛成してくれた。
いざ話しても賛同を得られるかどうか、ドキドキしていたのだけれど。


# トピックの例

1on1では、何を話せば良いのか。
可能性は無限にあると思うが、例を挙げてみる。

- 「1on1ってどう思いますか？」「どういう風に進めていきましょうか」というメタ的なことを話してみる。
  - 手探り状態で、やり方が決まってないなら良いかもしれない。仮に大枠のやり方が決まっていても、相手によってベストな進め方は違うかもしれない。
  - 何も出てこないようなら、まずは1on1自体の方針を決めるために1on1をやってみても良いかもしれない。
- 1on1の本を読んだ中で、自分が気になった部分について話してみる。
  - たとえば「雑談を交えた方が良いって書いてあるけど、どう思いますか？」「僕は雰囲気も砕けるし、良いと思うんですけど」みたいな感じで。
- 前職があれば、前職での働き方を聞いてみる。(前職の環境は、今の働き方に影響を与えている可能性が高いのではないかと、個人的に思っている)
- 自分が、なぜ1on1を始めるに至ったかの経緯を話してみる。
- エンジニアを始めたきっかけを聞いてみる。
- 普段、どんな風に勉強しているのかを聞いてみる。
- 「最近のチームって、どうですか？」とざっくりと聞いてみる。
- 個人的に気になっていることを聞いてみる。
  - チーム改善とは全然関係ないように思えるトピックでも、この機会だから聞いてみる。ひとつのトピックから思わぬ話題に広がることもあるし、これは一石二鳥のチャンスだ。
- メンバーの仕事の進め方や、やってくれていることで、いま感謝出来ることを伝えてみる。
- 自分がメンバーに対して、持っているイメージを伝えてみる。
  - 「アイアンマンみたいに活躍してくれている」とか。
  - 「バットマンみたいに、闇夜でチームを支えてくれている」とか。
- 雑談してみる。何か自己開示しても良いし、何か聞いてみても良い。
- 最近のコンディション、体調を聞いてみる。最高が10で最低が1なら、最近はどれぐらいか。
- 自分が相手からアドバイスをもらいたいこと。
- 他のメンバーに対して気になることや、雑談。他のメンバーの良いところを聞いてみる。
 
# 具体例


## まずは歴史を伝えた

- 僕がまた別の先輩から、教えを受けていたころの歴史を伝えた。(その時は明確に1on1というくくりではなかったが)
  - その先輩もまた、さらにその先輩から学んだものがあったという。
  - その先輩の先輩もまた、その先輩の先輩の先輩から何かを学んだのかもしれない。
  - 今まで受け継がれてきたものがあり、これからも続いていくかもしれない。
- なぜ1on1をするに至ったかの説明をした。
  - 「今までチーム改善のために、具体的なコストはかけてこなかったが、今回から、本腰を入れてやってみることにした」
  - 「この1on1がチーム全体のためになると思っている」
  - 「僕自身も、チームとしてもまだ手探り状態で、いまからベストなやり方を探していきたい」

## 「なぜやるか」の理由を伝えた

ごく基本的なことだが、大前提を共有した。

- チームとして成長したいから
- それぞれのメンバーにも良い影響があると期待しているから
- 僕自身もチームへの取込むをおこなうことで、成長したいから
- 個人的にも1on1　に興味があって、やってみたかったから

## ややKPTチックにしてみた

メンバーによって目的地も、最適なやり方も変わるだろうが、一例として、こんなやり方をしてみた。
KPT(振り返りの手法)を1対1の場で回していく感じ。

### 1. スタート

- まずはゆっくりする。
- ちょっと雑談したり。
- 仕事以外のことで、話したいことがあれば、話してみる。
- 初回と2回目は、１on1自体をどう進めていくかについて話していた。

### 2. フィードバック

チームとしての課題や、気になる点を見つけて、毎回フィードバックしてもらうことにした。

- 今、チームやメンバーにどんなことが起きているか、把握したかったから。
- 課題や、そのボトルネックがあれば、それを発見したかったから。
- 時間が経つと忘れやすいと思うので、専用のメモを取ってもらうことにした。

### 3. 課題発見

- 課題が見つかった時は、その解決法を、いったんメンバーに考えてもらうようにした。
- 特に何も出てこなかった時は、メンバーと解決法を一緒に考えてみる。
- ひとつの案が出てきた場合も、さらに良い解決法がないか考えてみる。
- 何がチームのためになるかについて、ディスカッションをおこなうようにした。

### 4. 宿題

- 課題に対して、何か具体的な行動や改善策が見つかったら、次回までにやってきてもらうことにした。
- 具体的な改善策が見つからなかった場合は、改善策を見つけてもらうことを宿題にしてもらう。

### 5.フリータイム

- ノンジャンルの話は有用だ。
  - 話の展開を、偶然に任せてみるフェーズ。
  - むしろノンジャンルの話を楽しむために、1on1を開いていると言っても過言ではない。(それぐらいの意識でやりたい)
- 「僕自身に対してや、他のことでも、なにか気になること、聞いてみたいことはありませんか」と聞いてみた。
  - 自分のことをメンバーから質問されて、質問されるのは嬉しいことなんだと気付いた。
  - 1on1の場で改めて質問を受けると、ふだん雑談で聞かれるのとは、また別の趣がある。

# TIPS

気をつけたことや、分かった、小さなことたち。

## オープンな取り組み

そもそも1on1は、チームとしての成長のためにおこなう、ポジティブなもの。
メンバーと話した内容自体はシークレットだが、1on1自体の存在はオープンで良いと思う。


## 改善点聞くときは宿題にしてみても良いかも

- たとえばチームとしての改善点を聞く時は、義務や宿題にした方が良いかもしれない。
  - 単に「気になるところや、改善点はありませんか？」と聞くだけだと、遠慮してしまって、トピックが出てくる可能性が低まるんじゃないだろうか。
  - 「次回までに、チームで改善できそうなところや、気になるところをリストアップして、教えて欲しい」などとお願いしてみた。
- 「他のメンバーの良いところを聞く」という手法も本に載っていた。こちらも、すごくアリだと思うのでやってみたい。

## 焦らずゆっくり話す

この話は、ごく個人的な属性によるかもしれない。

テレビでは3秒の沈黙があると放送事故になる。
だけど1on1はテレビではないので、気にしなくて良い。

僕自身、ひとつのことを考えて話すまでに、けっこうじっくりと時間をかけるタイプだ。
なので、話している最中に答えが出てこない時間があっても、焦らずにゆっくり答える。
時には60秒ぐらい考えていることもある。

相手にも、急いで答えることを求めない。
答えが出てこなかったら来なかったで、それは「今は答えが出ないことが分かった」という成果だ。

## メッセージの伝え方

- あくまで1on1は、ポジティブな効果を期待して、話し合う場所であることを強調したい。
- 課題発見や問題解決はどうしても「否定」というイメージにつながりがちだと思うので、メッセージの伝え方には慎重になるよう意識した。
- 「これは個人に対してではなくて、あくまでチームとしての取り組みである」という基本を、意識して何度か共有してみた。

# 今後、やってみたいこと

- あたたかいドリンクや、好きなドリンクを飲みながらやってみる
- 軽く音楽をかけてみる
- クッションを持ち込んで、もふもふしながら話してみる
- 1on1関係の本も他に出ているみたいなので、読んでみたい。

# 備考


## チーム構成

僕を含めて4人の少人数チーム。
だが1on1の組み合わせは、6種類もある。

## 場所

本当はスターバックスでやりたいぐらいなのだけど、プライベートな話もするので、会社の個室を使っている。
でもなるべく雰囲気の良い部屋を取りたい。(窓がある部屋がいい)

## 時間

30分ぐらい。
早く終わっても良いし、少し長引いても良い。

## 頻度

どれだけ少なくても、1メンバーあたり月に1回はやりたいと思っている。
まだ本当に始めたばかりなので、具体的には決まっていない。

# NOTE

- [いまのチームはプログラマが 3 人, 上司が 1 人いる. 一年前, プロジェクトが始まったときのプログラマは年寄 A と若者 B の 2 人だった. - Backnumbers: Steps to Phantasien](http://steps.dodgson.org/bn/2009/12/31/)

# あわせて読むかい？

- [エンジニアの新人教育 〜メンターとビギナーの日々是セッション〜 - Qiita](https://qiita.com/YumaInaura/items/128d1e37f7f72f176d87)








<!-- Update From Qiita API -->

# チャットメンバー募集


何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。

https://line.me/ti/g2/eEPltQ6Tzh3pYAZV8JXKZqc7PJ6L0rpm573dcQ





# Twitter


https://twitter.com/YumaInaura


<!-- Update From Qiita API -->