なみひらブログ

学んだことを日々記録する。~ since 2012/06/24 ~

「Developers Summit 2017(2日目)」に行ってきました

毎年恒例のデブサミへ参加したので、レポートを書いておきます。
event.shoeisha.jp

開催概要

  • 日時
    • 1日目:2017/02/17(木)10:00-18:30 ※一日目は不参加
    • 2日目:2017/02/17(金)10:00-18:30
  • 場所
  • 主催
  • 参加者数
    • 約2000人?
    • 年齢層が広く感じた
  • テーマ
    • エンジニアとして生きる、技術の先にある現実に踏み出す
  • 発表資料
    • 参加者アンケートに答えたらもらえる。

会場雰囲気

f:id:Namihira:20170217172124j:plain

セッションメモ

自動化はどこに向かうのか ~まだ開発・運用の自動化で消耗しているの?~(仮)

  • さくらインターネットの人
  • ツール導入や自動化を目的にしてはいけない。
  • ツール利用において業務環境、背景はそれぞれ。要件は組織ごとに異なる。
  • 何を達成したいのかが大切。
  • 自動化する理由は以下。
    • 省力化、時間短縮、人的ミス防止
    • ペットから家畜へ。大事に育てる。
    • 現実的な課題解決のための自動化。
  • 現場視点と全体俯瞰を考える必要がある。
    • 現場視点・・・常に正しい努力をしているか。
    • 組織視点・・・みんなが同じ方向を向いているか。
  • 必要だったから作ったが自然。
  • 自動化「したい」ではなく、自動化「すべき」か否か。
  • HashiCorpが定義しているDevOpsの定義
  • 自分で手を動かしてからツールは利用する。他社で導入されたからはいけない。自分の業務にあるか確かめてから。
  • 所感
    • 最近Slackを導入して「コミュニケーション促進」となんとなく言っていましたが具体化しないといけない(;´Д`)

Re: ゼロから文化を創り、技術を伝承する ~客先常駐エンジニアと「社内勉強会」で築いた価値と変化

  • お客様先駐在主体の会社での勉強会の取り組みと効果の紹介
  • エンジニアの成長にプラスになる「場」の形成が必要だった。
  • 伝える力と求める力が必要。
  • 営業身だしなみ勉強会とかもあった。
  • 長続きさせるコツ
    • スケジュール(年間)を予め決める。特別なイベントなど強弱をつける。
    • プロジェクトルイーダドラクエルイーダの酒場のように、同じ目的の仲間探しを支援する仕組み。予算提供もあり。
  • 勉強会の効果
    • 教育期間の節約。自己研鑽が見えるとお客様からの信頼が上がる。
    • 現場としての気持ちが伝えられる。体験談なども。
    • ビジョン、価値観の共有。
  • 成長の見えないエンジニアは本人は諦めていても、会社は諦めない。
  • 所感
    • 同じ基礎知識と価値観を持つことが大切(;´Д`)

まだ見ぬコミュニケーションAIの実現に向けて

  • NTTPCの作ったAIの紹介
  • 見た目の第一印象から性格を仮決めして、質問(とそのときの見た目)を通して性格を最終決定する。
  • 仕組みは、表情の画像から画像特徴量を抽出して解析し、事前登録してあるデータベースからレスポンスを返す。
  • 素材は以下。
  • 所感
    • AIに詳しくないけど、やっていることは結構ベタ?(´・ω・`)
    • 言葉を使わずに性格を見積もるのは何か使えそう。犯罪者とか?感情が分かれば赤ちゃんとか?

オルタナティブなチーム開発のすゝめ

  • オルタナティブ」= 「わくわくする」
  • 一般的なラインマネージメント(ツリー構造)の問題点。
    • 上に行くほどいけば現場から離れるので責任を回避する。
    • 伝言ゲームが発生する。
    • 管理能力を発揮しないと階段を登れない。
  • 機能的組織チームづくり
    • 仕事をすべて洗い出す。どこに課題があるか認識する。
    • 機能を洗い出す。
      • やらなくてはいけないこと=必須機能、できること=仕事とは関係ない機能(整骨院の資格など)。やりたいこと=将来的に必要なこと(個人ではなく、組織としてやりたいこと)。  * 機能に人をアサインする。アサインできない機能を外部に求める。または捨てる。
  • お客様とともに楽しむ
  • 以下の役割の人をいれた
    • Webディレクター・・・たぶんデザイン寄りの人のこと
    • サービスプロデューサー・・・たぶん他の製品に関わった人のこと
  • 給与日を意識した施策をいれる。
  • 新技術検証も計画に入れる。世間的に注目度の高い技術をお客様と共に検証する。
  • 最近マイソースファクトリーというものを作った。
  • 設計書も自社らしく(楽しく)
    • アイコンと矢印だけでシステムで表現する。
  • 所感
    • わくわくするような開発良い。
    • 「機能」について具体的な例や文言がなかったので掴みきれなかった(;´Д`)

DeNA機械学習基盤と分析基盤

コミュニティとエンジニアの生き方(仮)

  • コミュニティを運営している方の発表(二名)
  • 信条(クレド)、概要書作成しそれを軸にして活動。
  • 運営時のコツ
    • 参加者にスポットライトを当てる仕組み。アイスブレイク、名刺交換。初心者を登壇させる。
    • はじめにセッション、そのあともくもく会だと効果が広い。
  • 関西Javaエンジニアの会の人
  • 「こうなりたい」人に近づく、触れる。運営をやっているとそれが得やすい。
  • すごい人と接すると、すごい人がやっている普通のことがわかる。自分の普通が変化していく。
  • 変化が周りに伝染する。
  • コミュニティは「貢献」で成り立つ。何かしら貢献が必要。
  • 所感
    • 今住んでいるところにコミュニティない(;´Д`)
    • 搾取だけではいけない。貢献しないと(;´Д`;)

『もしもスクラムマスターがテストエンジニアだったら』(もしテス)

  • テストの会社のツール開発の話。
  • 既存のファイル(Excel)以外のインターフェースだとなじまない。
  • 小さくリリースするための仕組み
    • 要件の素因数分解:ユーザーストーリーの分解、スパイク・ストーリー(技術検証のストーリー)
  • 6W1Hでユーザーストーリーを書く。テストが書きやすい。
  • 最低限の仕様書
  • テストエンジニアがテストを実施するときは全体を見る必要がある。それはプロダクトマネージャの視点に似ている。
  • 所感
    • テスト会社の製品づくりの話おもしろい。
    • テスト駆動でプロセスも構築できそう。

『ジョイ・インク』Joy, Inc. 〜 共感のソフトウェアづくりについてみんなで考えるワークショップ

  • 以下の書籍の翻訳者によるワークショップ
  • 知識構成型ジグソー法を使った参加型セッション
  • みんなを喜ばせるではなくて、この人を喜ばせるとしたほうが良い(ペルソナ)
  • 同じ喜びを共有できること。
  • 所感
    • ワークショップだと他の参加者と話して講演とは違って生々しい話があって面白い。
    • 「喜」についてはセッション内だけでは理解できなかった。本買わないと(;´Д`)

ブース関連

所感

  • ソフトウェア全般の話が聞けてよかった。
  • 今回は気づいたら聴講したセッションがプロセス関連やチームづくり関連が多かった。多くの書籍分の知識を効率的に吸収できた感じ。
  • (逆に技術的な収穫はあまりなかった(;´Д`))
  • 今回講演前にシャッター音、キーボードタイピング音とか注意があってよかった。去年は結構気になった(;´Д`)今年も多少あったが。
  • 参加者も多く、目黒雅叙園では手狭になっている気がする(;´Д`)

まとめ

  • これからがんばりたいです(小並感)