いちプログラマーからマネジャーになるとき、「現場を離れたくない」と思うエンジニアは少なくない。実際に手を動かしていないと不安だという声も多く聞かれる。

DeNAのシステム開発部部長を務める小林篤氏も、そうだった。しかし、実際にマネジャーとして仕事をするようになると、戦略的・長期的な視点でモノづくりを考えるマネジャー職の面白さが分かってきたという。

マイクロソフトやグーグル、Incrementsなどの開発現場で豊富な経験を持つ及川卓也氏が、100名を超えるエンジニアを束ねる小林氏の仕事ぶりと、DeNAのモノづくりを支える組織の実態に迫る。

株式会社ディー・エヌ・エー オープンプラットフォーム事業本部　システム開発部　部長 兼 オートモーティブ事業本部　基幹システム開発部　部長
小林 篤氏

法学部法律学科からエンジニアへ転身。2011年にDeNAに入社。Mobageおよび協業ゲームプラットフォームの大規模システム開発・運用を担当し現在は同システムの開発責任者を務める。2017年よりオートモーティブ事業本部において開発責任者を兼務。一般社団法人Japan Perl Association 代表理事を兼務し、Perlの普及・振興の為、YAPCや各種イベントを企画実施。技術系カンファレンス多数登壇。技術系書籍・雑誌多数執筆

株式会社クライス＆カンパニー　顧問
及川卓也氏

早稲田大学理工学部を卒業後、日本DECに就職。営業サポート、ソフトウエア開発、研究開発に従事し、1997年からはMicrosoftでWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントやChromeのエンジニアリングマネジメントなどを行う。2015年11月、技術情報共有サービス『Qiita』などを運営するIncrementsに転職。17年6月より独立し、プロダクト戦略やエンジニアリングマネジメントなどの領域で企業の支援を行う。17年9月、ヘッドハンティング・人材紹介を展開するクライス＆カンパニーの顧問に就任

最初は、マネジャーになりたくなかった

及川　まず、小林さんのご経歴について教えてください。

小林　もともとは、サーバー系の開発エンジニアでした。言語としてはPerlを使って開発することが多く、Perlコミュニティーつながりで2011年3月にDeNAに入社したんです。MobageにおけるオープンプラットフォームのAPI開発などに携わりました。当時、この分野のコアメンバーは私を含めて3人だったのですが、エンジニアの急増に伴い、マネジャーを置く必要が出てきて。でも、最初は3人とも嫌がってたんですよ（笑）。結局は、私が手を挙げてマネジャーに。入社後、1年半ほど経ったころです。

及川　現在は何名のメンバーをマネジメントされているんですか？

小林　今は2つの部門を統括しています。一つはMobageなどの基幹システム開発で、もう一つはオートモーティブ事業のシステム開発。前者では約80人、後者では約35人のメンバーがいます。

及川　合計100名以上のメンバーを束ねるのは大変でしょうね！ 小林さんは最初、なぜマネジャーになりたくなかったのでしょうか？

小林　それはもう単純に、コードを書いていたいと思っていたからです（笑）。だから、マネジャーになってからも1年ほどの間は、自分でもコーディングをしていました。捨てきれなかったんですね。

及川　その後、マネジャーに専念することにしたんですね。何かきっかけが？

小林　自分が作ったものをチェックしてもらうじゃないですか。すると、ミスが発見される比率がだんだん上がってきた。マネジャー業務で時間を取られる割合が加速度的に増えている頃でしたし、同僚からも直接、「コーディングはもうやめた方がいい」と言われたこともあります。自分でも集中して書けてないという自覚があったので、マネジャーに専念しようと気持ちを切り替えました。

及川　とはいえ、一方では実際に手を動かしてないと、テクノロジーを理解できないという部分もあると思います。不安はありませんでしたか？

小林　もちろんありました。2年ほど前、スマホアプリをPCで楽しめる『AndApp』というサービスをリリースしました。そのプラットフォーム開発にあたっては、ゼロベースで技術選定を行い、従来からノウハウを蓄積していたPerlを不採用とし、すべてGCP（Google Cloud Platform）上で開発すると決めたんです。Mobageなどでは今もPerlを活用していますが、AndAppではPerlを捨てた。大きな意思決定でしたが、この時はリサーチをしたり、他社事例を研究したりするだけでなく、自分で実際にGCPを使ってみて一部機能の開発なども行いました。やっぱり、ここぞという時には自分で直接触ってみないと分からないと思うんです。一方で、常日頃から手を動かしていなくとも、情報のキャッチアップさえ怠らなければ、要所要所で触れてみることで理解はできるという勘所も得ました。

エンジニア組織のマネジメントにおける3つの役割

及川　小林さんが見ているメンバーは全員がエンジニアですか？

小林　一部、企画職のメンバーもいますが、大半がエンジニアですね。

及川　私は通常、開発チームのマネジメントを3つに分けて考えています。エンジニアチームをつくり育てるエンジニアリングマネジャー、高い技術力をもって設計・開発を牽引するテックリード。そして、小林さんの話にあった企画職に相当するのかもしれませんが、プロダクトの戦略を担うプロダクトマネジャーです。お話を聞く限りでは、小林さんはこの3つの役割をすべて担っているように見えるのですが。

小林　確かに、そうかもしれません。

及川　テックリードとしての業務もカバーされているんですね。

小林　そうですね、ただ私一人というわけではありません。開発を進める上で、技術選定は人材採用にも関わる重要テーマです。どういう技術を採用するかによって、求める人材要件も変わってくる。全体を視野に入れて技術の方向を考えるので、テックリードの役割もある程度担わざるを得ないところがあります。

及川　1人のマネジャーが広い領域をカバーすることによるメリット、デメリット、両方ありますよね。

小林　はい。今後チームをさらにスケールさせるためには、役割を分けた方がいいと私自身は考えています。今、採用活動の中では、特にプロダクトマネジャーに適任な人材を積極的に採用していますね。

シナジーを促進に向け、マトリックス組織を導入

及川　小林さんと現場メンバーの間には、何人くらいの中間マネジャーがいるのですか？

小林　2つのチームを合わせて100人強の中で、マネジャーは10名弱でしょうか。もう少し増やしたいですね。

及川　テックリードは？

小林　当社には役職としてテックリードという呼称はないのですが、役割としてテックリードを担っているリーダークラスが3、4名います。

及川　組織全体から見ると、人数としては少ないですよね。

小林　エンジニアリングマネジャーがテックリードを兼務するケースが多いのです。また、事業を推進するプロジェクトリーダーの役割を担うマネジャーも多い。企画職がプロジェクトリーダー役を務めることもあるし、エンジニアリングマネジャーがそのポジションに入ることもあります。整然とロールが分かれているわけではなく、オーバーラップする部分もありますし、その人の特性を見ながらその都度役割を変えているというのが実態です。

及川　ゲームやアプリ開発においては、プロデューサーのような役割もあったりします。DeNAさんでいうと、プロデューサーの立場にあるのはどのポジションの方ですか？

小林　タクシー配車アプリを例にとると、事業責任者がプロデューサーを兼ねています。オートモーティブのチームは、マトリックス組織になっています。縦のラインの事業責任者が損益責任を負い、横のラインとしてプロダクトを見る組織があります。特に自動車関連では、１つのプロダクトだけに集中するのではなく、他のプロダクト状況を把握した上でシナジーを起こし、新たなサービスを生み出していく動きが求められます。例えば、自動運転の技術とシェアリングの技術を組み合わせると何ができるか、などです。こうした技術横断的な取り組みを促進するために、マトリックス組織を導入しています。

なぜ、マネジャーを避けようとするのか？

及川　先ほど、マネジャーをやりたくなかったという話がありました。DeNAに限らず、どこの会社でもエンジニアにはその傾向が強いと思います。小林さんは、なぜだと思いますか？

小林　自分自身もそうでしたが、モノづくりをやり続けたい、手を動かしていたいということでしょう。マネジャーの仕事はモノづくりではない、という感覚なんですよね、きっと。でも、実際に経験して実感するのは、マネジャーはエンジニアとは違う視点でモノづくりにしっかり関わっているということ。この点があまり理解されていません。

及川　エンジニアの世界ではプログラミングだけが注目されがちですが、その周囲に大事な仕事がたくさんある。実はそこにも、プログラミングと同じくらいエキサイティングなモノづくりの醍醐味があると私は思っています。マネジャーという仕事の中身、面白さをエンジニアに対していかに伝えるか。小林さんは、何か工夫していることはありますか？

小林　明確に言語化して示すことはできていないかもしれません。ただ、自分の今の仕事をできるだけ具体的にみんなに話すことを日々心掛けています。例えば、チームのケイパビリティーにどんな課題があるのか、課題解決に向けてどんな人材を採用しようとしているのか。すると中にはそうした話に興味を持ってくれるメンバーが出てきます。そういう相手には「一緒にやってみよう」と声をかけて、自然な形でマネジメント業務の一端を経験させる機会を作ってみたり。もちろん、全く興味を示さないエンジニアもいます。そういう人を無理やり引き込むようなことはしません。

及川　興味の有無、向き不向きがありますからね。マネジャーに必要とされる能力にはいくつかの要素がありますが、それはエンジニアにとっての個別スキルと同じ種類のものだと思います。例えば、あるエンジニアはデータベース設計、別のエンジニアはカーネルのデバッグが得意だったりします。マネジャーに必要とされるスキル要素も、それと同じように考えることができます。

反省を経てコミュニケーションスタイルを変えた

及川　マネジャーにとって非常に難しく、しかし絶対にやらなければいけないこと。その一つが、パフォーマンスが上がらないメンバーへの対処だと思います。一時的なパフォーマンスの低下であれば、サポート次第でリカバーできるケースもあります。ただ、長期にわたって改善が見られないケースもあるはず。小林さんはどのようにお考えですか。

小林　確かに、非常に難しいですね。実は、苦い記憶があります。あるメンバーに改善を働き掛けるべく、1on1ミーティングなどでアドバイスをしていました。私自身は「こうできるようになるといいね」とポジティブに伝えていたつもりだったのですが、後からメンバー自身は私にいつも否定されていると受け止めていたことが分かって……ショックでしたね。この時の反省に立って、コミュニケーションのスタイルをいろいろ工夫するようになりました。

及川　例えばどんな点を変えてみましたか？

小林　以前よりも丁寧に言葉を選んで伝えるようになりました。また、特に1on1の面談時には目線や話すスピード、座り方などもかなり意識しています。

及川　それは大事ですね。例えば、テーブルを挟んで向かい合って座ると、対立構造になりがちで良くないと言われています。最悪なのは向かい合って座った2人が、互いにノートPCのモニターを立てている状態です。1on1でPCを使いたいときには、同じ画面を2人でのぞき込むような形が望ましい。そうすると、共同作業の感覚が生まれます。

小林　私も1対1のときは正面ではなく、テーブルの角を挟んで斜めに座るようにしています。そういうことでも、コミュニケーションって変わってきますよね。今は、チームメンバーにも、フラットに話しやすい相手として認めてもらってると自負してます（笑）。

マネジャーを対象に「360度フィードバック」を導入

及川　DeNAは昨年秋、社員が熱意をもって働ける環境づくりを目的とした人事プロジェクト『フルスイング』をスタートしていますよね。マネジャーに対しては「360度フィードバック」を導入したと聞きました。面白い取り組みですね。

小林　はい。全社的にピープルマネジメントを強化しようという中で、その施策の一つとしてマネジャー職に対する360度フィードバックを導入しました。5つの評価軸について、そのマネジャーがどの程度できているかを数字で回答するとともに、フリーの記述欄も用意されています。5つの評価軸は「ゴールを示す」、「適切に任せる」、「支援する」、「結果を出す」、「インテグリティ（誠実さ）」。フィードバックは記名式です。

及川　では、人事評価とは別のものという位置付けなんですね。

小林　はい。あくまでも、マネジャーの成長のために導入された仕組みです。

及川　ご自分のフィードバック結果を見て、率直にどう感じましたか？

小林　僕は40人ほどからフィードバックをもらいました。とても良い意見をもらえたと感じています。自分が普段感じている課題を、的確に指摘してもらった。やはりそう見えていますか、というカンジです。私自身が認識していない意外な指摘などはありませんでしたが、これは私もメンバーも同じ感覚を共有できていて、日頃からコミュニケーションが図れていることの証なのかな、と理解しています。そういう実感が得られたのも収穫ですね。

及川　最後に、マネジャーという仕事の魅力について改めてお聞かせください。

小林　マネジャーの役割として長期的、戦略的にモノづくりを考えることが求められます。それに基づいてチームでプロダクトを創っていく面白さは、経験してみないとなかなか分かりません。私自身もそうでした。エンジニアにはぜひ、食わず嫌いをせず、一度食べてみることをお勧めします。すると、これまでとは見方や考え方が変わることも多いものです。例えば、マネジャーを経験することで、これまでとは違ったコードの書き方が見えてくるとか、新たな発見がきっとあります。

及川　同感です。よく聞く話ですが、普段自転車に乗っている人が、車の運転をすると、その後、自転車の乗り方が変わるといいます。ドライバー目線で見ると、危ない自転車の乗り方がよく分かる。それを踏まえて、自分の自転車の乗り方を変えるわけです。ドライバーからの視線を想像して、より安全な自転車のコースを取れるようにもなる。私も、いろいろなエンジニアに「一度マネジャーを経験してみれば」と勧めています。一度経験した上で、プログラマーに戻ってもいい。小林さんが言うように、以前とは違うコードを書けるようになっているはずです。

取材・文／津田浩司　撮影／小林 正（スポック）