【スマートニュースのエンジニアが知りたい】Engineering Manager 井口 貝「エンジニアがめっちゃ楽しい会社をつくりたい」

f:id:smartnews_jp:20190527173917j:plain

会社としてスマートニュースを見たとき、まだまだ知られていないことがあります。

たとえば、プロダクトの開発体制について。現在スマートニュースのプロダクト開発を率いているのは、サンフランシスコオフィスに勤めるJeannie Yangという人物です。Senior Vice President of Productとしてプロダクト開発責任を担っています。「One Product, One Team」の哲学に基づき、日米で異なるタイムゾーンや言語、物理的環境でありながらも、活動のコードベースは1つ、そしてチームも1つでグローバルプロダクト開発体制をつくっていることはあまり知られていません。

そもそも「どんなエンジニアが働いているのか」、その姿も正直よく知られてません。スマQでは、スマートニュースではたらくエンジニアをフカボリしていきます。

第1回目は、News BackendチームとMedia Engineeringチームの2チームを率いる、Engineering Managerの井口貝さんにお話を伺います。どんな経緯でスマートニュースに入社して、どんな思いで働いているのか、多くのQを解き明かします。

マネジメント未経験から現在は2つのチームを束ね、英語話者をマネジメントする井口さん。彼を突き動かすのは、「エンジニアがめっちゃ楽しい」と感じる組織をつくりたいという思いでした。

井口さんのお仕事、教えてください!

―― スマートニュースではどんな仕事をしてきましたか?

井口 スマートニュースには「ニュース」と「広告」、2つの大きな柱があります。私は入社以来、「ニュース」の開発を担当していました。

ニュースの取得から配信までのパイプラインの実装、改修、運用を3年間ほど担当し、2018年の1月からEngineering Managerとして勤務していて、今に至ります。

入社時には全員で30人ほどだった従業員数が、今では5倍、6倍と規模が拡大しました。現在は同期や少し先輩の社員が、マネジメント業務や技術的な意思決定をするテックリードをやっています。この5年間で徐々に役割が変わってきた社員も結構多いです。

f:id:smartnews_jp:20190527173907j:plain

井口 貝(いのくち かい)
東京都出身。1986年生まれ。国立東京工業高等専門学校で5年間の本科と2年間の専攻科、その後、中央大学大学院に2年間通い、合計9年間、情報工学を学ぶ。そして、2011年新卒でNECソフト株式会社(現在のNECソリューションイノベータ株式会社)にSEとして入社。小売のECソリューション導入、要件定義から実装・運用までを4年間経験。2015年1月スマートニュース株式会社に入社。ニュース配信基盤全般の開発・保守運用を3年間経験し、2018年1月よりEngineering Managerを務める。

―― 社歴と役割は連動しているのですか?

井口 スマートニュースでは経験年数や在籍年数はあまり関係ないですね。完全に適性と指向性だけ。この考え方は会社としてもそうですし、個人としても全く同じ見解です。入社後すぐにマネージャーをやってもいいし、10年ずっとプレイヤーをやり続けてもいい。技術を追求していくキャリアもあるし、マネジメントの道を進むキャリアもある。どの道に進むかは人それぞれで、会社はその人に合ったキャリア形成を支援しています。

―― エンジニアのキャリアは大きく2つあるのですね

井口 はい、エンジニアのキャリアは「技術に深くコミットする方向」と「組織の向上や課題解決にコミットする方向」の大きく2つに分かれています。技術にフォーカスしたいのか、マネジメントもしたいのか。もちろんグラデーションはあって、中間状態にいる人もいます。

スマートニュースには正解がありません。抽象的な表現になりますが、どちらの道でも「影響範囲を拡大していけばいい」というのが会社としての答えです。つまりチームに対する影響範囲なのか、システムに対する影響範囲なのか。どちらを選択しても、影響範囲の大きさをどんどん広げていきましょう、というのが、キャリア形成でスマートニュースが大切にしている部分です。

―― 井口さんは、もとからマネジメントの道を目指していたのですか?

井口 正直なところ、その辺りのことは全く考えていませんでした。今でも10年後のキャリアは全くわからないです(笑)。ただ当時はとくに考えてなくて、単に自分が面白いと思うことと、会社に対して必要だなと思うところをずっとやっていました。

マネジメントの道に進んだきっかけは、前任のEngineering Managerがさらに上のレイヤーに就任することになり、彼がそれまで担っていたポジションが空いたからでした。そして、後任として声をかけてもらったとき、会社の全体最適のためには自分の就任が必要だと思い、拝命したんです。

―― Engineering Managerとして、どのような組織をマネジメントしているのでしょうか

井口 私は現在News BackendチームとMedia Engineeringチームの2チームを担当しています。News Backendチームは、「ニュース」の開発・運用・改善を全部担当している8名のチームです。

もう1つの、Media Engineeringチームは、News Backendシステムをコントロールするための機能を提供する5名のチーム。SmartNewsのチャンネルの内容を調整する機能や、ニュースの配信結果や収益・PVなどを媒体社さんに提供するためのコンソールをつくっています。

そして、この2チームのエンジニア組織の成果を最大化することがEngineering Managerとしての私のミッションです。

―― そのミッションに向け、どのような業務が多いですか?

井口 以前は、組織と技術、両方のマネジメントを担当していましたが、現在は組織に関するマネジメント業務が多いです。

例えば、メンバーから「こういうプロジェクトをやってみたい」「こういう技術的特性を身につけたい」といった要望があれば、それを実現できるようにサポートしています。要望を受けた後は、最適なプロジェクトにアサインしたり、技術的に伸ばすべき領域を一緒に考えて、今後取り組む課題を提示したりと、メンバーが楽しく働ける環境づくりをしています。

Squad(スクワッド)を軸に、全員がミッションを持って主体的に動く

―― スマートニュースでは、どのようなプロジェクト体制なのですか?

井口 まずスマートニュースの組織には、チームという単位があります。評価などに使われる、いわゆる管理のための単位です。しかし、SREチームのようにチーム一丸となって同じ課題に取り組むチームもあるので、管理以上の機能を果たすところもあります。

しかし、News BackendチームやMedia Engineeringチームを含む「ニュース」チームの場合、ニュースのプロダクト、サーバー、システムを良くするという共通点はあるものの、その手段は人それぞれ。あるエンジニアはクーポンの機能をつくったり、また別のエンジニアはプッシュ通知の機能をつくったりと様々です。

そのためスマートニュースでは、プロジェクト進行のために「Squad(スクワッド)」という単位も導入しています。Squadは日本語にすると「分隊」。共通するミッションを持った分隊、つまり小さな集団でプロジェクトを進める方法です。例えば、「ユーザー獲得Squad」というSquadでは、そこに集まったメンバーはユーザー獲得にコミットしています。

そして、Squadはクロスファンクショナルなメンバーで構成されるため、中にはPMやデザイナー、サーバーサイドエンジニア、アプリエンジニア、データサイエンティストが在籍しています。

Squadの一例
チームとは別に、「ユーザー獲得」「エンゲージメント向上」など、それぞれ横断的に集まったメンバーがひとつのミッションに取り組む(画像はSquadの一例)

このように組織横断的に集まったメンバーが、同じミッションに向かって集中して取り組む、それがSquadです。ユーザー獲得のSquadや、獲得ユーザーのエンゲージメントを高めるSquad、収益化のSquadなどに分かれており、チームとSquadがマトリクスになっています。そのため、同じチームでもメンバーそれぞれの業務が異なることが特徴です。

―― マトリクス組織だと、Engineering Managerの役割は大切ですね

井口 はい、それぞれやっていることが異なるので、全員の状況を把握することが重要です。Engineering Managerは、一義的にはチームの成果を最大化することですが、メンバーが「Squadでこういうことをやっているが、次は違うこともやってみたい」という状態であれば、他のSquadへの変更をPMに掛け合うこともします。

―― Squadならではの問題点は何かありますか?

井口 Squadはそれぞれ別の目的を持って進めているため、Squad間でシステム的なコンフリクトが発生します。そんなときに、どう折り合いをつけるのか、もしくはどちらのSquadの機能を優先させて進めるのか、という調整もEngineering Managerの仕事です。組織のなかで必要不可欠なマネジメントと言えるでしょう。

また、Squad構造におけるダウンサイド、複数のSquadが共通した部分を誰がやるのかという問題も発生します。例えば、A/Bテスト。ユーザー獲得、エンゲージメント向上、収益化、どのSquadでもA/Bテストは必要です。そんなときに、A/Bテストのフレームワークにバグが発見された場合、どこがバグの対応をするのかといった話です。

そのような場合は「ファンデーション(Foundation)」という横断的なSquadが力を発揮します。

例えば、News Backendファンデーションというのがあります。これは、全体的な基盤改善への貢献をミッションとしたSquadです。具体的にはユーザーの増加に伴い、システムのスケーラビリティを改善したり、エラーレートを下げたりすることをやっていて、私はそのSquadのPMも務めています。ただし、PMがトップダウンで指示するのではなく、メンバーが主体となって技術的な課題を解決しています。

―― Engineering Managerだけでなく、メンバーも含めて全員が主体的に動いているのですね

井口 Squadの仕組みが、メンバーを主体的にさせるのかもしれませんね。ミッション達成のためにメンバー同士で考えましょう、というSquadの構造自体が、メンバーの自発性を生みやすいのだと思います。

特にスマートニュースの場合は、エンジニアリングによって物事を解決していこう、レバレッジをきかせて解決していこう、というカルチャーがあります。

そのため、例えばこういうアルゴリズムにしたら、よりスケールするんじゃないか? といった現場のアイデアがプロダクトに反映されることも多いのです。職種に関係なく、それぞれの意見がプロダクトの成長に直結しています。

―― Squadは企画段階からエンジニアも関わりやすい体制で良いですね

井口 まさにそうです。Squadは初期のプランニングの段階からエンジニアやテックリードがちゃんと入って、実現可能性を判断したり、もっとこういうアルゴリズムを使ったら良いものになる、という議論を行う。コードを1行も書かない状態からエンジニアとPMが議論するというのを、社内文化的にたびたび行なっています。

f:id:smartnews_jp:20190527173859j:plain

マネジメント未経験からEMへ。メンバーを信頼し任せるようになった

―― マネジメント業務を実際にやっていて、苦労した点は何かありますか?

井口 苦労で言うと、本当に苦労しかありません。

学生時代も含めて過去に一度たりともマネジメント経験がなかったので、個々の力を全体の力に変換するといった経験が全くありませんでした。そんな状態で、2018年に初めてマネージャーになったんです。就任当時は、本当に右も左もわからない1年生状態でした。

―― そのような状況でEngineering Managerになることへ不安や躊躇はありましたか?

井口 躊躇ばかりでしたよ。 「え、なんで自分なんだろう?」って。チームメンバーは歳上が多く、人生経験やエンジニアリング経験もみんな素晴らしい人ばかり。他に適任者がいるんじゃないかと思っていました。

一方で自分は在籍期間が長かったので、システムをよく理解していたことは確かです。当時のEngineering Managerは、プレイングマネージャー的な要素が求められていたので、システムの理解は、必要要件の1つだったのかもしれません。

Engineering Managerになりたての頃は、自分が過去に担当していたシステムに障害が起こると、ついつい自分で対応していたんです。確かに早く対処できるかもしれないけれど、これはチームメンバーに任せるべきでした。任せることで、信頼感が醸成されるし、メンバーのスキルや経験にもなる。本当に手を出さないといけないときを見極め、それ以外のときはメンバーに任せようと、今では心がけています。

―― マネジメント業務をされていて、これまでに遭遇した課題を教えてください

井口 1番の課題は、システム的な課題ではなく組織的な課題でした。メンバー全員が優秀だからこそ、自分1人で全部解決できてしまい、お互いに助け合う風潮がなかった。例えるとすれば、100の成果を出せる人が3人いて「100 + 100 + 100」にはなるけど、「100 × 100 × 100」にはならないチームだったんです。それに加えて私は、自分で手を動かしてしまうスタイル。メンバーが学ぶ機会はほとんどありませんでした。このような状態が、就任半年から1年ほど継続し、大きな課題だと気付いたんです。

この課題を解決するため「私は戦争の思い出を語るおじいちゃんになります」とメンバーに宣言しました。確かに私は昔のシステムについては詳しいけど、技術的な意思決定は、優秀なメンバーである皆さんに任せたいですと伝え、権限移譲をしました。

他には、各メンバーがそれぞれ別の業務を担当しているので、チームとして情報が集まりにくいといった課題があったんです。その対策として「皆さんがいいアイデアを思いついたら、是非チームに持ち帰ってみんなで議論しましょう」と働きかけました。例えば、なぜこれはMySQLじゃなくてRedisを使ったのか。あなたは当然のように知っているかもしれないけど、チームメンバーにもその知識を共有して欲しい、と言うことで、各メンバーが業務で得た知見をチームに持ち寄るようになりました。

これらの効果かは断言できませんが、システムの理解がメンバー間で相当深まったと思いますし、Squadを越えて協力する雰囲気が昨年末くらいから見られるようになりました。これにより、新たな挑戦をしたくなったときのSquad間の移行もスムーズにいくでしょうし、エンジニアのレベルの底上げにも繋がっていると思います。

―― 就任当時と比べると、自分自身が変わったと感じますか?

井口 それはそうですね。今は、まだいけてないマネージャーかもしれませんが、当時よりも成長していると自分自身でも感じます。

マネジメントをしていて感じるのは、スマートニュースは社員が優秀で、オーナーシップを持っている社員が多いこと。そのため「自分のシステム」という意識も強く、担当中のシステムに障害が発生すると、良くも悪くも単なるアラート対応以上の意味が生まれてしまうんです。もちろんその姿勢も大切ですが、次のステップとして「みんなのシステム」と思って取り組めるようにすべきだと感じています。きっと、1年前はこれを課題だとは感じることができなかったと思いますね。

―― 何か変わるきっかけがあったのですか?

井口 2018年3月にクーポン機能をローンチしました。そのときのサーバサイドの開発はチームメンバーの1人と私の2人体制。そのため私は、クーポンプロジェクトの開発のメイン担当に近い状態でした。それに加えて、クーポンプロジェクトの取りまとめも担当していたので、サーバーの仕様はこうしましょうね、クライアントサイドはこういう風に実装してください、データの入稿の流れはこうしましょうね、といったことも行なっていました。

そのときは結構忙しくて、Engineering Managerとして組織を見ないといけないし、クーポンという全社のビッグプロジェクトもやらないといけなかった。これら全てを自分で対応するのは限界があると気づき、メンバーに任せられるものは委譲していかなければいけないと痛感しました。それが今のマネジメント姿勢に繋がっていると考えています。

f:id:smartnews_jp:20190527173854j:plain

チームメンバーの半数以上が海外出身

―― 話は変わりますが、業務で英語を利用するシーンが多いそうですね

井口 チーム内のドキュメントは全部英語です。 Pull Requestやソースコード内のコメントも英語、Slackでのコミュニケーションも日本語と英語半々くらいです。

News Backendチームは、国際色豊かで、イギリス・ドイツ・台湾・中国など海外出身者が多く、日本人のほうが少ない環境です。Media Engineeringチームも同様で、2チーム13人中7人が外国籍。そのためミーティングや情報共有はもちろん英語を使用しますし、英語しか使わない日もあるくらいです。

ちなみに、Slackでは“あえて”日本語と英語を半々にしています。もちろんぼくたちのチームは英語が共通言語ですので、仕事上の会話もおのずと英語になりがち。しかし、海外出身のチームメンバーは日本に住んでいることもあり、日本語を学びたいというモチベーションが高い方が多いのです。

そんな彼らに、「Inokuchiさんは気をつかって英語にしてくれているのかな……」と思われないよう、けっこう気をつかっています。日本語と英語を半々で使ったり、たまにはあえて日本語でメンションするなど、Slack上での言語の使い分けを心がけています。

―― 海外出身者のメンバーがいる環境で、特に気を付けていることはありますか?

井口 まず私自身が、英語を使いこなせていない自覚があるので、自分自身でそのことを認識するようにしていますし、同時にメンバーにも認識してもらうようにしています。メンバーと1〜2週間に1回、1on1を実施しているのですが、その際には、「今言ったことってこういうことだよね」と、お互いの認識にズレが発生していないか細かく確認しています。

f:id:smartnews_jp:20190607120027j:plain

―― 英語は元々得意でしたか?

井口 前職では「英語は得意!」と思っていたのですが、入社早々に鼻をへし折られる出来事がありました。

入社から2週間が経った頃、Googleのチームと私の所属していたチームがランチミーティングする機会がありました。他のチームメンバーは英語ができるので活発な議論が続き「最後になにか質問はありますか?」と振られたので、入社したばかりだし英語できますアピールでもしてみよう、と張り切って英語で質問しました。すると、そのGoogleの方たちに全く質問が伝わらず、その中にいらっしゃった日本語も話せる海外の方に「日本語でも大丈夫ですよ」って言われてしまった。それがすごく恥ずかしくて……その日以来、英語を頑張らないといけないなと強く思うようになりました。

―― その日からどうやって勉強されたんですか?

井口 「勉強」が得意ではないので、教科書ではなくTED TalksとNetflixを使って学びました。どちらも興味のある動画を英語字幕で観ては、作中のフレーズをモノマネしてみる。英語が話せたらカッコいいなと思っているので、ネイティブの人がよく使うフレーズを真似したかったんです。意味はわからないまま、音としてコピーしていったのが入口でした。他にもチーム内の英語話者の人との会話から、あれこれコピーしながら覚えていきましたね。

―― 文法はどうされましたか?

井口 「勉強」は嫌いだと言ったのですが、文法は好きなので難なく学べました。文法は構文があってアルゴリズミックじゃないですか。これはここまでが主格だよね。このwhatはここに係っているな、みたいなのは好きなんですけど、それってスピーキング力とはあまり関係ないかもしれませんね。

―― 簡単には真似できなさそうな学び方ですね

井口 英語の文章は結構読めたほうだとは思うんですが、入社するまでは喋れませんでした。今思えば、恥をかいてカルチャーショックを受けたのが大きな原動力だったと思います。バンド時代に耳コピはしていたので、もしかしたらたまたま耳がよかったからできたのかもしれません(笑)

技術を追求するよりも、エンジニアが楽しく働ける状態をつくりたい

―― マネージャーとして一番大切にしていることは何でしょう?

井口 メンバーが楽しく働いていることが一番大事かなと思います。何をおいても。

なので、逆にメンバーが楽しくなさそうなところを見ちゃうと結構気になっちゃったりします。何かあったのかなとか。

やはり、楽しんでいるときが一番パフォーマンスが出ますよね。

―― マネージャーとして今後どうしていきたいですか?

井口 エンジニアがめっちゃ楽しい会社・チーム・組織をつくっていきたいです。

ひょっとすると、それを実現させるための役割はEngineering Managerではないかもしれないし、人事かもしれない。実現のために必要だとされることをやるだけです。

私はマネジメント経験を通じて、エンジニアが楽しみながら働くことで生産性が上がり、現場から生まれた良いアイデアが成果に繋がることを知りました。今後も、エンジニアが働きやすい環境をつくっていきたいですね。

f:id:smartnews_jp:20190527173912j:plain

スマートニュース 採用情報

取材・編集・撮影:株式会社ZINE