ID:83689さん

## 品質管理システム テスト対応 ### 期間 2023年6月〜2023年8月(3か月) ### チーム情報 - テスト仕様書作成: 現場未配属の新入社員7名で分担 - 開発チーム: 5〜8名程度(詳細不明) ### 期間の補足 3か月のうち前半1.5か月でテスト対応を実施。 後半1.5か月はテスト案件がなく、次の配属先(ドキュメント管理システム案件)に向けて Angularの自主学習(チュートリアル、簡単なAPI連携の練習)を実施した。 --- ### 開発・実装内容A｜テスト仕様書作成 【概要】 品質管理システムのテスト仕様書作成 【どのような機能の開発・実装か】 既存システムの仕様書を基に、テスト項目を作成 【課題】 既存仕様書をそのまま引用する形での作成となり、独自の試験観点の追加は実施していない 【工夫したこと】 仕様書の内容を網羅的にテスト仕様書へ反映 【成果】 テスト仕様書の作成完了 【使用技術】 特になし --- ### 開発・実装内容B｜JavaScript表示バグの修正 【概要】 テスト実施中に発見した画面表示の不具合を修正 【どのような機能の開発・実装か】 テスト実施中に発見したJavaScript側の表示崩れを修正 【課題】 JS側の表示崩れ(詳細不明) 【工夫したこと】 テスト実施中に能動的に不具合を発見し修正対応 【成果】 表示バグの解消 【使用技術】 JavaScript

### 期間 2023年9月中旬〜2024年3月末(約6.5か月) ### チーム情報 - プロジェクト関係者(システム連絡用チャット参加者): 約30名(変動あり) - 開発体制: チケット単位で各メンバーが個別に担当、アジャイル開発 - 担当工程: 要件定義以降の設計、実装、テスト(フロントエンド〜バックエンドをフルスタックで担当) - 使用技術: C#(ASP.NET)、TypeScript(Angular)、PostgreSQL、Windows、VSCode、VisualStudio、A5M2、TortoiseGit、AzureDevOps、GitBucket --- ### 開発・実装内容A｜検索結果の件数表示追加・検索項目追加 【概要】 検索結果一覧への件数表示と、検索機能への新規項目追加 【どのような機能の開発・実装か】 検索結果一覧に件数を表示する機能の追加と、既存の検索機能への新規検索項目の追加 【課題】 当時は既存コードの読解に慣れていない段階であり、 大規模なコードベースの中から修正対象箇所を特定することが難しかった 【工夫したこと】 既存コードを丁寧に読み解き、修正対象箇所を特定した上で実装を進めた 【成果】 数日で実装を完了。実務の中で既存コードベースの読解スキルを習得するきっかけとなった 【使用技術】 C#(ASP.NET)、TypeScript(Angular)、PostgreSQL --- ### 開発・実装内容B｜マスタDBとのデータ結合 【概要】 これまで連携していなかったマスタDBのデータを結合して表示・利用できるようにする機能 【どのような機能の開発・実装か】 新規マスタDBのモデル定義を作成し、既存処理内にデータ結合ロジックを組み込む 【課題】 新規連携のためモデル定義が存在せず、 また既存処理のどこに結合ロジックを組み込むべきか判断が必要だった 【工夫したこと】 既存のモデル定義やコードスタイルを踏襲しながら新規モデル定義を作成。 結合処理はSQLのJOINではなくC#側で行う既存の設計方針に従い、 既存処理への影響範囲を考慮した上で組み込み位置を選定した 【成果】 新規マスタDBとの連携を実現し、既存システムへのデータ結合表示が可能になった 【使用技術】 C#(ASP.NET)、PostgreSQL --- ### 開発・実装内容C｜承認ボールを持つ一般ユーザーへの管理者機能の一部展開 【概要】 従来管理者のみに提供していた機能の一部を、承認ボールを持つ一般ユーザーへ展開 【どのような機能の開発・実装か】 承認ボールを持つ一般ユーザーを判定し、対象ユーザーのみ管理者機能の一部を利用できるようにする機能拡張 【課題】 権限制御を誤ると、対象外の一般ユーザーにまで管理者機能が展開されてしまうリスクがあった 【工夫したこと】 承認ルートのプロパティから「承認者が自分であること」かつ 「現在承認ボールを自分が持っているか」という2つの条件を組み合わせて 対象ユーザーを判定するロジックを実装。 バックエンド(C#)側での判定ロジックとフロントエンド(Angular)側での表示制御の 両方で対応し、意図しないユーザーへの機能展開を防いだ 【成果】 承認ボールを持つ一般ユーザーのみに対象機能を安全に展開することができた 【使用技術】 C#(ASP.NET)、TypeScript(Angular) --- ### 開発・実装内容D｜テンプレート展開時のデフォルト設定機能 【概要】 ベーステンプレート展開時に、責任者・管理者をデフォルトで設定する機能 【どのような機能の開発・実装か】 テンプレート展開時に責任者・管理者が自動でデフォルト設定される機能を追加 【課題】 特になし 【工夫したこと】 特になし 【成果】 テンプレート展開時のデフォルト設定機能を実装し、ユーザーの手動設定の手間を削減 【使用技術】 C#(ASP.NET)、TypeScript(Angular)

### 期間 2024年4月〜現在継続中 ### チーム情報 - 基本メンバー: 先方4名+自社3名(計7名) - 担当期間前半: 別ベンダー3名も在籍(引き継ぎ完了後に撤退) - 使用技術: AWS(Glue, Lambda, S3, DMS、Neptune、CloudWatch、SecretManager、EventBridge)、Azure(Synapse、AppService、ストレージアカウント、仮想マシン)、Snowflake、Python、TypeScript、Angular、AzureDevOps、C#（ASP.NET）、Python - 並行稼働: 2026年1月〜3月末は購買関連システム開発とも並行して稼働 --- ### 開発・実装内容A｜既存データパイプライン・検索システムの運用保守 【概要】 別ベンダー構築のデータパイプライン・検索システムの運用保守 【どのような機能の開発・実装か】 別ベンダー構築のCDM変換パイプライン、CDM検索システム、グラフDB取り込みバッチの運用保守。 CDMのグラフDB取り込みから検索システムまで、データ取り込み層〜検索UI層を 一貫して保守(フルスタックで対応) 【課題】 既存ソースコードがブラックボックス化しており、保守性に課題があった 【工夫したこと】 既存ソースを丁寧に読み解きながら保守対応を実施 【成果】 安定した運用保守を継続 【使用技術】 AWS、Azure、Snowflake、グラフDB --- ### 開発・実装内容B｜日次データ連携の高速化(DMS廃止・差分連携への置き換え) 【概要】 AWS DMSを用いた全件取り込み処理を廃止し、差分連携方式に刷新 【どのような機能の開発・実装か】 従来AWS DMSを用いて全件データをS3に出力しGlueで取り込んでいた処理を、 差分連携方式に置き換え。新規GlueジョブをPythonで構築し、 共有フォルダ→S3→Snowflakeの連携を実現 【課題】 データ量の増加に伴い全件取り込み処理が5〜10時間に達しており、 日次バッチとして運用上の負荷が大きくなっていた 【工夫したこと】 - データ提供元担当者と連携し、全件出力から差分データのみを 共有フォルダへ出力する形に変更を依頼 - 差分データを共有フォルダからS3へ転送し、Snowflakeへ取り込む 新規のGlueジョブ(Python)をゼロから構築 - 当時Pythonの実務経験がなかったため、前任者からの引き継ぎ期間中に 基礎構文のキャッチアップと既存Glueジョブのソースコード読解を並行して行い、 実装に必要な知識を習得 - ジョブの実行はGlueのトリガー機能を用いて日次スケジュールで自動化 【成果】 - DMSを完全に廃止し、処理時間を5〜10時間から20分弱まで短縮 - 未経験だったPythonでの開発スキルを実務の中で習得 【使用技術】 AWS Glue(Pythonジョブ、トリガー機能)、AWS S3、Snowflake、Python --- ### 開発・実装内容C｜AWS Glueジョブの新規構築(Snowflakeへのデータ格納・Parquet出力) 【概要】 CDM変換前データのSnowflakeへの格納とParquet出力処理の新規構築 【どのような機能の開発・実装か】 - CDM変換前データをSnowflakeへ格納する処理 - SnowflakeデータをParquet形式で出力し共有フォルダへ配置する処理 【課題】 引き継ぎ時点で要件チケットが作成されており、対応が必要だった (詳細な背景は前任者からの引き継ぎのため不明) 【工夫したこと】 PySparkベースのGlueジョブを新規構築。 データ処理ロジックをPythonジョブ側に持たせるのではなく、 大容量データ処理に適したSnowflakeのストアドプロシージャ側に実装し、 Glue側からはSnowflakeドライバー経由でストアドプロシージャを呼び出す構成とした 【成果】 CDM変換前データのSnowflakeへの格納、およびParquet出力・共有フォルダ配置の 一連の処理を実現し、後続のデータ活用の基盤を整えた 【使用技術】 AWS Glue(PySpark)、Snowflake(ストアドプロシージャ、Snowflakeドライバー)、Parquet --- ### 開発・実装内容D｜Azure Synapseパイプラインのメモリエラー対応 【概要】 並列実行によるSparkPoolのリソース競合が原因のメモリエラーを調査・解消 【どのような機能の開発・実装か】 並列実行時に発生していたメモリエラーの原因調査と、 スケジュール調整による直列実行化で暫定対応 【課題】 4つのパイプラインが1つのSparkPoolを共有しており、 並列実行時にメモリ不足が発生して処理が失敗するケースが続いていた 【工夫したこと】 - 朝のインシデント確認(エラー検知の自動通知メール)でメモリエラーを検知 - Synapse Studioのモニタリングログを確認し、同時間帯に4つのパイプラインが 稼働していることを特定 - AIアシスタント(Copilot)も活用しながらSparkPool共有による リソース競合という仮説を立てた - 各パイプラインの処理時間をテスト環境で実測し、 本番環境での完了時間を推測した上でスケジュール起動時刻をずらして直列実行化 - 運用開始後も実際の処理時間の実績を見ながらスケジュールを再調整し、 待機時間を最小化する形で最適化 【成果】 - メモリエラーの発生を解消 - 実行時間を約60%削減 - エラー発生率も低減し、安定運用につながった 【使用技術】 Azure Synapse Analytics(Synapse Studio、SparkPool、パイプライントリガー設定) --- ### 開発・実装内容E｜Glue・Lambdaのエラー検知・通知の自動化 【概要】 Glue・Lambdaのエラーをメトリクスで自動検知し、関係者へメール通知する仕組みを構築 【どのような機能の開発・実装か】 CloudWatch AlarmとSNSを組み合わせて、エラー発生時に 関係者へ自動でメール通知が届く仕組みを構築 【課題】 従来、各サービスのエラー発生は人力で監視しており、 ログを都度確認する必要があるなど運用負荷が高かった。 業務改善の一環として自動化が依頼された 【工夫したこと】 CloudWatch Alarmを用いて各サービスの失敗回数をメトリクスとして監視する仕組みを構築。 アラームが発生した際にSNS(Simple Notification Service)経由で 関係者へメール通知が届くよう設定した 【成果】 - エラー発生の検知を自動化し、人力での監視作業を削減 - エラーへの気づきが早まり、対応の初動を早めることができた 【使用技術】 AWS CloudWatch(Alarm、メトリクス監視)、AWS SNS --- ### 開発・実装内容F｜パブリックネットワーク非接続環境での外部ライブラリインストール対応 【概要】 ネットワーク制約のある環境でのGlueへの外部ライブラリ(pysmb)インストールを実現 【どのような機能の開発・実装か】 共有フォルダへのSMBプロトコルアクセスに必要なライブラリを、 ネットワーク制約のある環境のGlueランタイムにインストール 【課題】 - 共有フォルダへのアクセスにSMBプロトコルを使用する必要があったが、 AWS Glueの標準ライブラリにはSMBプロトコルを扱えるライブラリが含まれていなかった - 実行環境がパブリックネットワークに接続できない制約があったため、 通常のpipコマンドによるインストールができなかった 【工夫したこと】 - 使用するライブラリ(pysmb)の依存関係を調査し、必要なwhlファイルを個別に取得 - 取得したwhlファイルをS3に配置し、Glueジョブのパラメータ設定 (追加ライブラリのS3パス指定)を通じてランタイムへのインストールを実現 【成果】 ネットワーク制約のある環境でも外部ライブラリのインストールを実現し、 SMBプロトコル経由での共有フォルダアクセスが可能になった 【使用技術】 AWS Glue(パラメータ設定)、pysmb、AWS S3 --- ### 開発・実装内容G｜Snowflakeをデータソースとする新規検索システムの構築(技術検証) 【概要】 ユーザー要望を起点に、Snowflakeをデータソースとする新規検索システムを技術検証として構築 【どのような機能の開発・実装か】 既存CDMベース検索システムとは別に、 Snowflake上のデータを検索できる新規システムをテスト環境に構築 【課題】 既存検索システムはCDMをベースにしており、 ユーザーが検索したいSnowflake上のデータには対応していなかった 【工夫したこと】 既存のCDMベース検索システムの3層構成 (フロントエンド・バックエンド・データソース)を参考に、 Snowflakeをデータソースとする検索システムを新規構築。 Azure App Serviceへのデプロイまで対応した 【成果】 テスト環境へのリリースまで完遂し、Snowflakeをデータソースとした 検索機能の動作を確認した (その後、本番対応は行わない方針となりテスト環境での検証にとどまった) 【使用技術】 Snowflake、Azure App Service --- ### 開発・実装内容H｜既存ソースコードの設計書化(属人化解消・保守性向上) 【概要】 ブラックボックス化していた既存ソースコードを解析し、Markdown形式の設計書として文書化 【どのような機能の開発・実装か】 - Synapseノートブックの処理フロー20件以上を文書化 - グラフDB取り込みバッチの処理フローを文書化 - 成果物の構成: 使用技術・改訂履歴・概要・詳細フロー 【課題】 - 設計書が存在せず、対応できるメンバーが属人化していた - ソースコードにコメントがなく可読性が低かった - 処理の挙動を制御する設定ファイルの仕様がドキュメント化されていなかった 【工夫したこと】 - 作業に余裕が生じたタイミングで上記を課題と捉え、 別ベンダーの上司に相談の上、自発的に先方へ設計書作成を提案 - 設定ファイルの値によって処理が動的に変わる構造のため 処理フローの追跡が困難だったが、CopilotにソースコードをインプットしてAIに たたき台を生成させ、実際のソースと比較・差分を修正する形で 効率的に文書化を進めた 【成果】 - Synapseノートブックの処理フロー20件以上、 グラフDB取り込みバッチの処理フローを文書化し、設計書のない状態を解消 - 属人化の解消と、新規メンバーや他ベンダーが参照できる保守ドキュメントの整備につながった 【使用技術】 Azure Synapse Analytics、Markdown、GitHub Copilot

## 購買関連システム開発 ### 期間 2026年1月〜2026年3月末(3か月、データ基盤と並行スポット対応) ### チーム情報 - XLSX一括登録バッチ: 3名 - 設計担当者が途中辞任 - その後自社上司がPM的に要件整理・テスト支援 - サポートメンバー1名が途中参加 - リリース後の運用: 別メンバー2名へ引き継ぎ - 使用技術: C#(ASP.NET)、TypeScript(Angular) - 並行稼働: 担当期間中、プロジェクト4(データ基盤案件)とも並行して稼働 ### 稼働体制に関する補足 データ基盤側で先方の工数確保が困難な期間が発生したため、 該当期間はデータ基盤・自社購買システムそれぞれに0.5人月ずつ稼働する形でスポット対応した。 当初の見積を上回り、該当期間2か月で計110時間ほどの時間外対応が発生した。 なお、この2か月のうち1か月(実質稼働2週間)は、 別の第三案件(炎上案件)の結合テスト支援にも従事した。 --- ### 開発・実装内容A｜XLSX商品一括登録バッチの新規開発 【概要】 XLSXファイルから商品情報を一括で登録するバッチ処理の新規開発 【どのような機能の開発・実装か】 XLSXファイルを読み込み、商品情報をDBへ一括登録するバッチ処理を新規開発。 実装からリリース・初回稼働確認までをほぼ単独で担当 【課題】 - 設計担当者が途中で辞任し、引き継いだ基本設計と詳細設計の間に不整合があり、 実装段階で都度判断に迷う場面があった - XLSXファイルを扱うC#ライブラリ(NPOI)、ログ出力ライブラリ(Log4Net)、 ASP.NETプロジェクトの初期設定(Program.cs、Startup.cs)が未経験だったため、 キャッチアップしながらの実装となった 【工夫したこと】 - 仕様の不整合箇所は上司(PM役)と都度確認しながら実装を進め、リリースまで完遂 - 未経験のNPOIはドキュメントや既存コードを参照しながらXLSXの読み込み処理を実装 - Log4NetやProgram.cs・Startup.csの設定も自主的にキャッチアップして対応 - 想定登録件数の2倍・5倍・10倍のデータ量で負荷検証を実施し、安定動作を確認 - エラー発生時も処理を停止せず、正常データのみ登録を継続し エラー内容をログファイルに出力する方式を採用(要件による) 【成果】 未経験ライブラリを習得しながら、実装からリリース・初回稼働確認までをほぼ単独で完遂 【使用技術】 C#(ASP.NET)、NPOI(XLSXファイル操作)、Log4Net(ログ出力) --- ### 開発・実装内容B｜既存購買システムのUI不具合・機能改善対応(計5件) 【概要】 既存購買システムのUI不具合修正および機能改善を複数件対応 【どのような機能の開発・実装か】 - AngularのUI値フィルター非表示の不具合対応 - 3商品カテゴリの同時購入制御 - 対象カテゴリの商品受け取り場所固定対応 - 既存コンボボックスのオートコンプリート化 【課題】 カテゴリ分割やオートコンプリート化など、 要望ごとに既存UIロジックへの影響範囲の見極めが必要だった 【工夫したこと】 ■ AngularのUI値フィルター非表示の不具合対応 既存コードを読み解き、フィルター値が表示されない原因を特定して修正 ■ 3商品カテゴリの同時購入制御 カートに商品を追加するタイミングでカート内の既存商品とカテゴリを比較し、 異なるカテゴリの商品を追加しようとした際にエラー警告を表示する バリデーション処理をフロントエンド(Angular)側に実装。 バックエンド(C#)側では同時購入不可のカテゴリ一覧を取得するAPIの新規作成と DB周りの実装も担当した ■ 対象カテゴリの商品受け取り場所固定対応 対象カテゴリ選択時に受け取り場所を固定する制御を実装 ■ 既存コンボボックスのオートコンプリート化 ag-autocompleteを使用してコンボボックスをオートコンプリート対応に置き換え。 入力値に対するフィルタリング処理を新規実装し、 部分一致検索および大文字小文字を区別しない検索(case-insensitive)にも対応した 【成果】 UI不具合の解消と、ユーザビリティを考慮した機能改善を複数件完遂 【使用技術】 TypeScript(Angular)、C#(ASP.NET)、PostgreSQL、ag-autocomplete --- # スポット対応 ## 第三案件(炎上案件)の結合テスト支援 ### 期間 2026年(自社購買システム対応期間内の1か月) ### チーム情報 データ基盤・自社購買システム対応と並行する形でスポット参加 --- ### 業務内容｜結合テスト支援 【概要】 別案件(炎上案件)における結合テスト支援 【どのような機能の開発・実装か】 既存の仕様書をもとに、担当画面の結合テストを実施 【課題】 単体テストレベルの不具合が多数見つかる状況であり、品質状況に大きな課題があった 【工夫したこと】 結合テストを通じて品質状況を把握し、状況を踏まえて支援を終了(契約終了) 【成果】 品質上の問題を早期に把握し、適切な判断につなげた 【使用技術】 特になし