特別編：トップエンジニアたちの夜 『シドニアの騎士』観賞会＆座談会 ～Part2～
こんにちは、ライターの岡田大です。
お待たせしました。先日公開した特別編「トップエンジニアたちの夜」の続編をお届けします。
※パート１未読の方＆内容を忘れてしまった方は、コチラを一読してからお楽しみください！
『シドニアの騎士』第１期の総括で盛り上がったメンバーたちの話題は、徐々にシドニアを絡めた仕事論にシフトしていった。登場人物をエンジニアやマネージャーにたとえ、能力や適性について語り合う。とくに、優秀すぎるがゆえに扱いづらい、シドニアの長道タイプのキャラクターに話が及ぶと、場はおおいに盛り上がった。そして、TOMエンジニアの重岡氏が、複数の企業でCTOや顧問を務めてきた経験を持つ伊藤氏に対して……。
重岡 直也さんはいろいろな会社にいて、エンジニアチームを見てきたと思いますが、個人プレーみたいなものってけっこうありますか？
伊藤 それ、マジメな話ですか？（笑）
一同笑
伊藤 いやいや、実際にはありますよ。人が少ないところのほうが、個人プレーに依存しがちという面はあると思います。
堀木 個人プレーが結果的にチームプレーになるという意味では、攻殻機動隊がそうかも（笑）。「我々の間には、チームプレーなどという都合のよい言い訳は存在せん。あるとすればスタンドプレーから生じる、チームワークだけだ！」
一同笑
川崎 個人プレーは個人プレーのままだと思うけどねぇ。
伊藤 小さい組織ならまだいいんですけど、組織が大きくなってくると、どこかでパラダイムを転換しないと全体の生産性は上がってきませんよね。例えば、デプロイとかを個人ベースでやっていると、みんなバラバラにQAすることになってしまう。そうすると、全員１回同じタイミングでやればいいって話に必ずなってきますから。
堀木 みんなでタイミングを合わせて、デプロイサイクルを実施して……。
伊藤 そうです。そういうチームワークは重要なんですよ。『Team Geek』って本にも「ソフトウェア開発はチームスポーツのようなものだ」と書いてる。でも、今度はそれをやりすぎると長道みたいなのが出てきて、それはそれで望ましくないことになる。「長道、テストを書けと言ってるだろ！」って言っても書きやしない。
一同笑
堀木 テストは通ってないけど、すごく効率は良くなる、みたいな。
伊藤 長道はテストを書かなくても、バグを出さないコードを書いちゃうから、マネージャー的には苦笑い。
川崎 それは苦々しいなぁ（苦笑）。
堀木 そういう長道ポジションのスーパーエンジニアって、どこの組織にもいるものですか？
伊藤 30人に１人くらい、いますね。めちゃくちゃコードを書くのが速い、長道のようなタイプが。で、ただ速いだけじゃなくて、コードも正確で、とくに自己主張するでもなく、さっと作っちゃう。チームプレーを重視しすぎて、そういう優秀な部分をスポイルしないようにも、マネージャーは気を配らないといけない。
柄沢 正確なコードを書けるんならいいじゃないですか？（笑）
伊藤 その人を基準にしちゃうと、いろんなことがおかしくなっちゃうんですよ。同じスピードでできない人も当然いますから。
川崎 できるけど、無軌道な人もいるよね。
伊藤 岐神（くなと）みたいなタイプね。長道とは別の意味で言うことを聞かない（笑）。
川崎 岐神ほどイジイジしたタイプは、そうそういないでしょ（笑）。
伊藤 でも実際、エンジニアとしては優秀だけど、無鉄砲な人はよくいますよ。例えば、Prototype JavaScript framework (以下、Prototype)を使おうということになって、みんなで使い始めたと思ったら、「Prototypeはもう古い！」って言い出したり。そうしたら今度はMochiKitって言って、JSの関数型言語のかぶれたフレームワークみたいなのを導入したあげく、そのページでPrototypeとスクリプトタスクがMochiKitからロードされる、みたいなことになってしまって。しかも、某ブログサービスのユーザーの記事ページに。
一同大爆笑
伊藤 けっきょく、それを全部入れたあとに本人が飽きて「もういいや」ってなり、最終的に誰かがMochiKitを取っ払ってjQueryに替えた、なんてことがありました。まあ、そのエンジニアもいまや誰もが一目置く立派なマネージャーですけどね。
関根 やっているときは、誰しもよかれと思ってやってるんですよね。
伊藤 難しいですよ。これだ！と思って使うわけだから。
堀木 どうするのがベストかはわからないですよね。Prototypeは一時期、一世を風靡しましたし。
伊藤 もう黒歴史気味ですけどね（苦笑）。
関根 ほんとですよね。
今吉 当初はPrototypeとjQuery、どっちが残るか？ みたいな感じでしたけど。
堀木 Prototypeは明らかに失速した感が……。
伊藤 話膨らんじゃうけど、同じような話で、自分のなかで嬉しい意味でポジショニングに困っているのが、Google BigQueryですね。いっときは他のサービスをよく使ってたんだけど、最近になってBigQueryも侮れないなと。BigQueryはログデータとかがんがん送りつけておくと、1TBとかのデータでも数秒でSQLクエリできるという基盤なんですけど。まだまだ荒削りなんだけど、単純にデータを流し込んでGoogleスケールで解析したいというときはBigQueryはすごくいい。
重岡 いままでSQLを使えていた、非エンジニアの人が社内にいる場合はそっち使ったほうがいいみたいな、そういう感じですかね。
伊藤 BIと接続しやすいとか、JDBCにつなげるとか、そういうインターフェースを使いやすいという付加価値を持った他サービスとかもいろいろあるんだけど、単純にSQLを流すだけだったら、BigQueryで十分間にあっちゃうし、異常に安い。BigQueryはテラバイトくらいデータがいっても、ようやく月200円とかの世界ですしね。
重岡 そういうメリットがあると、使う人がそっちに流れますよね。すると今度は、もっと成熟した、別のなにかができたり。
伊藤 AmazonのRedshiftとかBigQueryとかだとクラウドサービスなんだけど、同じようなスケーラビリティをHadoopにアドオンする、FacebookがつくったPrestoとかもありますね。あとはClouderaのImpalaとか。TreasureDataもその辺のエンジンをアドオンして、追いつきましたね。業界全体の製品の性能が均質的になってきたと思います。
一同 へ～。
堀木 Prestoって、別々のところで最近３回くらい聞きました。みんな付けたがるんですね。
伊藤 ありますよね、そういうブームみたいのって。いま、TOMではそういうビッグデータ系はなにを使っているんですか？
関根 Redshiftです。Flydata経由で。
伊藤 へ～。Redshiftをなにに使っているんですか？
関根 ログと、トラッキング。あとクリックとか、メールの送信ログとかですね。
伊藤 Redshiftはあんまり使ったことがないなぁ。あれは速いPostgreSQLみたいなものだってみんな言いますけど、そういう理解で正しいですか？
関根 比較したらどうかはわからないですけど、集計は速いですね。それまではずっとMongoDBでやっていたので、MongoDBのデータと比べちゃうと……。
伊藤 Redshiftはスキーマがいるんですよね？ リストキーとかソートキーとか。
関根 そのへんの知識は必要ですね。
伊藤 BigQueryはスキーマはあるけど、パフォーマンスチューニングのためのインデックスとかいっさい気にする必要がないのがいいですよね。
重岡 それは便利ですね。
伊藤 あと、Redshiftって自分が借りたインスタンスに性能が制限されるじゃないですか。でも、BigQueryは基本性能限界がないんです。
重岡 パフォーマンスで課金されるものなんですか？
伊藤 基本、データサイズです。転送料も課金されません。計算対象のデータサイズも Table Decorator という概念があって、Queryを投げるときに「ここからここまでの時間帯のデータ」というように指定できるから、そのぶんしか課金されないみたいなTIPSもある。例えば100テラくらいのデータを持っていたとしても、直近のデータで１ギガ分しか計算しなくてもよかったら、それ以外は課金されないんです。あとデータを溜めこんでおくだけだったら、バイト当たりストレージ価格がS3よりも安いという。
一同 ほ～。
伊藤 S3 から Glacierに入れると当然そっちの方が割安だけど、Glacierを使わないで、S3に生でログを書き込んでいるんだったら、BigQueryに突っ込んだほうが安いですね。SQLとかも解析できちゃうし。まぁ、スキーマを切るのが面倒くさいけど。
一同 なるほど～。
伊藤 BigQueryの欠点は、ドキュメントとかが少ない点かな。あと、他サービスと違ってGoogleはそれ単体でビジネスしてるわけじゃないから、現時点ではその辺あまり期待できないというか。stackoverflowに質問書き込むと中の人が答えてくれるみたいなのはあるけど、まあビジネス向けじゃないですね(笑) それからまだコミュニティが大きくなってないから、BigQueryのことを聞いて答えられる日本人はわずかしかいないというのがネックですかね。って、この話、シドニアにつながります？
一同 ここでもシドニアしばりか（笑）。
堀木 まったくつながらないっす（笑）。
筆者は機械音痴の完全文系人間ゆえに、エンジニアチームが展開する専門的な話は、正直ちんぷんかんぷんだった。ビッグデータを扱う際に使用するツールやら、クラウドサービスやらといったことに関する知識もほとんど（というか、まったくといっていいほど）ない。
しかしながら、横で話を聞いていて、いっさい退屈することはなかった。なぜなら、作業の効率化を図るうえで必要な要素、個と集団それぞれに求められる姿勢、新しいものに対する接し方と扱い方等々は、いかなる業界でも、どんな職場でも、時代背景やその場を取り巻く状況を鑑みつつ、熟慮すべき共通事案だからだ。これを怠っていては、チームや企業は前には進めない。
- 個の力は重要ながらも個に頼りすぎてはいけない
- 組織が大きくなるほどチームワークが必要
- 人やモノには必ず長所と短所がある
- 新たな“道具”に対する理解を深めて自分（チーム）に合うものを
彼らの話からは、基本かつ重要なポイントをいくつもくみ取ることができた。「うんうん」「なるほど」と頷ける話ばかりだった。指示を出す側と出される側。リーダーとメンバー。お互いの特性を高いレベルで理解することにより、チームは機能し、成長していく―――。つまりは、そういうことなのだろう。
トップエンジニアたちによる激論は、このあとさらに熱を帯びていった。話題は、スタートアップ企業のエンジニアの間に広く浸透しているリモートワークへ。その模様は、次回のPart3でお届けしようと思う。
告知
Tokyo Otaku Mode ではアニメ大好きなエンジニアを募集しています。ご興味がありましたら、こちらからご応募ください。
