機械学習プロジェクトのマネジメントの入り口 -『仕事ではじめる機械学習』を読んだ -

仕事ではじめる機械学習

ちょうど仕事で機械学習を用いた機能開発のプロジェクトの進行管理をしていて、目次をみたところ良さそうに思ったので読んでみました。 オライリーのEbookでPDF版を買ったのですが、まもなく紙版も出るようです。

まえがきには、CourseraのMachine Learningコースを受講するか、『ゼロからつくるディープラーニング』を読んでおくと良い、とありました。ぼくは直前に『ゼロからつくるディープラーニング』を読んだあとでしたが、いきなり1冊目に読んでも問題ないのではと思います。難しい数式などはあまり出てきません。とはいえ、ある程度の機械学習についての知識を持っているのが前提になっているので、少なくとも機械学習を取り扱う際によく出てくる用語の意味などはある程度知っていたほうが読みやすいと思います。

ちなみに、『ゼロからつくるディープラーニング』は初学者にとってはとても良い本で、これを丁寧に一冊読むとなんとなくディープラーニングが分かったつもりになれます。ぼくは高校から文系コースに進み、大学では国文科を卒業したゴリゴリの文系です。数式を見てもあまりピンと来ないという体たらくですが、幸いプログラマとして長年生活をしてきたおかげで、ソースコードは読めます。この本を読んで、ピンと来ない数式もPythonのソースコードで書かれたらなんとすんなり読める、ということに気づいた瞬間から、数式に対する苦手意識が消失しました。

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

『やさしく学ぶ 機械学習を理解するための数学のきほん』あたりと組み合わせて読むと、「機械学習完全にマスターした」という気持ちになって学習のテンションも跳ね上がります。

やさしく学ぶ 機械学習を理解するための数学のきほん アヤノ＆ミオと一緒に学ぶ 機械学習の理論と数学、実装まで

仕事として機械学習に取り組むのは難しい

ぼくは現在、ディレクターという立場です。自分でプロダクトのコードを書くことはありません。なので、自分が開発するというよりも、開発チームのマネージャとして機械学習のプロジェクトを成功に導く、という視点で本書『仕事ではじめる機械学習』を読みました。

実際にビジネスに寄与するための機能として機械学習を取り扱うのは難しいです。具体的には

• 高速に技術的負債が蓄積する
• 試行錯誤が必要で見積もりがしづらい
• 完了の定義が難しい

といったことがあげられると思います。これらを理解せずに、従来の「機械学習を用いないシステム開発のセオリー」しか知らない状態でプロジェクトに取り組むと、確実に失敗すると思います。

とはいえ機械学習を仕事で扱った経験のある人は少ないのも事実。どのように取り組んでいけばいいでしょうか？

機械学習プロジェクトを仕事として成功させるためには、少なくとも自分たちがどういう性質のものを扱おうとしているのか、ということを知る必要があると思います。上記の3点に対して、それぞれ

• どのようにして技術的負債が蓄積されるのか
• プロジェクトを進行するにはどのような手順があって、どのフェーズで試行錯誤が必要なのか
• 何をもって完了とするのか。または、リリース後にどのように継続的な取り組みが必要なのか

といった事柄を知り、理解しておく必要があります。

本書を読むと、これらについての概観を得ることができます。また、本書を読む以前から機械学習プロジェクトのマネージメントに取り組んでいますが、そこで経験した所感とも一致します。もう少しはやくこの本を読んでいたら、プロジェクトの最初のアプローチも変わっていたかもしれない、とも思いました。

コードを書かなくなったマネージャによってもたらされる最大の地獄は、「自分がコードを書いていた時代に経験したセオリーをいつまでも当てはめ続けることで失敗する」というものです。機械学習プロジェクトは、この世にそれを経験した人が圧倒的に少ないゆえに、このようなマネジメントの過ちが、これから最も起きやすい分野であるともいえます。

正しい知識を得て、適切にプロジェクトに取り組めるようにしておきたいですね。そういう意味では、これから仕事で機械学習に取り組んだり、取り組もうとしていたりする全人類が読んでおいても損はないかもしれません。

今年のn冊

今年読んでよかった本

サピエンス全史(上)文明の構造と人類の幸福

サピエンス全史(下)文明の構造と人類の幸福

異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養

ここは今から倫理です。 1 (ヤングジャンプコミックスDIGITAL)

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

2017年の振り返りと来年の予定

恒例の年末の個人活動の振り返りです。 去年はこういう感じでした。

daiksy.hatenablog.jp

今年は書籍を執筆したりDJデビューしたり、新しい経験ができました。仕事でもディレクターになって働き方が変わりました。 それでは月ごとに振り返っていこうと思います。

1月

特に主だった活動はしていないですね。

インスタ映えのする鴨鍋を食べたりしてました。

鴨を喰らう！！

2月

ディレクターになりました。

DevLOVE関西で登壇。心理的安全についてお話しました。 devlove-kansai.doorkeeper.jp

スライドはこちら。

ScalaMatsuriにスタッフとして参加しました。

daiksy.hatenablog.jp

3月

ヴァル研究所さんに見学に行きました。 daiksy.hatenablog.jp

スクラムブートキャンプ大阪に参加してきました。 scrumdo-kansai.connpass.com

この頃は、仕事が忙しくてめちゃくちゃ消耗していた。ゼルダが唯一の人生の癒やしでした。

4月

Scala関西Summitの会場の下見などをしていました。

あと、念願のクラフトビールの聖地ポパイに行きました。

ポパイの様子です pic.twitter.com/Qk4YzRL8fK

— だいくしー (@daiksy) 2017年4月1日

5月

会社の部活でDJデビューしました。

休日のたびにコワーキングスペースにこもって本の執筆してたのもこの頃かな。

6月

Agile Japan 2017 京都サテライト & KANJAVA PATY 2017 daiksy.hatenablog.jp

このときの発表が好評だったので、来年のRSGTやデブサミに繋がります。 ここでの発表をアレンジしたものをプロポーザルとして提出しました。

7月

Scala福岡で登壇しました。来年も行きたいです。 daiksy.hatenablog.jp

8月

夏休みに恒例のフェスに行ってました。が、ずっと雨でつらかったので来年は晴れてほしいです。 daiksy.hatenablog.jp

9月

Scala関西Summitが開催。スタッフとしてお手伝いしました。 daiksy.hatenablog.jp

人前でDJデビューしました。 smtppp.club

本が出ました。

Mackerel サーバ監視[実践]入門

10月

Web+DB Press誌にScala関西Summitのイベントレポートを書きました。

WEB+DB PRESS Vol.101

11月

10月, 11月はライブに行きまくっていました。

12月

またDJやりました。 smtppp.club

毎年恒例の合同勉強会に行きました。 gbdaitokai.connpass.com

来年

早くも来年の登壇予定がなんと3つも決まっています。 来年は30代最後の1年です。エンジニアコミュニティで活動をはじめたのが32歳のとき。30代の10年間でずいぶん遠いところに来たな、という感慨があります。とくに自分がデブサミで登壇することになるなんて、たぶん10年前の自分に言っても信じないと思います。

30代の締めくくりに相応しい1年にしつつ、次の10年のキャリアの方向性をきちんと決める1年にしたいなと思っています。

1月12日 Regional Scrum Gathering Tokyo 2018 Day2 に登壇 2018.scrumgatheringtokyo.org

2月15日 Developers Summit 2018 Day1 に登壇 event.shoeisha.jp

2月18日 Backlog World に登壇 backlog.com

スターウォーズ 最後のジェダイ 感想 (ややネタバレあり

スターウォーズ 最後のジェダイを観た。

ネタバレ無しでTwitterで雑に感想だけ書こうかと思ったが、まだ観てない人には「面白かった」「面白くなかった」の評価だけであっても先入観を与えてしまって良くないと思ったので、ゾーニングの観点でブログに雑に感想を書く。

以下、観てない人は注意

スター・ウォーズ／フォースの覚醒 (字幕版)

ローグ・ワン／スター・ウォーズ・ストーリー (字幕版)

いやーーーーー。なんか今回、微妙じゃないですか？？

予告段階から無駄に期待感を煽る「予想を超える展開」も、なるほどこういう展開にするのか、とは思ったけど別に予想の域を超えてこなかったし、ラストバトルのオチはあれでいいんですか？

インターネットでは高評価が多くて逆に戸惑っていて、正直スターウォーズとしても映画としてもまったく良さがわからなかったです。

ビールと日本酒飲んだあとのレイトショーで観たので、酒によって判断力を失っていたおそれがあるので、素面でちゃんともう1回観ておこうとは思います。

あ。デル・トロが出てるって知らなくて、なんか似てる人がいるなー、と思ったらエンドロールでデル・トロだったのはなんか、面白かったです。

ちなみにフォースの覚醒は最高、という立場です。ただ、フォースの覚醒が微妙だという人の意見は、まぁそういう意見もあるかと納得がいったけど、最後のジェダイが良かったという意見はまだ1ミリも共感できないので、とりあえず今日は朝からひたすら賛否さまざまな感想を読みまくってなんとか腹落ちさせようと苦心しているというステータスです。

たんに旧作最高で新しいものを受け入れられない老害っぽい感覚なのかもしれない。

誰か、ぼくに共感できる人、一緒に飲みに行ってくれ...。

(追記) これが良い記事だった。

theriver.jp

うーん。過去との決別というのはとても良く分かるんですけど、あまりにも決別の仕方が雑じゃないですかね。

それこそフォースの覚醒で煽った期待感をあっさり投げ捨てるのは、作劇上の意図としてはそうやりたい気持ちはわかるし、やってもいいけど、手口がちょっと観客をバカにしすぎている気がした。もう少し丁寧にひっくり返すか、いっそのことエヴァQくらい思い切って捨ててほしかったな。

年末年始、お酒の機会多いので控えつつやっていき

counting.hatelabo.jp

今年買ってよかったもの - GODJ Plus -

今週のお題「今年買ってよかったもの」

GODJ Plusシルバー フルデジタルスピーカー内蔵オールインワンポータブルDJ機器

今年買ってよかったものベスト1はGODJ Plusです。

実際にお金を払ったのは、クラウドファウンディングが開始された去年の3月だったのですが、実際に手元にきたのは今年の4月だったので、「今年買った」ということにします。

買ってなにがよかったのか

DJデビューできました。

もともと音楽が好きで、ライブやフェスに良く行っていて、気持ちのどこかにずっと「いつかはプレイヤー側になりたい」というのがありました。プレイヤーになりたいなら何か楽器を1つ練習すればいいだけなのですが、飽きっぽい性格ゆえなかなか続かずにいました。

たまたま前職の同僚でDJ活動をしている人が多かったこともあって、iPadとかMacのDJソフトでちまちま遊んだりはしつつ、GODJ Plusの前身であるGODJあたりを買って遊んでみようかなーとかぼんやり思ったりしてました。

Monster GODJ-C ポータブル DJ 機器 バッテリー駆動型 portable stand alone dj system

今の会社でDJ部なる活動がはじまり、みんながDJ活動を開始したのを機に、自分もやってみようと思いたち、ちょうどこのGODJ Plusのクラウドファウンディングが始まったのをみて勢い良くお金を振り込んだわけでした（そこから手元に来るまで1年かかりましたが）

GODJ Plusのよさは、ぼくが書くよりもBUBBLE-Bさんのこの記事が最高なので読みましょう。

weekly.ascii.jp

GODJ Plusをゲットしてから、結局3回ほど人前でDJをする機会がありました。

実はもうちょっと本格的にやりたくなってきて、DDJ-RBを購入してしまいました...。今週末に届く予定なので楽しみです...。

Pioneer DJ パイオニア / DDJ-RB DJコントローラー

ディレクターとしてのMackerel活用術 - サービスメトリックとグラフボード

これはMackerelアドベントカレンダー 3日目の記事です。

昨日は tanakahisateru さんの記事でした。

qiita.com

ぼくはMackerel開発チームのディレクターをしている、id:daiksy です。

Mackerel開発チームでは、ドッグフーディングも兼ねて様々な場面でMackerelを活用しています。今回は、ディレクターの立場での活用をご紹介したいと思います。

サービスの利用状況をMackerelでトラッキング

ディレクターとして、Mackerelというプロダクトをマネージメントしていくためには、プロダクトについての様々な数字を見ていく必要があります。プロダクトの成長戦略にも関わる部分なので、詳細をすべてお話することはできませんが、主な部分では、Mackerelがどのくらい実際に利用されているのか、というものがあります。

たとえば、Mackerelにメトリックを送っているアクティブなagentはどのくらいあるのか。それぞれどのようなOSで利用されているのか。新しくリリースした機能はどういう推移で利用が拡がっていくのか、などです。

チームでは、このような情報をMackerelのサービスメトリックを用いて可視化しています。

たとえば、上記のグラフはAWSインテグレーションの利用状況を可視化したものです。マネージドサービスごとに色分けして、利用数をグラフ化しているので、それぞれの機能のリリースタイミングによって段階的に利用者が増えていく様子が概観できます。

Mackerelの各機能がどのくらい使われているか、という情報は、Mackerelのデータベースから各機能のテーブルを参照することで件数などが取得できるので、定期的にSQLを実行して集計し、サービスメトリックへ結果をポストするスクリプトを社内で動かしています。

サービスメトリックはAPIから簡単に投稿することができます。

mackerel.io

Mackerelでサービスを作成し、サービスメトリックがまだ1件もポストされていない状態で、サービス詳細画面のサービスメトリックタブを見ていただくと、curlコマンドを使ったサービスメトリックのポストの例が表示されるので、そちらも参考にしてみてください。

サービスメトリックとグラフボードでの情報整理

はてなでは、会社全体で1つのMackerelのオーガニゼーションを利用しています。そのうえで、はてなブログやはてなブックマーク、といったプロダクトごとにMackerelの「サービス」を作成しています。Mackerel自身もそのうちの「サービス」のひとつとして管理されています。

Mackerelの「サービス」や「ロール」については以下のヘルプが詳しいです。

mackerel.io

この「サービス」には、ホストやロールのグラフとは別に、「サービスメトリック」という任意の時系列データを投稿できる機能があります。

mackerel.io

さきほどお見せしたAWSインテグレーションのグラフは、このサービスメトリックを使ってグラフ化しています。

サービスメトリックは任意の時系列データをポストできるので、Mackerelの運用にあたって、システムの健全性を確認する目的でも利用しています。たとえば、アクセスログの結果を集計し、レスポンスコードの2xx, 4xx, 5xxのそれぞれの件数を投稿。4xxや5xxのレスポンスの数が閾値を越えたらアラートを通知する、などです。

このようにサービスメトリックを使って、Mackerelでは様々な情報をグラフ化し、監視をしているのですが、ディレクターとしてサービスの利用状況を把握できるグラフだけを見たい、という用途があります。そこでぼくは、グラフボード機能を使って、自分が普段見たいグラフだけを抜き出して一覧化しています。

mackerel.io

ちなみに、これはサービスメトリックに投稿している、グラフボードの利用数の推移を可視化したグラフです。このように順調に利用が増えており、たいへん便利な機能ですので、ぜひご利用ください。

Mackerelアドベントカレンダー。明日は ore_publicさんです。よろしくお願いします。