コンサルティング同行で学んだ、エンジニアリングマネージャーとして新しい組織にジョインして取るべき姿勢

おはようございます。いしげ（@oturu333）です。

このブログは Engineering Manager Advent Calendar 2018 - Qiita 10日目の記事として書いています。

一般職からエンジニアリングマネージャーになり1年くらい経ったときに「ここでしかマネージャーができないんじゃないか」という思いになったことがあります。

知っている会社、プロダクト、メンバーだからできているだけじゃないかと。

そう思ったのは自分のやっていることを抽象化できなかったからだと、今になって思います。

その後コンサルティングに同行させていただく機会があり、外部の組織、人へのアプローチの仕方を間近で見て、コンサルティングの手法は新しい現場でマネージャーになるときにも使えるなと感じました。

今回はその学びをアウトプットしていきます。

エンジニアリングマネージャーの仕事だと思っていること

一言で表すならば、環境整備、仕組み作りだと思っています。

• 組織の三要素を満たす環境創り
• 共通の目的をもっていること（組織目的）
• お互いに協力する意思をもっていること（貢献意欲）
• 円滑なコミュニケーションが取れること（情報共有）
• スループットをあげるための仕組み作り
• 成長実感やビジネス貢献を感じられる仕組み作り
• 継続的な改善活動を行うための仕組み作り
• etc

これをはじめましての現場でやるにはどうしたら良いのか。

新しい組織に入って一番やってはいけないと感じていること

過去すべてやったことがあることですが、以下のようなことを気をつけています。

• べき論だけで議論すること
• 相手の知らない言語、舞台で話すこと（エンジニアではない人に対して）
• 受け身になってしまうこと
• 決めつけてしまうこと

逆に言うとこれらをしないということになるので「積極的にファクトを洗い出し、課題を見つけ、相手に分かりやすい言語で伝える」というプロセスを意識しています。

積極的にファクトを洗い出す

人を知る

一緒に働くメンバーがどんな人で、どんな技術があって、どんな仕事をしていて、どんな悩み、課題を持っているか。まずはそのあたりが知りたいです。

ただ「教えてください」と言っても話してくれる人は少ないと思うので、まずは自分から話すようにしています。

自分のキャリア、書いたブログ、こんな事を考えている、こんなことが得意 / 苦手だ、お酒が好きだ、こんな失敗をした、などなど。なんでも良いので、この人に話しても大丈夫だという信頼を得る努力をする必要があります。

主にやっていることは以下のようなことです。

• Slack の雑談板で一人語りしてみる
• ランチに誘ってみる
• なにか悩んでいることを話してくれたら、一緒に解決策を考える
• やると言ったことは必ずやって報告する

歴史を知る

新しく入った人にとっては不思議に感じるプロセスや文化も、だいたい歴史があります。

頭から否定するのではなく、その経緯や理由を詳しくヒアリングするようにしています。

ヒアリングをする際には以下のようなことを意識しています。

• 認識齟齬にならないよう、あいまいな言葉は意味やアウトプットを確認する
• 矛盾を感じるところは深く話を聞いてみる
• 歴史、現状と合わせて課題感を話し合い、認識を合わせる
• 議事録は終わった直後にパブリックな場所で共有する

あいまいな言葉は「大変」「複雑」「忙しい」というような個人によりけりなものだけではなく、一般的な言葉にも潜んでいます。

例えば「システムテストをしています」と言ったとして「システムテストだからこんなことをやるんだろうな」ではなくアウトプットまで見ないと認識がずれたりします。

総じて無邪気に、興味をもって話を聞く

誰かに何かを聞くときに「それってなぜですか？知りたいです！教えてください！」の姿勢が大事です。

例えば「どう考えてもおかしいなぁ」と思っても、斜に構えずに聞く姿勢のほうがお互いに話しやすいですし、提案も通りやすいからです。

「謙虚なコンサルティング」を読んでからこれを意識するようになりました。

謙虚なコンサルティング――クライアントにとって「本当の支援」とは何か

課題を見つける

環境整備、仕組み作りでいかに解決できるかを考えます。

すぐに100点になる必要はなく、最低限今より良い方向へ、最終的にこうなりたいまで考えられるようにしています。

相手に分かりやすい言語で伝える

nekonohitai.hateblo.jp

例えばこのプロジェクトを提案したとき「サポート切れてるフレームワーク使ってるとかダメでしょ」と言っても伝わらない状況だったので、提案資料では技術的な観点にはほぼ触れませんでした。

サポート切れの状態のままでいることで起こりえるおそろしいできごと（例：エンジニアのモチベーションが下がることによる離職率増や伴って採用、育成にかかるコスト増）など、相手が共感できる話題を探して承認をもらいました。

まとめ：最終ゴールは「相手に動いてもらうこと」であることを忘れない

組織に属していると、人や組織との関係が深くなるにつれ感情的になり、主張をおしつけあってしまうことがあると思います（私はこれが大いにあります）。

ただ、コンサルティングに同行して強く感じたのは、私が本当にやりたかったことは「相手に動いてもらうこと」だったということです。

動いてもらうというのは「承認してもらう」「一緒にやってもらう」「誰かに何かをやってもらう」などです。

このゴールを失わないための姿勢を、コンサルティングから得ることができました。