こんにちは。QAエンジニアをしているharashinです。 freeeプロダクト共通で利用される従業員情報や取引先などのマスターデータを扱うプロダクトを担当しています。 freee QA Advent Calendar2024 1日目です。 adventar.org 去年に引き続き、QA Advent Calendar2024の発起人です。 今年も無事QAエンジニアだけでアドベントカレンダーを実施できることを大変うれしく思います。 去年のアドベントカレンダーを実施するにあたり、多くの方に圧をかけた結果、社内ではharashin とハラスメントがかけ合わさったハラシンメントという造語が作られました。 harashin とハラスメントがかけ合わさったハラシンメントという造語 今年は、「テストレシピをやってみた」というタイトルでアドベントカレンダーを書いてみようと思います。 チームのQAに関する

SRE team の suzuki-shunsuke です。 今年の 8 月(約3か月前)から freee の SRE team に join しました。 本記事では Terraform Monorepo の CI の実行時間を CIAnalyzer で可視化し 2 分 (70 percentile で約 160 %) 以上高速化した話を紹介します。 背景 freee には AWS などを管理する Terraform の Monorepo があり、 SRE を中心に多くの開発者がそのリポジトリで開発を行っています。 CI には GitHub Actions の Self-hosted Runner を使っています。 フローとしては GitHub Flow を採用しており、 Pull Request を作成すると CI で terraform plan が実行されます。 terraform

こんにちは。現在プロダクトマネージャー兼ソフトウェアエンジニアとしてfreee人事労務の開発を行っている金山（@tkanayama_）です。私は現在、労務担当者の勤怠締めにまつわるペインを解消するための「勤怠モニター」という機能を開発しており、この開発を通して特にプロダクトマネージャーとして様々な学びを得ています。今回はその中から、「スコープの絞り方」について考えたことを整理します。 時間・予算・品質・スコープのトレードオフ プロジェクトにおいて、時間・予算・品質・スコープはトレードオフの関係にある場合が多く、私も日々このバランスに頭を悩ませています。 これについて、書籍「アジャイルサムライ」では以下のように主張されています。 時間と予算、それから品質は固定されたものとみなし、スコープを柔軟に扱うのだ。 たしかに実体験としても、苦渋の決断としてスコープを切り詰めざるをえない場面が多いように

こんにちは、『freee技術の本』編集長のWaTTsonです。 先日のブログ記事で、技術書典17で『freee技術の本』の第2弾を出すことを発表しました。 developers.freee.co.jp 前回の記事では概要だけを公開していましたが、書影や目次などの詳細を公開します！ 『freee技術の本 freeeにおけるマルチプロダクト開発 ～モノリシックとマイクロサービスの狭間で～』 目次 第I部 freee のプロダクトアーキテクチャと開発 第1章 成熟したプロダクトの大規模リアーキテクチャ～統合分離への挑戦～ 第2章 インタビュー: 新しい業務システムを作るために必要な思想を巡って 第II部 マルチプロダクトを構成する要素 第3章 アクセス制御基盤 第4章 ワークフロー基盤 第5章 通知基盤 第III部 freee のプロダクト開発を支える基盤チーム 第6章 マイクロサービスにおける

読まなくても良い漫才パート ボケ「いきなりですけどね、freee人事労務の給与計算ロジックでいつも使ってる DB instance があるらしいんやけど」 ツッコミ「あっ、そーなんや」 ボケ「うちのオカンがね、reader instance なのか writer instance なのかをちょっと忘れたらしくてね」 ツッコミ「どうなってんねそれ」 ボケ「でまあ色々聞くんやけどな、全然分からへんねんな」 ツッコミ「分からへんの？いや、ほな俺がね、どっちの instance なのか、ちょっと一緒に考えてあげるから。詳しく教えてみてよ」 ボケ「オカンが言うには、どちらかというと CPU 利用率がいつも低い方らしいねん」 ツッコミ「おー reader instance やないかい。freee人事労務 の DB で CPU 利用率が低い方は reader instance や。黄色の折れ線の方や。r

こんにちは、DBRE (Database Reliability Engineer) の shinta です。 今回は、Aurora MySQL 3.04.2 に存在する DDL の予期しない挙動について紹介したいと思います。 発見のきっかけ きっかけは、Aurora MySQL 3.04.1 に存在した以下の事象の検証でした。（CyberAgent 様の記事で事象の存在を知り、検証するに至りました。ありがとうございます！） ca-srg.dev これがどんな事象かというと、「ALGORITHM=INPLACE で特定の online DDL を実行している間、そのテーブルに reader からアクセスできなくなる」というものでした。 writer で DDL を実行している間、reader からそのテーブルにクエリを投げると以下のエラーが出ます。 Table 'db_name.tbl_n

どうも、freee でエンジニアリングマネージャー をやっている sentokun です。 以前に私の所属しているチームで開発している権限管理基盤マイクロサービスの記事を書いたのですが、そういえば「権限制御ってなに？」という説明をしていないと思ったので、今回記事にしました。 権限制御とは？ freee の権限管理基盤が行なっている権限制御とは？を一文でまとめると以下となります。 アクセス制御ポリシーを元に、ユーザーの属性に合わせた適切なアクセス制御を行うこと というわけで、この記事は権限制御について説明しました。ありがとうございました！ … とはなりませんよね。ちゃんと一文の中の要素を分解してそれぞれ解説していきます。 ユーザーの属性 適切なアクセス制御 アクセス制御ポリシー ユーザー属性とは？ freee ユーザーが持っている、様々な属性のことです。例えば以下が挙げられます。 管理者やメ

こんにちは、 freee でエンジニアリングマネージャーをやっている sentokun と申します。 4 月になり、新人や中途入社など新メンバーの参入など、チームの変化を感じている方も多いのではないでしょうか？ この記事では、そんな新メンバーの受け入れ時に、チームで大切にしたいと思う心構えについて記載していきます。 人と環境には相性がある！焦らずその人にあったペースで 新メンバーは、チームに参画する際とにかくできるだけ早く環境に慣れて成果を出したい！と考えると思います。特に経歴がある中途入社だと、本人は経験がある分早く成果に繋げられるはず！と考えるし、受け入れ側の視点でも、経験豊富なんだから早くキャッチアップしてくれるはず！と期待するかもしれません。 もちろんスタートダッシュが決めれれば大きいですし、そのために全力を尽くすことは大事だと思います。一方で、うまくいかない場合の大事な心構えもあ

共通マスタ基盤チームにおけるソフトウェアエンジニアのyugoです。 共通マスタ基盤チームは、従業員、商品、取引先といった製品横断で利用できるマスタデータを一元管理し、ユーザーにfreeeプロダクトにおける統合体験を提供できる基盤開発をミッションとしております。 そんな共通マスタ基盤チームチームですが、製品横断で利用されるとだけあり、日々の開発フローでPRレビューの割り込みが多いです。そんな中で、開発フローにgit worktreeを導入してみて、個人的にはPRレビューの割り込み作業時に割と使いやすかったので紹介します。 git worktreeを使うに至る背景 実はfreeeで働く以前、前職で先輩シニアエンジニアが「レビューするときにgitのstagingにあげていない自分の変更を、stashしたり、テキトーにcommitしてからrebaseするなりするの嫌だったら、worktree使った

こんにちは。認証認可基盤エンジニアのてららです。 最近好きな言葉はコンフォートゾーンです。好きな食べ物はニンジンです。 猫派です。 経緯 週末、パートナーが祖父母の家に帰るということで付き添いをしてきました。 その1つの目的としてパートナーの祖父（以下、おじいちゃん）がスマートフォンを利用していたのに急にスマホアプリから認証を求められて困っている、とのことでそれの解決をしていました。 「なんとか出来ないかねぇ」ということでパートナーがおじいちゃんのスマホを触りながら操作方法を教えつつ、認証情報を探しておじいちゃんに手解きしている様子を眺めていました。 その時、“ログイン”や“ユーザーID”、知識認証情報を紙に記してその紙の管理をしていたところからこのアプリは何をしたかったのか、おじいちゃんが苦労せずにアプリを触るためにはどうあるべきなのかをずっと考えていました。認証認可基盤のエンジニアとし

こんにちは、freeeでアプリケーションエンジニアをしているossoです。 日本酒のしぼりたての季節ですね。今年も良い出会いがありました。日本酒だいすき🥴🍶 今回はfreee社内で実施しているエンジニアのエンジニアによるエンジニアのためのイベント「成果発表祭」についてお話ししたいと思います。 （「歴史と変遷」なんて大掛かりなサブタイトルをつけてしまいましたが、2022年からの2年間について語ります。笑） エンジニア成果発表祭とは 「エンジニア同士がお互いの成果を知り、成果を称賛し合う場」として、エンジニアが内発的にはじめたイベントです。 私の入社時点（2021年11月）からすでに定着しており、毎クォーター（3ヶ月）ごとに1回実施しています。 成果発表祭のやり方や目的に合わせて賞も用意しており、賞を取るとお菓子などがもらえます。 運営メンバーは有志で集まっており、「他の開発チームのひとと

こんにちは、北海道から freee PSIRT（Product Security Incident Response Team）に参加している yu です。 今年は雪が少ないな〜と思っていたら最近ドカドカ降るようになってきて、1日デスクで集中した後に外に出ようとすると玄関のドアが雪で開かない日もありました。雪国エンジニアの各位、除雪も忘れず頑張っていきましょう！ さて、この記事では前回の記事で bucyou が紹介した開発合宿において、私と同僚の tomoya さんで取り組んだ freee の Attack Surface Management（以下、ASM）について紹介します。 ASM とは ASM、Attack Surface Management という用語はさまざまなところで異なる定義がされており、私自身、この言葉を使うときにはまだ少しだけ違和感があります。 国内では昨年の5月に経

こんにちは、関西拠点にて freee販売の開発を行っております、bucyou (ぶちょー) です。2023年も freee Developers Hub をご覧いただきありがとうございました。2024年も引き続き freee での技術的な知見や、カンファレンスレポートをお送りしてまいりますので何ぞとよろしくお願いいたします。 さて、昨年は Advent Calendar の真っ只中でお知らせ出来ていなかった、2023年の開発合宿についてのご報告です。 過去の開発合宿の記事一覧です。 2022年も開発合宿を開催しました！ - freee Developers Hub 2021年も開発合宿を開催しました - freee Developers Hub 2020年も開発合宿を開催しました - freee Developers Hub 2019 年も開発合宿を行いました - freee Develo

こんにちは。freee販売を大阪で開発しております、bucyou (ぶちょー) というものです。 この記事は、freee Developers Advent Calendar 2023 の10日目です。 例によって普段は Ruby on Rails で開発をしておりますが、ここでのアーキテクチャや、モデリングに関する話題は、先日 freee技術の本 に書かせていただきました。 また、先日は TechNight にて、freee販売での取り組みを紹介させていただきました。 この本や、イベントの中で伝えたかったメッセージとしては、以下のようなものでした。 実現したいビジネスを、より適切に表現するためにモデリングを重視していく。 ActiveRecord によって作られたモデルと、ビジネスを表現するためのモデルをしっかり分けていく。 しかし、本はみんなで書いているものだったのでページ数はある程度

こんにちは。freeeでQAのマネージャーをやってるでーにしです。 freee QA Advent Calendar2023 25日目です。QAマネージャーをしていて、あるあるアンチパターンを見事に踏んでいったので、振り返って良いお年を迎えたいと思います。 失敗①運用を考えずに自動テストを作ってしまう（2017年くらい） freeeではいくつか自動テストがありますが、一番運用が大変なのはE2Eテストになります。 E2Eテストについての詳細は、以下の記事をご参照ください。 developers.freee.co.jp その運用が大変なE2Eテストを運用を考えずに作ってしまいました。 当時の自分の経験値としては、作ったこともあるし、日々の運用もしたこともあったので、運用の大変さも味わっていたと思っています。 なんで失敗したか、考えてみます。 何をしたか 当時のテストシステムは、テストシナリオと

京王線 16:27 各停 調布 32768両編成 こんにちは。freeeでQAのマネージャをやってるuemuです。freee人事労務とグローバル開発のQAをメインで担当しています。 これは、freee QA Advent Calendar2023 23日目の記事になります。 はじめに みなさん、境界値分析はやってますか？ 普段、QA業務を行っている人だったら、やったことがない人はいないでしょう。「そんなの知ってるよ」「いつもやってるよ」という人がほとんどだと思いますが、今回は普段より少し広い視野で境界値分析をやってみたいと思います。 ちょっと話が脱線しますが、私はブラタモリという番組をよく観ます。タモリさんが“ブラブラ”歩きながら知られざる街の歴史や人々の暮らしに迫る番組ですが、その中でタモリさんがよくこんなことを言っています。 「へりがおもしろいんですよ、へりが。」 「事件はへりで起きて

こんにちは。freee の Platform Solution チーム1 に所属している nkgw （Twitter） です。 この記事は freee 基盤チーム Advent Calendar 2023 の 15 日目の記事となります。 普段は、エンジニアリングマネージャーをしつつ、新規プロダクトのリリースサポートとか、プロダクトのキャパシティプランニングやコンピューティングリソース調整などをやってました。 今回、freee のプロダクトにおける health check の標準化について取り組みました。health check の要件と非標準化がもたらす具体的な問題を整理しつつ、freee では実際にはどのように health check を定義したのかを紹介します。 その前に... 詳細な内容の前に、弊社のような複数のプロダクトが相互に依存関係があるような環境下における health

この記事は freee 基盤チーム Advent Calendar 2023 の 22 日目の記事です。 こんにちは、freee のDBRE (Database Reliability Engineering) で ジャーマネ（マネージャー）としてDBRE組織を運営管理しているJuni です。 今回は何故integration環境*1を相乗り化してきたのかという話しをしていきたいと思います。 始まる前に、タイトルにも書いてある「DB相乗り」に関して一度定義していきましょう。 DB相乗りとは、複数の論理Databaseを1つの物理cluster内にまとめて乗せておく事です。 何故integration環境を相乗り化しようとしたのか？ freeeでのintegration環境は主にproductionへのリリースの前の機能テスト、QAなどで使われていまして、数十環境が構築されています。 それぞ

SRE 統制チームの oracle です。 この記事は freee 基盤チームアドベントカレンダー の12日目になります。 今回は AWS の 組織移行を行った話をさせて頂きます。 AWS の 組織移行というのはどういうこと？と思われる方もいらっしゃるかと思いますので、正しく説明しますと、 既存の複数の AWS アカウントを構成している AWS Organizations を解体し、新規に作成した AWS Organizations にすべてのアカウントを移動させました。 となります。 その動機とアプローチについてご紹介したいと思います。 背景 AWS 組織移行する前から、freee では 数十の AWS アカウントを運用していました。運用の仕方は組織によって様々ですが、一般的にはプロダクトで分けたり、環境で分けたりすることが多いかと思います。 freee でも同様の手法でアカウントを分け

こんにちは、freeeのQAでマネージャーをしてるymtyです。 freee QA Advent Calendar2023 22日目です。 私は、QAマネージャーとしていくつかのプロダクトのQAに関わっています。今日はその中のひとつで、freee会計の申請機能（経費精算、各種申請、支払依頼、購買申請）を担当しているQAのメンバーであるMさんとリグレッションテストで使うテストの設計をした話を書きます。 テスト設計の細かい内容は読み飛ばしたい方は最後のほうにある（ここ大事）テスト設計の裏話って部分だけ読んでもらえればいいと思います！ きっかけ 最初にやったこと ワークフローのステータス遷移のテスト設計 テストで確認したい状態やイベントを追記 0スイッチテストケースをテスト実行しやすいように連結してシナリオにする 関連申請の紐付けパターンと申請時の入力パターンのテスト設計 権限のテスト設計 （こ