ID:66935さん

# 概要 freee株式会社の会計ソフトサービスであるfreee会計には「支払依頼」という機能がある。 これは主に請求書を自社の従業員が取引先から受け取り、それら請求書の支払業務依頼をワークフローとして申請経路を通して経理担当者に申請する機能である。 請求書のOCR読み取りや過去の支払依頼データを元に金額や取引先データを自動補完する仕組みが元々あったが、支払依頼における明細情報の補完（品目、部門などのタグ情報）が充実していなかったため、「支払テンプレート」という明細情報をあらかじめテンプレートとして登録しておき、それらを使用して補完することができる機能を開発した。 # チーム編成 エンジニア4名（全員サーバーサイドからフロントエンドまで担当） # チーム内の自分の役割 このプロジェクトのエンジニアオーナーを担当し、PMとデザイナーと自分の3人で要件定義を詰めつつ、システム要件に合うように仕様を落としたり、変更したりした。その後、DesignDoc（システム設計書）を自分1人で書き、それらをチームメンバーに参照してもらいながら実装を進めた。 自分はコーディングも担当し、チームメンバー内では最も多くPRを作成・レビューし、リリースした。 # 工夫した点 サーバーサイドに関して、freee会計は巨大なモノリスなRailsアプリケーションになっており、Rails wayを外れて独自のアーキテクチャに全体移行しようとしている。（Ref: https://speakerdeck.com/mihyaeru21/freee-backend-api ） 具体的には、これまでMVCアーキテクチャのcontroller上で書かれるロジックがバラバラになっていたのをきちんとinput form層、service層、presenter(serializer)層で分け、service層のI/OのインターフェースをProtocol Buffersで定義し明示するようにした。serviceロジックはCQRSパターンを使って実装し、責務を明確化した。 チームメンバーにはこの新しいアーキテクチャで開発したことがないシニアエンジニア1人と、2022年新卒1人がいたため、すでにこのアーキテクチャでの開発経験があった自分がPoC PRを作成して開発序盤は参考にしてもらいながら開発を進めてもらったことで開発速度は初期から早くすることができた。新卒メンバーは技術レベルがまだ未熟だったこともあり、ペアプロを頻繁に行い、詰まったらすぐにヘルプに入るようにした。 フロントエンドに関してはRailsでHTMLをレンダリングし、その後はReact componentをマウントするという構成を取っている。（railsの1routeに対してreactの1routeを作成するMPA構成）明細情報を入力するformを作成したため、state管理にはuseReducerを使用し、カスタムhooksでロジックをカプセル化した。 freee会計のフロントエンドは主にJavaScriptとflowtype、Reactで構成されているが、全社的に使用しているデザインシステムはTypeScript、Reactで作られている。そのデザインシステムにあったcomboboxを利用したが、不備があったためPRを出して修正して使うようにしていた。

# 概要 開発を担当しているfreee会計というプロダクトはバックエンドフレームワークにRuby on Railsを使用しており、Ruby on Railsのversionを5.2から6.0にメジャーアップデートした。 freee会計はRubyファイルが10000ファイル以上という巨大なモノリスアプリケーションであり、古い書き方が多かったり、古くから存在しているpatchがあったため、Railsアップデートにあらゆる壁があった。（ref: https://speakerdeck.com/mihyaeru21/freee-backend-api?slide=8 ） 以下は一緒にプロジェクトを進めたメンバーがテックブログ https://developers.freee.co.jp/entry/update-freee-accounting-to-rails6 # チーム編成 エンジニア2名 # チーム内の自分の役割 - DesignDocの作成とRailsアップデートによる影響範囲調査 - アップデートが必要なgemのアップデート - 必要なRailsのロジック移行 - breaking changeによるfailするRspecの修正 - QA対応 # 開発内容詳細 ## DBのReader利用の仕組みを自社ライブラリからRails 6.0から標準で搭載された機能に置き換え DatabaseはMySQLを利用していて、負荷分散のためにwriter / readerを用意していたが、Railsアプリケーションからreaderに対してクエリを実行する仕組みは内製ライブラリで動いていた。 Rails version 6.0から標準でreaderを活用できる仕組みができたため、Rails updateと一緒に内製ライブラリを置き換える対応を行った。 コードの改修対象ファイルが多かったため、事前に内製ライブラリのロジックをラップしたメソッドを作って置き換えておき、その後そのラッパーメソッドの中身をrails 6.0標準のロジックに置き換えることでコンフリクトが発生しないようにした。 ## deprecationになっているgemを洗い出し、バージョンアップ まずざっとRailsのChangelogやRails 6.0のリリースノートに目を通し、明らかに修正が必要なものはリストアップと修正をした。残りはバージョンアップしたPull Requestを用意してCIを実行し、failした箇所を重点的に調査しながら潰していった。 依存している社内・社外gemも調査し、アップデートが必要なものは事前にアップデートした。 feature branch運用というmain branchに変更をmergeするのではなく、feature/rails6.0 のようなブランチを用意してそこに主に変更を加えていったが、feature -> mainへの差分が大きくなりすぎないようにmain branchに入れられる改修は積極的に入れていった。 また古くから残っているが誰も存在が知らないようなpatchファイルがいくつか残っていて、それによってテストが失敗していたためpatchを外せるかどうかを調査し、外せるものは外していった。 # 工夫した点 Railsのアップデート以外にも、freee会計で採用しているMySQL（Aurora）のReader / Writer構成で、Readerにクエリを向ける機構を独自Gemで行っていたため、Rails 6.0から使える同様の機構に乗り換えることも行った。これらは別チームのDBREエンジニアにも協力してもらいながら進めた。

# 概要 freee会計というプロダクトには総勘定元帳という仕訳データを勘定科目ごとに表示することのできるレポート類の機能がある。これらは元々API化されておらず、Railsのweb controller上にすべてのロジックが書かれ、ERB上で表のUIを表示していた。 freee会計としてはERBは1つのDOMをレンダリングするだけにし、それ以外はすべてReactでUIを構築していく方法に統一していきたい（サーバーサイドの関心をフロントエンドから切り離したい）ため総勘定元帳のReact化とAPI化を行った。 仕様はほぼ変わらず、UIの刷新とシステム側の刷新という技術的負債解消系のプロジェクト。 # チーム編成 エンジニア3名 # チーム内の自分の役割 1人プロジェクトのような形でUIの作成をデザイナーにお願いし、部分的に調整しながら行った。その後それを元にDesignDocを作成し、必要なAPIのProtocol Buffersのprotoファイルやserviceロジックの整理を行った。（上述した新アーキテクチャで実装） コーディングはサーバーサイドのAPI作成からフロントエンドのReact化まで自分1人ですべて行い、レビューだけ他のチームメンバーにお願いした。 1機能をリニューアルする際に、データのエクスポート機能が「新エクスポート、旧エクスポート、旧旧エクスポート」というようにバージョンが混在して残っていたため、新エクスポート以外はすべてユーザーに事前告知した上で廃止した。 # 工夫した点 新アーキテクチャでの実装が初めてだったこともあり、キャッチアップとしてPoC PRを作成して全体像を把握しつつ、すでに新アーキテクチャの知見を持っているチームメンバーにFBをもらってから本格実装に入った。

# 概要 freee会計というプロダクトは2012年から開発が行われているプロダクトのため、当時はメインで使われていたCoffeeScriptのコードが400ファイルほど残っていた。 それらは新機能開発で使われるような画面ではなく、ほぼ手が入らないような箇所で残っていたために、置換する機会もあまり持てないまま時間が経っていたため、一括置換とQAを行ってリリースするプロジェクトをチームメンバーの2人で進めた。 以下は一緒にプロジェクトを進めたメンバーが書いたテックブログ https://developers.freee.co.jp/entry/goodbye-coffeescript # チーム編成 エンジニア2名 # チーム内の自分の役割 - CoffeeScriptの自動置換スクリプト作成 - QA対応 - 注意点を記載した記事作成 # 工夫した点 CoffeeScriptの自動置換（decaffinate）によって可読性の悪いコードが生成されてしまったが、人的リソースの問題ですべてを書き換えることはできなかったため、注意点や次にその可読性の悪いファイルを触った際に参考にできるよう社内ナレッジツールを用いて注意点やリファクタリングの詳細な方法について記事を書いて共有した。またその記事のリンクを自動置換したすべてのファイルにコメントで追加するなどして、安心してコード修正できるように配慮した。

# 概要 freee会計には貸借対照表と損益計算書を閲覧する機能があるが、翌年度表示に対応していなかったため、当年度だけでなく、翌年度のPL/BSも閲覧できるように改修した。 # チーム編成 エンジニア4名（自分のみフロントエンドとサーバーサイド両方行い、他のメンバーは全員サーバーサイド開発のみ） # チーム内の自分の役割 別プロジェクトを同時期に行っていたため、要件定義やDesignDocが大方完成した実装開始直前からこのプロジェクトに参画した。 要件的にフロントエンドはほとんど改修がなく、主にサーバーサイドの改修とデータ移行がメインのプロジェクトだったため、チーム内で1番フロントエンドに関心のある自分がフロントエンドのコーディングを行った。 会計ソフトは大量の仕訳データが日々作成されており、PL/BSはそれらの仕訳データをすべて集計するため同期的に集計するとかなり高負荷になる。そのためバッチ処理等で集計データをあらかじめ作成しているが、翌年度分の集計データが存在しないため、全事業所データの翌年度分の集計データを作る必要があった。それをRailsのTaskを利用してデータ移行した。 データベースへの負荷を考慮してアクティブユーザーが少なくなる夜の時間帯を活用してデータ移行した。Datadogを活用してAPMを行ったり、監視を注意深くしつつ行った。 # 工夫した点 大規模なデータ移行が特徴のプロジェクトだったため、あらかじめデータ移行に伴う負荷やサーバーのメモリ使用量を計算した。 integration環境を本番環境同等のマシンリソースにして、本番同様のデータを用意し、複数事業所データでいくつかのデータ移行のサンプルを取った。その結果データ移行を、持っているデータ量が小規模事業所から大規模事業所にかけて行うことでなるべく影響範囲の小さい状態からデータを移行することができ、リスクを抑えた。