創業から18年、クリエイターを支援する数々のインターネットサービスを提供し続けるGMOペパボ株式会社。同社で取締役CTOを務める栗林健太郎（あんちぽ）氏は、自社のエンジニアチームを「コミュニティ」と捉え、チーム作りやプロダクト開発を進めています。GMOペパボのエンジニアリングを支えるものは何か？ 今回のインタビューで核心に迫ります。
目次
OSS活動が、今の立場の第一歩
――まず、栗林さん（以降、本文中もハンドルネームの「あんちぽさん」と表記します）ご自身のこれまでのキャリア、GMOペパボでの経歴などについて教えてください。
栗林さん（以下、「あんちぽ」）：私はもともと大学で法学部に在籍し、卒業後の最初の就職先は市役所でした。それから、6年経ち、新しいことをやってみたいと、当時から日々重要性が高くなっていたIT業界へ飛び込みました。
エンジニアのキャリアは、2008年、株式会社はてなのWebアプリケーションエンジニアがスタートです。それから4年の経験を積み、paperboy&co.（※現・GMOペパボ。以降「GMOペパボ」で統一）へ転職し、今に至ります。
GMOペパボ内の職歴を簡単に説明しますと、2012年技術基盤を担当するエンジニアとしてスタートし、2014年に技術責任者、2015年に執行役員CTO、そして、2017年に現職の取締役CTOに就きました。
――このお話でまず気になるのは、やはり、2008年のはてなへの転職です。市役所職員からWebアプリケーションエンジニアへ転身したきっかけはなんですか？
あんちぽ：今の自分の活動の基本であるアウトプットとコミュニティ活動がきっかけです。市役所職員時代からPerlコミュニティに触れており、自分もモジュールを書いたり技術ブログを書いたりして、いろいろと活動していました。そうした活動をしている中で、これを仕事にしてみたいと考え、ちょうどWeb 2.0の潮流が成熟し始めたタイミングで転職した、という経緯です。
技術選定で大事なのは「適材適所」、そして、コミュニティへの還元
――なるほど。ご自身の活動の中で、さらに強いコミットメントを考えての転身だったわけですね。その後、4年間はてなに在籍し、2012年にGMOペパボへ移ったとのこと。この時期、日本では東日本大震災の直後で、混乱もある中で一気にクラウド化が進み、また、個人にとってはiPhone、そして、Android端末が普及し始めた時期かと思います。
そのタイミングでGMOペパボへ移り、それまでの経験と比較して感じたこと、違いはありましたか。
あんちぽ：それでは、少しGMOペパボのことをお話しさせてください。私が転職する前から、弊社はインターネットサービスを提供する企業として活動していました。2003年の創業時、主力事業はロリポップやムームードメインなどのホスティング事業でした。その後、2005年に新たな主力事業となるECとしてカラーミーショップをリリース、この間、また、その後もさまざまなサービスをリリースしました。そして、私がGMOペパボに入社した2012年にminne、2014年にSUZURIと、クリエイターを支援するインターネットEC支援・ハンドメイドサービスの拡充が始まっています。
このような事業拡張・成長の中で技術的な面での大きな変化は、Webアプリケーションの開発基盤がPHPからRuby on Rails（以降、「Rails」）へシフトしたことでしょうか。まさに私が入社した2012年前後からの変化です。その理由の1つは、同時期にすでにRuby開発コミュニティにおいてさまざまなプロダクトに関わり、のちにRubyコミッタになった柴田博志さんが同じくGMOペパボへ入社したことです。
また、会社としても、2008年にリリースした写真共有サービス「30days Album」の開発・運用でRailsの知見は持っていましたので、シフトすることへの抵抗はなかったように記憶しています。
Railsへのシフトは顕著な例の1つですが、技術選定をするうえで私がとくに重要だと考えているのが「適材適所」です。たとえば、Railsへのシフトに関しては、PHPよりRailsが良いなど、言語やプロダクトの良し悪しが理由だったわけではなく、2012年のGMOペパボとして、（技術の成長度合い、エンジニアチームの状況など）開発を進めるにあたって最適な環境がRailsだったからです。
適材適所には、実際に開発するエンジニアたちの気持ちも含めています。実際にコードを書くエンジニアたちが楽しいか、好きで書けるかといったことですね。また、それと同時に、私たちはOSSの恩恵を受けて開発を行い、事業を運営しています。ですから、OSSコミュニティ還元できるか、還元しているかということも技術選定の大きな理由となっています。OSSを使う意味、意義があるかどうか、です。
Railsの話ばかりしましたが、Rails一辺倒ではなく、2021年現在ではパフォーマンスの観点からNode.js、また、パフォーマンスが求められるミドルウェア等についてはGoやRustなどの言語も活用しています。このような考えも、まさに適材適所によるものです。
2021年のGMOペパボの組織とエンジニアチームの関係
――それでは、2021年のGMOペパボの組織、エンジニアチームについて教えてください。現在はどのような体制になっていますか？
あんちぽ：2021年8月現在、GMOペパボが提供するサービスは11種類あります（ホスティング5、EC支援5、ハンドメイド1）。そして、エンジニアの総数は2021年6月末時点で117名です。
どのような体制かというと、ベースは事業部制です。先ほどの11のサービスを、ホスティング事業部、EC事業部、minne事業部、SUZURI事業部に割り振り、事業部ごとにサービス開発・ビジネス開発を行う体制です。
現在は事業部とは別に、技術部とセキュリティ対策室という、事業部を横断的に管轄する2つの部署が存在します。さらに、技術部には技術基盤チーム、データ基盤チームに分かれています。
事業部制をアップデートし、事業部制＋横断的なインフラ体制へ
――この体制は、あんちぽさんがGMOペパボに入る前からですか？ それとも入ってから変わった部分、変えた部分はありますか？
あんちぽ：ベースとなる事業部制は、私が入社する前、創業時からほぼ同じと聞いています。大きく変わったのは、ちょうど私や柴田さんが入社した2012年に技術基盤チーム（の概念）ができたあたりでしょうか。
それまでは開発にたずさわるエンジニアはもちろん、インフラエンジニアもそれぞれの事業部付けで配属されていて、各事業部がそれぞれの扱うサービス・プロダクトの開発や運用を担当する体制でした。この場合、それぞれに所属するエンジニアが、局所最適化を図ることになります。
弊社はオンプレミスでインフラを運用していたため、最適化が進むことでインフラがサービスごとに異なっていくなど、サービスの成長や数の増加に合わせ乱立状態になるという課題が顕在化していきました。
そこで、私がCTOになった2015年ごろに、技術戦略の一環としてプラットフォームを横断的に見る技術部を作り、さらに横串で見るセキュリティ対策室の立ち上げとつながります。なお、技術基盤チームの中に、2020年にデータ基盤チームを新たに立ち上げ、今の組織構造になりました。
ちなみに、技術基盤チームとデータ基盤チームの役割は、技術基盤チームは先進的な取り組み、正式採用の前の技術試用などを積極的に行う、傭兵的な位置付けの組織、データ基盤チームは、自社で開発するユーザの行動ログや属性情報を収集・分析・活用するための全社基盤「Bigfoot」の開発・運用を行っています。
事業部制と横断のバランス
――サービスの成長による、技術基盤の分散、結果として事業部制と横断的なインフラチームの体制になったと理解します。この体制に移行して、ご自身ではどのように考えていますか？
あんちぽ：事業部制を取っていた理由には、サービスごとにフットワークを軽くし、開発や運用、また、トラブルに対応する必要があったからです。とくに、ユーザに近い部分での対応やフィードバックは事業部制の形が適しています。
一方で、インフラは共通化できる部分が多く、事業部ごとにパフォーマンス向上や最適化を図ることは、会社組織全体で見ると無駄が増える可能性が高くなります。他にも、モバイル対応やフロントエンドに関する情報交換など、横串できる技術に関しては横断的なコミュニケーションが年々必要となっています。
それが、技術部やセキュリティ対策室が生まれた背景です。自社で共通化できる技術は共有し、コミュニケーションの活性化、結果として効率化につながるわけです。2021年時点ではこの体制で進めていますが、他の切り口も考えられますし課題は年々変化するため、つねに変化できる組織にすることは意識しています。
自薦しなければ上がらない、GMOペパボの等級制度
――企業の状態に合わせた組織、また、それを支えるエンジニア組織を目指しているわけですね。今のお話で気になったのが人事評価・考課です。事業部および横断部門での職制や評価はどのようにしているのでしょうか。
あんちぽ：GMOペパボは今、8等級のグレード制でエンジニアの基準を設けています。この制度の大元は、私の前任の技術責任者がいた2011年ごろに作られたものです。
8等級のうち、下位の3等級はルーキー、アソシエイト、アドバイザーの3つを用意しており、入社後に成果と（部署側の）評価で昇格します。
その上の4等級以上はエンジニアの場合、図（左側）のような職位制度となっています。
※GMOペパボ株式会社の採用ページより引用
上からチーフエンジニア、シニア・プリンシパルエンジニア、プリンシパルエンジニア、シニアエンジニアの職位があり、評価は半期ごとに行い、それと同時期に、職位昇格を行います。
この4等級以上の職位昇格はGMOペパボならではの仕組みで、昇格を希望する場合、まず自身の立候補（自薦）が必要です。立候補後、エンジニアに関しては上級エンジニアの面談を経て通過すると4等級以上の専門職として昇格できます。
昇格の基準は、各サービスや会社全体の技術的な問題解決、技術力の底上げ、事業価値の創出にコミットを行えているかどうかが判断基準となります。
――自薦ありきでの昇格制度は非常にユニークですね。一方で、評価には一定の基準や客観性が求められると思います。そのあたりについて詳しく教えてください。
あんちぽ：おっしゃるとおり、昇格に自薦が必要というのは珍しいかもしれません。しかし、昇格するには自発的な行動や責任もありますので、自分から動いてもらうことが必要です。そのうえで、GMOペパボではエンジニア同士で行う3つの評価軸として、
- 作り上げる力
- 先を見通す力
- 影響を広げる力
を重視しています。この3つの評価軸に対し、さらに3つに分けた、計9つのコンピテンシーに項目を分け記述するようなフォーマットを用意しています。
※ペパボテックブログより引用
まず、昇格希望者自身が評価資料を作成し、GitHub Enterprise（以下GHE）経由で上長に提出（プルリク）します。これもまたGMOペパボのユニークなポイントで、それぞれの評価資料はGHE上で全パートナー（従業員）が見られるよう、オープンなものになっています。
この評価資料は、評価する上級エンジニアだけではなく、他のエンジニアたちもコメントできるなど、全方位で評価資料を扱えるのも特徴的ですね。
余談になりますが、もともとはエンジニアの評価で使っていたGHEによるプルリクの仕組みは、今は全職種でも利用しています。GHEに慣れていないバックオフィスなどのエンジニア以外のメンバーも、今ではお互いで協力しながら利用しています。協力し合うというコミュニケーションにつながったのは、副次的な効果と言えますね。
次のフェーズに向けた課題解決としての「コミュニティ」型組織
――まさにOSS的に、オープンな評価、そして、メンバー間でのコミュニケーションと感じました。また、良い形でブラッシュアップが進んでいるようにも思います。そのうえで、2021年現在の課題はありますか？
あんちぽ：今までお話をしたように、初期の体制や前任の技術責任者から引き継いだ仕組みと、私や柴田さんが入社してから改定した部分が良いバランスで融合し、制度としてはしっかり整備されていると自負しています。中でも、9つのコンピテンシーによる評価資料とGHEの仕組みで、成長のプロセスが本人・周囲に可視化できている点は、エンジニアたちの成長に対して良い効果が出ているのではないでしょうか。
ただ、今が完璧な形なのかというとそうでもなく、きちんと整備した制度ならではの課題も見えてきました。その1つは、細かすぎる要件です。制度が整っている分、制度に合わせようとする意識が働き、結果として、要件に縛られるケースが見られるようになりました。
要件に縛られると目的と手段が逆転してしまう危険性があり、ここで今、私が解決策として目指しているのが「コミュニティ」型組織です。
具体的にどういうことかというと、整備した制度によりコミュニケーションの解像度が上がった一方で、最終的に詰める部分やサービス・プロダクトごとに出てくる固有の課題に対して、個別最適化、局所最適化を図れる体制です。
制度により、GMOペパボとしてのエンジニアコミュニティという枠を用意し、その中でエンジニア一人ひとりが周囲とサポートし合いながら、事業部や業務に合わせた成果を上げられる組織です。
整備された制度や基準だけで物事を判断するのではなく、自分自身がコミュニティメンバーの一人であるという意識、コミュニティメンバーとしてどうやってコミュニティ（GMOペパボ）の価値を上げ、外部に伝えていくのか、そういう組織であること、またエンジニアにはその意識を持ってもらうことが理想と考えています。
その時代の「クリエイターのあたりまえ」を支えるサービスと技術を提供できる会社を目指す
――OSSを最大限に活用し、インターネットの強みを生かしたサービスやプロダクトを開発・運用し続けてきたGMOペパボだからこそ目指す、コミュニティ型組織ですね。
最後に、CTOとしてこれから取り組みたいこと、展望を教えてください。
あんちぽ：コミュニティ型組織とともに、インターネットを通じてクリエイターを支えていくということが、私たちGMOペパボのミッションと考えています。
そのためには、サービスを開発するエンジニアとして、何ができるかを改めて考えています。私がGMOペパボに入社した当時は、エンジニアが扱える範囲は広く、何でも触ろうと思えば触れる時代でした。しかし今は、技術の進化とともに技術の細分化が進み、エンジニアと一口に言っても、たとえば、フロントエンド、バックエンド、SRE、機械学習など扱う範囲が多岐にわたり、また、その内容が深くなっています。
ですから、これからはまず専門性を意識し、専門的に業務にコミットしてもらうことが重要と考えています。そのために、私の立場としては、専門性を伸ばせるようなアプローチを心がけたいです。
また、今のコロナ禍という観点では、コロナ前とコロナ禍では利用者や表現者が求める事が大きく変わり始めています。すべてをオンラインで完結する意識はその一例です。このとき、どうしても社内でのコミュニケーションも希薄になりがちなので、今は月に1回、全エンジニアを対象としたオンラインミーティングを実施しています。内容は、私が全エンジニアに向けて、今、自分が考えていること、CTOとしてのGMOペパボの1ヵ月の方針を話す、と言ったものです。
コロナ前のように、対面でできていた部分を埋めるためのもので、できる限りコミュニケーションを活性化しています。他にも、最近『CTOが訊く』という、社内向けのインタビュー企画を行うなど、オンラインでできるものに取り組んでいます。
このような形で、技術動向に合わせた組織づくりのアプローチとともに、コロナの登場のように外的要因に合わせて、組織の在り方、コミュニケーションの取り方を変化させていくことが、現在意識していることですね。
GMOペパボの18年の歴史を振り返ると、ホスティング事業に始まり、ECやEC支援、さらにハンドメイドなど、つねに、「その時代に活躍するクリエイター」を支援するサービスを提供し続けてきました。今後も、クリエイターたちが今、何を必要とするのか、どこで表現をしているのかをキャッチアップし、そのために必要なもの、支える存在となるサービスやプロダクトを提供していきます。最近ではVRの注目が高まっていますし、VRもまたその可能性の1つと言えます。
今後も先を見据えたGMOペパボとしてのエンジニアリングとエンジニアコミュニティとして、その時代の「クリエイターのあたりまえ」を支えるサービスと技術を提供できる会社を目指します。
――ありがとうございました。
（聞き手：株式会社技術評論社 馮富久、撮影：中村俊哉）
