リクルートグループのキャッチコピー
高岡将氏（以下、高岡）：どうも、こんばんは。高岡と申します。
みなさんからすると、「リクルートグループは何をしているのか？」がわかりづらい部分もあると思いますし、その中でさらに「リクルートテクノロジーズのインフラエンジニアがそもそも何をしているのか？」という疑問があると思います。今日のイベントは「リクルートがやっていること、どんなエンジニアがいるのか、現在困っていること」についてざっくばらんに話すことを目的としています。あまり何回もできるようなイベントではありません。
ということで、今日は「リクルートのネットサービスインフラを支えるエンジニア環境」というテーマで、お話しできればと思っています。内容がぎっしり詰まっていますので、期待して聞いていただけると嬉しいです。
まず、今日のアジェンダについてお伝えします。
はじめに「リクルートの果たすべき役割とは？」というところをお話しして、合間にCMもはさみながら、私自身の自己紹介とかインフラエンジニアとしてのキャリアパスについてお話しします。
途中で「実際の環境はどのようになっているのか」という部分を現場のエンジニアに話してもらいながら、どういう人材ニーズがあるかについてお話ししようと思っています。
ということで、最初にCMから入るんですけれども。
（リクルートホールディングスの「The Ribbon Model」の紹介動画が流れる）
リクルートホールディングスでは「まだ、ここにない、出会い。」というメッセージを出していて、それを「The Ribbon Model」と呼んでいます。これについてはまた後程、お話しできればと思います。
次もいきなりCMですね。
（「SUUMO」の紹介動画が流れる）
「SUUMO」。みなさんご存知かと思うんですけれども、これもリクルートのサービスの1つです。リクルート住まいカンパニーという事業会社のビジネスになっております。
「まだ、ここにない、出会い。」と出ているかと思うんですが、これからみなさんリクルートのCMを見るたびに思い出していただければと思っています。
誰と誰を結んでいるかというと、例えば賃貸領域の場合、「部屋の空きがあるから入ってもらいたい」という大家さんのニーズと、「新しい部屋を探したい」という利用者のニーズがあり、この2つをきちんと結んであげるようなサービス。その結び方として、紙の媒体やネットで事業を行っています。
リクルートの生い立ちに関しては、創立が1960年と、だいぶ昔からあります。
グループ企業の社員数は、若干古い数字ではありますが、2015年の3月までに3万人を超える社員が働いています。当然、パートナーの方やSIerの方もたくさんいて、そちらも含めるともう何万人いるかよくわからないというような感じです。
オフィスはグラントウキョウサウスタワーを拠点としており、周りのビルにもかなりリクルートのグループ会社が入っていて、打ち合わせが隣のビルといったことはざらにあります。
会社もM&Aや分社化を進めておりまして、かなり（会社が）たくさんあるというイメージを持っていただければと思っています。
続いて、ビジネスモデルをご説明します。リクルートグループでは、「カスタマー」を一般ユーザ様に見立てています。「クライアント」というのはサービスを提供するような会社様であり、双方をマッチングさせるところを主軸において、リクルートのサービスは展開されていると思っていただければと思います。
それで、CMにも出てくるような、「まだ、ここにない、出会い。」というイメージにつながります。
これは、リボンのビジネスモデルですね。ユーザのほうは「こういう結婚式をしたい」という想いがあり、サービス提供側である結婚式場のほうは「こういう融通が利く」ということであれば、我々としては『ゼクシィ』という媒体を使って二つを結びつけます。
また、ユーザの「こういうヘアスタイルにしたい」というニーズ、それからサービス提供側である美容院さん側の「私たちはこういうことができます」「カリスマがいます」というところを私たちが真ん中で結んでいる。ほとんどこういったビジネスモデルとなっています。
これを「リボンモデル」と呼んでいるんですけれども、詳細はYouTube上にあり、最初に見ていただいた動画のもとになります。
（『ゼクシィ』のサービス紹介動画が流れる）
これもリクルートマーケティングパートナーズが展開している事業の1つになっています。リクルートマーケティングパートナーズは、ほかに『カーセンサー』などもやっているところです。
リクルートテクノロジーズではなにをしている？
リクルートグループでは多くの事業を運営しています。もしかしたらみなさん1個ぐらい知っているサービスもあるかもしれませんが、ほとんどのインフラの部分を我々が担当しています。
何度も出てきて申しわけないんですけれども、どの事業においても「まだ、ここにない、出会い。」というマッチングをかけていく。そういうことを様々な事業領域に仕掛けていくことができる。それがリクルートの強みです。
さらにいうと、こういうネットサービスを作った上で、営業が一気に営業かけられるというところが、ほかのネット系の企業にない1つの強みなんじゃないかと思っています。
続いて、リクルートホールディングス全体のお話です。上側の青文字のところが事業会社と言われるところで、下側の赤文字の方が機能会社というふうに分けています。
事業会社は、今CM見ていただいたような、いろいろなメディアやサービスを持っている会社。機能会社は、1つは今日お話ししている我々リクルートテクノロジーズだけでなく、アドミニストレーションやコミュニケーションズというところがあります。
事業会社の「やりたいことを叶える」ための支援をしたり、課題を技術的に解決したりする領域を機能会社で分担しています。
我々リクルートテクノロジーズ内にも多様なミッションがございまして。これは少し手前味噌なのですけれども、「IT・ネットマーケティングの領域で専門的な部隊」であるということと「ITでリクルートのビジネスを牽引する企業」というのが、我々リクルートテクノロジーズのミッションになっています。
リクルートテクノロジーズ内が見ているネットインフラは、数多く存在します。
インフラの組織は、大きく分けて3つあります。
1つはみなさんの会社にもあるかもしれませんが、「情シス」と言われる部署ですね。パソコンを配ったり、標準化などを行ったりする部署。その部署も、グループ全体の社員が3万人を超えていますので、けっこう大きい部隊です。
また、「Ponta」などポイント系のシステムはぜんぜん違う隔離されたインフラを持っており、超高セキュアなインフラ環境を持っています。そこも一番上の情シス系のインフラ部隊が見ています。
2つ目としては、ビッグデータと言われるインフラ基盤を持っている部隊があります。これは完全にクラウドで全部完結するようなところで、例えばGoogleのBigQueryを社内で使用できるAPIを作成している部隊です。
3つ目、ネットインフラ。だいたい僕が説明するときは「その他全部が僕らの部署です」というようなイメージで話をしますが、「その他」の定義がちょっと難しくて。有名なサイトから小さいサイトまで網羅しています。今日みなさんATND（アテンド）などを見てイベントに参加して頂いたかと思いますが、こういったサービスも全部我々の見ているインフラに入っているイメージです。
当然、この「ネットインフラ」のなかに、実際のスイッチとかルーターとか、サーバ自体を見守ったり、ケーブリングしたりするような部署があります。
ほかに、インフラDevOpsやSRのようなところであったり、共通のネットインフラをクラウドで使ってもらったりするための部署があり、このネットインフラのなかでもかなりの部署があるというイメージです。
インフラエンジニアの業務範囲
（スライドを指して）社内での定義というか、これはインフラエンジニア業界の「インフラエンジニアとは何か？」という話に近いところがあるんですが。
最近よく言われるインフラエンジニアというのは、上側から下側に向かっている矢印なんですけれども、OSI参照モデルみたいなものでいうと、アプリケーション、L7から見たインフラエンジニアというのを指すことが多いです。
それに対して、ファシリティとか電源とかケーブルとか、そのあたりから気にしなくてはいけないものは、ファシリティ・リソース観点から見たインフラエンジニアと言われているのではないかと思います。
どちらもインフラエンジニアと言われるので、クラウドしかわからないインフラエンジニアがいたり、サーバの複雑なドライバーとかCPUに非常に詳しいような人もいたりするなど、様々です。
真ん中から右側にかけては、簡単な説明となりますが、どこのレイヤーでも監視やモニタリング、ソースの自動化は、インフラエンジニアとして統一してやるべきことであると思います。
例えば、1サイトしか担当していないインフラエンジニアというのは、「コスト」から下ですね。リソース、ユーザに関しては1ユーザしか管理しないし、1つのサイトのコストしか管理しないんじゃないのかなと。これでも一応インフラエンジニアですよね。
一方クラウドまわりですと、先ほどリクルートには数百のサイトがあると言いましたが、この数百のサイトに対してアカウントを発行したり、「悪いことしてませんよね」と監視したり、コストをメーカーさんと交渉することも、全部インフラエンジニアの担当領域となっています。
さらに、オンプレミスですね。プライベートクラウド環境みたいなところだと、データセンターであったり、「最近電源を使いすぎですよ」「落ちました」というようなところも含めて、全部インフラエンジニアというくくりで見なくてはいけません。
インフラエンジニアといっても、どのあたりが得意なのかという、向き不向きというのがあるんじゃないかと思います。
（スライドを指して）これはインフラエンジニアの仕事の泥臭い面だけを取ってきています。
まず最初に、左側を見てください。インフラエンジニアとして関係するのは何かといいますと、事業会社に対して我々の利用料や使ったリソースに対して社内取引みたいなことをしていかないといけないというところです。あと、予算を確保してもらったり付け替えたりするというのも、インフラエンジニア側でやらないといけません。
次に真ん中ですね。ネットインフラの部署のなかでは、事業側とアーキテクチャの相談があったり、そこから個別にインプリメントしたり、監修する必要があります。
さらに、事業側が新しいものを使いたいという要望を持っていたり、勝手に使い出していたりすることもあるので、そのあたりも相談を受けていく必要があります。
そして、一番右側ですね。本当に面倒くさいと思うこともあるのですが、数百のサイト、数百のユーザに対して、踏み台サーバとか、SSHを開けてあげるとか、操作ログを取ってあげるというところも共通で全部見ていかなくてはいけません。申請などがあったら、その都度対応してあげないといけないということもあります。
それから、このあたりはおもしろいという人もいるかもしれないんですけど、リクルートですと、やはりどこの会社から見ても大口顧客として見ていただけるところが多いので、そうしたメーカーさんなどに対して、契約をする役割もあります。
とくに、どんどん技術の変化が早くなり、「まったくもって追いつけていけません」というようなところに対して、アプリケーション側、特にリクルートの場合は事業の現場で新しい技術を先走って導入してしまうケースもあります。
「作るだけ作って保守できなくなってしまいました、あとはテクノロジーズさんよろしく」なんて言われると、かなりつらい目に遭う場合もあるので、やはり新しい技術というのはどうにかしてキャッチアップするという部分についても、すべてインフラエンジニアでやらないといけません。
その点について、我々ネットインフラチームとしては、「プライベートクラウド」と「パブリッククラウド」というアプローチを、リクルートグループとして安全に使ってもらうためにどうしたらいいかということを、ひたすら考えています。
成果を出し続ければいつか年収は跳ね上がる
ここで、CMをもう1つ。
（リクナビNEXTのCM動画が流れる）
今日は、僕が疲れたタイミングで、リクルートのCMを挟むようなテイストにしていこうかなと思っています（笑）。
これ（リクナビNEXT）は入れるかどうか迷いましたが、リクルートといえばこのイメージが大きいのではないかと思い、入れています。
リクナビNEXTも、一応我々のネットインフラに置いています。みなさんもしかしたら登録されている方がいらっしゃるかもしれないんですが、年収などのデータなど、本当に危ないデータが多く入っています。これは我々がお漏らししたら大変なことになるという部分も、大規模インフラの1つとして扱っています。
ということで、遅れましたが、自己紹介です。私、高岡将と申します。「いまさらか」という感じなんですけど、本当にどうもすみません。92年に社会人スタートしてるので、もう完全にいいおっさんだというのはわかっていただけるかと思います。
左上の写真が新人の時のものです。このころは、後ろは大きいオープンリールの汎用機と、あと外部記憶装置、テープ装置みたいなものがあり、「よくこの時代にデータセンターで写真を撮れたな」という感じではありました。
唯一の友達が、うちで飼っている小鳥さんということで、小鳥を出しています。
また、少し転職の回数が多いといえば多いんですけれども、いままでいろいろやってきました。
はじめの10年ぐらいは金融系の会社にいて、汎用機でずっとアセンブラをやっていたところから、「時代はオブジェクト指向」みたいなときにJavaの1.0を触り始めて、そこから「オープン系っておもしろいんだな」ということで、いろいろな会社で経験を積んでいます。「ベンチャーって伸びたら一攫千金なんじゃないか」というところで何社か渡り歩いたんですけれども、まったくご利益が出ず、40歳近くになってから外資系に転職し、今に至ります。
年収に関しては、やはりはじめのうちはだいぶつらいんですよ。ただし、ちゃんとした規模の会社でちゃんとした成果を出していれば、いつかけっこう跳ね上がるというところがありますので、みなさんインフラエンジニアとして安心して人生設計してもらえればと思って描きました。
高岡氏独自のマネジメント論
（スライドを指して）こちらは「自分視点でインフラエンジニアについて語ると」というテーマのスライドです。
自分の組織論やマネジメント論が「ほかの人と違う」と言われることが多いので、入れています。
僕は一応クラウドチームと、リクルートライフスタイルのオンプレミスのチームを全部まとめています。メンバーの人数でいうと50～60人くらいですね。
僕のスタイルとしては、業務の進捗などは自分から聞きにいくことはなく、会議などになるとメンバーの方から相談にくるというかたちになっています。こういったやり方を周りに話すと「そんな方法はとらない」と言われたりします。
だいたい、そういうマイクロマネジメントとか、進捗取ったりするのは僕の仕事ではないと考えていて、やはり本質的に「今なにやってなくちゃいけないんだっけ？」というところを常に追求します。
新技術を使うことにばかり目がいってしまう人もいますが、「それを使うと事業の方々は何が嬉しいのか？」とか、「それを使って来年、再来年、この次の移行のときにどういう状態になっていればいいのか？」という本質を、できればコミュニケーションを取りながら整理して、きちんと選択できるという状態を作ることを意識して仕事をしています。
（スライドの）下のほうに細かく書いてあるんですけれども、だいたいリクルートの今までのスタイルからいくと、ミスを起こさないためにも、メンバーのみなさんはかっちりやりたがるというスタイルが強いです。
ただ、個人的には「間違ったら修正すればよい」という感じもしています。「挑戦しなくなってしまうぐらいであれば、1回は許すからやろうよ」というスタンスで仕事を進めています。
で、CMです。僕が疲れてきたということなんですけれども。
（「ホットペッパービューティ」の紹介動画が流れる）
このCMも見たことある方いらっしゃるかもしれませんが、ホットペッパービューティですね。リクルートライフスタイルという事業会社が展開しているサービスです。
冒頭でも出ましたけど、「髪を切りたい」というユーザさんには美容院の情報を届け、サービス提供側の美容師さんに対して、予約の管理などがモバイルでできるようなボードを我々が提供したり、クーポンみたいなものを簡単に発行できるようなシステムを提供したりというところで、利用者と事業者側が双方ハッピーになるようなイメージで作って運営を行っているサイトになっています。
実際のネットインフラ環境
ということで、「実際に我々のネットインフラはどのような環境か」というところを少しお話ししたいと思います。
このグラフですね。いろいろ迷いましたが、まずオンプレミスとクラウドの比率はどれくらいかというところです。
トラフィックやPVの比にすると、99：1の感じでほとんどオンプレミスになってしまったので、サイト数ベースで出してみました（笑）。
サイト数にすると、およそ半分強、3分の2ぐらいがオンプレミスで動いていて、残りはクラウドで動いています。オンプレミスが2色に分かれているのは、一番上の水色のところが超エンプラ系のようなイメージだと思ってください。
これも包み隠さず言っておいたほうがいいだろうと思うのですが、オンプレミスの方は、データベースのOracleを採用しています。OracleのReal Application Clustersというきちっとしたものを入れています。
このRAC環境がちゃんと動いていない場合、そもそもクラウド側にRACがないので、いきなり持っていくことができない。それに対するアプリケーション・サーバからはちゃんとJavaでアクセスするようなところまできっちりやっているところがあります。本当に大変なサイトは、お金をかけて、ミドルウェアとか保守とかも含めてお金をかけてやっています。
オレンジ色のオンプレミスのところは、「気軽に使いたい」という要望に対して、我々はたくさんサイトを運営していて、サーバ数もそこそこありますので、ボリュームの観点から1コア2コアであれば微々たるお金で払い出せるような環境があって、図のオレンジ色の数ぐらいになりました。
クラウド側の黄色いところは、このあとうちのメンバーにも話してもらうリクルートの標準的なクラウド環境です。青い部分はそれ以外の、いわゆる“野良”の環境です。現場で契約して使い始めたが、うまく機能していないという環境が、しかも我々がわかっているだけでこれくらいあるというイメージです。
どういう使い方をしているかということについてですが、まずオンプレミスですね。「ATND」がそうであるように、先ほどいったOracleなどのシステムが必要な部分や、AWSより本当に安くしたいところ、ボリュームが本当に1コア以下しかいらないという場合などに、VMwareを使って払い出しているところがあるんですけれども、そういったところをとりあえず大量に試したいということがオンプレミスを採用する理由となっています。
それともう1つ、先ほどお話しした「Ponta などのお金に絡むポイント系など、エンタープライズよりもセキュアな環境というのがもう1個オンプレミスとして動いています。
次に、クラウドの利用方法です。これは基本的にAWS環境を中心に行っていて、これからGoogleやAzureなどを検討していくところです。
実際に使っている内容は、中小サイトや検証環境、あとはキャンペーン用のサイトというかたちで、まだまだライトな使い方しかしていません。
ネットインフラの取り組みと課題
オンプレミス環境の仕様や設計、運用ポリシーについてまとめてみたものが、こちらの図になります。
やはりどこの会社さんにもある程度の基準が設けられているかと思います。リクルートの基準はかなり厳しいのではないかと思いますが、この基準をオンプレミス環境がとりあえず満たしているので、クラウドはどこまで満たせるのかというところを考えています。
そのため、払い出すまでにかなり時間がかかってしまい、サイト側の不満が溜まるということもあるんですけれども、こちらをこれからどんどん改善していかないと、技術革新のスピードや手軽さといったところがトレードオフになってしまうのではないかと感じています。
右側の課題に書いてあるんですけれども、オンプレミスというのは、はるか昔にルールで統一していたといわれています。エクセルにヒアリングシートのようなものを書いて、「これにのっていないとやりません」というような会話の仕方をしていたこともありました。
そうなってしまうと、自由度や俊敏性というものが損なわれていくのと同時に、エンジニアの不満がどんどん溜まってしまいます。このジレンマはいまだに続いています。
クラウドはここまでできないので、「じゃあどこまでやるのか？」とか、「できないところはどのようにしてクラウドとして解釈するのか」というところで、社内のセキュリティ基準と日々、戦っています。
本当に面倒くさくて大変なところなんですけれども、インフラエンジニアが中心になって、事業側からの要望やトレンドを省みて、これからのインフラというものをきちんと考えていくという動き方になっています。
逆に、（スライドの）下のほうに書いてありますが、リクルートというブランドがあって、こういった規模の会社が、例えばなにも施策をしていないで、いろいろなデータを流してしまいましたとなると、それはそれで大きなリスクになると思っています。
このなにもしなかったときのリスクと、がんじがらめにするときの不満やリスクのちょうど良い加減を常に見たり、調べたりと、情報収集をしながら仕事を行っています。
続いて、プライベートクラウド。プライベートクラウドというと若干語弊があるんですけれども、VMwareが基盤で払い出しているというオンプレミス環境になります。
これが今どのようになっているかについてお伝えすると、ことはさかのぼること2006年～2007年頃。当時はデータセンター4つに1,400台ぐらいのサーバを散りばめて運営していました。
ネットワーク機器とか、共通化できるようなところも全部4つ分、バラバラにしていました。無駄の発生、人件費の増加、インフラサービスの提供が追いつかない、とスライドには書いています。
リクルートのサービスが伸びてきたということも1つありますが、やはり当時、パソコンなどが一気に低価格になり、ガラケーからスマホに移り、スマホが高性能化してきました。その結果、同じサイトでも通信トラフィックがどんどん上がってきた時代だと思っています。
それを4つのデータセンターで同じようなトラフィックがたくさん来るということをわかりながら受け続けていて、これに限界を感じて、2009年にデータセンターを1つに統合しました。このタイミングで仮想化基盤というのを一気に入れて、プライベートクラウドが誕生しました。
効率化と自動化の弊害
当時2009年でかなり前のもので、しかもいまだにちゃんと動いてる基盤ではありますが、当時はかなり先進的なチャレンジをたくさん行っており、リソースをプール化して払い出すというような概念を入れていました。
払い出す部分に関しては、「極力自動化していきましょう」「自動化の考え方を入れていきましょう」ということで、工程をひたすら短縮化しました。下の図にあるように、決まったものに関してはすぐ払い出せるような環境を作ることができました。
疲れてきたのでCMを挟みます。
（「じゃらん」の紹介動画が流れる）
この「じゃらん」も、みなさんご存知かと思いますが、リクルートのサービスです。これもリクルートライフスタイルにて、オンプレミスで動いています。最近ですと、九州の復興割などで一気にトラフィックが集まってしまい、大変なことになっているサイトです。
「データセンターを統合して、自動化を入れました、ウェーイ！」と喜んでいましたが、もうすでに2016年が終わろうとしてるんですね。そこで、今どうなってるかについて赤裸々に書いてしまいました。
統一化した時に徹底的に効率化を求めすぎてしまい、とにかくやれることが属人化してしまいました。「すみません」という感じです。しかも、相当狭い範囲で専門化してしまいまして、隣の席やチームが、「人が少ないんだけど、対応してあげられない」という状況が今も若干あったりします。
そして2つ目ですね。自動化を意識しすぎたというところがあります。2006年の時代の自動化って、「Chef」とか「Puppet」とかそういう次元よりさらに前の状態ですので、エクセルに色々な情報を埋めて、それを謎のマクロで回して作って、いろいろなところに配布するということをやっていたんですけれども、もう完全に今カオスです。
誰が何にどういうふうに関わっているのかもよくわからなくなってきている上に、今、新たな自動化というものをかぶせようと、Ansible化というのも進めようとしていて。この新旧の境目がだんだん難しくなってきているのが今です。
当然、今世の中の自動化といえば、下から2行目にもありますが、DevOpsとかSREという考え方が入ってきていると思いますが、今のやり方でいきなりこれに移行できるかといったら、できません。
それだけにとどまらず、当時の自動化といえば、例えば「Red Hatの6専用」のようになってしまいましたので、当然なんですけれども、「6まではがんばれるけど、7だとぜんぜん意味がわからないです」という感じになっています。新しいOSやオープンソースのミドルウェアというところに対して、なかなか移行できていないです。
外のASPサービスとか、JenkinsのCI・CDもなかなか取り入れにくいというのが、今のプライベートクラウド、オンプレミス環境の課題になっています。
こういう点について、現場としてどう困っているのかという点と、今後どうしていきたいのかに関して、現場のエースを連れてきましたので、1つお話ししてもらおうと思います。
