インフラ戦略最前線~トップ技術者たちが語るインフラ戦略のリアルな裏側~

2020年7月15日に開催したFLEXY主催CTOmeetup。今回のテーマはインフラ戦略の最前線です。

登壇するのはDeNA、メルカリ、DMM、ミクシィの計4社のCTO及びVP of Backendのみなさん。

応募者多数、また登壇最中も質問がかなり寄せられる大人気イベントとなりました。

日本を代表するトップ技術者たちがインフラ戦略についてどのような考えを持っているのか、各社のインフラ事情も含めてオンラインで2時間ディスカッションしていただいている様子をライブ中継しました。

<パネラー>
●株式会社メルカリ 執行役員 VP of Backend 田中 慎司 氏
●合同会社DMM.com CTO 松本 勇気 氏
●株式会社ミクシィ 取締役CTO 村瀬 龍馬 氏

<モデレータ>
●株式会社ディー・エヌ・エー 常務執行役員 兼 CTO 小林 篤 氏

登壇各社のインフラ事情Overview

YouTube Liveでの中継イベントは登壇各社のインフラ事情の説明からスタート。

各社の共通点は、オンプレからクラウドへの移行が現在進行系で進んでいることです。

移行の経緯や手法も語られた本イベントレポートは、特に自社サービスのクラウド移行を検討している方必見です。

DeNA / 緻密なコスト試算によって経営承認を得てクラウド移行を実施

株式会社ディー・エヌ・エー 常務執行役員 兼 CTO 小林 篤 氏(以下、小林):株式会社DeNAのCTOを務めている小林と申します。

DeNAはもともとオンプレ+Perl、プロジェクトによってはRubyやAWSという技術スタックで事業開発を進めていました。それが近年は徐々にAWSの利用が増え、経営としてオンプレとパブリッククラウドどちらで進めるのか、方針を決める必要性が出てきました。 その結果、2018年に社内システムも含めてパブリッククラウドへ移行することが決定し、現在はAWSやGCPをメインとして、IDCF、Tencent Cloud、Alibaba Cloudなどを必要に応じて利用しています。

クラウド移行にあたっての一番大きな論点はコストでした。DeNAは長らくオンプレを利用していたのでそれなりの規模に成長しており集約効率が高く、インフラコストが圧倒的に安かったんです。当初、オンプレとクラウドを比較すると4倍ものコスト差があり、クラウドは全く勝負になりませんでした。

ただ、このときは償却が切れたサーバーのランニングコストと比較しており、サーバー入れ替えのための購入費なども試算に入っていませんでした。比較基準に問題があるということで、極力条件が揃うような形で試算し直してみると、クラウドのほうが約2倍高いという結果になりました。

これなら可能性がありそうだったので、ほかにもBCPの観点でのDRやクラウドにかかるコストのさらなる最適化、インフラの運用人員などの条件を付与。最終的にオンプレとクラウドでほぼコスト差異は出ないというレベルまで落とし込むことができました。 コストに差が無いのであれば、優秀な社員をよりクリエイティブな業務に向かわせたいという意見を経営陣に伝え、クラウド移行の承認に至ったのです。

経営承認されたのは2018年6月で、基盤の設計などの準備を経て、2019年10月からオンプレ上にあるサービスを本格的にクラウド移行し始めました。現在は移行期のど真ん中ですね。2021年4月に3カ年計画が終わり、全てのクラウド移行が完了する予定です。

移行期の中で我々が得た知見は積極的に外に発信しようとしていて、さまざまなカンファレンスでお話ししたり、DeNAのエンジニアブログでインフラチームのことを書いたりしています。Twitterアカウント(@DeNAxTech)でも取り組みをお伝えしていますから、良ければフォローお願いします。

メルカリ / マイクロサービス化を目指し、GCPメインでクラウドを活用中

株式会社メルカリ 執行役員 VP of Backend 田中 慎司 氏(以下、田中):メルカリの田中です。よろしくお願いします。

メルカリのこれまでのインフラは主にアプリケーションサイドの言語がPHP、データストアはMySQL、インフラはオンプレミスという環境でした。

創業した2013年からずっと同じ環境で続けてきましたが、2018年頃にそろそろマイクロサービスを検討しようということになりました。社内で話し合った結果、言語はGo、データストアはCloud Spannerなど、インフラはGCPを中心として進めることにしました。 このときコスト面に関する議論も当然出たのですが、プロダクティビティやアジリティなどを重視して、マイクロサービスへの移行を決定しました。

移行にあたって難しかったポイントは、もともとオンプレ環境が北海道のデータセンターにあったことです。マイクロサービスの環境は東京で作ろうとしていましたから、データセンター間とのレイテンシの大きさがアーキテクチャを考える上でのハードルでした。

具体的なマイクロサービス移行の手順については以下のような形です。マイクロサービスに移行する以前は非常にシンプルな構成で、オンプレミスの環境にアプリケーションサーバーがあり、裏にデータベースがあるという状態でした。

これがマイクロサービスに移行すると一気に複雑になりました。まず東京側にAPI Gatewayと呼ばれる入り口があり、そこにAuthorityという認証を扱うサービスが並列しています。その裏にマイクロサービス群が並ぶのですが、移行するにしても一気に全てをマイクロサービス化できるわけではないので、当初は多くのトラフィックをMercari API、つまりオンプレミス側に飛ぶ形にしていました。

加えてGCPの環境とオンプレの環境に物理的な距離があるので、GCPだけにマイクロサービスを置けばいいという話でもありませんでした。マイクロサービスを切り出すタイミングでGCPかオンプレどちらに置いたほうが良いのか、少しずつ設計しながら進めていきましたね。

データも最初は全てMySQLにありましたが、少しずつGCPに移動させているところです。数年かけてじわじわ進行していて、まだ道半ばですね。

システム的なアップデートと並行して、組織的なアップデートも行なっています。以前はモバイルエンジニアとバックエンドエンジニア、DevOpsを扱うSREのエンジニアが職能ごとに分かれていました。現在はバックエンドエンジニアにマイクロサービスを切り出す単位として「ドメイン」という考え方を導入しています。バックエンドエンジニアがドメイン単位でチームを作り、マイクロサービスの移行を進めるというやり方です。

将来的にはそれをさらにクロスファンクショナルチーム化し、モバイルエンジニアとバックエンドエンジニア、SREが一つのチームになって特定の機能を担当する形にしていきたいと思っています。同じようなチームが複数あり、全体のシステムをまかなうというわけです。

DMM / 10年で300事業の展開を目指し、アジリティの高い環境づくりを推進

合同会社DMM.com CTO 松本 勇気 氏(以下、松本):DMMでCTOや人事などを務めている松本です。

DMMのインフラについてほかの皆さんと違うのが、当社は事業数が40以上あるカオスな状態だということです。我々の手掛けるサービスは2017年頃から一気に数が増えたのですが、古いものだと20年ほど稼働しているシステムもあります。

内容としてはハードウェア製造からものづくりの拠点、プログラミングスクール、最近では水族館といったように実にさまざまです。全体のサービス規模を数字で表すと売上が2211億円、会員数は3196万人です。

こうした多岐にわたる事業をほとんどオンプレで捌いていたのですが、直近はどんどんクラウドに移行しようとしています。全て一気に移行するケースもありますが、サービスの状況に合わせながらときには分割して進めたりもしています。AWSを使う場合もあればGCPを使う場合もありますね。サービスごとに自社のプラットフォームとの関係の濃淡もあるため、状況に合わせて技術選択しています。

戦略に悩んだ場合の基準として捉えているのが「アジリティ」という言葉です。これは僕がCTOに就任して以来掲げている「DMM Tech Vision」の4つのバリューのうちの一つです。小林さんのお話にあったように、人件費やサーバー交換のコストを踏まえても確かにオンプレは若干安いのですが、それでも大切なのはアジリティだという考えで最適なものを選ぶと、現時点ではクラウドに分があります。特にアプリケーションサーバー群に関してはどんどんクラウドにリプレースする方針です。

実際に行なっている作業が、上記の図にある①~③の内容です。

①について…我々のサービスは一つのプロセスで複数の事業が動いていたので、まずオンプレ内で環境を分離しました。それらを順次クラウドにリフトして、その後クラウドに合わせた改善しています。いわゆるAWSが提案しているLift-and-Shiftです。

②について…プラットフォームと呼ばれる各事業で利用している共通機能を、マイクロサービスとして切り出す作業です。特に認証や決済といった重要な機能のみを共通機能として分離して疎結合にし、各事業がAPIを探す形で連携する戦略です。

③について…最後がモノリスの解体ですね。AWS CloudFrontやALBなどを上手く活用しながら新しいシステム群をルーターで受け、少しずつモノリスの部分を減らしていこうとしています。

今後はAWSやGCPのさまざまなマネージドサービスの恩恵を受けながらアジリティの高い環境を作り、10年の間に300事業くらい立ち上げられる会社にしていこうと話しています。

もちろんオンプレ環境がプラスになる領域もあるので、おおよそはクラウド化しながらも一部はオンプレを使いながら最適化を進めていく感じですね。

ミクシィ / コスト以外の諸要素を検討すると今後オンプレという選択肢は無い

株式会社ミクシィ 取締役CTO 村瀬 龍馬 氏(以下、村瀬):株式会社ミクシィ取締役CTOの村瀬です。

当社は現在「コミュニケーション」を軸として、スポーツ事業、デジタルエンターテイメント事業、ライフスタイル事業の3つの領域でサービス展開しています。どの事業においても、目指すのは家族や身近な友人を幸せにするコミュニケーションの活発化です。

みなさんのお話をお伺いしていると、パネルディスカッションで意見がぶつかることはなさそうだなという印象ですね。当社も現在基本的にクラウドに寄せています。コストというよりも、先ほど松本さんがおっしゃったアジリティが大切だという考え方も含め、エンジニアリソースや事業の独立性、依存関係、さらには撤退などの諸要素が持つ目的に沿っていこうとすると、結果としてクラウドに寄せていくことになるのだと思っています。

ですから、ミクシィも基本的には今後オンプレという選択肢は選びません。一部オンプレ環境も存在しますが、これは適材適所ですね。動画の配信でAWSのElemental Applianceを入れていたりします。

さらに詳しい技術スタックについては、ミクシィのオウンドメディア「ミクシル」で紹介していますので、ご覧いただければと思います。

質疑応答


※当日は、視聴者からリアルタイムで様々な質問が寄せられました。

大規模なインフラ戦略は事業・採用計画を考慮しながら進行する

小林:各社のインフラの現状が見えてきたところで、YouTubeコメントからいただいた質問に答えていきたいと思います。

質問者:クラウド移行、マイクロサービス化など+組織を検討する際、CTOとしてビジネス的な計画(事業計画、採用計画)も同時にやっていますか?


小林:DeNAとして簡単に答えるとイエスですね。

DeNAの場合、オンプレからクラウドにリフトする際にインフラコストがオンプレとクラウド両方でかかってしまうんですよね。これは事業計画にも大きなインパクトがあります。そのため、想定外のコストが発生しないよう、どんなタイムラインでどういう風にリフトを進めていくのか、きちんと経営レベルで中長期的な計画に落とし込んでいます。 クラウド化によって事業が拡大すれば当然人員が必要になりますから、必要に応じて採用計画も立てます。ただし、クラウド化のためだけに採用するケースは少ないですね。

田中:うちの場合は、エンジニアリング組織として主体性を持って事業計画の作成をリードすることはやっていません。プロダクトサイドやビジネスサイドが事業計画を立て、そこに合わせたエンジニアの採用計画を考えています。

マイクロサービス移行はエンジニア発のプロジェクトですから、必要な人員の採用計画はエンジニア主体で作りました。

松本:僕自身はマイクロサービスやインフラ戦略のための採用計画及び事業計画には関わる動きが多いですね。経営管理室長という肩書きも持っているので事業計画をモニターしているのですが、その中で「CxOが決めた事業戦略をどう達成できるか」という点を考えています。「ここの領域にだけはマイクロサービス化が必要だ」ということが見えてきたら、必要な兵站を整えるために採用などをする感じです。

村瀬:僕は田中さんに近いと思います。事業計画自体は各事業の担当者が立て、僕は経営会議で予算や事業をどう成長させるのかといった内容を見て、実現可能性や採用計画に関する意見を出します。採用しやすいアーキテクチャなどもありますからね。

会社的に注力する事業の場合は、一人目のリードエンジニアをどう採用するか、どんなアーキテクチャを組んでメンテナンスの手間を減らすのかといった計画を考える役割を持つこともあります。

先行き不明なプロダクトに対してオンプレを採用するメリットはほぼゼロ

質問者:パブリッククラウドが充実している現在でもオンプレを選択するケースはありますか?特に新規で立ち上げる場合についてお伺いしたいです。


小林:DeNAの場合は新規立ち上げでオンプレを選択することは今後無いです。というのも、現在はこれまで持っていたデータセンターを全て解約していっている状況なので、オンプレを選ぶと立ち上げコストがかなりかかってしまうんです。メルカリさんはいかがですか?

田中:小林さんとほとんど同じ回答です。今の時代、新規でオンプレを採用するのはあまり現実的な選択肢ではありません。仮にオンプレで何か作業をするとしたら、巨大なシステムのスケールメリットを生かしてコストを圧縮する場合や、特殊なハードウェアを使う場合などでしょうか。

一般的なサービスなら、基本的にスケールメリットよりもコストメリットが上回ると思います。

松本:事業を立ち上げる瞬間から「当たる」とわかっているのならオンプレを選択する可能性もあるかもしれませんが、何が当たるかなんてわかりませんよね。先行き不明な状態の中で一番大事なのは、素早く回収ができること、失敗しても捨てられるということですから、新規事業でいきなりオンプレスタートという選択肢は無いと思います。

すでに大きく成長した事業で、明らかにシステム運用の安定化や高速化、コストダウンが見込めるなら、オンプレミス回帰という意思決定もできるでしょう。Dropboxが例ですね。

逆に言えばそこまで安定してからでなければ選べない選択肢ということだと思うので、僕自身はオンプレ回帰には懐疑的です。

村瀬:もう僕から特に言うことは無いのですが(笑)、確かに今は当たるかどうかわからないものに対してわざわざハードウェアを買わなくてもいい時代ですよね。そういう流れに乗るのが一番選択肢としては正しいと思います。

ただ、オンプレでしかできないことも確かにあり、うちも動画配信部分はオンプレです。逆に言えばそこくらいかもしれません。

経営とエンジニアが同じ方向を向くために求められるCTOの立ち回り

質問者:インフラの開発・運用に取り組む際にエンジニア視点と経営者視点でそれぞれ考えていることはありますか?


松本:コンウェイの法則ではありませんが、組織設計とプロダクト設計は沿わせていこうとしていますね。僕が言っているだけかもしれませんが(笑)。

前職ではそこに採用目線も入れていました。例えばサーバーレスが流行りはじめた頃にバリバリのサーバーレスアーキテクチャのサービスを発表したところ、多くの方が採用に応募してくれました。そういう色目を使ったアーキテクチャを考えることもあります。

田中:どうやったら経営とエンジニアが同じ方向を向けるのかは意識していますね。エンジニアはやはり新しい技術を使いたいとか、リスクを減らして安全なオペレーションをしたいと考えます。経営側はコストや採用について考えるので、それらを一貫した形に整えて同じ目線になれるようにすることが大事だと思います。

村瀬:人材や事業のスケールについて考えだすと結局は俯瞰で見なければならなくなりますよね。人を採用して急激にスケールしなければならなくなったときに、最善なアーキテクチャや言語は何なのかということをよく話すのですが、これは経営視点とも現場視点とも言えると思います。

インフラコストに対する考え方

コストカットはファクトベースで判断するのがポイント

小林:ではパネルディスカッションに入っていきたいと思います。

まずはインフラコストに対する考え方というざっくりしたテーマなので、各社いろいろな意見が出るかと思います。DeNAの場合は経営的にコストをしっかり管理しているので、それこそ予算を作るときの試算はもちろん、月次のトラッキングもかなりチェックしています。

今もまだまだ削減の余地があるので工夫して取り組んでいますね。最近は費用は少し高くなりますが、付加価値のついたマネージドサービスの利用を増やすなどいろいろなチャレンジをしているところです。

田中:基本的には年間ベースで予算を立てています。月次のトラッキングも行なっていて、例えばGCPならプロジェクト単位でかかっているコストをブレイクダウンして確認し、増減に対してきちんと説明ができるかどうかを定性的にチェックしています。

並行してクラウドのリソースの利用度合いも見ていますね。例えばメモリーが余りすぎていないか、CPUの使用率が高くないのに確保しすぎていないかといった項目をピックアップして削減します。最近はログの保存にコストがかかっていたので、ログを溜めすぎていないか、不要なログを出していないかなどを見て効率化を検討しています。

月次単位でそれぞれのコストを見て、感覚とのズレが無いかを確認するのが大事ですね。

松本:うちも今はコストに関して予算上限はここまでという弾き方はしておらず、かかっているコストが合理的かどうかという基準で議論しています。例えばオンプレを使うにしても、AWSのインスタンスと単位を揃えたらいくらになるのかとか、配信コストをギガバイト単位にしたらクラウドと比べていくらになるのかといったように、比較可能な形にして合理的にコストを抑えようとしています。

ほかにも、例えば大きなサービスを撤退するタイミングで残った未使用中のライセンスなど、積もり積もった不要なものをPLを見ながら削っていく作業もしています。場合によってはそれだけで数千万円削れたりするので、嗅覚を働かせてチェックしていますね。

村瀬:うちも大体一緒ですね。合理的かどうかはもちろんですし、ファクトベースで会話して感情は分離しながら次の手を打つことが重要だと思っています。

クラウド事業者のエンタープライズサポートなどに入っていればコストは全部見せてくれますから、山のようにある各事業でどこにどんなコストがかかっているのかを洗い出し、数字をもとに例えばRIをまとめて買ったほうがいいのかどうかといった議論するのが大切です。

クラウドを選ぶ際に学習コストの高さは気にしない

小林:YouTubeに来ている質問も拾いたいと思います。「システムによってはマルチクラウドでインフラコストが安くなりますが、学習コストはどう見られますか?」という点について、そもそも一つのサービスをマルチクラウドでやっている企業はありますか?DeNAは微妙にあるという感じなのですが、メルカリさんはGCP一択ですよね。

田中:画像の置き場所としてAWSのS3を使っていたりします。ただ、これは積極的にマルチクラウドにしたのではなく、GCPを採用する以前から使っていたS3が残っているというケースです。

マルチクラウドはマイクロサービス移行が一通り済んで落ち着いてから次のステップとしては考えるかもしれませんが、まだ先の話ですね。

小林:松本さんのところはいかがでしょうか。

松本:一つのシステムに対してマルチクラウドにしているケースはありませんが、マイクロサービスの置き場所がバラバラになっていることはありますね。何かメリットを求めてやっているわけではありませんし、実際にコスト面の優位性もありません。今後もコストを意識してマルチクラウドを選定することは無いと思います。

村瀬:うちもあえてマルチクラウドを選定することはありませんが、歴史的経緯でモンスターストライクはオンプレにDBとキャッシュがあります。クラウドでスケールするからといってAPIサーバーをどんどん立てると、レイテンシの問題があるんですよね。ですからIBMやGCP、AWSなどで片っ端からレイテンシを測り、短いところからコア数分を取っていくということをしていました。在庫切れしてしまったらまた別のクラウドを使っていましたね。

これが良いか悪いかで言うとちょっと変態的な感じがするので(笑)、いずれは一つのクラウドにすると思います。

小林:DeNAの場合はデータウェアハウスでBigQueryを使い、アプリケーションでAWSを使うということがよくありますね。プロダクトの特性を最大限に活かすという観点で自然にクラウドが分かれていくケースです。経営レベルでマルチクラウドやシングルクラウドを強制することはありません。

学習コストという面ではみなさんいかがでしょうか?

田中:何をやるにしても学習コストは必要ですし、システムはどんどん進化させていかないと中長期的に効率を上げられません。ですから特定のクラウドの学習コストを気にして、利用するかどうか決めることはありませんね。ただ、流行りのものに飛びつかないようにはしています。

松本:エンジニアの「遊び場」を作るコストは結構かかると思っています。当社は全エンジニアに対してAWS、GCP、Azureで使える費用を1万円ずつ用意していて、学びのための遊び場を提供しています。実際には予算の30%程度しか使われてはいませんが、学びたい人は独立した自分のアカウントでクラウドの特性を試せるようにしているんです。

また、社内勉強会を通じて知見を横に広げていったり、AWSさんに依頼して、有償で4日間の研修を実施してもらったりもしています。

村瀬:学ぶ場の用意は重要ですよね。一方で僕自身はクラウドの学習コストがそこまで高いとは思っていません。それよりも難しいことは事業を作る上で非常に多いので、まずは手を動かして試行錯誤しながら進めてもらうことですね。きちんと有識者に教えてもらいながら作っていけるようなフォローもしています。

オンプレ、AWS、GCP、他パブリッククラウドの選定方法

エンジニアに技術選定を任せる企業が求めるのは「合理的な理由」

小林:オンプレ、AWS、GCP、他パブリッククラウドの選定方法についても各社の状況からお話しいただければと思います。

DeNAは、技術選定に関して会社から特別な指示は出していません。現場の方がプロダクトを作っていく上でベストだと思う技術スタックを選ぶ感じですね。もちろん全く未知のクラウドに対しては導入の必要性について相談してもらいますが、基本的には自由です。

現状はその自由さによりプロダクトの独自性が高くなり、なかなか知見を共有できていないのが課題です。

田中:メルカリはクラウドについては基本的にGCPを使うよう会社としてお願いしています。もともとGCPを選定したのは、クラウドサービス移行を進めるにあたってKubernetesをフルに使っていきたいという考えがあったからです。Googleが作っているので、GCPは一番サポートが充実していました。

セキュリティ監査のための仕組みやアカウントとパーミッションの考え方も基本的にGCPのスキーム上で構築しているので、AWSなどほかのクラウドを使うとなるとセキュリティの仕組みから作る必要があります。なので、厳密にはGCP以外に手を出せるほど仕組みが整っていない状態ですね。

松本:うちはDeNAさんと近い状況で、みんなが好きな技術を選定して好きなアーキテクチャを作っています。僕が入社する前はもっとカオスだったと思いますよ。現在も会社がレギュレーションを決めたりはしていませんが、チェックする中で気になるアーキテクチャがあれば合理性を確認しています。

僕自身はできればメルカリさんのように技術を縛って一定の規律の下でやりたい派ではあるのですが、これは事業や会社の在り方に関わりますからね。DMMとして一つの技術にこだわるということは考えていません。

村瀬:うちも縛りは入れておらずびっくりするほど自由なのですが、それなりに周りに合わせて選んでいるという感じです。

人材の活かし方についての考え方

元オンプレエンジニアはクラウド環境でも活躍できる

小林:次のテーマに移ります。今回はインフラやクラウドがテーマなので、特にインフラ周りの人材の活かし方の話もできればと思います。

DeNAはもともとオンプレを運用するための組織としてチームが作られていたので、オンプレに対する知見や技術、スキルはかなり蓄積された状態でした。ネットワークエンジニアもオンプレ環境におけるネットワーク構築をかなりバリバリやっていましたね。

クラウド移行する際に、そういうメンバーがどのようにスキルセットを活用できるのかは一つの課題なのですが、やはり変化することは大事ですから、当社は全力で活かす方向で進んでみました。その結果、もともと使っていたパブリッククラウドのコストが半分になりました。オンプレで頑張っていた人のパワーは、クラウドでも十分発揮できると証明できたわけです。 ネットワークエンジニアも同様で、クラウドでネットワーク構成を考える際に過去の知見が非常に活きています。ベンダーさんとも良いやりとりができていますね。

田中:メルカリもDeNAさんと同じで、ある程度一つの技術を深めた人なら、ほかの技術にも大体対応できると考えています。エンジニアである以上は、新しい技術をキャッチアップするのが当然ですしね。

インフラに限らず、アプリケーションエンジニアに関しても昔のPHP+MySQLの環境から、マイクロサービスの環境できちんとアプリケーションを作れるようになってもらわないといけません。フロントエンドやiOS、Androidも同様です。技術の変遷についていくべきという考えがベースにあります。

最近重要視しているのは、むしろマインドセットですね。特定の技術に拘泥するのではなく、できるだけ視野を広く持っていろいろな技術に手を出してもらいたいです。会社としても、インフラをやっている人がアプリケーションを、モバイルをやっている人がアプリケーションやフロントエンドを触るなど、異なるスキルに興味を持ってもらえるような取り組みを促進しようとしています。

松本:人材の活かし方というものは、メンバーから見た会社の活かし方の両面から見てプラスになるようにするべきだと思っています。

その上で、「技術に拘泥しない」という話はその通りですね。どういった方向に進むのかは各人の自由なのですが、会社として進む方向はきちんと伝えて、勉強するための材料やチャンスを丁寧に作っていこうとしています。AWSさんなどにお願いする研修や、各社で開催されているイベントに足を運んでもらい、得た知見を部内に広げてもらうというのもその一環です。

村瀬:僕も会社が進んでいる方向などは社内勉強会やエンジニアの横軸のミーティングを通して伝えていますね。その上でマネージャーによる1on1でメンバー一人ひとりがどういう方向に進むべきかを擦り合わせ、技術の習得などに動いてもらおうと考えています。

その人が進みたい方向があるなら、どの事業で何ができるかを本部長らと相談して異動や交換を決めるなど、人の流動性を高める取り組みも推進しています。

インフラエンジニアも目標達成度や事業貢献度で評価するのが基本

小林:インフラエンジニアの評価に関する質問も来ていたので軽く触れたいのですが、「守り」の役割は成功していて当たり前、失敗するとマイナス評価というイメージが強いと思います。各社はそのあたりどういう風に評価をしているのでしょうか。

DeNAの場合はチームで仕事をしていて発生する障害に関して個人が責められるようなことは基本的にありませんし、ネガティブな評価もつきません。

今はオンプレをクラウドに移行する準備が大変なので、新しい技術を使ったりしながら丁寧にやりきることに対してプラスの評価をしていきたいと思っています。メルカリさんはいかがですか?

田中:評価の前段としてどういう目標を設定するのかが重要だと思っています。うちの場合は例えば「このクォーターはこの辺りのプロセスを改善しよう」とか、「このシステムに手を入れよう」といった計画を立てるので、その目標設定をどれくらい達成できたのかという形で評価することが多いですね。ですから障害が起きたとしても基本的にマイナス評価はしません。

松本:僕もここは各社あまりズレない部分かなと思います。一つのミスで評価を下げることは特にしていません。インフラだからと言って評価制度をほかのチームと特別変えているわけでもありませんね。基本的にはチームとしての目標を置いていて、それに対する評価をしています。

今の時期であればオンプレからクラウドに移行するにあたっての大きめのアーキテクチャの変更やデータセンターのシュリンクなどいろいろな作業がありますから、そういう攻めの施策をどれだけ円滑に進めたか、プラスになるように走ってくれたかもきちんと評価していこうとしています。

また、インフラに限らずマネジメント教育で「みんなの貢献を拾う」という基本の部分をもっと伝えていかなければいけないと思っているところです。

村瀬:素敵ですね。うちは社長も含めてサーバーエンジニアやインフラエンジニアをよく見てくれる文化があり、よくモンスターストライクのサーバーエンジニアが社内表彰されたりしています。

やはりマネージャーがしっかりメンバーを見て、どういう行動、どういうテクノロジーで問題を解決したのか、アウトプットの生産性は高かったのか低かったのかなどを判断すべきですね。あとはグループ自体をどう変えていったのかも大切です。

技術、アウトプット、グループ、プロダクトの4軸でどう貢献してくれたのかがわかれば、そんなに評価はブレないのかなと思います。

<CTO meetupご登壇者プロフィール>

●株式会社ディー・エヌ・エー 常務執行役員 兼 CTO 小林 篤 氏
法学部法律学科からエンジニアへ転身し、2011年にDeNAに入社。Mobageおよび協業プラットフォームの大規模システム開発、オートモーティブ事業本部の開発責任者を歴任。2018年より執行役員としてDeNAのエンジニアリングの統括を務め、2019年より常務執行役員 CTOとしてより経営レベルでの意思決定にかかわることと、技術・モノづくりの強化を担う。

●株式会社メルカリ 執行役員 VP of Backend 田中 慎司 氏
株式会社メルカリ 執行役員 VP of Backend、情報学博士。 NTT研究所研究員、株式会社はてなCTOを経て、2016年より執行役員としてメルカリに参画。ロンドンに赴任し現地開発チームを立ち上げる。2018年9月に帰国し、現在はメルカリのMicroservices化を旗振りしている。

●合同会社DMM.com CTO 松本 勇気 氏
2018年10月11日より合同会社 DMM.com CTO(最高技術責任者)に就任。 2018年8月まで株式会社Gunosyにて執行役員 CTOおよび新規事業開発室室長。 Gunosy創業直後に入社。 これまでニュース配信サービス「グノシー」「ニュースパス」などの立ち上げから規模拡大、また広告配信における機械学習アルゴリズムやアーキテクチャ設計を担当し、幅広い領域の開発を手がける。 新規事業開発室担当として、ブロックチェーンやVR/ARといった各種技術の調査・開発を行う。2019年5月よりEXNOA(DMM GAMES) CTOを兼任。

●株式会社ミクシィ 取締役CTO 村瀬 龍馬 氏
2005年に株式会社イー・マーキュリー(現:株式会社ミクシィ)に入社。SNS「mixi」の開発に携わる。2009年に退職後、ゲーム会社などを経て、2013年に再度ミクシィに入社。 主にモンスターストライクの開発業務に従事。2016年7月、XFLAGスタジオ ゲーム開発室長に就任し、XFLAGのエンジニア全体を統括。 2018年4月、執行役員CTO就任。2019年6月、取締役就任。2020年4月より取締役CTO。(現任)

この記事を書いた人
FLEXY編集部
FLEXY編集部
ハイスキルIT人材への案件紹介サービス
FLEXYメディアは、テックメディアとしてテクノロジーの推進に役立つコンテンツを提供しています。FLEXYメディアを運営するのは、ITに関連するプロシェアリングサービスを提供するFLEXY。経営課題をITで解決するためのCTOや技術顧問のご紹介、ハイスペックエンジニアやクリエイターと企業をマッチングしています。【FLEXYのサービス詳細】求人を募集している法人様向け/お仕事をしたいご登録希望の個人様向け

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

FLEXYでご案内できる業務委託案件

業務委託契約・開発案件(JavaScriptメイン)

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内/リモート含む
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

業務委託契約・インフラエンジニア

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週1日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

人材紹介のCTO案件(非公開求人)

テーマ CTO、技術顧問案件はFLEXYに登録後、案件をコンサルタントからご紹介します
勤務日数 業務委託から人材紹介への移行
報酬 年収800万以上
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ FLEXY登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週2-3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)