ゲームエンジンからセキュリティに至るまで、多くを自社エンジニアが内製するカルチャーを持つDeNA。それは会計や人事といった社内システムにも及びます。
その役割を担うのが、IT戦略部システム開発グループ。ややもすれば地味に見える部門ですが、実はモダンな言語や手法をどこよりも積極的に取り入れ、社内のニーズに高いレベルで応え続けているクリエイティブなエンジニア集団なのです。
チームの中心にいる、杉浦 祐司(すぎうら ゆうじ)に、その内実を伺いました。
花屋経営からの転身
ーーかつて“お花屋さん“を経営していたそうですね。
杉浦 祐司(以下、杉浦):そうなんです。たまたま実家の一階が空き店舗だったので、何か活用できないかなと思って。実家も私自身も花屋の経験やツテがあったわけではないのですが、花屋ならイチから立ち上げられるんじゃないかなと思って始めてみました。
ーー朝も早いし、お仕事はハードだったのでは?
杉浦:でしたね(笑)。早朝に市場に行って仕入れをして、それをスーパーに配達して、店でも売って……ということをやっていましたからね。ただ、ほぼ1人でやっていたので、ビジネスの流れも一通り経験できたのは、ビジネス感覚を身につける意味ではとてもいい経験になった。気づけば約10年も続けていました。
ーーなぜ、そこからエンジニアに転身することになったのでしょう。
杉浦:いろいろあって店をやめることになって別のことをしようと。学生時代からパソコンが好きで、プログラミングの専門学校にも行っていましたし、卒業後3年間はシステム開発の仕事をしていたこともあるんです。なので出戻った感じです。
ーー何社かを経て、2007年からDeNAに入社されました。ちょうどMobageができた頃ですよね?
杉浦:はい。毎週モバゲー用にサーバーを100台ずつ増やしていくような、すさまじい時期でしたね。
僕は当時あったアフィリエイト広告サービスのシステム開発の部署にいました。入金や滞留債権の管理をする必要があるので、自ずとシステム開発で手を動かすうちに会計にもくわしくなっていった。
2012年にその広告サービスが終了したタイミングで「IT戦略部」、自社のコーポレートシステムを手がけるこの部署に声をかけられジョインして、今に至ります。
ーー社内システムの部署であることに抵抗はなかったですか?
杉浦:まったく。僕は「定年するまでプログラマーの仕事以外、イヤです」と入社時から言っていたんですね。手を動かして、モノをつくり続けるのが、僕のキャリアビジョン。それができる環境ならば、モノづくりの対象にこだわりはなかったです。
結果としてIT戦略部は、僕にはベストな場所でした。
ーーなぜでしょう?
杉浦:社内の基幹システムは、通常、外部のSIer任せだったり、パッケージソフト(SaaS製品含む)だけを使うのがスタンダード。しかしDeNAは、パッケージソフトも当然利用しますが、アカウント管理の自動化や不便な部分を内製化したりするので、開発案件がなくなることがないんですよね。
とにかく手を動かせる。そのうえ、社内システムは、利用者がすぐ横にいるわけです。
ーー同僚が使うわけですからね。
杉浦:ゲームや他のサービスでも、僕らエンジニアが、直接、利用する方の笑顔や喜びをダイレクトに感じられる機会って実は少ないんですね。
しかし、社内システムには日常の場にそれがある。「すごく便利になったよ」とか「楽になって、助かった」とか。声をかけてもらえたときが一番テンション上がるし、ドヤ顔したくなる感じです(笑)。
ーー今はシステム開発グループで、どのようなお仕事をされていますか?
杉浦:会計領域のシステム開発をしています。クラウド型の財務会計システムであるNetSuiteを導入しているのですが、会計処理において不足している機能を追加で開発したり、他のSaaSとのデータ連携をするシステムの開発をしたりしています。
たとえばDeNAでは、利用しているサービスの支払いを1年分前払いすることがよくあるんです。その際に、支払いのタイミングで1年分まとめて計上するのではなく、各月各事業部へ配分して計上したいのですが、そのような機能がないために追加で実装しています。ちなみに、このシステム全体を「ROMEポータル」と呼んでいます。
内製エンジニアでつくり上げた一大システム「ROMEポータル」
ーー「ROMEポータル」はどのような経緯でつくられたのでしょう?
杉浦:「DeNAの会計システムをすべて刷新する」プロジェクトから生まれたものです。もともとは2年計画でしたが、結局3年かけて連携しているすべてのシステムも運用も見直した一大プロジェクトでした。
導入当初の「ROMEポータル」というシステムは、IT戦略用の運用機能(システム間連携等)の機能を載せたシステムでした。名称も「ROMEポータル」ではなく、「Ope Rome」という名前でした。その後、少しずつ利用者の不満を吸収する形で成長していったシステムが「ROMEポータル」になります。
さらっと言いましたが、ハードな作業でしたよ(笑)。
ーー内製にこだわる理由はどこにあるのでしょう?
杉浦:もともと、DeNA創業者・南場智子のポリシーからですね。 そして、「ないものはつくろう」「便利ならばつくろう」が社内の、また僕らチームのカルチャーとして根付いています。
社内システムもそうで、腕の立つエンジニアが現場からの要望を受け、どんどん機能改修するのが日常でした。私自身も個人的に相談を受けて「その程度ならすぐつくるよ」とササっとつくった社内システムがいくつもあります。
同時に、それをするにはビジネスの現場への視点も欠かせません。そんな視点を持つエンジニアが集まっているので、現場の声にいち早く対応できる。反面、さまざまなシステムが乱立して収集がつかなくなってきた面もありますが(笑)。
ーー裁量があって、自由に開発できる環境なんですね。
杉浦:使っている言語も、会計領域ではあまり使われないRubyやNode.jsなどモダンな言語も使っています。
Rubyを使い始めたのは私なのですが、元々使っていたPerlの後継のような言語でとっつきやすそうという興味本位で使い始めてみました。
これもそろそろ少し整理が必要だなとは思っていますが……。とはいえ、ガチガチのルールをつくるのではなく、一旦古いものは整理した上で、新しいものはこれからもどんどん取り入れていきます。そのような昔から根付いているDNAは残すつもりです。
ーー「ROMEポータル」は、またDeNAがインフラ基盤のすべてをオンプレからクラウドにシフトしたタイミングで、一緒に移行されました。
杉浦:これもハードなプロジェクトでしたね。
「せっかち」だから、10分を10秒にした
ーーサーバーの容量アップがリアルタイムでできるなど、クラウド化そのものは、サービス領域の課題解決がメインの狙いでした。社内システムのクラウド化のメリットというのは?
杉浦:社内システムだけでみると、ほとんどなかったんです(笑)。ただオンプレの環境がなくなるから、対応せざるを得なかった。加えて何も考えずに移行させると、むしろランニングコストが高くなる試算でした。
最初の計画では、オンプレと同じスペック、台数のサーバを用意してもらうことになってたんですが、複数のシステムを1つのフレームワークに統合させることで、コスト削減できるんじゃないかと閃いたんですよね。
これは、システム数を減らしたい自部門の方針とも合致してたので、担当システムのサーバコストを計算して、統合後のサーバのスペックを倍にしてもコスト削減できることがわかったので進めました。
ーー自ら課題設定してコスト削減に挑んだ。
杉浦:はい。どうせやるなら前より使い勝手がいいか、スピードアップできるか、コストがかからないか、など、メリットがないと意味がないじゃないですか。だから、クラウド移行のタイミングでこれまで複数に分かれていたサーバーを、1つに集約させるように整理。実際に(年間)300万円削減させることに成功しました。
ーーすばらしいですね。クラウド移行の際にもっとも大変だったのは?
杉浦:原価計算システムの移植ですね。技術的にうんぬんではなく、元のシステムをつくった人がすでにいなくなって、謎のソースコードが多々ある状態だったので(笑)。
ーー何でも内製できるデメリットがそういうところにあったわけですね。
杉浦:ただこれもいい機会だとゼロからシステムをつくり直しました。ソースコードをながめてみるよりも、経理にヒアリングしてつくり直したほうが早いし、いいものができるよなという判断。
結局、これまで10回クリックしなければできなかった計算が、ワンクリックでできるようになりました。クラウド化を起点にブラッシュアップできたわけです。
ーーこれが内製のメリットですね。
杉浦:そうですね。先程の「利用者が身近」なところにつながりますが、ユーザー目線がより強くなる面もあります。
「これは不便だろうな」「解決できたらうれしいだろうな」との考えが常に念頭にあります。
以前、「ROMEポータル」のとある経理システムの機能を修正するついでに、10分かかっていたレスポンスを10秒になるようにつくり変えました。
ーー驚異的ですね。どうやって実現したのですか?
杉浦:まず10秒にするという目標を立てました。これは、せっかちな自分がそのシステムを使うとしたら「10秒程度しか耐えられない」なという単純な理由です(笑)。
現状をベースに考えるのではなく、まっさらな思考で目標を立てる。すると工夫しないと実現できないし、抜本的にやり方を見直す必要に迫られます。どうせ古いソースコード見てもブラックボックスで混乱するだけなので、それは見ずに、仕様の大枠だけ把握してつくり直しました。
表示データをつくるためには、裏側で膨大なデータの突合が必要で、その処理に10分かかっていました。これを10秒にするのは不可能なので、バッチ処理でデータを突合してデータテーブルを常につくっておくことにしました。そうすれば、必要な部分のデータを拾い集めて表示するだけで済むので、10秒レスポンスを実現することができましたよ。
ーー実際に使う経理担当者からは喜ばれたのでは。
杉浦:そこはちょっと胸を張るというか、「でしょ?」とドヤ顔できるシーンでしたね(笑)。醍醐味です。
ーー仕事をするうえで心がけている事ってありますか?
杉浦:チームのミッションですが「長く使えるものを早くつくる」を心がけています。一般的なサービスのソースコードは寿命が短いことが多々あります。たとえばゲームのイベント用だったら期間限定ですよね。それに比べて社内システムは長く使うものなので、セキュリティリスク対応も含めてしっかりバージョンアップしながら使い続けられるような立て付けにしておくことが重要だと思っています。
あとは、運用チームが疲弊してしまうようなものは長く使えないですよね。たとえばマスターのメンテナンスをユーザー側でできず、運用側がすべて対応しないといけないとか。そういうさまざまな観点を含みます。でも長い時間をかけるのではなく、素早くつくるというのがDeNAらしさでもあると思います。
ーーそのためには、高い技術力も必要そうですね。
杉浦:最近、シングルポイントをやめようという方針のもと、スクラムを導入しました。一スプリントでペアプロかモブプロを最低一個はやると決めて、皆で集まって意見交換しながらやっています。他の人の考え方とかロジックの組み方とかを知れる機会なので、皆の成長に繋がると思っています。
一時的には開発スピードは落ちてしまいますが、全員が同じレベル感になることによるメリットの方が大きいはずです。今まで積み上がっているシステムのバラバラ感を抑制することにもつながるし、私にしかできなかったことを他の人もできるようになることで、総合的にはスピードも上がるはずです。
ーーそれだけ優秀なエンジニアが社内システムを創造し、磨き上げてくれるとなると、現場から幅広い要望が上がってきそうですね。
杉浦:はい。なのでチームは7人しかいないのに、リポジトリが130個もあるんですよ!つくることが楽しいのでつくりすぎちゃったかな。こちらは整理しようとしています。
定年までずっとプログラマーでいたい
ーー今後はどのようなキャリアを考えているんですか?
杉浦:定年するまでずっとプログラマーでいたい思いは変わりませんね。会社もその意思を尊重してくれています。50歳越えてマネジメントではなく現場から離れたくないなんて思いを認めてくれる会社は珍しいんじゃないですかね。
ーー今後新たに取り組もうと思っていることは何ですか?
杉浦:システムの整備が最優先です。4年計画で、130もあるレポジトリを整理したいと思っています。1日に書けるソースコードって少ない人でも500行、多い人だと1500~2000行は書けるんですよ。それが日々増えていくばかりだとものすごい量になるわけで。同時に整理していかないと破綻するに決まっていますよね。新しいものをつくり続けるためにも、不要なものはしっかり捨てていかないと。
ーーせっかくつくったものを捨てることに対して、ためらいはないんですか?
杉浦:まったくないですね。そう思う人もいるんですかね?私にはさっぱりわからない(笑)。つくる過程で満足できるというか。つくり終わったものにこだわり続けてもいいことないじゃないですか。つくったその瞬間に、それはもう過去のものなので技術負債になるんですよ。古いものは容赦なく捨てて、未来に向かい続けたいです。
ーー未来に向かい続ける仲間として、どのような人に加わってほしいですか?
杉浦:会計領域のシステムを扱いますが、会計に関する知識はまったく不要です。私もそうでしたが、やっているうちに覚えていくと思うので。あと、ソースコードを書けることは当たり前の条件なのでわざわざ語るほどのことでもないかなと。
とにかくものをつくりたい、手を動かしたい人にはどんどんジョインしていただきたいですね。
※本記事掲載の情報は、公開日時点のものです。
※本インタビュー・撮影は、政府公表のガイドラインに基づいた新型コロナウイルス感染予防対策ガイドラインに沿って実施しています。
聞き手:箱田 高樹 執筆:日下部 沙織 編集:フルスイング編集部 撮影:小堀 将生