こんにちは！freee会計でアプリケーションエンジニアをやっている hachi ( @hachiblog ) です。この記事は freee Developers Advent Calendar 2023 7日目の記事です。 先日チームに最近新たに加わったメンバーに「このチームは皆楽しそうに仕事をしますね」と言われました。 たしかに楽しいと思いつつ、あまり言語化したことがなかったので自分なりに実践していることを考えたとき、タイトルの「いつかやりたい」リストをメンテナンスすることだと思い至ったので筆をとりました。 さて、なぜそう考えるかの話のまえにまずは仕事に欠かせないタスク管理の話から。 タスク管理とGTD 皆さんはふだんどのようにタスク管理をしていますか？ 世の中には数多のタスク管理手法やツールがあります。 ノートにチェックリストを書いて管理している人や Slack のブックマークで管理し

freee 会計でエンジニアをやっている jaxx です。今年もアドベントカレンダーの季節がやってきましたね。freee Developers Advent Calendar 2023 の 4 日目の記事となります。 去年に引き続き「突撃！隣のリモート・オフィス環境」をやりたいと思います。 developers.freee.co.jp 前回は freee 会計のエンジニア、QA に限定してデスク環境を紹介しましたが、今回はスコープを広げて developers 全体に周知して書いてくれる方を募集しました。猛者揃い(?)だと思うので、こだわりのリモート・オフィス環境について紹介していきたいなと思います。 大崎ネスト周辺に引っ越しして来ました（jason） freee 会計でエンジニアをしている jason です。大崎ネストの周辺に引っ越ししてきたばかりなのでまだ未完成ではありますが、変化の過

こんにちは、freee会計チームでWebエンジニアをしているe-mohaです。4月に入社しました。 この記事では、先日プレスリリースが発表されたきっぷUIの開発についてご紹介します。 燕駅から大崎駅までの交通経路のスクリーンショット まだプレスリリースをご覧になっていない方は以下のリンクをご確認ください。 prtimes.jp 今回は、freeeのプロダクトのデザイン方針である「Design Philosophy」を意識してUI開発をしました。 Design Philosophyの4つのキーワードに沿って、解説していきます。 brand.freee.co.jp 爽快でシンプルな見た目にする "かろやかシンプル" 「かろやかシンプル」というキーワードでは、業務の面倒な事務作業のストレスから開放するためにシンプルでわかりやすいデザインを心がけることを定義しています。 きっぷUIでは、右上のつば

freee会計からマイクロサービスを切り出すのに4年かかりました / 4 Years for Carving Out A Micro Service from freee Accounting.

chat.md 結城浩 こんにちは。今後、GPT-4を使ったアプリケーションやサービスがたくさん登場してくると思います。その中には、たとえばSNSを利用したbotもたくさん出てくるでしょう（現在でもすでにありますけれど）。そこで質問なんですが、SNSでおしゃべりしている相手が、人間なのか、GPT-4などの技術を使ったAIなのかを識別するにはどのような会話をしてみればいいでしょうか。一般的なAIでは難しいかもしれないので、GPT-4に限ってもいいです。あなたの考えを聞かせてください。 ChatGPT Model: GPT-4 GPT-4のような高度なAIと人間を識別するのは、時に難しいことがあります。しかし、いくつかの方法を試してみることで、相手が人間かAIかを見極めることができるかもしれません。 複雑な感情やニュアンスについて尋ねる: AIは感情やニュアンスを理解するのが苦手です。複雑な感

これは Recruit Engineers Advent Calendar 2022 - Adventarの13日のエントリーです。（書いているのは21日です。） 1. 納期コミットのオーダーは結果的に納期を遅らせる 先日、興味深いエントリーを読んだ。 bufferings.hatenablog.com これにつてはほぼ同じようなことを社内のtimesチャネルでも会話しており、スケジュールへの向き合い方についてメタ的理解に昇華させたい。 我々が納期をコミットしなさい、確実に守れる日を教えてと言われたときにやることは、、、 確実に納期を守れるように、余裕をみる。である。 ------------------------------------------------------------ ■：実作業日（問題なければできそうな工数） □：バッファ日（例えば50％の確率で問題おきたときに使う予

freee 会計でエンジニアをやっている jaxx です。アドベントカレンダーも終盤ですね。freee Developers Advent Calendar 2022 の 20 日目の記事となります。 今回の記事では freee 会計に関わる人達のこだわりのリモート環境や、オフィス環境について共有していきたいと思います。 ガジェットは資産！な環境（jaxx） このエントリーを企画した jaxx です。デスクはスタンディングデスクに IKEA で買ってきた天板をつけています。子どもがいて比較的賑やかな環境で仕事しているのでダイナミックマイクを使っています。 気に入っているところ、こだわりポイント 自作 PC、自作キーボードが趣味です。自作キーボードは季節が変わると作りたくなってしまうので、去年いくつか整理して棚に飾ってます。 個人的にマウスは大きくて軽いやつが好きなので長いこと有線マウスを手

こんにちは、サービス基盤のkumashunです。この記事はfreee Developers Advent Calendar 2022の14日目です。 突然ですが、自分は今年の11/23に開催された荒川トライアルというマラソン大会に参加し、フルマラソンを4時間17分29秒で完走しました！成人男性のおおよそ平均タイム4時間30分を下回るサブ4.5と呼ばれる実績をクリアしたことになります。今回は、このゴール達成に至るまでの1年間の記録をあえて共有します。 荒川トライアル(フルマラソン)の記録証 目指すきっかけ 挑戦のきっかけになったのは、新卒配属当時のJM(freee用語でマネージャーの意)であるkawamuraさんが市民ランナーだったことでした。自分が入社した2020年当時はコロナ禍の影響で大会そのものが開催されない時期が続きましたが、2021年になると徐々に大会が開催されるようになり、kaw

こんにちは、今年は家電が何かと壊れる freee会計のアプリケーションエンジニア id:him0 です。 この記事は freee Developers Advent Calendar 2022 の19日目の記事です。 今年自分のチームは特定のドメインの DB を分離しパフォーマンスのカイゼンを図るプロジェクトに取り組んでいました。下調べを行いドメインの境界を定義し分離できるぞーとプロジェクトは走り始めましたが、やはり単純には行かないのがアプリケーション開発、ちゃんと問題に突き当たります。特定の検索条件を利用する際に分離される予定の 2 つの DB を横断して JOIN を行っていることが発覚しました。 この問題に対して我々チームは当初パフォーマンス犠牲に元ある機能を再現することを考え始めたのですが「この検索軸消しちゃっていいんじゃない？」というメンバーの提案をきっかけに方向を転換して「ユー

freee Developers Advent Calendar 2022 １日目の記事です！ ついに今年も始まりました freee Developers Advent Calendar、一日目は会計チームの hachi (@hachiblog) からお送りします。 エディタはソフトウェアエンジニアにとって毎日使う道具です。あなたはどんなエディタを使っていますか？そのエディタに満足していますか？ 自分は３年ぐらい VSCode を使っていて大方満足はしていたのですが、細かいところで不満が出てきていました。 そのため思い切って Neovim にエディタを移行しました。 移行して、超快適！という状態ではまだないのですが、VSCode と同等ぐらいまでには使いこなせるようになりました。 自分は今まで何度か VSCode から Vim/Neovim に移行しようとして何度か挫折していて今回始めて成

freee 会計でエンジニアをやっている jaxx です。昨年 freee 会計を Rails 6 に上げましたが、今回チーム（@jaxx @kaion @hachi @gakky）で Rails 6.1 へのアップグレードを担当して9月末にリリースしたのでエントリーしました。 developers.freee.co.jp 目次 作業全体の流れ まずは feature ブランチで Rails 6.1 に上げてみる 依存パッケージのアップデート Deprecation Warning の解消 Breaking Change の解消 Fail している RSpec の修正 最後に 作業全体の流れ まずは feature ブランチで Rails 6.1 に上げてみる 事前作業として依存パッケージのアップデート 事前作業として Deprecation Warning の解消 Breaking Ch

会計チームで債権周りの開発をしている hachi (@hachiblog)です。会計チームが開発している freee 会計は freee の中で一番歴史が長いプロダクトです。加えて会計というドメインは複雑かつバグを生むと顧客の業務を大きく阻害するという点で一度作ったものを変更しづらいという特徴があります。 そのような環境で今回、債権のチームでは freee会計の初期からある「自動で経理」という機能の一部リファクタリングを行いました。リファクタリングのしづらい環境下でうまくリファクタリングをすすめるための tips は多くの人に役立つのではと思い、このエントリを書くに至りました。 今回「自動で経理」でリファクタリングしたときに事前に以下のことを行いました。 課題の発見 課題の具体化 設計とスケジュール見積もり テストコード実装 それぞれについて今回意識したことを書いていきます。 課題の発見

忙しい方向けサマリ EKS化・IaCの浸透・DB改善活動が、ここ数年のfreeeのインフラ事情の主だった動きです。 一方で組織・サービスも増えてきており、従来のワンチームSREでは色々と厳しくなってきました。 基盤も進化し、課題も変化した。それに伴い、SREの組織構造を、チームトポロジ的に再編しました。 本文 こんにちは、freeeでSREのマネージャをやっている河村です。 freeeは会計年度の開始月が7月となっており一つの節目となっています。加えて今年はfreee創業10周年ということで、一つのマイルストーンとして、freeeのSREの現状と、それを受けた今後の展望について整理してみました。 この数年の中で、EKS化やAurora化といった基盤の刷新が進む一方、プロダクト・組織規模拡大に伴う従来型SREチームのスケール限界が顕在化してきています。それに対し、新しい基盤に合わせた仕組みの

こんにちは、会計チームでエンジニアをやっている ut (@utdoi1) です。最近はレポート周りの開発を主に担当しています。 先日あった機能リリースにおいて、大量のデータを対象とした移行タスクを実行する機会がありました。 タスクの概要としては、freee会計に登録されている事業所1つごとにデータ移行をしていくものでした。 今回はfreee会計にアカウントを作成している全ての事業所に対してタスクを流す必要があったため、普通に実行していたら完了までいったい何日かかるのか分からないくらいの規模感でした。 そのため、並列実行も考慮に入れて割としっかりめに実行計画を立てて臨みました。 この記事では、その実行計画を立てた時の作業の流れと、それぞれの過程における細かい作業内容を紹介します。 計画策定までの流れ 全体としては以下のような流れで作業を進めていきました。 タスク実行時間に関係するデータの度数

会計チームで債権周りの開発をしている hachi (@hachiblog)です。自分は 2022年4月 に関西拠点初めてのfreee会計チームのメンバーとして入社しました。会計チームは現状 3〜4人の小さいチームがいくつかあるようなチーム構成になっています。今後関西にも会計チームのメンバーは増えると思いますが、今はその中のひとりとして東京のメンバーと仕事をしています。 自分以外のメンバーは東京にいるなかで３ヶ月仕事をしてきて、「コミュニケーションハンデがある中でよくやってくれている」とお褒めの言葉を頂いたので、自分が気をつけていることや自分が自然にやっていることで良かったことを言語化してみました。 関西拠点勤務とは言いつつ、東京のメンバーと働くのがメインなのでフルリモートに近い働き方になっています。自分と同じように働き方がリモート勤務である会社に転職したり新卒入社した人の参考になれば嬉しい

スパイスからカレー作ろうと思うと 何十種類もスパイス用意して死ぬほど大変な男の料理みたいなイメージありそうだけど、実は簡単に作れる。 それでいて、その辺のインド人カレー屋より美味しくできたりする。 だいたい誰に作っても「マジでインド料理屋」と驚かれるから試してみて。 用意しなきゃいけないスパイスは４種類だけ。 「クミン（ホール）」「ターメリックパウダー」「チリペッパーパウダー」「コリアンダーパウダー」 これだけでOK。この４つでチキンカレーだろうが、キーマカレーだろうが、だいたい大丈夫。 （まあ、凝りたい人はいくらでも凝れるけどね） ベーシックなスパイスなので、大きめのスーパーなら大概あるけど、 都内なら御徒町とかのスパイス問屋（大津屋）とか行けば20回分で一袋200-300円で超お得。 で、他の材料。玉ねぎ大１個、トマト大１個、ニンニク３かけ、生姜１かけ。好みでプレーンヨーグルト。 これ

はじめまして。freee の SRE チームに所属している nkgw （Twitter） です。 普段はエンジニアリングマネージャーをしつつ、開発チームの新規プロダクトリリースサポートをやっています。 我々のチームは大部分のプロダクトのコンピューティングリソース (CPU / Memory など) を Amazon Elastic Kubernetes Service (EKS) で実行できるようにインフラ基盤移行 (EC2 → EKS) を進めてきました。 移行プロジェクトの大部分は 2021 年 7 月に無事終わったのですが、移行スケジュールを最優先としたため割り当てている各リソースはかなり保守的 & 過剰でした。 (移行後の性能劣化が怖かったため、EC2 時代と比較し、1.5 倍のバッファを積むなど... etc) コスト増大したグラフ その結果、 去年と比較して、コストが倍以上に跳

try { const data = await fetchSomething(); // 正常系レスポンスの処理 } catch (err) { if (isAxiosError(err)) { // 異常系レスポンスの処理 } } 動機はつぎの 3 つです。 データ取得も宣言的に書きたいから データ取得に関係ない例外も catch してしまうから HttpError の集計に不便だから データ取得も宣言的に書きたいから 要約すると、データ取得時は常にこのように書きたい、という話です。useSWR・useQuery や apollo/client でお馴染みのインターフェイスです。 const { data, err, status } = await fetchSomething(); if (data) // 正常系レスポンスの処理 if (err) // 異常系レスポンスの処理

こんにちは、freee会計でワークフロー機能の開発をしている @mitubaEX です。 先日 freee会計のパフォーマンスチューニングに取り組みました。本記事では、調査の流れ、改善の事例を紹介します。 問題発覚までの流れ freee では自社の経理業務に freee会計を利用しており、その中でも経費精算の機能はほぼすべての従業員が利用しています。そのため日々多くのフィードバックをもらえます。そのフィードバックの1つで、「経費精算の一覧を開くのが遅い」という報告をもらいました。幸い表示件数を指定できるので調整すれば遅くはならないのですが、一覧性が下がってしまうため有用な解決策ではありません。 そこでワークフローを開発しているチームで、このパフォーマンスイシューの調査を始めました。 調査する まず事前調査として Datadog*1 で一覧画面を表示するリクエストの処理を確認しました。 一覧

こんにちは、freee会計でエンジニアをしている jaxx です。 freee 会計におけるメイン業務とあわせて、会計フロントエンド委員会というフロントエンドに思い入れのある有志で集まった委員会にも所属しており、フロントエンドの技術的負債と向き合ったり、新しい技術導入に向けて意見を交換し合ったりしています。 今回はその改善の一環として freee 会計に残る 400ファイルの CoffeeScript を decaffeinate を使って書き換えた話をします。 freee 会計と CoffeeScript 参考:「10分でわかるfreee エンジニア向け会社説明資料」 freee 会計の開発が始まった 2012 年ごろ Ruby on Rails3 では CoffeeScript が標準サポートされており、freee もそれにならってフロントエンドでは CoffeeScript がメイン