INTERVIEWEE
GMOペパボ株式会社 取締役CTO セキュリティ対策室長 栗林健太郎氏
東京都立大学法学部政治学科卒業後、奄美市役所勤務を経て、ソフトウェアエンジニアに転じた。2008年5月、株式会社はてなにエンジニアとして入社。はてなダイアリー、ポータルサイト、はてなブックマークなどのサービス開発とともに、新サービスの開発に従事。2012年5月、株式会社paperboy&co.(現GMOペパボ株式会社)に技術基盤整備エンジニアとして入社。全社的な技術基盤整備や開発プロセスの導入等を経て、2017年3月からは取締役CTOとして、技術に関わる全社での戦略策定、実行を担う。
エンゲージメントが高いチーム（※）の秘訣を探る、DIO STORY。今回は、CtoCハンドメイドマーケット「minne」や「カラーミーショップ」「グーペ」などのEC支援サービス、「ロリポップ！」「ムームードメイン」などのホスティングサービスを手がけるGMOペパボ株式会社のCTO栗林健太郎さんにお話をお伺いしてきました。
※ エンゲージメント計測サーベイwevox（ウィボックス）にて測られたエンゲージメントスコアが81点以上（100点満点）のチーム。（wevoxにて計測されたエンゲージメントスコアの上位1%に当たる。）
あんちぽちゃんの愛称でも知られる栗林健太郎さんは、独学でエンジニアとしてのキャリアをスタートし、現在GMOペパボのCTOを務めています。その過程で、組織開発にも積極的に関わり、評価制度や文化づくりなど様々な実績を重ねてきました。そんな栗林さんは、「エンジニアリングとマネージメントを別物だとは思っていない」と語ります。その真意とは？
「誰が評価するか」によって伝わるメッセージは変わる
– 栗林さんが初めてマネージャーという立場になったのはいつでしょうか？
公式には2015年1月からで、当時、複数の事業を横断して技術インフラを開発・運用する「技術部」という部署を立ち上げたんですね。その部長に就任するという形で、マネージャーという役職を担うことになりました。ただし、2014年の春頃から、前任者のあとを引き継ぐ形で、非公式にではあるものの技術組織のマネジメントに携わってきました。
– マネージャーとしての最初の取り組みは？
主だったこととして、評価制度を見直し、社内のエンジニアの評価は全て自分がやる、という形にしました。技術部だけでなく、全てのエンジニアです。それまでは直属のマネージャーが評価をする形だったのですが、エンジニアとしての専門性を評価にもっと反映する必要があると考えていました。それに、私が考える良いエンジニア像を伝えるには、自ら評価するのが一番伝わるとも思いました。評価する人によって、伝わるメッセージは変わってきますから。
– 栗林さんが伝えたかったエンジニア像とはどういったものですか？
一言で言えば、「広い視野で仕事に取り組めるエンジニア」です。サービスの成長にコミットしてそのために技術を用いるのは当然だとしても、エンジニアとしての専門性を高めていくには、特定のサービスに特化するだけではなく、それを汎用化していく必要があります。そうした考え方を伝えるために、まずは自分が全てのエンジニアの評価をする、ということにしたのです。ただ、そうした評価制度もいまでは少しずつ当時とは違う形になっています。
評価マインドは判例法主義で広める
– 具体的に、今はどう変化しているのでしょう？
全て自分で評価する、としていたのはいわゆる緊急対応でした。ずっとそれを続けるのは不可能ですから。次のステップとして、それぞれの事業マネージャーに、事業目標に直接つながる3分の2の評価項目を返して、残りの技術的な3分の1の評価を自分ですることにしました。最近ではそれぞれの部署にCTL（チーフテクニカルリード）というエンジニアのリーダーを置き、その人たちに私がやっていたその技術的な評価をしてもらうようにしています。さらに、そのCTLを私が評価する、という仕組みです。段階的に変化させていったことで、理想とするエンジニア像が会社全体に広まったと思っています。
– なるほど。段階的に進めたとはいえ「理想の人材像」を意識付けするのは難しくはなかったですか？
“判例法主義”的なやり方での意識付けを行うようにしています。“判例法主義”というのは、裁判所による過去の判決事例を重要な根拠とする考え方です。対して“成文法主義”は、明文化したルールを重要な根拠と考えますが、この方法は変化が激しいエンジニアリングの世界には合いません。それよりも、「こんな行動や考え方、やり方が評価されている」という事例を積み重ねていく“判例法主義”的なアプローチが合っているのです。
– 評価基準を明文化した資料は作っていないのでしょうか。
基本的な方針はまとめてありますし、社外にも公開しています。また、これまでどんな働きをしてきた人がどういう評価を得てきたか、という資料についてもすべてGitHub Enterprise上で見られるようにしています。シニアエンジニア以上になるには、自ら立候補して昇級のためのプレゼンをしてもらうのですが、その時にどういう基準で昇級の判断をしたのか、といった資料をストックしているんです。
– では、新たに昇級を希望する人や、その可否判断をする人は、その資料を見ればこれまでの“判例”がわかるということですね。
そうですね。その資料だけでなく、一定の等級以上の人は全員自ら立候補して判断をされるという経験をしているので、自ずと判断基準が自分の中で蓄積されていくんです。
例えば昇級できなかったとき、何がダメだったか考えますよね。同じ時期に周囲で昇級した人がいれば、その人は何がよくて、自分は何がダメだったかを考えます。そうして、自分の中で判断基準が固まっていくのです。
だから、細かく明文化はしていませんが、判断基準がブレないような評価軸というのは持っています。その評価軸というのが、先ほど言った「広い視野で仕事に取り組めるエンジニア」。例えばコードを書くことで言ったら、自分のサービスだけでなく、他のサービスにも役に立つプログラムを書けたらなお良いし、それがOSS（オープンソース・ソフトウェア）になってもっと広く使われれば最高ですよね。
社内横断チームのコミュニケーションの心得
– なるほど、そのエンジニア像が根底にあるんですね。ここからは、エンゲージメントスコアが非常に高い技術基盤チームについてお聞かせください。社内横断的な部署ということで、他部署と連携して開発する際のコミュニケーション上のポイントはありますか？
技術基盤チームは、横断的に複数のサービスの課題解決を行うことがミッションなので、他部署とのコミュニケーションについては特に考慮しなければなりません。ポイントとなってくるのが「課題を一緒に見つける」というアプローチ方法です。
同じ会社なので、他部署のサービスでもプログラムの内側は見られるんですね。そうすると、例えばプログラムの言語バージョンが古いとか、開発プロセスに改善の余地があるとか、いろいろな課題が見えてきます。ただ、そうした課題をそのサービスの人たちに伝えても、「いきなりなんだ」という気持ちを抱かせてしまい、すんなり受け入れられづらい。それより「まずは課題について理解してもらって、一緒に解決していく」というアプローチの方がコミュニケーションが円滑に進むんですね。
– 目線を合わせるんですね。でも、課題を正確に捉える、というのも難しいと思うのですが？
昨年から技術基盤チームとは別に、デザイン戦略チームという、デザイン思考を社内横断的に推進する組織を作ったんですね。そのチームは、課題を他部署の人たちと一緒に正確に捉えられるようにワークショップ（体験型講座）を行っています。
– 具体的にどういったワークショップをやられていますか？
まずは小さな機能開発のようなものを題材に、デザインスプリントをあちこちで行いました。インサイトを見出し、「Crazy8s（クレイジーエイト）」という手法を用いてアイディアを思いつく限り書きだし、最終的にプロトタイプを作って発表する、といったことです。目に見える形で議論することで、デザインの問題点をより明確に把握するためです。他にはサービスの名前を一緒に考えたり、ユーザーインタビューを一緒に行ったりするなど、デザイナーにはいろいろチャレンジしてもらっています。
「やっていき、のっていき」
– ワークショップの開催や、そこに積極的に参加する風土というのはどのように作っていったのでしょうか？
1つは、そうしたことに積極的なメンバーをアサインしている、ということがあります。それに加え、分かりやすいオリジナルの言葉でビジョンや理念を伝える、ということをしています。
例えば、昨年僕が作った言葉で「やっていき、のっていき」というものがあるんですね。これは、リーダーシップとフォロワーシップの関係についてキャッチーに表現した言葉です。「やっていき」はリーダーシップのことで、自主的にワークショップを行う、といった行動を指します。こうしたリーダーシップが高く評価されるのはよくあることだと思うのですが、一方で参加する側がいないと意味がないですよね。「のっていき」というのは取り組みに積極的に参加する側のことを指し、こうしたフォロワーシップも、リーダーシップと同じくらい価値のあることなんだよ、と伝えたかったのです。
– 確かに説明的な文章より、キャッチーな言葉は印象に残りやすいですよね。ちなみに、最新作はあるんですか…？
まだ、全然広まってませんが、「SKY」という言葉を考えました。「世界的な基準でヤバイ」の略です。意味は…そのまんまです（笑）。せっかくならグローバルな視点でいろいろやろうよ、という意気込みを言葉にしました。
エンジニアリングもマネージメントも対象は「人」
– これまでお話いただいたことを実践するには、栗林さんが経験されてきたエンジニアとしてのスキルとはまた違う、マネージメントのスキルが必要だと思います。こうしたスキルをどのように習得していったのでしょうか？
そもそも、私はエンジニアリングとマネージメントが別物だとは思っていないんですね。いずれも「何かをつくる」という点では共通しているからです。組織や文化づくりもそうですよね。「人にいい環境を作って、よりよいパフォーマンスを出してもらう」という点では似ているんですよ。
相手が人なのか機械なのか、という違いはあるかもしれませんが、昨今ではエンジニアリングにしても機械の先にある人の心を捉えなければいけません。こうしたエンジニアとして培ってきた視点や考え方というのは、マネージメントの業務にもしっかりとつながっています。
– 今、エンジニアからマネージャー職を目指している人にとっては、とても心強い言葉だと思います。具体的な取り組みからマネージメントのエッセンスまで非常に濃いお話を聞くことができました。本日はありがとうございました！
