今年も開催された、
今回、
ISUCON11、予選～本選の心持ち
- Q：予選終了後の順位、
また、 他チームの結果を見て感じたこと、 本選に向けてチームとして意思確認したことがあれば教えてください。 藤原氏： 今回は予選は通過できれば良いぐらいのリラックスした気持ちで参加しました。
そして、
予選17：00の時点でISUCON11 オンライン本選スコアボードが凍結され、 その時点で私たちのチームは1位でしたので、 少し余裕を持っていました。結果的に予選突破できたので、 順位 （4位） はあまり気になりませんでした。 川添氏： 前回のISUCON10もこの3名で参加し予選落ちをしていたので、
とにかく予選突破はしたい、 という気持ちが強くありました。また、 11の予選課題はスコアが大きく上がりやすい書き込み型の問題だったため、 最終的には100万点を超えるチームが出てくることは予想していました。自分たちは残念ながら100万点を超えることができませんでしたが、 予想通り、 100万点を超えたチームが2チームありました。 谷脇氏： 3人の中では、
最後の1時間、 おそらく自分がいちばん不安を持ちながら進めていたと思います。結果的に、 予選突破が決まったときは心底ホッとしました。 藤原氏： 無事予選通過しましたが、
その後、 決勝に向けて特段みんなで準備したことはなかったですね。 川添氏： 私はISUCON7以来となる久々の本選進出だったので、
個人的に予選の振り返りをしました。とくに、 各チームの予選ブログを読んで、 自分たちのチームで見落としていたことをピックアップし、 「れもんが本番中にいつも忘れる細かい改善チェックポイントリスト」 （通称：ISUCONとらのまき） として、 A4サイズ1枚にまとめました。 たとえば
「認証のある静的ファイルはX-Accel-Redirect!」 「JSON生成遅いのでgoccy/ go-jsonを使う!」 「Thundering Herd対策にsingleflight!」 といったものです。 ざっと書き出して、
写真に撮ってチームSlackに共有しておきました。
fujiwara組が優勝できた理由はこれだ！方針決めと実行の内容
- Q：お話を伺っていると、
お三方とも予選後半から手応えを感じ、 また、 本選が決定してからも普段どおりの日常を過ごしていたように思います。そのリラックスも優勝につながったのかもしれませんね。
さて、
本選の課題 「ISUCHOLAR」 の高速化の出題を受け、 最初に話し合ったことは何でしょうか？ また、 どのような役割分担で進めることにしましたか。 藤原氏： まず、
履修登録という課題を見て 「予約型か」 と思いました。これまでも、 ISUCON2、 8でもあったようにISUCONでは予約ネタは頻出していたので、 驚きはなかったです。チューニングのポイントとしては 「ロックの取り合い」 を想定しました。 川添氏： 藤原さんが
「履修登録、 予約型か」 とつぶやいたのを聞いて、 同じく 「ロック」 を強く意識しました。また、 予選のISUCONDITIONでは書き込みが激しい課題だったので、 本選もまた書き込みが激しくなることも想像しました。 一方で、
本選のレギュレーションではキャッシュ禁止となったため、 書き込みが激しい場合の対策をどうしよう、 とも思いましたね。 谷脇氏： 2人と同様の感想で、
さらに藤原さんもコメントしたようにISUCON2の課題を思い出しました。一方で、 予選の問題とも違うと感じ、 課題が出てすぐにアプリケーションのコードを読み始めました。 - Q：それぞれが課題の第一印象を捉え、
そして、 動き出したわけですが、 実際に本選が始まった際、 どのように方針を決めたのか、 また、 注意したことや自分たちのチームとして工夫したこと、 エピソードがあれば教えてください。 藤原氏： まず、
大きな役割分担として、 私がまずインフラ全般を担当し、 川添・ 谷脇両名にはコードを読む作業に専念してもらいました。 その体制で、
本選開始直後からインフラの見直し、 初期でできる設定を終わらせてみてスコアを確認したところ、 それほど点数が上がりませんでした。なので、 これ以上はインフラチューニングに時間をかけず、 自分も含め3人でコードを読もう、 と切り替えました。 川添氏： 私たちのチームの初期スコアが30,000点で、
他チームでは早い時間で70,000点出ているところもあって、 足の早い課題だと感じました。ここで、 優勝の前にまず特別賞 （最初に80,000点を超えたチーム） を狙っていたので、 そこを最初の目標に設定して動きました。 一方で、
Indexはきれいに張られていてDB周りで高速化するネタはほとんどないと判断しました。ですので、 このタイミングで、 コードかクエリに手を加えなければいけない、 という大きな方針に注力できました。 この分析は他チームも同様で、
おそらくデータベースを切り分けた複数台構成への変更をするところが出てくるだろう、 と、 藤原さんに複数台構成への変更をお願いしました。11：00ぐらいには完了しましたかね。 結果、
スコアが上がり午後には80,000点を超えました。ただ、 残念ながら2番目で特別賞は取れませんでしたが、 特別賞を獲得したチーム焼肉ジャンボチキンのブログエントリを読むかぎり、 方向性や初動はほぼ同じでしたね。 その後は、
N+1クエリをなくしていく作業に専念し、 アプリケーション・ DB双方の負荷を確実に下げることを目指しました。修正するエンドポイントが谷脇さんと被らないように打ち合わせて分担しました。 私はGPAのsingleflight化を行いました。実際にやってみて点数はあまり上がりませんでしたが、
データベースやCPUの負荷は下がったため手応えはありました。
スコア凍結、そして、優勝へ
藤原氏： 80,000点を超えたあたりから、
中間スコアで首位に立ち、 そのまま優勝となりました。振り返ってみて、 今回の課題はいきなり50,000点上がるといったチューニングはなさそうだったので、 3人でできることを着実にやっていきました。 GPA計算のsingleflight化については、
私も同じで、 スコアが大きく変わらなくても、 アプリケーションに効いている感触はあって、 効果があったな、 と思います。 川添氏： 私は最初からアプリケーションコードを読んで、
手を入れていました。たとえば、 interpolateParamsの設定やechoのLoggerをなくす作業です。1つ1つやる作業が目に見えていたので、 3人で担当を分担してできたことが良かったですね。 ただ、
昨年のISUCON10では、 負荷の度合いを変更するパラーメータをベンチマークかける側で操作できたこともあり、 もし、 ああいう状況が発生したら仕方ないと割り切っていました。 藤原氏： 17：00のスコア凍結時で私たちのチームだけ110,000点超えていた
（2位と約15,000点差） ので、 この時点でかなり有利とは思っていました。そこからさらにスコアを積みまして、 私自身は130,000点を超えた時点で一気に抜かれることはないだろう、 3位以内は入れると、 確信しました。 川添氏： ISUCONはスコアがマスクされる最後の1時間が、
最も予測できないですし、 正直他のチームが何かやってきたらという不安があったのは事実です。というのも、 これまでのISUCONは本選終了1時間後に結果発表がされていましたが、 今回は一晩置いて翌日発表だったため、 寝ている最中にいろいろ考えてしまいました。とくに、 1つやり忘れた思いついたチューニングがあって、 他チームがそれをやっていたらやばい！ と思って、 翌日を迎えました （笑 谷脇氏： 私はとにかく優勝かそれ以外の気持ちでずっとやっていました。今回の課題については、
自分の日常業務で行っている投稿の既読・ 未読管理と共通する部分が多く、 その経験と知識を活用できたと思います。
3人が考えるfujiwara組、優勝の理由
- Q：予選と同様、
あるいはそれ以上に本選ではチームとして成熟し、 また、 時間が経過するにつれ、 優勝への確信が高まっていたように伝わりました。そして、 ISUCON11の栄冠を獲得されました。今回、 fujiwara組が優勝できた理由 （自前の考察） は何でしょうか？ それぞれ教えてください。 藤原氏： 私自身4回目の優勝をすることができました。これまでの優勝はこの2人とは別のメンバーで、
そして、 この3人で出場したISUCON10が予選落ちだったこともあって、 本選出場や優勝への意気込みは強かったと思います。 ISUCON10と並行して行われたエキシビジョンでは、
本選参加チームと比較して総合3位 （社会人チーム1位） のスコアを出せたことで、 最初の手応えがありました。 今回を含め11回出場した経験から、
私が優勝できたときは必ず最初から最後まで手を動かせた （私が行う作業が必ずある） 状況で、 今回は、 作業を探すことを含め、 最後までとにかく手を動かす意識が強かったですね。実際、 3人とも最後までコードを編集・ 書くことがあった、 というのが、 優勝できた要因の1つかもしれません。 それから、
3人の作業をレイヤごとに完全には分担せず、 独立して動けたことも大きかったです。 川添氏： 今の話の流れで、
3人の作業がコンフリクトしないように意識しました。また、 3人それぞれが計測も行った （行えた） ことで、 作業待ちや作業遅延が発生せず、 並行して進められたことが大きかったです。 谷脇氏： ISUCON10から組んだチームで、
その当時はまだ分担がふわっとしていました。また、 予選の最後に日和って途中で止めた作業があり、 結果的に予選落ちとなりました。 ですから、
今回の自分としての勝因は 「攻め続けた」 です。 また、
個人的要因としては、 当時はGo言語の経験が少なかったのですが、 1年経過して業務でのGo言語での開発経験が増え、 ようやく馴染んだというのもあります。 前の2人もコメントしているように、
やはり、 3人の円滑な作業分担、 3人で仕事をやっているというチームワークと温度感、 「この3人の円滑なコミュニケーション」 が最も大きな勝因かもしれません。
ISUCON11 で通算四度目の優勝となるfujiwara組の皆さんにトロフィーとパネルをお渡ししました🚀あらためておめでとうございます！ 🎊 #isucon pic.
— ISUCON公式 (@isucon_official) October 21, 2021twitter. com/ tsHvdHqm1e
fujiwara組の技術力に迫る！
- Q：ISUCON11優勝には、
それぞれの技術力や知識、 そして、 チームワークがあったからだと思います。その中で、 とくに技術力について伺います。お三方にとって、 実際の業務でパフォーマンスチューニングをする際、 心がけていること、 また、 そのために必要と思われるスキルセット （技術領域） やマインドセットがあれば教えてください。 藤原氏： 普段あまり意識的にチューニングをする機会はないとは思うのですが、
たとえば、 日常的な業務で障害が発生したとき、 その原因を探し出す能力が重要です。多くの場合、 コードにあるわけで、 コードを読む力も大切です。 そして、
素早く要因を見つけ出せれば、 あとは、 手数を増やして改善・ 改修を続けていくことでしょうか。 川添・谷脇氏： 藤原さんのコメントがすべてです
（笑 川添氏： ボトルネックを見つけ出すこと、
それはパフォーマンスチューニングをするうえで欠かせないスキルと言えますね。 谷脇氏： 今の話でいうと、
前半の原因・ ボトルネック探しについては、 私自身は思いつきで進めることが多いです （笑 ただ、
日常的にコードを書く業務をしているので、 （パフォーマンスチューニングが目的でも） 必ずまずコード全体を読むようにしています。コードを上から下まで読んで、 直せそうな場所を見つけたら、 すぐに書き直します。 ここで意識するのは、
コストパフォーマンスの良い書き換え、 つまり、 周囲への影響は少なく、 バグが生まれにくい部分から手を加えることでしょうか。 川添氏： 業務ではコード書き換えによる効果と結果を意識しますが、
ISUCONだとコードを書き換える作業が （そういったビジネス的なやましさなく） 無心でできるのが良いですね。 谷脇氏： でも、
ISUCONでも後半は自分たちが書き換えたコードが増えてくるので、 （直す・ 直さないの選別で） やましさというか、 主観が入ります （笑
それから、
エンジニアのキャリアとターニングポイント
- Q：今のお話は、
パフォーマンスチューニングに限らず、 ソフトウェア・ エンジニアリングすべてに通じて大切なことのように思います。
次に、皆さんのこれまでのキャリアについて伺います。また、 キャリアが続いていく中でのご自身の変化、 ターニングポイント、 たとえば、 5年前の自分と今の自分で成長した部分 （技術的観点で）、 また、 成長できた理由 （学習、 経験、 人脈など） があれば教えてください。 藤原氏： 今、
おもに使用している開発言語はGo言語です。ISUCONで初めてGo言語を使用したのはISUCON3の出題のときでした。それまではPerlの開発ばかりしていて、 ISUCONも5まではPerlのみ、 6の本選でGo言語を混在して触りました。ですから、 まさに5年前が1つの自分自身の変化のタイミングでした。 ISUCON6の時点ですでに経験があったのでGo言語を書くことはできましたが、
Perlと比べてそこまで得意ではありませんでした。その経緯から、 ISUCON7以降は完全にGo言語で参加しています。 この背景の1つに、
所属しているカヤックで実施したGo言語推進宣言も関係しています。 ISUCONや業務以外に、
個人で開発するものも今はほぼすべてGo言語ですね。実際に触ってみて、 Go言語の素性はすごく良いと感じます。今時の言語らしく、 Webアプリケーションやネットワークサーバ開発に必要な標準ライブラリが充実しているいる点を評価しています。 カヤックでも、
かつてはGo言語の標準ライブラリを読む勉強会を毎週開催していて、 エンジニア同士での共有、 理解を高めることを行っていました。 川添氏： 今、
私は15～16年のエンジニアキャリアがあるのですが、 もともとはC++言語のエンジニアでした。2012年2月にカヤックへ転職し、 来年2022年2月で10年目となります。 カヤックに入って、
当時在籍していた@typester （村瀬大輔氏） とWebサービスの開発をすることで、 Webの世界に入りました。 ISUCONは2から参加しています。3は出題する側だったので、
運営の立場で関わったのですが、 その際、 初めて社内ISUCONを開催し、 試し役をやったのですが、 その経験は非常に大きかったのを記憶しています。 使用言語については、
C++からWeb開発になり、 カヤックのGo推進宣言とともにGo言語の開発を経験しつつ、 主業務となったフロントエンド開発ではTypeScriptをメインで使うようになりました。同じく5年ほど前がこのタイミングでした。 TypeScriptはC++と同じ型付言語で個人的に扱いやすかったこと、
そして、 C++と異なり、 型付言語なのにWeb開発に向いているということがとても気に入っています。 また、
Go言語と同様、 まさに進化中の言語の1つで、 日々新しい情報をキャッチアップできますし、 それがそのまま成長につながるという点でTypeScriptは嬉しいですね。 谷脇氏： 私は、
業務のプロジェクトはPerlとGoがそれぞれ半分の比率です。とくにシステム運用に関わることが多く、 ログの収集や分析など、 パターン化とスピード感が求められる業務が多く、 その点ではPerlが合っていると思います。また、 先ほども述べましたが、 昨年からGo言語を触る比率が上がっています。 キャリアというか、
経験の積み方という点では、 業務内容もあって火事場 （炎上） プロジェクトを経験して成長しているように思います。でも、 これは一般的にはおすすめしません （笑 私は言語という観点より、
業務内容という点で5年前と今で変化していることがあります。今までは 「これを使う」 とあらかじめ決められた技術や言語を使っていました。今、 デベロッパからアーキテクトへ職種が変わったことで、 「どれを使う」 という選ぶ立場に変わってきています。 ただ、
コードを書くことは継続しています。 川添氏： また、
3人それぞれの変化というよりは、 カヤックを含め、 多くのエンジニア組織で顕在化したのがこの2年でのコロナ禍で人が対面で集まりづらくなった結果、 マネジメントの在り方が課題になりました。今もまだ方法を模索しています。誤解を恐れずに言えば、 今はマネジメントの中でも後進の育成を実施できていないです。 その中で、
経営管理の所属になってからは新卒研修に工夫を加えています。もともとカヤックでは、 新卒研修で新しい言語を身に付けてもらうカリキュラムを用意しているのですが、 今年はTypeScriptを選びました。 この理由の1つとして、
新しい言語、 社内ではあまり使われていない言語を選ぶことで、 新人研修だけではなく、 社内の中堅、 ベテランエンジニアにも、 自分たちが知らない言語の良さ、 特徴を知ってもらえるようになり、 コミュニケーションにもつながるからです。 その他、 新しい試みとしてはこれまで新卒研修で社内ISUCONを実施してきましたが、 今年はCTF （Capture The Flag） をやってみました。
ISUCON11優勝チームが注目する技術・コミュニティ
- Q：豊富なエンジニアキャリアを持つ皆さんが、
今、 2021年以降のWebサービスを考えるうえで、 より深く身に付けておいたほうが良いと考える技術、 知識、 あるいは、 関わっていたほうが良いコミュニティがあれば教えてください。 川添氏： コミュニティで言うと、
先ほどの育成と同じく活動そのものが難しくなっていると思います。地域活動はとくに停滞している印象です。 谷脇氏： 私は以前から八王子で行われているHachioji.
pmや、 その他の地方pm （Perl Mongers） などに参加していますが、 オフライン開催ができなくなって以降は参加自体もあまりしなくなってしまいました。また、 地方pm自体も私の観測範囲では、 以前に比べて開催の頻度が減っているコミュニティもあるように思えます。 藤原氏： 一方で、
技術に関するイベントやカンファレンスの在り方が、 コロナ禍前から、 少しずつコミュニティベースのものから企業ベースへシフトしてきたことも、 コミュニティの存在や定義が今と数年前で異なる理由かもしれません。 これに関連して、
コミュニティベースが主流だった時代は1つの言語、 1つの技術を軸に、 イベントが開催され、 結果、 コミュニティが成長していました。今は、 技術軸ではなく、 技術領域 （フロントエンド、 バックエンド、 インフラなど） 軸で分けられ、 目的に応じたイベントが増えた結果、 コミュニティという考え方が薄れているのかもしれません。 谷脇氏： 技術に関して言えば、
最近はGraphQLに注目しています。今後のWebアプリケーションのつくり方に大きな影響があると思います。、 現在は活用された例や、 日本語の情報についてが少ないのが課題です。海外での事例や情報にもアクセスして、 会社に閉じないで情報収集しています。 川添氏： 技術領域ではSREが広がることを期待しています。職種ではなく、
知識としてのSRE、 SRO、 SLIです。どうしても横断的、 また、 サービスやプロダクトによっての差異があり、 体系的にまとまったものが少ないため、 それを改めて認知して、 エンジニアに理解してもらえたらと考えています。 また、
どの技術に関しても、 技術力を上げることが目的か手段か、 エンジニア自身でその見極めが大事ですし、 マネージャの立場としては、 一緒に働くエンジニアがどの視点でいるのかを意識しています。中には技術力向上が目的で入社して、 自己達成して辞めてしまった、 という例もありました。
ISUCONの魅力とこれから
- Q：最後に改めてISUCONの魅力を一言ずつお願いします。そして、
ISUCON12が行われたとして、 出場しますか？ 藤原氏： 次回開催されたとして、
もし参加できるとしても何が何でも参加したいとは思っていないです。ただ、 ISUCON11開催前は、 優勝したらこれで終わりと考えていましたが、 次やその次に関しても、 自分の予定が空いていて組めるメンバーがいるのであれば出場する気持ちになりました。その場合、 4回優勝したことで、 次は負けてもいいやぐらい気楽な気持ちで出場できると思います。 ただ、
おじさん枠みたいなものを作られるのは困るので、 若いメンバーと一緒に組んだり、 普通に出場したいです。 川添氏： ISUCONの魅力――みんなが同じ問題を解いているのに、
解答方法が十人十色であること、 そして、 参加者自身が自分や自分たちのチームの取り組みをブログに残してくれていて、 それを読めることですかね。 「他人のチューニング方法を共有できる」、 これが魅力でしょうか。 優勝チームは出題側に回る可能性もあるので、
もし出られればという仮定になりますが、 出られるのであれば出たいです。ただ、 もし藤原さんと組むとつねに 「fujiwara組」 という名前が着くのでプレッシャーですね （笑 谷脇氏： ISUCON10から、
自分の裏テーマとして 「藤原さんを優勝させたい」 を設定していました。ですから、 今回はとにかくそれが実現できてよかったです （笑 ISUCONの魅力は、
普通に参加しやすいこと、 日常の業務に近いことです。そして、 結果として、 エンジニアとしての自分の力を可視化できることが一番の魅力です。腕試しの場でもあり、 他人との比較ができる場も嬉しいですね。 今回の私たちを含め、
ISUCONで優勝しているのは会社の同僚や元同僚といったチームがほとんどです。ですから、 もし12に出場できるとなったら、 社外のメンバー、 たとえばHachioji. pmの仲間と組んで出場して、 社外の人と組んでどこまでやれるか、 腕試ししたいです。 - ――ありがとうございました。
- プロフィール
藤原俊一郎
（ふじわらしゅんいちろう） 所属：面白法人カヤック 技術部
職種：ソフトウェアエンジニア、SRE
扱っている技術領域：クラウド、SRE、 CI/ CD、 バックエンド
注目している技術、プロダクト：クラウド技術全般、 モニタリング （可観測性） ISUCON参加歴 ISUCON：fujiwara組 優勝 （fujiwara、 Songmu、 sugyan）
ISUCON2：fujiwara組 優勝（fujiwara、 Songmu、 typester）
ISUCON3：出題
ISUCON4：fujiwara組 3位（fujiwara、 acidlemon、 handlename）
ISUCON5：fujiwara組 優勝（fujiwara、 Songmu、 sugyan）
ISUCON6：morimoto組 準優勝（fujiwara、 kasari、 moshisora）
ISUCON7：fujiwara組 本選出場（fujiwara、 acidlemon、 handlename）
ISUCON8：出題
ISUCON9：シン・フジワラ組 予選敗退 （fujiwara、 tagomoris、 joker1007）
ISUCON10：fujiwara組 予選敗退、並行チームとして本選にエキシビション参加 （fujiwara、 acidlemon、 macopy） ISUCON11：fujiwara組 優勝 （fujiwara、 acidlemon、 macopy） ISUCON11にエントリした
動機、理由 ISUCON10の予選であともう一歩だったものの、 本選はエキシビション枠で参加したところ全体で3位のスコアを記録できたので、 このチームならいいところまで行けるかなと思ったため。 
川添昌俊
（かわぞえまさとし） 所属：面白法人カヤック グループ戦略室
職種：経営管理、会社の技術面の全体統括とか相談役、 組織マネージメントなど （※経営管理の部分でバリバリコードを書きまくりつつ、 実際の経営管理業もするエンジニアです）
扱っている技術領域：フロントエンド、バックエンド、 インフラ
注目している技術、プロダクト：最近はTypeScript書くのが楽しいです。フロントエンドのフレームワークは主にVue3使っています。サーバを書く必要があるときはGoで、 AWSやGCP/ Firebaseを使います。考え方としてもSREが好きで、 たまに動向などをチェックしています。 ISUCON参加歴 ISUCON：不参加
ISUCON2：チームぽわわ 初参加 （acidlemon、macopy、 kenjiskywalker）
ISUCON3：出題
ISUCON4：fujiwara組 本選3位 （fujiwara、acidlemon、 handlename）
ISUCON5：不参加
ISUCON6：2名で参加 予選敗退 （acidlemon、handlename）
ISUCON7：fujiwara組で参加 本選出場（fujiwara、 acidlemon、 handlename）
ISUCON8：不参加（出題がKAYACだったので、 見守っていた）
ISUCON9：1人で参加 予選敗退、本選の事前解答に参加 （acidlemon）
ISUCON10：fujiwara組 予選敗退、並行チームとして本選にエキシビション参加 （fujiwara / acidlemon、 macopy）
ISUCON11：fujiwara組 優勝（fujiwara、 acidlemon、 macopy） ISUCON11にエントリした
動機、理由 深く考えずに、 もう1回くらい昨年と同じチームで出れば勝てるのでは! と思ったから。 
谷脇真琴
（たにわきまこと） （Twitter：@mackee_ w ）所属：面白法人カヤック GC事業部
職種：サーバサイドエンジニア
扱っている技術領域：Webアプリケーションのサーバサイド（Go/ Perl/ MySQL/ DynamoDB/ Redis）、 同アプリケーションの技術選択とアーキテクチャ設計 （GraphQL/ Microserivces）
注目している技術、プロダクト：Server-Driven UI Systems、 Incremental Static Regeneration/ stale-while-revalidate ISUCON参加歴 ISUCON：不参加
ISUCON2：チームぽわわ 初参加 （acidlemon、macopy、 kenjiskywalker）
ISUCON3：本選進出
ISUCON4：予選敗退
ISUCON5：予選敗退
ISUCON6：予選敗退
ISUCON7：予選敗退
ISUCON8：出題（本戦問題Perl移植担当）
ISUCON9：不参加
ISUCON10：fujiwara組 予選敗退、並行チームとして本選にエキシビション参加 （fujiwara / acidlemon、 macopy）
ISUCON11：fujiwara組 優勝（fujiwara、 acidlemon、 macopy） ISUCON11にエントリした
動機、理由 ISUCON10の際に社内でfujiwaraさんがチームメイトを探していてそれに立候補したのがきっかけ。そのときに足掛け何年かかるかわからないが、 またfujiwaraさんに優勝してもらうのを目標にしていた。また、 ISUCON8で運営側で散々楽しんだのと、 それ以降はあまり勝てる気がしなかったので、 やる気がフェードアウトする形でISUCON9は参加しなかったが、 fujiwara組で出れるということでモチベーションが出た。