とにかく今の時代は機械学習だ人工知能だ、といったことを考えたくなるが、その応用の前段として、大量のデータを扱うためのデータ分析の基盤が必要。
データ分析の基盤としては企業がすでにもっているデータウェアハウスなどをバッチとして利用したり、ウェブやアプリのログやロボットのセンサーデータなどのストリーミングデータをアドホックに分析できることが必要である。
そのための技術基盤として、Apache Kefkaなどのproxy技術が活用されている。
また、データを生に近いままストアしておくための仕組みとしてHDFSなどでのData Lakeを構築するためにcassandraという分散DBがすでに多くの企業で利用されている。
Data Lake周りの話ではAWSのRedshift SpectrumというS3にデータをホストするだけでSQLライクな仕組みで検索できる仕組みが最近発表されてた。
こうしたデータ分析基盤を構築するノウハウはやってるところはかなり溜まってきており、人気のアプリ等のバックエンドを支えるチームには強さみを感じる。

データ分析を語る上でのスキルセット

結局はSQLベースの分析と何ら変わりがないからそのためにSQLの知識は必須となっている。
PythonのJupyter Notebookなどで生のSQLを書いて実行し、その結果をデータフレームとして読み込んでBIとして使える形のグラフとしてレポート出力することは既に日常茶飯事である。
Jupyter Notebookからはscikit-learnなどを利用してダイレクトにクラスタリングやそこからの機械学習系のライブラリに食わせることも可能。
結局のところ、機械学習や人口知能を語る上ではpythonなどのプログラミングの知識やSQLの知識は必須になってきていると思う。

また、biz側も継続的にレポートして出てくるデータと向き合う根気が必要なので、dev x data x bizの連携が密接に連動する組織作りが一番重要ではないか?
スタディサプリの講演の受け売りですが。

センサーデータと機械学習

みんなのPython勉強会で紹介されていたというH2O.aiマシーンラーニングのプラットフォームについてのお話です。

startpython.connpass.com

MAPRテクノロジー
データエンジニアマテウスさん
ソフトウェアエンジニア　マシューさん

例としてロボットの動作の異常検知をあげる
異常があるとロボットの動きがおかしくなるが、本当は異常が起きていても人間の目で分からない場合もある。
そういう異常があるかどうかを機械学習を使えばリアルタイム表示できる。

具体的には、

ロボットのセンサーデータをラズベリーパイに無線データで送る
ラズベリーパイからデータを分析するためにAWSのクラスタに送る
AWSのクラスタからの出力はARのヘッドセットに出力され、リアルタイムに確認できる

H2O.aiは２の部分のAWS クラスタで処理系として使われている部分である。
データでパターンを作り、パターンを予測できる。
データがちゃんとないとモデルは役に立たない。だからデータが重要。そしてそのための仕組みづくりが重要
Apache kafkaがREST API proxyとしてメッセージキュー処理を行うのだが、そのためのRESTリクエストの仕組みはpythonのrequestsモジュールでかんたんに実装できるとのこと。

機械学習を利用したシステム構築のの実際
最初はとにかくデータを観察する。だからデータ分析ができるためにjupyterなどでのプログラミング＋アドホックなデータ分析は必須。
そして、どう活用するか考えて、モデルを作る、仮説を作る。

「異常が出たら予測がほしい」

仮説はとにかく素早く検証する。検討ではなく検証。

センサーを作った人と話して、新幹線などでも使われている加速度センサーを使うことにした
普通のデータ以外の異常データが出たらすぐにわかるようにしたい

教師なしでの学習を行い、正常系の動作から変わったときに異常かどうかを判断する
おかしく見えるけど本当におかしくはない状態もある。
予測が変わったらすぐに異常を出すのではなく、ちょっと待つようにしている

デモムービーで実践が紹介されていた

Q
教師あり　教師なし学習の差はどんなものがあるのか？
A
データによってアルゴリズムと問題を見て判断する。
クラスタリングなどは教師なしのほうがいいけども、基本的には、教師ありのほうが良い
教師ありが使えるなら使うべき
教師ありでラベルを付けるのがコストがかかる
作戦としては教師なしから教師ありを考えるべき

現場では基本的に正常系データしかないことが多い

Additional
最近ではGPUでの分析に対する顧客の要求が高まっているため、このプラットフォームでも全部で使える状態を構築中。（今は一部）

「Pysparkで始めるデータ分析」

BIと機械学習についてのお話こちらもみんなのPython勉強会です。

田中裕一さん（日本IBM）全文検索エンジン R&D

PysparkはApache sparkをpythonを使って利用できる！

分析アプローチのパターン

健康診断アプローチ
BIや現状の見える化を行うためのもので、サマライズすることがメインの要求になる
例えば、「どういう顧客が製品を使っているのか」「どういう導線」
探索的アプローチ
これはセンサーデータの例でも出てきたように、データの中身を探索するときに使う
基礎集計、機械学習、教師なし学習などで分類
実際のビジネスでは有料会員化のフローなどを考える。
「無料会員がどういう経緯を経て有料会員になったのか」などを探索して分析
離脱ユーザーのカムバックフローなども
UIUXのためのセグメンテーションで戦略を立てる
「女性にはこういうUIがうける」
検証のためのデータ分析アプローチ
定量的な観測
仮説を立てて検証のフェーズで使う。
無料の会員を有料に遷移させるためにステップアップ施策
「通常１０００円を３００円で使えますよ」という施策を実行したときにどういう結果が出たのか観測する

データ分析ってどういう人がやるのか

データエンジニア
データサイエンティスト
ビジネスアナリスト
アプリ開発者

４ロールが協調してデータ分析を行う

Apache sparkとは、

大量データを分散並列インメモリのフレームワーク
大きなデータにたいしてトライアンドエラー。Hadoop単体では難しかったアドホックな分析が可能になっている
最近はGPUでの分析が話題になることも多いが、こちらも相当有名。

お題　ABテスト

pythonからsparkを使ってデモンストレーションを行う。
pysparkもpandasと同様にデータフレームを持っている

CSV１に顧客情報
csv２に購買情報
csv３にアクセスログ

jupyter上でデータフレームとして読み込みを行う

得られる内容としては以下の通り

どの顧客が何月何日どこのURLにアクセスした
スマートフォンやPCなどのUA

k-means法をつかってABの対象顧客を抽出

sparkではshowで先頭データを見ることができる
文字列のデータを扱うのは難しいので、MFの性別の文字を変換するなどしてコード化
なぜコード化が重要なのか -> 性別は２値だがアンケートなら数十になることもある

pysparkを使うと分散処理意識せずに使える

無作為抽出を色々工夫しながら行い、K-meansというクラスタリング　ラベルデータはなく３分類する
性別利用頻度によるセグメンテーションとAB抽出

大事なのは機械学習でクラスタリングして、人がデータを見て意味づけする。
そこから次の施策を考えるための分析をアドホックに行うことができるということ。
抽出のための工夫などもプログラミングのスキルは必須なんだと思う。

感じていること

人工知能や機械学習は常に進化していて、ひょっとしたらプログラミングなどの領域も人工知能に置き換えられるかもしれない。
ただその中間地点として、ドメインに人工知能などを適応させる領域には常にプログラミングが必要になるんじゃないかと思う。
もう一つはdev x data x bizのチームビルディングが重要だということ。もちろん基盤も必要だろうけどそれよりもチーム。
アジャイル、顧客開発、リーン、仮説検証。それらのキーワードもしっかり自覚しておく必要があると感じている。
そういう感想をいろいろと感じられたという意味でこのPythonの勉強会やDevsumi2017に参加した意味は大きかったと思う。
結局のところ主体的に機械学習に取り組めていないという意味ではまだまだちょろあまな自覚はあるけれども。

2017-04-19

Amazonで「ハッカーと画家」を検索すると「ソフトウェアエンジニアに読んでほしい本○○冊」みたいになってる

タイトルの通り。
だけどどういう検索なんだろう？

ハッカーと画家
情熱プログラマー
UNIXという考え方
Team Geek
リーダブルコード
アジャイルサムライ

f:id:hirokts:20170419095815p:plain

2017-03-19

DevLove関西『リンスタ関ヶ原 (新大阪の変)』に参加しました #Devkan

2017年3月18日にあったDevLove関西のイベントに参加しました。
東京に引っ越してからは初の参加です。

devlove-kansai.doorkeeper.jp

「正しいものを正しくつくる」

Guildworks 市谷聡啓さんの話

感想

市谷さんの話は「頑張ればいいプロダクトマネージャーになれるかもって人」に聞いてもらうといいのではと思いました#DevKan
— hirokts (@hirokts) 2017年3月18日

市谷さんは価値の探索・検証が得意技でそのお話でした。
正しくないものを作り続けるのってソフトウェアエンジニアにとって不幸でしかないし、本当に考えないと。

新規サービス食のつながりが世界を変えるFoodionの立ち上げ

クックビズ要徳幸さんの話

社内スタートアップとして開始したFoodionの話。料理のプロの人のインタビューサイトを作って、調理業界全体のキャリアのモチベーションを高めたい、というミッションがすばらしいと思いました。
タックマンモデルなど結構ハイコンテキストな現場の話で、「チームとは」みたいなのを深く考えさせられます。

スタートアップを陰ながら支えるときに心がけるべき5ヶ条

楽天の川島淳美さんのお話です。

スタートアップを陰ながら支えるときに心がけるべき5ヶ条 from Atsumi Kawashima

www.slideshare.net

この５か条本当に大事だと思う。

当事者意識を持つ
本質を追究する
「それ、絶対使う？」を意識する
いい感じの木にタイヤブランコを１週間で作ってきてー！
関係者をトリコにする

４つ目の「いい感じの」とか「わかる（わかる）」です。
５つめのトリコにするというのもスライドにあるように「関係者以外に言いたくなる」ってならないとだめだなーと思いました。

ちょっと話がそれます。
当事者意識については、「圧倒的当事者意識」っていうキーワードを別の勉強会で聞いていてそれが気になっていました。 FB広告でそれが出てたHarvard business reviewを買いました。
読んだ感想、プラス元リクルートの人のお話を聞いた感じでは「で？」という問いを常に自分でし続けるのに近いのではないかと思います。
「で？（どうしたいの？　どうするの？　どうなったの？）」みたいな感じの問いをするある人が思い浮かびます。
当事者意識についてはその質問を自給自足し続けることがいいんじゃないかなと思いましたので実践します。

元ソフトウェア設計者の缶詰事業挑戦記録！〜「目的」は変えず「手段」を変えながらの事業作り〜

缶詰事業のベンチャーとして株式会社カンブライトを設立した井上和馬さんのお話。

docs.com

すごい。やばい。おもしろい。
絶対見学に行きたい。これ参画できたら絶対楽しいよ

という頭の悪い感想です。

SIerからの転身でも、本当にその領域にのめりこめば自分のスキルや今までやってきた改善が十二分に生かして仕事ができいるということがよくわかりました。

泥臭い時期の話も含めて本当に面白いです。スライド上がったのでぜひ見直してみたいです。

リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ

リクルートテクノロジーズ　黒田樹さんのお話

リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan from Itsuki Kuroda

www.slideshare.net

とにかく一番聞きたかったやつです。本当に学びしかない。

２年前のDevLOVE甲子園日本シリーズでお話を聞いたことがあったのですが、そこからさらに進化しています。仮説を立てるときは逆回りにサイクルを考えるとか、別でうまくいっているプロダクトを輸入するときはどこのフィットが崩れるか仮説をたてるとか。スライド上がるそうなのでメモをもう一度見直しながら、理解したいと思います。

ちょっと内容と関係ない感想。
Switchの初期不良を引き当てて、やっと修理から戻ってきたそうなのですがスライド作成中にどうしてもゼルダやってしまったとか。
ゼルダやりたいーーーー。
Switchいつまともに買えるんだろう。。。

全体の感想

とてもよかった。プロダクトとどう向き合うか、とか、スタートアップで実際にやるとどんなことをやるとどんな感じなのか？とかいろいろ考えさせられます。
自分としてはプロダクトへの向き合い方、エンジニアとしての在り方、チームをどう支えていくか、価値をどうやって早く届けるか・検証するか・フィットさせるかなどあらゆる学びがありました。

登壇者の皆さま、スタッフの皆さま、会場のMOTEXさま　ありがとうございました！

2017-03-04

エバンジェリズム研究会 #0に参加してきました。

2017年2月28日、横浜にあるAtlassian社でのイベントに参加してきました。

atlassian-club.doorkeeper.jp

東横線で意外と短時間で辿りつけました。勉強会のノートですが、お酒のみながらのメモなので誤りなどがあればご容赦ください。

Atlassian　長沢さんの話

エバンジェリスト

伝えるだけじゃなく、伝えて行動を変えてくれて初めて何か達成できたな

場を作る　ひとはそれぞれのコンテキストで生きている

まともな製品なら宣伝は必要ない　きっかけが必要なだけ

やりたいこと　世界観(Why)を伝える
「こういう世界があったらどうですか？」

聞いてくれてる人のコンテキストは違う
受託　自社開発　開発者　デザイナー

ゴールデンサークル

(ゴールデン・サークルについては以下のTEDを見ると非常によく解ると思います。Wantedlyのエンジニアさんに教えてもらいました。)

www.ted.com

４C

顧客価値
顧客の痛み
(convinienceについてはメモし忘れ）
対話

自己管理

エバンジェリストは孤独

飼うのが難しい
基本的に野放し

謝罪力が重要

評価について

現場を耕すことで実がなるように仕向ける

マーケットに役に立つ
マーケットに評価されれば会社は評価せざるを得ない

感じること

自分の価値を消費してる
周りがどんどんレベルアップして　あいついらないじゃんといわれるのも目標

感想

話の中で「自然とそうなるように」するという話があってなるほどなーと思いました。営業でおしつけするのではなく、コンサルするのでもなく、コミュニティをさすらう感じみたいです。自己管理とか自分の価値をどう捉えるのかとかすごく大変そうだ。

アジャイルコーチ　川口さんの話

(エヴァンジェリズムのことそのものではないのですが、川口さんが後半いろいろお話してくれた時のメモです。)

知人が薦めてくれる
「ユーザーストーリーマッピングは川口さんに聞きに行ったらいいよ」 ↓
全否定しに行く

作れることが大事
エクセルマクロを困ってる人たちに教えるというようなことでも

プログラミングであれ設定であれ　やりやすいように本線にもどるようにやっていく

開発チームは開発やってるけど超遅い
2週間　かかって　受け入れで見せる
見せないからダメ
そういう現場にもどんどんきりこむ

呼ばれなくなる現場もある

コミュニティに来る人
会社の中でいたたまれない人　（ひどいよｗ）
話しやすい

エンジニア１０年後食えないかもしれない問題

AIでプログラミングがいらなくなる
IT業界生き残ってるの？

マイクロソフトbingチーム　UIテストの自動化

誰にも任命されずにスカンクワークスで始めた
フルタイムでそのテストができるようになったのが4年前

環境を用意したい
モノ作りするのにはいつでも戻れるというマインドだった今は違う

アトラシアンの創業者

２，３年前前まではプロダクションコードを見てた　今はわからないけれど

色んな所でコード読めることが必要になってくることについて

GEはプログラミングしない人は取らない
ITもわかる人
わりとネイティブにコードを見ることが必須

アジャイルコーチについて

結局やってることは交通整理
それだけでも意味がある

JIRAやRedMineについて

ワークフローいらない場合もある
課題が一覧できて集計できる
エクセルで事足りる場合はエクセルでいいじゃん

子チケット問題

孫作れないじゃん子供が閉じたら親が閉じれますっていうSQLなだけテーブルの定義はシンプルにしといたほうがいいプログラミング言語のオブジェクトでいじってるのに(Railsの話)

オブジェクト指向

継承で死んでることが多い

ジリ貧バックログの話

焼肉屋のメニューのたとえ上の方に上タンやカルビなどがある「上の方から食っていく」宣言して本当にやる人たち下の方になったときミノとかレバーしか残ってなくて「お前たちそれでいいのかよ、もっとカルビ食えよ」みたいなツッコミを入れたくなる

(多分、下のスライドの84ページ目）

speakerdeck.com

感想

テーマなしの雑談みたいな感じだったのですが、参加者と議論しながらのやり取りが非常に面白くエキサイティングでした。

これが必要になった理由

コード

スマートホームの技術

人工知能、機械学習 その前に