デブサミ関西2016

• 2016/09/16(金) ＠神戸国際会議場
• http://event.shoeisha.jp/devsumi/20160916/
• #devsumi
• 資料まとめ1,資料まとめ2

[基調講演] クラウドの発展とデベロッパーの役割について

• クラウドの発展
  • 非機能要件がコーディングできる
    • 今までは機能要件しかデーでィングできなかった
  • ITサービスの運営（企画→開発→運用という営み）がスピードアップ
    • アプリを書くことだけが早くなるのではない

---

• 「仕事の仕方」の違い
  • WF
    • やるべきことを終わるまでやる
  • アジャイル
    • 期限までに今やるべきことをやる

---

• モノリシックシステムの課題
  • 全体のリグレッションテスト
    • 開発スピードが遅くなる
• MSAの注意点
  • アプリ管理ではなくシステム管理
  • 設計指針ではなく結果論
  • 「MSAで再構築」は「愚」
    • MSAもDevOpsも今すぐに取り掛かれる。すこしずつ取り組んですこしずつ改善していく

---

• クラウド時代のデベロッパー
  • 機能要件だけでなく非機能要件もコーディング可能に
    • アプリとインフラは不可分に
  • システム開発からサービス運営に
    • 企画→開発→運用のあらゆるところでエンジニア能力が求められる
  • 技術そのものだけではなく「技術の使い方」のトレンドを意識する
  • 「何に最適な技術か」を理解する
  • 「ITがビジネスの最重要課題」なら「デベロッパーがビジネス活動の中心」にいるべき
    • デベロッパーにもビジネススキルが必須
      • コミュ力、プレゼン力、チームビルディング

一万人のエンジニアが集うオープンコミュニティから脳のような知能の創造を目指す

全脳アーキテクチャ・イニシアティブ
http://wba-initiative.org/

• 大人のAI
  • 理解できるので設計可能
    • 演繹推論
• 子供のAI
  • 理解できないので学習が必要
    • 帰納推論（機械学習）
    • 一定以上のリソースが必要
• 十分にデータを得られるタスクの範囲内であれば応用価値のある人間並みの性能をもつ帰納推論が可能に
• 特化型AI → 汎用人工知能（AGI: Artificial General Intelligence）
  • 転移学習
    • あるタスクから学んだ知識を他の他のタスクに転用、流用する

尼崎から世界へ！モノタロウの海外展開を支えるDevOps基盤

• ベンダー → 内製
  • 時代の変化に素早く対応
  • スピード感
  • 競争優位
• インフラはほぼすべてAWSに置き換えている
  • 海外ECサイトは全部AWS
• 国内ECサイトは週１リリース
  • 定例リリースのデメリット
    • リリース日がくるまでリリースできない → その機能が生み出す利益の機会損失

---

• 海外展開
  • 韓国に現地子会社
  • シンガポール、マレーシア、＋５カ国にECサイトを展開
• 目標を達成するための全体最適化
  • そのためのDevOps
• 保守・運用にかける時間を減らす
  • GoogleのBotのアクセス（280万ページ）によりサイトが瞬殺(ﾟдﾟ)!
    • 対策：Auto Scale
• 開発スピードを上げる
  • 「○○さんに聞けば分かる」→ ボトルネック、長老のような人（バッドノウハウに詳しい人）
    • 対策：Docker導入
      • MW、アプリのセットアッププロセスをDockerの中に閉じ込める
      • Docker Machine
      • Amazon ECS、ECR

ビジネスにおける機械学習の現場

• CRISP-DMプロセス
• 主題は時間不足で詳しく触れられず

生涯エンジニアというマインドを活かしてYahoo!天気アプリを成長させたPM手法

• 第１次 Yahoo! 時代
  • 「内のリソース」の利用が魅力的なサービスづくりの近道
  • 「外の変化」に危機感を感じ始めた

---

• 任天堂 時代
  • 新人として、新たな技術要素の経験
  • Yahoo!時代の経験は大いに活かせた
  • 自信（＝生涯エンジニアとして生きたい自分への）がついた

---

• 第２次 Yahoo! 時代
  • 天気アプリのPM
  • 動機づけ
    • 天気には興味がなかったが...
    • ユーザに役立つ「道具（ツール）」をつくる
  • 作品作りの軸を決める
    • 目標（将来悩んだときに立ち戻れるポイント）が定まる
  • 「作品」という表現へのこだわり
    • エンジニア＝職人であれ
  • あくまで提供者が自信を持って作品をつくるべき
    • 自信と責任
  • プロジェクトチーム
    • 面で捉える
      • メンバのスキルに応じて担当領域
      • PM → スキマの領域を見つけフォローする

SIerの中で技術を大切にする生き方とその舞台裏

• マネージャーか技術者か
  • 指示する人ではなく、（作業して）「何とかする人」でありたかった
  • 「指示されて作る」から脱却しないといけない
  • 自分の存在が必要不可欠（キーマン）であると認識させる
  • 管理するよりもコードを書いて欲しいと思われる存在にならなければならない
  • 「みんなが書けるPGを自分も書ける」では勝負にならない
  • 技術者は説明責任を果たさなければいけない局面がかならずある
    • コミュ力、プレゼン力、リーダーシップ
• アプリケーションか？基盤か？
  • エンタープライズのPJでは業務を知っている人のほうが評価が高い
    • プログラムから業務を知る
    • データモデルから業務を知る
• 自分の影響力が最大限になるような仕事のほうが楽しいし、やりがいがある
• 成功に対して、自分の技術を最大限に貢献できる方法は？
• 報酬と責任はセットである
• どうありたいか？を明確にする
• 居場所を作る
  • 課題×得意な技術（＝ニーズ×やりたいこと）
• 仕事が難しくないと
  • 成果に差がつかない
  • 達成感が得られない
• やりたいことができるように
  • できる場所に行く
  • できるように今いる場所を変える
• 仕事で失敗すると自分が許せない
  • これでいいやと思うようになったら、終わり