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

 こんにちは。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

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

おわり

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

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

ビジネスチームを支える縁の下の力持ちGYOMUハック

エンジニアをしている廣野(@mirygoaround)です。今日はGYOMUハックというエンジニアとしてもちょっと特殊な立場にいる私の仕事についてお話します。

freeeという会社は、2012年7月に創業してから急激な勢いで成長を続けています。 そして、最初はエンジニアだけだった会社も、サポート、マーケティング、セールスとどんどんと違う役割のチームを増やしてきました。

ビジネスチームの人数が増えたとき、彼らの業務をエンジニアリングで支える役割が必要となりました。 それが、GYOMUハックという役割です。

2017/04/26にGYOMU Hackers Night vol.1〜ビジネスチームを支える立役者・業務効率UPの仕組みづくりをするGYOMUハックエンジニアのつどい〜というイベントを行います。そこで同じような仕事をしている方と交流できればと思っていますので、気になる方はぜひご参加ください!(`δωδ´)

GYOMUハックのミッション

GYOMUハックというチームのミッションは、社内の各チームが突き抜けた生産性で働ける環境をつくるために、業務の観察を通じて本質的な問題点を見つけ、適切なソリューションで解決することにあります。

具体的に、ビジネスチームの実現したいことにあわせてfreeeのプロダクトを修正したり、ビジネスチームで利用しているSalesforceというツールをカスタマイズしたりしています。

すごい勢いで成長してきた社内のビジネスチームは、たくさんのアイデアややり方を無理くりつなげて業務を回してきた面もあり、管理コストが高かったり、作業コストが高かったりします。 そんな彼らの業務を支え、改善に導くのがGYOMUハックという仕事です。

きれいな庭をつくるおしごと

GYOMUハックの仕事は、きれいな庭をつくることに似てるかなと思っています。

ゴミだらけの荒地を想像してみてください。 その荒地をきれいな庭にするためにはステップがあります。

  1. ゴミを取り除く
  2. 土を耕す
  3. きれいな芝を育てる
  4. 池やオブジェクトをおく

このステップがすごくGYOMUハックの仕事に似ていて、

  1. 目に見える課題・リクエストをつぶす(ゴミを取り除く)
  2. チームが本来の力を発揮できるように導く(土を耕す)
  3. もっとよくするためのHackをする(きれいな芝を育てる)
  4. みんながビックリするような大改善をする(池やオブジェクトをおく)

こんな感じで各チームの状況を把握しています。

f:id:mirygoaround:20170410141130p:plain 1をこなすための労力は、ぶっちゃけ頭数さえあれば大したことありません。 頑張ってゴミ掃除すればいいだけです。

目に見えている課題については潰して、リクエストに関してはヒアリングをして本当にそのリクエストが妥当なのかの精査をしつつリクエストをこなします。 ここでちょっと気をつけないといけないのは、上がってくる課題やリクエストが本当のボトルネックではないことがあることです。 その辺りも見極めながらゴミ掃除をします。ゴミの分別みたいなものです。

f:id:mirygoaround:20170410141137p:plain 2をこなすためには、目に見えない課題を発見する必要があります。地中に巨大な石が埋まってるかもしれないし、土に栄養がなかったり毒素があったりするかもしれません。それを見つけて一つづつ解決していくのには時間といろんな人の協力が必要です。

一度出来上がった仕組みを壊して組み立てることも辞さず、より良い仕組みを考え、新しくしていくフェーズです。 巨大な石をそのままにしておいたら、木を植えようと思っても根っこが伸びないですよね。なので土を一回掘り起こして石を取り出して、また土をきれいに戻すということをしないといけません。

f:id:mirygoaround:20170410141142p:plain 3は、整った地盤で何をやるかを考える必要があります。 この頃になると、ビジネスチームはある程度戦略的に業務を回すことができてきているので、そこに+αをするのがGYOMUハックの仕事になります。今まではマイナスをゼロ、あるいはプラスに転じさせる仕事でしたが、ここからはさらになにをするか、にかかってくるのです。

各チームのミッションに沿って、彼らの武器となるべき仕組みを投入していきます。

f:id:mirygoaround:20170410141150p:plain 4は完全に発想力を求められます。考えもつかなかったような大Hackが生まれるかもしれません。そのための発想力が必要です。

今までやってきたことから離れて、こういう仕組みを入れたら劇的に変わるのではないか。どうあるのが理想なのか。というふうに脳みそをフル回転させないと、庭に置くべきかっこいいオブジェクトを思いつきません。freeeの価値基準の一つである「理想ドリブン(理想から考える。現在のリソースやスキルにとらわれず挑戦しつづける。)」でGYOMUハックとしても挑戦を続けています。

実際にやっていること

効率化する、改善する、と一言で言ってもやり方は様々ですが、私はエンジニアなのでやはり開発をします。

ビジネスチームのメンバーが利用するための機能を埋め込むためにfreeeのプロダクトを修正することもありますが、私が触ることが多いのはSalesforceです。 freeeでは、プロダクトでサインアップするとSalesforceに連携する仕組みがあります。その連携周りを修正したり、Salesforceのカスタマイズそのものを行ったりしています。

Salesforceの開発はApexという独自言語で行われていますが、最近作ったものだと、セールスのメンバーがコールするための一覧をSalesforce標準のレポートから作成する機能などが結構大きめの案件でした。

その他にもfreeeを利用する税理士さんのために事業所を大量に作成する機能を作るためにRubyを触ったり、ビジネスチームが利用したいデータを取得するためにSQLを書いたりと、いろいろなことをやる日々です。

苦労する点としては、開発言語のコンテキストスイッチもそうですが、各チームでやる業務内容も全く違うので、関わる案件ごとのコンテキストスイッチもかなーり大変です。ミーティングも多くまとまった実装時間が取れなかったりもします。

しかしfreeeのミッションは「誰もが創造的な活動ができる社会」「スモールビジネスが強く、かっこよく活躍する社会」を実現すること、なので、私も「freeeのビジネスチームが創造的な活動ができる」ことを目指して日々Hackを続けています٩(๑òωó๑)۶

さいごに

エンジニアというとプロダクトの開発に携わる人をイメージするかもしれませんが、GYOMUハックのような仕事をしている人もいるんだよ、というところを少しでも知ってもらえたらなと思います。