ID:60824さん

## チーム構成 - **テックリード**: 1 名（私） ### **背景と課題** * 本番環境で断続的に発生する **OutOfMemoryError（OOM）** の原因を特定するため、**JVMヒープダンプを取得して分析**を開始。 * `Dominators by Retained Size` による可視化の結果、**`mysql-connector-java` を介して作成された JDBC オブジェクトが大量のメモリを保持している**ことを確認。 * 接続リークなどを疑いスタックトレースを調査した結果、**金型部品メンテナンス推奨データ（特に修繕レコード）の異常な蓄積**が根本原因の可能性と判明。 ### **原因分析** * `TblMoldPartMaintenanceRecomendDetail` テーブルにおいて、**同一個体（mold + partInd）に対する `replaceOrRepair=2（修繕）` レコードが、バッチ実行のたびに重複登録されていた**。 * 「個体（moldPartInd）」は新たに導入された概念であり、従来の「rel（mold + part）」では `replaceOrRepair=1（交換）` のみが重複チェック対象だった。 * relデータでは重複があっても**最終的に削除して再挿入する**対応をしていたが、この方式は設計上不自然でコストも高い。 * 修繕データにおいては事後削除の処理もなく、**レコードが無限に蓄積され、結果としてOOMを引き起こしていた**。 ### **対応と成果（テックリードとしての取り組み）** * **設計方針を見直し、rel・個体ともに「事後削除」から「事前除外」へ統一**。 * JPQLの `NOT EXISTS` 条件から `replaceOrRepair=1` の限定を外し、**交換・修繕を問わず、既存レコードがあれば抽出しない仕様に修正**。 * **重複データを一括で削除するマイグレーションSQLを作成し、事前に検証環境で動作確認を実施**。 * 影響範囲・緊急度を判断し、**クリティカルな修正に絞って段階的なリリース方針を提案・実行**。 * 不要な検証データがバグのトリガーである可能性を指摘し、**顧客環境と開発環境の分離ルールの徹底を関係者に提言**。 * これらの対応により、**重複登録を完全に排除し、メモリ使用量の増加を防止。OOMは解消し、バッチ処理の安定性が大幅に向上**。 ### **工夫点** * **VisualVM による Dominator Tree 分析を通じて、単なる実装不備ではなく設計思想に踏み込んで問題を特定**。 * スタックトレースには現れない、**データ設計レベルの不備を疑い、コード・DB・ヒープの三側面から問題を横断的に調査**。 * JDBCドライバによるリソース消費に注目し、**インフラ依存の課題にも対応可能な調査スキルを発揮**。 * 品質が低く見えるコードにも、「なぜこのような構造か」を追究し、**対症療法でなく根本的な改善を実現**。 --- ### 成果の要約 **クリティカル障害を設計改善と運用是正により解消し、テックリードとしてプロジェクトの技術的安定を主導。 パフォーマンス・保守性・品質のバランスを最適化した再設計を実現した。** ---

## チーム構成 - **テックリード**: 1 名（私） #### 概要 「システムが実際に使用されているかを営業が把握できる仕組みが欲しい」との社長の発言を受け、**ファイル差分の継続的監視とアラート通知機能を即時提案・実装**。 業務会議中にシステム案を提示し、**同日中にバッチ処理含めたプロトタイプを構築**。 差分が一定期間小さい状態が続いた際にメールで通知し、**顧客離脱リスクの早期検知**を可能にした。 #### 担当業務 * 差分検知バッチ (`javax.batch`) の設計・実装 * 前回と今回の `.sql` ダンプファイルのサイズ差分を自動記録 * **増加量が小さいファイルのみを検出対象とするJPQLの設計（`NamedQuery`）** * 差分記録ログエンティティ（`DumpDiffLog`）の作成・DB登録 * アラート対象の閾値・期間を管理する設定エンティティ設計（`DumpMonitorConfig`） * JPAでの範囲抽出クエリにより、**「差分増加が小さい日数」が一定以上であればメール通知** * JavaMailによる社内通知メール送信（件名・本文に監視IDや統計情報を付加） #### 成果 * **属人的な利用状況の可視化が不要となり、営業や社内メンバーが能動的に動ける仕組みを提供** * 監視対象が使われていないことを**定量的に判断可能**になり、対応漏れや離脱を未然に防止 * シンプルなファイル差分ロジックながら、**日次監視・長期蓄積・通知連携の基盤となる再利用性の高い構成**に * **要件定義・設計・開発・運用までを1日以内に自走対応**し、スピード感と実行力を評価された

## チーム構成 - **テックリード**: 1 名（私） #### 概要 社内外のバグ報告を一元管理し、**報告精度の向上・初動対応時間の短縮・情報の属人化排除**を目的とした専用フォームを新規に設計・開発。 従来のメールベースのプロセスをWebフォーム＋自動課題登録の仕組みに刷新し、**ユーザー利便性と社内対応品質の両立を実現**。UI設計からAPI連携、説明資料作成、運用方針策定まで一貫して担当。 #### 担当業務 * バグ報告専用画面のUI設計・開発（React + MUI） * Backlog APIへのmultipart対応課題登録処理の実装 * 添付画像・ファイル（複数対応）のBase64変換～アップロード処理実装 * バリデーション（必須入力項目）の追加 * フォーム送信後の初期化・連続送信ロック制御の実装 * 自動登録される課題に「会社名・ユーザー名・使用中バージョン情報」を付加 * ステータスを件名に反映する運用ルール（「リリース済み」「処理中」等）の設計 * 操作説明マニュアル、リリースノート、顧客向け案内文の作成 * フロー全体の運用設計（顧客→Backlog→社内対応→完了）および説明資料の整備 #### 成果 * 顧客による報告件数が**増加（入力の敷居が下がったため）** * 社内対応の初動工数を**大幅に削減** * 属人化・転記ミスを排除し、**課題管理の正確性と透明性を向上** * リリース連携を含む運用設計まで一貫して対応し、**将来的な機能要望フォームにも展開可能な拡張性を確保** * **企画・設計・開発・説明・運用設計までを1人で完遂**し、社内での再利用モデルにも寄与

## チーム構成 - **テックリード**: 1 名（私） #### **背景** 従来のリリースノートは営業担当が個別に作成しており、フォーマットや記載内容が統一されていなかった。また、細かな機能追加や修正内容が適切に反映されず、情報の抜け漏れが発生していた。 #### **取り組み** * Gitログのバージョンタグ差分を自動で取得： ```sh git log V3.4.00.00..V3.5.00.00 --pretty=format:"- %s (%an)" ``` * コミットメッセージから課題IDを抽出し、Backlogで一括検索・CSV出力。 * GitログとBacklog課題CSVをChatGPTに入力し、リリースノートの草案を自動生成。 * 出力された草案の口語表現を人手で調整し、最終版を作成。 #### **成果** * **作成工数を1時間→10分に短縮**し、担当者の負荷を大幅に軽減。 * **ChatGPTによる構造化と要約精度が高く、上司から「有益」とのフィードバックを獲得**。生成したリリースノートは**即座に顧客説明に活用された**。 * **ドキュメント品質の標準化と属人性の排除を実現**し、再利用・展開しやすい仕組みを構築。

#### **背景と課題** * 運用中の業務アプリケーションにおいて、**断続的に OutOfMemoryError（OOM）が発生**する事象を検知。 * 予防的に取得していた平常時のヒープダンプと比較し、**`byte[]` オブジェクトの異常な蓄積と特定スレッドの増加**が見られた。 * スタックトレースを分析した結果、**認証処理におけるハッシュ生成ロジックがメモリ枯渇の引き金となっていることを特定**。 #### **原因の分析** * 認証処理内のストレッチング処理で、**非効率な文字列連結が繰り返されていたことにより、`String` オブジェクトが大量生成されていた**。 * 加えて、**認証トークンを使用しない自動データ送信クライアント（アップローダー）からの高頻度アクセス**が、GCの許容量を超えてメモリを圧迫していた。 #### **対応と成果** * **ハッシュ生成処理を `StringBuilder` や `byte[]` ベースにリファクタリング**し、オブジェクト生成数とメモリ消費を大幅に削減。 * 同時に、**当該クライアントの認証方式をトークンベースに変更し、アクセス頻度の見直しを依頼・調整**。 * 対応以降、**OOMは完全に解消し、安定稼働を継続**。 * さらに、**ヒープダンプ取得・比較による調査体制を標準化し、再発防止策としてドキュメント化・共有を実施**。 #### **工夫点** * JVMオプション `-XX:+HeapDumpOnOutOfMemoryError` を事前に有効化していたことで、**障害発生直後の状態を正確に分析可能に**。 * VisualVMとOQLによる詳細調査を通じて、**GCルートからのリファレンス保持状況を追跡し、根本原因の特定に成功**。 * **セキュリティ要件（ハッシュ強度）を満たしつつ、メモリ効率も考慮した設計変更**により、パフォーマンスと安定性の両立を実現。

## チーム構成 - **テックリード**: 1 名（私） ### **プロジェクトの背景** * 客先デモ用のローカル環境（VirtualBox上）にて、**特定APIで生産詳細画面がタブレットからアクセス時にエラーとなる不具合が報告された**。 * バックエンドでは例外は発生しておらず、**取得件数が0件であることが原因で、画面側の処理が想定外の挙動を起こしていることが判明**。 * クラウド上のデモ環境と同一データを使用しても問題が再現し、**データ起因の問題でないことを確認**。 * Viewに差分があり、一部欠損が見られたため調査したが、**該当のViewは本処理では使用されておらず、影響がないことを確認**。 * クエリ定義やコードに差異はなく、**ソース差分がない状態で動作に違いが出るため、環境依存の可能性を疑い調査を継続**。 * ロガーを大量に仕込み、クラウド環境とローカル環境で発行されるクエリやその結果を比較した結果、**JOIN FETCH句を使用したJPAクエリの挙動が異なっていることに気づいた**。 ### **成果** * **GlassFish 4.1では、JOIN FETCHで結合先エンティティのコレクションが空の場合に、親エンティティごと結果から除外されるという仕様があることを突き止めた**。 * この仕様はGlassFish 4.1.2（EclipseLink 2.6.1）では修正されており、**同一ソース・データで結果が変わる原因がバージョン差異にあると特定**。 * 仮想環境のGlassFishを4.1から4.1.2へアップグレードし、**問題が解消されたことを確認**。 * アップグレードに際しては、**設定ファイルの移行、パーミッション修正、systemdサービスの調整など複数の課題に対応**し、環境を再構築。 * **マイナーバージョン差異によってもORMの挙動が変わる可能性があることをチーム内に共有し、今後の調査・環境構築時のリスク管理に貢献**。

## チーム構成 - **テックリード**: 1 名（私） ### 背景・課題 * 社内外からの検索条件付きの問い合わせ対応が日常的に発生していたが、画面状態を再現する手段がなく、やり取りの手間が発生していた * クエリパラメータがURLに反映されない設計のため、画面遷移後に検索条件を手動で入力し直す必要があった * ユーザー体験を向上させるとともに、問い合わせ対応やデモ実施の効率化が急務となっていた ### 担当業務 * URLに検索条件をクエリパラメータとして付与・保持・復元する機能の共通化を企画・実装 * 既存の検索条件項目（部署、日付範囲、チェックボックス等）を動的にクエリ化／復元処理に変換する共通モジュールを作成 * JavaScriptにより画面初期表示時にクエリを解析・入力項目に復元するロジックを実装 * jQueryにより、検索ボタン押下時にURL書き換えを動的に行い、ブックマーク可能な構造に変更 * デモや運用操作の共有・保存性を意識したUI・UX改善を実施 * 汎用的な構造で他画面に横展開可能なコード構成にリファクタリング ### 成果 * 検索条件付きURLの生成が可能となり、ワンクリックで目的データへ到達可能に * 問い合わせ対応やデモ実施の効率が大幅に改善 * 画面状態のブックマーク保存により、業務の再現性・引き継ぎ性が向上 * 画面依存を排した実装により、他画面への導入も容易な設計を実現 * 従来の「URLで状態を共有できない仕様」の根本課題を解決し、業務全体のDX推進に貢献

### 背景・課題 * 各社ごとにAWS環境を分離して構築していたが、新規環境構築時に手順を忘れるケースが多く、**属人化が発生していた**。 * 手作業によるインフラ構築は、**ヒューマンエラーや作業漏れのリスク**が高く、**再現性のある構成管理が求められていた**。 ### 担当業務 * **AWS CloudFormationを活用し、インフラ構成のコード化と構築自動化を実現** * **既存の手順書をベースにテンプレート化し、構築パラメータを明確化** * **Terraformとの比較検討を実施し、以下の理由でCloudFormationを採用** * **マルチクラウド利用の予定がなく、構成が比較的単純だったため** * **CloudFormationの方がより手軽に扱え、既存メンバーにも習得コストが低かったため** ### 成果 * **新規環境の構築時間を大幅に短縮（手作業 → 自動化）** * **インフラ構成のコード化により、環境間の差分管理と再現性が向上** * **手順書の管理・更新作業を削減し、インフラ作業の属人化を解消**

## チーム構成 - **テックリード**: 1 名（私） ## プロジェクトの背景 - 既存コードの品質が低下し、新機能の追加が困難な状況に直面。 - プロジェクトでは単独で開発と設計を担当し、全体の品質向上に取り組む必要があった。 ## 課題と解決策 ### コード品質向上に対する取り組み - **課題**: 既存コードにバグが多発し、バグ修正を行うと新たなバグが発生するという悪循環に陥っていた。コードの保守性と可読性が低く、機能追加が難しい状況だった。 - **解決策**: コードのリファクタリングを提案し、以下の取り組みを実施。 - 標準的でない処理を行う場合には、意図がわかるようコメントを付けることで、他の開発者が理解しやすいコードを実現。 - メソッドを適切に分割し、コードの共通化を進めることで、保守性と再利用性を向上。 ### ユーザーフレンドリーな設計 - **課題**: 既存機能が作り手側の都合で設計されており、ユーザーが使いづらい状態であった。 - **解決策**: ユーザーの視点に立った設計に再構築し、ユーザーフレンドリーなインターフェースを実現。ユーザーからのフィードバックを取り入れ、使いやすさを大幅に改善。 ### 障害発生時の対応時間短縮化 - **課題**: Backlog の運用方針が明確でなく、障害発生時の原因特定に時間がかかっていた。 - **解決策**: 以下の取り組みを進め、障害対応の効率を向上。 - Backlog の運用方針を策定し、チーム全体での統一的な対応を実現。 - 運用マニュアルをドキュメント化し、新たなメンバーが迅速に対応できるようにした。 ## 成果 - **予定よりも大幅に早い開発進捗**: 当初のスケジュールを大幅に上回り、迅速な開発を実現。 - **単独での開発を成功**: 本来は4名の開発チームで対応する予定だったが、単独での開発を成功させ、リソースの効率的な活用を実現。 - **コードの共通化により開発速度の向上**: 重複した処理を削減し、コードの共通化を進めたことで、開発の効率が大幅に向上。

## チーム構成 - **プロダクトマネージャー (PdM)**: 1 名（主に指示・監督） - **開発者**: 1 名（私） ## プロジェクトの背景 - 1:1で管理していたデータを1:Nの関係に変更する。 - 別テーブルのカラムを適切な他テーブルへ移動する。 - 当該機能は主要機能と密接に関連しており、修正範囲が非常に広い。 - 以前、トランスファー機能（TF機能）の仕様漏れ対応と追加実装を行ったが、納期を優先したため、データベース構成を変更し、登録データの関係性をデータベース上で適切に表現する恒久対策は未実施だった。 - 修正の影響範囲が大きく、システム全体に影響を及ぼす可能性が高い。 - 既存のバグも多く、仕様とバグの区別が困難な状況。 ## 課題と解決策 ### 影響範囲の調査（画面・API） - **課題**: 修正に伴い影響を受けるAPIや画面が多岐にわたり、予期せぬ不具合が発生するリスクがあった。 - **解決策**: APIおよび画面の影響範囲を逐次調査し、詳細な資料として整理。これにより、作業の見積もり精度を向上させ、プロジェクトをスムーズに進行できるよう支援した。 ### 上司との密な連携 - **課題**: 作業が長期化し、タスクが増加することが予想されたため、進捗管理の徹底と認識の齟齬を防ぐ必要があった。 - **解決策**: 進捗状況を上司に細かく報告し、双方の認識を一致させた。この連携により、タスクの優先順位調整や迅速な意思決定が可能になった。 ### バグ修正および追加要望対応との並行作業 - **課題**: プロジェクト進行中に発生するバグや追加要望にも対応しながら、主要タスクを遅延なく進める必要があった。 - **解決策**: 全体の進捗を常に把握し、タスクの優先順位を明確化。バグや要望には即座に対応しつつ、メインのプロジェクトスケジュールを維持できるよう調整した。 ## 成果 - 作業の透明性が向上し、上司との円滑なコミュニケーションが確保された。 - 進捗は計画通りに進行し、バグ対応や追加要望にも迅速に対応できる体制を構築。 - 予定よりも2ヶ月早くプロジェクトを完了。 - 既存コードのバグ修正とリファクタリングを並行して実施し、機能性と可読性が向上。 - 現在のコードの状態を整理し、あるべき仕様書を明確化できた。

## チーム構成 - **テックリード**: 1 名（私） ### **背景・課題** * 私の入社後、バグ修正や機能実装の速度が向上し、**社内のテスト環境へのデプロイ頻度が急増**。 * しかし、**1回のデプロイに数分かかり、回数が増えるにつれ手動作業の負担・非効率さが顕在化**。 * **環境反映に人手を介することで、タイミングのズレや作業ミスが発生するリスク**もあった。 ### **担当業務** * **開発用環境へのデプロイ作業をスクリプトで自動化**。 * スクリプトに**ログ出力やエラーハンドリングを実装し、安心して実行できる設計**とした。 ### **成果** * **デプロイ作業を即時かつミスなく実施できるようになり、開発スピードと安定性が向上**。 * **時間がかかる単純作業を自動化することで、開発者が本来の実装業務に集中できる体制を整備**。 * テスト環境への反映が迅速になり、**検証・フィードバックサイクルの高速化に貢献**。

## チーム構成 - **テックリード**: 1 名（私） #### **背景・課題** * 社内メンバーや関係者に画面URLを共有した際、**ログインしていないとトップページに遷移してしまい、目的の画面にたどり着けない問題があった**。 * 特に自発的な画面共有時に「不便である」と感じたことをきっかけに、**ログイン後に元の画面へ遷移させる必要性を認識**。 * 認証後の遷移先を明示的に保持していなかったため、**ユーザー体験が途切れ、操作性が損なわれていた**。 #### **担当業務** * **ログイン前にアクセスされたURLを一時的に保持し、ログイン完了後に自動遷移させる仕組みを設計・実装**。 * **セッションストレージを利用してURL情報を一時保存し、ログイン判定後に復元**。 * **不正なリダイレクトを防ぐため、外部ドメインや想定外のパスを排除するセキュリティ対策を実装**。 * **React（TypeScript） + React Router による認証ガードをカスタマイズし、自然な画面遷移を実現**。 #### **成果** * **任意のURLを共有しても、ログイン後にそのまま画面遷移可能となり、UXの大幅な向上に貢献**。 * **デモ・トレーニングなどの案内時にも画面誘導がスムーズとなり、社内外の業務効率が改善**。 * **一般的なWebアプリにおける期待挙動を満たす構成とし、完成度の高いプロダクト体験を提供**。

## チーム構成 - **テックリード**: 1 名（私） ## プロジェクトの背景 - 他システムに弊社の生産データを連携させる必要があった。 - CSV を取り込む API は存在するが、機能改修が必要であった。 - プログラミング言語は自由に選定可能。 - 定期実行の仕組みは顧客側で設定。 - 出力した CSV ファイルの処理についても顧客が対応。 ## 課題と解決策 ### プログラミング言語の選定 - 実行環境は Windows であったが、特定の PC に依存せず実行できる形が求められた。 - 以前作成したショット数データ取り込みツールも Python で問題なく動作していたため、実装内容が類似している本件でも Python を採用。 ## 実装機能 - **ログ出力処理**: システムの動作履歴を記録し、トラブルシューティングを容易にする仕組みを構築。前回のショット数取り込みツールではコマンドライン出力がなかったため、今回は設定ファイル読み込み失敗時なども含め、詳細なログを記録するように改善。 - **メール送信処理**: エラー発生時のみ通知する方針とし、リカバリー手順を明確化。加えて、顧客がそのままメールを転送するだけで状況把握ができるよう工夫。前回ツールでの反省を活かした改善を実施。 - **設定ファイルの外部化（JSON）**: 環境設定や動作パラメータを JSON ファイルとして切り出し、メンテナンス性を向上。 - **例外処理強化**: 予期しないエラーに対する対応を強化し、システム安定性を確保。 ## 成果 - 1 人月分の料金をいただいたが、効率的な開発プロセスにより 1 日で開発完了。

## チーム構成 - **開発者**: 1 名（私）（顧客打ち合わせ、仕様整合、実装まで全て担当） - **関係者**: 顧客、上司 ## プロジェクトの背景 - 他システムに弊社の生産データを連携させる必要があった。 - CSV を取り込む API は存在するが、機能改修が必要であった。 - プログラミング言語は自由に選定可能。 - 定期実行の仕組みは顧客側で設定。 - 出力した CSV ファイルの処理についても顧客が対応。 ## 課題と解決策 ### プログラミング言語の選定 - 実行環境は Windows であったが、特定の PC に依存せず実行できる形が求められた。 - 以前作成したショット数データ取り込みツールも Python で問題なく動作していたため、実装内容が類似している本件でも Python を採用。 ## 実装機能 - **ログ出力処理**: システムの動作履歴を記録し、トラブルシューティングを容易にする仕組みを構築。前回のショット数取り込みツールではコマンドライン出力がなかったため、今回は設定ファイル読み込み失敗時なども含め、詳細なログを記録するように改善。 - **メール送信処理**: エラー発生時のみ通知する方針とし、リカバリー手順を明確化。加えて、顧客がそのままメールを転送するだけで状況把握ができるよう工夫。前回ツールでの反省を活かした改善を実施。 - **設定ファイルの外部化（JSON）**: 環境設定や動作パラメータを JSON ファイルとして切り出し、メンテナンス性を向上。 - **例外処理強化**: 予期しないエラーに対する対応を強化し、システム安定性を確保。 ## 成果 - 1 人月分の料金をいただいたが、効率的な開発プロセスにより 1 日で開発完了。

## チーム構成 - **開発者**: 1 名（私） ## プロジェクトの背景 - 基本設計書および詳細設計書が存在せず、機能単位での操作説明書も未整備であった。 - 社内での文書管理が不十分であり、特に操作手順書の差分管理が課題となっていた。 ## 課題と解決策 ### 操作手順書の作成方法の策定 - **課題**: 社内ではWordで操作手順書を作成していたが、差分管理が困難であった。 - **解決策**: Markdownを使用して操作手順書を作成することを提案し、採用。Markdownはバージョン管理が容易であり、チーム全体でのドキュメント管理が効率化された。 ### 操作手順書の公開方法の改善 - **課題**: 既存のマニュアルはダウンロード形式で提供され、不便であった。 - **解決策**: MarkdownをHTMLに変換し、システム上で直接閲覧できる形に変更。これにより、ユーザーが手間なく操作手順書を参照できるようにした。 ### 記載項目の策定 - **課題**: 操作説明書に記載するべき最低限の項目が明確でなかった。 - **解決策**: 「画面タイトル」「起動経路」「画面構成」「操作手順」「注意事項」「関連情報」の6つの項目を策定し、操作説明書としての基本要件を満たす構成を確立。 ### 認証系APIの作成 - **課題**: セキュリティ面で、認証されていない状態で操作説明書が閲覧できるリスクがあった。 - **解決策**: 認証系APIを新規で作成し、認証が通ったユーザーのみが操作説明書を閲覧できる仕組みを導入。セキュリティ強化に貢献。 ## 成果 - **操作手順書の作成方法を策定**: Markdownを使用したドキュメント作成手法を確立し、BacklogのWikiに手順を記載。チーム全体でのドキュメント管理が容易になった。 - **操作手順書の高評価**: 自身が作成した機能の操作手順書が、社内で高く評価され、他の部署でも参考にされるようになった。 - **新人教育の効率化**: アルバイトの加入時にも操作説明書を活用し、ドキュメント作成で迷わないような環境を整備。新人教育が円滑に進むようになった。

## チーム構成 - **テックリード**: 1 名（私） ## **プロジェクトの背景** * 約100件の要望・課題が蓄積しており、古いものには**既に廃止された機能に関する内容も含まれていたため、まずは棚卸と整理が必要だった**。 * システム利用者とのやり取りが**CSV形式のメールで行われており、視認性が悪く、内容の確認・対応が困難だった**。 * 通知メールに**対応URLや説明文などの必要な情報が欠如しており、ユーザー体験とサポート効率が低下していた**。 * 一部の機能では、**明確なエラー表示を行わず黙って動作を無効化する実装となっており、ユーザーが原因を特定できない状態だった**。 * **コード全体の可読性が低く、リファクタリングが行われていなかったため、拡張や不具合修正に時間を要していた**。 ## **成果** * **全体で約100件の課題を棚卸・分類し、対応優先度を整理。廃止対象や誤登録を除外し、チーム内の作業効率を大幅に向上**。 * 関係者に対してヒアリングを実施し、**要望の背景を把握しつつ、実現可能な改善提案を行った**。 * **整理された課題リストをもとに、運用フローの最適化にも貢献**。 * **通知メールを改善し、視認性・一貫性・利便性を向上**。 * **フォーマットをJSONベースに刷新し、自動処理との親和性を高めつつ、ユーザーが理解しやすい内容に改善**。 * **共通テンプレートを設計し、対応URLや説明文を含むように統一。通知品質とUXの向上に貢献**。 * **暗黙的な動作抑制処理を廃止し、ユーザーに明確なフィードバックを返す設計へ変更**。 * **エラーメッセージの表示により、ユーザーが自己解決できる場面を増加**。 * 結果として、**問い合わせ件数の削減と、サポート対応工数の軽減に寄与**。 * **可読性と保守性を高めるための段階的リファクタリングを実施**。 * IDEのリファクタリング機能や生成系AIを活用し、**コードの意味を保持しつつ安全に再構成**。 * **1つの変更を小さく保ち、短時間で完結する改善を継続的に積み重ねる方針を採用**。

## チーム構成 - **プロダクトマネージャー兼開発者**: 1 名（私） - **関係者**: 顧客、開発チームメンバー（要件定義、仕様確認、実装までを担当） ## プロジェクトの背景 - 前任者によって実装されたトランスファー機能に、可読性の低いコードや多くのバグが存在。 - 一部の機能が、仕様と異なる実装がされており、社内からの苦情が発生していた。 - 私がプロダクトマネージャーとして、プロジェクト全体を統括しながら、単独での実装を担当。 ## 課題と解決策 - **課題**: コードの可読性が低く、バグが多発。既存コードを修正する際に、デグレ（機能劣化）を防ぐ必要があった。また、仕様漏れによる機能追加も求められていた。 - **解決策**: スパゲッティコードを解析し、要所を見極めてリファクタリングを実施。デグレなくバグ修正と機能追加を行った。 ## 成果 - トランスファー機能のバグを全て修正し、社内からの苦情を解消。仕様漏れの機能追加も迅速に対応。

## チーム構成 - **プロダクトマネージャー (PdM)**: 1 名（主に指示・監督を担当） - **開発者**: 4 名 - 私 - アメリカ人開発者 1 名 - フィリピン人開発者 2 名 - **特記事項**: 多国籍チームであり、私以外のメンバーは日本語を話さないため、英語を用いたコミュニケーションが必須。 ## プロジェクト背景 - 複雑で品質の低い巨大なコードベースの保守が必要であり、頻繁に発生するバグへの対応が求められていた。 - 国際的なチームでの共同作業が必要であり、文化的・言語的な違いを超えた円滑なコミュニケーションと協力が求められた。 ## 課題と解決策 ### バグ修正速度の向上 - **課題**: コードベースの複雑さと低品質が原因で、バグ修正に多大な時間がかかっていた。 - **解決策**: バグ修正のプロセスを見直し、デバッグツールの活用と効率的なコード分析手法を導入。これにより、修正速度を従来の3倍に向上させた。 ### CPU使用率の最適化 - **課題**: 特定の処理が原因で、サーバーのCPU使用率が60%以上に達し、リソースの無駄遣いが発生していた。 - **解決策**: 問題のある処理を特定し、コードの最適化を実施。これにより、CPU使用率を10%まで低下させ、リソース効率を大幅に改善。 ## 主な成果 - **バグ修正速度の大幅な向上**: 複雑で品質の低いコードベースにおいて、バグ修正速度を3倍に向上。これにより、以前は1つのバグ修正にかかっていた時間で、今では3つのバグを修正できるようになった。 - **CPU使用率の劇的な改善**: CPU使用率が60%以上だったインスタンスを10%まで低下させ、より安価なインスタンスタイプでの安定稼働を実現。 ## 学んだこと - **デバッガーの早期活用**: 低品質なコードの場合、バグを特定するためにデバッガーを早期に使用することが効果的である。静的なデバッグは、バグの場所を絞り込んでから実施するべき。 - **二分探索的なアプローチ**: バックエンド、フロントエンド、Windowsアプリケーションに分散しているロジックを扱う際、APIリクエストのJSON内容を早期に確認し、問題が存在する部分を二分探索的に特定することが有効である。 - **現状のコードの状態を重視したデバッグ**: 様々な前提条件を無視し、現状のコードの状態からデバッグを進めることが、最も迅速な解決策につながると学んだ。

## チーム構成 - **プロダクトマネージャー兼開発者**: 1 名（私） ## 作業内容 - **テーブル定義の変更**: 棚卸時に登録する写真を一枚から複数枚に拡張するため、テーブル定義を変更。 - **顧客要望への対応**: 細かい顧客要望に迅速に対応し、システムの改善を実施。 ## 作業内容 - **テーブル定義の変更**: 棚卸時に登録する写真を一枚から複数枚に拡張するため、テーブル定義を変更。 - **顧客要望への対応**: 細かい顧客要望に迅速に対応し、システムの改善を実施。 ## プロジェクトの背景 - 途中で開発が放棄されたコードベースに取り組む必要があり、コードの品質が非常に低かった。 - 一部の機能が仕様と異なる形で実装されており、PM兼開発者として、単独での修正と改善を担当。 - テーブル構成を変更し、機能拡張を行う必要があった。 ## 課題と解決策 ### コード品質の改善とテーブル構成の変更 - **課題**: 低品質なコードベースの中で、仕様に沿った形で棚卸機能を改修し、複数枚の画像を登録できるようにする必要があった。 - **解決策**: デグレを防ぎつつ、テーブル構成を短時間で変更し、システムの安定性を維持しながら機能拡張を実現。 ### 顧客要望への迅速な対応 - **課題**: 顧客からの細かな要望が多く、これらに対して迅速かつ的確に対応する必要があった。 - **解決策**: 顧客とのコミュニケーションを密に取り、要望に対する優先順位を明確にし、スピーディーに対応。結果として、顧客満足度の向上に貢献。 ## 成果 - **テーブル構成の変更**: 複数枚の画像を登録可能にするテーブル構成の変更を短時間で実施し、デグレを防止。 - **顧客要望への対応**: 顧客からの要望にスピーディーに対応し、プロジェクト全体の進捗を円滑に進めることができた。

## チーム構成 - **プロダクトマネージャー (PdM)**: 1 名 - **開発者**: 5 名（リーダーとして従事） - **他部門スタッフ（Web 部分とデータクレンジング担当）**: 6 名 ## プロジェクトの背景 - 参画時にプロジェクトは遅延しており、Spring BatchとJavaの専門家が不在。 - メンターや技術指導者がいない状況で、プロジェクトの立て直しが求められていた。 ## 役割と責任 - **エンジニアリングとマネジメントの兼任**: 開発チームのリーダーとして、技術的な実装とプロジェクトの進行管理を担当。 - **技術選定**: 事業方針とチームのスキルに基づき、適切な技術の選定とアサインを実施。 - **Spring Batchのフレームワーク部分の実装**: フレームワークの設計と実装を担当。 - **協力会社のマネジメント**: 協力会社との連携を円滑に進め、品質と納期を確保。 - **ビジネスロジックの実装方針の立案**: 実装方針を策定し、チーム全体に共有。 - **コードレビュー**: コード品質を担保するため、全てのコードレビューを実施。 ## 課題と解決策 ### 技術選定の未確定問題の解決 - **課題**: 設計段階で採用技術が未確定だったため、技術選定を進める必要があった。 - **解決策**: 事業方針とチームメンバーのスキルを考慮し、効率的な技術を選定。これにより、実装時間の短縮と開発の効率化を実現。 ### 変更に対応できる仕組み作り - **課題**: ウォーターフォール型の進行で、前工程が完了しないままプロジェクトが進行していたため、柔軟な変更対応が求められた。 - **解決策**: 柔軟に対応できる仕組みを導入し、進行中の変更にも迅速に対応。結果として、想定以上の時間短縮を達成。 ### コード品質の担保における取り組み - **課題**: 運用部分が他企業に委託されるため、リランとリカバリーが容易なコード品質を維持する必要があった。 - **解決策**: フレームワークを制限のある構造に変更し、コンポーネント化を維持しつつ、質の高いソフトウェアを作成。 ### コミュニケーション活性化への取り組み - **課題**: チーム内でのコミュニケーション不足が業務進行の課題となっていた。 - **解決策**: メンバー間のコミュニケーションを促進するための取り組みを実施。これにより、業務がスムーズに進行し、チーム全体の効率が向上。 ## 成果 - **遅延の解消**: プロジェクトの2ヶ月の遅延を2週間まで短縮。 - **高評価の獲得**: 四半期ごとの360度評価で、5段階中4の評価を2期連続で獲得。