ID:65905さん

## プロジェクトの概要・背景 ### サービスのコンセプト データ連携機能の背景を説明するため、サービスコンセプトを述べる。 開発中の人事労務のサービス(以下、本サービスとする)のコンセプトとして、人事労務にかかわるシステムを全てリプレイスするのではなく、既存のシステムの基幹データベースのメンテナンスを行うことがなく導入できる、というものがある。 大きい企業になればなるほど基幹部分のリプレイスは難しく、リプレイスのコストを確保できずに人事労務サービスを導入できない、という問題がある。本サービスはそのような問題を抱えている企業をターゲットとしている。 ### データ連携機能とは 上に述べた通り、基幹データベースのリプレイスが行われない以上、本サービスと基幹データベースのデータの同期が必要となる。 そのため本サービスで行った人事労務関連の手続きで更新された従業員情報を基幹データベースに同期する作業や、人事労務手続きに必要な情報を基幹データベースから本サービスに同期する作業が必要となる。 データ連携機能とは、本サービスと基幹データベースの間のデータのやり取りを行う機能を指す。 ### 課題 データ連携の際、本サービスと顧客のデータベースの仕様は当然異なるので、連携するうえでデータ変換を行う必要がある。簡単な例でいうと、本サービスでは従業員の姓と名は別のカラムに保存されているが、顧客のデータベースでは一つのカラムに保存されているため、本サービスから顧客のデータベースに連携するために文字列を結合する必要がある。 このようなデータ変換は顧客のデータベースの仕様ごとに異なるので、愚直に実現しようと思うと顧客ごとのコーディングが必要になる。実際、このプロジェクトの始動前は顧客ごとに個別のコーディングを行っていた。 サービスの拡大に伴い、データ連携機能を希望する顧客が増えてきたため、個別のコーディングでは開発メンバーのリソースが足りず、改善を迫られていた。 ### 実現方針 データ連携の手順を「データ取得」「データ変換」「データ検証」「データ出力」の4つのフェーズに分ける。 #### データの取得 データ取得元のデータベースからデータを取得する。以下のような操作がある。 - 顧客データベースからファイルを取得する - 本サービスのデータベースから従業員情報を取得する。 #### データの変換 取得されたデータに対して、変換を行う。以下のような操作がある。 - 文字列を結合する - 文字列を置換する - 文字列を分割する #### データの検証 変換されたデータに対して、データが出力先の要件を満たしているか判定し、満たしていないものは出力から省く。以下のような操作がある。 - バイト数を検証し、指定のバイト数を超えているかどうかを検証する。 - 単純な比較演算を行う。 #### データの出力 検証されたデータを出力する。以下のような操作がある。 - ファイルとして出力する。 - 本サービスのデータベースを更新する それぞれのフェーズで企業共通で利用できるロジックを実装しておく。企業ごとにどのロジックを利用するかをymlやjsonで記述された設定ファイルで記述する。設定ファイルのアップロードによって企業ごとのロジックを登録するので、企業ごとのソースコードを記述する必要がない。 ## 達成されること ### 開発メンバー工数の徹底的な削減 #### カスタマーサクセスチームによるデータ連携設定構築 基本的にデータ連携の開発は以下のように進む。 1. データ連携のカスタマーサクセスチームが顧客とのヒアリングで設計書を作成する。 - 設計書は本サービスのデータベースのカラムと顧客データベースの対応表のようなもので、マッピングシートとも呼ばれる。 2. 1. で作成された設計書をもとに、開発チームが設定ファイルの構築を行う。 3. テストケースの洗い出しを行い、検証を行う。 1と2の間のコミュニケーションコストが大きいため、設計書の作成者と設定ファイルの構築者が同一になればそのコストを削減できる。ソースコードの記述は必要なく、設定ファイルの構築方法さえわかればよいので開発チーム以外のメンバーがデータ連携開発を行うハードルが下がっているため、十分実現可能である。 #### 生成AIとの協働 Claude 3.7 SonnetとClineを利用して、連携設定の記述を生成AIによって記述させることが可能になった。設計書(マッピングシート)のフォーマットを整えてインプットとして与え、適切に前提知識を与えればそこまで複雑ではない連携設定の構築ならばほぼ修正の必要がない設定ファイルを出力することがわかっている。まだ生成AIを利用した設定ファイルの記述は検証中であるため、より複雑な設定でも高精度の出力ができることが期待できる。 ## 展望 このプロジェクトは現在も進行中のため、この先の展望を述べる。 ### テストコードの自動生成 コードの記述は不要になったが、構築したデータ連携設定の検証については基盤が整っていない。こちらはまだ検討段階ではあるが、以下のようなロードマップを構想している。 1. 生成AIを利用し、設計書(マッピングシート)を入力としてテストパターンや期待する入出力のパターンの列挙を行えるようにする。 2. テストパターンを入力としてデータ連携の出力を検証することのできるテストフレームワークの開発 3. 設定の変更が行われるごとにテストを実行する継続的インテグレーションの実現

## 概要と背景 弊社の最高技術責任者の思想で「インフラエンジニアでなくとも、自分が携わるアプリケーションのインフラ構成やリソースについて理解しておくべきであり、自分の書いたプログラムがリソースにどのような影響を与えているかを理解しておくべき」というものがある。その思想に従って、最高技術責任者によるインフラの勉強会が定期的に開催されている。それだけではなく、アプロケーション開発メンバーの一部は週次でインフラのリソースのモニタリングを行い、アプリケーションの問題を洗い出す取り組みを行っている。 社内ではAWSを全面的に利用しているため、主にCloudWatchを利用している。 ## 主な活動 以下に述べる活動を通して、普段利用しているAWSリソースに対する理解を深め、サービスの改善を行った。またAWSに関するリソースに関する学習や学習内容の還元を行った。 ### 週次のモニタリング(バグ・パフォーマンスの計測) 主にCloudWatchを利用してリソースの状況を把握している。モニタリング内容は主に以下のとおりである。 - PumaやSidekiqが動いているECSのCPU使用率やメモリ使用率、オートスケーリングの状況 - リクエスト数やエラー数、レスポンス時間 - 特に長いリクエストの特定 - バグの原因調査 これらのモニタリング結果をもとに、特にメモリを消費しているプログラムの特定やバグの原因を特定し、対応方針を決めて修正する。 ### 週次のモニタリング(コスト) Amazon CTOであるVernerによる[frugal architect](https://www.thefrugalarchitect.com/)の思想にのっとり、アプリケーションエンジニア一人一人がインフラリソースにどれほどのコストがかかっているかを把握するためのモニタリングを行っている。モニタリングは主に[AWS Cost Explorer](https://aws.amazon.com/jp/aws-cost-management/aws-cost-explorer/)で行っている。 この活動によって、どのようなコードがコストを浪費する要因となるか気づくきっかけとなり、普段のコーディングの意識改善につながっている。 ### AWSの最新技術動向のキャッチアップ 2024年に開催された[AWS re:Invent](https://reinvent.awsevents.com/)に会社の代表として参加し、AWSの最新のトレンドの把握やAWSの学習を行った。 主にマルチテナントアーキテクチャの大量のリクエストをどのように効率的に捌くかといったところに関心があったため、ECSやRDSにかかわるセッションを主に受講した。 ### 教育活動 日々のモニタリングやAWS re:Inventで得た知見をメンバーに還元するため、チームメンバーに対する還元活動を行っている。特にAWS re:Inventのワークショップセッションを模した教材を作成し、自チームのメンバーに還元した。 教材の内容は以下のとおりである。 - ECS+Fargateを利用したサービスのデプロイ - CloudWatchにおける基本的な監視(アラームの追加やダッシュボードの利用) - ECSオートスケーリング

## プロジェクトの背景 データベースのレコードについて、[更新や削除の履歴を管理するgem](https://github.com/kufu/activerecord-bitemporal)のアップデートを行う。このgemはサービスのリリース当初から利用されているgemであるが、リリース以降一度もアップデートできていなかった。このgemのバージョンが古いため、RubyやRuby on Railsのアップデートの障害となっており、アップデートの必要性が生じた。 履歴管理のgemのアップデートに際して、gemを利用して履歴管理をしているテーブルに対するカラム追加と追加カラムに対する初期値の挿入が必要になるため、コードのデプロイ前にデータベースのマイグレーションとデータパッチが必要になる。データパッチが必要なレコード数は総計で2000万レコードを超えるため、障害なくリリースを完遂させるためには綿密な計画が必要となる。 ## 必要なタスク gemのアップデートについて、コードの改修からリリースの完遂までを主体的に行う。 ## 実現方針 ### 複数回のリリースに分け、ビッグバンリリースを避ける リリースの際のメンテナンス項目を列挙すると以下のようになる。 1. テーブルに対するカラム追加 2. 新規追加カラムに対するINDEXの追加 3. 新規追加カラムに対する初期値の挿入 4. 新規追加カラムに対するNOT NULL制約の追加 5. 新規追加カラムに対するEXCLUDE制約の追加 6. コードのデプロイ これらの手順の一部は、長時間テーブルロックをとるものがあるため、夜間などにサービスを閉塞して行う必要がある。ただこの手順を一度のリリースですべて実行すると、閉塞時間が非常に長くなってしまい、夜間の閉塞では済まない可能性がある。またリリース手順に問題があったときに切り戻しを行う必要があるが、一度にリリースすると切り戻しが難しく、失敗のリスクが非常に高くなってしまう。 したがって、リリースを一度で済ませてしまうのではなく、分割可能な範囲で手順を分割し、無閉塞で実施可能なものは事前に済ませておく。 結果として以下のような手順で実現した。 1. テーブルに対するカラム追加(無閉塞で実施) - カラム追加自体は既存の機能に影響を与えないため、事前に実施可能。 2. 新規追加カラムに対するINDEXの追加(無閉塞で実施) - PostgreSQLのCREATE INDEX実行時、[CONCURRENTLYオプション](https://www.postgresql.jp/docs/9.4/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY)を利用することで、テーブルロックをとらずにインデックスの追加が可能であり、事前に実行可能。 3. 新規追加カラムに対する初期値の挿入(無閉塞で実施するが、一部閉塞で実施) - 既存のレコードを細かい単位でUPDATEすることでユーザの通常利用との競合を限りなく少なくして、閉塞せずに前もって完了させる。 - カラム追加から閉塞リリースまでに定期的に初期値の挿入を行い、閉塞開始時に初期値が挿入されていないレコードが限りなく少ない状態にしておくことで、閉塞時のデータパッチ量を減らし、リリース時間を短縮する。 - 閉塞開始後に最後のデータパッチを実行する。 4. 新規追加カラムに対するNOT NULL制約の追加 (閉塞で実施) - ユーザの通常利用でレコードの追加や更新がある状態ではすべてのレコードの新規追加カラムの値がnullであることを保証できないので、手順3によってnullのカラム値が一切ない状態で実施する必要がある。 5. 新規追加カラムに対するEXCLUDE制約の追加 (閉塞で実施) - レコード数によっては10分以上かかるALTER TABLE文を実行する必要があり、インデックスの作成と異なりテーブルロックを取らないオプションの利用が不可能なので、閉塞リリース時に行う。 6. コードのデプロイ (閉塞で実施) - gemのアップデートとそれに伴うコードの変更をデプロイする。 ### 閉塞リリース時の手順のリリース想定時間の推定 リリース想定時間を推定するために、事前の検証を行った。検証は本番環境と同様のデータ量で行う必要があるため、[Amazon Auroraのクローン作成機能](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.html)を利用して同様の環境で検証を実施した。実行時間を事前に推定しておくことでリリースリスクの排除とスケジュール作成の補助となった。 ## 成果や学び 1. 大きな障害なくリリースを完遂できたこと 大規模なリリースであるにもかかわらず、大きな障害なくリリースを完遂でき、後に控えるRubyとRuby on Railsアップデートのスケジュールに影響を与えることなくプロジェクトを完了させた。 2. 大規模リリースに向けたノウハウを蓄積できたこと インデックス追加時のCONCURRENTLYオプションや閉塞を伴わないデータパッチなど、手法を検討するうえで様々な手法を実践したり、本番環境のクローン作成をしたり、様々な工夫を行った。 また、今回実施した方法以外にも方法を検討しチャレンジした。これらの手法は今後同様の大規模リリースでも活用できる有用な知見である。 - PostgreSQLのcopyコマンドを利用した高速なデータ挿入、移行の検討 - インデックスの有無によるデータ挿入のパフォーマンス計測などの手法を検討 またメンバーから「一時的にAmazon Auroraを高いスペックに変更し、処理を高速に終わらせる手法」や「通常利用でレコードが更新される際に、更新のついでにデータパッチを行う手法」など様々なノウハウを共有いただいた。

## プロジェクト概要 ### 手続き機能について 氏名・住所などの変更や配属の変更を行うことができる手続き機能があり、管理者からの依頼や従業員からの申請で開始する。手続きが承認されるなどして完了した時に手続きの内容に基づいて従業員情報が更新される。 また、手続き機能では雇用条件通知書や扶養控除申告書などの書類を発行・締結することができる。発行する書類には手続きの対象の従業員情報を参照して書類に埋め込むことができる。 ### 今回の機能開発によって実現されること 今回の機能開発により、人事労務担当(管理者)からの依頼時や従業員からの申請時に、手続きの内容を反映する日付を指定できるようになる。手続きが承認されて完了した時にすぐに手続き情報が従業員情報に反映されなくなる。代わりに、手続き開始時に指定した日付に到達した時点で従業員情報に反映されるようになる。 また、書類発行の手続きについて、書類に埋め込む従業員情報は指定した日付時点での情報に基づくようになる。 ## プロジェクト背景 人事労務の手続きについて、将来すでに変更予定があることがわかっている場合がしばしばある。例えば、引越しが決まっているため住所変更の予定があるが、実際に引越しをして住所が変わるのは数か月先である、4月から社内全体で大幅な配属の変更があることが3月時点で分かっている、などのケースが考えられる。 申請する従業員の視点からすると、変更が決まった時点で申請を済ませておくことで、申請忘れを防ぐことができる。また、大幅な配属変更の場合、4月になって実際に配属が変更されてから手続きを行わざるを得ない状況だと、4月以降の業務量が非常に大きくなってしまう。そのため3月時点で手続きは完了させておきたいが、手続きの承認フローは配属を参照して決定されることが多く、4月を待たずして変更が反映されてしまうのは都合が悪い。 ## 実現方針 本アプリケーションには従業員情報の[履歴管理のためのgem](https://github.com/kufu/activerecord-bitemporal)が導入されている。このgemを利用することで、レコード更新の際に日付を指定することで、その日付から有効なレコードを登録することができる。 またレコード参照の際に日付を指定することで、その日付時点での有効なレコードを参照することができる。 基本的にこのgemの機能を活用していくことで機能を実現する。 ### 特に難しかった点 gemの機能をそのまま利用することで基本的なケースは達成できるが、変更が適用される日付の指定や従業員情報の状況によってさまざまな更新パターンが存在し、あらゆるケースにおいて不具合なく実装することが非常に難しかった。 ### 考慮が必要なケースの一例 - すでに将来に変更予定がある状態のとき - すでにある変更予定の日付よりもさらに遠い日付で新たに手続きを開始するケース - すでにある変更予定の日付と同じ日付で新たに手続きを開始するケース - すでにある変更予定の日付よりも前の日付で新たに手続きを開始するケース - 変更予定の日付を指定して手続きを開始したが、完了までに時間がかかり、完了時点で指定した日付を越えてしまっていたケース - 認証にかかわる情報が変更されるケース(認証基盤は外部サービスを利用しており、外部サービスとの同期をとる必要がある) ### どのように解決したか - 手続きのパターンが非常に多いので、プロダクトマネージャーや顧客の背景事情を深く理解しているビジネスメンバーと仕様についての壁打ちを何度も行い、考慮漏れがないように要件定義、設計を行った。 - 利用しているgemのソースコードを丁寧に読み、どのようなロジックでレコードの更新が行われるのかを丁寧に調査した。gemの実装では実現できない要件については独自実装の必要があったが、gemのソースの理解によって実装をスムーズに行うことができた。 ## 業務を通じて学んだこと・成果 - 要件定義や設計をこれほどまで丁寧に行ったことはなかったので、要件定義・設計の良い経験となった。 - gemのソースコードを理解したり、実装時の挙動を検証したりすることで履歴管理や手続き機能の挙動を深く理解することができた。手続き機能に潜んでおり、未解決だった難しい不具合を何点か解決することができた。 - 履歴管理のgemのアップデート業務が控えていたので、ソースコードの理解がアップデート業務を進めるうえで助けになった。 - 機能変更の際に影響範囲が大きくなりすぎないようなコーディングを行うことができた。 - RubyやRuby on Railsに造詣が深いメンバーが多数在籍する企業の業務委託メンバーとペアプログラミングを行い、コーディング技術の向上につながった。

## プロジェクト概要 2023年に引き続き、年末調整機能開発を担当した。 ### 開発メンバー 開発リーダー 1名(自分) 開発メンバー 7名(業務委託1名、インターン生6名) QAエンジニア 1-2名 ## プロジェクト背景 2023年に担当した年末調整開発によって、機能の充実とパフォーマンス改善が行われた。しかし依然として他競合サービスと比較して機能が充実しているとは言い難く、さらなる機能充実が求められている。 一方で年末調整にかけられるリソースはそこまで多くなく、主に開発経験の浅いインターン生を中心とした開発になり、インターン生をいかに活用するかが重要である。 ## 自分の実績とその成果 インターン生が開発するうえで障害となる要素はあらかじめ排除して、開発がスムーズに進むようにした。またインターン生には難しい難易度の高い機能実装を担当した。あらかじめ計画されていた機能リリースを遅滞なく完遂することができた。 ### 法律上の要件を満たした機能実装 年末調整機能の開発において、所得税法をはじめとする法律に対する理解が必要になる。ただ、法律に対する理解をメンバー全員、特に法律関係に明るくないインターン生に理解してもらうのは難しい。開発にかかわる知識も実装しながら身に着けている状況で、ドメイン知識を取り入れないといけないとなると、知識の習得だけで開発期間の大半を費やしてしまうと危惧した。 そのため、年末調整にかかわる法律をまとめた資料を作成し、勉強会を開催して理解を深めてもらった。勉強会は開発メンバーだけではなく営業チームやカスタマーサクセスチームにも開かれ、事業部全体が年末調整に対する理解を深めるきっかけとなった。 自分自身も法律に対する理解をより深めるため、信頼できるリソースを参照して法律のキャッチアップに努めた。特に2024年は定額減税に伴う仕様変更があったため、法律の解釈に間違いがないように細心の注意を払った。 ### レガシーコードの改善(追加削除を伴うフォームの負債解消) 人事労務における家族情報の登録など一人の従業員につき複数登録できる項目をフォームで入力する際、フォームの追加・削除を動的に行うことが必要である。開発中のサービスでは、フォームの追加削除を行うために[jquery-repeater](https://github.com/blpraveen/jquery.repeater)というJavaScriptのライブラリを利用している。これはRuby on Rails向けに作られたものではないため、カスタマイズするためのJavaScriptのコードを別途記述している。ただ、カスタマイズ用のコードが複雑でありバグのもとになっていた。 そのため、jquery-repeaterへの依存を脱却し、[cocoon gem](https://github.com/nathanvda/cocoon)に乗り換えた。これはRuby on Railsで利用するために作られたgemであり、長く利用されて枯れた技術であるためリスクも少ない。乗り換えによって潜在的にあったバグがすべて解消されただけでなく、JavaScriptのコードが大幅に改善されて新規開発のハードルが大幅に下がった。 後続のタスクでインターン生がフォームを利用する部分のコード改修を行う予定となっていたが、フォーム関連のバグを踏むことなく新機能の実装を行うことができた。 ### 難易度の高い機能実装(回答グループごとのステータス管理) 年末調整では回答すべき項目が多いため、年末調整機能を提供するサービスは回答をグループ分けして、回答の進捗がわかりやすいようにしていることがほとんどである。本サービスでも例にもれず、以下のようなグループ分けを行っている。 - 年末調整が必要かどうかの確認・前職の有無 - 本人情報の入力 - 配偶者情報の入力 - 家族情報の入力 - 保険情報の入力 - 住宅ローン情報の入力 ただ、回答グループごとの細かいステータス管理の機能に不足していたため、回答グループごとに完了や差戻(修正依頼)をできるようにする機能開発を担当した。 #### 成果・学び 大きな技術的革新はないが、ほかの開発者がよりメンテナンスしやすくするような工夫や不具合が重大にならないような工夫を何点か行った。 1. バグがあっても大きな問題にならないような実装をする 完了していたり、管理者が確認中だったりして従業員が編集できないステータスの場合、その回答グループの設問画面には遷移できないようになっている。ただ遷移のパターンは複雑であり、遷移の制御が漏れているケースがあることが危惧された。そこで、仮に編集できない画面に遷移できたとしても、更新時にエラーになるような制御をコントローラ側で加えることで、遷移の制御ミスが重大な不具合にならないようにした。 2. ほかの開発者が追加開発をする際、ステータスの制御ミスがないようにする 年末調整機能内には回答ステータスを変更する処理が多く、これらをすべて把握して開発するには注意力を要する。新たに処理を追加・修正する際に複雑な分岐を実装しなくても制御ミスなく実装できるような工夫をした。ステータスの性質上、絶対にあり得ない遷移のパターンが存在する。あり得ない遷移のパターンが発生しないよう、あり得るステータス遷移のパターンのホワイトリストを作成しておき、そのリストに含まれない更新は破棄されるようにした。 これによって年末調整機能に詳しくない開発者が参画しても、ちょっとしたミスで大きな不具合にならないようになった。 またこのような安全な実装の意識を経て、自分自身やほかの開発者の実装ミス防止を開発者の注意力や善性にゆだねないような設計や仕組みづくりを意識するようになった。年末調整とは関係ないが、開発者のミス防止をコードで防止する取り組みとしてRubocopのカスタムルールを導入した。 https://developers.techouse.com/entry/rubocop-custom-rule

## プロジェクト概要 人事労務アプリケーションの年末調整機能の開発を担当した。当初は開発メンバーの一員としての参画だったが、プロジェクトの開発リーダーが体調不良によりプロジェクトに本格的に携われないようになったため、途中からは開発リーダーとしての役割も兼任した。 開発リーダーは主に開発スケジュールとの兼ね合いによるリリースアイテムの決定やビジネスチームとのコミュニケーション、他メンバーへの開発タスクのアサインとレビューや障害発生時のインシデントコマンダーなどの役割を持つ。 ### プロジェクトメンバー(開発チーム) 6月-8月 - 開発リーダー 1名 - 開発メンバー 3名(自分を含む) - QAエンジニア 2名 9-10月 - 開発リーダー 1名(元のリーダーの体調不良につき自分が代替) - 開発メンバー 2-4名(状況によって増減) - QAエンジニア 2名 11-12月(リリース後) - 開発リーダー 1名(自分) - 開発メンバー 0名 - QAエンジニア 1名(緊急の不具合の修正などの対応) ## プロジェクト背景 サービスとしては2021年から年末調整機能を提供しているが、利用顧客が大幅に増えた2022年では急ピッチで開発を進めた弊害であるバグやパフォーマンス問題が多発していた。また年末調整機能を提供する他競合サービスと比べても機能が豊富ではないため、新規機能の開発も予定されていた。 ## 成果 ### パフォーマンス問題の解決 2022年にパフォーマンスが原因となり顧客からのクレームの要因となっていた問題を複数解決した。 1. 年末調整初期設定のジョブの速度改善(一括インサートによる) 本サービスは年末調整機能以外にも人事労務にかかわる機能を多数提供しているが、年末調整機能は他の機能とデータを保存するテーブルが異なる。また年度ごとにテーブルが分かれている。 そのため労務管理の担当者(以降、管理者とする)が年末調整業務を始める前には初期設定のジョブを実行し、年末調整以外のテーブルからの従業員情報からのコピーや昨年の年末調整情報からのデータのコピーなどを行う。 初期設定のコードは実行速度について考慮されておらず、従業員1件ずつに対して関連レコードのインサートを行っていた。初期設定は基本的に従業員にかかわらず同様の処理を行うので、ActiveRecordの[insert_all](https://api.rubyonrails.org/classes/ActiveRecord/Relation.html#method-i-insert_all)を利用することでインサートの時間を大幅に短縮した。 3万以上の従業員を抱える企業も年末調整機能を利用しており、従来は1時間以上かかっていたが、10分程度で完了するまで改善した。 2. 管理者用の従業員一覧画面(N+1問題の解消、不要なActiveRecordオブジェクトを作成しないことによる速度改善) 従業員数が多い企業において、管理者用の画面の表示に非常に時間がかかるという問題が2022年に報告されていた。調査したところ従業員一覧の表示やステータスごとの従業員数の表示(未対応n人、完了n人などの表示)においてN+1問題が発生していたので、すべて解消した。 しかし、それでもステータスごとの従業員数の表示の速度改善については微々たるものであった。従業員ごとのステータス管理は複数のレコードによって管理されており、[eager_load](https://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html#method-i-eager_load)を利用してjoinしたレコードを使って取得されていた。N+1問題は発生していなかったが、ActiveRecordのオブジェクト生成に大量の時間を要しているようだった。 ActiveRecordオブジェクトは大量に生成するだけでパフォーマンスに影響を及ぼすことが分かったので、ActiveRecordの文法を利用せずにSQLを記述することでオブジェクトの生成を防ぐことによって高速化を図った。 従業員5000人程度の企業で20秒弱かかっていたページの表示を常に2秒以下になるまで改善した。 3. 従業員情報エクスポート機能(N+1問題の解消、分散ジョブ) 従業員の年末調整の提出がすべて完了した時点で、管理者は給与システムとの連携や源泉徴収票の発行などの業務に移る。その際に年末調整機能で収集した情報を他システムに取り込むなどの業務が発生するため、エクスポート機能が存在する。このエクスポート機能もまたパフォーマンス問題を抱えていたため、改善した。 まずN+1問題の解消に取り組んだ。年末調整は収集する情報の量が多く、関連テーブルは20から30ほどにもなる。純粋に改修の量が膨大であったが、不足していた開発者のテストも併せて実装し、不具合なく改修できた。 ただ、これだけで問題は解消されなかった。大量の従業員に対して大量のテーブルのレコードを扱うので、メモリを大量に消費する問題があった。これを解消するために、一つのサーバで処理するのではなく、複数のサーバで処理する分散プログラミングを採用した。これによってメモリの問題が解消されるだけでなく、速度のさらなる改善が期待できる。 幸い分散プログラミングについては社内に前例があったため、前例と同様に実装することで実現できた。分散プログラミングについては以下の社内ブログでの解説も行ったため、理解が深まった。 https://developers.techouse.com/entry/distributed-programming-on-sidekiq ### 開発リーダーとしての活動 やむをえない事情ではあるが、プロジェクトの途中から開発リーダーとしての役割を果たした。特に以下の内容について主導権をもって活動した。 1. リリースアイテムの決定 開発リソースや顧客要望の度合いなどの兼ね合いをもとにビジネスチームの年末調整担当者と相談してリリースアイテムの決定を行った。 2. リリース後の問い合わせ対応 年末調整は10月のリリースから業務が完了する12月ごろまでに顧客からの問い合わせが集中する。また顧客が年末調整を進められないような不具合が見つかった場合、最優先で解決する必要がある。大量の問い合わせから対応の優先順位を決定して迅速に対応する業務をやり切った。