謙遜は美徳だがチャンスは逃げる

なんかエモいことを書きたい気分なので。
タイトルで言いたいことは終わった。
以下、蛇足。


日本人は謙遜するのが美徳、みたいなところがある。
コミュニケーション上それはすごく共感する。


ただ、一方で、「こういう機会があるんだけど、どう?」みたいな誘いを誰かに言われたときにそれをやってしまうと、大きな機会損失になってしまう。


断り文句として使う場合は構わない。
スキル不足や遠慮で謙遜を使うと、それを乗り越えたときに得られたであろう経験がどれほど大きかったことか。


声を掛ける側はスキル不足かもしれないということは多少想定している。
なんだったら失敗して、それが糧になればいいくらいに思ってることもある。


迷ったらやってみる、というのを信条としたい。
ただ、時間は有限だ。


プレゼン資料ドリブン

先日、AzureMachineLearning のハンズオンイベントをスピーカーとして行った。

【Azure Machine Learning ハンズオン入門】実践からはじめる機械学習 - connpass

イベントについては会社のブログに書くとして、プレゼンの準備をどのようにしたかについて書く。

3/28 20:56 追記。
会社のブログに書きました。

blog.isao.co.jp

以下、前提

  • 準備はじめたのは3週間前
  • Azure はそれなりに知ってる
  • Azure Machine Learning について名前だけ知ってる状態からスタート
  • この手のイベントのスピーカー経験はなし
  • 社内でスピーカーやる経験は何度かある


やったこと

プレゼン資料作成

早速ブログエントリのタイトル回収。
ここからはじめた。

以下のように大まかな格子を考えた。

  • アイスブレイクとしての自己紹介(40歳以上ではない)
  • 概要説明
  • ハンズオン
  • 多少の解説
  • まとめ

この時点で埋まったのは最初の自己紹介だけ。
「ゼロから学ぶ Deep Learning」でくじけた自分でも Azure Machine Learning は使えます、って流れで紹介することだけ決めた。


connpass のページを公開すると、その日のうちに定員20人に対して34人参加が入る。
この時期の機械学習系のイベントは集客力が恐ろしい。
まだ白紙のスライドなのに。

30周年セールで衝動買いした ファイナルファンタジー X/X-2 HD Remaster をやってる場合ではない。
ベベルで足止め。

情報収集

メインとなるハンズオン部分や関わる技術概要を埋めるための情報収集

  • 公式ドキュメントを漁る
  • 公式のチュートリアルを試す
  • Qiita や個人ブログを中心にやってみた系の記事をあさる

最初にググってまわるのは効率悪くて、公式から追うのがベター。
特に MS は翻訳はアレなことがあっても最近ドキュメントが読みやすくタメになる。
検索にヒットする記事は1年前の記事ですら陳腐化してる可能性があるし、そもそも質が低いものが多い。

10日前の時点で満足度6割の資料ができあがる。
最低限開催できるだろうというレベル。

これで七曜の武器集めが再開できる。

校生・ビルドアップ

試行錯誤で完成度を高めていくフェーズ。

  • 資料全体を見て整合性チェック
  • 自分でリハーサル
  • 社内リハーサル
  • 他のイベントに参加する

効果的なのは社内リハーサルと他のイベントに参加したことだった。
視点漏れが減るのと、コンテンツの不足が補われた。
協力いただいた方々、ありがとうございました。

この頃、とれとれチョコボで0秒切りを達成して、無事ティーダの武器が限界突破を果たす。
プレゼンで玉砕して死んでも後悔はない。

本番について

割愛

考察

プレゼン資料ドリブンは議事録ドリブンに似ていて、必要なアウトプットを最短経路で生み出してる感あってよかった。
機械学習は闇雲に調べるとキリがないジャンルなので、伝えたいこと言いたいことにフォーカスして下調べできたのが大きい。
ただ、早い段階で伝えたいことを確定させてしまうことで、結論ありきにならないようにしないといけないという点はある。
バランス感覚が必要。

スケジュール感としてはギリギリまで資料作ってる、という状態にならず、早い段階で開催できる状態が見えたのもよい。

ふと思い返せばブログ駆動開発することもたまにある。
最終的にこういうアウトプットを出すために今やっていっているのだ、という認識があるとモチベーションになってよい。

進捗

スフィア盤埋めとルールーの雷避けが残ってる。
前者は作業なのでやる気がない。

雷避けは2年前にバズった記事で機械学習で自動化してる方がいたことを思い出した。
FF10の雷除けを自動化した話 - panchiga's blog

たまたまとはいえ機械学習という話でつながってくるとは。。
投資がかさむので気が向いたらチャレンジしたい。

Productivity Engineering − Forkwell Meetup #4 行ってきた

【増枠!】Productivity Engineering − Forkwell Meetup #4 - connpass

上記イベントに行ってきた。
発表で響いた点のまとめ。

クックパッドにおけるモバイルアプリ開発の工夫 クックパッド @ichiko_revjune

  • 機能ごとに開発チームを分割
    チーム内にデザイナー、エンジニアがいる
  • リリースサイクルは2〜4week

実装

  • 意図したとおりに実装できていること
  • 効果が計測できること

方法

  • 朝会
    増員に伴いチャットで行うようにした結果、他社への関心が薄れ、実装した機能のコンフリクトが生じて計測が正しく動かなかった
    そこでキックオフを行うようにした
  • キックオフ(開発初期段階)
    対象はディレクタ、デザイナ、エンジニア
    大きな変更を共有
  • 確認会(リリース前)
    UI/UX の一貫性を確認

Effective Retrospective アトラクタ @ryuzee

  • ふりかえりの目的
    「もっとうまくできるように」はみんな知ってる
    「仕事を急停止する」あまり知られてない。立ち止まって考える余裕を保つ
  • 心理的安全性をつくる
  • テクニック
    開始時に全員に口を開いてもらうと主体的参加度が上がりやすい
    施策は自分が実行者となってやる、くらいのものを少しだけ選んだほうがよい
    いっぱい採用してもどうせやらない

自己言及的なチームをつくる GMOペパボ @june29

  • 今日より明日をちょっとよくしたい
  • 自分たちを変えるのは自分たちでしかできない

Make Jenkins Great Again サイボウズ @miyajan

  • 2.0 よい

最速で価値を提供する ネクスト @masamichi

  • 価値を高めるためにも、品質の共通認識をつくる必要がある
    品質の仕様化、言語化
    具体的には速度=レスポンスタイムやセキュリティ=脆弱性診断結果など
  • 待ち時間や手戻りをなくす
    そのための情報共有ツール, CI, CD

ペアプログラミングの使いどころ タワーズ・クエスト @t_wada

  • How 考えを声出す、もしくは紙やホワイトボードに書く
  • When メンバージョインしたとき、新機能実装、週1
  • Why タスクは完了してこそ意味がある。並行作業で仕掛かりを増やすより1つずつ完了させる
    教育的側面、スキル伝授

Q&A

  • 開発環境が人によって異なるのでは?
    開発環境の好みよりもチームの成功が大事だよね
  • ペアにしかノウハウが残らないのでは?
    モブプログラミング
  • 上級者にメリットがないのでは?
    教えることで知識の整理ができる

最後に

プログラマが知るべき97のこと

プログラマが知るべき97のこと

微分積分?何それ?Azure Machine Learning を使って実践から入る機械学習

はじめに

機械学習、流行ってますね。
流行りに飛びつくのはシャクだが、少しは理解を深めたい。
しかし流行りに乗じて本を買っても数学などの基礎部分でつまずいてあきらめていた。 そんな自分にも機械学習を始められた。
そう、Azure ならね。

想定する読み手

  • 機械学習に興味がある
  • 地道に数学を学ぶモチベーションが維持できない
  • 動くプロダクトを早く見たい
  • 学習コストを低く機械学習を始めたい
  • 「ゼロから作るDeep Learning」を途中で挫折した

検証をはじめる前に

前提知識

さっそく手を動かしたいところだが、ちょっとだけこれを読んでほしい

一般的に機械学習で必要な手順は以下のとおり

  1. 題材を決める
  2. 元となるデータを用意する
  3. モデルを作成する(モデル=AI と思ってくれていい)
  4. 結果を確認し、必要があればモデルを修正する
  5. 4 を繰り返す

大事なのは1と2だ。
いきなり手を動かすにはデータがないといけない。
Azure Machine Learning にもいくつかサンプルデータが用意されている

自分にはピンとくるものがなく、英語も読みたくないし、複雑なものは理解しづらいので自分で準備した。

https://raw.githubusercontent.com/kheiakiyama/HolidayEstimation/master/holiday.csv

日本の祝日かどうかを50年分出力したデータ。
人間もプログラムも読みやすいようにしたつもり。

github.com

上記プログラムで出力した。

Azureサブスクリプションを用意する

メールアドレスがあれば下のリンクから始められる。

azure.microsoft.com

正直 Azure はこのアカウント周りが非常にわかりづらく、最初のハードルになりやすい。


ログインに必要なのは Microsoft アカウントで、既存のメルアドから作成できる。
Azure のリソースを管理する単位が Azure サブスクリプションで、この単位で請求が来る。


登録にクレジットカードが必要になるが、有料の支払いをオンにしない限りは勝手に決済されることはない。
(ただしこの設定は一度オンにするともう戻せないので注意)
無料のクレジットがついているので、ちょっと試すくらいなら十分ペイできるはず。

Azure Machine Learning Studio で検証

モデル(experiment)の作成

いよいよ本題。
とはいえ説明することは特にない。

↓に大変よくできたドキュメントがある。

docs.microsoft.com

ドキュメントは日本語だが Machine Learning Studio が英語だと混乱しがちだが、ほとんどつまづくことはないはず。
ポチポチするだけで結果が出て来るのはよい。


ということでドキュメント読みながらポチポチ進めるだけなので、途中経過は飛ばす。


以下はデータをフィルタせず、アルゴリズムにランダムフォレスト(Multiclass Decision Forest) を使ってみた結果。

f:id:khei-fuji:20170304152419p:plain

そこそこの正答率が出ている。
誤答している箇所をピックアップしてみる。

  • 2030/1/13 祝日ではないが祝日扱い
  • 2004/10/11 祝日だが祝日でない扱い

成人の日や体育の日は第2月曜となっているため、傾向が見えにくいのだろう。

国民の祝日 - Wikipedia


そもそもインプットしているデータに「曜日」や「第2週」という概念がない。
このへんを与えれば改善するだろうか。

ということでデータセット自体を作り変えてみたのがこちら。

https://raw.githubusercontent.com/kheiakiyama/HolidayEstimation/master/holiday-with-dayofweek.csv

曜日と第何週かをデータに追記した。


ロジックは特に変えずに出した結果。

f:id:khei-fuji:20170304160915p:plain

かなり改善している。
今回はデータセット自体を自分で用意したのでデータセットを置き換えたが、本来は Data Transformation で加工する。
データの型の特徴を正しく認識されるように加工してあげる必要があることがわかった。

あとは春分秋分の日あたりに間違いが見られるが、アルゴリズムの取捨選択でどうにかならない気がする。


本来、自分で実装できることを機械学習に頼るべきではなく、規則性の見えないこと・表現できないことをやってくれるもの、という位置づけで考えておくのがいいのだろう。
今回は機械学習を理解するために人間が理解できるものを例にして取り上げた。

デプロイ

こうして作成したモデルは簡単に WebService にデプロイできる。

f:id:khei-fuji:20170305122555p:plain

WebAPI で公開されるので後は既存のサービスから呼び出すだけ。
Bot 連携程度なら AzureFunctions 使っておけばいい。


API のドキュメントも生成されている。
Swagger フォーマットはもうスタンダードになりつつあるるのだろうか。

f:id:khei-fuji:20170305122925p:plain

認証は下の画面にある Key を Header に含めるだけ。

f:id:khei-fuji:20170305123024p:plain

デプロイされたAPIトランザクション数とコンピューティング時間の従量課金となっている。

料金 - Machine Learning | Microsoft Azure


今回は AzureFunction で毎朝 API コールして結果を Slack に流すようにしてみた。 本題ではないので詳細は省く。

f:id:khei-fuji:20170305124202p:plain

3/5(日) は祝日ではないけど休日ですね。。
英語力が足りてない。

まとめ

研究者みたいに学問として学ぶのが苦にならない人は数学を着実に学び直すのはいいと思う。
しかし専門職でもない自分が、機械学習に大量の学習コストを割くという判断はしづらい。
Azure Machine Learning のように短時間でお手軽に触れるテクノロジーをうまく活用してやっていきたい。


機械学習そのものについては、これをとっかかりにしてもう少し複雑なことをやらせてみたい。
やりたいことはあるが、試行錯誤そのものよりもデータ集めるのが大変なのでどうするか迷う。

さわってわかる機械学習 Azure Macine Learning 実践ガイド

さわってわかる機械学習 Azure Macine Learning 実践ガイド

Azure+Cognitive Servicesで英語の発音を練習するWebサービスを作った

はじめに

今年から Azure により深く関わることになった。
手始めに Cognitive Services の SpeechAPI でちょっとしたWebサービスをつくった。

kheiakiyama.github.io


PCで動作確認済み。
iPhone のMobileSafariではHTML5の音声入力が動かないので動作しない。


www.microsoft.com

システム構成

趣味のサービスなのでコストがかからないように、いわゆるサーバーレスな構成。

  • フロントは GitHub Pages で静的サイトホスティング
  • バックエンドは Azure Function
  • 英語の文章はスクレイピングして結果を TableStorage に保存
    同時に QueueStorage にも登録
  • Azure Function で Queue をトリガーに Cognitive Services の Text to Speech で音声化し、BlobStorage に保存

Azure について

Cognitive Services

サイトで試しに聴いてみればわかるとおり、Text to Speech で出力した音声は自然に聴き取れる。


一方、Speech Recognition は全然自分の英語を認識してくれないので評価しづらい。
英語が堪能な人に試してもらうと認識されるので、練習あるのみ。


Speech API が $4 per 1000 calls なので、API を軸にしたサービスでペイするのはなかなか厳しそう。
あくまでも既存のサービスの満足度を高めるために利用するのがベターそう。

Azure Function

全体的にすごくよい。
Function ごとにディレクトリ切って実装するだけなので簡単。


大半が WebApps と同じ感覚で使えるので学習コストが低くて済む。
単純に REST API を簡単に作れるだけではなく、Storage をはじめとした Azure のサービスとの連携が気持ちよくできる。
たとえば Queue と Table を入力に Blob へ出力するための設定は以下のような感じ。

{
  "bindings": [
    {
      "name" : "queueItem",
      "queueName" : "speech",
      "connection" : "{queue_accesskey}",
      "type" : "queueTrigger",
      "direction" : "in"
    },
    {
      "name": "entity",
      "type": "table",
      "direction": "in",
      "tableName": "sentences",
      "partitionKey": "speech-eng",
      "rowKey": "{queueTrigger}",
      "connection": "{table_accesskey}"
    },
    {
      "name": "outBlob",
      "type": "blob",
      "direction": "out",
      "path": "speechs/{queueTrigger}.wav",
      "connection": "{blob_accesskey}"
    }
  ],
  "disabled": false
}

name に指定した名前が実装する function のパラメータ名になる。

public static async Task Run(
    string queueItem, //in queue の binding
    TableEntity entity, //in table の binding
    Stream outBlob, //out blob の binding
    TraceWriter log)
{
    //do something...
}

公式ドキュメントでは functions-triggers-bindings のあたりを読むといろんなパターンが載っている。

おそらく厳しいが、DataFactory のように今後他のパブリッククラウドとも連携されたらいいなと夢が広がる。


悪い部分をあげるとささいなレベル。
ポータル上のエディタが不便(ローカルで書けばいい)とか、下に書いたハマりポイントがあった程度。

AzureFunctions で開発するときにハマったこと - Qiita

あとがき

サービス自体について思ってること

  • もうちょっと練習に適した文章使いたい。けど本などの教材からパクるわけにもいかないので悩む。
    サイトに載せていいようなまとまった資料あったらぜひ教えてください
  • 日本語訳くらいは表示しておきたい。
  • 正答の精度もうちょっとゆるくしたい。もしくは精度自体表示する。
  • 正答率表示は回答者いないとワークしないから後で実装すべきだった。
  • というかスクレイピングによって出題が増え続けるのはよくない気がする

と書いてみたものの、こうしてブログ書くとあまりいじらなくなるのでやる保証はない。

英会話・ぜったい・音読 【続・入門編】 (CDブック)

英会話・ぜったい・音読 【続・入門編】 (CDブック)

Cookpad TechConf 2017 に参加してきた

Cookpad TechConf 2017 に行ってきた。
面白いセッションばかりだった中でも印象に残ったことを中心に書きなぐっておく。
資料は ここ にまとまっている。
動画は現時点(21日22時)ではないが公開されるはず。

感想

Cookpad under a microscope

クックパッドのレシピ投稿というビジネスモデルがフィードバックループによって成り立っているという話が面白かった。
リーンスタートアップみたいな話でサービス改善のサイクルを回すんだ!みたいな話はもうお腹いっぱいだったが、ビジネス自体もそうなっているという視点は上手く回っていることを納得させられた感ある。
ビジネスにしろ組織体制にしろ、継続的な循環が生まれていないといけないのかという気持ちになった。

Building infrastructure for our global service

ローカライズのお手本みたいな話だった。
言語だけじゃなくて文化や習慣まで考えないとダメですよ、と。
ここまでグローバルに展開していくと、たとえば日本の食品関係の企業から何かを世界に展開したいときのいいパートナーになれるかもしれなくて、よりビジネスが強固に展開されるかもしれないと妄想した。

インフラは日本版とグローバル版が分かれているとのことだった。

快適なサービス開発を支える技術

これまで公開されてきた環境整備プラスアルファ。
技術で問題を解決するを地でやってる。
セットアップやデプロイ周りなど参考にしたいことがたくさんあった。

最後に

配られてたシイタケ美味しかった。まじシイタケ。

f:id:khei-fuji:20170121223120p:plain


見守りカメラのシステムをRapberryPiで作成・運用しての感想

この記事は Raspberry Pi Advent Calendar 2016 20日目の記事です

1年前に RaspberryPi2 で室内の温度を取ってましたが、年内で単身引っ越すことになったため、家族を見守るカメラとして生まれ変わることにしました。

システム構成


おおまかな流れ

  1. Webカメラを接続したRaspberryPiを、毎日人がいるところが写るように設置
  2. motion で動体検知する
  3. motion が検知して撮影した写真ファイルをチェックして最終更新日時を保存
  4. 7,19時に「最終更新日時」をチェックして、直近1時間以内に反応があるかどうかを Slack or LINE に流す

つまり、「普段そこにいるはずの家族がいないのはおかしいんじゃない?」と投げるだけのシステムです
万が一倒れてしまったりすると動体検知しないため「いない」と判別されます


使ったWebカメラはこちら

LOGICOOL ウェブカム HD画質 120万画素 C270

LOGICOOL ウェブカム HD画質 120万画素 C270


参考

はじめてのRaspberry PIで監視カメラを作ってみた。 - Qiita


感想

セキュリティとプライバシー

  • カメラによる画像はプライバシーの塊なので、ssh などで入らない限りはファイルが見えないし、定期的にファイルは削除している
  • (まだやってないけど)画像を要求するときは Slack や LINE からBotに反応させるようにするとセキュリティ問題をプラットフォームに丸投げできてよさそう

テストの問題

  • motion の動体検知のしきい値(threshold)をどの程度にすべきかがカメラの位置、被写体に依存するのがつらい
  • 基本的に外出してなければ「いる」のが普通なのでリアルな環境だとテストしづらい
  • GrowthForecast に「いる」or「いない」を吐き出して後で追えるようにしたところ捗った
  • 多少は「いない」と誤報が出るくらいでもよさそう

微妙なバグ

バッチ職人への道は険しい


あとがき

年末年始の休みでちょっとしたことをするには RaspberryPi は手頃でよいです