ID:75082さん

プロジェクト概要

決済代行システムのリプレイスプロジェクト。
リプレイスではあるが、システム構成から大幅に変更して開発。
担当は、input(JSON)をDB(Oracle)に登録/更新するAPI。
※担当機能はゼロからの新規開発。

目的、背景

決済代行システムをリプレイスする。

規模感、チーム構成

自チーム：7名程度(PM1名、設計チーム1名、開発チーム3～5名)、他ベンダ：数名程度

担当した役割

開発チームリーダー(テックリード)
・APIの構成検討
・設計の実装取り込み方式検討
・共通機能実装/テスト
・PGレビュー
・テスト方式決定

取り組んだ課題

どんな課題だったのか

ほぼ同じ処理内容のAPIを6本開発する必要があった。
また、近い将来にほぼ同じ処理内容のAPIを約20本開発する予定もあった。
⇒共通化を意識し、可読性・保守性に優れたソースコードにする必要がある。

技術的なアプローチや工夫した点

・処理内容がほぼ同一である為、共通化可能な箇所は共通化するように意識した。
・コード値などはEnumや定数クラスで管理し、リテラルを使用しないようにした。
・入力チェックは、うまくパラメータを与えることにより全てのAPIで共通化した。
・開発メンバのスキルが低い為、お手本を作成しある程度コピーで開発できるようにした。

取り組みの成果

・ソースコード量も少なくなり、かつクラス構成も目的毎に整備できた。
・構成をそのままコピーすれば良い為、開発スキルが低くてもAPIの開発自体が可能になった。

プロジェクト概要

目的、背景

ガスの保安調査に関して、新システムを構築し大きく変更する。
新システムでの保安調査結果は、旧システム側のDBにも登録する必要があり、
これを定時起動バッチにより実現する。

規模感、チーム構成

顧客：3名程度、自チーム：(PM1名、設計チーム：3名程度、開発チーム：2～10名程度)

担当した役割

・顧客との仕様調整
・仕様検討、顧客へ提案
・設計書作成、顧客レビュー
・開発チームリーダーと仕様の調整
・PGレビュー
・設計書内部レビュー

取り組んだ課題

どんな課題だったのか

・入出力の項目が多く、それぞれの個別の仕様やDBへのCRUDの仕様など、
　考慮すべき事項が多数存在する。

技術的なアプローチや工夫した点

・明らかに分かる仕様は顧客確認をスキップし、不明な仕様を重点的に確認する。
・一つ一つ丁寧に整理し、顧客に確認済のものと未確認のものを管理する。
・開発への影響度を考慮し、仕様確認は優先度を付けて行った。

取り組みの成果

・稼働が高くなった時期もあったが、最終的にはなんとか本番リリースを予定通り終えることができた。
・本番障害も発生させてしまったが、機能ボリュームを考慮すると少なく抑えられた。
・顧客から多数のご指摘を頂き精神的に辛い時期もあったが、最終的には最後までやり切ったことをお褒め頂いた。