はてなブックマーク

支出管理開発本部で事業部横断テックリードをしている @ogugu です。 広く複雑で大規模になりつつある支出管理のアーキテクチャについて、以下の連載形式でご紹介していきます。 OpenAPI ではなく TypeSpec を読み書きするスキーマ駆動開発 (本記事) ソフトウェアアーキテクチャに基づいた自動テスト戦略と実装ガイドライン 支出管理におけるマイクロサービスアーキテクチャの知見 今回は、自動テストの戦略をご紹介します。 社内展開した内容を可能な限りそのままご紹介しますので、文体についてはご了承ください。 目的 概略図 テストレイヤー毎の使い分け Unit Test Integration Test Backend E2E Browser E2E アプリケーションレイヤー毎の戦略 フロントエンド Page Component (画面レベルのコンポーネント) Page 以外の Compo

支出管理開発本部で事業部横断テックリードをしている @ogugu です。 広く複雑で大規模になりつつある支出管理のアーキテクチャについて、以下の連載形式でご紹介していきます。 (本記事) 支出管理におけるTypeSpecを中心にしたスキーマ駆動開発 ソフトウェアアーキテクチャに基づいた自動テスト戦略と実装ガイドライン 支出管理におけるマイクロサービスアーキテクチャの知見 今回は、TypeSpec を中心にしたスキーマ駆動開発をご紹介します。 結論からいうと、筆者は TypeSpec について「OpenAPI からの移行コストや技術的ロックインリスクを伴わず、開発体験を向上する最高のツール」と評価しています。その理由を順にご紹介します。 TypeSpec とは OpenAPI とのスキーマの比較 導入の意思決定 TypeSpec を取り入れた開発フロー カスタム Linter / Decor

みなさん、こんにちは！freee 外部連携基盤エンジニアのおっそーです。 少し遅くなってしまいましたが、2025年5月末に開催された TSKaigi 2025 に参加したので、その参加レポートを書きます。 最近は担当プロジェクトの都合上 TypeScript を書く機会がめっきり減ってしまったわたしですが、本カンファレンスは非常に学びが多く、また TypeScript をたくさん書きたい気持ちになりました☺️ 参加された方にもそうでない方にも、 TSKaigi の楽しさが伝わる記事になっていると嬉しいです。 個人的にピックアップしたいセッション まずは berlysia さんの主催者講演「TypeScriptネイティブ移植観察レポート TSKaigi 2025」です。 TSKaigi 1日目に発表された TypeScript のネイティブ実装である typescript-go について、T

こんにちは。支出管理領域のQAマネージャーをしているrenです。 2025年4月に行われたICST 2025の併設ワークショップInSTA 2025に事例論文が採択され現地発表してきたので、発表までの経緯や開催地の様子をレポートします。 ICSTの紹介 ICSTはIEEEの国際カンファレンスで、International Conference on Software Testing, Verification and Validationの略です。ICST 2025の開催地はイタリアのナポリで、海岸沿いのコングレスセンターが会場でした。 conf.researchr.org 発表当日のコングレスセンター ソフトウェアテストに関するカンファレンスで、今回のKeynoteではAppleのDistinguished EngineerであるAtif Memonさんや、GSSIで教授を務められている

こんにちは、SREの清水です。 この記事では、2025年の確定申告に向けてfreeeで行ったキャパシティプランニングの取り組みについてご紹介します。 freeeと確定申告 freeeでは個人事業主や法人向けのクラウド会計ソフトであるfreee会計1を提供しています。freee会計は確定申告の書類作成にも利用されるため、確定申告期間（2月中旬〜3月中旬）は年間で最もアクセスが集中します。アクセス数は1月から徐々に増加し、3月中旬の提出締切直前にピークを迎えます。 この期間のトラフィックには普段と異なる以下のような特徴があり、入念に準備することが必要になります。 アクセス数の急増: 通常時の数倍規模のアクセスが短期間に集中 ユーザー層の変化: 主に個人事業主ユーザーからのアクセスが増加 ワークロードの変化: 記帳や確定申告書類作成にともない書き込み処理の割合が増加 プロジェクトの目標と体制 今

こんにちは! 関西でfreee販売の開発を担当しております bucyou こと川原です。 RubyKaigi 2025 の閉幕から3週間が経ちました。これまでに、Drinkup イベントの様子やLTの内容について紹介してきましたが、今回は社内向けに実施したトークからの学びの共有会のダイジェストをお送りします。 RubyKaigi 2025 のスポンサーボードの前で 今までの RubyKaigi 2025 関連の記事はこちら developers.freee.co.jp developers.freee.co.jp 前半の登場人物 hachi: RubyKaigi 2025 ではLT登壇やDJにもチャレンジするなど、多方面で活躍したhachiさん。振り返り会では、特に印象深かった技術トークとして以下の2つを挙げていました。 bucyou (この記事の筆者): 大阪からはフェリーで移動し、Ru

はじめに 最近のAI関連技術の進化は目まぐるしいですよね。私たちfreeeの開発組織でも、世の中のトレンドに追従、あるいは先回りする形でGitHub Copilotや社内から安全にLLMを利用するための基盤整備にも取り組んできました。そして2025年、これまでの検証フェーズを経て、AI活用をさらに加速させるべく、AIツールの本格導入を進めています。 現在、freeeの開発現場では主に GitHub Copilot、Cline、そしてDevinといったAIツールが活用されています（他にも細かなツールはありますが！）。特に最近全開発者向けに開放されたClineは、今後の開発スタイルを変える可能性を秘めていると注目しています。 この記事では、そのClineを全社導入するにあたり、私たちがどのように考え、どのような課題に直面し、そしてどう対策してきたのかをお伝えできればと思います。この記事が、AI

こんにちは！24 新卒で freee に入社した kochan です！ 以前投稿した新卒研修の事例紹介の記事では、freee の新卒研修で社内のコミュニケーションに関する課題を解決するために、ショート動画プラットフォームを作成したことをお伝えしました。今回の記事では、新卒研修後に本番運用に乗せるまでにどんなことをしたのかを説明し、新卒研修後の取り組みで学んだことをお伝えします。 また、この記事に関する内容は 5/9 に freee tech night で話す予定ですので詳細が気になる方はぜひご参加ください！ freee-tech-night.connpass.com 本番運用にあたって行ったこと 本番運用するにあたって、まずセキュリティを専門とするPSIRTチームと、プロダクトのインフラを管理するSREチームに、何をすれば安全に社内サービスをリリースできるのか確認しました。そこで出てきた

サマリ 社内イベント楽しい！ Datadog Tシャツもらった！ profilerがすごい！あるリクエスト中のCPU使用率を関数単位で見れるぞ！ トレースクエリの検索機能もすごい！AからBに対するリクエストという検索ができるぞ！ Datadogのロゴのかわいいワンちゃんは bits という名前だぞ！これだけでも覚えて帰ってくれ！ Datadogのロゴ。このかわいいワンちゃんはbits。bitsくん、bitsちゃんではなく概念的存在（真偽不明） あいさつ こんにちは。freee申告・所得税の開発をしています。新卒二年目のsuzakiです。 所得税というと定額減税とか103万の壁とかのヤツですね。 自分は愛知県に住んでいるので普段は中部オフィスに出社しています。 24新卒の中で中部オフィスで勤務しているのは自分だけなので、大崎オフィスにいる同期に会えるイベントには飛びつきます。 さて、4/21

こんにちは、フリーのQAマネージャーをしているymty（ゆもつよ）です。 今回は、フリーのQAにてどのようにしてテストチャーターを作って実行しているか、1年ほど前に新規リリースした「freee支出管理 小口現金」の新規開発時の、実際のテスト分析資料を元にご紹介します。 テストチャーターを書く前に、私が入る案件で行っているのが「フィーチャーの整理と論理的機能構造をつかったテスト分析」です。 言い換えれば、「このフィーチャーは内部で小さな機能がどう動いてるか、そこまで深掘りして理解した上で何をテストすべきか？」をロジカルに分解していくプロセスです。 ステップ①：マインドマップでフィーチャーを洗い出す まずは対象プロダクトにどんな機能（フィーチャー）があるのかを洗い出します。 新規開発の場合は最初にこれをやる必要があります。機能拡張の際はすでにフィーチャー一覧はできているはずなので、このステップ

こんにちは。SEQ (Software Engineering in Quality)のzakiです。 これまで、freeeのE2Eテストは、Selenium、RSpec、Capybara、およびSitePrismを基盤とするRubyのテストを、Jenkinsを用いて実行していました。この構成にはいくつか課題があったため、現在は PlaywrightをベースにしたTypeScriptのテストを、GitHub Actionsで実行する新構成への移行を進めています。今回はその内、JenkinsからGitHub Actionsへの実行基盤の移行について紹介します。 従来のE2E実行基盤の構成とその課題 現在のE2E実行基盤図 (Jenkins) これまでのE2E実行基盤はEC2上にJenkinsを構築し、その中でE2Eテストを実行していました。しかし、この構成には以下の課題がありました。 テスト

こんにちは。freee 大阪拠点で freee販売を開発しております、bucyou (ぶちょー) こと、川原です。 developers.freee.co.jp RubyKaigi 2025 まで、残すところ1週間となりました。Xを見る限りは、もう現地入りしている方もいて、ワクワクしているところです。 freeeからは10名のエンジニアが現地参加の予定です。一方で、メンバーによって Ruby での業務経験がまだ浅かったり、Rubyコミュニティの雰囲気をよくわからないという新卒1年目までいるという状況で、どのように楽しんで、何を学ぶべきか? というのがわからないという方もいる状態でした。おそらくコミュニティに参加するには、最初の一歩の勇気というのはなかなか必要ですよね。 かくゆう私も Ruby コミュニティ初心者なので、大変ドキドキしております。 ということで、RubyKaigi 2025

こんにちは！PSIRT red team の kaworu と yusui です。 最近力を入れて取り組んでいる、 AIエージェントを利用した脆弱性診断の取り組みについて紹介します。 取り組みの背景 はじめに、現在のfreeeの脆弱性診断の体制と、取り組みの背景についてです。 freeeの脆弱性診断の流れとしては、開発チームから、設計レビューの依頼をきっかけに始まります。 セキュリティ観点でレビューを行い、あわせて脆弱性診断が必要な対象を決定しています。診断が必要なものは準備、診断作業、そして結果が開発チームに共有、修正が必要なものは対応を依頼しています。 上述のような流れなのは、Webアプリケーションの脆弱性診断はソースコードに変更の入ったタイミング、つまりリリースごとの実施を理想として体制を作ってきたためです*1。 その結果、以下のような課題をずっと抱えています。 リリースごとの小さな

はじめに by @solt9029 freeeサインの開発に携わっているソフトウェアエンジニアの塩出（@solt9029）です。 freeeのプロダクトには、freee会計やfreee人事労務をはじめとし、非常に多くのものが存在します。このような状況下で、各プロダクトがそれぞれ独自のデザインを採用してしまうと、プロダクト間で似たような操作に微妙に異なるデザインや体験が採用されてしまい、ユーザーの認知・学習コストが不必要に増加してしまいます。 そこで、ユーザーがプロダクト間で類似する操作や体験が統一的に行えるように、社内では「vibes」や「標準UI」といったデザインシステムが開発されてきました（vibesや標準UIの導入背景や詳細などについては、デザインシステム “Vibes” の育てかたやデザインシステムを拡張し、プロダクト開発の共通基盤を目指すをご参照ください）。 freeeのプロダク

こんにちは。freee 大阪拠点で freee販売を開発しております、bucyou (ぶちょー) こと、川原です。 freee は、2025年4月16日(水)〜4月18日(金) に開催される、「RubyKaigi 2025」 に協賛いたします。 ありがたいことに、freee からは私も含め10名のエンジニアが参加できることになり、普段使っている Ruby について知見を深めたり、交流ができればと考えております。 そんな freee の Rubyエンジニアと、RubyKaigi に参加しているエンジニアの皆さんが交流できるようにするべく、Drinkup イベントを開催いたします。開催日は会期2日目の4月17日(木)です。 RubyKaigi 2025イベント一覧ページ: rubykaigi.org Drinkup イベントページ (参加登録ページ): freee.connpass.com 参

freee PSIRT( Product Security Incident Response Team ) のhikaeです。freeeでも自律型AI AgentのDevin*1を雇用しています。 今回はPSIRTの業務の一つである Dependabot対応におけるDevinの活用事例（Devindabot）… ライブラリの脆弱性対策にAIを活用して、開発ライフサイクル全体にいい影響が出た話 をご紹介します。 Dependabot対応 ... ライブラリの脆弱性対策 ライブラリアップデートの辛さ フローを見直し負担を下げる ===DependabotがPull Requestを作る流れ 1. GitHub Advisory Database · GitHub に脆弱性情報が追加される 2. Dependabotがリポジトリごとの依存グラフを定期的に更新する。もし脆弱性による影響がある場合

こんにちは！24新卒でfreeeに入社したkochanです！この記事では、実際に私が経験した2024年度のエンジニア新卒研修について紹介します。これから研修を控える方や、就職先を検討中の学生の皆さんに、freeeでどのような成長機会が得られるのかをお伝えします。 私たちはまず、営業メンバーも含めた新卒全体で会計などに関する業務知識についての講義を受け、演習を行いました。 その後、エンジニア新卒研修が2.5ヶ月間あります。内容としては前半・後半の2段階構成で、実践的なスキルと即戦力になるための経験を身につけることができます。 前半研修ではWebフレームワークを自作するといった本格的な技術トレーニングや、社内サービスやインフラに関する講義を受講しました。これによって、実務で必要となる基礎技術力を習得できました。 後半研修ではさらに踏み込んでエンジニアとデザイナーが混合チームを組み、実際の社内課

こんにちは、関西拠点のお便りとして、「かんさい通信」を銘打って情報をお伝えしていきたいと思います。 普段は、freee販売の開発をしております、bucyouというものです。趣味は家計簿と、Railsのコードをひたすら読んでいくことです。 最近は、ChatGPT に自作の家計簿システムをメキメキ強化してもらっており、なかなか面白くなってきました。 freeeの関西拠点では、開発メンバーとしては freee販売・freee請求書・会計などのエンジニア・QAメンバーが集まり、 和気藹々と開発しております。 そんな、freeeの関西拠点では場所をお貸ししまして月に一度 kyobashi.rb というコミュニティイベントを開催しています。 前回、私が記事で公開した以下の Rails コード探検記事も、実は kyobashi.rb の中でライブコードリーディングをしながら解説していったものでした。 d

この記事はfreee Developers Advent Calendar 2024 - Aventar 23日目のエントリーです。 adventar.org こんにちは、私は freee でエンジニアリングマネージャーをやっている sentokun と申します。 この記事では、キャリアを配信する活動をしてたら、社内的に行っている組織課題への取り組みと融合した話をします。 ヘビとヤギとライオンが融合した空想上の生き物キメラ 記事中には 2 つのチームが登場します。 チーム 概要 補足 eng 波乱万丈委員会 ゲストがこれまでに経験したキャリアについて話す配信を行い、学びを社内全体で共有するチーム freee では、本業とは別に有志で行っている活動のことを委員会と呼んでいる eng サクセス 開発チームメンバーの「成功（サクセス）」を目指し、それだけを念頭に活動を続ける専門のチーム 本記事に

こんにちは。権限管理基盤チームでQAをしているyukkyです。 freee QA Advent Calendar2024 20日目です。 所属してるチームで運用しているCIの仕組みと課題について書こうと思います。 CI作成の背景 権限管理基盤チームでは、権限制御を担うマイクロサービスを開発しています。 このプロダクトはUIが少なく、APIテストを中心にしたテストを行っています。 機能追加のたびにテストシナリオを追加し、蓄積したテストシナリオは、リグレッションテストとして再利用しています。 以前の開発フローでは、PR単位でローカル環境にてリグレッションテストを実行していましたが、 シナリオ数の増加により、ローカル環境でのテスト実行が長時間になり、テスト実行中はローカル環境が占有され開発ができないという課題がありました。 これを解決するため、現在はPR作成時にGitHub Actionsを利用

こんにちは、freee人事労務でQAエンジニアをしているkairiです。freee QA Advent Calendar2024 21日目です。 今回はプロジェクトの中で実際にあった、不足しているテスト（自動テスト）をQAが書いてサポートした事例、およびそこからシステムの内部構造に踏み込んだ改善提案をした事例を紹介します。 きっかけ 複雑な表示ロジックを持つUIのリファクタに関わることになった際に、パターンが多すぎて目でチェックすることが非効率に感じたことがあり、なんとか楽ができないかと考えました。 実際のデシジョンテーブル。ほんの小さなコンポーネントに対してこの複雑度。 しかし該当箇所には複雑な表示ロジックを持つ割に自動テストが存在しておらず、自動テストを書いてもらおうにも開発エンジニアメンバーの工数には余裕がありませんでした。QAエンジニアもプロダクトコードにアクセスできるため、それな

こんにちは。freee人事労務でQAエンジニアをしているnunです。 freee QA Advent Calendar 2024 19日目です。 昨年freee QA Advent Calender 2023にて下記テスト管理ツールの移行について投稿しました。 developers.freee.co.jp 本日はその後どうだったの？というところを投稿したいと思います。少し長いので必要に応じて後述の目次もご活用ください。 さて、タイトルでネタバレはしてしまっているのですが… お陰様でTestRailからZephyr Scaleへのテスト管理ツール移行は無事完了しました！！！ 結果として1年間がかりの対応となり、実際どういうことを行なったのか、何が大変だったのかといったあたりについて書いていきます。 Zephyr Scaleの使い方に重きを置いた以下記事もありますのでぜひ併せてご覧ください。

この記事は freee Developers Advent Calendar 2024 の 25 日目の記事です。本記事は、freeeの共同創業者で取締役CTOの横路が担当します。 わたしが新卒で会社を選ぶときに知りたかったこと 最短で成長するためのエッセンス：打席数・没頭・巨人の肩の上に立つ なぜ打席にたくさん立つことが大事なのか なぜ没頭することが大事なのか なぜ巨人の肩の上に立つことが大事なのか なぜ会社選びと行動習慣が大事なのか 打席数を増やすための会社選びと行動習慣 没頭するための会社選びと行動習慣 巨人の肩の上に立つための会社選びと行動習慣 成長のその先へ まとめ わたしが新卒で会社を選ぶときに知りたかったこと 毎日起きるのが楽しみになるくらいエキサイティングなチームと一緒に自分の持てる力を最大限発揮して、世の中が大きく前に進む瞬間に立ち会い、そこに少しでも貢献したという実感を

崖っぷちのリスクに直面している こんにちは。freeeでQAのマネージャをやってるuemuです。 これは、freee QA Advent Calendar2024 24日目の記事になります。 はじめに 今年は、どんな一年でしたか？ 私は、大好きだった「ブラタモリ」の放送が終了してしまい、ショックを受けていましたが、この記事を書いている最中に「ブラタモリ復活！」のニュースが飛び込んできて、一気にテンションが上がっています！ www.nhk.jp さて、、、昨年は「ブラタモリ」に倣い、ぶらぶら歩きながらWebサービスの「へり」を探してきました。今年もその続きをお届けします。 よろしければ、昨年の記事もぜひ合わせてご覧ください！ developers.freee.co.jp Webサービスの歩き方 前回のおさらいになりますが、Webサービスの開発では、普段気づきにくい境界（以下、「へり」）が多数

こんにちは。決済プロダクトでQAエンジニアをしているrenです。freee QA Advent Calendar2024の23日目です。 今回は、決済プロダクト開発にテストアーキテクチャを設計した事例について紹介します。 テストアーキテクチャとは テストアーキテクチャによって解決したい課題 テストアーキテクチャ設計のステップ 1. この振る舞いを担保するためには、どのようなテストが必要だろうか？という問いを立てる 2. 抽象化して考えるための概念を学ぶ 3. テストアーキテクチャを描き、議論する テストアーキテクチャ設計のインパクト 実装改善に関する気づき テストの構造とソフトウェアの構造に関する気づき 自分たちのテスト活動の課題に関する気づき チーム開発の支援を通じた工数上のインパクト テストアーキテクチャがもたらす価値 今後の展望 [appendix]今回設計したテストアーキテクチャの