失敗から学んだ１on１の重要性。DMM松本勇気の過去から紐解く「組織のポテンシャル」の引き出し方 - エンジニアtype
コメント
注目のコメント
・上の立場として、下のエンジニアの士気が落ちてきたら
「全メンバーと個人面談を行いました。いわゆる１on１ですね。メンバーが今どんなことに悩み、何を求め、どこに課題を感じているかを把握するためです。」
・ただ、気をつけることとして
「CTO会などを通じ様々なスタートアップのCTOに、相談に乗ってもらいました。その中で最も心に残ったのが、「エンジニア受けしそうな待遇や制度づくりを先行させてしまうと、返って反発を招くかもしれない」という助言でした。」
・つまり
「話も聞かずに仕組みや制度だけ用意されても、ネガティブの根源の解消にはつながりませんし、喜んで受け取る人はいません。「まずは、一人一人と誠実に向き合うべきだ」と助言してくれたのが、エムスリーのグローバルCTO、ブライアン（Brian Takashi Hooper）さんでした。」
参考本: 『HIGH OUTPUT MANAGEMENT』（日経BP）
・わかったこと
「急成長のツケをエンジニアに背負わせていたことを痛感しましたね。例えば、それまで深夜に緊急対応してもらっても、エンジニアの負荷を減らしたり、貢献に報いたりするような仕組みは整っておらず、不満がオリのように蓄積された状態でした。」
・さらに気をつけてやっていたこと
「意識的に行っていたこととして、悩みや不満を拾い上げたら、その後定期的に「解決に向けた取り組みがどんな進捗状況にあるのか」を伝えるようにしました。仮に事情があって要望に応えられない場合でも、なぜ今これができないのかをきちんと説明することで、メンバーとの信頼関係を少しずつ再構築していったのです。他にも、コミュニケーションの密度を高めるためにミドルマネジメント職をきちんと立てるなどの取り組みをした結果、以前のような熱量やスピード感を徐々に取り戻すことができました。」
・大きい規模の会社でもやっていること
「会社が掲げるビジョン、ミッション、バリューと個人の評価を紐付け、定期的に１on１を行ってマネジャーとメンバー間で共有するようにしています。定量的な評価は事前に決めたKPIに基づいて判断し、定性的な評価は１on１を通じて把握するという方法です。」
具体的なものは記事に。
失敗しても安心できる環境をつくる。
この考え方はエンジニアにももちろん大切ですが、起業とかでもなんでも大切な気がします。
