サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猛暑に注意を
developers.freee.co.jp
こんにちは、freeeで支出管理領域のQAマネージャーをしているrenです。 今回は、支出管理領域のCIパイプラインにJust in Time Test(JiT Test)という仕組みを試験的に導入している話をします。 Just in Time Testとは PR作成時に、LLMを活用して生成するジャストインタイムなテストのことを指します。 MetaのMark Harman、Peter O'Hearn、Shubho Senguptaらが提唱している「Assured LLM-Based Software Testing」という研究領域に基づくものです。 論文「Harden and Catch for Just-in-Time Assured LLM-Based Software Testing: Open Research Challenges」では、PRが提出された際に生成される「JiTT
こんにちは!PSIRT red team の kaworu と yusui です。4月に公開した脆弱性診断 with AIエージェント、はじめました。では、 AIエージェントを利用した脆弱性診断内製化について紹介しました。 約3ヶ月が経過し、記事で目標に掲げていた「開発のタイミングでAIエージェントによる脆弱性診断を実施し、結果に問題がなければそのままリリース」が実現し、開発チームでの脆弱性診断がついにひろがってきました! 本記事では、実際に開発チームに展開されるまでと、工夫点をまとめました。 展開した脆弱性診断 with AIエージェント 4月の記事から、以下のような変化がありました! AIエージェント……Cline から Roo Code へ 診断ナレッジを渡す方法……Memory Bank から freee 社内の MCP server へ Cline → Roo Code 4月の記
developers.freee.co.jp こんにちは。freee の SRE チームに所属している nkgw (X) です。 KubeCon + CloudNativeCon Japan 2025 参加レポート 3日目を担当します。 先日開催された KubeCon + CloudNativeCon Japan 2025、楽しかったですね。 その中でも特に興味があった下記のセッションについて共有したいと思います。 From ECS To Kubernetes (and Sometimes Back Again): A Pragmatist's Guide To Migration セッション動画 スライド 概要 本セッションは、オンラインで使えるグラフィックデザインツールである Canva が Amazon ECS (以降 ECS と表記) から EKS (Kubernetes) へとど
こんにちは〜、freee販売エンジニアのErikaです。今回、関西Ruby会議08に行ってきたので、参加レポートです! 大阪Ruby会議には行ったことがあったんですが、今回はもう一つ大きな「関西」ということでワクワクしながら行ってきました! 今回は会場が先斗町歌舞練場という場所で、普段は舞踊の披露などに使われる格式高い会場です。 外観やロケーションだけでなく、内装も素晴らしく、思わず写真をたくさん撮ってしまいましたので写真多めでお送りします 歴史を感じる会場 印象的だったセッション イベントで特に印象的だったのは、Koji Shimbaさんの個人開発についての発表でした。個人開発って「モチベーションの維持が大変そう…」というイメージが強かったのですが、10年間の経験から得た知見がとても勇気づけられるものでした。 Koji Shimbaさんが教えてくれたのは、「自分が欲しいものを作っても意外
はじめまして、24卒として新卒で入社したSREのponです。 今回freeeのSREから7名が、2025年6月16日・17日に開催されたKubeCon + CloudNativeCon Japan 2025に参加しました。 参加記念写真 これから4日間にかけて、KubeConに参加したメンバーによる参加レポートを連載していきます。(おかわりもあるかも?) 様々なバックグラウンドを持つメンバーによる記事をぜひ楽しんでください! 日付 メンバー タイトル 7/15 sho What's New in Open Source Kubernetes?/Access AI Models Anywhere: Scaling AI Traffic With Envoy AI Gateway 7/16 nakagawa From ECS To Kubernetes (and Sometimes Back
freeeでは、2025年1月よりデザイナーの役割を「ApplicationDesigner」※1として再定義しました。 本記事では、デザインスペシャリストとして活躍する服部 有里が、デザイナーとしてどのように自身の役割と向き合い、変化してきたのかをご紹介します。 ※1 「ApplicationDesigner」の定義については、カジュアル面談資料にて紹介しております。 5年間の変化 前回の記事では「人を軸に考える」がテーマでした。そういった新卒時のマインドに変化はありましたか? そうですね。変わったと思います。具体的には業務に軸を置くようになりました。人だけじゃなく、業務です。 フリーの提供しているものって業務システムだからです。業務システムで使いやすい状態を提供するには、考えるべきは業務だろうっていうふうに、いまは変わりました。「人」っていう軸だと、ざっくりした「ユーザーのために!」っ
はじめに こんにちは、タイガーチームでエンジニアをしている横塚といいます。 自分は直近3ヶ月間、社内におけるAI 駆動開発の推進を主務として活動してきました。 今日は Coding Agent との向き合い方について思いの丈を綴ろうと思います。 Coding Agent という「魔法」を解明したい Coding Agent の登場によって我々の開発のやり方は大きく変わりました。freee でも Cline や Roo Code、Goose を使うことが当たり前になり、AI 駆動開発はエンジニアに求められる最も基本的なスキルのひとつとなりつつあります。 Coding Agent はまるで「魔法」のようです。自然言語で指示を出すだけでコードが生成され、テストやドキュメントも書いてくれる。 その Coding Agent がどのように動いているのか、我々はその「手品のタネ」を解き明かす必要がある
はじめに こんにちは、タイガーチームでエンジニアをしている横塚といいます。 この記事では Coding Agent へのタスク依頼を最適化していく過程を step-by-step で一緒に見ていきます。 お題は「Pull Request の作成」です。 コードは既に書いている コミット済みで git の work-tree はクリーンな状態 この状況から Coding Agent (Cline, Roo Code, Goose CLI, GitHub Copilot Agent, Claude Code etc…) に高品質な Pull Request を作成してもらうことを目指します。 TL;DR: Coding Agent によるワークフローの最適化には、シンプルなプロンプトチューニングのみでは不十分 事前に確定できる処理はスクリプトに任せ、LLM には柔軟性が求められる処理に専念させ
支出管理開発本部で事業部横断テックリードをしている @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がリポジトリごとの依存グラフを定期的に更新する。もし脆弱性による影響がある場合はアラ
こんにちは、SREの久保木です。一年弱ぶりにまた記事を書きます。 以前はfreeeに入って割とすぐの頃で、Project間の依存関係を表す図を自動生成したりしていました。 その後はfreeeで使われているTerraform Codeを一括整備するためにTFLintを導入しつつCustom Ruleを実装したり、この手のLinter導入にありがちな最初の間は警告が多すぎて無視されてしまう問題に対処するために全部のCodeを手入れしたり(すごい量でした……)、結果的にfreeeのInfrastructureのIaC周り全般の知識を得られたのでそれを用いてSecurity Riskのある問題の対処をしたり、最近はPSIRTやSRE内のCloud Governance Teamと連携してAWSのResourceの管理状態を見直したりと、いろんなふわっとした課題、ちょっと手をつけづらい課題を探しては
こんにちは!24新卒でfreeeに入社したkochanです!この記事では、実際に私が経験した2024年度のエンジニア新卒研修について紹介します。これから研修を控える方や、就職先を検討中の学生の皆さんに、freeeでどのような成長機会が得られるのかをお伝えします。 私たちはまず、営業メンバーも含めた新卒全体で会計などに関する業務知識についての講義を受け、演習を行いました。 その後、エンジニア新卒研修が2.5ヶ月間あります。内容としては前半・後半の2段階構成で、実践的なスキルと即戦力になるための経験を身につけることができます。 前半研修ではWebフレームワークを自作するといった本格的な技術トレーニングや、社内サービスやインフラに関する講義を受講しました。これによって、実務で必要となる基礎技術力を習得できました。 後半研修ではさらに踏み込んでエンジニアとデザイナーが混合チームを組み、実際の社内課
こんにちは、freee でエンジニアをしている横塚です。 急速に変化するビジネスの世界で、組織の機動性と適応力は成功の鍵となっています。本記事では、freee で実践している「タイガーチーム」という特殊な組織体制について、その立ち上げから運営まで、実践的な知見を共有します。 タイガーチームの語源 タイガーチームという言葉は、1964 年に NASA のエンジニア、ウォルター・C・ウィリアムズによって定義されました。*1「経験豊富で創造的な技術専門家による、問題解決に特化したチーム」を指し、当初は宇宙船の品質保証のために結成されました。 その後、この概念は航空宇宙分野を超えて、様々な産業で活用されるようになりました。特に 1970 年のアポロ 13 号の事故対応は、タイガーチームの代表的な成功事例として知られています。 なぜ freee にタイガーチームが必要なのか freee のタイガーチ
こんにちは、関西拠点のお便りとして、「かんさい通信」を銘打って情報をお伝えしていきたいと思います。 普段は、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 サクセス 開発チームメンバーの「成功(サクセス)」を目指し、それだけを念頭に活動を続ける専門のチーム 本記事に
次のページ
このページを最初にブックマークしてみませんか?
『freee Developers Hub』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く