こんにちは。SOLMU PdMの吉村です。今回は、あんちぽさんの愛称でお馴染みのGMOペパボ株式会社 取締役CTO 栗林健太郎さんにインタビューをさせていただきました。

ーー御社の事業内容を教えてください。

GMOペパボ株式会社は「もっとおもしろくできる」という企業理念を掲げ、「インターネットで可能性をつなげる、ひろげる」というミッションのもと、レンタルサーバー「ロリポップ！」やネットショップ開業・作成サービス「カラーミーショップ」、国内最大のハンドメイドマーケット「minne」、オリジナルグッズ作成・販売サービス「SUZURI」などのインターネットサービスを提供しています。場所や時間、背景にとらわれず、いろいろな方がインターネットで可能性を開花し、活躍するための環境を創造していくことを目指しています。

ーーエンジニアになったきっかけを教えてください

大学では法学部に在籍していました。卒業後、数年ぶらぶらした後に奄美市役所に入所することになるのですが、それまでは全くエンジニアリングをやっていませんでした。趣味でホームページを作りはじめてはいたのですが、その当時のインターネットは、まだホームページの手書きスタイルが主流で、ブログも出ていない状況でした。

手書きでのホームページ制作が面倒臭くなり、プログラミングすれば自動化できることを知ったのがきっかけで、そこからのめり込んでいきました。その後、舘野さんをはじめとした方々とネット上で知り合いになり、前職のはてなや現在の会社でのエンジニア・マネジメントに繋がっています。

ーーはてな在籍時に技術力はどう培ったのでしょうか？

それまでは趣味的に一人でやっていました。自分でサービス作ったり、プログラムコードを書いたりと量は書いていましたが、チームでのプロダクト開発の経験はないので、入社した当初は苦労しました。自分もそれなりにやってきたつもりでしたが、優秀な人たちとチームを組んで開発するというのは大変でした。ただ、そこで必死に喰らいついたので、苦労と同じくらいに開発力はついてきました。その頃に参加していたコミュニティの雰囲気の影響もあり、どんどんコードを書いて、公開してフィードバックを社内外からもらいつつ、楽しく開発をしているうちに技術力も伸びてきました。

ーーCTOになるまでのキャリアについて教えてください

はてなに在籍していた頃、様々なサービスを開発しているうちに、足回り（技術のプラットフォーム）を自分でもっと整備して、自分のやったことにレバレッジをかけたいと思うようになり、2012年にGMOペパボへ入りました。

当時の技術責任者が、技術基盤整備エンジニアというポジションを作ったという話をしていて、自分もそこに技術的なキャリアを求めていたので「これは願ったりかなったりだな」と思い、応募しました。

基盤整備エンジニアとして、サービスを横断するような働きをしていると、組織的な課題や技術的な課題を組み合わせたものとして解く必要があるものも見えてきます。

そうなってくると、技術的な取り組みも行いますが、組織の課題解決が必要になります。組織マネジメントの経験はありませんでしたが、必要性に駆られて勉強している中で、開発プロセスの立ち上げを実施し、今では当たり前になったいわゆるスクラムの導入みたいなことを始めました。そうするうちに、組織の力や個々の人たちをエンパワーすることでより成果を挙げることができるとわかってきました。

まずはあるチームに入り込んでスクラムの導入や立ち上げを行っていき、徐々に会社全体に広げていきました。2014年8月に技術責任者となり、そこからマネジメントをやるようになりました。

ーースクラムの普及等は根付かせるのが難しいと思いますが、工夫したことはありますか？

上の人を抑える、会社の中の人だけでやらないという2つがあると思っています。
ボトムアップで実施するのも重要ですが、マネジメント職やその上司が腹落ちしていないと「何をやっているの？」となり、元に戻されたりするので、きちんと対話をしながら、実現するようにしていました。
また、同僚が「こうしよう！」と言っても説得力に欠けることがありますが、そこに外部の実績のある人がきて「こうだぞ」と言われると納得できることもありますよね。というのがあってこの2つを心掛けていました。

ーーエンジニア組織のマネジメントや、働く環境をよりよい環境にしていくことで、特徴的なポイントはありますか？

1on1をする、技術的に最新の状況にする、パソコン・設備など基本的なところを最先端にするようにしていますが、ただそれは特徴というよりベースの部分ですね。
弊社の制度として特徴的なものを2つ話しますと、まず「職位制度」があります。ルーキーのエンジニアから、専門職のシニアエンジニアとかプリンシパルエンジニアなど、専門職としてのグレードを設けています。それぞれの専門職のグレードを作り、それが上がればマネジメントをしていなくても昇給できる体制を作りました。
グレードを作るだけなら他社にも同様の制度はあると思いますが、弊社ではそれに加えて昇格するプロセスの透明性を重要視しています。具体的には、まず立候補してもらい、GitHub Enterpriseでのプルリクエストで自分がその職位としてどうふさわしいかという主張を書き、それを見た上のランクの人によるディスカッションで「上がる」か「ステイ」かを決めるという、透明性を担保したプロセスを踏んでもらっています。

社内エンジニアというコミュニティがある中で、この会社でより優れたエンジニアってこういう人だよねという共通認識をコミュニティの中で醸成できる仕組みが、ペパボの「職位制度」です。

もう1つが、昨今その重要性が指摘されていますが、エンジニアリングマネジメントに該当する職位を3年前から設けています。GMOペパボの中では「チーフテクニカルリード」「テクニカルリード」をエンジニアマネジメントのラインにおき、いわゆる事業責任者のようなマネージャーではないし、専門職としてのエンジニアでもない、エンジニアのリーディングやマネジメントをするという職位を置いています。

なぜそうしたかというと、弊社にはホスティング事業、EC支援事業、ハンドメイド事業があり、それぞれのサービスもどんどん大きくなっています。それに伴い、CTO1人では全てを見るのが難しくなってきています。そこで、事業部を1つの会社と仮定してCTOを一人ずつ置いています。そうすると自分自身の想いはその人たちを通じて伝えられるし、逆もそうですし、意思決定などを任せることでスピード感も速くなります。このようにエンジニアリングマネジメントのラインを早期から敷いてきたのがもう一つの特徴です。

ーー現場のエンジニアとマネジメント職・CTOの違いを伺いたいです。視点が変わった点はありますか？

スコープがどれだけあるかだと思います。

見る「幅」という意味の「領域のスコープ」と「時間軸のスコープ」。それが縦横の軸だとしたら、どこまで広く取れるか、取るべきかの違いだと思っています。例えば現場のエンジニアが領域のスコープと時間軸のスコープを10と10で取っているとしたら、マネージャーは領域のスコープが20とか。開発のプロダクト、チームビルディング、予算管理とか。だけど時間のスコープは同じぐらいで10とか15とかで変わりません。CTOは領域も時間軸もさらに広く30などで見ていく必要があります。その2軸においてどれだけ見ていくことができるかが求められていると思います。ただ同じ領域においても現場エンジニアの方が密度があるので、そういう違いもあると思ってます。

ーー現場エンジニアのマネジメントで工夫はありますか？

トップダウンとボトムアップがあると思っています。
トップダウンも堅い感じではなく、「やっていき・のっていき」と社内では表現しており、「やるぞ！」としてリーダーとして引っ張るのが「やっていき」、それに対して「面白そう！やろう！」と付いていくのが「のっていき」だという話をしています。トップを含めマネジメントをする各レイヤーが、年初や半期に1回、様々なレイヤーで集まりを開いて、僕らが今やりたいのはこういうことだよねとか、私だったら技術的な解釈や方向性の話をしたりします。さらにその下のレイヤーでは、社長やCTOが言っていることは、自分たちとしてはこういうことだよねという解釈をして広げていくことで、数珠つながりに「やっていき」が広がり、トップダウンの情報がみんなに浸透していくようなプロセスを取っています。

逆にボトムアップでやっているのは、現場のメンバーから面白い提案が出てきたときに、リーダーシップをとってそれをどう掬い上げるかが重要で、現場の人が「やっていき」を出してきたときに僕みたいな人が「あ、それいいね。こうやったらもっと良くなるよね」とレビューをしつつ基本的には進めていきます。僕らが「のっていき」をするということを醸成していくために、エンジニアリングということでは1ヶ月に1回、エンジニア全員を対象に立候補してもらってTech Meetingみたいなことをやってもらいます。現状の取り組みや今後やりたい事の発表をしてもらったり、あるいはそういう公式な場ではなくてもどんどん各自のアイデアをSlackやGitHub Enterpriseに投げてもらって、それを拾い上げてみんなに拡散してというしくみを用意することで「トップダウン」と「ボトムアップ」で意見を出したり、ビジョンを浸透させたりしています。
逆に、こういう考えや技術を持っている人がいることを上層部が知らないと、やれることもできなくなるので、それを吸い上げるような仕組みもあったりします。

ーー数珠つながりのトップダウンを具体的にどうやっていくのですか？

わかりやすい事例でいうと、弊社では昨年セキュリティの事故があったので、全社的な方針としてセキュリティ対策の取り組みをやっていくことが急務となりました。

もちろん業務としても実施していくのですが、それとは別にセキュリティ対策はコストセンターという考え方ができます。自分たちでサービスをやっていて、かつセキュリティに対するノウハウも技術としてはある程度蓄積されているので、「セキュリティってある種のコストセンターだけど、そういう意味では自分たちの技術を使えば事業になるんじゃない？」という社長の一言がありました。それを受け、ホスティングやECなどのサービス運営で培ってきた知見やセキュリティチームとしての技術を統合して、「なめらかなセキュリティ」というコンセプトを私の中で作っていきました。

まず、例えばセキュリティというとアラートへの対応とか、検知する仕組みを作って人が見て事故かどうか判断し、人が頑張って対応するなど人手が掛かるので、できる限り効率化したいと考えます。それを実現するために、間に情報を取り扱うハブみたいなものがいるよねと考えると、その実装方法を他のメンバーが考えてくれたり…そういった粒度で繋いでいきますね。

そこでの技術選定は、担当する人が選べばいいというか、その人のテンションが上がるものを選んだ方がいいと思うので、突飛なもので保守性とか将来性が気になるもの以外は、基本的に自分が口出しすることなく、お任せしています。

コンセプトメイキングと体制作りが私のレイヤーの役割です。

ーー最後に告知がありましたら、お願いします。

2019/02/01にGMOペパボの鹿児島オフィスを開設しました。

鹿児島オフィスは、エンジニアの開発拠点としてだけではなく、街とか人とか会社とかを全部つないでいくハブのような場所になることを目指しています。その取り組みの一環として「SUZURI」とのコラボグッズ販売や各種セミナーの開催、そして現在、鹿児島大学との産学連携についても進めているところです。また、鹿児島ユナイテッドFCとのオフィシャルトップパートナー契約もしているので、街をあげて応援しているチームを様々な形で一緒にサポートしていきたいと思っています。2月1日にはオープニングパーティも開いたのですが、入りきらないほど多くの方がお祝いに駆けつけてくださり、期待していただいているなと感じました。その期待に応えられるよう色々と取り組んでいきますので、楽しみにしていてください！