フリーナンスの現在地とこれから

9/1にフリー株式会社にジョインした
フリーナンス
統合flowを実現するための課題や
現在地を紹介します

Transcript

2. 29 9/1にフリー株式会社にジョインした フリーナンス 統合flowを実現するための課題や 現在地を紹介します フリーナンスの 現在地とこれから
3. フリーナンスの 現在地とこれから the よしだ 2025年11⽉30⽇
4. the よしだ
 永遠のPHPer。
 最近は少しGopher。
 好きなお酒は
 メガジョッキハイボール。
 フリーナンス開発 Eng
5. 今日のお話 • フリーナンスの紹介 ◦ フリーナンスとは ◦ フリーナンスの MVV ◦ フリーナンスでできること • フリーナンスの現在地 ◦ ジョインに伴う移行 ◦ インフラ ◦ 開発体制 • フリーナンスのこれから ◦ 統合flow へ向けて ◦ 開発体制
6. 　 フリーナンスの紹介
7. フリーナンスとは 2025/09/01 フリーにジョイン！
8. フリーナンスのMVV
9. フリーナンスでできること
10. フリーナンスでできること
11. フリーナンスでできること
12. フリーナンスでできること
13. フリーナンスの実績
14. 　 フリーナンスの現在地
15. ジョインに伴う移行 ツールの移行 • Cursor → Roo Code ◦ LLM基盤を Proxy としてAIを利用 ◦ Cursor から Roo Codeへ移行 ◦ 月末のリミット問題はなくなった • Devin(freenance) → Devin(freee) ◦ フリーで利用しているDevinへ移行 ▪ Githubのorganization統合前 ▪ Devinのfreenance用organizationを用意 ▪ slackからも利用可能(特定のchannelのみ) ◦ エンジニアも利用するが、事業部が仕様調査やSQL作成に利用
16. ジョインに伴う移行 IPアドレス変更 • システムのIP制限 ◦ 管理コンソール ◦ 検証環境 • ツールのIP制限 ◦ 連携サービスの検証環境 ◦ 事業部で利用するツールのログイン 一時的にVPNを契約し 「旧IP → 一時的なIP → フリーIP」と移行
17. ジョインに伴う移行 ドメイン変更 • Google Workspace ◦ Google Cloud の IAMにも影響 ◦ フリーの Google Workspace でグループアドレスを作成 • ツールのログインアカウント ◦ フリーのアドレスへ変更 ◦ アドレス変更できないものは新規作成
18. インフラ 現在は Google Cloud を利用 サービスA Cloud Run Cloud SQL Cloud Run Cloud SQL サービスB Cloud Run Cloud SQL
19. インフラ • AWS 移行 ◦ フリー標準は AWS ◦ AWS環境での運用はメリットが大きい ◦ 移行には時間が必要 • Google Cloud からの段階的な移行 ◦ フリー自体、Big Query 等で Google Cloud を使っている ◦ Organization だけは早期に移行 ◦ フリー基準のセキュリティ強化は必須
20. 開発体制 • スクラムへの移行 ◦ マジ価値デリバリーには学習サイクルを回す必要あり ◦ 他チームのスクラムイベントを大いに模範 • AI活用 ◦ 調査での活用はできている ◦ 実装での活用は差が大きい ◦ やってみたを共有しやすい仕組みへ
21. 開発体制 • レビュープロセス改善 ◦ レビューに全員を巻き込むことで学習を促す ◦ AIによるアウトプットが増えることで レビュワーがボトルネックになる ◦ CodeRabbit は指摘の精度が高く、 CodeRabbitの承認後にレビュワーに依頼
22. 　 フリーナンスのこれから
23. 統合flow へ向けて 仕事の分断をなくし、シームレスな体験を生み出す • Work flow ◦ あらゆる申請・承認を、迷わずスムーズに • Communication flow ◦ 必要な情報が、必要な人に、きちんと届く • Data flow ◦ 一度の入力で、すべてのデータが正しくつながる
24. freee 請求書連携は既に可能 • freee 請求書連携では、請求書のアップロードは不要 統合flow へ向けて
25. よりシームレスな体験へ • 即日払い申込時の提出書類 削減 ◦ 提出書類が多いほど、信憑性は高まる ◦ 提出書類が多いほど、煩わしい ◦ 提出書類の種類によっては freee 連携で取得可能なものも 統合flow へ向けて
26. 開発体制 やりたいことが多く、チームを拡大して対応 • チーム構成 ◦ 複数システムを4~5名のエンジニアで担当している ◦ エンジニアを増やしつつ、担当領域を分ける必要がある ▪ サービスによって注力する対象が異なる ▪ 担当ドメインに注力することでもっと早く価値を提供したい • システム改善 ◦ 速く価値を届けるために、変更容易性やテストカバレッジを高める ◦ 定期的な改善タスクを積み重ね、少しずつ良い未来へ
27. フリーナンスのMVV