「使いやすさ」「成果より進捗」「いじりやすいこと」　ISUCONの達人たちが重要視しているパフォーマンス

草野氏が重要視しているパフォーマンス

草野翔氏（以下、草野）：じゃあいったん最後のテーマにいきます。このあとはみなさんの質問をいろいろ受け付けながらやっていきたいなと思っています。

（質問を見ながら）これは先ほどの優勝する方法にもつながってくる感じがするのですが、「好きなパフォーマンスは何ですか？」。（好き以外にも、）重要視しているとか。

これはこの前偉い人にも聞いてみたんですけれど、けっこういろいろな回答が返ってきておもしろかったので、著者陣のみんなはどんなパフォーマンスを気にして生きているのかがちょっと気になっていて、何かいい話が出てくるといいなと思っています。

僕はわりとヒューマンリソースのパフォーマンスを重視して生きているので、「みんながニコニコしているといいな」ということをなるべくベースにできるようにがんばっています。

パフォーマンスといっても、リソースのパフォーマンスとかデベロッパーエクスペリエンスとか、開発のパフォーマンスとか。いろいろなパフォーマンスがあるけれど、どんなパフォーマンスをけっこう大事にしているかとか、「これが好きだな」という視点があるのかを聞きたいです。

金子氏が重要視しているパフォーマンス

草野：catatsuyさんはどうですか？

金子達哉氏（以下、金子）：難しいですね。エンジニアとしての僕で言うと、圧倒的にコストパフォーマンスは気にしているというか、重要視しています。仕事の上では、開発者一人ひとりの開発パフォーマンスを重要視している気がします。

草野：なるほどな。サーバーのコストパフォーマンスとかですか？

金子：そうですね。サーバーの台数とかコスト。あとは、それを実際に改修しようとすると、ヒューマンリソースでまたお金がかかっちゃうじゃないですか。「コストをいいラインで止めたい」みたいな気持ちがあるので、「これは人間のコストをかけてでもやったほうがいいけど、ここから先はお金で何とかしましょう」みたいな。

草野：なるほどね。

金子：エンジニアとしての僕は、そのラインをけっこう気にするかなと思ってやっています。

草野：なるほど。

長野氏が重要視しているパフォーマンス

草野：kazeburoさんは気にしているパフォーマンスはありますか？

長野雅広氏（以下、長野）：使いやすさですかね。Webアプリケーションを触った時からUIの使いやすさまで、ボタンを押した時の反応速度みたいな、そういうパフォーマンスですよね。ボタンを押して10秒、20秒待たないと返ってこなかったり、返ってきたとしてもエラーになると、使う側としてはイラッとします。なのでレイテンシーというか、使いやすい速度で返ってくるパフォーマンスは大事にしています。

草野：そうね。エクスペリエンスパフォーマンスだ。

中西氏が重要視しているパフォーマンス

草野：waitaさんの気にするパフォーマンスはどうですか。

中西建登氏（以下、中西）：なかなか難しいですね。パフォーマンスはISUCONの時は気にしますが、日常的なところの一つひとつでいうと、実はそこまでパフォーマンスを気にしていないのかなというのを、今聞いていてちょっと思ったりしていました。

でも、その中でも完全に趣味の話でいうと、OSSのソフトウェアインターフェースの組み合わせはけっこう好きだったりするので、そういったつながっている部分が正しいと、綺麗につながると思います。そういうのがけっこうモチベーションというか、そういうところのパフォーマンスにつながってくるのかなとふと思ったりしていました。

草野：なるほど。

馬場氏が重要視しているパフォーマンス

草野：馬場さんの考えるパフォーマンスで大事なのは何ですか？

馬場俊彰氏（以下、馬場）：ポジショントークをすると、売上や利益が大事です。

（一同笑）

馬場：取締役なのでね（笑）。売上や利益が大事だというのと、従業員の居心地や、不満が少なくて楽しくとか、離職率が低いとか、満足度が高いということはあります。これでポジショントークは終わり。

エンジニアというか業務をやっていく上で言うと、どちらかというと成果より進捗を重視するようにしています。失敗を含めて、考えて何も手が動かないとか、事態が変わらないほうを私は恐れているので。OODAループみたいな本に書いてありますが、進む。とにかくちゃんと考えて行動して、次の結果を得ることを重視して、それがちゃんと回っているかどうかをパフォーマンスとして重視しています。

草野：ありがとうございます。

藤原氏が重要視していること

草野：藤原さんの考えるパフォーマンスは何ですか？

藤原俊一郎氏（以下、藤原）：パフォーマンスというか、好きな話ですよね。何を重視するか。何でしょうね。改修しやすいやつがいいですよね。いじる時に「どこをいじったらいいかわからない」みたいなことはやっぱりつらくて、直したくても直せない、モニタリングをしたくてもできないみたいなことは、いざとなった時にも何もできなくなってしまうので、いじりやすいことはけっこう開発のパフォーマンスとかにも結び付いてくるかもしれません。

というのと、スケーラビリティがある、要するにサーバーを足しただけで強くなってほしいということは常日頃から思っていて、スケールが難しいミドルウェアに頼りきりみたいになると、本当に困った時に、にっちもさっちもいかなくなるじゃないですか。

「この1台のRedisをまずどうにかしないとどうにもなりませんみたい」になってしまうと、アプリケーションを相当がんばって直さないとどうにもならないから、もうどうしようもないじゃないですか。そういうところを、いざという時にどうにかしやすいようなシステムになっているのがうれしいですね。

草野：なるほど。ありがとうございます。みんなけっこういろいろなパフォーマンスが好きでおもしろいですね。コスパ好きはいいなぁ。それから、並べて強くなるのはありがたい。

草野：並べてメチャクチャ強くなってほしい。並べて強くなってほしいやつは、藤原さんが言っていたやつですね。

金子：それこそ今回の本のテーマじゃないですか。なんか変に作ってしまうとサーバー台数を増やしてもあまりパフォーマンスは上がらなくなりがちなので、そういう方にISUCON本（を）みたいな。

草野：ISUCON本を全部やると、横に並べれば確かに強くなりそう。あれはわりと横に並べやすくなる感じの改修方法ばかり書いてある気がします。みなさんはどうですか？

金子：書いてあると思いますよ。

（一同笑）

草野：みなさんが書いたところですからね？　僕はその横に並んでいるやつをバコバコに叩く方法しか書いていないので。

（次回に続く）