教職員向け共済の
火災・教賠保険の開発

概要

現行システムをWebアプリケーションにリプレイスする案件です。
全国に支部があり、一部の支部では保険期間が異なる他、独自の機能を持つケースがあります。
私は主に火災保険と教職員賠償責任保険の契約入力・契約履歴・個人情報画面での保険情報の照会・帳票の制作などを担当しました。

案件詳細

現行システムは数十年前に自社で開発したもので、Javaで構築されていました。
コードの規模が大きく、保守・改修に課題を抱えていたため、Webアプリへのリプレイスが実施されました。
リプレイス時点においても運用は継続されていて、機能追加などの改修を行いながら、並行してリプレイスを進めています。

現行システムはコーディングガイドラインが定まっておらず、長年にわたり機能追加が繰り返された結果、可読性が低く保守が困難な状態となっていました。
また、リプレイス側ではある程度、画面やデータの取得の下地はできていて、現行を基にした仕様書もGitHubに用意されていました。
しかし、実際に現行と比較すると、不足や差異が多くある状態でした。
そのため、開発時は現行のコードを解析して、仕様書との差異を確認して修正。仕様書のレビューを経て、問題が無ければ開発に着手していくというプロセスとなっていました。

開発環境

フロントエンド

言語： TypeScript, HTML5, CSS3
フレームワーク： Vue.js 3
ライブラリ： Element Plus, Vue Apollo
開発支援ツール： GraphiQL

バックエンド

API： GraphQL
ツール： PostGraphile

データベース

DBMS： PostgreSQL
管理ツール： pgAdmin

ビルドツール

Vite

インフラ

OS： Linux
環境： オンプレミス

パッケージマネージャ

npm

バージョン管理

GitHub

CI/CD

GitHub Actions（ビルド・テスト）

エディタ

Visual Studio Code

データフロー

参画期間

2023年7月～8月、2024年3月～2024年12月（約1年）

役割と責任範囲

火災・教職員賠償責任関連の開発は、私とリード役の2名で担当しました。
基本的にはリード役の指示のもとに作業を進めていました。
この2名は、それぞれ別の案件に着手している期間があります。
その他に、常時アサインされているメンバーが2名で、別の保険を担当しています。

以前に別のメンバーが開発に着手していたようで、前任者によって実装されていた機能にも、仕様との乖離が見られたため、その修正も担当しました。
基本的には画面や機能単位で作業を分担し、相互レビューを実施。
片方が別案件に着手している場合は、常時アサインのメンバーにレビューを依頼して進行していました。

課題に対する取り組み

現行システムには明確なコーディングガイドラインが存在せず、1つの関数が数千行になっていて、その中でさらに呼び出される関数により、複雑に条件分岐している状態でした。
この課題を踏まえ、リプレイス版では可読性と保守性を向上することを目指しました。
変数名や関数名が実体を正確に表しているか、関数が不必要に大きくなっていないか、共通化できる部分はないかなどの観点を重視し、開発・レビューを行いました。

テスト工程での経験

これまでの開発経験では、テストに直接関わる機会は少なかったため、今回初めて vitest を使用したテストに携わりました。
関数単位でのテストはスムーズに進められましたが、複数のコンポーネントが連携する「登録処理」などのシナリオになると、テストに失敗し試行錯を重ねました。
原因は、スタブ化やモック化の際に適切なデータを設定できていなかったことにありました。
この経験により、複数コンポーネントが絡む処理では、依存関係やテストデータの整合性を意識する必要があることを深く理解しました。

入力テストは現行システムとリプレイス版の双方で実施。
リリース前は、リード役に重点箇所をピックアップしたテストケースを用意していただき、差異が無いか確認しながら対応しました。
その結果、数カ所の差異を発見し、事前に改修することができました。
この経験を通じて、漠然と全体を網羅的に確認するだけでなく、重点的に対応箇所を絞ってテストすることの重要性を学びました。

所感

リード役によるレビューは、これまで指摘を受けてこなかった細かな点にも意見をくださり、プルリクエストでの作法や、コミットの粒度を改善する意識が身につきました。
基本的にはissueに基づく作業ですが、issue外の対応がある場合はコメントで補足、レビュアーに意図が伝わるように心掛けました。
コミットの粒度は「意味のある粒度、または目的がわかる粒度」として、やむを得ず粗くなる場合も、コメントで補足しました。
これにより、レビュー効率の向上や、チームでの開発の流れや進め方が、以前より明確に分かるようになったと感じています。