GMOペパボ攻勢の裏側にあった「技術的負債を抱えない開発体制づくり」3つの布石

2015/03/09公開

今年に入り、ハンドメイドマーケットプレイス『minne（ミンネ）』のTVCMを開始するやいなやスマホアプリが100万ダウンロードを達成するなど、攻勢に出ているGMOパペボ。

国内最大級のハンドメイドマーケット『minne（ミンネ）』

サービスグロースへの積極的な投資により、2015年12月期の営業利益・経常利益・最終利益をゼロとする業績見通しを出して話題にもなったが、その背景には約3年前から行ってきた開発基盤の整備があるという。

新しい開発環境への移行、言語やフレームワーク、ミドルウエアなどの継続的なバージョンアップ、テストの自動化、スクラム開発の導入など、東京・福岡の両開発拠点における環境改善を地道に進めてきた結果、このタイミングで「攻め」へ転じた形だ。

さらには、自社クラウド環境を構築しての脱オンプレミス化による開発や運用の効率化、高速化をもくろんでいるという。

しかし、こういった改善は旗を振るだけではなかなか進まないもの。通常業務の傍らで、慣習を変え、新たなものを取り入れるのは骨が折れることでもある。

そこで同社は3年前、開発環境の改善をミッションとする「技術基盤チーム」を設立。現在は技術責任者で技術部部長の栗林健太郎氏と同チームのチーフエンジニア柴田博志氏を筆頭に、社内外からエンジニアをリクルーティングし、改善活動を推し進めてきた。

そのプロセスを紐解くと、長くサービス運営を続けることでどうしても抱えてしまう技術的負債を解消する、3つのポイントが浮かび上がった。

【1】社長直轄のチームで改善活動を行ったこと
【2】CIツールの導入では「ゆるやかな導入支援」を心掛けたこと
【3】「評価連動」の仕組みを作り、サービス開発チームを巻き込んだこと

その詳細を、栗林氏と柴田氏に聞いた。

経営トップの意思による“タスクフォース”的チームを編成

（写真左から）技術責任者で技術部部長の栗林健太郎氏と、技術基盤チームのチーフエンジニア柴田博志氏

前述した『minne』のほか、レンタルサーバーサービス『ロリポップ！』やショッピングカートのASPサービス『カラーミーショップ』など複数のサービスを展開するGMOペパボでは、3年前に技術基盤チームができるまで開発環境のマネジメントは各事業部に任されていたという。

「GMOペパボは10年以上続いている会社です。開発チームとしては、過去の良い遺産を受け継ぎつつも、どう未来志向の体制を築くかが課題になっていました。それゆえ作られたのが、横断的に環境改善を行う技術基盤チームです」（栗林氏）

発足の際にポイントとなったのが、【1】で挙げたような社長直轄のチームとして立ち上げた点だ。

現在約80名いるエンジニアはサービスごとに担当が異なる上、東京と福岡に分かれて開発業務を行っているため、インフラの整備や新たな開発手法の導入は草の根的な活動ではなかなか進まない。

そこで経営トップの意思として「継続的に技術的負債を取り除く」と示すことで、全チームにまたがる改善活動がスムーズに始まったと栗林氏は振り返る。

同社の開発基盤刷新への取り組みは、栗林氏がGMOペパボに入社して以降、加速度的に進んだ

この技術基盤チームが手掛けた中でも大きな改善の一つとなったのが、各サービスで使われているPHPやRuby on Railsのバージョンを最新版に対応し続けられるようにしたこと。

「新しいバージョンを継続的に取り入れていかないと、気が付いたら身動きできない状態に陥ってしまうケースがあるからです」（柴田氏）

例えば正式リリースから今年で7年目になる写真の共有・保存サービス『30days Album™』はRuby on Railsで開発されているが、2年前まで1.8.6だったRubyのバージョンを一気に最新の2.2.0にアップデート。それも、昨年12月のRuby 2.2.0のリリースから1カ月以内にバージョンアップしている。

合わせて、全チームでサーバ構築やモバイルアプリのテスト自動化を促進すべく、JenkinsやDroneの導入を行いながら、包括的に開発環境をRebuildしてきた。

ただ、前述したように、新機能開発やユーザビリティの向上に突き進みたい事業開発チームと根本的な体質改善を図る技術基盤チームとは短期的な利害が一致しない面もある。

そこでは、【2】で挙げたような忍耐強さが大事になったと栗林氏は明かす。

「各サービスのマネジャーとよく相談しながら、それぞれの事業のフェーズに合わせて進めてきました。『今、CIツールを導入しておかないと数年後につらくなるだけだ』といった話をすれば必要性は理解してもらえます。そうして各開発チームの中から優秀なエンジニアをアサインしてもらい、僕らも現場に入って一緒に手を動かしてきました」（栗林氏）

その改善期間は、長い時には1年に及んだ。

「単調な作業期間が長くなると、疲弊しますよね。別のサービス開発チームがどんどん新しい機能を生み出していたりしたらなおさらです。そこは適度にマイルストーンを設定し、『ここまで達成した！』という気持ちを共有することで乗り切りました。こうして一つ一つやり切ってきたことで、現在はだいたい50％くらいのテストが自動化できていますし、ほぼ全チームがスクラムで開発するようになっています」（柴田氏）

エンジニアの貢献度はエンジニアが最もよく分かっている

技術基盤を変えるだけでなく、社内の評価制度まで変える道を選んだ理由とは？

さて、技術基盤の改善に「各開発チームの中から優秀なエンジニアをアサイン」となると、気になるのがアサインされたエンジニアたちの評価だ。

例えば新しい環境に変えることで新規開発が滞ったチームや人より、古い環境のまま新しい機能を生み続けた方が、高く評価されることはないのだろうか。

傍目には、新環境への移行より、ユーザー数を増やすことの方が分かりやすく評価もされやすいと感じるが、この課題をクリアするために行ったのが【3】で挙げた評価連動の仕組みづくりだ。

「ユーザー数などの数値目標は、何をやってでも同じように達成できるのかというと、そうではないはず。同じ数字でも、より良く、よりうまく達成できた方がいいですよね。可読性の低いコードで達成するより、クリーンなコードを書いてしっかりテストもして達成した方がいい。これは気分の問題だけでなく、中長期的に見た時には、より良く達成したサービスの方が伸びると考えています」（栗林氏）

この「より良く」の評価を、栗林氏ら技術基盤チームのメンバーが直接行うことで、彼らによる一次評価＋各サービスの担当マネジャーによる二次評価でエンジニア1人1人の貢献度を測るように変えたという。

同社は2012年の1月から、全社員を対象にした等級制度とは別にエンジニア用の等級を設け、能力に応じて待遇が向上する専門職評価制度を運用しているが、2014年以降は技術基盤づくりへの貢献も評価に加味されるようになった。