普段週1で1on1をする際に気にしていること
1on1のサーベイがしたかった
普段週1でエンジニアとPM10人くらいに対して1on1をしている。ソフトスキルを上げるべく他社の事例も調べていたが、残念ながら明確な答えがある分野でもなく、中身がボヤっとしている記事も多かったので考えをまとめるために普段気にしていることをメモっておく。
そもそも1on1が適切なのか
いきなり話の腰を折るようであれだが、組織の健全性を保つ方法は1on1だけでないので、組織構造やカルチャーにそうことが大事だと思う。時間効率考えずに全部やろうとするのは愚策。
- 朝/夕礼
みんなで朝集まって今日やることを言い、夕方成果を報告するパターン。
伝統的日本企業的では始業/終業付近でやることも多いが、フレックス制に反しているので、現代においては朝弱い人や、時短勤務に合わせることも大切。プロダクト数が少ない、リモートワークが少ない組織むけ。
- 日報
その日の成果を書きあう。派生でその日やることも書く。
小さい会社なら営業やエンジニアの内容をごちゃまぜしてもワークする。リモートでも同じ仕組みを使える。
- 週1の定例会議
週1での全体の進捗共有。OKRをやってもよい。
単一自社サービスだとよりワークする。受託でいろんな人がやる業務内容が散在している場合は当人に関係ないノイズが増える気がする。
- 分報(minutesチャンネル)
作業ログをSlackの個人チャンネルに書く。
Twitter廃人が多い会社では抵抗がない場合も多いが、監視されているように感じる人もいる。リモートワークとの相性がよい。
- 1on1
週 or 月に1回エンジニアリングマネジャー、CXOなどが壁打ち。
マネジメント側の負荷が高いが、個別の話がしやすいので受託開発向き。Zoomなどを使えばリモートでも可。組織の人数が増えると壁打ち相手一人では破綻する。
普段気にしていること
時間は短く、コミット量に応じて調整
適度のコミュニケーションは必要だが雑談が増えすぎても良くないので時間は極力短く(15分/週)。
とりわけ業務委託で週何日かのコミット量の場合、フルタイムと同じ頻度で実施すると会議比率が上がってしまうので、業務に集中できるようにコミット量に応じて頻度を減らしています。
サーバント型リーダーであれ
極力聞く側に徹し、自分が喋りすぎないように。
古典的にはマネジャーは現場上がりの場合が多いが、PHP/HTMLとCSS書いてサーバーにポンの時代からは職種の専門化が進んでおり、組織が大きくなるにつれ本当の専門家には敵わない。横でサポートするようなサーバント型リーダーを目指すといいと思う。
一方で、Twitterでブイブイきかせているエンジニアはエンジニア人口の10%程度であり(個人の意見です)、ある程度のフルスタックさがあれば技術的な壁打ちも可能だと思う。1回に1度何かドキッとすること言えないかをターゲットにしています。
性格に応じたバランス調整も大事で、能天気な人の問題ありませんは信用しすぎず、深掘りして、内なる問題を洗い出せるのが大事。
その他
- レベルに応じた壁打ち調整
ベテランなら普通にコードレビューとか、インターン生なら簡単な教育
- 極力言わせる
人間は指示されたことよりも、自分で言ったことの定着が高いと思う。残念ながら他人の発言をコントロールするエスパーは持っていないが、何らかの目標がある場合、それをただ伝達するだけではなく、質問形式を通してうまく当人に言わせることができると人間力高いと思う。
- 天気は聞かない
よくある1on1マニュアルでは「その週の気分を天気であらわすと?」 がまあまあ載っている。実際の進捗と比べると定性的な値だし、話せばその人がどういう気持ちでいるかわかりません？
所感
新卒で入った伝統的日本企業は、フレックス制なのに朝礼があり、だいたい黒髪か茶髪、襟付きシャツマスト、会社出社マストだった。
いざ自分がマネジメント側に近づくと、朝いない人多数、Tシャツにサンダルの人もいて、髪が青や紫の人もいたりして、リモートワークは普通にする、とダイバーシティーあふれており、ちょっと損した気がするのは気のせいだろうか。
