Webアプリチューニングバトル「ISUCON」の歴史と、企業における“社内ISUCON”のはじめかた

ISUCONとは何か？

櫛井優介氏（以下、櫛井）：今日の最後のセッションなので、気楽に聞いていただければと思います。難しい話は1つも出てこないので。資料はこのあとすぐ公開するので大丈夫です。今日は、20分後にはここにいるみなさんが「次のISUCON、絶対出るぞ！」という気持ちになるのをゴールにしております。

軽く自己紹介させていただきます。

LINEという会社で働いておりまして。2004年に私はライブドアという会社にWebディレクターで入りましたが、気づいたらLINEという会社になっていて、今は技術系のイベントを担当しています。

本日お話しする「ISUCON」というイベント以外にも、「YAPC::Asia」というPerlのイベントの運営も一時期やらせていただいたりしていました。

LINEのDeveloper Relations Teamは、日本だけではなくて、韓国・タイ・台湾・インドネシアにもチームがあって、すべて合わせて30人ぐらいのチームになっております。対外的に技術広報したりといったことをやっているのが私の役割です。

本題に入ります。「ISUCON知ってるよ」という方、どれぐらいいらっしゃいますか？

（会場挙手）

ああ、今日は大丈夫そうですね（笑）。「出たことあるよ」という方、どれぐらいいらっしゃいますか？

（会場挙手）

これはいいですね、話し甲斐があります。20分後にはみなさんも出たいと思っているはずです。

それでは、ご存じの方もそうでない方も、初めて出す情報を盛り込んできましたので、「ISUCONとは何か？」というご説明をさせていただきます。

ISUCONが始まるきっかけ

櫛井：まず「なぜ生まれたのか？」というところからお話ししたいと思います。あれは2011年の夏、8年ぐらい前ですかね。ちょっと懐かしいですが、tagomorisさんという方がいらっしゃいまして、当時は一緒に働いていて、今はTreasure Dataにいらっしゃるんですけど、その方が発起人でした。

「けっこういろんな会社ですごいエンジニアいるんだけど、それぞれの環境でそれぞれの制約の中でやっているから、誰が本当にすごいのかわからないじゃん」と。つまり、みんな同じ環境で「よーい、どん」で勝負して1番を決めたいと。「天下一武道会的なことをやりたいんだ」ということを言われました。

当時、すでにパフォーマンスチューニングコンテストはいくつかありましたが、PHPに詳しかったら勝てるコンテストだったり、けっこう偏っていました。なので、とにかく1位を決めるコンテストをやりたいと。そこで「ないなら作ればいいじゃないですか」ということで始めたのがきっかけです。

問題作成は、そのtagomorisと、現在はメルカリでSREをやっていらっしゃるkazeburoさんの2人で問題を作って、企画と運営は私が担当するかたちで進めました。

当時ライブドアは、メディア事業、いわゆるポータルサイトとかブログとかニュースをやっている事業部と、データセンター事業をやっているネットワーク事業部の2つに分かれていたのですが、タイミングよくメディア事業部で使う予定のサーバが100台ほど準備できているので、これをなにかしらに使うことができる状況でした。

当時はライブドア事件があってあまりイケイケな時ではなかったので、予算はぜんぜんなかったんですが、いろいろなところからお金を集めて、今、賞金100万円でやっているんですが、当時は、1位が6万円で、2位が3万円、3位が1万円の総額10万円でやっておりました。

当時、FF11というインターネットゲームのネットワーク構築された伊勢さんという有名な方がいらっしゃるのですが、その方にいろいろと協力していただいて開催することができました。

ISUCONの名前の由来

櫛井：名前の由来です。ISUCONって純粋に聞くとなんか「ISUって何？」というのが先に来ると思います。なんでISUなのかと、ちょっと背景を説明させていただきます。

開催当時、ライブドアという会社でエンジニアがサーバチューニングをしていくときに、「あまりにひどい構成だったら、椅子投げちゃうよ」みたいな言葉が社内でちょっと流行っていたんですね。

そういうパフォーマンスチューニングに関わる行為について「椅子」という言葉が一緒にくっついていたんですが、そういう身内ネタがある状況をイメージしていただきつつ聞いてください。

これは当時のIRCのログですね。当時、チャットツールと言えばIRCだったので、すごく懐かしいですよね。あ、懐かしいとも思わないですかね。すいません。

イベント名もすでに決まっている状態で、あと出すだけという状況でのログです。あとはブログで告知してツイートするだけだったんですが、最初は「LPC」という名称でした。もう覚えてないんですが、たしか「Livedoor 〇〇 Performance Contestみたいな感じにしようか」と言っていました。

ただ、「なんかプリンタのコマンドっぽくね？」みたいな話があったり、私は企画担当なので、やっぱり多少バズって欲しいと。なので、もうちょっとバズりそうなキャッチーな名前にしたいという話が出てきて「やっぱり名前変えたい」ということで「ISUでいいんじゃね？」という話になりました。

「ちょっと身内ネタすぎるでしょ」という話もありましたが、当時CTOだったikebeさんという方が「だったら、イニシャルがISUで椅子になったらいいんじゃね？」みたいな話になり、それでトントン拍子で話が進み、「じゃあIikanjini Speed Upですかね」ということで決まりました。

これが初回の開催告知エントリーです。晴れてISUCONになりました。ISUCONって何の略か知らない方は、実は年に何度かこの話をして驚かれるんですけど、これが「Iikanjini Speed Up Contest」という名前になった全貌です。

ISUCONのルール

櫛井：こちらは、定期的に学生の方向けにやっている「ISUCON 夏期講習」というのもあるんですけど、そこで作った資料からの抜粋です。

何をするかというと、制限時間は8時間で、朝10時から夜18時まで、与えられたWebアプリケーションをあらゆる手段で高速化します。そしてベンチマークが実行されて、そのスコアが高いチームが勝つと。そのためならなんでもしていいよというのがISUCONです。

最初に渡されるWebアプリには参考実装がいろいろとあります。PerlとかPHPとかGoとかいろいろあるんですが、それにはボトルネックがたくさん仕込んであります。つまり激遅のWebアプリをどうにかするのがISUCONです。

これがISUCON本戦の様子です。朝10時に出題チームから「こういう問題ですよ」という説明が発表されます。ちょっと小芝居が入ったりして、たいへん楽しい雰囲気で始まります。去年のISUCON 8では、仮想通貨ならぬ「仮想椅子取引所」がテーマでした。

よく本戦でやるのは、朝10時に社長が「いい感じのサービス買ってきて、夜18時にバーンってCM打つから、それまでになんとかしておいて」というのが設定なんですね。というのがISUCONのお決まりのパターンです。なので、社長がいつもわけわからない行為をするのがわりと定番です。

参加者はこういう方たちが多いです。Web系の企業の方とか、大量のトラフィックを捌いてる人が多いです。チームは2人か3人で基本的には出てくださいとしているんですけど、職場の人で組んだり、友人で組んだりしてるみたいです。

なにが必要かというと、このようにあらゆる知識が必要です。あとは時間が限られているので、判断力も求められます。

ISUCONは過去8回開催していますが、このように年々参加者が増えています。一番最初のISUCON 1は、先着順で申し込んだら誰でも参加できたんですが、ISUCON 3からはオンライン予選を開催するようになって、直近のISUCON 8では1,392人のオンライン予選に参加していただけるぐらい、人気のイベントになってきました。

実は「1〜8までずっと出てるよ」みたいな、リピーターも多いですが、延べ人数だと5,000人を超えるようなイベントになっております。

エンジニアのみなさんにも「ISUCON」という言葉は浸透しておりまして、処理が遅いサイトを見ると「ISUCONの参考実装かよ」と言われる例もありまして、パフォーマンス改善する行為自体を「ISUCONする」なんて（表現する）言葉もあったりします。

私が最近やっている「実際に自分で行ったところに地図を塗りつぶす」みたいなスマホゲームなんですが、ちょっと処理が遅いので「これISUCONでどうにか直せないかな？」と思ったりしています。

ISUCONの歴史

櫛井：次に歴史です。たった8回しかやっていませんが、参加者の本気度がすごく高いので、けっこう濃密です。

これまでいろいろなチームが優勝しています。

これは本戦の集合写真です。最大30チームが参加するのですが、結果発表のあとなので、晴れ晴れとしています。ちなみに8時間めちゃくちゃがんばったあとで、同じ問題を解いた仲間みたいな雰囲気なので、懇親会はめちゃくちゃ盛り上がります。

これは出題した問題とサーバ提供、優勝チームをまとめました。いろいろな問題をいろんな方々に出していただきました。

ブログというベーシックなものから、各社さんの特徴を活かして、はてなさんだと「キーワードリンク」という問題だったり、ピクシブさんだと「お絵かき共有」とか、そういったお題がありました。ほかには、「ISUCON銀行」や「チケット販売」など、先ほど言いました「仮想椅子取引所」とか、そのとき時代に流行っているテーマなんかもわりと採用されたりします。

ちなみに、優勝チームはすべて3人チームで、8回やったので3×8で24人の優勝者がいそうなものですが、強い人は強いので、ISUCON優勝経験者って実は15人しかいません。

なので、これは初めて言いますが、実は7ぐらいから「優勝者同士で組むのはもうやめてください」と言うようにしています。

先ほどの図ですが、こう見るとカヤックさんがめちゃくちゃ強いです。8回中4回優勝してるという驚異の勝率です。

1と2で独走で勝ったので「次は出題しませんか？」と私から相談して、3で出題してもらったんですが、3から賞金が100万円になったので、すごく悲しそうな顔をして「僕らが出ないときに100万円なんて、ちょっとそれはないんじゃないですか……」みたいに言われました。

カヤックには藤原さんという凄腕のエンジニアがいて、彼がいると驚異的に強いです。なので「ISUCONで優勝したかったら、藤原さんと組めば最強」と言われているぐらいですね。

去年のISUCON 8は、実は優勝が学生チームでした。これは、今は過去問が出回っているのと、予習に時間をかけられる学生チームが強くなるのはいずれ必然だと言われてきたので、結果（として）出るまでに、そう時間がかからなかったという印象です。

業務でパフォーマンスチューニングをやっていない方にもたくさんご参加いただきたくて、これまでは学生枠という優先的な枠を用意してきましたが、「こういう状況になったからには、次は学生枠いらないよね」という話もあったりします。

そうです。ISUCONは新時代に突入していると。

ISUCONの魅力

櫛井：次に魅力についてです。何がそんなに楽しいのか、ちょっとわからないですよね。なので、今まで運営や参加者に聞いてきたものを抜粋して持ってきました。

ISUCON 5の時に、創設したtagomorisさんと、kamipoさんというRailsのコミッターとしても有名な方に話を聞きました。

学生にたくさん出てほしかったのでこういう聞き方にしてるんですが、「どういうところがいいですか？」と聞くと、「Webサービスの人たちがふだん何をやっているかわかりますよ」と。あとは「 普段なにをしていても、ISUCONはなんでもしていいので。『当方ボーカル、ギター募集』みたいな、そのときやりたいことができるので、ぜひチャレンジしてください」という話があったりしました。

これはISUCON 7の時に過去の優勝者たちに全員にインタビューしたものの抜粋です。「あなたにとってISUCONってどんなイベントですか？」って聞くと、「本当のWebサービスのチューニングに最も近い」とか「エンジニア人生が変わった」、あとは「寿命が何年か縮まる」。

あとは、「参加しようという人に向けて、なにかアドバイスもらっていいですか？」って聞くと、「自分に 何ができて何ができないのかを正面から見つめられるのは精神的にしんどいけど、ほかでは決して得られない体験があるよ」とか。

あとは、最後に「優勝した時の勝因はなんでしたか？」と聞くと、「強いメンバーと組めた」とか「信頼できるメンバーと組めた」とか。なんか「『ONE PIECE』かよ？」みたいなエモい文言ですね。

これは持論なんですけど、人は極まるとエモくなっちゃうんですよね。なので、それぐらい短時間で極まってしまうイベントだと思っています。

ISUCON沼

櫛井：これはISUCONの魅力、沼編ということで、よくあるエコサイクルを紹介したいと思います。

まず募集します。なんとなく悪そうな人に「100万円だよ」って言わせるんですけど。みんなけっこう「自分なら100万円余裕でいけるわ」って言って来るんですね。

そうしてやってみて「あ、いい感じだな」となると優勝できるんですが、先程言ったように、優勝ってめちゃくちゃできないんですね。実際できないので、ほかの人はどうなるかというと、「悔しい！」ってなります。「悔しいけど、なんか俺、実力ついてきた」みたいな感じになります。「パフォーマンスチューニング好きになってきた。スコア伸びて楽しい」みたいになっていきます。

会社に戻って「みんな一緒にやろうぜ！　自分たちの会社のあのサイトもパフォーマンスチューニングしようぜ」と言ってホワイトハッカー集団になっていって、最後は日本のインターネットがすごく速くなってハッピーになると。

これは実際に行われていることで、こういういい感じのエコサイクルができています。そういう人たちはまた出てくれるんですね。でも、中には「自分たちで社内ISUCONしたい！」みたいになって。これはもう完全に沼になっています。

このようにどっぷりハマる人が多いので、リピーターも多い。これがISUCONです。

勝つためのポイント

櫛井：ここまでですでに、みなさんも「出たいな」と完全に思っていると思いますが、一応勝つためにどうしたらいいのかを教えますね。勝つためのチーム構成のヒントです。

「3人で組むのが条件ですけど、1人や2人でも勝てますか？」と聞いたら、「基本勝てません」と明言されます。なので、「どういう3人だったらいいんですか？」って聞くと、「インフラが見れて、全体的に俯瞰で理解できて、指示を出せる人」。これはつまり藤原さんですね。「コードを書くのがめちゃくちゃ速くて、アプリケーションエンジニアの人」。あとは「細かくフォローができる人」。

なので、とにかくアプリを書くのが速い人が3人集まってもダメなんです。なので、最近はこうした布陣でないと勝てないと言われています。なので、みなさんもそういう人を探して、ぜひ組んで出てください。

運営の舞台裏

櫛井：ISUCONの運営の話をすると、時々話題になりますが、ISUCONの運営ってめちゃくちゃ大変なんです。参加者のレベルも年々高くなっているので、問題作成のプレッシャーが半端じゃないんです。なので、そこを「まぁまぁ」というのが僕の役割なんですが、問題を作ってまた手直ししてってやっていると、難易度もわからなくなってきて「これ、本当にいい感じにスコアが稼げるのかな？」と心配になったりします。

あとは、運営の大変さで言うと、ISUCON 7は予選の開始が3時間遅れるという事件がありました。あの時は本当に「お通夜かな？」みたいな感じの部屋になっていました。

まぁ、楽しみなこともあります。運営の醍醐味はいろいろありますが、スコアボードは参加者みんなが見えるんですが、最後の1時間だけは自分のチームのものしか更新されなくなります。

運営チームだけがこの図を見られるんですが、最後の最後で大逆転したりするんですよ。それをみんなでキャーキャー言いながら、「さすが俺たちの藤原さん！」と言いながら見守ることができて楽しいです。

なので、本気で運営をやると本気でこういうのも楽しめるので、ぜひみなさんも運営に興味があったら声かけてください。

あとは、最近、合宿をやったりしています。つらいだけでは大変なので、みんなで楽しく問題作りましょうっていうことで、湯河原で合宿をしたりして楽しくやってますね。

けっこう大変なんですが、私自身は、みんなのテンションを盛り上げたり、一番大事な役割としては、次回の出題の提供をしてくれる会社を探したりサーバ提供してくれる会社を探すといったこともがんばっています。

次回の出題企業は？

櫛井：みなさん、すでに参加したくなりましたよね！　参加したいなと思いましたよね！

最後に、せっかくデブサミなので、次回ISUCONで出題をしていただける会社が決まったので、ここで初めて発表させていただきたいと思います。そういう興味ないみたいな空気、本当やめてほしいんですけど、興味ありますよね？

（会場笑）

次回は、さくらインターネットさんと、メルカリさんに問題を出題していただけることになりました。

オフィシャルのブログも更新されたので、ISUCONオフィシャルアカウントの「@isucon_official」をぜひフォローしてください。

私からは以上です。ありがとうございました。

（会場拍手）

R-ISUCONを開催してみて

司会者：櫛井様、ありがとうございました。続いて、リクルートテクノロジーズ、古川陽介様よりご講演いただきます。よろしくお願いします。

古川陽介氏（以下、古川）：古川です、よろしくお願いします。

先ほど櫛井さんからすごくいいお話をいただいいたので、私はリクルートの中で社内ISUCONをやってみた話をしようと思っています。「R-ISUCON」と言われているリクルートのISUCONについてお話しします。

私は、リクルートテクノロジーズのシニアソフトウェアエンジニアであり、グループマネージャーをやっております、Yosuke Furukawaと申します。

会社での顔はリクルートテクノロジーズのマネージャーなんですが、もう1つの顔がありまして、Node.jsのユーザーグループの代表をやっております。

なぜR-ISUCONを始めたかという話なんですけど、これはもう完全に邪な理由です。

まず「ISUCONに勝てない」。これはISUCONに参加してみないとわからないことですが、本当に勝てないんですよね（笑）。

やっぱり強い人はずっと強いし、さっきみたいに学生みたいな若手からもすごく強い人が入ってきたりするケースもあるし、そもそも参加してる人数がめちゃくちゃ多いです。

予選を突破したことがあるのは私は1回しかなくて、本戦出場回数は1回。前回も参加していたんですが、予選の順位は34位で、たしか20位以内じゃないと本戦に入れないので、もう少しがんばらなきゃという順位ですね。勝てなくてずっと悔しい思いをしていました。

そこで私はどうしたかというと、ISUCONの強い人を調べてみると、先ほどの話にあがったtagomorisさんや藤原さん、kazeburoさん、という方々です。

この人たちはどうして強いかというと、そもそも出題者です。1回目と2回目の出題者だったり3回目の出題者だったりして、調べてみると、過去に出題している人は強い傾向にありました。

「出題していると出題者の気持ちがわかるんじゃないかな？」というか、自分が出題してみたら、ISUCONにも強くなれるんじゃないか？　という邪な気持ちで始めました。「社内でもISUCONをやって出題者になれば、将来的にISUCONでも勝てるんじゃないか？」という思いから始めた感じですね。

僕が社内ISUCONを作ってみようと思ったモチベーションとしては、そんな邪な理由ですね。邪なのかどうかわからないけど（笑）。別に「会社でISUCONをやってみんなの能力を上げよう」とかそういうことは考えてなくて、完全に自分のことしか考えていませんでした。

ただ、実際にやってみると方向性が変わってきて、自分の実力の向上というところももちろんありますが、それだけじゃなくて、会社全体がパフォーマンスチューニングのことを「ああ、おもしろいんだな」と思えるようになってきたところが、けっこう大きかったなと思っています。

本家との違い

古川：リクルートのISUCONと本家ISUCONの違いについて、話しておこうと思います。

ISUCON自体は、先ほど櫛井さんのお話にもあったとおり、出題する会社がそれぞれお題を出し合って決めていきます。基本的にはWebアプリなんですが、それぞれ出題する会社の色があります。

例えば、前回の予選はDeNAさんが作っていたんですが、データベースのレースコンディションでした。一気に複数から同じところにUPDATE文をかけるとか、同じところにINSERTさせるというときに、テーブルロックが多発してレースコンディションが発生する。そんな問題を解かなきゃいけませんでした。

これはけっこう難しい。普通はそこまで同時多発的にUPDATEや更新系の処理が動くことはあまりないので、かなり難しかったです。

私、実はもともとDeNAなんですが、DeNAにいる人間からすると、ソーシャルゲームなんかだとけっこう起きるんですよね。スタミナを消費するときに、ユーザーのテーブルの中にあるスタミナ情報を消費しなければいけないので、ポチポチするたびに毎回UPDATE文が走るんですね。

わりとその手の処理はけっこう難しかったりするので、会社の色がすごく出るつくりになっています。

リクルートのISUCONもリクルートなりの問題を作って、リクルートなりに解いてみるのもおもしろいかもと思って始めたところもあります。「リクルートなりの問題とはどんな問題かな？」ということで、テーマを紹介したいと思います。

リクルート特有の課題を問題に

古川：R-ISUCONで、自分が作った問題は2つあります。R-ISUCONはこれまで4回やっていて、最初の2回は、pixivとヤフーのISUCONの問題をやりました。この2回は昔誰かが作ったものを間借りさせてもらいましたが、3回目と4回目からは自分たちで作りました。

自分たちでは、よくある会議室予約システムを作りました。

これはどうしてリクルートっぽいかというと、リクルートって基本的に会議室が向こう1クオーター分しか取れないんですね。例えば第一四半期でいくと4月1日から6月の末までしか取れない仕組みです。そういう制限を設けないと、いつまでも会議室が予約されてしまう恐れがあるので、それを防ぐための施策です。

では、実際はどうなっているかというと、4月1日とか7月1日とか、クオーターのはじめのタイミングで、みんなが一斉に予約しにいきます。会議室を一斉に予約しにきた結果、だいたいこのページが死んでるんです。

そんなことがあったので、「これ、普通にISUCONだな」と思って、そのまま始めました。

本家のISUCONはバックエンドに強い人、データベースやバックエンドのアプリケーション処理に強い人が基本的には有利なんですが、それは別にそのままにフロントエンドのチューニング要素も入れてみたりしてました。

例えばCSSやJavaScriptをあえて煩雑に書いて重くしたりとか。このCSSはひどくて、第1回のR-ISUCONの問題を起動すると、CSSが13MBあります。13MBあるとめちゃくちゃ重く感じます。CSSのロードはブラウザでは一番最初に走ります。ロードされないと画面が出てこないので、画面が出てくるまでがめちゃくちゃ重く感じるはずということで作ってみました。

そんなフロントエンドチューニングは本家のISUCONではあまりなかったりするので、こんな要素も入れてみました。

これはどうするべきかというと、CSSをminifyしたりgzipかけると無駄なものが消えてしまうので、無駄なものを消した状態でサーブしなければいけません。

それだけでなく、CSSやJSに関しては、1回取得したら2回目以降はキャッシュが効いていてほしいと思うと思うので、Cache-Controlと呼ばれるヘッダーをちゃんとつけてキャッシュを効かせたり。

あとは、アイコン等には画像系の情報が入っているので、画像をきちんとWebアプリケーションに合わせて圧縮しないとスコアが出ないようにしたり。例えば、ChromeではJPEGとかPNGみたいな画像形式だけでなく、最近はWebPと呼ばれている新しい画像形式もあります。そのWebPにしないとスコアが出ないような問題も作っていました。

なので、本家のISUCONはわりとバックエンド有利なかたちで作られていますが、R-ISUCONは私自身がフロントエンドのエンジニアであるときも多いので、フロントエンドチューニングの要素も入れました。実際にリクルートでも起きたりしていて、CSSがminifyされていたり、そういった実際の問題に合わせて入れた感じですね。

チャットシステムにおける既読処理

古川：第2回目の問題、これはチャットシステムの「RINE」ですね。

ええと……（笑）。

（会場笑）

第2回目の問題はチャットシステムで、「RINE」と書いてリネと読みます。これは新卒やインターンの2次面接で使われているプロダクトのお題です。

「こういったシステムを作るにあたって、どうやって作りますか？」というのを見るために使っています。

もともとこれを問題にしようと思った背景は、リクルートでも最近はリアルタイムでコミュニケーションする系のアプリが増えてきていて。例えば、チャットや広告配信など、検索クエリを保管してリアルタイムなイベントの処理をすることがけっこう増えているんですね。

チャットでわりとよくある問題の1つとしては、WebSocketに慣れてない人、WebSocketをあまり使ったことがない人が多いところが一番の問題です。WebSocketで信号を送り過ぎてしまうと。

メッセンジャーアプリでよくあるケースは、既読になったときに「既読」マークがつきますが、クライアントが読んだ瞬間に「既読にしたよ」ということを送ってしまうWebSocket。そうすると、例えばクライアントが10人や20人いたとして、メッセージ数が100個や200個もあったら、メッセージ数×クライアント数のかけ算でイベントが増えてしまいます。ですので、本当はこうやって作られていないはずです。おそらく櫛井さんの会社ではこうやって作っていないと思います。

こういった問題が、リクルートのチャットシステムやその他のリアルタイムのやりとりをするシステムの中でわりと散見されていたので、実際のWebアプリケーションで起きた問題をもとに作り込みました。

パフォーマンスチューニングへの関心が高まった

古川：あと、もう1つ違いがあって、本家は8時間なんですね。8時間のうちでどこまで改善できるかというチューニングコンテストなんですが、R-ISUCONは合宿形式で1泊2日でやります。

これのなにが問題かというと、1泊2日でやると、人によっては寝ないでずっとやっているケースがあったりします。ですので、最終的に体力勝負みたいなときがたまにあったりするわけですよね。

競技として側面ももちろん強いですが、やっぱりみんなでワイワイ合宿としてやる側面も強かったりします。ですがやっぱりみんなスコアを上げたいし、順位も高くしたいと思うので、最終的にすごく競技めいた感じになっています。

一番の違いは、先ほどから説明しているとおり、実際にリクルートで起きた障害や、CSSがminifyされていないままたくさん置いてあるといった、実際の問題をベースに毎回新しいISUCONの問題を作っている点です。

教育的な側面も強いかなと思っていましたが、障害振り返り的な側面もけっこう強くて。やっていると「これISUCONでやったやつだな」ということもあったりします。

リクルート全体で実施することで、リクルート全体のサービスが徐々によくなっていると思います。これはあとで説明させていただきますが、リクルートサービス全体をよくすれば、日本のWebの全体のうち数パーセントはよくなるはずなので、こういう気持ちでやっているところはあります。

リクルートはいろいろなサービスを持っている会社なので、その中でこういったWebパフォーマンスコンテストをやることはすごく意味がある活動だなと思ってやっています。

ISUCONで勝ちたくてという邪な理由で始めましたが、問題を作るところからやってみると、リクルート特有のパフォーマンスの問題を解決するという、リクルート全体のエンジニアの底上げをすることに寄与できたかなと思っています。

今では業務でパフォーマンスチューニングをするときに「リアルISUCON」みたいな言葉で普通に語られるようになりました。

パフォーマンスチューニングに対してみんなが興味を持つようになった、かつ、すごくそこにセンシティブになってきたのが、やっていて良かったなと思いました。これは実際起きた問題をベースにしているところも大きいんじゃないかなと思っています。