見出し画像

エンジニアリングマネージャーがエンジニアのキャリアに責任を持つためのスタンス

この記事は Engineering Manager vol.2 Advent Calendar 2018 14日目の記事です。

はじめに

こんにちは、こんばんは。恋愛・婚活マッチングサービスのPairsを運営している株式会社エウレカでCTOをしている @kaneshinです。
エウレカのエンジニアトップとして、Pairsの事業戦略を踏まえてプロダクトがビジネスで結果を出し続けるための技術面や蓄積されているデータをどのように活用していくかの長期的な視点と広い視野で戦略を考えています。

日本のスタートアップではCTOがVP of Engineering(以後、VPoE)のような、エンジニア組織の組成やマネジメントを職責として持っている人は多いです。私もそのように幅広くCTOとVPoEの職責を持っていますが、会社のカルチャーをより良いものにしていくためにやれることは尽くしていきたいです。

VPoE不在で夜も眠れない問題?

昨今、日本のスタートアップでも会社のサイズがエンジニア以外も含めて30人ほどの規模でもCTOとVPoEの二頭体制も珍しくなくなってきた印象があります。このように早いサイズのときから二頭体制で権限も明確になっていれば、非常に良いと思います。ただ、それが難しいのも現実問題として存在しています。

だからといって悲観的に捉えず、より強固な組織をまずはひとりで作り上げるということも重要です。

自論ですが、会社に在籍する全エンジニアが60人までなら、CTO、もしくはVPoE単体であってもエンジニアリングマネージャーと連携を取れば回せると思います。しかし、これを超えてくると物理的に不可能だなと感じています。

不在だと何が問題なのか?
端的に言ってしまえば、技術戦略とエンジニア組織戦略(マネジメント)のトレードオフとなる事象が発生したときの意思決定が鈍ることです。今後の技術戦略を考え続けることは非常に重要です。しかし、それを執行するためには必ずエンジニア組織のことを考えなければならないということは、本来できたであろう技術戦略を策定できな可能性を秘めています。

眠るために、自身のキャリア/マネジメントのスタンスを知る
不在であるからトレードオフの中で「事業に振るべきか」、「人に振るべきか」というのを、自身の中である程度の道筋を立てておくことが大事です。ただし、その中で重要なことはマネジメントには正解がないことです。十人十色、人にはそれぞれ違った価値観があり正解なんてありません。それを踏まえて、自分が正しいと思ったことを相手の価値観を尊重して伝えることです。

さて、本題になります。今回は、マネジメントをする中で参考になるような法則やスタンスをご紹介します。

注:本記事は個人の見解であり、所属する組織の公式見解ではありません

ダニング=クルーガー効果

エンジニアに顕著に見られる自信と知識を踏まえた学習段階には
 ・(C++) 完全に理解した💪(SDK開発できる)
 ・(C++) わからない😖(SDKを熟知した)
 ・(C++) ちょっとできる😣(SDK開発できる)
のような理解曲線があるのは知られたことだと思います。こちら、実はしっかりとした名前が存在しています。

少しでも開発ができるようになると、アプリをひとつ作るのも容易になってきます。そうなってくると自分ひとりで開発ができるので、もう学ぶことがないと思うようになってしまいます。無論、それでいい人もいますが、これからのエンジニアキャリアを進む上で、RASISのようなコンピュータシステムの指標を求められることや、それこそ品質上での非機能要件を求めるためにSDKやフレームワークの内部を知らなければならない場面が出てきます。

最初からそれを学ぶことも時間対効果を踏まえるといいものとは思えませんが、いつかは必ずぶち当たる壁になるはずです。そのときまでに必要な勉強や周辺領域の知識を深めておくなどのティーチングを行うべきです。

RASIS
 ・Reliability(信頼性)
 ・Availability(可用性)
 ・Serviceability(保守性)
 ・Integrity(保全性)
 ・Security(機密性)

1万時間の訓練

先ほど、の学習曲線の中で「完全に理解した」から「ちょっとわかる」というところになるまでに、ひたすらコードを書き続けることも重要です。ときには車輪の再発明を恐れずに写経も兼ねて質の高いコードを模倣することで相手の思考やスキルを奪い取ること。また、寝食を忘れるくらいコードを書くことが好きなエンジニアは多いと思います。そのような人をどのようにサポートしていくかもエンジニアリングマネージャーのひとつの仕事だと思います。

開発エコシステム整備され過ぎ問題

さて、1万時間を費やすにあたって、昨今は初期開発のエコシステムが整備されていることがメリットを多く享受するも、デメリットも発生していると感じます。ただ、デメリットの中には初学者にはまだまだ必要のないトラブルシューティングの解決から学べる周辺知識もありますが、GitHubを活用することで多くの知識を手に入れることができます。それこそ、READMEをしっかりと作り込むのは当たり前で、ソースコードをチェックアウトしてきたら即時に使えることも当たり前要件として存在します。

柱となるスキルを深くするために、知識を広くする
広い知識を手に入れることができるGitHubには感謝しかありません。しかし、初学者の人は深くスキルを身につける前に違うことへ興味が移ってしまうデメリットが生じている可能性もあります。

自身の柱となるスキルを深くするために、知識を拡げていくことには賛成します。しかし、知識を拡げたいために、さまざまな技術領域に触れることは、自身のキャリアに対して集中と選択ができていません。それを止めてあげるのもエンジニアリングマネージャーの仕事のひとつです。

ティーチングとコーチング

それでは、毎回の1on1や定期面談において指摘をし続けたら、相手は常にあなたの回答を待ち続けてしまいます。これでは、相手のキャリアをあなた自身がないがしろにしてしまう可能性があるので、タイミングを見計らって相手に思考を促すこともしなければなりません。

そのスタンスを持つために、ティーチングとコーチングを切り替えて接していくことをオススメします。

ティーチングとは、何かを実施するにあたり習得すべきスキルや知識を教えてあげることです。勉強会を開催して、自分が持っている知識を伝えていくこともこれに当たります。
では、コーチングとは、何かを実施するにあたり、どのようにやるべきなのかといったプロセスに対して質問をしてあげることにより、相手に気づかせることです。

思考力とは、まず「認識すること」からはじまり、次に「気づくこと」で徐々に意識が変わってきます。そして、気づいてから「行動に起こすこと」で自身の思考力が向上していきます。

今回、お伝えしているマネジメントのスタンスも同じで、まずは知ること。知った後に気づいて行動に起こすこと。これらを忘れずにいることがエンジニアリングマネージャーにとって重要なスタンスになります。

おわりに

途中でもお伝えしましたが、マネジメントには正解がありません。ここで紹介したことはほんの一握りのスタンスと捉えて参考程度に留めてください。このようなことを相手の価値観を考えずに伝えることは、価値観の押し付けでしかありません。

しかし、本当に相手のことを常に考え続け、いまこそ伝えるべきだと思ったときが来たときは自分の言葉=本心で伝えていきましょう。


この記事が気に入ったらサポートをしてみませんか?