エンジニアリングマネージャーやVPoEの実体験を通じ痛感したことと感謝

こんにちわ！　これは[「モチベーションクラウド Advent Calendar 2018」](https://qiita.com/advent-calendar/2018/mcs) 23日目の記事です。

# はじめに
リンクアンドモチベーション社の開発に参加してまだ間もないため、過去にエンジニアリングマネージャーやVPoEをやるなかで経験した、多くの悩みや失敗、喜び、感謝を通じて学んだことを中心に書きたいと思います。

ちょうど最近他社のエンジニアリングマネージャーやCTOと以下のような点について会話することがありました。
1. エンジニアリングマネージャーの役割と誤解
2. [**エンジニアリングマネージャーのコミュニケーションの考え方**](https://qiita.com/jjj20/items/d4eafc4300b3f235bdfd#%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9E%E3%83%8D%E3%83%BC%E3%82%B8%E3%83%A3%E3%83%BC%E3%81%AE%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E8%80%83%E3%81%88%E6%96%B9)
3. エンジニアリングマネージャーのオンボーディング
4. [**エンジニアチームのパフォーマンスに影響を与える要素**](https://qiita.com/jjj20/items/d4eafc4300b3f235bdfd#%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AE%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E3%81%AB%E5%BD%B1%E9%9F%BF%E3%82%92%E4%B8%8E%E3%81%88%E3%82%8B%E8%A6%81%E7%B4%A0)
5. エンジニアチームの成功
6. エンジニアチームの自己評価（!=査定）
7. エンジニアリングマネージャーを面接する際の質問
など。今回は2、4を書こうと思います。（急遽投稿日が23日になったため笑）

ご支援いただいている[Rector社](https://qiita.com/organizations/rector)の[松岡さん](https://qiita.com/matsutakegohan1@github)と[広木さん](https://qiita.com/hirokidaichi)とも今度話してみたいです！　結果をまたどこかで書きたいと思います。

注意
・スキルよりも考え方多め。
・あくまで体験して感じたことなので、学術的視点やセオリー的にはおかしなところがあるかもしれません。

# エンジニアリングマネージャーのコミュニケーションの考え方
ずっと蓄積されていく資産、と捉えています。P/LとB/SでいうとB/S。一方向ではなく、双方向で初めて溜まるもの。

## エンジニアリングマネージャー に限った話ではないのでは？
もちろん「エンジニアリング」マネージャーに限ったことではないと思います。エンジニアの場合、仕事の性質上、集中してまとまった時間を取れるかどうかが成果を左右する大きな変数であるため、都度打ち合わせすることよりも、Slackなどの非対面の方がやり取りが多く、手段も増え、ほか職種に比べて大変だと思います。

ですので、コミュニケーションに対して、一定の優先順位の意識がなければ、流れるばかりになってしまいます。「言いました」⇆「見ていません」という議論に発展したこともあります。

##体験
お恥ずかしい話ですが、初めてマネジメントした時の自分のコミュニケーションはこんな感じでした。なんでこんなことができないのか？これをこうしろ、相手の話を遮る、など今考えると酷いもので、相手の自己効力感は下がりまくる…私のいない飲み会では悪口ばかりだったと思います笑　＊１０年ほど前です。
<img width="377" alt="スクリーンショット 2018-12-23 23.26.39.png" src="https://qiita-image-store.s3.amazonaws.com/0/324205/a75548fe-1542-346a-0b1e-f1e987d8b5ae.png">


そもそも変化の激しい（VUCA）の時代では事業の前提条件が刻々と移り変わります。制約が大幅に変わる可能性が高く、指示通りに頑張るだけでは必ずしも結果が出るとは限りません。もはや特定の誰かが変化をとらえてアクションを考えるのでは間に合わないほど変化する要素が増えています。だからこそ、各自が考えて行動できる自走型になる必要があるのだと思います。

言葉では自主性や自走を求めながらも、前述のようなコミュニケーションやマネジメントスタイルでは人は去るわ、みんな楽しそうでないわなど、当然の結果だったと思います。

粘り強く指導してくれた当時の社長、後輩のおかげでようやく改めることができ、以下のようなスタイルに変わって行けたと思います。結果、離職率も激減し、目標も達成する組織へと変わっていけたと思います。

<img width="373" alt="スクリーンショット 2018-12-23 23.27.53.png" src="https://qiita-image-store.s3.amazonaws.com/0/324205/0785b60b-7e15-257f-2d6b-15c3b2c3ed5b.png">
加えてたまたま「大量のコミュニケーションが仕事をより早く円滑に完了させている」という研究結果 （ハーバードビジネススクール　Tsedal B.Neeley教授ら）というのも目に留まり、量を増やすことも合わせて、コミュニケーションを改善していきました。

コミュニケーションだけで全てがよくなるわけではないと思いますし、相手のレベルや内容によっては指示や強い命令も必要だとは思いますが、
[広木さん](https://qiita.com/hirokidaichi) の [心理的安全性ガイドライン（あるいは権威勾配に関する一考察）](https://qiita.com/hirokidaichi/items/5d8c4294083d85654a04)
にもある心理的安全性への影響は大きかったと思います。

##具体的にやったこと
効果が高かったと思うことを５つ。どれも地味です。。。

| アクション       | 補足 |
|:-----------------|:------------------|
|日報や週報へは必ずリアクション|どんなに忙しくても移動時間など1日に5分、10分は取れるはずです。|
|1on1|重要性やノウハウはいろんなところで言われていますので割愛します。試行錯誤の中でも特に、上下だけでなく、斜めも/8割は相手に話してもらう。聞くことへのコミットメントが大事/相手のための時間と位置付けて、対象者にテーマを設定してもらうようにすること、などが気づきが多く効果的だったと思います。|
|態度（ex.話を聞くときはスマホやパソコンは触らない、ちゃんその人を向く（足を組んだり踏ん反り返ったりしない）|心ここにあらずの態度として伝わってしまいます。メラビアンの法則（人は非言語の要素で多くを伝えている）　|
|Slackなどのチャットとあらかじめの合意|極力見ます。どうしても全部は無理な場合があるので、ストックすべき情報、定例でフォローする設計を行い、これをメンバーとも合意しておくことがいいと思います。|
|沈黙を堪える|前述の態度にも関連しますが、当時の自分が最もできていなかったことです。沈黙が訪れると、その間に耐え切れず、自分から話を始めてしまう人がいますが、そのときはぐっとこらえてみることをお勧めします。せかすことなく相手が話し始めるのを待ってみることで、相手が自身の内側からアイデアや思いを言語化する可能性が高くなると思います。|
など。


リンクアンドモチベーションの開発組織ではパートナーさん含めてコミュニケーションやフィードバックも多く、日々気づきがあります！（飲み会にもよくお誘いいただき幸いです！）

#エンジニアチームのパフォーマンスに影響を与える要素
エンジニアのモチベーション、心理的安全は言うまでもありません。

そのほかには、
- 個々のスキルレベル
- アーキテクチャと組織の整合性（アーキテクチャに合わせてパフォーマンスが発揮できる組織や構成をデザイン。マイクロサービス、モノリシック）
も影響度の大きい変数だと思います。

加えて大事なのは、
**意思決定の精度（事業、業務理解の促進）・・・どれだけ自分たちで正しい意思決定ができるか？**
という意見が多かったです。そう思いましたし、これまで痛感してきました。

## ありがちな問題
- ほか組織やプロダクトマネージャーと社内受発注関係になりエンジニアのモチベーションダウン・・・
- スタートアップなど少数の時は開発速度が早かったが、だんだんと遅くなってきた・・・
開発組織のみが独立したプロセスで考えてしまい、事業組織との足並みがあわずに、結果として差し込み開発が入るなどして開発効率が低下する・・・

など体験したことがある人は多いのではないでしょうか。

スクラムやリーン、仮説・検証などのプロセスで解決することも大事だと思います。しかし、エンジニアやそのチーム自身が高い精度で意志決定できる状態になることが望ましいのではないか？と思います。

## そのために必要なことは？
エンジニアがビジネス（お客様、市場、競合、自社）について深く理解することが必要だと思います。会社が置かれている状況と、その状況で成功していくための戦略を、確実に飲み込むこと。全体の目標、戦略、期待、収益、機会、脅威、どのように利益を上げているのか、もっとも大切なことは？など。

自分自身もまだまだなため、自戒９割ですが、とても大事なことだと考えています。

## なぜか？
ゲームなどのtoCやエンジニアのコードが直接売上などの数字にヒットするような領域の場合はその限りではないかもしれませんが、エンジニアが技術領域だけに目を向けてしまい、（それが意図を持ってコントロールされたものでない場合、）自分が携わるビジネスに対して受け身にしかなれず、それでは多くの場合、やらされ感が積もるし、営業やコンサルなどのほか組織と受発注関係になり兼ねません。もちろん開発や運用などのスキルは広く、深いに越したことはないですが、技術を使って、ビジネスをどうドライブするか？この意識と経験値の蓄積が重要だと感じています。

そのためにはやはりビジネスの理解が欠かせません。持っている情報が同じで、価値観が揃っていればそこまで大きくずれたりもしないとも思います。ですので、継続的にコンテキストの理解を促す仕組みも必要だと思います。

## 具体的にやったほうがいいと思うこと
これについては銀の弾丸的なものはないと思いますし、特効薬は見つかっていません。。。営業同行することや勉強会、KPIツリーなどで同じことを見るように、など。継続的なコンテキストの共有としては、会議体の設計もとても重要だと思います。きちんと情報が流れる設計になっているか？などなど。

そのほかに、実績のある他の方から聞いて、他社や市場の理解のために、「個人の取り組み」としてこれはよかった！と教えてもらったものを１つだけ紹介いたします。

**expoなどの展示会やイベントに行きまくること**

とのことでした。多くの場合無料ですね。とても活きた最新の情報が学べて有意義だったとのことです。

リンクアンドモチベーションでは、このイシューに対し、オンボーディングから継続的に学ぶ仕組みがしっかりしており、学びがとても多いです。今度整理できたらどこかの機会にアウトプットしたいと思います。

#最後に
このアドベントカレンダーの取り組みを通じ、パートナー様もみなさんとても積極的に書いていて驚くことばかりでとても素敵だと感じました！今後もこういったことを継続していきたいと感じました。

リンクアンドモチベーションは組織やモチベーションを大事にする強烈な文化があります。これは日々強く感じています。引き続き、より良いサービスの改善に向けて組織で一丸となっていきたいと思います。

今回は全てを書ききれていませんが、ご意見、ご感想や「うちはこうしてるよ！」みたいなコメント大歓迎です！