ID:60824さん

# グループ企業人事管理システムリプレイス案件のバッチ部分の実装 ## チーム構成 - プロダクトマネージャー(PdM)：1 名 - 開発者：5 名 - 他部門スタッフ（Web 部分とデータクレンジング担当）：6 名 ## 技術環境 - 使用技術：Java, Spring Batch, PostgreSQL, MyBatis, Linux, Bash (Shell) - 業界：エネルギー業界 ## プロジェクトの背景 - 参画時点でのプロジェクトの遅延 - Spring Batch と Java の専門家不在 - メンターや技術指導者の不在 ## 役割と責任 - エンジニアリングとマネジメントの兼任 - 一部技術選定 - Spring Batch のフレームワーク部分の実装 - 協力会社のマネジメント - ビジネスロジックの実装方針の立案 - コードレビュー ## 課題と解決策 - 技術選定の未確定問題の解決。フレームワークとして Spring Batch の使用は既に決まっていたが、ORM などをどれを使用するか決まっていなかった。チームメンバーのスキルを確認したところ誰も ORM を使用したことがなかったので、厳格な ORM である JPA の使用は早期に選択肢から外した。その中で Spring JDBC と MyBatis が候補に残ったが、SQL に長けた開発者がいる場合は、SQL の部分が別ファイルに分かれていた方がコードの競合が起きないため便利かもと思い、MyBatis を採用した。→ 結果、SQL がとても得意で Java が全く書けない開発者が途中からジョインしたが SQL の部分だけを効率的に書いてもらうことができた。 - Java を扱える開発者がチームにいなかったため、本来はコードの可読性や保守性の観点から Java の方で処理するべき問題でも SQL の方で処理した方が今回の開発ではよいかと思い、SQL 側に処理を寄せるようにしました。 - 詳細設計の段階でも基本設計レベルのテーブル定義が揺らいでいたので、エンティティクラスをテーブル定義から動的に生成できる仕組みを MyBatis Generator で作成した。さらにテーブル定義だけではなく、CSV の変更を管理できる方が便利だと考えたので、CSV の構造を一度 SQL で DB に入れて、そこからリバースで CSV のエンティティクラスを生成するようにしてエンティティクラスの実装時間を短縮した。 - 運用は別の会社の運用部隊が行うことが決定していたので、リランとリカバリーを容易にする必要があった。そのためには一つのトランザクションで処理する必要があった。Spring Batch ではチャンクモデルとタスクレットモデルの両方があるが、タスクレットモデルでは、1 トランザクションでの処理機能のみを提供している。タスクレットモデルでは自由度の記述が高い書き方だが、読み込みや書き込みの処理を別のファイルに分割することはできない。そこでドキュメントなどには載っていなかったがチャンクモデルコンポーネントをタスクレットモデルの中で呼ぶ処理をライブラリのコードを読みながら実装した。 - Web チームとのコミュニケーション不足を解消するためには、まずはランチなどを行ったりして、業務外での交流を通じて関係を築くべきだと考え、ランチを一緒によく行った。 ## 成果 - 2 ヶ月の遅延を最終的に 2 週間に短縮。 - 四半期 360 度評価で 5 段階中 4 の評価を 2 期連続で獲得。

# 新機能承認ワークフローの実装 ## チーム構成 - プロダクトマネージャー(PdM)：1 名（主に指示・監督） - 開発者：1 名（私） ## 技術環境 - 使用技術：Java, JavaEE, VB.NET, JavaScript, jQuery, MySQL, JPA, Linux, AWS - 業界：製造業 ## プロジェクトの背景 - 既存コードの品質低下により、機能追加が困難な状況 - 単独での開発と設計責任 ## 課題と解決策 - 新規機能や追加機能の開発に際し、既存コードの改善が必要となったため、あまり一般的には良くないが、既存コードのリファクタリングと新機能開発を並行して進めた。 - 既存の処理に同様の処理がある場合でも、その質が良くないことが多かったため、ゼロベースでコード品質を評価し、劣ったコードから学ばないよう注意しながらコーディングを行った。 - 既存の機能では、エラーメッセージの数を減らすために共通のエラーメッセージが使い回され、エラーメッセージが具体的でない場合や、ユーザーが操作しても反応しないように無効化されている箇所が多かった。そのため、ユーザーフレンドリーなバリデーションエラーメッセージを実装し、エラー発生時にユーザーが取るべき次のアクションを示すような設計に努めた。 - 標準的でない方法を取っている処理に対するコメントが少なかったため、その処理内容がなぜ書かれたのかを示す意図コメントを残し、後でコードを見ても理解しやすくした。 - 既存のコードではコピー＆ペーストが頻繁に行われ、同じ処理が多くの場所に散在しており、保守性と可読性が低下していました。これを解決するため、コードの共通化を進め、メソッドを適切に分割しました。 - Backlog の運用方針が定まっておらず、本番環境での障害発生時に問題の原因となった修正を特定するのに多くの時間を要していた。これを解決するため、課題とコミットログを関連付け、ステータスなどを Backlog で適切に管理する運用方法を文書化し、プロジェクトに適用した。 ## 成果 - 予定よりも大幅に早い開発進捗 - 予定されていた 4 名の開発チームにも関わらず、単独での開発を成功させる - コードの共通化により開発速度の向上 - 同様の処理の重複を減らし、効率的な開発を実現

# 既存機能のバグ修正プロジェクト ## チーム構成 - プロダクトマネージャー(PdM)：1 名（指示・監督を主に担当） - 開発者：4 名 - 私 - アメリカ人開発者 1 名 - フィリピン人開発者 2 名 - 注意：私以外は日本語を話せない多国籍チーム ## 技術環境 - 使用技術：Java, JavaEE, VB.NET, JavaScript, jQuery, MySQL, JPA, Linux, AWS - 業界：製造業 ## プロジェクト背景 - 複雑かつ品質が低い巨大なコードベース ## 主な成果 - 複雑で品質の低い巨大なコードベースのバグ修正を通じて、バグ修正の速度を以前の 3 倍に向上。以前は 1 つのバグ修正にかかっていた時間で、今では 3 つのバグを修正できるようになった。 - CPU 使用率を上昇させていた処理を特定し、修正。これにより CPU 使用率が 60%以上だったインスタンスの使用率が 10%まで低下し、インスタンスタイプを下げても安定して稼働するようになった。 ## 学んだこと - 低品質なコードの場合、バグを特定するためにデバッガーを早期に使用する方が効果的である。静的なデバッグは、ある程度バグの場所を絞り込んでから実施するべき。 - バックエンド、フロントエンド、Windows アプリケーションに分散しているロジックを扱う際は、API リクエストの JSON 内容を早期に確認し、問題が存在する部分を二分探索的なアプローチで特定するべき。 - 様々な前提条件を無視して、現状のコードの状態からデバッグを進めることが、最も迅速な解決策につながる。

# 社内会議室予約システムの VBA 改善プロジェクト ## チーム構成 - 開発者兼プロジェクトマネージャー：1 名（私） ## プロジェクト背景 - 5000 行を超えるコードが適切に関数分割されていない。 - for 文が開始してから終了まで 2000 行以上続く。 - 処理が非常に重く、頻繁にシステムがフリーズする。主な原因は for 文のネストと処理件数。 ## 改善プロセス 1. 処理の重さを引き起こしている for 文のネストを解消しようと試みたが、アルゴリズム的に困難であると判断し断念。 2. 処理の重い for 文をアーリーリターンを用いて単純化しようとしたが、条件が不明瞭で断念。 3. 元のロジックに根本的な問題があると判断し、一から再構築することを決定。 4. 再構築にあたり、頻繁にツールを使用する若手社員からのフィードバックを収集。 5. 開発過程で得られたフィードバックを反映し、同僚に使い勝手を確認しながら進めた。 ## 主な成果 - 2 週間で既存機能を維持しつつ改善機能を加えた会議室予約ツールを完成。 - ループ処理を最小限に抑えたロジックへの変更で、動作速度が格段に向上し、フリーズすることがなくなった。 - 最終的に社内の改善活動の一環として、プロジェクトはチームでのメンテナンスを実施することに。 ## 学んだこと - 低品質なコードは修正するよりも、作り直すほうが効率的な場合がある。 - 既存のシステムの動作を把握した上で、同様の機能を持つプログラムを作成することは技術的に大きな難題ではない。

# 大手パブリッククラウドのテキスト分析 API 調査プロジェクト ## チーム構成 - 上司: 2 名 - 調査担当者: 2 名 ## 業務概要 - AWS、Azure、GCP といった大手パブリッククラウド 3 社のテキスト分析 API を調査し、その結果をまとめた資料を作成した。 - 資料には単に調査結果を列挙するだけでなく、API の独自の活用方法を提案するセクションも含めた。 - 資料作成過程では、初稿を作成し上司にレビューを依頼することで、常に双方の認識を合わせる努力を行った。 ## 学び - 複雑で読みづらいパブリッククラウドのドキュメントの効果的な読み方。 - プロジェクト進行のコツ：認識の齟齬を避けるために、早期に草案を作成し共有する重要性。