デブサミ2016に行ってきました　1日目 #devsumi

去年に引き続き、2回目の参加！自分用にめも。印象に残ったところと感想をかるく書きます。
（ふわーっとした感じで選んだセッションが多くて、理解が追いつかないのが多かった！） 去年と違って、今年は就業扱いで参加できました。嬉しい〜。

雅叙園には猫がいた( *｀ω´)

公開されてる資料はここにあります。

codezine.jp

実感駆動でものづくり ユーザーストーリーマッピングで想いと体験をつなごう

  • 楽天の川口さん
  • ユーザーストーリーマッピングとは↓（後から調べたので、川口さんの言ってたのとちょっと違うかも。）
  • 顧客の視点からサービスや商品の要件を記述したもの（ユーザーストーリー）を時系列順に挙げていき、さらに優先度付けをおこなうことで、サービス・商品が満たすべき要件仕様を整理し、全体像をチーム全員で共有するためのツール
  • 作っても使われない機能がある。
  • リリース後にユーザが本気になるって問題はよくある。なぜか？
  • ユーザに諦めの川を渡らせない。リリース、混乱、クレーム、対策。このサイクルをまわして実感してもらわないといけない。
  • そのため（ユーザを本気にさせ続ける）にはどうしたらいいのか。ずーっと作り続けるチームを作る。ドキュメントで意思疎通する。セットで動くソフトウェア。早めにだすと、ユーザが本気になってくれるので、どんどんドキュメントと動くソフトウェアを出す。

  • 信頼貯金！！

  • 全体像を全員で共有するのがミソっぽい。

  • 今年はうさ耳じゃなかった。
  • 信頼貯金すごい考えさせられる。今けっこうしんどいって感じるのは、信頼貯金がないのが原因なんだろうな、とかぐるぐる考えていた。
  • この本「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」、２日目のアラサーエンジニアのセッションに出てきてた。
  • ユーザーストーリーマッピングの本買えばよかった。

データ分析で始めるサービス改善最初の一歩

  • サービスのログを分析し、様々な改善に活用するための第一歩を踏み出した話（これから始める方向け）

  • ライブラリも充実してるので、怖がらずに気軽にためしてみてもいいのでは

  • ログのフォーマットが統一されてないと苦労する、というのはいろんなところでよく聞く。わたしも苦労したことあるな！＞＜

  • あんまりデータ分析のことよく知らなかったけど、わかりやすかった！

データ分析グループのチームマネジメント変遷（ロングバージョン）

  • データ分析グループの仕事の範囲は？アプリ運用で生まれたログデータを研究レベルで解析してビジネスに生かす。そのため、必然的に研究からアプリ運用までカバーする。
  • 組成失敗例。大企業ならではの問題。個人情報。
  • データサイエンティスト＝高学歴、研究者で採用しがち。アカデミックにおけるバリューと、ビジネスにおけるバリューは違う。
  • 雑用になりがち。同僚から感謝されるのは気持ちいい。本質的な価値を見出せなくなる。
  • 仕事の範囲がエンジニアとかぶるため、エンジニアと対立しがち。
  • 何が問題なのか？データ分析グループは近年できた新しい組織形態。運用方法を知っている人もいないし、当人たちも知らない。
  • 正しく運用するには、エグゼクティブのサポートが必要
  • カバー範囲の明確化。システム面のサポート（データ分析者の書いたコードがサービスに影響を与えないようにアーキテクチャを設計、エンジニアとの対立を解消）
  • 会社として十分な御膳たてがないと機能しない。（データ分析は、個人としてどうにかできる問題ではない。空軍みたいなもので、パイロットが生身で飛べるものではなく、戦闘機のメンテなどが必要。）

  • イノベーションのジレンマ。合理的に判断（意思決定）するとイノベーションは起きない

  • 空軍の例えがわかりやすかった。

  • 新しい役割、組織ができるたびにこういった試行錯誤があるのかなーとふわっと思った。
  • エグゼクティブの意思、大事。

FinTech 金融とテクノロジーの○○な関係

  • 日本におけるFinTech企業→zaim、マネーフォワード、freee、お金のデザインなど。始めやすいサービスから、規制業種領域へ参入して行っている。
  • 規制業種領域へのスタートアップ参入。参入への鍵は徹底したユーザ視点だと思う。
  • 規制はもともとなんであるのか？ユーザを守るためにある。そう考えたら、こわくない。規制の裏にあるユーザへの想いを受け止める。ユーザのことを一番に考えてサービス構築をしましょう。
  • お金のデザインで始めた資産運用サービスTHEO(テオ)の紹介

  • ネットって開かれた実験場のような感じ。チャレンジしてすごくイノベーティブな経験をしたと思う。そういった経験を既存業種でやるとさらにイノベーティブなことができると思っている。

  • ベンチャーが徹底したユーザ視点を持ってとりくんでくるの、SIerからしたら怖くない？！って思ってしまった。なんとなくですけど。

  • けっこうスポンサーセッションっぽい内容（自社サービスの紹介が多め）だったけど、わたしは面白いな〜って聞いてた。

アジャイル開発でハードウェアをつくる～イノベーションはラーメン食えればいい！～

  • ハードウェアガジェットの恐るべき混沌（それ資金集めてるけど、ほんとに実現できるのか？！）
  • 地溝油とか
  • 中国の業者とのやりとり（最初は絶対失敗する）

  • ハードウェアの世界のやり方は遅れている。儲けはラーメン１杯食べられるくらいでいいので、Webサービスの手法（とりあえず作ってみる、アジャイル開発など）を取り入れていこう。

  • 今は中国に発注したら基盤も安く作れるのでとりあえず作ってみて、ワークショップでお客さんに作ってもらってフィードバックをもらい、製品に反映させる、というアジャイル開発の考え方を電子工作に取り入れたりしてるよ、って話だと思ったんだけど、合ってるかな。。わたしの理解が浅そう。。

  • 電子工作とかしたことないから、ほぇ〜って聞いてた。東日本大震災の後足りなくなったガイガーカウンターや地溝油検出のデバイスとか、そういうの作れるのか！って新鮮な驚き。

Yahoo! JAPANを支えるデータテクノロジー 〜機械学習、クラウド分散システム処理モデル〜

  • 解決したい課題→MacBookAirのカテゴリにパーツも出てくる。このことをカテゴリ違いと呼ぶ。 このカテゴリ違いはユーザビリティの低下を招く。
  • カテゴリ違いの検知。人による検知は高い精度があるが、限界があるし、量もこなせず、スピードも遅い。 そのため、ここに機械学習を利用。ただし、機械学習にも限界が。過去の情報から学習するので、未知のパターンには対応できない。百パーセントの精度は難しい
  • 機械学習はブームになっているが、銀の弾丸ではありません。適切に使う必要がある。

  • なので、ヤフオクでは人と機械学習のハイブリッド方式を採用している。人は判断し、機械学習で人が判断する順序を決定し、双方のメリットを両立させている。

  • これも理解できてない。難しかった＞＜

  • ヤフオクの商品ドメインは多いので、機械学習分析？を進めていかないとやっていけない、という話はその通りだなと思った。家とか車まで取り扱ってるなんて知らなかった。

２日目に続く！