「第4回 CodeIQ感謝祭 CodeIQ夏の陣」参加レポート

概要

• セミナー名: 第4回CodeIQ感謝祭「CodeIQ夏の陣」
• 日時: 2016/07/16 (土) 13:00 - 19:30
• 場所: グラントウキョウサウスタワー（東京都千代田区丸の内1-9-2）
• ハッシュタグ: #codeiq39
• ATND URL: https://atnd.org/events/79187
• 参加費無料
• 後日、CodeIQ MAGAZINE にてレポート記事が投稿されるとのこと

基調講演: エンジニアサバイバル

登壇者

• まつもとゆきひろ さん
  • Ruby の開発者
  • Rubyアソシエーション理事長
  • ネットワーク応用通信研究所
  • 楽天技術研究所のフェロー
  • 米Heroku社のチーフアーキテクト
• Twitter ID: @yukihiro_matz

概要

• エンジニアとして幸せになるにはどうすれば良いか, を三題噺の形式で紹介

発表内容

1. 格差社会

• 「格差」をポジティブに考え、自分自身を向上させましょう

• 「格差」から生まれるネガティブな感情: 「上の人が妬ましい」「上の人を引き摺り下ろそう」

  • ⇒ マスコミ・政治家は格差を無くそう、と声を上げている
  • ⇒ 下の人を支援するのは良いこと。でも、上の人を下げる行為を「格差解消」として上手く化粧しているように思う

• 「格差」から生まれるポジティブな感情: アメリカンドリーム

  • ⇒ 頑張った人は良いポジションに就く、ということ
  • ⇒ 向上心が生まれる

• 向上するために

  1. ルールを理解する
  2. 運
     • 誰かは宝くじに当たる。でもあなたには当たらない
     • ⇒ 運で勝負しては駄目

• まつもとさんが「当たった」ときの話

  • ネット懸賞に沢山応募した
    • ⇒ スパムメールが沢山くるようになった
    • ⇒ でも PC が当たった
    • ⇒ でも、勝ったというのは違う
  • 車をガードレールに当ててしまった

2. 能力と収入の関係

• 収入のある人は必ずしも能力が高いとは限らない

• 例: 年収1億円の人と年収500万円の人

  • 1億円は500万円の20倍。でも、能力も20倍なのか、というとそうではないはず

• 仮説1: 能力は年収の対数に比例する?

  • log(20) ≒ 1.3
    • ⇒ 能力が1.3倍なら20倍の年収をもらえる
    • ⇒ 1.3倍なら頑張れそうな気がする

• 仮説2: 能力と年収は無関係?

  • 年収を高める要素は評価と成果
    • ⇒ 能力だけでは決まらない
    • ⇒ 知識、経験、コネクション、信頼、知名度も年収を高める要因になっている

• 自分の持っているものを棚卸しして、他の人と差別化しましょう

  • ⇒ 自分の評価を高める
  • ⇒ 幸せに一歩近づく

3. ゲームに勝つために

• 柔軟な発想でルールを解釈しましょう

• 現実はハードモード

  • 固定のゴールが無い
    • ゲームならドラゴンを倒せ、など明確に決められている
  • ルール・達成度合いを教えてもらえない
  • 攻略本が無い
    • ビジネス本はあるけど、読んでも役に立たない
      • ⇒ ビジネス本は成功した人が成功した後に書いたもの
      • ⇒ その人が成功した時とは状況が異なるので、書いてあった通りにやっても成功するとは限らない

• 30年前に行われた、木村泉 先生 (東工大の教授) の講演の紹介

  • 以下のルールのゲームを行った
    1. パンチカードとホチキスを使って、できるだけ高い構造物を作る
    2. パンチカード、ホチキス以外は使っては駄目 (風船で吊るすのは駄目)
    3. 構造物は自重を支えること
    4. 床からの高さを測ります
    5. 測定前にピンポン球をぶつけます (球をぶつけたあとに倒れないよう、耐久性を持たせる必要がある)
    6. 構造物を壁に立てかけるのは OK (壁で自重を支えるので)
  • 当時、まつもとさんのチームは 3m の構造物を作って優勝した
    • カードを筒状にして構造物を作った
  • だが、過去に 15m の構造物を作ったチームがいたらしい
    • その人達は、階段にカードを並べたらしい
    • ⇒ ルール上、壁に立てかけて OK なので、階段に置くのも OK (階段で自重を支えるので)
  • 我々はルールを聞いて構造物を立てなければならない、と思い込まされていた
    • ⇒ 現実の本当のルールは何かを見極めなくてはならない、という教訓を得た

4. エンジニアサバイバル

• 30年前、エンジニアとしてどう生き残るかを考える必要は無かった

  • 会社が社員教育を行って、保険・年金の面倒も見てくれた
  • 今は運だけでは生き残れない時代

• 必要なのは目標設定・ルールの理解・問題解決

  • ⇒ 問題解決はエンジニアの本質
  • ⇒ 達成したいこと (お客さんの要望で業務改善ソフトを作る、社内でスクリプトを組む、など) があってソフトウェアを作る
  • ⇒ デバッグも問題解決

• エンジニアの活動≒問題解決

  • 生産性を向上させましょう
    • 安く、早く、価値を提供する
  • ソフトウェアは社会の生産性を上げる
    • 生産性が高いと色々な問題が解決する
  • 変化を嫌う人たちがいる (static おじさん、保守派な人たち)
    • でも、ソフトウェアは同じことを繰り返しては駄目
    • ずっと同じアプローチで課題を解決しようとするのは、生産性が低い

• 許可を求めるな。謝罪せよ

  • 「やってもいいですか?」と上司に聞いては駄目

    • ⇒ 上司としてはリスクがあることをさせられないので、断らざるを得ない
    • ⇒ 勝手にやって成功してから上司に報告する

  • 過去にまつもとさんが6ヶ月でアプリを作って、と言われたときのエピソード

    • まつもとさんはボスに許可を取らず、最初の4ヶ月はライブラリの整備をして、その後1ヶ月でアプリを作り上げた
    • 最初にボスに許可をとろうとしたら、駄目と言われたと思う。勝手にやってよかった
    • 勝てば官軍

• 組織が生産性・モチベーションを高めることに積極的でないなら見限って良い

  • 転職しましょう

まとめ

1. ゴールを設定する

• 何になりたいのか、何を達成したいのか

1. ルールを理解する
2. 本当のルールを把握する

• ソリューションはこれだ! とすぐに飛びつかない
• ベターな方法を探しましょう

1. 問題解決
2. 大局を見失わない

• 勉強・技術は大事だが、局所的にならないように

Microsoft Channel 9 告知タイム

概要

• 動画で Channel 9 の紹介が行われた
• Channel 9 はTech系イベント・セミナーなどの動画コミュニティサイト

内容

• Channlel 9 で公開されている、業界の人に聞いてみた! ゲーム視点での Windows と開発環境 というシリーズものの動画を、10分程度に要約してまとめた動画を視聴
• 司会の喜屋武ちあきさんが、CodeIQ MAGAZINE で上記動画のレビューをした

パネルディスカッション

登壇者

• まつもとゆきひろ さん
• 伊藤直也 さん (株式会社一休 CTO)
• 増井雄一郎 さん (株式会社トレタ CTO)
• 白石俊平 さん (株式会社オープンウェブ・テクノロジー CEO)

概要

• テーマ:

  • キャリア、技術のキャッチアップ、マネジメント、エンジニアの方向性etc…「どこでも必要とされるエンジニア」になるには？

• リスト から議題を選び、ディスカッションをする形式で進行

内容

技術のキャッチアップはどうしてますか?

• (増井さん) 最新技術は追ってない

  • ⇒ Facebook とか、 Twitter で流れてきたのを見ている
  • ⇒ やりたい事があったとき、その都度周辺技術を調べている

• (白石さん) 放っておいても情報のシャワーを浴びれるように TechFeed を作った

  • ⇒ イベントの主催など一つのことをやってると他のことが疎かになるので

• (まつもとさん) ニーズがあったら見る

  • ⇒ 今、取り組んでいる問題を、他ではどうやって解決しているか、という観点で見る
  • ⇒ その技術がどんな目的で作られて、仕様はどうなっているかを見るけど、それより先は見ない
  • ⇒ 最新技術を追いかける必要は無い。でも、解決したい課題があったとき、必要に応じて調べるべき

• 最新技術を追っているかどうかという観点で、採用面接に来る人をどう見てますか?

  • (伊藤さん) 最新技術を追っているかどうか、は重要視していない

    • ⇒ 例えば、「C# が好きだそうですが、何でですか?」 ということを聞く
    • ⇒ ここで、C# しか知らないから好きというのは困るが、他の言語と比較して～～だから好き、とかなら良い

  • (白石さん) 今、何がどこまで出来るのかを開発の観点で持っているのが良い

    • ⇒ 最新技術でイノベーティブなものは実はそんなに無い。生産性を上げるのは多い

勉強会は是か非か

• (白石さん) 勉強会を2週間に1回開催していた。でも勉強会は無駄、という批判があった

  • ⇒ (伊藤さん) エンジニアで年収4ケタってどうやったらなれるの? の記事で、年収4ケタの Kaizen Platform のエンジニアの方がスーパー出来る人で、「勉強会に出るヒマがあるなら勉強しろ」という話をしてましたね

• (伊藤さん) 勉強会の意味はある

  • ⇒ 勉強会に出ると、自分の相対的なレベルが分かる
  • ⇒ 自分が世の中の水準でどこにマッピングされるのかが分かる

• (白石さん) 自分の興味に火をつけるために勉強会に出た

  • ⇒ React は見て面白いと思った

• (増井さん) オープンソースに contribute して自分の力を計る方法もある。勉強会に行かなくても良いのではないか

• (伊藤さん) 勉強会で話すのは勇気が要りますよね

  • ⇒ (白石さん) 学生に LT をやってもらった
    • ⇒ 最初はすごく緊張していたが、就職活動のときにそのことを話したらウケて内定をもらったらしい

スマートフォンアプリ開発における共創的な開発チーム

• (伊藤さん) FRIL のエンジニアの人が、アプリを作る際にエンジニアとデザイナーがどのように共同作業をしているか、という記事を書いた

  • ⇒ FRIL ではプロトタイピング合宿、というのをやっている
    • ⇒ エンジニアはエレガントなものを作る一方、プロデューサーは目的に対して一直線なデザインにする
    • ⇒ 異なる視点を持った人たちに共同作業してもらい、共創的なチームを作るのが狙い
    • ⇒ 合宿ではペーパープロトタイピング、他社のアプリのデザインを参考にしたりする

• (白石さん) 職種間の障壁は無くしたい

  • ⇒ 最近は技術の敷居が下がっていて、他の事をする余裕が出てくるようになった
    • ⇒ エンジニアはデザインもやるようになった
    • ⇒ デザイナーはエンジニアリングもやるようになった

エンジニアのキャリアについて

• (伊藤さん) 会場にいる人に聞きますが、エンジニアじゃないこともやってみたい人はどれくらいいますか?

  • ⇒ 2割くらい

• (伊藤さん) マネージメント・マーケティングをやってみたい人は?

  • ⇒ 少ない

• (増井さん) 自分はマネジメントが出来ない

  • ⇒ 増井はこのままで良いのか? というミーティングが開かれたほど

• (白石さん) プロジェクトマネジメントをやっている

  • ⇒ 優先順位を重要視している

• (伊藤さん) マネージャをやることに対する誤解は、マネージャをやるとコードを書けなくなる、会議ばかり、ということ

  • ⇒ でも、マネージャになったらコードを書くな、とは言われない
  • ⇒ マネージャやりたくない、という先入観は捨てましょう

• (伊藤さん) 元マネージャのエンジニアの人がいた

  • ⇒ その人は海外のオフショアを経験。でも楽しくなくて辞めてしまった
  • ⇒ マネジメントも経験しているので、求めていることを理解できる。 1 言うと 10 わかる
  • ⇒ そういう意味で、マネジメントをやってみるのも悪くない

• 伊藤さんはコードを書いてますか?

  • ⇒ (伊藤さん) データ解析の基本のコードを書いている
    • ⇒ Fluentd, digdag をやっている
    • ⇒ コードはあまり書かない

勤勉さだけでは改善できない日本の低い労働生産性

• (増井さん) どうやって生産性を上げられるか、を考えるべき

  • ⇒ ゴールを設定するのは大事
  • ⇒ ルールを作ると生産性は落ちる

• (まつもとさん) 日本企業は生産性を重要視しない

  • ⇒ 残業、失敗しないことを評価、会議が多い
  • ⇒ これらが勤勉として評価されている

• (まつもとさん) 海外では、短い時間で仕事を仕上げると評価される

  • ⇒ 日本で「こんなに長い時間をかけて○○したんだよ～」と自慢げに言う人がいるが、海外の人からは格好悪いと思われる

SOFT SKILLS ソフトウェア開発者の人生マニュアル

• (伊藤さん) Hard Work 大事

  • ⇒ SOFT SKILLS の著者は20代の間にスタートアップのようにギュッと働いて早期退職。30代までダラダラ働いている人を出し抜く
  • ⇒ スパートかけるところでスパートをかけて、残った時間で家族と過ごす、など
  • ⇒ 生産性を追及し、他の人と差別化しましょう

• (伊藤さん) この本に Slack はチャットソフトは OFF にすべき、という話もあった

  • ⇒ (これに対し、会場から驚きの声が上がった)

• まつもとさんはこの考えには反対

  • ⇒ ゆとりを持つべき
  • ⇒ 無駄な時間は必要
  • ⇒ そうしないと新しい発想が生まれない

• (増井さん) 日本のスタートアップは特に無駄を切り詰めている

  • ⇒ PM として、機能を一個落とす/落とさない、で議論を行う
  • ⇒ 一方で、海外だと意外と雑で、あるサイトのボタンを押すだけでブラウザが落ちるようなバグがあったりした
  • ⇒ 抜くところを抜けるようになりたい

生産性と創造性は両立しない

• (まつもとさん) 仕事を半分の時間で終わらせて、残りの半分は遊ぶ。そうするといいものが出来る

• (伊藤さん) ゲーム会社の人は、ゲームパッケージをローンチした後、長期休暇をとる。その間にハワイに行ったり

  • ⇒ その間に新しいアイデアが浮かんだりしてる、とのこと

• (伊藤さん) 生産性だけを高めると駄目

  • ⇒ どういうところに投資するか、が大事
  • ⇒ (まつもとさん) 生産性を上げて余分な時間を作って遊ぶ

• (伊藤さん) 3～4人ぶらぶらしてるエンジニアがいるほうが健全

  • ⇒ この人たちをつかまえて「ちょっと速く動くように直して」と頼んだりできる

まとめ

• 結局、エンジニアとしてキャリアアップするにはどうすればいいんですか?
  • ⇒ (伊藤さん) わからない (笑)
  • ⇒ (まつもとさん) 市場価値を高める。稀少価値を高める

基調講演: レンジでチンする機械学習

登壇者

• シバタ アキラさん
  • データサイエンティスト, DataRobot Inc.
• Twitter ID: @madyagi

概要

• 人工知能技術のこれから
• エンジニアはどう関わるのか

発表内容

人工知能の概要

• ディープラーニングが画像認識の領域で注目を浴びた

  • 人間を置き換えられるのでは?
  • 人工知能 ⊃ 機械学習 ⊃ ディープラーニング

• 色々な問題を解けるようになった

  • 予測、回帰、レコメンデーション、クラスタリング

• 広くビジネスに応用されている

  • 金融 (貸し倒れする確率など)、保険 (人が病気にかかる確率など)、マーケティング、スポーツなど

• 今後、パターン認識技術が誰でも使えるような時代が来る

DataRobot の紹介

• Top Kaggler が沢山いる

  • Kaggle は簡単に説明すると人工知能のオンラインコンテストを開いているサイト
    • 例1: 運転手の顔写真の中から、集中していない人の顔を判定してください
      • ⇒ 運転中の事故防止に応用
    • 例2: 売り上げ履歴から今後パンがどれくらい売れるか予測してください

• DataRobot のデモ

  • Lending Club 向けにモデルを作成するデモを実施

    • ⇒ Lending Club は、お金を借りたい人と貸す人をマッチングするサイト
    • ⇒ 借りる人のデータ (家を持ってるか, 職業, 収入, 結婚しているか, 過去の貸し倒れの有無, etc.) を基に、その人が貸し倒れする確率を計算するモデルを作成

  • デモの手順

    1. データを Webサイトにアップロード
    2. プロジェクトを作成
       • ⇒ 各変数が見やすくカテゴリ分けされるようになる
    3. 「何を予測?」 の入力フォームに「貸し倒れ」 を入力
       • ⇒ 15% と表示された
    4. 「開始」ボタンを押すと各変数が貸し倒れ率にどれくらい影響するかを表示
       • ⇒ データ項目「グレード」「サブグレード」が貸し倒れ率に大きく影響する、と表示された
    5. モデルを構築には、あらゆるアルゴリズム (RandomForest, SVN, など 20種類以上) をそれぞれ実行している
       • ⇒ 本来ならそれぞれのアルゴリズムを実装したり、ライブラリを探したり、といったことが必要だが、DataRobot が代わりににモデルを作ってくれる
    6. API の形で自社製品に組み込むことが可能
       • ⇒ 「Deploy Model」ボタンを押すだけで、API として公開され、使えるようになる

• 皆が AI を使えるようになるとどうなるか

  • ⇒ 専門家でない人もできるので、多様なアイデアが出てくるようになる
  • ⇒ すごいインパクトが起きる

今後求められるスキル

1. 取れるデータを取っていくのではなく、どんなデータを取っていくべきか、の戦略
2. モデルの精度が落ちているかどうかのモニタリング
3. 現場の問題解決

• AI の結果から具体的な提案に落とし込み、問題解決につなげる