某公共業務向け 地図パッケージシステム 新規開発
概要
自社の汎用GISパッケージシステムをラップした形で、特定の官公庁の業務に特化したパッケージシステムを開発。
既存２顧客に対するリプレース案件としての開発。
（２顧客以外にも順次、リプレースまたは新規導入していく予定での開発）
- 開発期間：2014年6月〜2015年4月
- システム形態：クラサバ
- 使用技術
- フロントエンド
- 言語：Java、VBA
- フレームワーク：Swing
- バックエンド
- 言語：Java
- フレームワーク：Seasar2
- テストフレームワーク：JUnit
- テストライブラリ：DBUnit
- DB：Oracle
- 資源管理：Subversion
- フロントエンド
PJ体制と担当業務
- PJ人数：最大時20名
- 開発スタイル：ウォーターフォール型開発
- 担当フェーズ：要件定義、システム設計、コーディング、テスト
- 役割
- バックエンドチームのチームリーダ（チームメンバー数：3名）
- データ移行チームのチームリーダ（途中から。チームメンバー数：3名）
行ったこと
バックエンド機能の設計と実装
基本的には、クライアントから渡されてきた情報に応じて、DB検索や更新を行うAPI機能の開発。
APIは約100個あったが、8割はシンプルな検索、登録、更新処理のため、
最初に全APIを洗い出して全てのインタフェース設計を行い、サンプルになる機能をテストコード含めて実装し、
シンプルなAPIについては、これを参考にして実装するようにメンバに実装を依頼。
仕様の複雑な2割のものについては、業務仕様の整理、データ設計等を業務の有識者であるPLと相談しながら行い、
実装まで行った。
データ移行機能のリカバリ
リプレース案件のため、旧来のシステムからのデータ移行作業が必要であり、
データ移行チームが仕様整理から移行ツールの開発までを行っていたが、
1番目の顧客のデータ移行作業にてデータ移行に失敗。
以下理由から、自分が移行チームのリーダとなって、2番目の顧客のデータ移行に向けての作業を行うことを提案。
- 移行チームの状況
- 移行に失敗したデータのリカバリが急務になり、そちらに人員を割く必要が出た（→別動隊を編成）
- 同時に、1か月後に行われる2番目の顧客のデータ移行に向けて、移行ツールの改修がPJとして急務となった
- 移行チームのリーダが疲労困憊に達していた
- 私の状況
- バックエンド機能の開発のうち、最低限必要な機能については開発完了していた
- 移行先DBの仕様は、自身が一番熟知していた
移行チームのリーダを引き継ぎ、1ヶ月弱で移行仕様の整理から移行ツールの改修までを実施。
（自身は主に既存移行ツールの仕様確認と、移行するデータの仕様整理を行い、実装は他メンバに依頼）
2月末のデータ移行は大きな問題なく無事完了。
他メンバがギブアップした帳票機能の不具合対応
帳票機能は、サーバから取得したデータを元にVBAで計算や整形を行う方式だったが、
このうちの1つの帳票において、
「サーバから取得した内容は全く同じにも関わらず、帳票の出力結果が稀に異なる」
という不具合が発生した。
当該機能担当者や他メンバが調査するも原因がわからず、
苦肉の策で検算プログラムを用意して、顧客には帳票出力後に検算してもらう対応で凌いでいた。
諸々の自作業が落ち着いてきたタイミングで、この不具合について調査して原因を解明し、
無事、不具合解消。
この時の不具合原因について、ネット上に情報が見当たらなかったため、以下記事執筆。