ID:78020さん

# 目的 - 証券会社のトレーダーに向けて、社内の100以上あるシステムから、P/L、ポジション情報を集約する。 # 背景 - EOLを迎えるシステムの刷新。 - Pythonで作成された、既存のシステムをJavaで置き換える - OJT期間として、ノーロードで参画 # 規模感、チーム構成、担当した役割 - 15人程度のプロジェクト - バッチチームを担当(画面チーム、バッチチーム、運用設計チームに別れた) # 使用技術や開発環境等 - AWS - Batch - ECS - CloudWatch - StepFunctions - EventBridge - ElastiCache - SNS - SQS - EC2 - Lambda - S3 - RDS - 開発環境 - IntellijIDEA - VisualStudioCode - SQLWorkbench - Docker - Redmine - GitLab - DBUnit # 自身が担当した範囲 ## バッチ実装 - 技術セット - Java - SpingBoot - Mybatis - JUnit - DBUnit - AWS ElastiCache - AWS SNS - AWS SQS - 概要 - 証券会社の営業時間外に営業時間中に約定されたポジションの処理（P/L･リスク等を算出）を行うバッチ１５本のコーディング･テストを行った。 他のシステムから外貨や金利情報を取得する処理が必要で、他システムではPostgreSQLの他に、Sybaseなどの他のRDBMSを使う必要があり認知負荷が高かった。 - システム内部DBも取り扱い商品分のPL･リスク情報などが記録されており、そこからデータを更新するためクエリが複雑で複数の結合や副問い合わせなどが複数必要であった。 - 課題 - 設計書･現行ソースコードの品質が低いこと - 品質の低い現行ソースコード（if文のネストが10以上存在する、コメントが少ない、業務不理解によるバグが埋め込まれた実装）からリバースされた設計書に基づき実装を行ったため認知負荷が非常に高かった。 - 課題への向き合い方 - 現行ソースコード(Python)をJavaに書き換えるということを考えるだけでなく、そのコードを通して、業務的に何をやっているのかを理解するように努めた。 - 例)部署Aのポジションを0にして、部署Bのポジションを100にする。→ポジションの移転が行われたのだと理解する。 - 社内で開催されている業務知識勉強会に参加するとともに、発表者となって業務理解をより深めた。 ## 内部結合テスト - 技術セット - Excel (VBA) - AWS CloudWatch - AWS Lambda - AWS Batch - 概要 - AWS Lambda上で営業時間中に入る約定データを処理するシステムの内部結合テストを行った。 - テストを行う前にDBのテーブルを特定の条件下に置く必要があった。 - １テーブルあたりのカラム数が30〜50程度あり、それが1つのテストで10テーブル程検証が必要だった。 - 課題 - 証跡の残し方 - １ケースのテストで、証跡を残すために、10個ほどのクエリが必要だった。 - テーブル名が異なるだけで、条件が同じであるなど単純な作業が発生していた。 - 課題の向き合い方 - VBAを使った効率化 - テーブルに応じて、VBAでクエリを自動生成して証跡を残せるようにした。 - テンプレートの作成 - 他人が同じように実行できるように、自分が実行したVBAをテンプレート化し他人も同じように作業できるようにした。 ## システムテスト - 技術セット - Excel (VBA) - AWS Cloud Watch - AWS CLI - AWS Batch - 概要 - シナリオテストを担当した。システム時間を１時間ごとに区切り、バッチの実行を行った。 - 課題 - 親子関係のあるバッチや前後関係のあるバッチがあり、手動で実施すると事故が発生する可能性があった。 - StepFunctionsやEventBridgeはクライアント側作業があるためテスト時に利用できなかった。 - 関連企業とAWS環境を共有しているため、利用申請から許可までに通常より時間が大幅にかかる。 - 課題の向き合い方 - 事故防止のため、VBAで実行順序を制御するスクリプトと、前後関係を制御するスクリプトを組み込んだ。 ## リリース - 技術セット - AWS CLI (EC2) - 概要 - 本番環境に、アプリを構築すること。 - CloudFormationはクライントの許可が降りず利用できない。 - 課題 - クライアント側の本番ルームでしか作業できず作業時間も限られており、ミスが許されない環境だったため、手順書にあいまいさを残さないことが必要だった。 - 課題の向き合い方 - 手順書にあいまいさを残さないために、マネージメントコンソールで作業を行うのではなく、CLIで環境構築を行うようにした。 - また、相当数のLambdaやBatchがあったため、VBAを利用してコマンドを自動生成できるようにした。

# 目的 - キャリアショップと顧客が利用するシステムの統合をすることにより、顧客･ショップ店員の利便性を向上することが目的 # 背景 - プライムベンダーの開発が大幅に遅延し、携帯キャリア様が別のベンダーに依頼をし弊社が開発に携わることになった。 # 規模感、チーム構成、担当した役割 - 300人程度のプロジェクト - バックエンドの開発 # 使用技術や開発環境等 - 使用技術 - Nest.js - JUnit - SpringBoot - OpenAPI - MyBatis - 開発環境 - VisualStudioCode - Eclipse - DBeaver - Amazon Workspaces - Miro - Adobe XD - GitHub - Jira - Confluence # 自身が担当した範囲 ## バックエンド開発 - 技術セット - SpringBoot - MyBatis - GitHub - 概要 - フロントエンド→BFFから渡ってきたデータを社内システムへ流すバックエンドシステムの開発。 - 6600万件以上を扱う顧客管理システム、商品情報システム等との接続を行いBFF･フロントエンドへ返す。 - 課題 - ベンダーが１０数社入っており、設計･実装･テストをするベンダーが異なるため認知負荷が高かった。 - 設計書に取得項目がどのシステムから取ってくるかが書いていなかった。 - iPhone等のApple製の機種が別システムのDBに入っていること。 - 同キャリアでも別の格安ブランドの契約かどうかを判別する方法。 - 税込み価格と税抜き価格でそれぞれのDBで入っている値がことなること等。 - 課題の向き合い方 - 設計書を精緻化しないで無理矢理次の工程へ進めた場合、バグの検出が困難になると考えた。 - 社内の同じチームの先輩とも相談し、設計書を書いたベンダーとデイリーミーティングを行い、密に連携を取りながら認識齟齬の無いようにすすめた。 ## フロントエンド開発 - 技術セット - Vue.js - Nest.js - TypeScript - Pinia - GitHub - Adobe XD - Miro - 概要 - デザイナーが作成した、Adobe XDのワイヤーフレームを元にVue.jsでBFFとの通信をTypeScriptで実装した。 - Vue.jsによるSPAでの実装 - 課題 - 契約/購入の最終確認画面で、これまでにカートに入れた商品や契約等をまとめて表示する必要があったが、それまでの商品画面や契約画面で、Piniaに保存されるべき情報が保存されているのかが明確化されていなかった。 - 課題との向き合い方 - どの画面でどの情報を保存しておく必要があるのかをリスト化して、各ベンダーにまとめてもらい、不足している場合はどの画面でいれるべきかを整理した。

# 目的 - 社内に生成AIを導入するにあたっての実証実験をすることが目的 # 背景 - 社内に生成AIを導入したいが、社内のニーズがわからないため事前に検証したい # 規模感、チーム構成、担当した役割 - 5人程度のプロジェクト - 画面の作成 # 使用技術や開発環境等 - 使用技術 - React - Typescript - Python - Azure - OpenAI - AI Search - EntraID - App Service - CosmosDB - 開発環境 - VisualStudioCode # 取り組みんだ課題 ## どんな課題だったのか - 開発期間の短い中（1ヶ月間）、追加画面が欲しい - 実証実験ではあるが、クライアントの要望で追加の画面が欲しいと言われた。 - もともとOSSの画面を利用する想定だったが、要望された画面がなかったため新たに開発が必要だった。 - 設計書などは特に用意されていなかった。 ## 技術的なアプローチや工夫した点 - 開発期間の短縮 - 実証実験段階のため、クライアントの要件を満たしつつ設計やワイヤーフレームは省略した。 - GitHub Copilotの導入を行い、生成AIを利用した開発を行った。 #取組の成果 - 追加要望を取り込んだ上で、クライアントに納品することができた。

# プロジェクト概要 ## 目的 - ブロックチェーンを利用したデジタル証券プラットフォームの開発 ## 背景 - 新規口座件数増加による社内システムとブロックチェーンシステム間のマニュアル業務を自動化するためのプロジェクト ## 規模感･チーム構成･担当した役割 - 10人程度のプロジェクトで、画面･バッチの開発を行うプロジェクトであった。 - 自身は画面設計(レイアウト制作、フロントエンド、バックエンド設計）･開発（フロントエンド、バックエンド）･インフラ構築を行った ## 使用技術や開発環境等 - クラウド - AWS - ECS - S3 - Lambda - EventBridge - CloudWatch - SNS - EC2 - CloudFormation - 言語(フレームワーク) - Python - Django - Vue.js - TypeScript - 認証基盤 - LDAP - 開発環境 - VisualStudioCode - TerraTerm - Docker # 自身が担当した範囲 ## 基本設計（画面設計） - 概要 - 要件定義からワイヤーフレームを制作し、動作やアクションの定義を行った - 課題 - デザイナーが不在で、ワイヤーフレームを作成するツールの利用も不可だった。 - 課題の向き合い方 - 対顧客向けの社内システムの設計標準に従って、UI設計をしHTMLでワイヤーフレームを制作した。 ## 詳細設計 - 概要 - １週間という短い時間の中で４画面の詳細設計を行う必要があった。 - 課題 - 期限がとにかく短かかった。 - 課題の向き合い方 - 優先度付けをクライアントと行った。 - ユーザ（クライアント本社事務部）が使う画面と、IT部門が使う画面で優先度付けを行い、IT部門側が使う画面は劣後させる形で開発を止めない形を取った。 ## 開発 - 概要 - 画面開発と社内システムからデータを取得するBFFを開発する - 課題 - 人員交代が頻繁に発生し、業務の引き継ぎを何度も行わなくてはならなかったこと - 課題の向き合い方 - オンボーディングの資料を整理し、クライアント特有の業務の内容や開発環境整備等をスムーズに行えるようにした。 ## 結合テスト - 概要 - 開発した画面のテストを行う - 課題 - 画面担当者の正常バイアスがかかっており、バグ検出に支障を来していた。 - 課題の向き合い方 - 状況を速やかに上長に報告したうえで、開発者がテスト実施者と同一にならないようにした。 ## 環境構築 - 概要 - CloudFormationを利用して、手動で構築した開発環境を本番環境で自動で構築できるようにする - 課題 - クライアント側がAWSの作業を他ベンダーに委託しているため、通常よりも過大な工数を必要とした。 - SNSトピック作成に8営業日かかる等 - 課題の向き合い方 - 申請が必要な作業は短縮が不可能なため、CloudFormationで可能な限り自動化を行うようにした。 # 取り組んだ課題 ## どんな課題だったのか - 認証基盤の選定 - 当初要件では画面側機能はクライアントのIT部門しか使わないものだった - しかし、クライアントのバック部門（本社事務社員）からも利用したいとの要望が出された - そのため、全社認証基盤を利用する必要があった - 全社ではLDAP認証基盤、SSOによる認証基盤の２つがあった。 ## 技術的なアプローチ - 当初は弊社で導入実績のあるSSOによる認証を検討していたが、クライアント側の作業に6人月かかるとのことだったので、LDAP認証を利用した。 # 取り組みの成果 - LDAP認証による画面認証を行い、設計〜開発工程までスケジュール通りにすすめることができた。