Azure Machine Learningが便利なことを布教したい

おはようございます。 スモールビジネスAIラボ 研究員のKenji Usuiです。

クラウド機械学習流行りですね。かく言う私も最近使い始めたらその便利さにハマってしまいました。
ここではメインで使っているAzure Machine Learning(以下Azure ML)の良さについて語っていきます。

Azure Machine Learningのここがよい

私がメインで使っているクラウド機械学習ツールはAzure MLです。なぜAzure MLを選んだかというとザックリ次の3点が大きな理由になります。

  1. GUIが使いやすい and わかりやすい
  2. 簡単にWebサービスとしてデプロイできる
  3. SQLやPythonも使える

それぞれ詳細を説明していきます。

1. GUIが使いやすい and わかりやすい

モデル構築は試行錯誤の繰り返しなのでサクサク変えていけると楽です。
その点ではGUIは非常に便利でAzure MLはGUI上でユニットを変えるだけで処理を変更することができます。後で見返してもわかりやすいのも良いですね。加えてテスト結果を可視化してくれます。これが見やすくてカッコイイのでそのままドキュメントに使えます。
便利ですね。 f:id:Grahamian:20170726145935p:plain

2. 簡単にWebサービスとしてデプロイできる

Azure MLは学習したモデルを5分でwebサービス化できます。しかもスケーラブル。
学習のために設計した状態からほぼ自動でwebサービスへ変換することができます。
f:id:Grahamian:20170726154043p:plain 学習器を使うためにコードを書く必要もありません。普通だとwebサービス化やその保守に手間がかかってしまいますが、これを圧倒的に短縮できます。
呼び出しもREST APIなので簡便でJSONを渡すかcsvを渡してバッチ処理できます。
便利ですね。

3. SQLやPythonも使える

前処理をちまちまと変更しながらテストしたいことは多々あると思うのですが、これもクラウドで完結できます。
Azure MLはデータをSQLで抽出したりPythonで簡単な処理を追加したりできます。またPythonのライブラリとしてAnacondaが用意されています。これを使って大概の処理はできるためローカルと変わらない処理をクラウド上で完結することができます。地味ですがこの機能のおかげて痒いとこに手が届きます。
便利ですね。

Azure Machine Learningのここが気になる

機械学習アルゴリズム自体を変更できない自由度の低さは悪い点かもしれません。
f:id:Grahamian:20170726151407p:plain
↑こんな感じにAzure ML上ではパラメータチューニングはできますがアルゴリズムの変更はできません。Neural Networkもhidden layerの数やnodeの数を変更することはできますが複雑な変更はできません。「既存のアルゴリズムを改修したい!」「新しい論文のアルゴリズムを実装したい!」というのはほぼ無理です。
これはAzure MLがコモディティ化した技術を簡単に扱えるようにするツールなので方向性が違うのだろうな、と思います。Deep Learningをガッツリ活用するならAzure MLではなくコードを書いてスクラッチするか、用途に合うものが有るならばGoogleの学習済みAPIを使うのが良いと思います。
加えてUIがモッサリすることがちょっと気になりました。そのため前処理のテストなど「処理は軽いけどトライ&エラーが多い」みたいなケースはローカルで処理するほうが早いことがあります。

Azure Machine Learningはいいぞ

Azure MLを用いることで多くのビジネス課題の解決やプロダクトへの応用が手軽かつ高速に行えます。
最先端の機械学習技術を用いたプロダクトには向きませんが、多くのビジネス課題やデータ分類にはAzure ML上のアルゴリズムで十分です。機械学習のコモディティ化がよく話題になりますがAzure MLはそれを具現化したツールだと感じます。
エンジニアリングで効率化のためにツールを活用しているように、AIラボでは機械学習の場面でも最新のツールをガンガン活用していきます!

GYOMU Hackers Night vol.2をセールスフォース・ドットコム様のオフィスで開催しました

どうも、こんにちは。freeeでGYOMUハックという社内の業務改善系エンジニアをしている廣野です。

4月にfreeeとビズリーチさんで協力して、業務改善系エンジニアを集めたGYOMU Hackers Guildというコミュニティーを立ち上げました。経緯としては、社内に閉じがちになってしまう社内向けシステムを触るエンジニアが、同じような悩みを抱えているのではないかと考え、それを相談して、さらなる高みに行けるような集まりができればいいなと考えたことがきっかけでした。

そして先日、セールスフォース・ドットコム様のオフィスをお借りして、GYOMU Hackers Night vol.2を開催したので、その様子を紹介します。

peatix.com

Lightning Talk

LTは株式会社LIFULL・藤原裕也さんとランサーズ株式会社・土屋雅彰さんに発表していただきました。 LIFULL藤原さんは、Salesforceと業務システムを連携した業務改善の事例、ランサーズ土屋さんはコミュニケーションツールとSalesforceを連携したコミュニケーションの改善の事例を発表してくださいました。 とても参考になる内容でした!

f:id:mirygoaround:20170627201344p:plain

発表資料については、GYOMU Hackers GuildのFacebookページで公開されているのでぜひご覧ください。

パネルトーク

vol1のときは、テーブルトークがメインでしたが、今回は趣向を変えてコミュニケーションをテーマにしてビジネスチーム側、エンジニアチーム側にわかれてのパネルトークを行いました。

ファシリテーターはコードキャンプ株式会社・矢野目佳太さん(写真一番右)、 ビジネスチーム側パネリストは株式会社ビズリーチ・白石剛爾さん、freee株式会社・坪井亜美、エンジニアチーム側パネリストは株式会社ビズリーチ・田中聡さん、freee株式会社・廣野美里、でした。(写真の左から名前順) f:id:mirygoaround:20170627141846p:plain

パネルトークではビジネスチーム側とエンジニアチーム側の感じ方の違いと歩み寄り方について、盛り上がりました。

ここが変だよエンジニアチーム

1.要件の持ち込み

坪井:エンジニアとビジネスサイドでは時間間隔が違う。ビジネスサイドでは明日から効果測定したいのに数週間かかると言われてしまう。そのスピード感では次の施策が決められない。

白石:エンジニアからそもそもそんなことはできないと言われることもある。ビジネスサイドの説明が足りていないのは自覚しているが、汲み取って欲しい。

坪井:ビジネスサイドで内容を6割くらい考えて持っていっても、エンジニアから要件がわからないと撥ねられる。

田中:エンジニアとしては、依頼されたその数字が見えることでどうなるのかが分からない。可視化した先が知りたい。

廣野:エンジニアサイドからするとシステム要件よりも何をやりたいのか言って欲しい。毎回依頼が来るたびにビジネスサイドにヒアリングすることになる。

坪井:スピード感が大事だからと、ビジネスサイドでやりたいことでできることを全部やってたら、Salesforceが散らかってしまった。

廣野:そして余計に闇が広がるんだよね……笑。

2.ビジネスサイドとのコミュニケーション

廣野:ビジネスサイドからの依頼はJIRAで来るが、文字のコミュニケーションが辛い。依頼をもらった時点で対面でのコミュニケーションをしに行く。

田中:自分も同様。文字では相手の感情が分からない

3.エンジニアからの歩み寄り

田中:エンジニア的にスピード感が必要だと感じたら、PDCAサイクルを回すために一旦要件の曖昧さは度外視する。 →実装/運用後にビジネスサイドからフィードバックをもらい、目的がずれていないことを確認している。

4.具体性が分からない要件への対応について

白石:相談という形で、一旦エンジニアサイドに話を聞いている。話を聞いてくれ、対応案を出してくれるので助かっている。

廣野:エンジニアとしても要件がふわっとしているなら、具体的な依頼ではなく相談なのだと伝えてくれると嬉しい。

田中:エンジニアもビジネスサイドの情報を常に収集し、先にビジネスサイドに働きかけるようにしている。

ここが変だよビジネスチーム

1.施策の実行について

廣野:ビジネスサイドは短期間にたくさんの施策が実施されては無くなっていくのでそのスピードについていくのが大変。それに、それぞれのステークホルダーが分からない。

坪井:数が多すぎて、ビジネスサイドもよく分かっていない。

廣野:組織全体として、うまいやり方をするために体制から考える必要もあると思う。

コミュニケーションをより良くするために……

白石:ビジネスサイドとしてはコミュニケーションとリソースの調整が大事。役割とスケジュールをはっきりさせる。分からないことは積極的にコミュニケーションを取って溝を解消していく。

坪井:エンジニアに完璧を求めすぎない。ビジネスサイドもSalesforceが使えることが一種の営業スキルだという想いで自ら学ぶことも怠らない。

廣野:ビジネスサイドから相談が来た場合は、他にも同様の件で困っている人がいるのではないかと意識しながらフォローに入る。

田中:使うのはあくまでもビジネスサイドのメンバー。使っているビジネスサイドの業務フローや各場面での使われ方を知っておく。

ー結論ー:ビジネスサイドとエンジニアサイドがそれぞれ歩み寄ることが大事!!

Q&A

Q:YES/NOしか答えてくれないエンジニアにはどうコミュニケ―ションを取れば良いか?

A:廣野:かつてリソース面で対応ができなかった場面があった。自分はYES/NOだけでは答えないよう心がけている。なんでNOなのか、なんでYESなのかの理由もセットで聞くと良いのではないか。

  田中:ミスを恐れて、確実に対応できるものでないとYESと言いづらいのかもしれない。その方の上司も巻き込んでコミュニケーションを図ることが良いかもしれない。

こんなかんじで、かなり盛り上がったパネルトークとなりました。

テーブルトーク

そのままの流れでコミュニケーションをテーマにしたテーブルトークを実施。ものすごく盛り上がっていて、真剣に話されていました。同じ悩みを抱える方は多いみたいでした。

次回

次回のGYOMU Hackers Night vol.3は8/23にビズリーチさんのオフィスで行います! ご興味のある方はぜひご参加ください!!!

詳細はGYOMU Hackers GuildのFacebookページにてご連絡いたします。

New Relic で取得したデータや独自に集計したパフォーマンスログを Re:dash で可視化する

こんにちは、エンジニアの foostan です。 freee では法人向けの決算や申告まわりの開発を主に行っています。

先日「【AWS・New Relic・freee】合同セミナー AWSで実現するクラウド・ネイティブ ITサービス」というイベントに登壇して来ましたのでまずはその報告をさせて頂きます。

私の発表内容の概要は以下のとおりです。

freeeのクラウドサービス活用術とパフォーマンス改善活動のご紹介

freeeでは会計freeeや給与計算freeeなどのクラウドサービスを開発・運営していますが、実際にはAWSやNew Relicといった様々なクラウドサービスを活用しています。freeeでのクラウドサービス活用術として、いくつか事例を交えながら紹介したいと思います。またサーバのレスポンスタイムの改善にフォーカスして、どのように行っているかをより具体的に、技術的な観点と組織的な観点でご紹介いたします。

発表で使用したスライドが少々長いので、本ブログでは事例をひとつピックアップしてご紹介します。 なお、パフォーマンス改善活動については昨年のアドベントカレンダーに投稿しましたので、よろしければこちらも御覧ください。

qiita.com

パフォーマンスログを Re:dash で可視化する

freee ではパフォーマンスを測る指標として New Relic で取得したデータや独自に集計したログを用いており、それらを Re:dash で閲覧できます。

f:id:foostan:20170621012225p:plain

New Relic のデータを Re:dash で可視化する

New Relic のデータは保存期間が短く、APMBrowser の場合は PRO 版にしても最大で 90 日までです。 また Insights を利用すると独自のグラフとダッシュボードを作成することが出来ますが、こちらは最大で 8 日までです*1

パフォーマンスを中長期的に監視したい場合これだけの期間しか見れないとなると少々物足りません。 またダッシュボードを作るにしても New Relic 以外から取得したデータも一緒に見たい場合は Insights では実現できません。

そこで freee では New Relic のデータを API で取得し、そのデータを Redshift に取り込んで Re:dash で可視化できる仕組みを作りました。 技術的に難しい点はあまりなく既存のツールやサービスの組み合わせだけで実現できました。

具体的には以下のようなグラフなどを作成し、日々の改善に利用しています。

f:id:foostan:20170621020048p:plain

独自に集計したパフォーマンスログを Re:dash で可視化する

サービスをご利用して頂いている事業所毎に扱うデータ量は異なるため、それに伴いパフォーマンスも事業所毎で異なってきます。 freee では Controller/Action *2 毎のプロセスタイムをログとして取っていますが、パフォーマンスを監視/改善するにあたって事業所のIDを付与しています。 またそのログは fluentd 経由で S3 に保存され、最終的に Redshift に取り込まれて Re:dash で可視化できるようになっています。

具体的には以下のように事業所の特徴毎に分類してパフォーマンスを監視しています。

f:id:foostan:20170621021727p:plain

最後に

イベントではクラウドサービスの活用事例の紹介ということでいくつか挙げさせて頂きましたが、どれもトリッキーな使い方はしておらず、シンプルな組み合わせで利用しています。 会場にいらした方々やこれを見ている方々にとって少しでもご参考になれば幸いです。

freee では既存のサービスを組み合わせて効率化したり、パフォーマンスを改善するのが好きな仲間を募集しています!

発表で使用したスライドはこちらになります。

*1:https://newrelic.nissho-ele.co.jp/price (代理店などにより多少異なります)

*2:Ruby on Rails の Controller/Action のこと

独学学生プログラマがサマーインターンに参加してから新卒入社するまで

 こんにちは。4月にfreeeの2017年新卒エンジニアとして入社したtaiyoです。私はfreee新卒エンジニア一期生であり、freeeが2015年に初めて実施したエンジニアサマーインターンの参加者でもあります。今回は、freeeの新人エンジニア育成の特徴を含めながら、私がサマーインターンに参加してから新卒入社した現在までについてお届けします。

我流でプログラムを書いていたインターン参加前

 freeeのサマーインターンに参加する以前は、サークルでのLaravel(PHP)を使ったWebサービスの運営やScrapy(Python)を使ったWebスクレイパーを開発したりしているエンジニア初学者でした。 ザ・我流で作っていたスクレイパーなどはお世辞にも分割されているキレイなコードと言えず、コードや開発プロセスのお作法的なことも全く知らなかったため、ただ動くものを愚直に作っていたという感じでした。

 そんな「とりあえず動くけど決して綺麗とは言い難いし、何より改善を入れづらい」ものが手元にあって、何から手をつけていいのかモヤモヤしていた中で、freeeのサマーインターンの募集を見つけました。

 募集要項には、「実際に本番で動いているサービスの改善をしてもらいます。」とあり、私は「これだ!」と思い、即座に応募しました。本職のエンジニアが作るプログラムはどうなっているのか知りたい、そこから今手元にあるプログラムの改善のヒントを得ることができないだろうかと考えたからです。後日参加承認のメールが来て、参加することになりました。

改めて井の中の蛙であることを知る

 私が参加した2015年のfreeeのエンジニアサマーインターンは、参加人数3人、実施期間3日間で、freeeが提供する「会社設立freee」の機能追加や改善タスクをそれぞれがこなし、出したプルリクエストをメンターにレビューしてもらうという内容でした。

 RubyもRailsも初心者だった私ですが、さすがに別言語だけどWebフレームワーク使ったことあるし、全く分からないということはないだろうと思っていました。しかし現実はそう甘くはありませんでした。

 初めて見る、企業が提供するサービスのコードに対して初めに抱いたことは、とにかくデカイということです。そこまで大きなプログラムに触れたことがなく、特にエディタの機能を使いこなせていた訳でもなかった当時の私は、タスクに関係するコードの箇所を特定するのに時間を費やしてしまいました。Rails初心者であったことも作用してたのかもしれませんが、それでも時間をかけすぎだと強く思っていました。

 次に思ったことは、当時の自分が想像していた以上に、様々なことを考慮して開発を進めていく必要があるということです。インフラ、パフォーマンス、設計、コード規約など、ボトルネックや割れ窓を作らないために工夫してやっていく必要がある訳ですが、当時のタスクでは今も迷うことがある”命名”に関してかなり突っ込まれていました。

 個人で開発しているものでは「自分さえ分かれば」「動きさえすれば」と心のどこかでおざなりにしていたところがありましたが、チーム開発となるとそうはいきません。他にも多くの観点でレビューをもらって、学びに繋がりました。

 そして、最終的にリリースまでたどり着いた私のタスクは2つでした。3日で2つです。もらったレビューの数はそこまで大きくないPR3つの合計で60を超えていました。コードとは少し離れたチーム開発でのお作法的な部分も含まれています。私は完全に打ちのめされました。「全然何も知らないやん僕」と率直に感じました。

インターン成果発表ギリギリまで作業を続ける様子

弟子入りから現在

 サマーインターン後、打ちのめされた私は弟子入りするような形でfreeeの長期インターンとして入社させてもらいました。ビクビクしながらも必死で喰らいついていったところ、段々とレベルアップしていく形で多くのタスクを任せてもらえました。

 スタイル崩れを修正するものから始まり、メインサービス外のフォームのUX改善や機能追加、会計freee内の新機能の要件定義からReact + Fluxを使ったSPAでの機能実装&リリースまで、Go製のサードパーティのエンジンバージョンアップと機能追加などなど。1年半で数多くのタスクをやってきましたが、まさかRubyやJavascriptだけでなくGoまで触ることができるとは思っていませんでした。

 freeeのインターンのよいところは、上記のように大きなタスクをインターンでも任せてくれるところだと思います。これは、エンジニアチーム内でレビューをしっかり通す体制だからこそ実現できていることであり、freeeのインターンの大きな特徴です。

 サマーインターンでも同様ですが、実際に稼働している大規模サービスを触るからこそ得られる知識&経験があり、さらにそれに受けるレビューからも多くのことを学ぶことができるのだと思っています。これは学生という環境ではなかなか得ることのできない機会なのではないでしょうか。

 この記事を書くためにサマーインターンの時のプルリクエストから振り返っていたんですが、全然できない頃の自分がそこにはいて、その自分と今の自分比べると少なからずのギャップが感じられました。もちろんエンジニアとしての力は圧倒的に足りませんが、少なくともここまでやってきた分の成長を感じることができています。

新卒入社式

 そんなfreeeの短期&長期インターンを経て新卒入社した現在は、会計freeeのコアなエンジンをエボリューションするプロジェクトチームに配属され、主にGoとRubyを書いています。

 このプロジェクトは少し前に立ち上がった新規プロジェクトで、エンジニアチームを含め全社から注目されています。優秀なエンジニアに囲まれ、再び打ちのめされている日々ですが、これまでのインターンで経験したことのない経験を更に得ることができています。ここでの経験は自分のエンジニアとしてのキャリアにとって大きな財産になると確信もしています。やっていくぞーー!

社内でチームを組んで参加した駅伝大会

パワーアップした2017年サマーインターン

 そんなわけで、今年もfreeeではエンジニア/デザイナーサマーインターンを実施します。今年のサマーインターンは一昨年や去年のものからパワーアップしたところが2つあるんです。

 一つは配属チームです。これまでは基本的に会計freeeや会社設立freeeの開発チームがメインでしたが、今回はエンジニアのチーム全てで受け入れる体制を作ります。人事労務freeeの開発チーム、モバイルチーム、インフラチーム、デザイナーを含めたエンジニア内の全チームに配属される可能性があります。

 自分はモバイルアプリの開発はできるつもりだけどどれだけ通用するのか試したい、自分の専攻はインフラだけどアプリケーション側の実装もしてみたいなど、多くの学生の要望に応えられるよう準備を進めています。

 二つ目はメンターの数です。これまでのサマーインターンではインターン生3人につきメンター1人がついていましたが、今回はインターン生1人につきメンターが1人つくようになります。マンツーマンです。一週間という期間で可能な限りワザを盗んでください。

 最後になりますが、freeeが提供するインターンは、学生の期間では中々得られない経験を提供できる機会だと思っています。皆さんの成長機会としてぜひ活用していただければ幸いです。ご参加お待ちしております!

応募はこちら

jobs.freee.co.jp