この記事はfreee 技術の日イベントDay2(2024年6月1日)に配布された謎解きコンテンツの解説・あとがきです。 freee謎解き部のkinchanです。 ※ 本職はQAです。謎解き×QAの記事(おまけ謎つき)謎解き制作にfreeeQAプロセスを適用してみた - freee Developers Hubも書いてるのでぜひ見てね! freeeでは先日、5/31と6/1に freee 技術の日 というテックカンファレンスが開催されました。 イベントの内容としては、エンジニアリング、プロダクトマネジメント、デザイン、QAなど、freeeのあらゆる技術をご紹介するものでした。 本記事は、イベントでお楽しみコンテンツの1つとして提供されていた、freee謎解き部で制作した謎解き【free entry】の解説記事となります。 まだチャレンジしていない方向けに当日の状況と配布物をお伝えして、これだ
どうも、freee でエンジニアリングマネージャー をやっている sentokun です。 以前に私の所属しているチームで開発している権限管理基盤マイクロサービスの記事を書いたのですが、そういえば「権限制御ってなに?」という説明をしていないと思ったので、今回記事にしました。 権限制御とは? freee の権限管理基盤が行なっている権限制御とは?を一文でまとめると以下となります。 アクセス制御ポリシーを元に、ユーザーの属性に合わせた適切なアクセス制御を行うこと というわけで、この記事は権限制御について説明しました。ありがとうございました! … とはなりませんよね。ちゃんと一文の中の要素を分解してそれぞれ解説していきます。 ユーザーの属性 適切なアクセス制御 アクセス制御ポリシー ユーザー属性とは? freee ユーザーが持っている、様々な属性のことです。例えば以下が挙げられます。 管理者やメ
ひとり会社を経営してこの4月から第6期になる。期間として次の12月で創業5年になる。先日、その5年近くの経営の中での失敗からのふりかえりについて書いたところ、多くの人たちに読んでいただいたので嬉しい。 この記事で引用した次の経理の書籍についても多くの人たちが読んでくれているようにみえる。それ自体は素直に嬉しいものの、約4年前の記事であるため、当時の私が起業に関して無知だったり、よくわかっていなかった内容もいくつかある。そこで現時点でのアップデートを含め、いま私が起業するならこうした方がよかったと、自身の経験からわかったことを整理してみる。 起業時に夢も希望もない私自身、先にあげた過去の記事を読み返していて、よい大人がひどい理由で会社を辞めたものだと思う。一方で世の中には既存の社会構造や組織に馴染めない人もいる。自分で会社を経営することは自己責任ではあるが、社会に対して馴染めないなにかを少し
2019年12月に自分の会社を設立した。 なんの考えもなく意味なく3月決算にしてしまい、4ヶ月弱で決算を迎え、2ヶ月以内に法人税を納める必要があるので5月に入ってから法人決算を行った。そのときに役立った本の紹介と実際に法人決算をやってみた経験談 (失敗談) を書いておく。 (2024-05-05 追記) 本稿の続編として時間が経ってからわかったことなどをまとめました。 法人設立のきっかけ仕事を辞めようと思ったとき、次にやりたいことはとくになかったし、40歳を超えて年齢的にも雇ってくれる会社をみつけるのは難しいだろうということは容易に予測できた。少し転職活動をしてみたものの、自分自身にやりたいことがないのもあり、あまり手応えを感じなかったので消去法のような流れで起業することにした。 私の場合、会社設立 freee を使って法人設立のための手続きをした。必要な手続きや書類作成など、法人登記まで
共通マスタ基盤チームにおけるソフトウェアエンジニアの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のQAでマネージャーをしてるymtyです。 freee QA Advent Calendar2023 22日目です。 私は、QAマネージャーとしていくつかのプロダクトのQAに関わっています。今日はその中のひとつで、freee会計の申請機能(経費精算、各種申請、支払依頼、購買申請)を担当しているQAのメンバーであるMさんとリグレッションテストで使うテストの設計をした話を書きます。 テスト設計の細かい内容は読み飛ばしたい方は最後のほうにある(ここ大事)テスト設計の裏話って部分だけ読んでもらえればいいと思います! きっかけ 最初にやったこと ワークフローのステータス遷移のテスト設計 テストで確認したい状態やイベントを追記 0スイッチテストケースをテスト実行しやすいように連結してシナリオにする 関連申請の紐付けパターンと申請時の入力パターンのテスト設計 権限のテスト設計 (こ
freee、デザインシステム「vibes」を公開 アクセシビリティをはじめとするフロントエンド開発のノウハウが満載 ■マジ価値サマリー(このお知らせでお伝えしたいこと) ・freeeのアクセシビリティをはじめとするフロントエンド開発のノウハウが詰まったデザインシステム「vibes」を公開します ・あらゆる組織でシステム開発に携わるエンジニアやデザイナーの皆様に、「vibes」を利用してシステムを構築いただく、またはコード等を参照いただくことで、社会全体としてアクセシビリティ向上の取り組みが広がることを目指しています freee株式会社(本社:東京都品川区、CEO:佐々木大輔、以下「freee」)は、freeeがこれまで培ってきたアクセシビリティをはじめとするフロントエンド開発のノウハウが詰まったデザインシステム「vibes(読み:ヴァイブス)」を公開しました。本デザインシステムを公開するこ
この記事はfreeeアドベントカレンダー2023の19日目の記事です。 こんにちは!freeeカードチームのmattsunです。freeeカードUnlimitedの開発運用をしています。私は1年前にfreeeに入社しfreeeカードチームに所属しています。これまでの自分のエンジニアとしてのキャリア(10年強)を通してみても、今のチームではPRレビューやリファクタなどからの学びが多いなぁと感じます。個人的に学びがあったことやチームとしての知見が深まったもののうち、ベスト5(私の主観)をまとめます。 freeeカードシステムは、フロントエンド(TS,React)・BFF(RoR)・Backend(Go)で構成されており、Goでの開発比率が多いことから、本記事はGoのコードに関する言及が多いです。freee社全体をみるとRailsで開発されたシステムも多いですが、Goで開発しているサービスもある
こんにちは。freee の Platform Solution チーム1 に所属している nkgw (Twitter) です。 この記事は freee 基盤チーム Advent Calendar 2023 の 15 日目の記事となります。 普段は、エンジニアリングマネージャーをしつつ、新規プロダクトのリリースサポートとか、プロダクトのキャパシティプランニングやコンピューティングリソース調整などをやってました。 今回、freee のプロダクトにおける health check の標準化について取り組みました。health check の要件と非標準化がもたらす具体的な問題を整理しつつ、freee では実際にはどのように health check を定義したのかを紹介します。 その前に... 詳細な内容の前に、弊社のような複数のプロダクトが相互に依存関係があるような環境下における health
この記事は freee Developers Advent Calendar 2023 の 14 日目の記事です. freee でエンジニアをしているけむりだま (@_kemuridama) です. 普段は freee 会計の技術的負債の返済や実装の標準化を行っている会計基盤というチームで freee会計の TypeScript 化を進めています. エンジニアとしての業務の傍ら freee で色々なことをやっていて, dev branding チームで技術広報的なことをしていたり, 社内イベントの運営をしたりしています. 昨年までは株主総会のオンライン配信を担当してたりしていました. その中でも今回は運営リーダーを務めている,「freee Tech Night」という freee 主催の技術イベントが 5 周年を迎えた話をしていこうと思います. freee Tech Night とは fr
こんにちは!freeeでアプリケーションエンジニアをしているおっそーです。 この記事は freee 基盤チームアドベントカレンダー の11日目になります。 昨日のuryyさんのPagerDutyについての記事はいかがでしたでしょうか?😊 わたしは外部サービス連携開発部のグロースエンジニアをやっており、1年半ほど運用負荷の改善に努めてきました。今回はその取り組みについてお話します。 また、外部サービス連携開発部は freee 内部ではコアエンジンチームと呼ばれているので以降コアエンジンチームと記載します。 コアエンジンチームとは freee会計の一機能で銀行やクレジットカード、交通系IC、レジサービス、決済サービスなどのfreee外のサービスからユーザーのお金の動きについてのデータをfreee会計に連携して、ユーザーの仕訳業務を自動化・効率化する連携機能を開発しているチームです。 以前 f
freee 基盤チーム Advent Calendar 2023 13日目です。 はじめまして。SRE Platform Delivery チーム(以下 Delivery チーム)の tetora です! 今年の3月に freee に join しました。 年末年始はずっと積ん読していた三体の完結編を満を持して読もうと思っています。今からワクワクが止まりません。 はじめに 現在、freee ではプロダクト開発に Amazon EC2 を標準の開発環境として採用しています。 どの IT 企業でも入社したエンジニアがまずはじめにやることは開発環境の構築かと思います。 そして多くの場合、開発環境の構築は入社したてのエンジニアにとって最初の難関だと思います。 freee には多くの開発者がいます。プロダクトの規模も大きく数も多いです。 開発環境の構築のしやすさや安定した運用はプロダクト開発において
はじめに こんにちは! freeeアドベントカレンダー2023の13日目の記事を書きます、金融開発カード事業部Engの田畑です。 現在、私はfreeeカードの開発運用に携わっております。 www.freee.co.jp この10/1に入社をさせて頂いたので、入社直後の今でないと書けないようなことを書いてみようと思います。 私がfreeeに入社するまでを振り返ると様々な規模の会社に所属していました。その規模の違いを一つの切り口にして、その中で感じたことを今回書きました。 分かりやすく規模の違いをタイトルにはしていますが、組織の規模が同じぐらいであったとしてもその会社や組織の歴史が違うので一口にそれが組織規模の違いだと言い切ることは出来ないです。 あくまで一つの切り口である点はご了承下さい。 ターゲット、想定読者 メガベンチャーから独立や創業期のベンチャーにキャリアを変えようと思っている人 キ
SRE 統制チームの oracle です。 この記事は freee 基盤チームアドベントカレンダー の12日目になります。 今回は AWS の 組織移行を行った話をさせて頂きます。 AWS の 組織移行というのはどういうこと?と思われる方もいらっしゃるかと思いますので、正しく説明しますと、 既存の複数の AWS アカウントを構成している AWS Organizations を解体し、新規に作成した AWS Organizations にすべてのアカウントを移動させました。 となります。 その動機とアプローチについてご紹介したいと思います。 背景 AWS 組織移行する前から、freee では 数十の AWS アカウントを運用していました。運用の仕方は組織によって様々ですが、一般的にはプロダクトで分けたり、環境で分けたりすることが多いかと思います。 freee でも同様の手法でアカウントを分け
こんにちは、freeeで決済プロダクトのQAエンジニアをしているrenです。freee QA Advent Calendar 2023 - Adventarの11日目です。 この記事では、決済プロダクトでアジャイルQAを実践するために取り組んでいる、バックエンドQAの事例を紹介します。 決済プロダクトで取り組んでいるアジャイルQA 決済プロダクトの開発はスクラムで行なっており、QAを含むOneTeam*1で行っています。 そのため、QAエンジニアもスクラムイベントに出ており、開発と併走できるQA活動を目指して日々仕事に取り組んでいます。 このようなQA活動をfreeeではアジャイルQAと呼んでいます。詳細な経緯や意図については、ymty-sanの記事を参照ください。 developers.freee.co.jp スクラムのイテレーティブな開発にあわせてイテレーティブにアジャイルQAを行うこ
はじめに こんにちは!freee の Enabling SRE チームに所属している阿部 寛明 (uryy)と申します。freeeのシステムを運用する際にはDatadogからの通知をもとにアラート対応するケースが多いのですが、組織拡大により従来の方法ではうまくワークしない箇所もでてきたので改善に取り組んでおります。今回はその一環で進めているPagerDuty導入の取り組みとその際に気づいたTipsについて紹介します。 PagerDutyについて PagerDutyは監視ツールやアプリケーションからのアラートを受けてインシデント発生を担当者にオンコール通知するプラットフォームサービスです。オンコール機能だけでなく、受け取ったアラートのトリアージやシフトに基づいたエスカレーションも可能となっています。freeeでは下記図のようなシステム連携の環境構築を進めています。 システム連携イメージ 現在
こんにちは。決済プロダクトでQA兼スクラムマスターをしているbarusです。 本日はfreee QA Advent Calendar2023 7日目です。 adventar.org 今回は「スクラムマスターを兼任して見えてきた、シフトレフトのための立ち回りとやってきたQAの活動」と題してお話させていただきます。 freeeカードUnlimitedの立ち上げ期から現在に至るまで、各チームを転々としながら、いずれもスクラムチームの一員としてアジャイルQAを行ってきました。 今年の9月からスクラムマスターを兼任しながら、日々品質とスピードの両立に取り組んでいます。 本記事ではスクラムマスターを兼任して見えてきた視点を交えながら、より早期にシフトレフトをしていくためにQAがどのように立ち回るべきか、そして実際に自分たちのチームがやってきたことをお話しようと思います。 ここではQAプロセスの最適化と
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く