楽天テクノロジーカンファレンス 2009 私的不完全議事録 【rtc2009】

IT

10 月 24 日に、品川シーサイド楽天タワーにて開催された「楽天テクノロジーカンファレンス 2009 〜集まれ! モノヅクリスト〜」に出席してきました。いつものように、可能な限り議事録を取りましたので、ここに公開します。

拾えなかった発言、うまくまとめられなかったので省略した部分などはたくさんあります。不正確な内容や事実と反する記述、誤字脱字などがありましたら、この記事のコメント欄やブックマークコメントにて教えていただければと思います。

また、このような有意義なカンファレンスを開催してくださった楽天株式会社の開発部の皆さんに、この場を借りてお礼を申し上げます。ありがとうございました。



目次

基調講演 (三木谷 浩史氏)

  • 今日は 670 人のエントリー
  • 技術者の交流、技術の発展に寄与したいという趣旨で開催している

技術への思いと取り組み

  • 楽天市場 1997 年オープン
  • 店舗数 3 万
  • 商品数 4 千万点
  • 流通総額 7300 億円
  • 会員数 6 千万人
  • 編集権を店舗に与えるビジネスコンセプトにブレイクスルーがあったのではと思う
  • アプリケーションをサーバーに置くことで改善ができる。よって、すべてのものは自社開発しないといけない。当時は多少時間がかかっても自分たちで作ろうとしていた
  • 現在、38 のビジネスがある。ブランドビジネスの共通化でマーケティングシナジーを図っている
  • システムのプラットフォームを共通化し、いかにして効率を上げるかが重要だと思う
  • 楽天グループはインターネット企業 8 位だが、上位にいる企業の中で唯一の日本発の企業

ネットが未来を変えていく

  • 民主党政権のマニフェストで IT 系についての言及がなかったのが残念
  • 根本的に人間の生活、経済学までもがネットによって変わってくる。通貨や国までも変わっていく。教育も医療も
  • そうなったときに、社会の雇用、国のあり方はどうあるべきか、真剣な議論が必要。米国にはそのようなシンクタンクがあるが、日本にはない
  • 楽天は、ものを買うことの意味を真剣に考えてきた。Shopping is Communication! + Communication is Entertainment! = Shopping is Entertainment!
  • ネットショッピングは究極の対面販売
  • 販売者に編集権を与えた
  • 最初はチンケなサービスでもいい。それをいかに速いスピードでユーザーの動向等をとらえながら改善していくかがサービスの成功に関わる
  • インターネットが常識を変える
  • 小さな農家やブティック、メーカーがネット上で直接販売することは以前は考えられなかったが、楽天はそれを実現してきた
  • 好き嫌いはあるかと思うが、一店舗当たりの情報量が多い。ものを買うというのは、安いから、機能がいいから、ということだけではない

ビジネスモデルの話

  • e-Commerce における違い
    • C to C …… eBay
    • B to C …… Amazon
    • B to B to C …… 楽天
  • ビジネスモデルにおける違い
    • Yahoo = 広告メディア
    • Google = サーチ×キーワード広告
    • 楽天 = ネットによる流通×金融の革命
  • 広告のマーケット規模は 7 兆円、うち EC のシェアは 7000 億円
  • 小売流通のマーケット規模は 176 兆円、うち EC のシェアは 2.5 兆円
  • 楽天は流通を根本から変える
  • 日本全国をエンパワーメント
    • 商圏に制限なし
    • ロングテール

      →インターネットは、地方経済の活性化のための重要なツール
    • 技術に明るくない人に対する人的なサポート
    • 開発拠点の展開……東京→宮城→大阪→北海道→福岡
    • 営業拠点を作ると売り上げが伸びる
  • データベースによるユーザーごとのサービス
    • 楽天の多様なデータを集約、一人一人のユーザに応じたサービスの実現
    • 「楽天スーパー DB」に情報が集約されている。これを分析し、利用
    • 楽天技術研究所による高度なレコメンド機能
    • 根幹部分なので独自開発で
  • 金融を含めた経済圏によるトータルサービス
  • 国際展開も進行。世界をネットで変えていく
    • アメリカ(LinkShare)・タイ(TARAD.com が資本参加)・台湾
    • 台湾楽天市場は日本の立ち上げ時を上回る成長を遂げている
    • 会社の技術力、文化、オペレーションを利用して中長期的に勝つのが戦略
    • 楽天は立ち上がりは緩やかだが天井がなかなか来ない
  • 国際配送事業の拡大

テクノロジーが未来を変えていく



特別講演: 楽天の中のわたしと勉強会 (よしおか ひろたか氏)

自己紹介

楽天テクノロジーカンファレンスのあゆみ

  • 2007 年……「つきぬけろ」。楽天 10 周年、創業からの事業を支えた技術の紹介
  • 2008 年……「広がる」。OSS コミュニティが協力、コミュニティセッション
  • 2009 年……「集まれ」。エンジニアを元気に、より参加型のお祭りイベントに

楽天市場・ブックスの規模感

  • 注文件数 2908 万件(32 万件強/日、13400 件/時) ※2009 年度第 2 四半期
  • 流通総額 1944 億円(20 億円強/日、9000 万円/時) ※2009 年度第 2 四半期
  • 日本最大規模の EC サイト
  • 99% の稼働率だと月に 7 時間分ダウンしている計算。損失はいくら?
  • 商品数 4200 万点
  • サーバーは数千台規模、大型サーバーも
  • ハイブリッドなシステム
  • 文化の衝突
  • 組織の限界
    • 組織が肥大化すると、蛸壺化する。横串は言うほど簡単ではない
    • 対立ではなく文化の融合が必要
    • そこで社内コミュニティ
  • 社内コミュニティ
    • コミュニティ・オブ・プラクティス
    • 組織は縦割り、プロジェクトは横串
    • 社にコミュニティは縦でも横でもない
  • 勉強会の隆盛──毎月 300 件 (IT 勉強会カレンダーによる)
  • 主催者が個人的興味の延長で開催していて、ボランティアによって運営。
  • 無料ないしは廉価
  • 事例: カーネル読書会
  • 楽天社内コミュニティ
    • ジャングル
    • 勉強会(社内・社外)
    • RTC 実行委員会
    • クリーンナップ大作戦 (ゴミ拾い)
    • ランチ (カフェテリアを利用したカジュアルなミーティング)
  • オープンイノベーションの時代
    • 社外に価値の原産を求めざるを得ない
    • 会社に閉じこもってはいけない
    • コミュニティ的なノリ
  • 技術は会社のものではない
  • 日本には Google や Amazon のような Web 2.0 の覇者はいないが、Web 企業はたくさんある
  • それぞれの会社の技術者は勉強会で繋がっていて、価値観を共有している
  • 開発者の皆さんへ
    • 解ける問題ではなく、解くべき問題を解こう
    • 楽天には解くべき問題がいっぱいある
    • それはコミュニティの問題でもある
  • わたしのミッション = 楽天の芸風を変える
    • 開発者コミュニティを醸成することによって、よりオープンに、アジャイルに、スケーラブルに
    • 開発者がもっともっと元気になったら素敵だ。心に火をともしに行きます
  • Q&A
    • 楽天芸風を変えるとあったが、具体的な問題は。どうやって変えるのか
    現場にいるエンジニアが外でオープンに議論できるようになると嬉しい。外で発表している楽天のエンジニアはそう多くない。PHP の安藤さんなど、楽天からもとがったエンジニアが少しずつ出てきている。生々しい話をみんなで共有できれば、楽天のみならず開発コミュニティにとってもプラスになる。そういう人たちを励ますのが私の役目。
    よりオープンにアジャイルに開発して技術を共有するという面で、知財や特許など、資産についての考え方は。
    サービスそのものがオープンになるとは考えにくい。むしろ基盤(PHP や Linux など)がオープンになる。それらはコミュニティに貢献するほうが、バグがすぐ直るなど、実利にかなり通じる。基盤系のオープンソースのコミュニティにコントリビュートすることは会社の利害と矛盾しない。楽天のサービスを外部に出すのは今は考えにくい。


日本最大の Rails サイト、クックパッドのものづくり (橋本 健太氏)

クックパッドとは

  • ミッション……「毎日の料理を楽しみにすることで心からの笑顔を増やす」

cookpad.com とは

  • 1998 年オープン
  • ミッション……「毎日の料理を楽しみにすることで、心からの笑顔を増やす」ウェブサイト
  • 世界で一番! 生活に役立つサイト作り

cookpad.com の使い方

  • おいしいものができたとき「レシピをのせる」
    • レシピを作って整理
    • みんなに公開
  • おいしいものを食べたいとき「レシピをさがす」
    • 63 万品のレシピから、今日食べたいものを探す
    • 作った料理の写真をレシピの作者さんに報告することも

cookpad.com の規模

  • 月刊ユーザー数 770 万人 (利用者の 9 割が女性)
    • Rails サイト中、世界9位
  • 月間 3.5 億 PV(PC)、携帯からもほぼ同数のアクセス
  • 登録レシピ数 63 万点

cookpad.com のトラフィック

  • 生活に密着したサイト
    • 16〜18 時がピーク
    • 秋からバレンタインにかけてトラフィックが伸びる

クックパッドのものづくり

Best なことに集中する

  • 「Better なこと」「やった方がいいこと」は、やらない
  • Best なことを見つけるための 3 つの輪
    • 「やりたい」──情熱を持ってとりくめること
    • 「とくい」──世界で一番になれること
    • 「やるべき」──儲かること
  • この 3 つの輪の共通点にフォーカスしているか?

ユーザの欲求に基づいたゴール設定

  • EOGS (Emoton Oriented Goal Setting)
    • そのサービスに関わるキャストをたてる
    • キャストごとの疑いようのない欲求を理解
    • 解決方法を探す
    • すべての解決方法を実現する方法を実行

3 分割の法則

  • スケジュールを決めるときの法則
  • サービス完成までの時間にやるべきコト
    • 設計
    • 開発
    • 質を高める
  • 3 週間でサービスインするならば、1 週間の開発でできるように設計する

ものづくり 3 原則

  • 無言実行
    • 公開前にサービスについての説明をしない
      • サービスを言葉で説明することはできない
      • 告知するメリットがない
  • 無言語化
    • 機能を言葉で説明しない
  • サービスに値段をつける
    • どんなサービスでもいくらの価値があるか値段をつけて考える
    • 無料だから大丈夫、という考えでは負ける。無料だからという理由だけでは使われない
    • ウェブ以外のサービスやものは価値に対して値段がついている

まとめ

  • 「毎日の料理を楽しみにすることで、心からの笑顔を増やす」
  • このためにテクノロジーの力を最大限に活かす
  • 自分の住みたい世界を作れるのがエンジニア




楽天市場を取り巻く状況と開発 (仲宗根 徹也氏)

自己紹介

  • 開発部所属
  • 楽天市場の開発・運用
  • 2003 年に Infoseek より転籍

楽天市場のシステム

  • いわゆる一般的な Web システム
  • 裏側
    • 巨大な RDB
    • 多くの機能が API 化
    • システムの依存関係はかなり複雑化している
  • Oracle WebLogic Server──100 以上のドメイン、約 900 インスタンス
  • SunFIre25K──64 インスタンス
  • 買い物かご処理量
    • 2008 年 12 月現在、月刊購入件数約 900 万件、ピークタイム 1000 件/分以上
    • 12 月にピークを迎える……お買い物マラソン(1 時間ごとに目玉商品が出る)

サービスへの要望

  • 店舗様
    • 使い勝手を改善してほしい
    • 商品ページにレビューを出したい
  • ユーザー様
    • こういう買い方はできないの?
  • さまざまなグループ事業
    • 楽天カードを持っていないユーザーをターゲットにバナー広告を出したい
    • API の仕様変更があるので対応してほしい
  • 社長
    • 「スピード! スピード! スピード!」

案件の特性

さまざまな要望に対して

  • 短いものは 1 週間、長くても 3 ヶ月くらいのプロジェクトを組んで実施
  • ブランチ分岐とマージの計画を立てたり、依存関係に注意しながら
  • 200 人くらいで回す

EC サイトについて

  • お金のやりとりが行われている場補
    • 1 分の障害停止が何百万円の売上機会損失に繋がる。一度エラーが出たら客は戻ってこない
    • 楽天の障害が店舗様の業績にも直結する
  • 運用
    • 障害対応訓練を定期的に
    • トラブル時の初動、体制構築は俊敏
    • リリースは計画的に
    • 手順作成、ダブルチェック、リハーサル
  • 開発、リリースサイクルのスピードが求められている→ビジネスチャンスを逃すわけにはいかない
  • 今後もこの複雑なシステム上で行うのは困難
  • 目指すべき姿
    • 開発生産性、保守性を高く
    • 適切なコストで──安くできるところは安く、守るべき所はしっかり守る
    • 安定稼働
    • 無限にスケール (流通 3 兆円でも耐える)
  • 教科書的ではない新しい取り組みや発想も重要
  • 複雑なものをシンプルに
  • やっていきたいこと
    • HTTP セッションを使わない買い物かご
      • Stateful な Web API を作ってみた (ロジック+セッション管理)
      • ライトな作りの UI アプリ
    • トランザクション範囲の見直し
      • 2-Phase Commit も見直してみれば不要
      • そもそも 2-Phase Commit や EJB を使わない前提で考えていきたい
    • DB に依存しないシステム
      • 整合性を確保でき、DB と非同期連携可能な Key-Value Store があれば可能
      • 海外での事例を参考にしたい

最後に

  • 楽天市場のシステムは、楽天の成長を支えた要素の一つ
  • 今のままでいいとは考えていないが、簡単に変えられるものでもない
  • 大規模システムを考えてみたい人は、ぜひ来てほしい



ネットワーク分散型フレームワーク ConView (こんぶ) (福田昌弘氏、シュティフ・ロマン氏)

ConView とは?

今までと何が違う?

  • ConView は同時に多数の API を呼び出せる
  • 結果としてモデルを小さく作ることができ、モデルが完全に独立する

開発動機

  • 楽天のアプリは、内部ではかなり API 化されている
  • Ajax / iframe の問題点
  • SEO 効果が高いと有名な某サイト(Amazon)を参考にした
  • 今までやらなかった理由

Key Technologies

技術的観点から

  • マルチタスクに特化したデザイン
  • テンプレートエンジンに依存しない
  • さまざまなサービスで使える(RPC、SOA、REST……)
  • 国際化に特に念頭に置いた設計

具体的に何ができる?

  • 複数サービスの組み合わせが容易
  • 応答速度の向上
  • Pylons フレームワークで楽天 API を 30 回叩く Python アプリと、同じことをする ConView アプリのデモ──画面が表示されるまでに前者は 15 秒、後者は 2 秒弱

まとめ

なんで ConView?

  • MVC-M = VC = Controller + View = ConView = こんぶ
  • アメリカ人に「かんぶ?」と言われたので「こんぶ」と命名



LinkShare Way (Anna Patithman 氏、Nathan Bryant 氏、Lana Adamov 氏、安藤 祐介氏)

自己紹介

  • 安藤氏、米リンクシェアの開発支援など

LinkShare 社

Introduction to Agile (Anna 氏)

  • 以前はウォーターフォールモデルを採用。仕様の取り違いがリリース後に発覚するなどの問題があった
  • アジャイルを取り入れる際にプロジェクトの作り方を変えた。ビジネス側、開発者、QA が同じチームで動く
  • ホワイトボード
    • 赤い紙……悪かったこと
    • 橙い紙……やってみたいこと
    • 緑い紙……よかったこと
    • 投票でやるべきこと、やめるべきことを決める
    • 決まった後は Wiki にドキュメント化
  • アジャイルに移行して不具合が初期の段階で 30% 見つかるようになり、$58,968 の節約


Increased Unit Test Coverage (Bryant 氏)

  • ある時点からユニットテストが義務づけられるようになった
  • 今までのコードの書き方ではユニットテストができなかったので、コードの書き方を変えた
  • なるべく小さな単位に分割
  • テストを書く
    • モックオブジェクトを使う(特に DB 問い合わせ)
      • テスト実行時間が早い
      • データがないのでテストできないという問題を排除
  • テストカバレッジの例
  • Before / After
  • 将来はもっとテストを増やしたい
  • さらに多くのコードをリファクタリングしてテスタビリティを上げたい


Quality Assurance (Lana 氏)

  • Affiliator Dashboard の例
    • レグレッションテストに 3 週間かかっていた
    • テストの自動化で改善
    • 3 週間→2 週間を目標に。1900 万円の削減を
    • オープンソースの Selenium を使用
      1. テストケースとレポジトリを整理──完了
      2. マルチブラウザへの対応 (Firefox 以外にも対応)──完了
      3. 失敗したテストからの復帰。テスト A が失敗しても B のテストは実行──現在対応中
      4. テストの結果をリポジトリに出力できるように──来年以降の対応予定


まとめ

  • リンクシェアでのアジャイルアプローチはまだまだ進化中
  • 個人的な感想では、日本ではツールの知名度が高まらないと使わないが、アメリカでは「こういうのがあるらしい、使ってみよう」という感じで使ってみる文化
  • 開発現場の国際化が絶賛継続中!



楽天 USA のアジャイル開発 (Sean Hussey 氏)

小さなチーム

  • 開発者 4 人、QA エンジニア 2 人、GUI デザイナ 1 人、DBA 1 人
  • ツールを使わないと回らない→アジャイル
  • Act quickly, Respond to change, Make decisions
  • 分析データがカギ
  • 典型的なウォーターフォールプロセスは 3〜12 ヶ月で 仕様策定→開発→QA→Deliver のサイクルを回す
  • アジャイルでは上記のサイクルを 1〜2 週間でこなす
  • ツールと技術
  • TDD
  • RightScale
    • Amazon EC2 上のサービス層
    • $0.1/時で 10 台のマシン。起動→45 分の負荷テスト→シャットダウンで、トータルコストは $1
  • Capistrano
    • 複数のリモートマシンに対してタスクを実行する Ruby のユーティリティ
    • "cap deploy" でデプロイでき、問題があれば "cap deploy:rollback" でロールバックできる
    • システム監視者が 2 人増えた気分
  • New Relic RPM
    • パフォーマンス監視
    • リリースごとにファンクション単位でパフォーマンスを見ることができるのが大きい
  • Hoptoad
  • 小さなチームが開発者 5 人、QA エンジニア 2 人、GUI デザイナ 1 人、DBA 1 人、Integration Specialist 1 人、システムアドミニストレータ 1 人、リリースエンジニア 1 人、システム監視者 2 人の系 15 人相当のチームになった気分に
  • 学んだこと
    • 自分の仕事を肩代わりしてくれるツール、よい判断材料を提供してくれるツールを用いる
    • フィードバックのサイクルを短縮するプロセスを採用する
    • 2 週間くらい使って、合わなかったらやめるくらいでよい


楽天エンジニアライフ (隈部 有希子氏)

自己紹介

  • アプリケーションエンジニア、サーバ/DB エンジニア
  • 2005 年 4 月入社で現在 5 年目
  • 開発経験なしで入社

開発部紹介

  • 楽天単体で 2,081 人、うち 3 分の 1 くらいが開発要員
  • エンジニアタイプ
    • プロフェッショナル型──大きめサービスのアプリケーションエンジニア
    • マルチサービス型──サーバ/DB エンジニア、一部のアプリケーションエンジニア
    • マルチジョブ型──小さめサービスのアプリケーションエンジニア

5 年間の歩み

いろいろやっててよかったこと

  • 身軽に動ける
  • 週 1 日分くらいコーディングできるので社内ツールを作った
    • リソースグラフ化ツール──3 ヶ月で完成
    • 情報共有掲示板──興味のあるフレームワークを使用して 2 ヶ月で完成

開発部紹介まとめ

  • 希望を出せば叶う
  • 極めるも広げるも自分次第

楽天ビジネスに見る超ミニマムなサービス開発体制

  • 決済代行機能開発プロジェクト (7 ヶ月)
  • 商談成立後にカードで決済できる機能
  • 社員 0.3 人(自分)、パートナースタッフ 2 名
  • 各種調整は担当を決めて個々で行う。全員プロジニア
  • コーディングフェーズに入ったら会議なし
  • 少人数だから開発リソースの仮コストを最小限に、他部署調整コストを最小限に



パネルディスカッション 〜CTO のから騒ぎ for the future〜

  • 仙石 浩明氏 (KLab 株式会社)
  • 藤本 真樹氏 (グリー株式会社)
  • 太田 一樹氏 (株式会社 Preferred Infrastructure)
  • 貝畑 政徳氏 (株式会社カヤック)
  • 笠谷 真也氏 (株式会社 BONNET)
  • モデレータ: 森 正弥氏

森  主旨……激動のインターネットで戦う CTO、エンジニアでもあり経営も意識。「CTO = 人柄×明暗×未来」を激しく放談できれば。ぶっちゃけ、何でもあり。重要なのは言ったもん勝ち。あと重要なのは、ナイスボケ。ナイスボケをいただいた CTO の方には、(テーブルの下から)黒いカラスコ人形をもれなくプレゼント。大事なのはボケる勇気(会場苦笑)。だからビールをご用意しておりますが、本来は勇気が必要になったらお飲みくださいと言おうとしていたのに、もう開けている(笑)。では、自己紹介を。

藤本  実名でがんばってます。30 歳、独身、彼女なし。グリー株式会社 CTO。決算発表前なので、あまり(いろいろ)言えないんで(笑)。Flare を作ってます。

笠谷  ここにいる中で唯一の「旧」 CTO、今は独立して BONNET をやってます。スタジオビッケというクッキー屋を妻とやっている。店があるわけでもなく、たまにイベントとかに出している。Selenium IDE、iPhone アプリの PocketGuitar (2008〜)などを作っている。

貝畑  株式会社カヤック CTO、12 年目の会社になる。去年は携帯事業部を立ち上げた。そろそろ漫画家になりたい。面白法人カヤックとして年間 130 程度のサービスをリリースしている。当たるのはそのうち 1、2 個だが、それを大事に育てている。本社は鎌倉なので、よかったら遊びにいらしてください。「コンチ」のメルマガは僕が書いている。

仙石  KLab 株式会社の仙石です。就職してから 16〜17 年。卒業してしばらくはベンチャーに縁がない生活(論文書き)。ある日突然転職することになり、2000 年に転職。気の向いたことにどんどんのめり込む性格。技術者が経営をやるのってどういうこと? という質問はまた後ほど。KLab を設立してから、どんどん仕事を捨てて自分を変えている(ピーターの法則に陥らないように)。部下が成長したらすべて任せてしまう。すべての仕事を部下に振り終えたら、私は CTO をやめる予定。早く育成しないと。

太田  Preferred Infrastructure の太田です。スライドを用意してないので、(スケッチブックを持って)僕を写してもらえませんかね?(会場笑い) PFI という分散型検索エンジン。今 24 歳で東大の M2 に在籍中。僕はツッコミのほうなので、仙石さんがボケたらツッコミたいのでがんばります。Twitter は @kzk_mover。

森  CTO に質問。CTO って何をする人? CIO とか CTO とかいろいろありますが、CTO とは? 普通の人が持ってる CTO のイメージって(戦国武将の鎧甲姿がスライドに)こういう感じでは。エンジニアでもあり経営も意識しないといけないのだが、CTO って何をしている?

藤本  グリーで 2005 年から働いているが、名刺に当初から CTO と書かれていた。「何をするんだろう?」って僕も思った。いろんな CTO に聞いて回った。ひとつ分かったのは、みんな言ってることが違うということ(会場笑い)。小さい会社だと開発全部を見る。大きい会社だと、会社のコア技術をどうやってお金に換えるかを考える。グリーで CTO の僕は、ウェブサービスはどういう技術をお金にするか、どういう人を採用するかを考える役割だと思う。

森  CTO をやっててうれしいことは。

藤本  最初は自分で手を動かしていたが、今はエンジニアが 40 人。何となく「こうやっていけばいいね」と話したらエンジニアが面白いものを作ったりする。そういう時が楽しい。

森  仙石さんは何をされているんですか?

仙石  ボケなくちゃいけませんか? 何もしてません(笑)。会社を興したときは何から何までやってました。プロマネ兼プログラマ兼システム管理者。社内でヘルプデスクをやる羽目になったり。年を経て人が増え、部下に自分がやってた仕事をどんどん任せた。次から次へと部下が成長していくので、私がやっていたことを部下ができるようになる。あるとき、「自分がデータセンターに行かなくても何とかなるな」と思い、仕事をどんどん捨てていった。これこそが CTO の役割なのかな、と思った。会社の中でやるべきこと、やったほうがいいことを新たに作って、明確にした上で部下に押しつける。そんな感じでやってきた。自分が今仕事をしているのはよろしくないことだ。一生懸命部下に押しつけるのが仕事だ。もうひとつ言わせてもらっていいですか? CTO っていうのは、「技術者にとっての社長」という役割を果たすべきではないのかな。技術者はビジネスに対して本音の所では興味が持てない。なので、社長に本当に心の底から共感できるかというと、微妙。そういう社員も多いんだろうな、そういうときにビジネスのことばかり言ってないで技術の話もすれば共感できるんじゃないか。

森  その話を深めたいが、本質的な話になるのでまた後ほど。次の質問。ソースコードは書いていますか? 仕事では?(全員挙手) CTO はソースコードを書く、と(会場笑い)。

仙石  バイナリを書くというのは?

森  ありだと思います。じゃあ、最近何を書かれていますか?

笠谷  最近は iPhone アプリを書いている。CTO 時代もソースコードを書いていた。自分で書いていないと気が済まない。本来は仕事をしない方がいいんでしょうが、どうしてもやりたいというところがあって離れられなかった。

森  どうしてか。離れないメリットとは。

笠谷  完全に離れると技術に疎くなるのと、書いてるのが楽しい。会社が大きくなってくるとそうも言っていられなくなる。仕事を押しつけるのではなく、エンジニアの興味を伸ばすようなお願いの仕方ができればいいなと悶々としていた。

森  論点の対立軸ができてしまいましたね。仙石さん?

仙石  10 人 CTO がいたら 10 とおりの CTO になるので、問題ないと思う。

貝畑  年間 100 以上のサービスを作っているので、単純にプログラマが足りない。誰もやりたくないコードを書かされることがある(会場笑い)。最近では「パンツ日記」(会場笑い)。全社員にクリエイターという肩書きを与えているので、役員と言えども書かないといけない。プレイングマネージャのようなことをしている。クリエイティブ力やアイディア力は優秀な社員に負けないように心がけている。

森  すごくやる気に満ちあふれた会社組織になっている気がするが。

貝畑  そうですかね?(笑) サービスを出すときに「それが全力なのか」という客観的判断ができるようにしてほしい。何でも作っていいというわけではなく、金になるのかという判断ができるようになってくれれば。

森  この業界やお仕事のワクワクするところは? ほかの業界にはないよねとか、ウチの会社はすごいとか。

太田  僕は 18 歳のときに、父に i アプリ搭載機種を買ってもらい、Java アプリを作って公開したら、いきなり 40 万ダウンロード。それまでネトゲをやっていたが、プログラミングにのめり込んでいった。普通の人から見るとプログラミングは魔法のように見えるそうだが、分かってしまえばサクサク書けるし、影響を与えられる範囲が大きい。300 万人、400 万人とか。

森  藤本さんがため息をついたので(笑)。

藤本  どこですか、「18 歳」ってとこですか? 30 歳以上の人に対して「ここイケてない」と思うところは。

太田  上の世代は輝いている人も輝いていない人もいる。輝いていない人を見たときのガッカリ感は相当なので、がんばろうと思う。僕は年上の人と付き合うのが好きで、同年代の友達はいない。

藤本  無難な答えで最高だと思います(会場笑い)。

森  あれは修羅場だったなという体験を。答えたい方から行こうかな。

太田  データセンターが火を噴いた話……(会場爆笑)。

藤本  データセンターにはお世話になっていると思うので──そういうのはありますよ、昨日もここ停電になりましたし(suno88 注: 楽天タワーや隣接するイオン品川シーサイドショッピングセンターなどが 23 日午前から 24 日未明まで停電していた)。ウェブアプリだとデータをメモリに書くことが多いので、データセンターが壊れたときにマズい(グリーは足跡がオンメモリ)。ヤフーは東西で完全冗長化しているという噂。いや、あれはホントに……(会場拍手)。

太田  そのときは陣頭指揮を執られた?

藤本  あのくらいの規模になると状況把握がそうとうしんどい。情報を集めるのに必死だった。都合よく言うと、あんまり覚えていない。一刻も早く忘れたい。忘れちゃいけないんだけど(笑)。

森  今の俺なら言える、というのは。仙石さん笑ってるけど。

仙石  会社立ち上げてるんだからいろいろありますよね。でも言えません。

森  そこから得た教訓は。

仙石  何からでも教訓を得なければいけないというのは部下にいつも言っていること。──と話をそらしてみますけど。

森  貝畑さんがマイクに手をかけているので。

貝畑  とにかくリリースするのが早い者勝ちという感じでどんどんサービスをリリースして、サービスが大きくなっていくとデータセンターにデータを置いたりして。で、ある日プロンプトでコマンドを打っていたら、魔が差して顧客データを消してしまった。このままここで凍死しようかとも思ったが、でもこれで誰が死ぬわけでもないしなと思って復活した。部下が失敗しても、これで死ぬわけじゃないんだからできることを精一杯やれと言っている。他の役員から「あいつはクビにする」と言われても、僕はその社員を守っている。

仙石  いい話だと思う。上が余裕をかまさないといかんなと思っていて、だから自分が仕事をしちゃいけないと思う。部下が SELECT の代わりに DELETE を発行して全データを消してくれて(笑)。その時はログから全レコードを再構成しました。すいません、自慢話で。

森  そういうときじゃないと身につかないスキルってあるんですよね。ではここでフェーズを変えます。「CTO に無茶振り」のコーナー。大喜利をやります。スケッチブックにいろいろ書いてもらいます。未来に向けた大喜利。出されたお題を即興で書いていただく。忘れちゃいけない、ナイスボケ。飲むなら今です。ではお題。

時は 20XX 年。国際クラウド連盟の成立、拡張現実開発協会(ARA)の躍進、絶滅危惧プログラミング言語(アレとかアレ)保護条約の成立等、一変してしまった未来の日本と世界。年老いた CTO のあなたは、無垢な目を向ける孫たちに向かって何と言った? ──何でしょうね、このピクリともしない空気は(笑)。

太田  (スケッチブックを見せる)「Ruby っていう言語がありまして…」(会場笑い)。

森  まつもとさん、コレ(カラスコ人形)あげられますかね?

まつもと  いいんじゃないですか。(壇上に上がって)僕が生きている間は Ruby はあってほしいですが、死んだ後はお好きに。言語は寿命が長いんで、COBOL も……。

太田  Ruby って書くか COBOL って書くかで迷ったんですよ(笑)。例えば COBOL は 50 年後にも使われているかもしれない。根本とか原典とかはいつの時代にも変わらないと思う。

森  来たついでにご質問は。

まつもと  技術者としての上がりとしての CTO ってどうですか?

仙石  CTO が上がりとは思っていない。

まつもと  キャリアパスの途中としての CTO は。

仙石  キャリアパスって全然意識していない。興味のあることをトコトンやって、飽きたらやめる。今は私が定義した CTO の道をドンドンやるって感じ。他の人は違うと思うが。

笠谷  「元」CTO ですが、僕はまだいろんなものを作ってダイレクトに反応を見たくて独立した。落ち着いて、いろんな技術が分かるようになってから経営者として CTO をやってみるというのもいいと思う。極端な話、プログラムが書けなくても CTO をやってもいいと思うが、僕はまだプログラムを書いていたい。

森  この話は後ほど触れます。

藤本  (スケッチブックを見せる)「もうクラウドじゃなくね?」っていうのが、今くらいからそろそろ誰かが言っててもいいかな。あと、この会社の人がいたらアレなんですが、(ページをめくって)「Google ってあったよね」。ひとつはこうなる可能性がありますし、もうひとつの可能性は「United States of Google」とかなってるかも(笑)。

笠谷  (スケッチブックを見せる)「昔、マウスというものがあってね…」。最近 Win7 でタッチパネルに対応したし、マウスじゃなくてもいいかも。

森  じゃあ何が来るんですかね。

笠谷  さっき(お題に) AR って書いてたじゃないですか。最終的に脳に繋がるのかな。動かさなくてもいいっていう感じになるのでは。

森  次のお題。おクスリ。あなたは、ある日、医者に処方された薬を飲みました。それは、何と、強気になる薬。その名も「ミキタニニナ〜ル(仮)」。大量に服用してしまった CTO のあなたは、興奮しながら、社員のみんなに「オレはエンジニアのみんなのために、××な会社を作るぜ!!」と言った。さあ、なんて言った? ここにミキタニニナ〜ルという薬がありますので、まずはこれを飲んでいただいて……。

仙石  (スケッチブックを見せる)「技術者の成長に一番役に立つ会社」。これは私のブログを見てる方にはつまらんという答えが返ってきそうですけど……。これ、クスリを飲まなくても常に言ってるんですけど。ミキタニニナ〜ルを飲んだら、三木谷さんのビジネスセンスが身についてほしい。

貝畑  (スケッチブックを見せる)「年収 1500 万保証」。ウチの会社では役員に対して給料アップを要求されたことがなく、こいつら何をモチベーションに働いてるんだろうと。家庭ができたり子供ができたりするとお金が必要になってきて、お金がないと家庭内に問題が起こってくる。すると仕事に集中できない。これくらいあれば自由にできるんじゃないかと。

森  いつやりますか?

貝畑  お金があればいつでも。

森  衣食足りて礼節を知るという言葉があるが。

貝畑  余計なことを考えてほしくないな、お金のことで悩むのは馬鹿らしいなって。

藤本  僕は結構、制限の中でこれをやってやるぜ、って思うこともあるじゃないですか。何かが足りてないときのほうがコーディングが進むこともあるが。

貝畑  コードを書くことと物欲は、僕は一致しない。新しいことをやろうと思うときは、お金のことを考えてやるのではない。

藤本  この業界は改善すべき問題がたくさんある。(スケッチブックを見せる)「開発男女比 1:1」(会場拍手)。以上です。

森  アイディアあります?

藤本  いや……これ、どうするんでしょうね(会場爆笑)。

仙石  開発の中で 1:1 にする必要は? 同じ会社の中で 1:1 であればいいのでは。

藤本  自分のチームが 1:1 だとハッピー。

仙石  企画者を自分のチームに入れるというのは。

藤本  それはアリだと思うが、僕はサーバーやインフラを見てるのでさらにハードルが高いかな。

太田  彼女とかとそういう話をしたいですか?

藤本  僕は別に彼女を作りたいと言ってるのではなくて(爆笑)。長い時間を過ごす場で男女どちらかしかいないのはおかしいんじゃないかと。

笠谷  (スケッチブックを見せる)「PC 会社に 1 台」でいいんじゃないかって。ひとりでコーディングしていることも多いので、じゃあ家でやってればいいんじゃない? 会社に来てるときはコードレビューとかで 1 台あればいいのかも。こういう会社があってもいいんじゃないかと思った。実際問題、いろいろ難しい面もあると思うが、集まっているのならコミュニケーションを取ることをしたほうがいいのではないかと思った。

森  環境の話、藤本さんの本能的な話(笑)があったが、それぞれ CTO としてどういう会社を作っていきたいかというのが浮かんできたと思う。真面目な質問で、一人ひとりのエンジニアはこれからどうあっていくべきだと思うか。若者からという意見が出たので(と太田氏に振る)。

太田  オープンソースの流行で技術がコモディティ化している。そういう時代が進んでいったら、例えばサーバー管理者がシステム構築までしてしまうだろう。そこでどういう違いを出していくのか。どうやって技術をお金に換えるか、会社を伸ばしていけるかということを考えられるスキルが必要。

藤本  一方でテクニカルな力を伸ばしたい技術者もいるが、そういう人は CTO には向かない。

太田  午後 5 時くらいに会社に来るのに、すごいコードを書く人もある。そういう人が普通の人と調整を取りながら進めていくのは難しくないか。

藤本  人が増えると、ルールがいるよね。すごい人は平均から外れるが、責任をまっとうしてよね、と。身の程を外れたら、説教だよね。

仙石  私の持論は「餅は餅屋」。技術とビジネスを考える人がいてもいいけど、24 時間技術のことだけを考える人がいて、24 時間ビジネスのことを考える人がいればいい。会社なんだから、役割分担しつつ進めていくのがいい会社だと思う。技術者はビジネスのことは考えなくていいから、みんなをアッと言わせることをやろうよ、と。

太田  アメリカでは 80 年代から、優秀な学生はコンピュータサイエンスに進まない。

仙石  隆盛があるので、みんながコンピュータサイエンスに行かなくてもいいのでは。ウェブの世界になって進歩が止まったという人もいるが、それでもいいんじゃない。

藤本  お互い(技術者と非技術者)どうやってリスペクトするのか。

仙石  自分ができないことをできる人を尊敬すればいい。ウチの会社はそうなっている。

藤本  エンジニアリングを追求していきたい人とはどういうコミュニケーションを?

仙石  週 1 の定例ミーティングで、私は会計の話をしている。技術者であっても、いろいろなことに興味を持ってほしい。できなくてもいいから。他の人が何をしているかは分かってほしいし、分からなければリスペクトできない。私も会計の素人だが、会計の話を延々としている。

貝畑  エンジニアにもレベルがある。ピンキリのキリのほうはそれでずっとはやっていけない。35 歳定年説に繋がるのかも。会社はそいつが一番力を発揮できることをやらせたがるか、本人にとってはルーチン化なので、本人のためになっているのだろうかと思う。僕は社員に言うのは、「言うとおりに作るな」。プログラムが分からない奴の企画どおりに作っているだけでは成長しないので、チャレンジしてみろと。会社からすれば損だが、本人の成長には繋がる。エンジニアの枠の中でやれることはたくさんあると思う。

笠谷  まずは好きなことを突き詰めていくのがいい。何か得意な部分を伸ばしていって、その分野では負けないという部分がないと厳しい。エンジニアに向いていない人もいると思う。例えば Rails アプリが得意で企画ができるとか、そういうのでないと厳しいと思う。

森  グローバルな話を考えたときには。

笠谷  最初に発表してから海外で先に反応があって、その後日本で流行ったというのが僕の作ったものには多い。最初から英語で発信した方がトクだと思う。ML にちょっとメールを投げればいいくらいの話だから、海外でも使えるものを作ったら英語で発信したほうがいい。

藤本  すごく同意。僕らはエンジニアで、コードを書くことができるので、オープンソースの世界ではコミットしてほしい。できることをやっていってほしい。自分で作るのでもいいし、すでにあるものにコミットするのもいい。そこで人の輪が広がり、自分のやるべきコトが見えるかもしれない。未経験の人は是非やってほしい。

森  会場の皆さんから質問をお受けします(と言って会場のよしおかひろたか氏にマイクを渡す)。

よしおか  手を挙げてないんですけど(笑)。20 年後の自分の姿はどう見えているか。

太田  44 歳?

仙石  私と同じ年齢です(笑)。

太田  コンピュータを始めてまだ 6 年しか経ってないので想像がつかない。こうなりたいというのをひとつひとつ吸収してカッコイイ大人になりたい。

会場質問者 1  今までやってきて、一技術者から CTO になったきっかけがあったら聞かせてほしい。

藤本  きっかけは転職。会社が変わったら CTO でした。自分の中で? 僕は素人だったときに、一度会社の開発の人にすごく怒られたことがあって、自分の振るまいが会社のみんなに迷惑をかけることがあるかということを実感した。怒ってくれる社員がいてよかった。

会場質問者 2  今後を見据えた上で、自分の部下や新卒 1 年生に、今後こういう風になるからちゃんとやっておけというのがあれば。それから、女性の開発者を増やすためにはどうするべきか。

貝畑  女性開発者を増やすには、婚活の一つに組み込んじゃえばいいと思う。プログラムを書ける女性は絶対にモテます、エンジニアに。ウチの会社は男女比 1:1 だが、女性プログラマは 0。プログラマは口下手なので、「プログラム勉強中です」っていう女の子がいたらみんな食いつく。5 年後 10 年後……基本、クリエーターであることはやめないと思う。考えることを諦めるな。考えずに開発するのは簡単だが、それでは成長しない。自分のポジションを見つけるスキルを身につける方が、エンジニアの技術を上げるより大切ではないか。開発にどっぷり時間をつぎ込んだときに、開発スタイルや次にやるべきコトが見えてくると思う。20 代の社員には厳しく言っている。

仙石  技術者という職種はすごく難しいと思う。誘惑がたくさんある。次から次へと新しい技術が出てくる。「ちょっと」Ruby を勉強しておこうか、って思うじゃないですか。いろんな言語が出てきて、何から何まで「ちょっと」勉強してみるというのがあまりにも多すぎるのでは。「Hello, world.」を表示させるだけのように、表層だけ学んで時間を浪費することが多すぎる。考えることが大事というのはまったく同感。どんな時代でも、考える力がすべて。どこまで深く考えられるか。知識を求めることに貪欲になりすぎるな。

森  最後に、CTO からの熱いメッセージを手短にお願いします。

太田  エンジニアというのは世界を変えられる。世の中を便利にしていけたらいいなと思う。

仙石  会社に対する不満がウェブで山ほど出てくるが、嫌々する仕事は成長に役立たない。嘘でもいいから「この仕事をやっててよかったな」と思ってほしい。どんな仕事でも好きでやってほしい。今の仕事を楽しむところから成長は出てくる。難しいですけどね。

貝畑  Apple には Engineer Driven という言葉があるが、どんなエンジニアでも偉いわけではなく、アーキテクト以外は偉くないらしい。会社の中で搾取されないように、やりたいことを本当にやってほしい。言ったとおりに作るな、作りたいものは土日に作れ。

笠谷  好きなことを突き詰めていくためには、好きじゃないことは人に押しつける。できるだけうまいこと人に振るなりして、自分の時間を作るほうがいい。

藤本  エンジニアは一人で勝負できることが多い。せっかくなので、会社でもがんばるし、世界で勝負できるようにオープンソースをやるとか、そういうことをして業界が楽しくなればいいなと思っている。

森  一緒にがんばっていきたいですよね。そういうことで、皆さん未来を一緒につくっていきましょう。