ID:85395さん

## プロジェクト経験概要 **クラウド型デジタルバンクシステム開発（勘定系システムの業務単位分割・クラウド化）** - **期間**：【2023年5月〜2024年6月】 - **概要**：従来の勘定系システムを、融資・資金運用・ローンサービスなどの業務単位に分割し、クラウドサービス基盤上で疎結合に連携できるネットバンクシステムとして再構築するプロジェクト - **役職**：開発メンバー - **規模**：プロジェクト全体 約400名／所属チーム 15名 - **担当工程**：結合テスト、総合テスト（追加要件に伴う新機能は基本設計〜結合テストを担当） ## チーム情報 - **プロジェクト体制**：銀行業務の種類ごとに縦割りでチームを編成（約400名） - **所属チーム（15名）**：入出金・ローン計算など各種銀行業務で発生したデータを集計する機能と、他システムへ連携する機能を開発 - 体制：チームリーダー1名、サブリーダー1名、開発メンバー13名 - **自身の役割**：開発メンバーとして、以下を担当 - 各機能の結合テスト、Salesforceへの顧客データ連携機能の総合テスト（総合テストは自身が単独で担当） - 追加要件に伴う新規バッチ2件の基本設計〜結合テスト - 常駐バッチの改善12件、性能改善1件 - 新規参画者への機能・運用ルールの説明 ## 開発・作業内容：Salesforceへの顧客データ連携機能の総合テスト 【概要】 - 各種銀行業務で作成されたデータがSalesforceへ連携され、Salesforce側のDBに正しく取り込まれるかを検証する総合テスト - 私が実施したこと：銀行システム側の動作確認と、テスト全体の調整・進行（Salesforce側の確認はSalesforce社員が担当） 【どのような機能の開発・実装か】 - 各銀行業務チームが作成したデータを集約し、Salesforceへ連携する機能 - テストには、他チームが担当する各業務機能で作ったデータが必要であり、他チームの協力が不可欠だった - 日次バッチなどで作成されたテストデータを使用するため、テストケースごとに実施日が決まっており、関係者間で事前の日程調整が必要だった 【課題・問題点】 - プロジェクトが大幅に遅延し、各チームが自チームの進捗・品質対応に手一杯で、チーム間の協力体制がなかった - 縦割りの体制のため、この連携機能の存在自体が他チームにほとんど認知されていなかった 【打ち手・使用した技術】 - 担当者間の個別調整では協力を得にくいと判断し、チームリーダーとプロジェクト責任者に、全チームの協力体制づくりを提案。「連携テストで各業務機能のデータの正しさを検証でき、各機能のバグを検知できる」と、品質面のメリットを示した → プロジェクト責任者が各チームに周知し、チーム間で協力しやすい体制ができた - 各テストケースの実施日の2〜4週間前に、関連機能の担当者へ協力を依頼し、試験内容を説明 - 手順や確認タイミングが複雑なケースは、各担当者とSalesforce担当者の作業可能時間をヒアリングし、タイムテーブルを作成・共有 - 各チームの総合テスト仕様書を確認し、流用できるテストデータは借用して、各チームのデータ作成の負担を軽減 - バグを検知した際は被疑箇所を特定し、主幹チームへ調査を依頼 【成果】 - **定量**：各テストケースを決められた実施日どおりに実施（事前にバグを検知して保留にした項目を除く）。保留項目も総合テストの納期内に完了 - **定性**：連携テストを通じて各業務機能のバグを検知し、品質向上に貢献。他チームとの関係ができ、機能仕様を互いに質問しやすい関係を築けた ## その他の取り組み - 新規参画者に、担当機能とプロジェクトの運用ルールを説明し、立ち上がりを支援 ## 身に付いた知識・スキル - 相手の状況を考慮し、余裕を持った調整を行う進め方 - 利害の異なる相手とも、共通の目的（品質向上）を示すことで協力関係を築けること - 分岐パターンをテーブルで管理し、コード量を減らす設計手法 - 接続先のレスポンスとエラーパターンを整理してから行う、REST通信のエラーハンドリング設計

## プロジェクト経験概要 **製品含有化学物質・資源循環情報プラットフォーム（CMP）の開発** - **期間**：【2024年7月〜現在】 - **概要**：製品に含まれる化学物質情報と資源循環情報を、サプライチェーン全体で一元管理・連携するデジタル共通基盤の開発。CO2排出量の伝達など、他のユースケースにも活用できる共通基盤として構築 - **役職**：開発メンバー（基盤ベンダ側） - **担当工程**：基本設計（要件定義と並行）、詳細設計、製造・単体テスト、結合テスト、大規模実証、運用 ## チーム情報 - **関係組織** - CMPタスクフォース：ユーザー企業を代表する30社。要件定義と運用上の意思決定を担う - アプリベンダ3社：ユーザーが利用するアプリケーションを開発 - 基盤ベンダ（所属）：共通基盤（プラットフォーム）を構築 - ユーザー企業：最大10000万社の利用を想定 - **所属チーム（業務チーム・8名）**：共通基盤の業務要件を満たすAPIとテーブルの設計・開発から運用までを担当 - 体制：チームリーダー1名、サブリーダー1名、開発メンバー6名 - **自身の役割**：開発メンバーとして、以下を担当 - 要件定義ワーキング定例会への参加と、業務フロー作成・機能分割・API仕様設計 - テーブル定義・データモデル設計、約300件の業務要件と設計の整合性検証 - アプリベンダ向けAPI利用ガイドラインの作成・説明 - 性能モデルの作成から性能試験の実施・解析・レポート作成まで（業務チーム側の担当者） - 詳細設計、実装、テストケース作成、結合テストの実施・レビュー、大規模実証での障害調査 ## 開発・作業内容1：共通基盤のAPI・データモデル設計 【概要】 - 要件定義ワーキングで業務要件とアプリベンダの要望を把握し、業務フロー作成、機能分割、API仕様・データモデルの設計を担当 【どのような機能の開発か】 - サプライチェーン上の企業が化学物質情報・資源循環情報を登録・閲覧・連携するためのAPIとテーブル群 - 私が担当したこと：約300件の業務要件について、APIやアプリの組み合わせで実現できるかを確認し、設計との整合性を検証 【課題・問題点】 - データ主権（登録した企業がそのデータを更新できる）の考え方から、全テーブルで主キー以外を更新可能にする設計方針が検討されていた - しかし、企業間の取引関係を管理するテーブルで、データを識別する複合ユニークキーが更新できると、データの整合性と閲覧権限の制御が崩れるリスクがあった - プロジェクトの立ち上げ段階で、メンバー全員が手探りで業務要件の整理を進めている状況だった 【打ち手・使用した技術】 - 更新した場合の影響範囲を整理し、現在の要件だけでなく将来のユースケースも考えたうえで「複合ユニークキーの更新禁止」を提案 - プロパーの幹部クラスの社員との仕様検討の場で、論点を整理しながら説明 - 毎回の仕様検討の議事録を復習し、各API・データモデルを構造化して把握しておき設計方針のずれやデータ不整合の可能性に気づけるようにしていた - テーブル設計では、APIの使われ方と登録データを想定してインデックスを設計 【成果】 - **定性**：提案が採用され、設計書に反映された。データの整合性と閲覧権限の制御を設計段階で担保した - **定性**：設計内容をアプリベンダ向けのAPI利用ガイドラインにまとめ、業務フローとAPIの使い方を説明して、アプリベンダ社の仕様理解に貢献した ## 開発・作業内容2：性能試験の設計・実施と解析の効率化 【概要】 - 基盤の性能試験で、性能モデルの作成から試験ツール作成、実施、解析、レポート作成までを担当した - 自分は試験データの統計値とレイヤーごとの処理時間を算出し、その結果をもとにインフラチームがコンテナごとの遅延分析などインフラ観点の解析を実施した - 想定利用者数とTPS目標に基づく性能モデル、JMeterの負荷シナリオを作成した 【課題・問題点】 - JMeterの測定データの加工・可視化を手作業で行っており、1回の解析に3〜4日かかっていた - 性能改善のたびに再テストが必要なため、1回あたりの解析時間の短縮が必要だった - チーム内では問題視されていなかったが、改善サイクルの遅さにつながると自分で課題として捉えた 【打ち手・使用した技術】 - 応答時間の95パーセンタイル値、秒間TPS、エラー発生状況を可視化する分析処理をPythonでスクリプト化した - ユーザー単位の応答時間やレイヤー別の処理時間まで分析できるようにし、問題箇所の特定に活用した - スクリプトの作成には生成AIを活用し、作成自体も効率化した - 解析手順を手順書として整備し、俗人化を防いだ 【成果】 - **定量**：解析作業を3〜4日から**約1日**に短縮 - **定性**：解析結果を業務チームとしてまとめることで、インフラチームがすぐに解析に着手できるようになった - **定性**：手順書の整備により、自分以外の業務チームメンバーも性能試験データを解析できる状態にした ## 開発・作業内容3：開発上の課題の提起と、追加要件の実現方針の提案 【概要】 - 開発上のリスク・課題を自ら見つけ、対応策とあわせて起票・提案を行った（業務チームの課題管理簿130件中22件を起票） 【課題・問題点】 - 要件の曖昧さ、システム構成変更に伴う懸念、ローカル開発環境の不便さ、実装の可読性・保守性の低さなど、技術的負債が生じていた - 追加要件の実現方針を他チームと自チームリーダーが決めていたが、修正範囲が大きく、実装〜試験に約1か月かかる見込みだった 【打ち手・使用した技術】 - 曖昧な要件の詳細化、構成変更に伴うデータ不整合や業務要件不適合の懸念、現行実装の課題などを検知し、対応策と想定タスクを添えて起票 - 一部は担当者として対応した - 主幹が別チームの場合には課題を説明し、進め方を相談した - 追加要件への対応では、実装の修正範囲・テスト工数・保守性を考え、既存機能への影響が少ない実現方針を提案 【成果】 - **定量**：課題管理簿130件中22件を起票し、チームの課題解決に貢献 - **定量**：追加要件への対応では、提案した方針で合意を得て、実装〜試験を**約1か月の見込みから3日**で完了させた ## その他の取り組み - 結合テストでソースコードを確認し、テスト観点の不足を指摘した - 大規模実証でAPIの障害（5XXエラー）発生時に、ログとシステム構成から原因箇所を切り分け、主幹チームへ調査を依頼し、プロパー社員へ状況を説明した ## 身に付いた知識・スキル - 要件を整理し、業務フロー・データモデルを作成したうえで、機能分割・API設計・テーブル設計を行うスキル - 性能試験の設計と性能分析 - 繰り返し行う作業を仕組み化する進め方 - 議論の際は、相手の主張の意図を理解したことを伝えてから意見を述べると、建設的に議論できること - 課題は対応策とセットで提起すると、議論が進みやすく合意も得やすいこと - 製品含有化学物質管理の業務知識