【勉強会参加記録】 ITベンチャーが語るエンジニアリング組織論とは #エンジニアリング組織論

参加イベント

lob.connpass.com

参加目的

• 『エンジニアリング組織をマネジメントする上で重要となる思考法や手法についてたっぷりとお話しいたします。』とのことで、たっぷりとお聞きしたい。
• エンジニアリング組織をマネジメントするぞと意気込んでいるが、実際に自分から見える範囲にやれることは限られている。壁を突破するヒントが欲しい。
• 広木さんのお話目当て。EM.FMの公開イベント見に来たみたいな気持ち。

トークセッション

Theme01：初期採用

事業コンセプトが決まりました。エンジニアを採用する必要があります。
・何をした？
・人事はいる？
・社員の巻き込みは？

リファラルについて

• リファラル戦争をした。2チームにわけて知り合いを誘いまくる。
  • 2ヶ月をかけて5人ほど社員を採用出来た。

事業開始初期にベンチャーから人材採用について相談を受ける話

• 事業を始めた初期が最もいいエンジニアが集まりやすい
• この時期に優れたエンジニアを一人も連れてこれない経営メンバーに、出資する必要はない
  • そういう経営メンバーには、エンジニアのカンに触るような喋り方をする人が結構いたりする

社員の巻き込みを積極的に

• 広報や人事等の採用側の人間が、エンジニアと手を取り合ってイベントをやったりして採用に活かしていく
• うまく巻き込めたコツは？
  • 自社のエンジニアに『エンジニアはエンジニアリングだけしていたい』って人はあまりいなかった
  • 長い目で見れば、優れたエンジニアの獲得により自分のやりたいことを実現出来る可能性が上がる
  • エンジニアリングだけしていたいという人には、メンタリングをしている

Theme02：チーム開発

チーム開発をはじめました。どうやる？
・ウォーターフォール？アジャイル？
・なんのツール使ってる？
・体制は？PM、ディレクター…
・役割分担やその決め方

LOB

• JIRAを使ったチケット駆動開発
• 月曜にプランニングおよびKPTを実施
• 水曜午後のみリモート可能

BizteX

• GitHub Projectをつかったカンバン（スクラムではない）
• GitHub Flow
• 毎週月曜にプランニング、他は基本的にリモート
• 対面では木曜日を中心に。柔軟に調整。
• オンラインミーティングは基本なし。
• SlackやGitHub issueでコミュニケーション

リクルートテクノロジーズ

• フロントエンドは顧客に最も近い位置にあり、要求のるつぼになりがち
• Consumer Driven Contract

qiita.com

• ちょっと前までは外製だったが、今は内製の風が吹いている
• 『新しいことをやってみたいです』という人がいる
  • 新しいことをやる際、大変であることをしっかり伝えた上で、それでもやりたいと言わせたら勝ち
  • 小さく失敗できることを繰り返せるのであれば、それは福利厚生になる
  • 大きく損害が出る場合も、影響範囲を把握した上で、うまく落とし所をつけれたら成長に繋がる

Theme03：目標設計や評価制度

目標設定と評価（査定）をする必要がでてきた
・OKR？MBO？
・定性ってどんな内容にすべき？
・スキルの向上の評価ってどうやってる？
・1on1ってやってる？頻度は？内容は？

評価制度

• わざわざ作る必要のないものなのに、わざわざ作る
  • 最終的に、社長は決裁権で社員の給料を出すことが出来るため、給料に直結するような評価制度をわざわざ作る必要はない
• 評価制度は給料を決めるためのものではなく、その人に成長してもらうための説明しにくさのコストを下げるためにある

目標設定

• 目標設定は、目標っていうゴールテープを引いて、それを達成してもらうためにある
• 目標設定が評価制度と密接に結びつくと、目標を下げる圧力が発生する
  • 評価してもらうために、低い目標を設定する
• 給与額についての説明コストが低いならば1on1だけでいい。評価制度があれば、マネージャーの期待値コントロール力に依存せずにメンバーに納得感を出すことができる

エンジニアにおける定性評価、定量評価

• Will(未来像), Can(出来ること), Must(やらないといけないこと)シート
  • マネジメントがやることは、WillとMustを結びつけること
• 定量的な指標は、QCDを評価する。
• 定性的な指標は、定量的な指標に対し、プロセスをどう回したかを評価する。マネジメントも含めてみんなのいる場で発表し、認めてもらう等。

エンジニアとしての課外活動や、業界貢献への評価はどのようにすべきか

• 本を執筆したり、社内ブログを書いたりし、社内外への認知を広めていくことで評価する
• 会社のプレゼンスが上がる＝別に課外活動ではない
• パーセント評価を一次評価者がする必要はない
• その人がパーセント評価でだけ評価される時点でおかしい

エンジニアリングマネージャーの定義は？

• エンジニアリングをマネジメントする人（笑）
• 事業を成功させるために効率的に人的リソースを動かせる人

どういう人がEMに向いてる？

• エンジニアリングでイケてる人
• プロダクトに対して責任感を持てる人
• 事業側に興味がある人
• エンジニアリングのキャリアが詰まってからマネジメントになっても、どんどんつまらないマネージャーが増えていくだけ
• マネジメントは神じゃない。親でもない。たまたまロールプレイをしている
• 目標を達成するためにマネジメントという仮面を被っているだけ
• プライベートでたまたま会った人に「あなたは成長した方がいい」とか普通言わない。マネジメントという仮面を被っているだけ
• 組織設計・ビジネス設計は、システムのアーキテクチャを設計することと何も変わらない

質疑応答

リファラル戦争について、もう少し詳しく教えて欲しい

• それぞれのチームにエンジニアを振り分ける
• 内定を出したら1p、承諾で3p
• 勝っても何も無いが、負けたらマネージャーが恥ずかしい罰ゲームを受ける
• 会社のバーカウンターを週一で解放し、そこに入社して欲しい人を呼んで丁寧にコミュニケーションをとった
  • そこに誘った人の採用率は結構高かった

マネージャーのロールプレイをしながら社員と接する場合、ドライなコミュニケーションになる。アジア的なベッタリしたコミュニケーションが出来なくなるのでは？

• 別にマネージャーのロールプレイをする＝ドライに接するわけではない
• 仕事だからといっても、人間的な関係を取ることは出来る
• 重要なのは、ロールプレイに没入した結果、自分や相手を傷付けるところに踏み込まないこと
• 『マネージャーはメンバーと仲良くしすぎない方がいい』と、上長から言われたことがある
  • マイナスのフィードバックをしづらくなるため
  • マネージャー層・経営層は軽々しく弱味を見せられないという心理がある
  • あえて距離を取らないで親しみやすくするという人もいる
  • 仲が良いから言えないという状態は、心理的安全性が低い。心理的安全性が高ければ、組織がパフォーマンスを出すために、フィードバックを言える
  • いい兄貴＝いい上司ではない。マネージャーのやるべきことは、業績を上げること
• 大体の問題が難しいのは、コンフリクトが発生しているから
  • エンジニアと仲良くしながらパフォーマンスを出すことが難しいのは、コンフリクトが発生するから
• ゴリゴリのパワハラ上司に当たると、もっとソフトに接してほしいと言われる
• 物腰が柔らかでフレンドリーな上司に当たる地と、ここには尊敬出来る人がいないと言われる
• バランスが大事

マネジメントをするメンバーがマネジメント嫌いで、ほぼマネジメントをやってない組織で7年くらいやってる。マネジメントを嫌々やっている人に無理なく楽しくできるような手はないか？

• EM.FMを聞かせてください
• 本当に嫌々な人にはやらせない方がいい。ただ、その人が本当に嫌いなのはエンジニアリングマネジメントなのか？
  • マネジメントの仕事はそれこそたくさんある
  • その人はマネジメントの何が嫌いなのか、嫌いの理由を分解して、委譲できるタスクはメンバーに委譲してはどうか
  • 「開発だけしていたい」というのと同じ口で、「決まった仕様のものを作りたくない」という人もよくいる。定義の問題。
  • 『その人の中のマネジメントとは何か』を紐解くこと

どうしてもこの人が欲しいという場合の、エンジニア採用での口説き文句を教えてください

• 「僕と社長で奥さんを口説きに行きます」
• これだけ必要なんだということをメチャメチャに伝える
• 逆に何でうちに来ないのかがわからないというスタンスで説明する
• いいミッションを作り、そのミッションベースで思いを伝える
• 業界の歴史から語り、いまこの事業はこうだから、こういう位置で楽しいことが出来ると、未来を説明する
• エンジニアが足りないから来て欲しいのではなく、あなたに来て欲しいというメッセージを時間をかけて伝える