freeeの社内異動制度「異動戦国」のチーム紹介を一挙公開

こんにちは、DevBrandingのellyです。

先日ブログでご紹介したfreeeの社内異動制度「異動戦国」、この時期になると社内では毎年、異動希望者を募集するために各チームの熾烈なPR合戦が繰り広げられます。

今回は、その際のSlackや社内WikiでのPR合戦の様子をご紹介します。募集期間中の社内の雰囲気やfreeeの開発組織にはどんな仕事があるのか、どんな魅力があるのかを知ってもらうきっかけになれば嬉しいです。

チーム紹介

SREチーム
DBREチーム
DXチーム
IAM （認証認可基盤開発）チーム
サービス基盤チーム
課金基盤チーム
ERP基盤チーム
データ基盤チーム
コアエンジン（外部サービス連携）チーム
AIラボチーム
会計チーム
LEGO（Public API・アプリストア開発）チーム
人事労務チーム
金融チーム
プロジェクト管理チーム
モバイルチーム
申告チーム
スモール会計/グロースチーム
SEQチーム
CREチーム
プロダクトデザインチーム
PSIRTチーム

SREチーム

業務内容：Site Reliability Engineering（インフラの管理・運用の自動化、システムの最適化、スケーラブルかつ安定的なサービス稼働を実現する基盤の開発）

SREは主にソフトウェアエンジニアリングによりインフラストラクチャの管理や運用を自動化・効率化していくことで、サービスの規模・複雑さ・数に対してスケーラブルに安定稼働を実現していくことを生業としています。

何が面白いの？

大量のリソース・コンポーネントを一手に受け持ち、洗練された自動化の仕組みを作り上げたり、ミドルウェアやプラットフォームの仕様や仕組みを深堀りしてそのポテンシャルを引き出したり、システムをいい感じに統合したりといったところに個人的なやりがいを感じています。

思い通りに動くシステム、調和の取れたアーキテクチャ、優れた仕組みを理解し使いこなすことにより世界が拡張されていく感覚、とてもいいですよね。いいと思います。

加えて、Kubernetesに代表されるように、インフラの抽象化技術は進化が著しく、その流れを身近に感じられることや、DBなどの、深い含蓄やコンピュータサイエンスの真髄が感じられるミドルウェアやシステムに触れる機会が多いのもワクワクできる点です。もちろん触るだけでなく使いこなすことが求められます。楽しい。

freeeのSRE今昔物語

まずfreeeはAWSをサービスの主な土台として使っています、これはおそらく今後も変わらない。では何が変わるのかというと、サービスの数、規模、複雑さ、です。コスト・セキュリティリスク・パフォーマンス・開発生産性・オペレーションコスト、といった課題が徐々に大きくなっていき、さらにサービス数が増えていくと、徐々にシステム全体を制御できなくなり、運用が機能不全に陥るでしょう。もちろん人員を増やすということで対応もできますが、限界があります。なので自動化や横展開を進めたり、それらを効率化に組織するためのモジュール化や標準化が必要になってきます。これらにより戦略的に対応していくために、SREは現在、DBの運用改善をターゲットにおくDBRE、開発生産性をインフラから支えるDX、Site Reiliabilityを推進するSREの3チーム体制となっています。

SREの中にSREチームがある構造ですが、現在役割を更に整理して再編中です。SREチームでは、長らくサービスの足回りをKubernetesに載せ替えるプロジェクトを推進しています。しかし、すべてのサービスに最適化された共通の仕組みを一息で作ることは難しく、サービスに深く入り込んでシステムを最適化していく、その上で得られた知見を共通基盤に還元する、というサイクルも必要になりそうです。また、サービス毎のSLI/SLOを策定・合意し、サービスの品質をDevとSRE一体となって維持していく、といったプロセスもこれまでは不十分でした。今後は、横断的仕組みを育てていくプラットフォームSREと、サービス個別の最適化や安定稼働達成を担うサービスSREの2面体制でさらに推進していきたいと思っています。

DBREチームとDXチームの紹介は別記事にありますのでそちらに譲ります。

アプリチーム x SRE チームによるアプリケーションモニタリング運用改善 - freee Developers Hub

SRE カテゴリーの記事一覧 - freee Developers Hub

DBREチーム

業務内容：Database Reliability Engineering（データストア系ミドルウェア活用によるサービススケーラビリティ実現）

DBRE では「業務システムの一段下、ミドルウェアのレイヤーに詳しくなりたい人」を募集しています。

freee プロダクト群の安定的成長を支える基盤作りが SRE のミッションなわけですが、最も大きな技術課題の1つがデータストア層のスケーラビリティの確保です。主要なミドルウェアであるところの RDBMS の運用品質が保てなくなると、サービスの安定提供ができなくなり、ひいては会社として安定して事業を行うことができなくなります。そんなクリティカルなミッションを担うのが DBRE です。

アプローチとしては、DBA 的な集中管理方式ではなく、各チームが適切にデータストア層を運用できる仕組み作りや、ルールを整備するプラットフォーム活動を手段とし、安定的なサービス提供を目指しています。

得られる経験

ミドルウェアの知識を増やすことが比較的成果に直結しやすいので、こういったミドルウェアの知識を増やしたいという方にとっては面白いんじゃないかなと思います。我々もまだまだ理解度が低い部分があるので一緒に詳しくなりましょう。

MySQL
Aurora MySQL
Redis
Elasticsearch
DynamoDB
Kinesis Data Stream

Web という領域において、システムのボトルネックの大半はデータストア層ではないでしょうか。そういった意味で、一般的な Web サービスの運用に関して得るものが多いのではないかと思います。ミドルウェアの特性上、課題の要件として無停止性が求められることが多く、技術的難易度の高い課題も多いです。

監視ツールは Datadog、運用ツールは ECS/EKS を terraform で運用しているので、そういった技術スタックもついでに詳しくなれます。

MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub

DXチーム

業務内容：Developer eXperience（開発者体験）の向上

SREではかねてより、サービスの安定稼働に加えて開発生産性をObjectiveに持っていましたが、サービス安定稼働が優先されがちで、余力で開発生産性、という優先度で進めていました。ただ、昨今の開発者の増加・サービスの数、複雑さの増大により、開発環境構築の問題や、検証環境の治安悪化、QA工程への影響、といった課題が浮き彫りになってきています。

この事態に、2021年より発足したのがDXチームで、コンテナ化の進んだインフラを最大活用するようなCI/CDパイプラインや次世代評価環境・開発環境の検討を推し進めています。

DX チームでは開発者体験を良くするため、そして失敗して攻めようのカルチャーを守るためにさまざまな施策に取り組んでいます。

canary release を導入して安心して攻めれるデプロイの実現
freee会計のステージング確認中の hotfix を減らして、デプロイまでの時間を短くする
開発者に高速かつ安定したビルド環境を継続的に提供する

ロードマップも徐々に決まっていますが、まだまだ人が足りない状況です！デラックスな仕事をしたい方、ぜひご応募お待ちしています！

CloudNative Days Tokyo 2021 に参加しました - freee Developers Hub

IAM （認証認可基盤開発）チーム

業務内容：identity and access management（freee の認証認可、権限管理マイクロサービスの要件定義・設計・開発、他社サービスIDとの連携の要件定義・設計・開発）

IAMチームは各プロダクトの基板となるサービスを開発するチームです。今は主に以下をやってます。

会計に密接にならない新しい認証/アカウント管理基盤の開発
プロダクト横断で権限管理ができる新しい権限基盤の開発
M&A / 銀行等とのつなぎ込み freeeアカウント管理の開発

詳しくは以下の資料を参照してみてください。

speakerdeck.com

丑三つ時におくるWebAuthnの勘所 - freee Developers Hub

サービス基盤チーム

業務内容：プロダクトをまたいだアーキテクチャの設計とそれを実現する基盤サービスの実装、全プロダクト共通の基盤ライブラリ・ツールの開発

プログラミング・ソフトウェア開発をドメイン領域とするチームなので、言語処理系・フレームワークなどの奥まで理解し活用する、変更しやすい設計、高速化・並列処理アルゴリズムなど、技術力の発揮が割とダイレクトにインパクトに繋がります。
freeeの共通基盤はまだ全然足りていないですが、それが故に一から大規模なサービスの基盤を自分で考えながら作っていけます。これは初期のスタートアップだと必要とされず、成熟した企業だと作り終えているので、今のfreeeの規模はちょうど面白いフェーズです。
ライブラリ開発とか経験無くてもメンバーで手厚くサポートできます。
技術が好きで、コードをガリガリ書くことでインパクト出したい人ぜひ応募してください。

freeeのサービス基盤を支える──挑戦の場を渡り歩いた先に行き着いた場所 | 採用ブログ | freee株式会社採用情報

課金基盤チーム

業務内容：課金基盤の開発、安定運用

まだ迷っている方いましたら是非課金基盤も検討してください！

課金基盤は「顧客とfreee社内ユーザー、双方にとっての課金UX向上を通じてfreeeの価値が顧客に届きやすくすると同時に、freeeのビジネスのアジリティ・収益性・生産性の向上に寄与する」ことをミッションに掲げています。課金基盤では、現在ジュニアからシニアまで幅広く募集しております。

自分が開発経験年数が少ないから、もしくは課金基盤ってシビアな感じだからやめておこうと思うあなた！心配することないです！技術力高いエンジニアから手厚いサポートを受けながら成長できる環境だと断言できます！課金基盤では一緒にfreeeを支えて行く家族をお待ちしております！何卒よろしくお願いします！！！

ERP基盤チーム

業務内容：統合型製品としてのfreeeならではの価値を直接自分たちの手で実現

↓にピンときた人はぜひ！

「アーキテクチャレイヤーでの『各製品・サービスとしての独立/安定性』」と「UXレイヤーでの『一元的な情報管理/メンテナンスUXの実現』」を両立する製品アーキテクチャの設計、その実現のための開発
freee製品全体のユーザビリティ向上、開発生産性UPのための基盤となる共通ビジネスコンポーネントの開発

その他にもスモールビジネスを元気にすることから世の中を変えていくfreeeのビジョン達成のため、中長期的な価値創出のための機能・基盤構想を検討しています！

データ基盤チーム

業務内容：社内データ分析基盤の構築

ビッグデータとかデータドリブンというキーワードに興味がある方をお待ちしております！

コアエンジン（外部サービス連携）チーム

業務内容：freee会計の外部サービス連携機能の新規開発、保守運用

何を目指すチームなの？？

「freeeだけ開けば全てのバックオフィス業務が完結する世界」を実現することを目指したいと考えています。 freeeを利用する事業者は様々な外部サービスを利用していて、それらのサービスとの連携機能がない場合、全てのサービスを画面上で開きながら入力作業を行う必要があり、非効率です。サービス間の情報の断絶から発生する非効率をコアエンジンが構築するシステムと機能を通して解決していきたいと考えています。

どうやって達成するの？

「freee内のプロダクトと外部サービスを繋げるハブ」となる基盤を構築し、freeeのプロダクトが簡単に外部連携機能を実装できることを目指します。

AIラボチーム

業務内容：機械学習を用いたサービス・機能を全社横断で研究開発

AIラボだよ！AI/MLブームが去る前に！今がチャンス！最近だとOCRとかたくさんやることあるよ！MLOps関連もやりたいこと山積みなんで「興味あるけどいきなりはちょっと・・・」という人もバックエンドの仕組み含めて経験値積めるよ！

データ処理パイプラインの Argo Workflows 移行を検討した話 - freee Developers Hub

会計チーム

業務内容：freee会計の開発

100万課金事業所に使われることを目指したサービス開発も、その過程でのパフォーマンスチューニングもフロントエンドのモダン化もアーキテクチャの置き換えもいろいろやりたい欲張りさんをお待ちしています

―関連記事

大きなプロダクトの育て方 - Speaker Deck

会計 freee バックエンドの今後 / freee backend api - Speaker Deck

うちの技術負債2021 freee編 - Speaker Deck

LEGO（Public API・アプリストア開発）チーム

業務内容：freee会計・freee人事労務のPublic API開発、freeeアプリストアの開発

できること、アピールポイント

開発によって届けられるマジ価値の総量が多い

自分たちがつくったAPI x APIを利用して開発されたアプリ x アプリを利用するユーザーの数だけ価値が届くので、freeeの開発の中でトップクラスにレバレッジが効きます

日本のtoB マーケットプレイスをリードしていくことが出来る

toBビジネスのアプリストアではおそらく国内で一番うまく行っていて参考にしていると言われることも多いです。アイディアを探すときはIntuitやHubspotなど海外サービスを参考にします。ライバルは世界です。

スキーマファーストなAPI開発ができる

freeeのPublic APIはOpen API Specification (OAS)に準拠したスキーマを公開しています。また、committeeというgemを利用してスキーマにあわせたrequest validationを行っています。最近Private APIでもOASを利用したスキーマ定義やっていこうという話が出ていますが、Privateよりも圧倒的な人数の開発者に使われるAPIの開発ができます。

外部開発者のためのメタな開発 (API)と直接ユーザーに価値を届ける開発 (アプリストア )どっちもやりたい欲張りな人ぜひ！

Stripeを使って自社マーケットプレイスに決済機能を実装しました - freee Developers Hub

穴馬を探せ！freee人事労務のAPIで有馬記念を予想する - freee Developers Hub

人事労務チーム

業務内容：freee人事労務の開発

全面的にTypeScript書いてけるぞ
品質専門のチームがあるぞ
- DDDの考えやアプリケーションアーキテクチャについて考える機会が多いぞ
最近では組織規模が大きくなってきた(Engだけで約30名)けど、Engがボトムアップで技術チャレンジできる仕組みを作ってるぞ
スクラム開発できるぞ
- たくさん有資格者がいるぞ
- 新卒1,2年目でもスクラムマスタにチャレンジしてるぞ
英語で開発にもチャレンジできるぞ
- グローバルエンジニアリングチームがあるぞ
難易度の高い業務ドメインをコードに落とし込めるぞ
- 定型的な法律の他に、ユーザー特有の曖昧な業務が多いので倒しがいがあるぞ

「人事労務freee」のEC2→EKS移行で、大変だったことと良かったこと - freee Developers Hub

金融チーム

業務内容：freeeカード Unlimitedの開発

成長環境として0→1や1→10はコアプロダクトと違う筋肉がつきますよ。「新しいチャネルのマジ価値」を届けるのがプロダクトグロースであり金融開発です！

スモールビジネスの持つ資金繰り課題解消

スモールビジネスの大きな悩みは「資金繰り」です。金融開発では、ここを直接的に解決するプロダクトを作っています。

金融プラットフォーム構想

「決済プラットフォーム」「金融仲介プラットフォーム」の2PF構想があります。独立した価値提供ではなく、クラウドERPの一部として価値提供します。

事業を学ぼう

事業部と密に関わって新規事業開発をしています。「将来起業したい」「スタートアップに挑戦したい」のような野望を持った人にもピッタリ。

freee流、クレジットカードのマイクロサービス設計構築術 - freee Developers Hub

プロジェクト管理チーム

業務内容：freeeプロジェクト管理の開発

英語で仕事したい・海外でのエンジニア採用第一歩に力かしてやるぜという方はプロジェクト管理のグローバル開発でTogetherしようぜ

モバイルチーム

業務内容：freeeが提供する全サービスのネイティブモバイルアプリの開発

最近入社したメンバーから“もっとはやくfreee入ればよかった“と言われたモバイルチームにもぜひ。入ったらその秘訣がわかるかも？

最近iOS/Android2チーム体制からドメイン毎チーム体制に移行しました。やる範囲もチーム規模も拡大する中、みんなが広い範囲を見ている状態だったので、各ドメインに集中してコミットできるように整理しました。人事労務も専任チームを作って本格的に開発進めていくぞ！

申告チーム

業務内容：freee申告の開発

申告も大大大大募集してます！よろしくお願いします。10 =>100フェーズを作っていきたいエンジニアにぴったり。難しいドメインをシンプルで拡張性高いコードに落とし込んでいく力がつくと思います。そしてこれからどんどん技術的な難易度もあがるしのでいろんな仕事がありますよ〜

Rubyの型チェッカーのSorbetを導入しました - freee Developers Hub

スモール会計/グロースチーム

業務内容：他チームと連携しながら、マネタイズやグロースに必要な機能を立案および開発

異動するならスモール会計/グロース船を是非！後悔させません

マイナポータルAPIを活用した設立オンライン申告
社会の進化を担いつつ会計DBパフォーマンスも考慮しないといけない電子帳簿保存法改正対応
ユーザービリティ的にもドメイン的にも難易度高い会計利用者のためのオンボーディング関連開発

最高のフィールド用意してお待ちしています！！！！

SEQチーム

業務内容：Software Engineer in Quality（自動テスト基盤の開発、運用構築）

自動テストを基本とした開発を当たり前にすることで、freeeを品質面でも他より抜きん出ているプロダクトにすることを目指しています。

これからやること

freee会計で、Pull Request毎にE2Eテストを実行させるという、先進的な基盤の開発を進めています。そして今後はモバイルアプリやAPIのテストの実行基盤やa11yテストの自動実行基盤の開発を予定しています。

特徴

社内で使うサービスなので、色々試したり、新しいサービスを作ったり、ライブラリのメジャーバージョンをがっと上げたりすることができます。例えばE2Eテスト基盤レポジトリで利用されているライブラリはほとんどが最新&自動でupgradeされています。また社内のエンジニアから積極的にフィードバックをもらいアクティブに改善しています。

Reason for developing and operating code-based automated E2E testing - Speaker Deck

SEQ（Software Engineer in Quality）チームの採用ページ

CREチーム

業務内容：お問い合わせ削減、ユーザー体験の向上

目指している世界

お問い合わせが発生しなくていい世界

バグがない
仕様がわかりやすい
要望すら事前に実装しちゃってる

それらはCREだけで実現できるものではなく、開発からBizも含めたクロスファンクションで連携して実現していきたい世界です。

お問い合わせコストの最適化

ユーザーさんもfreeeも、お問い合わせに「時間」「労力」「お金」等コストを払わなくていい状態

発生してもすぐに解決できる状態
お問い合わせの元を断てる状態

関係者がお互いに本業へフォーカスできている状態で、ここもクロスファンクションでやっていきたいところ。

やってきたこと

上記の状態を実現するために、これまで大きく２つの軸で動いてきました

エンジニア調査が必要なお問い合わせの調査、修正をおこない解決時間を短くする
ヘルプページの充実、チャットボットの改善などによってセルフ解決へ導く

やっていること

発生したハッピーのJIRA対応だけでなく、その手前にも踏み込んでいます

プロダクトの品質や体験を改善することで問い合わせの元を断つ（会計、人事労務）
JIRA起票する前のお問い合わせを、Salesforce上で引き取って解決しちゃう（Public API、公式アプリ）

これからの「もっと」

より手前で解決して行くことで、お問い合わせ対応のコストを減らして行く

サクセスチームのユーザー対応に同席して、その場で解決していくフロント対応
品質改善、運用改善、問い合わせ削減で、お問い合わせの元へもっとアプローチしていく
会計、人事労務、Public API、公式アプリ以外のプロダクトへ拡張していく

異動戦国のチャンス

クロスファンクションの中心で品質や運用の改善を企画したり、巻き込み巻き込まれるカオスを楽しみたい人これまでのCREチームは、比較的部分最適に寄った感じでそれぞれの領域で個別の運用を試して来ました。今後は、共通化できるところを統一して、横に展開できる新しい体制や指標作りを進めていきます。

まだカオスな今の状態だからこそ、今後の成長を楽しんでいけるんじゃないかと思います。セルフサクセスチームとさらに連携して、プロダクト改善からお問い合わせ削減をしていく構想もあるので、Bizとの連携に興味があるエンジニアは、この機会にCREというキャリアもぜひ考えてみてください。

―関連記事

freeeのCREチームとは - freee Developers Hub

freee CREのこれから〜お問い合わせの横断対応イメージ - freee Developers Hub

プロダクトデザインチーム

業務内容：開発プロジェクトにおけるユーザー課題発見とソリューションの検討、UIデザイン、デザインシステムの開発・普及

デザイナーってことは絵を描けたり、なんか魔法みたいな感じでオシャレなものを作れたりするんでしょ？みたいに思ってしまう人もいるかと思うんですが、freeeのプロダクトデザインにおいては、必ずしもそういう感じではないです。

freeeのプロダクトデザインで真に必要になるスキルはたぶん情報設計（Information Architecture: IA）です。ユーザーの属性やら行動やら業務の内容やらいろんなものを整理して、どういう情報がどう関係しているのかを明らかにして、最終的にユーザーにどんなUIを見せればいいのかを明らかにする作業が必要です。

プロダクトデザインの現場では、その材料を集めるためにインタビューや観察というかたちでリサーチをしたり、作ったものが有効であるかを確かめるためにユーザーテストをしたりします。そして、デザインシステムの力を借りながらUIのかたちにしていきます。……という流れでデザインをしているので、実はすごくロジカルな作業です。

上記に加えて、デザインシステムな人たちは、文字の大きさや色の使い方などが多種多様だと一貫性が崩壊していくので、なぜその値を使うのかを言語化して、ルール作りをしていかなければなりません。

これをやるにはUIから概念モデルや設計思想を考察する、リバースエンジニアリングするようなスキルが必要となります。これも古今東西のアプリケーションを触ってきた・作ってきた経験があると大きなアドバンテージになるので、エンジニアが優位に立てるところだったりします。

エンジニアとデザイナーは単に役割が違うだけで、それぞれにデザインの知識やエンジニアリングの知識を活かしていくことができるものだと感じています。WebアプリケーションのUIをデザインするときにWebアプリケーションの作り方を知っているとやりやすいし、コーディングするときにデザインの考え方を知っていることで「良い」コードになることは多くあると思います。

ということで、スキルの幅を広げるという意味では、デザイナーを経験してみるというのは価値があることなんじゃないかと思っています。

5年半勤めたエンジニアチームを辞めて、UXチームにジョインしました - freee Developers Hub

freee Design Magazine｜freee公式編集部

PSIRTチーム

業務内容：アプリケーション脆弱性対策運用、プロダクト共通基盤のセキュリティ対策、プロダクト開発プロセスにおけるセキュリティ統制強化

常時稼働している本物のRed Teamを持つ

これからPSIRTを、次の3段階を経て成長させていきたいと考えています。これらは非連続的な変化というよりは、オーバーラップしながら徐々に次のフェーズに移っていく感じになるとは思うのだけど、それでも向き合うテーマが大きく異なるので、これを意識しておくと自分たちの未来をちゃんと見据えることができるようになるんじゃないか。

フェーズ1: 既知の攻撃に対処するまず、現状はここが主戦場。誰かが見つけて公表してくれたサイバー攻撃や脆弱性に、リアクティブに対応している段階。

たとえばWAFは、既存の攻撃をパターン化したリストにマッチしたアクセスを弾いてくれている。サービスの依存ライブラリや、コンテナイメージに存在する脆弱性も基本的には既知のものが通知される。PSIRTはこれらの攻撃・脆弱性をトリアージして、危険なものであれば止め、もしくは開発チームにアップデートを依頼するという仕事をしている。

ここは最終的に「機械に任せる」か「開発プロセスに溶け込ませる」ことでほとんどの仕事を消すことができるはずだ。そうすればフェーズ2に進める。

フェーズ2: 未知の攻撃に対処する次はまだ公開されていない攻撃や脆弱性を自分たちで発見して、攻撃者に利用される前に対処する段階。すでに導入済みの静的解析ツールは、このフェーズの仕事をやりやすくしてくれている。リリース前の脆弱性診断もこれにあたる。つまり、われわれはこのフェーズに一部到達している。

このフェーズでは、さらにプロアクティブなセキュリティに取り組みたい。たとえばbug bounty program。国内のSaaS企業でも、bug bounty programをしっかり運用しているところはいくつもある。追いつきたい。

それから自分たちでセンサーを作るような、研究開発もやりたい。freeeのプロダクト規模にマッチする動的解析製品は、実はほとんどない。複数セッションにまたがるような巧妙な攻撃をちゃんと見つけられるセンサーも、世界中探したけど存在しなかった。なければ自分たちで作るしかない。

ざっくりこのフェーズのPSIRTは立派な「Blue Team」と言って良いと思う。守りに関してはやれることをすべてやっている状態。これで満足しても、十分に「PSIRT」と名乗れますね。

フェーズ3: 未知の攻撃を作り出すだが自分は、もう一歩先に進みたい。それが「常時稼働している本物のRed Team」。

Red Teamとは、製品・サービスに対する「身内の攻撃者」のこと。自社プロダクトを攻撃することで、外部の攻撃者に先回りして穴を塞ぐのをミッションとしている。サイバーセキュリティの世界では、攻撃サイドは圧倒的に有利と言われている。守る側はどうしてもリアクティブになってしまうから。これに先んじるには、自分たちで攻撃するしかない。本来の使い方とは違う意味で「攻撃は最大の防御」。

Red Teamは自社プロダクトそのものだけでなく、社内外のさまざまな情報を駆使して、潜在的で複合的な脆弱性を見つけ出す。使えるものはなんでも使うために、Red Teamは社内のさまざまなことがらに精通している必要がある。ゆえに「本物の」Red Teamは社内組織であるべきだ。そしてそのRed Teamは、常に攻撃者の視点をもって自社プロダクトの穴を探し続けなければならない。freeeの規模であれば、パートタイムではなく「常時稼働している」専任のRed Teamを持つべき。

これが「常時稼働している本物のRed Team」。国内企業でこれを持ってるところはほとんどないと思う。セキュリティ屋として、ここまでたどりつければ本望でしょう。

freee Product Securityのこれまでとこれから - freee Developers Hub

おしまい

いかがでしたでしょうか？異動戦国期間中はこのようなチーム紹介に加え、気になるチームのJM（freeeにおけるマネージャー）との1on1などを通して希望の異動先を決めていきます。現在は応募期間が終了し、実際に異動が決まったところです。

さて、来期どのように組織が進化するのか、いまからとても楽しみです！！

jobs.freee.co.jp