ID:81558さん

# ユーザーのビジネス課題 - 印刷装置から収集した内部動作情報を Metabase（BI ツール）で可視化し、利用者がデータを直感的に活用できる仕組みを構築したい。 - チーム内に Metabase や AWS の本格利用経験者がいない中で、導入可否の検証からアーキテクチャ設計まで進める必要があった。 # 状況 - チーム内に Metabase や AWS の利用経験者がいない中で、導入可否の検証からアーキテクチャ設計と実装をする必要がある。 # 取り組み方針・思考プロセス ## Metabase のテスト環境構築 1. 所属チームに Metabase／AWS の経験者がおらず、「他チームで導入されている Metabase を当チームでも活用したい」という要望から検討を開始。 1. まず自分のローカル環境（WSL2 + Docker）上に Metabase のテスト環境を 3 日で構築し、チームメンバーに対してデモを実施して、可視化できる内容や操作感のイメージを共有。 1. 個人 PC 上の環境では全員が触れないため、次のステップとして AWS EC2 上に簡易テスト環境を 3 日で構築し、Metabase 未経験のリーダー陣も含め誰でも操作・検証できる共通環境としてチーム全体で利用開始した。 ## AWS 環境構築 - 業務要件 1. 印刷装置からのログが不定期に送られてくる。 1. ネットワーク経由ではなく、USB 経由でログファイルをアップロードする。 1. アップロードされたログを解析アプリで処理し、その結果を Metabase で参照したい。 ※解析アプリは別チームで作成する。 - 上記を踏まえ、以下の方針で AWS 構成を検討・提案・実装。 1. ログアップロードは S3 をフロントに置く形が適すると判断し、簡易に実装できる Amplify + Cognito + React を利用した Web アプリを提案し実装。 1. ログ到着が不定期であることから、常時稼働サーバーではなく Lambda によるサーバーレス構成とすることで、コスト最適化と運用負荷軽減を図ることを提案し実装。 1. Lambda のデプロイには GitHub Actions を用いた自動デプロイパイプラインを構築し、デプロイ作業の標準化とミス低減を実現。 1. DB については、バックアップ機能が豊富、かつ、スケールアップが容易な RDS（PostgreSQL）を採用し実装。 1. Metabase は将来のスケールアップも見据え、公式から公開されている Docker イメージ使用し、 ECS/Fargate 上でコンテナ運用する構成を提案し実装。 1. DBメンテナンスおよび他チーム環境からRDSへ接続を可能とするため、EC2の踏み台サーバーを提案し実装。 # 担当内容・出したバリュー 1. 約1か月でRDS・ECS・ALB・Route53環境を構築し、metabaseサーバーの起動に成功。 1. 約３週間でAmplify＋Cognito＋S3環境を構築し、ファイルアップローダーWEBアプリの稼働に成功。 1. 約３週間でLambda＋GithubActionsによる自動デプロイと、S3のファイル更新イベントをトリガーにLambdaを起動＋DBへの書き込み環境の整備に成功。 1. 約４週間で他チーム作成のアプリ（windowsベース）を解析し、Lambda（Linuxベース）上で動くようカスタマイズを行い実装に成功。 1. 約１週間でSESを構築しmetabaseからのメール通知機能の実装に成功。 1. Metabase の操作マニュアルや AWS の構成要素・運用手順をドキュメント化し、ツール・基盤に不慣れなメンバーでもダッシュボード作成・拡張や運用保守が行える状態を整備。 1. Metabase・AWS ともにチーム内初導入の技術であったが、検証〜設計〜構築〜ナレッジ共有まで一貫して推進することで、今後の類似案件でも再利用可能な基盤と知見を残した。 # 使用技術・構成要素 1. RDS（PostgreSQL）：データストレージ 2. ECS/Fargate：Metabase コンテナ運用基盤 3. EC2：RDS 接続用踏み台サーバー 4. Amplify + Cognito + S3 + React：ファイルアップロードアプリケーション 5. Route53 + ALB：Metabase 用グローバルドメイン取得および通信暗号化 6. VPC：各サービスをネットワーク内に配置し、セキュリティを強化 7. IAM：各アプリケーションの権限設計・調整 8. SES：SMTP サーバーとして利用し、Metabase からのメール送信機能を実装 9. Lambda：収集データ解析アプリケーションの実装実験および開発手順の整備 10. GitHub Actions：Lambda デプロイ用の自動デプロイパイプライン構築に使用

# プロジェクト概要 - 証券用会計システムの既存アプリ保守・開発要員として参画し、主として調査・開発・テスト・導入を担当。 - 併せて、業務部門発の新規アプリについて、プロトタイプ作成の担当者として抜擢され、他社とのコンペディションを実施。 # ユーザーのビジネス課題 1. 既存の証券用会計システムに対して、障害対応・仕様追加・制度改定への追従を安定的に行う必要があった。 1. 業務部門から新たな会計関連業務を効率化するための Web アプリ作成要望があり、どのような方式・技術スタックで実現するかを短期間で提案・検証することが求められていた。 # 取り組み方針・思考プロセス 1. 既存システムについては、障害調査や仕様変更時に影響範囲が読みづらい箇所が多く、まずは「調査・構造解析しながら安全に改修できる状態」を作ることを優先。 1. 新規アプリについては、業務フローや既存システムとの連携方式をヒアリングし、「現行運用を大きく変えずに業務負荷を下げられること」「将来の拡張や他部署展開がしやすいこと」を軸に技術選定を検討。 1. Python/Django による Web アプリとすることで、短期間でのプロトタイプ開発・変更容易性・既存の Python 資産の活用を両立できると判断し、画面構成や API 設計のたたき台を自ら用意してコンペ提案に臨んだ。 # 担当内容・出したバリュー 1. 既存の証券用会計システムでは、調査・設計・実装・テスト・導入まで一貫して担当し、仕様が複雑な会計処理についても影響範囲を整理しながら安全に改修できるよう、ログ出力やテスト観点の洗い出しを強化。 1. Python 開発の有識者として他部署からの要請を受け、コードレビューや実装方針の相談対応などアドバイザー業務を実施し、部署横断での開発品質向上に貢献。 1. Django の有識者として、新規アプリ開発時の設計・実装方針のアドバイスおよびデバッグ支援を行い、立ち上げフェーズの技術的なボトルネック解消をサポート。 1. 新規アプリのプロトタイプでは、開発担当者として抜擢され、要件整理から画面・API 設計、実装までをリードし、他社とのコンペにおいて提案アプリが採用される結果を出すことで、技術力と提案力の両面で評価を獲得。 1. プロトタイプ開発で得られた知見を踏まえ、今後の機能拡張や他業務への横展開も見据えた設計・実装ルールを整理し、チーム内の標準化に繋がるベースを提供。 # 使用技術・構成要素 - Python 3.10 / Django 3, 4 - JavaScript / jQuery - SQL Server 2019 - Azure App Service - TortoiseGit / Visual Studio Code

# ユーザーのビジネス課題 - 銀行向け次期システム開発において、長年運用されてきた既存システムの仕様を正確に把握しつつ、新フレームワーク（Spring Boot + Vue）への置き換えを期限内に完了させる必要があった。 - 既存システムはドキュメント不足かつ独自フレームワークで構成されており、新規参画メンバーが仕様を理解するまでに時間がかかり、開発生産性と品質に影響が出ていた。 # 取り組み方針・思考プロセス - まずは自分自身が既存システムの構造と独自フレームワークの流儀をソースコードから徹底的に解析し、「どこを見れば何が分かるか」を早期に把握することを目標に設定。 - 解析結果を個人の暗黙知にせず、資料化してチームに共有することで、「新しく入った人でも短期間でキャッチアップできる状態」を作る方針を取った。 - 次期システムで新規採用された Vue についても、まず自分が一通り触って動かしながら理解を深め、他メンバーのデバッグ相談に応じられる状態を作ることで、チーム全体の開発停滞を防ぐことを意識した。 # 担当内容・出したバリュー 1. 基本設計フェーズ途中から参画し、詳細設計〜UT〜IT を主担当として実施。人手が足りない局面では基本設計レビューや補助も担当し、上流〜下流を一貫してカバー。 1. 配属先独自フレームワークの使い方をソースから解析し、参画から約 1 ヵ月で既存システム仕様の 8 割を把握。顧客リーダーから高い評価を受け、「チームメンバーのサポーター役」に抜擢された。 1. 解析内容を資料にまとめてチーム内に共有し、新規参画メンバーがシステムの読み方を理解しやすいよう整理。結果として、問い合わせ対応や説明コストを削減し、チーム全体のキャッチアップ速度を底上げした。 1. Vue（未経験技術）についても自らキャッチアップし、Java / Vue / JavaScript のソースや Git / Maven / Spring Boot / VSCode / Eclipse / npm / ブラウザ devtools を組み合わせたデバッグ支援を実施。デバッグ依頼に随時対応することで、開発遅延の抑制に貢献した。 1. 特に難度の高い機能で前任者が開発に失敗し制御不能になっていた箇所について、再開発担当として抜擢。大量のスパゲッティ SQL を棚卸しして重複クエリの統合や分割を行い、Web フレームワークの流儀に合わせて「SQL 直更新」から「Java 経由で更新する形」へ改修することで、可読性と保守性を大幅に改善した。 1. 上記の改修と並行して設計書の再作成も行い、「ソースと設計が同期している状態」を回復させたことで、以後の機能追加・障害対応を行いやすい基盤を整えた。 # メンバー育成 1. プロジェクト期間中、配属された客先の新人が開発についていけず精神的に不調となり、一度 2 ヵ月ほど休業する状況が発生した。 1. 復帰後、担当機能を通じて関わる機会を得たため、自発的に育成を申し出て 1on1 での伴走を開始。 1. まず理解度を確認したところ、Java の文法は理解できているものの、Web フレームワークの流れやファイル間のつながりをイメージできていないことが判明。 1. そこで、彼女が担当している 1 機能を題材に、「画面からどのクラス・設定ファイルを経由して処理が流れるか」を、自分で資料に書き起こしてもらいながら解説するスタイルを採用。 1. 資料化の仕方もレクチャーし、「解析に役立つメモの取り方」自体を身につけてもらうよう工夫した。 1. 以降は、質問があった際にすぐ答えを渡すのではなく、「どの資料・どのソースを見ればヒントがあるか」を伝える形でサポート。自力で辿り着けなかった場合のみ答えを示し、聞き癖がつかないように意識した。 1. 約 4 ヵ月後には 1 機能の改修を自力で完遂できるレベルに到達し、朝会で成果を嬉しそうに報告する姿が見られるまでに成長。 1. 新人が自走できる状態になったことを確認し、育成フェーズを完了した。 # 使用技術・構成要素 - Java 8 / 11（Spring Boot ベース独自フレームワーク） - Vue 2 / JavaScript - SQL（PostgreSQL） - Git / GitLab / SVN / Sourcetree - Jenkins - Eclipse / Visual Studio Code / Chrome devtools

# ユーザーのビジネス課題 - 医療系を含む保険システムにおいて、マイナンバー対応や各種制度改正に継続的に追従しつつ、老朽化した給付システムのトラブル多発を解消する必要があった。 - 長年運用されてきたメインフレーム COBOL システムは、ドキュメント不足と複雑なロジックによりブラックボックス化しており、障害時の原因特定や影響範囲の把握に大きな時間がかかっていた。 # 取り組み方針・思考プロセス - 制度改正・マイナンバー対応などの大型案件では、まずユーザー部門と業務フローを丁寧にすり合わせ、「既存運用を崩さずにシステム側で吸収すべき部分」と「業務プロセスとして見直すべき部分」を整理する方針を取った。 - 老朽化した給付システムについては、単発のバグ修正ではなく、「入力チェックロジックと設計情報を一度棚卸し・整理し直すことで、以後のトラブルを根本から減らす」ことをゴールに設定した。 - ユーザーの手作業事務でトラブルが多発していた部分は、作業頻度・エラー内容・担当者スキルをヒアリングし、「どこまでをシステム化すれば最もコストパフォーマンスが高いか」を意識して自動化案を検討した。 # 担当内容・出したバリュー 1. 保険システムの開発・保守リーダー／テックリードとして、マイナンバー対応や制度改正対応におけるユーザーとの折衝、要件定義、基本設計、ST、リリースを担当。 1. 詳細設計〜IT を外部ベンダーへ委託する場合は、スケジュール管理・タスク管理・問い合わせ対応を通じてプロジェクト全体を推進した。 1. 担当業務（保険契約、給付、送付書類作成、会計業務）について、業務部門とのやり取りを通じてドメイン知識を深く習得。システム構造も含めて部署内で最も理解しているポジションとなり、エンドユーザーや客先からシステム改修の相談を受けた際は「第一人者」として解決策を提示し、高い信頼を獲得した。 1. 老朽化によりトラブルが多発していた医療系給付システムでは、入力チェック（単項目／関連チェック／マスター整合性）の順序や抜け漏れを棚卸しし、チェックロジックを整理・統一。設計書とソースが乖離していた点も合わせて整備し直すことで、退任まで約 4 年間、トラブル発生ゼロを実現した。 1. ユーザー部門の手作業事務で頻発していたエラーについて、ヒアリングを基に「すべてを自動補正する」のではなく、「エラーデータをシステム側で分離してリスト出力し、既存画面で補正する」方式を提案・実装。これにより、週 6 時間かかっていた手作業を約 10 分まで削減し、手補正ミス由来のトラブルを解消した。 1. 開発部門の日次作業についても VBA マクロを作成し、作業時間を 15 分から 2 分に短縮。 1. 担当システムの概要資料や開発者向けの便利情報をまとめた資料を作成し、部署全体の情報共有と保守作業の効率化に貢献した。 # 使用技術・構成要素 - 富士通系汎用機 - COBOL / VBA / NDB（DURL & FormHelper） - 各種バッチ／オンライン処理（保険契約・会計・給付システム） - 要件定義、基本設計、詳細設計、コーディング、UT、IT、ST、導入

# ユーザーのビジネス課題 - 自然災害共済など、新商品の立ち上げに伴う保険契約・会計システムへの新規機能追加を、限られた期間内で確実にリリースする必要があった。 - 併せて、既存の保険基幹システムについて、制度変更への継続的な対応や日々の保守・運用を通じて、運用トラブルを最小限に抑えつつ安定稼働を維持することが求められていた。 - これらは、長年運用されロジックが複雑化した富士通系汎用機 COBOL システム上で実現しなければならず、影響範囲の把握と品質確保が大きな課題となっていた。 # 取り組み方針・思考プロセス - 配属から 2 ヵ月で大型案件（自然災害共済など）の新商品開発担当に抜擢され、まずは担当システムの全体像とバッチ処理の役割を把握することを優先した。 - 担当システムはバッチ処理の根幹部分であり、ソース解析と業務理解は困難を極めたが、地道にソースを解析し、分かったことを資料に落とし込むことを繰り返した。 - ユーザー部門との折衝では、契約・会計それぞれの業務フローを丁寧にヒアリングし、「現行運用をどこまで維持しつつ、システム側で吸収するか」を明確にしながら要件定義・基本設計を行った。 - 詳細設計〜IT を外部ベンダーに委託する体制だったため、「ベンダーが迷わない仕様」と「後から読んでも分かる設計」を意識して成果物を作成し、スケジュール／品質の両面でコントロールしやすい状態を作ることを重視した。 # 担当内容・出したバリュー 1. 保険システムの開発・保守にリーダー／テックリードとして参画し、新商品（自然災害共済など）の要件定義、基本設計、ST、リリースを担当。バックエンド基幹処理に加え、途中からフロント部分の設計も任されるようになり、システム全体をまたいだ設計・調整を行った。 1. 根幹となるバッチ処理の解析を地道に行い資料にまとめ続け、3か月で解析および設計書の整備を完了。 1. バッチ処理担当ではあるものの、オンライン側とも密接に結びついているためオンライン側の処理についても理解を深めながら進めた。結果、６か月後にはバッチ処理とオンライン側に精通した人員となり、プロジェクトの中核人員として貢献。 1. 詳細設計〜IT は外部ベンダーへ委託されていたため、ベンダーのスケジュール管理・タスク管理・問い合わせ対応を行い、仕様の意図を補足しながらプロジェクトをスムーズに推進。これにより、期日までに大きなトラブルなく新商品リリースを完遂した。 1. 担当業務（保険契約・会計業務）についてドメイン知識を深く習得し、システム構造も含めて部署内で最も理解している人材として位置付けられた。契約や会計に関するトラブル発生時には、ユーザー・客先から真っ先に相談が来る「トラブル解決の第一人者」として、原因分析と対処方針の提示を行った。 1. ユーザーとの折衝を通じて業務とシステム双方の観点を持ちながら仕様を調整した結果、ユーザーからの信頼を獲得し、一度別案件に異動した後も、顧客側マネージャーの強い要望により再契約・再アサイン（2013年）されるなど、高い評価を受けた。 # 使用技術・構成要素 - 富士通系汎用機 - COBOL / VBA / NDB - 保険契約・会計システム（バッチ／オンライン） - 要件定義、基本設計、詳細設計、コーディング、UT、IT、ST、導入