この記事は、freee Developers Advent Calendar 2025の 23日目の記事です。
こんにちは！最近ようやくわからないことがわかってきた25卒のtakaです。普段はfreee会計のチームでエンジニアをしています。
今回は、AIで生産性を向上した・課題解決したといったキラキラした話ではないです。新卒1年目の私が「freee会計」という複雑なドメインと、10年以上の歴史が詰まったコードとどう向き合っているのかについてお話します。
3行サマリ
- 新卒研修ではAI活用で乗り切ったが、freee会計では一筋縄ではいかなかった
- 複雑なドメインではコードが読めても全体像が理解できない
- 図解することで理解の精度が格段に上がり、「わかったつもり」によるミスを減らすことができた
AIフル活用の新卒研修
最近はAI活用による生産性の向上が叫ばれています。今年の新卒研修でも「配属後に AI ネイティブ世代として新しい風を吹かせる」という目標があり、AIをフル活用して開発してほしいと言われていました。
新卒研修では、社内のGeminiやFigmaなどのITツールを管理するアプリケーションを0から開発するということをやっていました。私はエンジニアとして経験があまりなかったため、実装できるかな？と思っていましたが、AIのおかげでなんとか乗り切ることができ、配属後もやっていけそうかもと思っていました。
そして、研修後の配属先については freee 会計の開発を希望しました。会計や簿記の知識などはほぼ0でしたが、せっかくfreeeに入社したので会社の代表的なプロダクトかつ大規模アプリケーションの開発を経験したいと思ったからです。
配属後の現実
配属されたチームは、会計の中でも貸借対照表や損益計算書などの会計帳簿のドメインを扱うチームでした。そこで、バックエンドのリファクタリングプロジェクトに関わりました。既存の実装を整理し、将来的な機能追加を見越して保守性や拡張性を向上させることが目的でした。
プロジェクト当初は、保守性や拡張性を高めるための設計を考えるのはとても面白そう！と意気揚々としていたのですが、現実は違いました。
今振り返ると、私が配属された時点である程度リファクタリングの設計が決まっていたというのもありますが、リファクタリングプロジェクトと言いつつも実際に時間をかけて取り組んでいたのはほとんどドメインと既存実装の理解でした。
freee会計には様々な機能があるので先輩エンジニアもすべての仕様を把握しているわけではありません。また、仕様書が揃っているわけでもありません。先輩エンジニアからは次のように言われていました。
Design Doc やチケットには詳細な仕様までは記載できていないので、実装する際は既存実装のコードも読んで仕様を把握し、それを再現するようにしてください
エンジニアならコードが真実であるというのは当たり前と思われるかもしれません。私もPMやQAと異なりエンジニアとしての価値の1つにコードが読めることがあると思っています。しかし、配属直後の私にとってはとても難しかったのです。たとえ、一般的な会計や簿記のことを理解したとしても、freee会計特有の仕様があり、例えば会計帳簿では裏側に複雑な集計ロジックがあったりします。よってコードが読めても何をやっているのか、なぜそうなっているのかが全く読み取れないのです。
わかったつもりの危うさ
当初は、AIの力を借りつつ、なんとなくコードを翻訳するように実装を進めていました。しかし、これで大丈夫そうだ！と思って出したPRがレビューやQAで実装漏れやロジックが違うといった指摘をたくさん受けました。
例えば、会計には決算整理仕訳というものがあります。決算時の帳簿上の数字と実際の数字を合わせるために事業年度末に行う仕訳のことです。freee会計には大きく分けて個人向けプランと法人向けプランがあるのですが、それぞれで決算整理仕訳の挙動が異なっています。既存実装を把握する際に、法人と個人の違いを把握できず、QAで実装漏れとして引っかかってしまうことがありました。原因は、コードの表面だけをなぞってなんとなく理解した状態で、決算整理仕訳の処理がどうなっているのか仕組みを追いきれていなかったからです。
AIがあるといっても、freee会計という巨大なアプリケーションの前ではAIが歴史的経緯などを含めたすべてのコンテキストを読み取ることは難しいです。私はここで、実装力以上に理解することの重要性を痛感しました。
理解の定義を決める
配属当初、先輩エンジニアから「理解することを諦めないでください」とよく言われていました。にもかかわらず、理解したとはどういう状態なのかを自分の中で明確な基準を持てていませんでした。よって、新米エンジニアの私では、会計の複雑な処理を実現しているコードを読んでも、どうしてもコードに目が行ってしまい、中々構造的に理解できるようにはなっていませんでした。
そこで、チームの先輩エンジニアの方々がどうしているのか注目したところ、わからないときはホワイトボードやGoogle 図形描画など様々なツールを用いて図解し、メンバー間で議論したりしていました。それまで私は、経験豊富な先輩エンジニアの方々はコードを見ただけで複雑なロジックもすべて頭の中で理解できているのだと思い込んでいたので驚きました。圧倒的な知識を持つ先輩方でさえも、図を描くことで思考を整理し、認識をすり合わせているという事実は、私にとって大きな発見でした。
これは余談ですが、先輩エンジニアの方々はさらにその先輩から図を描けと言われていたそうで、社内には図を書く文化がありました。 Slackで「いいから図を描け」と投稿すると、カスタムレスポンスが返ってきて、図を書くことの重要性を説いた社内ドキュメントが送られてくるぐらい、社内には図を書く文化が根付いています。
ドキュメント書いて中に図表がひとつもなかったら、それはおかしいと思わなければならない。
これまで図が大事っていうのはわかっていましたが、中々実践はできていませんでした。そこで、自分の中で理解した = 図解できる状態 という基準を設けることにし、ちょっとでもわからないことがあればすべて図に書き起こすようにしました。簿記のことや既存実装のロジックに関して、システム構成図からクラス図、データフローを表す図などたくさん書くようにしました。
図解による変化
構造的に理解できるようになった
図解の一番いいところだと思っています。コードを追っていくだけではなく、図解することでロジックを可視化し構造的な理解ができるようになります。コードは上から下へ流れる1次元的な情報です。対して、会計帳簿の裏側にある集計ロジックは複数の条件が絡み合ったり時系列が入り乱れる多次元的な構造をしています。これまでコードしか読んでなかったときは、1次元の情報だけで多次元の構造を理解しようとして、認知負荷が限界に達して脳内メモリが焼ききれてしまっていました。図解することで全体像を俯瞰し、仕組みを簡単に理解できるようになった結果、手戻りなども減っていきました。
メンバー間の共通言語にできる
図解することでチームメンバーとの認識合わせも簡単になりました。例えば、ある機能の既存実装をリファクタしたPRをレビューしてもらうときに、レビュワーが必ずしもその実装に詳しいわけではありません。文章や会話で説明することもできますが、複雑なロジックの場合は中々伝わりづらいことが多いです。そんなときに図があると、一目で何をやっているのかを理解してもらいやすくなるし、その図を元に議論できたりします。また、実装完了後にアプリケーションエンジニアとQAエンジニアで仕様を確認し、テスト内容を「すり合わせる会」があるのですが、そこでも複雑な仕様を図解しておくことで、認識の齟齬がなくQAのテストケース作成がスムーズにいくようにもなりました。
加えて、新卒の私にとってはわからないことがどうわからないのかうまく言語化できないときが多々あります。言語化力を鍛えろっていう話に尽きるのですが、自分の現状の理解を図に書いておくと、ここの部分間違っているよといったフィードバックをもらいやすくなり、さらなる理解につながることが多くなっていきました。
おわりに
今回のリファクタリングプロジェクトを通して、図解の威力と重要性を実感しました。AIによってコーディングのハードルは下がっていますが、freee会計という複雑で巨大なアプリケーションを開発する上ではすべてAI任せというわけにはまだまだいかないですし、最終的な品質を担保する責任があるのは人間であるエンジニアだと思います。まだまだスキルも経験も足りていないですが、理解することを怠らずこれからどんどん成長していこうと思います。
明日は、minさんから、AWSのリソースについての記事が公開されます。お楽しみに！
