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の仕様など、 　考慮すべき事項が多数存在する。 ## 技術的なアプローチや工夫した点 ・明らかに分かる仕様は顧客確認をスキップし、不明な仕様を重点的に確認する。 ・一つ一つ丁寧に整理し、顧客に確認済のものと未確認のものを管理する。 ・開発への影響度を考慮し、仕様確認は優先度を付けて行った。 # 取り組みの成果 ・稼働が高くなった時期もあったが、最終的にはなんとか本番リリースを予定通り終えることができた。 ・本番障害も発生させてしまったが、機能ボリュームを考慮すると少なく抑えられた。 ・顧客から多数のご指摘を頂き精神的に辛い時期もあったが、最終的には最後までやり切ったことをお褒め頂いた。