FLEXY主催CTOmeetup、インフラ戦略の最前線のイベントレポート後編記事です。登壇するのはDeNA、メルカリ、DMM、ミクシィの計4社のCTO及びVP of Backendのみなさん。

＊前編はこちらをご覧ください。

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

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

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

株式会社ディー・エヌ・エー 常務執行役員 兼 CTO 小林 篤 氏（以下、小林）：ではパネルディスカッションに入っていきたいと思います。

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

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

株式会社メルカリ 執行役員 VP of Backend 田中 慎司 氏（以下、田中）：基本的には年間ベースで予算を立てています。月次のトラッキングも行なっていて、例えばGCPならプロジェクト単位でかかっているコストをブレイクダウンして確認し、増減に対してきちんと説明ができるかどうかを定性的にチェックしています。

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

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

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

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

株式会社ミクシィ 取締役CTO 村瀬 龍馬 氏（以下、村瀬）：うちも大体一緒ですね。合理的かどうかはもちろんですし、ファクトベースで会話して感情は分離しながら次の手を打つことが重要だと思っています。

クラウド事業者のエンタープライズサポートなどに入っていればコストは全部見せてくれますから、山のようにある各事業でどこにどんなコストがかかっているのかを洗い出し、数字をもとに例えば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としてより経営レベルでの意思決定にかかわることと、技術・モノづくりの強化を担う。