サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大阪万博
developers.freee.co.jp
はじめに 最近の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 サクセス 開発チームメンバーの「成功(サクセス)」を目指し、それだけを念頭に活動を続ける専門のチーム 本記事に
こんにちは。権限管理基盤チームで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サービスの開発では、普段気づきにくい境界(以下、「へり」)が多数
こんにちは!freee 債権請求書領域でプロダクト開発に取り組んでいる 🇰🇷 韓国出身のエンジニア jason です。 この記事は freee Developers Advent Calendar の24日目🎄になります。 adventar.org すでにお気づきの方もいらっしゃるかもしれませんが、今年のアドベントカレンダーでは担当の25名の中で、債権請求書チームのエンジニアが5名も参加していて、朝会などで雑談ネタとして大いに盛り上がっています! また、QA エンジニアである nori さんも参加していて、それぞれが興味深いテーマで構成されていますので、まだ読んでいない方は、ぜひご覧ください! jaxx:拠点が離れているチームメイトに物理的に励ましてもらう雑電子工作 - freee Developers Hub kochan:社内経理にプロダクトのFBをもらった話 - freee D
こんにちは。決済プロダクトでQAエンジニアをしているrenです。freee QA Advent Calendar2024の23日目です。 今回は、決済プロダクト開発にテストアーキテクチャを設計した事例について紹介します。 テストアーキテクチャとは テストアーキテクチャによって解決したい課題 テストアーキテクチャ設計のステップ 1. この振る舞いを担保するためには、どのようなテストが必要だろうか?という問いを立てる 2. 抽象化して考えるための概念を学ぶ 3. テストアーキテクチャを描き、議論する テストアーキテクチャ設計のインパクト 実装改善に関する気づき テストの構造とソフトウェアの構造に関する気づき 自分たちのテスト活動の課題に関する気づき チーム開発の支援を通じた工数上のインパクト テストアーキテクチャがもたらす価値 今後の展望 [appendix]今回設計したテストアーキテクチャの
こんにちは!PSIRT ( Product Security Incident Response Team ) でお仕事をしています、kaworuです。 この記事は freee Developers Advent Calendar 2024 Advent calendar 21日目です。 今年も残すところあと10日!今日はfreee の Red teamについての記事を書きます。 freee Red teamの発足と模索 Red teamは、攻めの視点からセキュリティを担当する役割です。 対して、守りの役割はBlue teamと表現します。 両チームあって効果が発揮され相互に高め合う関係性から、freeeでは別の組織に分かれておらず、PSIRTの中の役割として存在します。 さかのぼること1年半前の2023年7月より、自分たちは freee の Red teamと宣言しました。 Red te
この記事は freee Developers Advent Calendar 2024 の 22日目のエントリーです。 こんにちは、PSIRTでtech leadをやっている eiji です。冬にモヒート作ろうとしたらライムが手に入らず、柑橘類だから秋から冬にとれるはずでは? と調べたらライムは四季咲きだそうです。もしかして、ここでも買い負けているということ? TL;DR Redisのnetwork帯域を使い果たして自滅する話 です。 RedisをCacheとした構成 Redisをcacheとして用いた構成は、ごくありふれたものだと思います。 Redisをcacheとして利用したよくある構成 session IDに対応するuser IDと各種statusを返してもらって処理をする、といった感じです。 user IDはbrowser側からcookieやheaderで送付してもらって、Redi
統合UX基盤というチームでエンジニアをしているtakumiです。freee Developers Advent Calendar 2024の20日目は、現在社内向けに開発を進めている新しいUIライブラリ「標準UI」について、その特徴や開発過程を紹介していきます。 デザインシステムの浸透と新たな課題 freeeでは2018年からデザインシステム「vibes」を開発・運用してきました。最近ではOSSとして公開し、アクセシビリティをはじめとするフロントエンド開発のノウハウを広く共有できるようになりました。以前の記事「デザインシステム "Vibes" の育てかた」でも詳しく解説していますが、vibesの導入により、ボタンやフォームといった個々のUIコンポーネントのデザインは標準化され、一定の成果を上げることができました。 しかし、アプリケーションの規模が拡大し開発チームが増えていく中で、新たな課題
こんにちは。freee人事労務でQAエンジニアをしているしほです。 freee QA Advent Calendar 2024 18日目です。 なぜこのアンケートを実施しようと思ったのか QAの仕事は多岐にわたり、普段自身が業務をしている時に今すごく楽しいなと思うことが沢山あるのですが、他のQAの方をみていたり話していると人によって楽しいなと思う所が違ったりするのでは?と思い始めました。 QA業務の魅力についても人によって考え方が違いますし、アンケートをとってみました。 17名から回答を頂いたのでそれを発表したいと思います! アンケートの概要 アンケート対象者 フリーでQAエンジニアとして働くメンバー アンケート項目 質問1. QAの仕事で一番テンションがあがるのは?(選択式) テスト対象調査 テスト設計 テスト準備 テスト実行 振返り テスト管理 自動化テスト対応 その他 質問2. 質問
こんにちは。 この記事は freee Developers Advent Calendar 2024 - Adventar 18日目の記事です。 adventar.org 担当するのは債権と請求書ドメインでPdL(プロダクトリード)をしているJumpです。以後お見知り置きを! 今日はfreeeのロールモデルのひとつであるPdLとはなにか、何をしているのかの一例を紹介しようと思います。 そもそもPdL(プロダクトリード)って何? 理想のユーザー価値を実現するリード人材でfreee の名称では PdL、プロダクトリードと呼んでいます。 ここ数年で生まれた出来立てほやほやのロールモデルです。 PdM(プロダクトマネージャー)とは何が違うん? プロダクトをリードしていくといえば、一般的にはPM(プロダクトマネージャー)を思い浮かべる方が多いのかなと思います。PdMは事業計画を司り、ユーザー体験を向
freee Developers Advent Calendar 2024 17日目の記事はWaTTsonが担当します。昨年のAdvent Calendarでは「credentialをSlackに書くな高校校歌」というのを出してプチバズりしていたのですが、今回はネタ枠ではなくもうちょっと真面目な話を書きます。 developers.freee.co.jp 脅威モデリングの取り組み みなさんは開発しているシステムに対して「脅威モデリング」を行っているでしょうか?脅威モデリングとは、システムの各要素が持つ様々な脅威を挙げ、それらの緩和策を考えて整理する、という取り組みです。最近では、12月6日・7日に脅威モデリングナイト#5とTMC Tokyo x ZANSINの2日連続でのイベントが開催されたりと、界隈が活気を見せつつあります。 freeeでは、2023年に開催した自社カンファレンス「fre
こんにちは。QAエンジニアをしているtoyopiです。 フリー以外のサービスと連携するプロダクトの一員としてQAをしています。 freee QA Advent Calendar2024 17日目です。 去年に引き続きアドベントカレンダーを執筆しております!! developers.freee.co.jp はじめに 約1年前、私は今の開発チームに配属されました。 悲しいことに、このチームは社内で1、2位を争うほど障害(※)が多いチームです…。 このチームが開発するプロダクトで起きる障害の中には、外部連携先に依存する原因もありなかなか一筋縄ではいかない現状です。 そうは言っても、ユーザーにとってはバグがあることには変わりないので、対応していかなければならないという難しさがあります。 そんな障害が多いチームで、約1年間QAをやっている私の取り組みを、課題とアクションとともにご紹介していこうと思い
次のページ
このページを最初にブックマークしてみませんか?
『freee Developers Hub』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く