読者です 読者をやめる 読者になる 読者になる

星と海のあいだで

ブログタイトルが厨二なのは、ちょうど天地明察を読み終えた直後だったから。海の方は趣味のダイビングから来てます

1 on 1 ミーティングの効能

チーム 開発 働き方

https://www.pakutaso.com/assets_c/2015/06/AL001-1onakakaigi20140830-thumb-1000xauto-17440.jpg

現在、有給消化中で結構暇しているのですが、ふと前職でやったことを振り返ってみようかと思ったので、エントリにまとめてみます。

前職では私は、退職直前にソーシャルゲームの開発チームリーダーを務めていました。 最大で私含め5人のエンジニアチーム(+デザイナー1人)のチームマネジメントを担当していました。

具体的な役割としては下記のエントリがのTech Leadの役割がとても近いと思います。

d.hatena.ne.jp

ただ、上記エントリとの差分としては、

は、私が行っていましたし、Tech Lead の仕事ではないとされている、1 on 1 ミーティングも行っていました。

また、1 プロジェクトだけでなく、部門全体の方針や施策を決定するリーダーミーティングにも参加して、多少なりとも部門運営にも関わっていました。

今回は、その経験を元に、1 on 1 をやってみて感じた効能について書いてみようと思います。

1 on 1 の目的

正直、私の場合、明確な目的意識は持たずに、1 on 1 を始めました。

思いっきり原則なきプラクティスでアンチパターンを踏み抜いていますが、結果的に無駄ではなく有意義だったと思います。

状況的には、厳しいプロジェクトが一段落して、チームの運営を見直す余裕ができたので、まずはチームメンバーの意見を吸い上げるために 1 on 1 を行うことにしました。 この時点では、私のチームのメンバーは 私 + エンジニア2人でしたが、新人研修のメンターを担当していたので、他チームですが新人エンジニア1人を含めた 3 人と 1 on 1 を行っていました。

なんで 1 on 1 を始めたの

最近 1 on 1 が流行ってる(?) みたいですが、私はそれとは知らずに自チームに 1 on 1 を導入することにしました。

というのも、入社当時のチームリーダーが、私が入社する以前(4年以上前)は 1 on 1 を行っていたという話を聞いたためです。 で、その様子を知るメンバーがチームにいたので、じゃぁやってみようかと思って取り組むことにしました。

1 on 1 の進め方

2週間に一度、毎週火曜の午前中に1人あたり 30 分で実施しました。

月曜だと土日の間に何かトラブルであったり、ユーザからのお問い合わせがあったりでリスケになる可能性が高いので、 火曜の午前中に設定しました。

場所は、ちゃんと会議室を確保して、落ち着いて(時にはダラケて)話せるようにしました。

# 1 on 1 の内容

内容については、アジェンダなどは作らずに雑談ベースでコミュニケーションをとることを中心に据えました。

完全に雑談で、家庭の話でも体調の話でも個人的な土日の過ごし方でもなんでもありで、仕事からプライベートまで、とりあえず色々話しましたが、 私とチームメンバーの関係であったり、当時の環境的にはそれで良かったように思います。

話を聞くだけではなくて、話を聞き出されることもありました。

新婚旅行の話とか聞き出されたような記憶があります。

唯一、毎回意識して聞いていたことは、「最近、仕事でもなんでもいいけど、困ってることとかないか」という点です。

これだけは常に聞くようにしていました。

# 実際に話したこと

覚えている範囲で内容を列挙するとこんなかんじです。

  • 私の新婚旅行の話
  • 私の家での様子
  • 本人の体調(厳しいスケジュールの開発を終えた後だったので疲れが溜まっていないかなど)
  • 家庭の様子(ご家族の体調とか諸々)
  • 他のチームメンバーと普段どんな話をしているか
  • 飲み会の日程調整
  • ボーナスの使い方
  • 施策などの提案
  • 現在の部門方針について
  • 会社の制度について(休暇取得とか)

かなり雑談多めなのがわかると思います。

効能

こんな 1 on 1 を通した効能としては、チームメンバーの不安感を拾い上げることができるという点だと思っています。

なるべく、メンバー各自に最大限パフォーマンスを発揮してもらうには、不要な不安要素は取り除くべきだと思っています。 そのためにも、メンバーがどういったことに不安、心配を抱いているかを知れる機会は重要です。

そういった心配事の中でも、特に部門マネジメントとチームメンバーの橋渡しをできたことが一番重要だった気がします。

例えば、リーダーミーティングの議事録は部門全員が見えるMLに流して、週1 で報告ミーティングを開発メンバーに対して行っています。 しかし、共有されるアジェンダと結論からでは、各チームメンバーが抱えている疑問や心配事と紐づいていないように見えることも多いですし、 未決定の事柄やセンシティブな情報(人事関連など)については、伝えることのできるタイミングの調整も難しいことがあります。

1 on 1 で、抱えている心配事を聞いて、部門としてどのように対応しているか、もしくは今後対応していくかを話すことで、 心配事と部門の動きをつなげて説明することができました。 もちろん、既に述べたようにタイミング的にすべて答えられるわけではありませんが、メンバー個人が抱えている心配事について、 リーダーミーティングでも既に取り上げられていれば、部門として、問題に無関心ではなく今、検討を進めているところだと伝えることはできますし、 もし部門として認識していない問題があった場合には、それを取り上げて改善につなげることができます。

まとめ

1 on 1 を実施することで、心配事の芽をつむ機会を早期に得ることができるようになったかと思います。

私のやりかたで最大限の効果があったかというと疑問ですが、チームメンバーの不安に対して何かしらのアクションをとれたので、 やっぱり実施してよかったと思います。