本特集の一人目に登場するのは、NTTコミュニケーションズでエンジニアリングマネージャー（以下、EM）として活躍する牧志 純さん。

牧志さんは、NTTコミュニケーションズのR&D組織として設置されているイノベーションセンターに所属し、NTTグループ各社のDevOpsを推進するSaaSの開発にEMとして携わっている。

同組織のEMに求められる成果を「事業成長につながるプロダクトの開発と、そんなプロダクトが開発できる強いエンジニアチームをつくること」だと語る牧志さん。

牧志さんはどのように成果を出しているのか。このポジションのやりがいや課題とともに話を聞いた。

NTTコミュニケーションズ株式会社
エンジニアリングマネージャー
牧志 純さん（@JunMakishi）
東北大学大学院（修士課程）を卒業し、2009年に新卒でNTTコミュニケーションズ入社。 NTTグループ向けDevOpsプラットフォーム『Qmonus Value Stream』のアーキテクト／エンジニアリングマネージャとして活動中。 過去、エンタープライズクラウドのネットワークコントローラ開発など、同社の複数のSDNプロジェクトに従事

「動機付け」の工夫で、自律的に判断できるチームに

ーー牧志さんが所属している組織では、EMはどのような役割を担うのでしょうか。

大きく二つあります。一つは、プロジェクトを通じて生じるさまざまな問題の調整です。トラブル発生時など、何らかのコンフリクトが伴う技術判断や、他部との利害調整、チーム全体の業務の優先順位付けなどを担当しています。

もう一つの役割はピープルマネジメントです。エンジニアの育成や評価、採用のほか、1on1を通じた動機づけなどを行っています。

ーー幅広いですね。具体的な成果としては何が求められていますか？

最終的なゴールは、私たちが開発しているNTTグループ向けSaaSを継続的に成長させ、各事業に貢献し続けることです。

「事業に貢献する」をもう少し分解すると、例えば利用者数が継続的に伸びていくプロダクトを開発することはもちろん、サービスを止めないことや、いざトラブルが発生したときにステークホルダーと調整すること。

また、私がそうした役割を果たすことで、チームにいるテックリードやエンジニアがコトに向かえる環境をつくることも成果として期待されているところです。

ーーそれらの成果はどのように図るのでしょう？

利用者数の増減は定期的にウォッチしています。あとは、ユーザーに本当に使いたいプロダクトになっているかヒアリングすることで、定量・定性の両面から確認しています。

また、事業の成長につながるプロダクトを開発するために「強いエンジニアチーム」を作ることもEMの重要なミッションです。

ーー強いエンジニアチームとは？

エンジニア一人一人がユーザーに届けるべき価値を意識し、作るべきものを自律的に考えられる。そんなメンバーが集まるチームです。

もしチームメンバーが「言われたことをやる」エンジニアばかりになってしまったら、多くの人に必要とされるプロダクトは決して作れません。それに、リーダーやマネージャーだけが意思決定をする組織は結構危険だと思っていて。

そうならないように、一人一人のエンジニアがユーザーに届けるべき価値を意識し、作るべきものを自律的に考えられるような動機づけを普段から行っています。

ーーエンジニアに対する動機づけは、どのように行っているのですか？

基本的には対話です。「ユーザーの掲げるビジョンを達成するために、自分は何をしたらいいと思う？」という問いかけを、1on1やチームミーティングの場で行っています。

自分がEMとして一番やってはいけないと思うのは、エンジニアに「こうしてほしい」と一方的に伝えて会話を終わらせること。それでは「牧志さんの言っているのは、こういうことですか？」という“答え探し”になってしまい、チームの中で切磋琢磨し合うことはできません。

技術的な問題一つとっても「このバグをどう直したらいいと思う？」ではなく、「ユーザーの事業成長に貢献するにはどうしたら良いか？」という大きな課題設定をすることによって、一人一人の目線を引き上げるような対話を心掛けています。

対話といってもコーチングなどの勉強をしているわけではないので、とにかく腹を割って話すこと、解決方法を一緒に考える姿勢を大切にしていますね。

自分の役割を周囲に渡すことで、組織全体が成長する

ーーEMとして手ごたえを感じる瞬間はどのようなシーンですか？

自分が介在することで課題が解消された時ですね。以前、開発しているSaaSのトラブル対応で、チーム全体が疲弊してしまった時期がありました。

バグやユーザ問い合わせが大量に発生し、来る日も来る日も目の前のユーザ対応に追われ、エンジニア全員が息切れ状態になってしまっていたんです。

1日でも早く全ての問題を解消し、事態を収束させなくてはいけない状況でしたが、この状態じゃ事態は好転しないと思い、一度立ち止まることに。

トラブル解決までの時間が少し伸びてしまうことをユーザーに説明し、対応する時間を確保した上で、「今本当にやるべきことはなんだと思う？」とチームメンバーに問い、当事者全員で解決方法を考える時間を取りました。

アーキテクチャを変える、仕事の進め方を変える、自動化に取り組む……エンジニアの中から「ここを根本的に変えたほうがいい」「本当の課題はこれだと思う」という意見がいくつか出てきたので、私がその中から効果が高そうなものを採用し、仕事の優先順位やチームのチームの役割分担を変更しました。

結果、時間はかかりましたが何とか自転車操業の状態を解消することができました。再び業務がスムーズに回るようになり、ユーザーに価値を提供できる状態になったときは、EMの存在意義を実感しましたね。

ーーバグが発生している状況でありながら、一歩引いた視点や決断力を持てたのはなぜだと思いますか？

EMになる前に、テックリードやアーキテクトも経験し、さまざまなトラブルを経験してきたからだと思います。それこそ、バグだらけでいつまでたってもリリースできないプロジェクトや、チームメンバー同士の仲がよくなく、常にギスギスした雰囲気が漂う開発現場も（笑）

そこで私自身が現場の一員として汗をかき、トラブルの解消にも取り組んできたので「このままではまずい」という泥舟に乗っている感覚が分かるんです。

先の事例でも似たような感覚がありました。もちろん判断する怖さはありましたが、あのときは判断しない方が怖かったですね。

ーーEMはやるべき業務が多く、そのどれもが専門的な知識が求められる業務が多いと思います。EMというポジションの課題はなんだと思いますか？

やるべき仕事が多いのは、本当にその通りです。自分がEMになったのは3年前ですが、1年目は大量のタスクに追われて自分を見失いながらそれをただ処理し続ける状態でしんどかったですね。

でも時間が経つにつれて、リーダーだからといって「自分が全部やらなきゃ」と背負い込む必要はないと気づきました。

チームビルディングが得意なメンバーには、それに関する仕事を任せたらいいし、プロダクトマネジメントがやりたい人にはその役割を任せればいいと思います。

ーー人に仕事を任せる際には、どのような指針を持つと良いでしょうか？

最初のうちは、自分の得意な仕事はできるだけ自分でやり、それ以外の仕事を自分より得意な人に任せるようにするのが良いと思います。

EMは周囲から信頼を得ることが大切なので、得意な仕事に取り組んで早めにEMとしての成果をチームに見せることが大切だと思います。

そしてある程度EMの仕事に慣れてきたら、今度は将来の理想のチーム像をイメージして、そのチームに必要なメンバーを育てるつもりで仕事を渡すと良いと思います。

例えば、将来はマネジメントができるエンジニアが必要だと思ったら、あるエンジニアにマネジメントの仕事を一部任せてみる。役割を与えることは、今は足りていない力をメンバーに伸ばしてもらうのに有効な手段です。

ただ将来のチーム像をイメージするといっても、変化の激しい時代ですから、遠すぎる未来は考えません。考えられるのは、長くても数カ月後から一年先ではないでしょうか。でもそれで十分だと思います。

EMは責任ある立場なので、業務範囲が広い一方で自由度があります。EMのあり方に対する世の中的な正解がまだないからこそ、チームのあり方や自分の役割を自分の意思でデザインできることに、EMの面白みを見出すことができると思います。

EMには賞味期限がある？ 幅広い経験から導かれるキャリアパス

ーーEMにはどんな人が向いていると思いますか？

一つは、プロダクトマネージャー（以下、PM）の仕事への理解がある人。EMはエンジニアを育てたり、技術の方向性を決めたりするのが仕事ですが、どの仕事においても最終的にはプロダクトの成果に結びつける視点が欠かせないからです。

もう一つは、テックリードとして自分の頭で考え、腹を括る経験をしたことがある人。特にマルバツ表をつけても分からないような難しい技術的判断を下し、その結果を最後まで見届けた経験ですかね。逆にそうした経験がないEMは、いざ同じような決断が迫られるシーンで周囲から信頼を得にくいと思います。

ちなみに私はEMとして技術的な決断をする際に、自分だけでなくチームメンバーが納得していることを大切にしています。

そのとき、どちらの技術なら気持ちよく運用できるか、あるいは腹をくくれる覚悟があるのかを確認する言葉として、「この技術を愛せるか？」というワードがチームで使われることがあります。

オープンソースのツールやアーキテクチャーのパターンを決めるときなど、論理的には説明できなくても「なんか引っかかる」というエンジニアの感覚ってありますよね？ そういう勘のようなものをチームで共有する必要があるときに、この言葉が使われます。

ーーEMを経験すると、将来どのようなキャリアを描けるでしょうか？

今、私はEMでありながら課長という役職でも一つのチームを見ているので、将来は部長職として複数のチームを見るというオーソドックスなキャリアパスが考えられると思います。

またスキルセットの重なりが多いプロダクトマネジメントの方向性に進み、プロダクトを生んだり、成長させることに専念するというキャリアも描けます。

一方、ピープルマネジメントに興味がある方の場合は、VPoEなどの組織に向き合う役職に就く道も企業によってはあり得るのではないでしょうか。

ーー牧志さん自身は、EMを経てどのようなキャリアパスを描いていますか？

正直悩んでいます。と言うのも、EMには賞味期限があると思うからです。

エンジニアが解いた技術課題の難しさを理解し、きちんと評価できる状態でいるためには、EM自身がプログラミングなどをする時間を確保して、最新の技術をキャッチアップし続ける必要がありますが、限界があります。

賞味期限が具体的にあと何年先なのかはわかりませんが、今のロールを続けていくか、プロダクトマネジメントの方向性に進むか、この二つの選択肢を検討しつつ、どちらの方向に進んでもより良いプロダクトを出すことにコミットし続けられればと思います。

取材・文／一本麻衣　編集／玉城智子（エンジニアtype編集部）