@hidenorigotoです。現在はメルカリJPのBackendチーム全体のマネジメントをしています。以前のキャリアではマネジメントもやっていましたが、どちらかと言えば1人のエンジニアとして、ソフトウェアの設計と数多く向き合ってきました。その過程で、良い設計を生み出す設計者は、どのようなスキルを持っているものなのかと疑問を持ち、アレコレ考えることがありました。
今、メルカリでマネージャーとして仕事をする中で、この疑問は次のように形を変えました。
「マネジメントが上手いマネージャーはどのようなスキルをもっているのだろうか。」
そして、私の中で1つの仮説が浮かびあがってきました。それは、「良いソフトウェア設計者」と、「良いエンジニアリングマネージャー」には、仕事をより良く遂行するためのコアなスキルとして共通する部分がある、というものです。
ソフトウェア設計者の仕事
ソフトウェア設計は、1つの正解に向かって一本道を進むように行う活動ではありません。ましてや、パターンを当てはめたり組み合わせたりするような作業では決してありません！ 多くの場合、ソフトウェアの設計とは、正解の用意されていない問題に取り組む活動です。問題に対して何らかのアプローチを試み、さまざまな関連要素間の折り合いを付けながら、どうにかしてソフトウェアとしての良さを引き出すのがソフトウェア設計ではないでしょうか。あくまで1つの見方ですが、ソフトウェア設計者の仕事は、ソフトウェアに対するさまざまな要求、ソフトウェアの実行環境、ソフトウェアを記述しメンテナンスするプログラマーという3方向を同時ににらみながら、ソフトウェアという人工物の構造を調整することと言えます。設計者が直接ソフトウェアに手を入れて、機能する構造を作り出す場合もあれば、概念の枠組みだけを与えて意図した設計方向へ向かうように仕向けるといった、間接的な方法をとることもあります。
エンジニアリングマネージャーの仕事
一方、エンジニアリングマネージャーの仕事はどうでしょうか。Googleのreworkには、マネージャーの行動規範として次の10項目が挙げられています。
- 良いコーチである
- チームに任せ、細かく管理しない
- チームの仕事面の成果だけでなく健康を含めた充足に配慮し、インクルーシブ（包括的）なチーム環境を作る
- 生産性が高く、結果を重視する
- 効果的なコミュニケーションをする – 人の話をよく聞き、情報を共有する
- キャリア開発をサポートし、パフォーマンスについて話し合う
- 明確なビジョンや戦略を持ち、チームと共有する
- チームにアドバイスできる専門知識がある
- 部門の枠を超えてコラボレーションを行う
- 決断力がある
この10の行動規範からも分かるように、マネージャーの仕事の対象は、主としてメンバー、つまり人です。しかし、人だけを見ていれば良いマネジメントができるわけではありません。ましてや、マネジメントの教科書に書いてあることをマニュアル通りに実行する作業では決してありません！ メンバーや組織を取り巻く様々なことに目を向け、耳を傾け、関わり、行動し、得た情報を自分の頭で解釈して整理し直すことも同時に行わなくてはいけません。解決すべきビジネス課題、会社全体や他部門との協調、エンジニア個々人の状況や成長するための戦略という3方向を同時ににらみながら、エンジニア組織の構造を調整することが、エンジニアリングマネージャーの仕事だと言えるのではないでしょうか。
ヘンリー・ミンツバーグは著書『ミンツバーグ マネジャー綸』で、情報、人間、行動をマネジメントの3つの次元とした上で、「あらゆるマネジャーは、行動の世界と人間の世界と情報の世界を結びつける存在でなくてはならない」と言い、「バランスのとれたマネジメント」を強調しています。
より良く仕事を遂行するために必要なスキル
上に挙げたソフトウェア設計者の姿、そしてエンジニアリングマネージャーの姿は、かなり恣意的に取り上げたものですが、そこには「緊張関係にある複数の要素に対して、なんとかバランスを取る」という共通の構造があります。そして、活動の対象は違えど構造的に同じであるならば、その活動を上手く行うための本質的なスキルは同一のものだと思います。しかし、この本質的なスキルが具体的に何であるのかはまた別の話で、諸説あるところかと思います。私は、次の3つが重要だと考えています。
- 視点
- フォーカス
- 説明力
「緊張関係にある複数の要素」という図式を見出したり、そのバランスを見極めるには、対象を様々な視点で観察できるだけの視点の自由さを備えておかなくてはなりません。ソフトウェア設計で言えば、要求されている内容と実装するコードとのバランスだったり、ある機能のためのコードと別の機能のためのコードの緊張関係といったものです。また、メンテナンスのしやすさとパフォーマンスとの緊張関係は、ソフトウェア設計における永遠のテーマのようなものですね。
エンジニアリングマネージャーであれば、良い意味で、さまざまな緊張関係の間で仕事をすることは日常茶飯事です。しかし、時には目の前にある複雑に絡み合った緊張関係を解きほぐして、本質的な要素にスポットを当てることが大事だと思います。
「緊張関係にある複数の要素」は、1つだけが見出されるのではなく、複数の可能性が浮かび上がってくることが普通です。その時、今の状況では何に重点を置くべきかを加味し、それによってどの可能性を選択すべきかを判断します。ここで必要なのが、状況における重点にフォーカスするスキルです。
また、要素を見出す過程や、見出した要素のバランスを取る過程では、人を相手に説明するスキルも必要です。ソフトウェア設計であっても、その設計の要所を言語化して説明できないのであれば、それは設計とは呼べないのではないでしょうか。また、できあがった設計の説明だけでなく、その設計にいたる過程、つまり要素を見出す過程においても、その時点で問題となっているポイントを関係者に説明しながら情報を引き出すこともありますので、説明力は重要です。
エンジニアリングマネージャーの場合、説明力を求められる機会はもっと増えます。エンジニアメンバー、つまり人をマネジメントするためにマネージャーが使える主な道具は、コミュニケーションです。マネージャーは、チームが向かうべきビジョンと現状との差分を頭に描きながら、個々のメンバーと1対1で向き合ってコミュニケーションし、その中で様々な説明をしていきます。状況にあった説明、相手に合わせた説明、簡潔な説明や詳しい説明など、バリエーションも必要ですね。これを繰り返すことで、結果としてチームを方向づけることができるんですよね。
おわりに
いろいろ書いたことを一言でいうと「地頭の良さ」と表現されるスキルなのかもしれません。しかし、この一言からはこぼれ落ちてしまう様々な具体的な内容があり、それを拾い集めてこそ、地に足の着いた豊かな理解が得られると思います。
メルカリでは、エンジニアリング組織強化の取り組みの一貫として、Engineering Manager Drink Meetupなどのイベントも開催しています。エンジニアリング組織のマネジメントについていろいろ思いのある方は、是非ご参加ください！
（既に申し込みは締め切られていますが、参加したい方は @hidenorigoto までご連絡ください。）
