ID:60824さん

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

# ショット数連携ツール実装 ## チーム構成 - **開発者**: 1 名（私） - **関係者**: 顧客、上司（顧客打ち合わせ、仕様整合、実装まで全て担当） ## 技術環境 - **使用技術**: Python3 - **業界**: 製造業 ## プロジェクトの背景 - 生産管理システムから吐き出される CSV を弊社のシステムに連携させる必要があった。 - 生産管理システムから吐き出された CSV ファイルを弊社のシステムが取り込めるように成形する作業はお客様側が担当。 - CSV を取り込む API は既存のもので、プログラミング言語は自由に選定可能。 - 定期実行の仕組みはお客様側で設定。 ## 課題と解決策 ### プログラミング言語の選定 - 実行環境は Windows であったが、プログラムが動作する PC に依存しない形で実行できることが求められた。 - 先輩は.NET を推奨したが、コードサイズの抑制、exe 化の容易さ、ライブラリの豊富さを考慮し、Python を選定。 - この選定により、開発の効率化と保守性の向上を実現。 ## 実装機能 - **ログ出力処理**: システムの動作履歴を記録し、トラブルシューティングを容易に。 - **メール送信処理**: 処理結果を担当者に自動通知。 - **設定ファイルを JSON ファイルに切り出し**: 環境設定や動作パラメータを外部ファイル化し、メンテナンス性を向上。 - **例外処理**: 予期しないエラーに対する対応を強化し、システムの安定性を確保。 ## 成果 - 1 人月分の料金をいただいたが、効率的な開発プロセスにより、4時間で開発を完了。 - 顧客からは、開発の迅速さと品質の高さについて高評価をいただき、後続プロジェクトでも同様の手法を採用。

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

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

# トランスファー機能正式版の実装 ## チーム構成 - **プロダクトマネージャー (PdM)**: 1 名（主に指示・監督） - **開発者**: 1 名（私） ## 技術環境 - **使用技術**: Java, JavaEE, VB.NET, JavaScript, jQuery, MySQL, JPA, Linux, AWS - **業界**: 製造業 ## プロジェクトの背景 - 以前、トランスファー機能（TF機能）の仕様漏れと追加実装を行ったが、その際は納期を優先し、データベース構成を変更して登録データの関係性をデータベース側で表現する恒久対策が未実施のままだった。 - 修正範囲が非常に広く、システム全体に影響を及ぼす可能性が高い。 ## 課題と解決策 ### 影響範囲画面とAPIの逐次調査 - **課題**: 修正により影響を受けるAPIや画面が多岐にわたり、予期せぬ影響が発生するリスクがあった。 - **解決策**: APIと画面の影響範囲を逐次調査し、詳細な資料としてまとめた。これにより、作業の見積もり精度を高め、スムーズなプロジェクト進行を支援。 ### 上司に対しての細かい頻度での連絡 - **課題**: 作業時間が長引き、タスクが増加することが予想されたため、進捗管理と認識のズレを防ぐ必要があった。 - **解決策**: 作業状況を上司に細かく報告し、上司の認識と自分の作業状況が乖離しないようにした。この連携により、タスクの優先順位調整や迅速な意思決定が可能になった。 ## 成果 - プロジェクトは現在進行中だが、上記の対策により、作業の透明性が向上し、上司との円滑なコミュニケーションが確保されている。 - 作業の進捗が順調で、予期せぬ問題も迅速に対応できる体制が整っている。

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

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

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

# 大手パブリッククラウドのテキスト分析 API 調査プロジェクト ## チーム構成 - **上司**: 2 名 - **調査担当者**: 2 名（私を含む） ## 業務概要 - **テキスト分析 API の調査**: AWS、Azure、GCPといった大手パブリッククラウド3社のテキスト分析APIを詳細に調査し、その結果を基に資料を作成。 - **独自の活用方法の提案**: 単に調査結果をまとめるだけでなく、各APIの独自の活用方法を提案するセクションを追加。これにより、調査結果の実用性と価値を高めた。 - **レビューとフィードバックのプロセス**: 資料作成過程で初稿を作成し、上司にレビューを依頼。これにより、プロジェクトの進行中に認識の齟齬を防ぎ、双方の理解を常に一致させる努力を行った。 ## 学び - **クラウドドキュメントの読解力向上**: 複雑で読みづらいパブリッククラウドのドキュメントを効果的に読み解くスキルを習得。 - **プロジェクト進行のベストプラクティス**: 認識の齟齬を避けるため、プロジェクトの初期段階で草案を作成し、関係者と早期に共有する重要性を学んだ。

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