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

エンジニアも「飛び込み経理」を経験した新卒研修

こんにちは。今年の4月にfreee株式会社のエンジニア新卒1期生として入社したkotegawaです。 今回はfreeeの新卒研修の内容をご紹介した上で、その感想をお伝えしたいと思います。

エンジニアは今年が第1期!freee新卒研修の概要

今年の新卒研修の最初の2週間は、ビジネス職で採用された新卒も含め、15人の同期たちと一緒に研修を受けることとなりました。

f:id:ymrl:20170403185305j:plain 新卒15人と社長の佐々木大輔

最初の1週目はfreeeの基礎知識や部署の紹介など、基礎的な内容の研修を受けましたが、研修の目玉コンテンツは2週目でした。 その内容は、「freeeを導入していない企業に1週間常駐し、実際のバックオフィス業務を体験させて頂く」というものです。

なぜ「freeeを導入してない企業」か

近年、freeeは多くの企業に導入していただいていますが、まだまだバックオフィス業務のスタンダードになれているというわけではありません。 そこで、バックオフィス業務がどんなものか、リアルを知ることができるだろう、という意図から「freeeを導入していない企業」に常駐させていただくという内容の研修になりました。

正直、研修を受ける前は「研修を早く終わらせてコード書きたい」という思いでいっぱいでした。 しかし、この研修2週目の大胆で実践的な内容を聞いてからは、「この会社やっぱり面白いな」と感じると共に、常駐研修が楽しみになりました。

バックオフィス常駐研修の具体的な内容

バックオフィス常駐研修をスタートするにあたり、freeeからの「こんなスケジュールで〇〇をしてきてください」というような具体的な指示はありませんでした。

研修担当の社員から伝えられたのは、「全力で業務を手伝わせてもらって、学んだことをプレゼン資料とレポートに落とし込んでこい」ということくらいです。

常駐研修では15人の新卒同期が6つのグループに分けられ、それぞれ別々の会社に訪問させて頂くことになりました。(チーム構成は、エンジニアとビジネス職の新卒が満遍なく振り分けられていました。)

訪問先の6社は、

  • 飲食店におしぼりをレンタルする会社
  • 個人指導塾
  • 印刷会社

など、それぞれ業種や規模もバラバラです。

僕達のグループは、僕のほかにビジネス職の2人を加えた3人で、株式会社ビデオマーケットという映像配信のWebサービスを行っている会社に常駐することとなりました。

1週間の常駐期間でやったこと

常駐期間中に行ったのは、主に次の2つです。

  1. バックオフィス業務のお手伝い
  2. 日頃のバックオフィス業務についてのヒアリング

お手伝いした業務はどれも大変でした。 しかし、手伝った領域は経理や人事業務のまだほんの一部だと考えると、バックオフィス業務に携わる方の忙しさは想像以上だと感じました。

たとえば印象に残っているのはビデオの仕分け作業。

f:id:kote15:20170511162256j:plain ビデオ仕分け作業の様子

写真に載っている物だけでも、段ボールの中を含めて1000本以上のマスターテープがあります。

これらのテープがどの段ボールに入っているかを管理するために、一つ一つExcelに記載する作業を、半日ほど掛けて行いました。

業務効率化の提案も

他にも様々な業務を体験させて頂きましたが、その体験を通じて実際に業務を効率化してもらえるような提案もさせていただきました。

具体的にいうと、「押印管理票」という紙と印鑑で管理されている台帳を、紙を使わずにGoogleフォーム・スプレッドシートだけの管理に変えていただけたことです。

Googleフォームに書いたものがGoogleスプレッドシートに転記されるだけの簡単なものですが、実際に経理の方にご紹介し作って活用して頂いた所、いつでもどこでも更新や保存、承認ができるクラウドの簡単さを実感して頂けました。

f:id:kote15:20170511161937p:plain 紙で書いていた情報をGoogleフォームに(イメージ)

実際のところ、研修に行く前の僕は「世の中から紙をなくしたい」「全部クラウドにしたほうが絶対効率的だ」というような思いを持っていました。

ただ外部の会社さまでの常駐研修を通じて実際に業務の全体像を見た時に、紙や印鑑を使ったほうが効率的であったり、法律的にクラウド化するのが難しいところがたくさんあるということを知りました。

そんな中で業務の一部分だけ切り取ってクラウド化してもらったとしても、効果は限定的かもしれません。

ですが、情報を管理する方法の1つとして、クラウドという手段があると実感して頂いたことには価値があると思っています。

なによりも、実際にフォームを作っていただいた経理の福原様に、「色々なことに応用できそうだね」と笑って喜んで頂けたのが嬉しかったです。

f:id:kote15:20170511161605p:plain ビデオマーケット経理担当の福原様(中央右)と僕(中央左)、ビジネス職新卒(両端)の一枚。 他社の新卒にも関わらず、直属の後輩のように親切に接してくださり、1週間お世話になりました。

エンジニアとして得たもの

これからエンジニアとしてバックオフィス業務の効率化を目指していく中で、実際の業務を伺ったり体験したりできたことは財産になりました。

わかりやすいところで言うと、業務フローがより明確にイメージできるようになったので、よりスムーズに実装にとりかかることができるようになりましたが、研修で得たのはそれだけではありませんでした。

バックオフィスの最前線で働く方々が、どれだけ必死で、全力で業務と向かい合っているかを知ることができたのは、大きな収穫だったと思っています。

僕が元々freeeに入社を決めた最も大きな理由は、社員の優秀さやエンジニアとして成長できる環境にありました。

ですが今回の研修で色々な方に懇切丁寧に接して頂き、話を聞かせてもらう体験を通じて、シンプルに「大変な仕事、面倒な仕事を減らして役に立ちたい」、そして「そんな仕事と全力で戦っている福原様のような方々を、技術力をつけて全力でサポートしたい」と思えました。

freeeの中で自分が何をしていくべきなのか、研修前よりも明確になったように思えます。

最後に

freeeでは、エンジニア新卒を募集しています。 エンジニア新卒は僕を含めた4人が第一期となりますが、全員が違うチームでスーパーエンジニアに囲まれながら腕を磨いています。

今回の研修もいい例になっているように感じますが、ユーザーが本当に困っていること、そして本当に価値が有ることを全力で考え、議論しながらコーディングに取り組んでいく。 そんな仕事に興味を持っていただいた方は、是非エントリーしてみてください。

今回お世話になった株式会社ビデオマーケット様の紹介

今回は映像配信事業を行う株式会社ビデオマーケット様に常駐させて頂きました。

ビデオマーケット様は、2005年に設立された、現在急拡大している動画配信を行う企業です。 社名にもなっている「ビデオマーケット」という動画配信プラットフォームをはじめ、最近ではmintoというスマホ向けの動画アプリもリリースして、事業を急拡大させています。

f:id:kote15:20170511161502p:plain ビデオマーケットの想いを、高橋社長ご本人にお伺いする時間まで頂きました。沢山勉強させて頂き、感謝です。

※この記事は研修にご協力頂いた、株式会社ビデオマーケット様の許可を得て掲載しております。

品質をトゥギャザーするために、不具合を見える化している話

こんにちは、freeeでQAエンジニアをやっている西出(@ichikoich)です。freeeのQAエンジニアは、E2Eテストを作ったり、ドメインスペシャリストを巻き込む仕組みを作ったり、手動テストのアウトソースをしたり、品質に関する様々なことをしています。

その中でも今回は、不具合の見える化にフォーカスして話します。freeeでは不具合のことを「ハッピー」と呼んでいます。(ハッピーと呼ばれている背景

難しい運用

今までもハッピーの見える化にはトライしていたのですが、いろいろな問題がありました。

freeeでは長年、不具合報告に関するサポート⇄エンジニア間のコミュニケーションやタスク管理をAsanaのタスクとして起票することで運用していました。この運用をはじめた当時のAsanaには、タスクに「対応中」や「デプロイ待ち」というような「ステータス」を表現できるフィールドがなかっため、「すぐ対応する」「あとでやる」のような「優先度」と同じフィールドで「ステータス」を管理していました。

<Asanaの画面例>

f:id:ichikoich:20170428133518p:plain

例えば、「すぐ対応する」に振り分けられているタスクを、エンジニアが修正に取りかかるときには、「開発者対応中」ステータスに変更します。ところが、それをすると、優先度の情報が消えてしまいます。逆もしかりで、優先度をつけると、ステータスの情報が消えてしまいます。

温かみのある見える化

Asana上の不具合の報告数や消化数の見える化は、Googleスプレッドシートで運用していました。最初はシンプルで、Google App ScriptでAsanaのAPIを叩いて調理するだけでしたが、エンジニアやサポートの運用が変わるたびに、集計が複雑になってしまい、いつの間にか集計するのに1ヶ月にトータル30時間ほどの手作業が発生するようになっていました。

f:id:ichikoich:20170428133600p:plain

もちろん、ステータスや優先度の情報がよく消えるため、集計した結果も正しいとは限りませんでした。

品質トゥギャザーの誕生

そこで、思い切って、仕組みを変えて定量的に品質改善を測定できるようにしました。この取組みを品質トゥギャザーと呼んでいます。品質を良くしていくためには、みんなでやっていくのが一番ということで、印象づけのためにトゥギャザーと連呼していくことにしました。

JIRAとembulkとRedshiftとRedashをトゥギャザー

まず、より正しく情報を扱うために、AsanaからJIRAへ移行しました。チケットのステータスと優先度が別々のフィールドであるのはもちろんですが、それ以上に柔軟にカスタマイズができることがJIRAへ移行した理由です。これまでビジネスや組織の成長により、集めたい、見たい情報やその運用が変わっていくことを経験してきたので、柔軟にカスタムフィールドを追加したり、ワークフローをシステム上で定義できることが魅力的でした。また、バグトラッキングツールとしてマジョリティなので、他サービスとの連携プラグインが豊富にあるところにも将来性を感じました。

次に、集めた情報を調理しやすいように、スプレッドシート × Google App Script からRedshift × Redash に切り替えました。データの調理がしやすいように、会社の中の様々な情報をできるだけひとつのデータウェアハウス(freeeではRedshiftを採用)に蓄積させていきたいので、デイリーでJIRAの全チケットをAPI経由で取得し、Redshiftに保存しています。毎日作られるチケットはそれなりの量になりますが、バルク処理に特化したembulkを採用することで簡単に実現することができました。treasure-data/embulk-input-jira というJIRA用のインプットプラグインを使っています。

あとは、Redash上で集計用のSQLを書いておけば、グラフや表などの見える化されたものが日次で更新されるので、コストほぼ0で最新の集計結果を見ることができるようになりました。

f:id:ichikoich:20170428134124p:plain

RedshiftやRedashなどの仕組みは既にfreeeが誇るすごいデータ基盤エンジニア(@krt)が構築していたので、ただそこに乗っかるだけでした。あっ、すみません、トゥギャザーですね。

freeeのデータ分析基盤について speakerdeck.com

ビジネスチームもトゥギャザー

社内の誰もが簡単にハッピーを起票できるように、JIRAに直接起票するのではなく、質問形式のGoogleフォームに用意しました。起票される内容に不具合の内容や発生条件などの対応に必要な情報の漏れがないようにするためです。Asanaの時も一部の製品に関してはGoogleフォーム経由での起票を試しており、これが好評だったのでJIRA移行を機に全製品のハッピー起票をGoogleフォームにしました。

f:id:ichikoich:20170428134224p:plain

実は、JIRA移行する時に一番苦労した点はハッピー運用フローの構築でした。Asanaでは、運用自体が複雑だった上に、エンジニアと他チームの責務分担や優先度の認識が明確ではありませんでした。そこで、各チームの関係者と一緒に話をして下記のような運用を明確にして、そこからフローを改善していくことにしました。明確なベースがないと改善していくことはできないので、大きな一歩だと思います。

f:id:ichikoich:20170428134316p:plain

エンジニアもトゥギャザー

freeeのエンジニアはローテーションでハッピーの対応を担当しています。この対応エンジニアたちをハッピーピーポーと呼びます。ハッピーピーポーは毎朝集まってハッピー朝会をします。ハッピー朝会ではハッピーピーポーたちが物理的に集まって2つのことをやります。

  • 新しく起票されたハッピーの優先度振り分けと一次回答
  • ハッピーのアサイン

これをみんなでやることで、ハッピーによるユーザのインパクトや、解決までにどれくらいの時間がかかりそうかが共有されるのを期待しています。始めた頃はみんなでやるのは高コストかなと思っていましたが、やっていくと今まで知らなかったことをたくさんインプットできるので、しばらく続けていきたいなと思っています。

f:id:ichikoich:20170428141042j:plain

簡単にハッピー消化のパフォーマンスが見られるようになったため、ハッピーピーポーを増やさなければまずいのか、逆に減らしても大丈夫なのかといったこともアラートしやすくなりました。

おわり

品質の可視化を話そうと思ったら、トゥギャザーの話ばかりになってしまいました(「・ω・)「

トゥギャザーしていきましょう!!