というのをチームで議論する機会があったので、書いてみます。「うちではこうしている」とか「ここはこっちのほうがいいんじゃない?」とかあったらコメントで教えてください。 背景 / 前提 データウェアハウスのテーブルを社内に広く提供したい 初期の提供時期が過ぎてしばらくすると、要望を元にスキーマの変更や集計ロジックの変更が入る (事前にレビューはもちろんするが)SQLのミスなどで以前のバージョンに戻したいといったことがありえる 他の部門では新しいバージョンをすでに使っていて、気軽に戻せないこともある データウェアハウスのバージョンを場面に応じて複数提供できると都合がよい 一方で、大多数のデータウェアハウスのユーザーは最新バージョンの利用だけでよいはず SSOT(Single Source of Truth)になっていて欲しいわけなので... 複数バージョン見えていると「どのバージョンを使えばいい

3~4年前はモブプロにめちゃくちゃ苦手意識があったんだけど、最近はなぜか(?)モブプロを推進していく旗振りをしている。モブプロの取り組み自体については今度会社のTech Blogに書く予定だけど、このエントリでは自分の心境の変化にフォーカスを当てる。人間、数年すると割と変わるもんだなぁと思って面白かったので、記録に残しておく。 モブプロが苦手だった頃 なぜモブプロしようとなったか 今はどうモブプロしているか 所感 モブプロが苦手だった頃 前職の開発チームにいた頃(3年前くらい)で、状況はこんな感じ。 7~8人くらいの規模の開発チーム 京都と東京でそれぞれメンバーは分かれているが、まだ物理出社している時期だったので、大きなディスプレイに写された自分の画面をみんなが見るスタイル 時間は60~90分くらいだったかな タイピストはガンガン交代するスタイルではなく、1回を1~2人のタイピストで回して

そろそろ前職を退職してから、はてなで働き始めて5年(!)が経とうとしている。5年も働いていると、昔何をやっていたか、その当時どういう気持ちで働いていたかを忘れてしまう。備忘録っぽく書き残しておこう。ポエムです、長いです、大体自分向けに書いてる。 NTT CS研 => 株式会社はてな チーム開発への適応 インフラ苦手意識の克服 教師なし機械学習の本番環境での運用 データ基盤とCustomer Reliability Engineerへの挑戦 今後はデータエンジニアリング NTT CS研 => 株式会社はてな 基礎研究職からWebアプリケーションエンジニアへの転職だった。ログを残しておくと、こういう時に振り返れて便利。 NTT CS研を退職して、株式会社はてなに入社しました - yasuhisa's blog 割と珍しい(?)転職ではあったかもしれないが、機械学習や自然言語処理はアルゴリズム単

こういう風に投稿すると(左)、esa.ioにこういう感じ(右)で投稿される分報風のアプリを自分用に年末年始に作りました。 作った動機 使った要素技術 Firebase Authentication Firebase Hosting + React Firebase Cloud Functions デプロイ自動化 所感 作った動機 きっと皆さんそうしているように、私も日々ログを残しながら作業をしている。仕事ではscrapboxを使っているが、プライベートではesa.ioを愛用している。プレビューを見つつmarkdownで書けたり、タグとカテゴリがいい感じに使えたりするところが気に入っている。あと、アイコンがかわいい。 ちゃんと作業をするときにはesa.ioにページを作るが、そうでない雑なものも記録したいときが度々ある。例えばこういうの。 今度コンビニ行ったとき、忘れずにXXXを買う 統計の本

去年に引き続き、東京都立大学の非常勤講師の依頼をid:mamorukさん(小町先生)からして頂いたので、今年も講義を担当してきました。講義の内容としては Mackerelでのロール内異常検知を題材に、機械学習をプロダクトに取り込んでいく際、どういった視点が必要になるのか 実際の開発はどういった形式やツールで行なわれているのか、擬似的に体験してもらう といった内容(講義 & 演習)で行ないました。内容としては昨年とほぼ一緒ですが、新型コロナウイルスの影響で演習パートがオフラインの対面ではなく、オンラインで行なう点が一番違いました。演習系のサポートは学生さんの手元の環境がそれぞれ違う、などあって去年も苦戦しました。今年は同じ感じでいくとさらに大変そう(というか見切れない...)だろうなと思って、やり方を考えてみました。 他にいいやり方があったら誰か教えて & 自分用の今後*1のメモという感じの

FAQサイト、サポート問い合わせをせずとも自分で疑問を解決できて便利ですよね。でも、検索した単語が一件もヒットしないと、ちょっとガッカリしてしまします。そういったガッカリを減らすために、簡単なデータ分析を使ってFAQサイトを継続的に改善する話を書いてみます。 ...というのも、自分が仕事で関わっているMackerelでは最近FAQをリニューアルしたからなのでした。 MackerelのFAQではZendesk Guideを利用していますが、Zendesk Guideは便利なAPIが用意されているので、それと既存のデータ基盤を組み合わせて改善していく形です。 FAQサイト内の検索語を列挙する まず、FAQサイト内でどういった単語が検索されているのかを列挙します。Google Tag Manager経由でFirebase Analyticsにデータを飛ばすと閲覧状況が分かりますが、そのログをBi

第3回 データアーキテクト（データ整備人）を”前向きに”考える会という勉強会で、CREとしてデータ基盤を整備する活動についてオンライン登壇しました。 カスタマーサクセスのためのデータ整備人の活動記録 from syou6162 イベント登壇はまあまあやってきたはずなんですが、今回の登壇は初めて要素が満載でした。 CREとして初めての登壇 これまでは研究者 or アプリケーションエンジニアとして登壇 今年の2月にCREになったばかりなので、私がCREについて語ってもいいんかいな...みたいなところはありますよね と言いつつ、偉そうに語ってしまった データ基盤に関する初めての登壇 これまでは機械学習や自然言語処理に関する登壇がメイン 関連: データに関連するいくつかの見方と私 - yasuhisa's blog 初めてのオンライン登壇 意図せず(?)YouTuberデビューを果してしまった..

2020/02からMackerelチームのCRE (Customer Reliability Engineer) になりました。もうちょっと早くエントリを書く予定でしたが、職種が変わった & 期初であれこれイベントが多いということで遅くなってしまった...。 CREになろうと思ったきっかけ 一番大きいきっかけはid:missasanと前期一緒に働けたことだろうなぁと思います。id:missasanはCREであり、現在はCREチームのマネージャーをされています。私がアプリケーションエンジニアとして働いていたとき、id:missasanを含むCREとももちろん一緒に仕事をしていたわけ*1ですが、大きくタスクフォースを一緒に組んで仕事をするといったことはあまりありませんでした。そんな中、今年の夏にid:missasanが通称赤本の読書会をチーム内で始めたので、私もほぼ毎回参加しました。 カスタマ

インフラやミドルウェアにとにかく苦手意識があるが、仕事的にいつまでもそう言ってられない。そこで、最悪全部ぶっ壊れても大丈夫な砂場を作り、そこを土台に活動をするというのを2018年の目標に設定していた。 結構な時間をかけたこともあり、それなりの砂場と活動ができて、自分としても勉強になってよかった点が多かったので振り返りを書きます。一個一個ちゃんとエントリ書いていたので、振り返りが楽で助かった。 完成系はML Newsだけど、2018年1月時点では そもそもWebアプリですらなくCLIアプリだった データの管理もデータベースではなくテキストファイル という素朴な作りだった。 インフラ編 最初はCLIアプリをWebアプリにする活動をやったが、その後はAWS上にインフラ部分の構築を進めた。 次に一台のEC2をAWSコンソールから立てて、sshでログインしてyumコマンドを打って...という10年前

現在仕事で作っている異常検知システムについてPyCon mini Osakaで登壇してきました。異常検知というマイナーなトピックですが、多くの人に聞いてもらえてよかったです。 #pyconjp #pyconosaka 「Pythonを用いた異常検知システム構築の裏側」 吉田康久さんです！ たしかはてなの人だったはず。 pic.twitter.com/hRacSgV59D— PyCon mini Osaka (@OsakaPyConMini) 2018年5月19日 はい、はてなのMackerelチームの中の人です。 機械学習の人からすると「なんだただの混合ガウス分布か」と思われるかもしれませんが、異常検知のシステムを実際に作ろうとすると考えることが色々あります。今回の発表では ユーザーのどのような要望から異常検知機能を作るに至ったか 異常検知とはそもそも何か、どういった問題設定か 異常検知手

最近、社内勉強会で機械学習についてエンジニアに説明する機会があり、その際にKaggleについても説明しました。一方で うーん、「Kaggler はパラメータチューニングやアンサンブル等の自明でインクリメンタルな改善『しか』できない」というような誤解はどうやって解いていけばいいんだろう。— im132nd (@im132nd) 2018年4月4日 という話もあり、(特にデータサイエンティスト以外の職種の人が)Kaggleをやる意義/メリットについてまとめてみました。ガッと勢いで書いたので、項目に結構被りがあります。なお、書いている本人はKaggleほぼ初心者であまり説得力がないです。Kaggle Masterの人がもっといいエントリを書いてくれるのを期待しています、議論の叩き台エントリです!! Kaggleをやる意義/メリット 様々なデータセットを触ることができる kernelでデータ分析の

機械学習の中でもマイナーなテーマであろう異常検知がテーマの勉強会、異常検知ナイトというイベントでLTの登壇をしてきました。マイナーテーマなのに300人以上が集まる東京怖い。 3ページしかないですが、発表資料も置いておきます(LTのレギュレーションで3ページ5分)。 異常検知ナイト LT登壇資料 はてな id:syou6162 from syou6162 LTのテーマは、現在自分がどんなデータで異常検知をやっているか、どういう困り事があるかを発表してプロの方からアドバイスをもらおうというものです。Mackerelで今まさに異常検知機能の開発をしていて、時系列周りのモデルのハイパーパラメータを開発データでチューニンングしたいけれども、そもそも異常データを含む開発データって手に入らないことが多くてどう対応していくのがよいのか?という質問をさせてもらいました。プロからのアドバイスは動画で見れるので

背景 半年前から機械学習に関するよさそうなエントリを提示してくれるbot(ML君)を運用しています。 大量のtweetの中から関連するエントリを人手で探す手間は省けるようになったのですが、最近別の問題が起こっています。以下の画像はある日に提示されたエントリの結果ですが、arxivの論文(しかもほぼ深層学習関連のもの)ばかりになっています…。ML君はURLが与えられたときに、それが機械学習に関連するいいエントリかどうかを判定しますが、提示したエントリの話題が重複しているなど条件は全く考慮していないので、当然と言えば当然の結果です。ML君を責めてはいけない。 上のような推薦結果は私が深層学習研究者/エンジニアなら喜ぶかもしれませんが、残念ながらそうではありません。機械学習/自然言語処理に関連する企業のニュース/githubのライブラリなど、色々なトピックについてカバーして欲しいものです。問題設

サービスに機械学習技術(例えばSVM)を入れる際に、「この機械学習技術は本番サービスに投入しても大丈夫なものか?」を考える基準がまとまっていると人に説明するときに便利だなとふと思ったのでまとめてみました。散々言われ尽くされている話だとは思います。 前提 考慮に入る採用基準 予測精度 (コードの)メンテナンスの容易性 計算オーダー 学習時 予測時 挙動のコントロールのしやすさ/予測説明性の容易さ チューニングの必要性 その他 まとめ 前提 機械学習がプロダクトの主要な武器になる(例えば最近話題になっているGoogle翻訳におけるNMT)ものではなく、サービスにデータがまずあり、機械学習でデータを活用することにより、そのサービスを支えていくようなものを前提に考えています(例えばCGMサービスのスパム判定)。また、投稿内容は私個人の意見であり、所属組織を代表するものではありませんとお断りしておき

社内で機械学習の案件があった際に、機械学習の経験者しか担当できないと後々の引き継ぎで問題が起こりがちです。これを防ぐために、機械学習に興味があり、これまで機械学習を経験したことがないエンジニアにも担当できる体制を整えられることが望ましいです。しかし、機械学習のことに詳しく知らないディレクターやエンジニアにとっては、どのような機械学習の理解段階ならばタスクを任せられるかの判断をするのはなかなか困難です。そこで、このエントリでは機械学習を実タスクでやるまでに乗り越えるべき壁だと私が思っているものについて説明します。 第一の壁: 綺麗なデータで機械学習の問題を解ける 講義で扱われるような綺麗なデータを扱える 行列形式になっていて、欠損値や異常値もない 上記のデータを回帰や分類問題として解くことができる 実際に解く際にはライブラリを使って解いてよい 手法を評価する上で何を行なえばよいか(Preci

自然言語の誤りを指摘してくれるRedPenを手元で使えるようにしてみました、という記事です。気が向いたので、色々書いてみました。 エンジニアであっても意外と文書を書いたり見たりする機会が多い 自然言語も機械が勝手に間違いを指摘して欲しい 自然言語もルールで分かることは機械(RedPen)に指摘してもらう 指摘例 EmacsからRedPenを使う まとめ エンジニアであっても意外と文書を書いたり見たりする機会が多い エンジニアとしてはてなに入社後、コードレビューをする機会はもちろん多いですが、意外と自然言語(私の場合は日本語、英語がメイン)のレビューをする機会も多いことに気が付きました。他人の書いた文書に対するレビューに限らず、自分の書いた文書に対するレビューも含みます。 告知文のチェック mackerelでは毎週告知をブログに書くので、エンジニアも内容をレビューする こういうやつ: mkr

社内の機械学習勉強会で最近話題になった機械学習関連のエントリを取り上げているのですが、ここ一ヶ月ではGoogle Neural Machine Translation(GNMT)がとても話題になっていました。GNMTで使われているEncoder-Decoderやattentionのような仕組みを直近で使う予定は特にはないですが、機械学習を使うエンジニアとして知っておいて損はないし、技術的に何が変わったことにより何ができるようになって、何はまだできないのかを知ろう、というのが目的です。技術的な項目は興味ない人も多そうなので、最後に持っていきました。 Google Neural Machine Translation(GNMT)の最近の進化について できるようになったこと 定量的な評価 まだまだ難しいこと 技術的な詳細 Encoder-decoder Attention based encod