daisuke

■プロジェクト名 放送用媒体管理システム開発 ■プロジェクト概要 概要: 放送局が保有するビデオテープ・音声用テープ等の記録媒体の貸出／出庫／在庫管理を行う業務用システムの開発（既存システムのリプレイス／改修案件） チーム規模: 9名 自身の役割: SE（実装担当メンバー／フロントエンド・バックエンド・移行・テストを横断） 開発手法: アジャイル ビジネスモデル: BtoB ■担当工程 実装 / 単体テスト / 結合テスト ■使用技術 言語: PHP 8 / JavaScript / SQL / HTML5 / CSS3 FW: Laravel / React DB: MySQL インフラ: AWS（RDS, ECS, EC2, S3, Secrets Manager）/ Docker ツール: Git / Slack / Chatwork / Backlog / PhpStorm AI: Claude Code / ChatGPT ■担当業務 ・Dockerを利用したローカル環境構築手順書の更新 ・C#で実装されたバッチ処理のLaravel（PHP）への移行 ・Javaで実装されたバックエンド処理の Laravel（PHP）への移行 ・Reactを用いたフロントエンド画面の実装、および Laravel（PHP）による REST APIの実装 ・FTPS/Digest認証/LDAP認証による外部システム連携機能の実装 ・外部システム連携のテスト実施 ・単体テスト仕様書の作成、手動実施、エビデンス取得 ・結合テストの手動実施、エビデンス取得 ・総合テストの不具合対応 ・基本設計書・詳細設計書の修正 ・リリース物の報告書作成 ・協力会社のPRを自チームの開発ブランチへのマージとマージで生じた競合解決 ・協力会社へのPR作成、レビュー依頼、レビューでの指摘対応 ■取組・実績 取組① 参画したタイミングでプロジェクトのスケジュールが遅れているという問題が発生していた。 スケジュールは組み直されており、それ以降は遅れが許されないという状況にあったため、自分のタスクを前倒して完遂し、他メンバーのタスクを巻きとるという課題を自分に課して対応を進めた。 自分に与えられたタスクは予定より何日か余裕をもって前倒しで完遂し、空いた工数で他メンバーの未着手のタスクや遅延タスクを巻き取った。 結果として、開発フェーズで遅れを発生させることなくプロジェクトに貢献した。 取組② 総合テストフェーズで他メンバーが現場を離れ、不具合対応を一人で担う体制となり、自身の担当範囲外での不具合も含め件数は200件以上ある状況にあった。 一人で対応するには件数が多く、効率良く捌いていく必要があったため、ClaudeCodeを取り入れて効率良く不具合対応を進めていく方針を自分で立てた。 Backlogに優先順位付けがされた課題が追加されていく運用だったため、優先順位が高いものから着手。 Backlogに記載のある不具合の内容と関連するソースファイルをClaudeCodeのプロンプトに入力をし不具合の原因を突き止める。 その後、ClaudeCodeの修正案を確認して、ソースファイルを修正。 デグレ等の確認を行うため、ClaudeCodeにテスト用のデータを生成させ、手動テストで問題がないことを確認した後にリリース。 結果、AIを用いて修正速度を上げ、また人手で品質を担保しながら効率良く不具合対応をやりきった。 取組③ 基本設計書や詳細設計書は存在はしていたが、記載する人によってフォーマットや書きっぷりが異っていて記載内容も粗いという問題があった。 記載から漏れている仕様などなにか取りこぼしがあり、手戻りが発生してしまうと工数がかさんでしまうおそれがあったため、設計書作成者やプロパーへの確認・既設の実装（C#・Java）や既設の設計書を確認しながら、対応を進めていく方針を自分で立てた。 具体的には、作成された設計書と既設の実装や設計書との相違点などを事前に洗出し、関係者にWEB会議などで認識をすり合わせながら対応を進めた。 結果として、既設と同等の動作を担保したうえで、手戻り等発生させずにリプレイスを行えた。 取組④ リプレイス元のバッチ処理はC#、バックエンド処理はJavaで実装されており、どちらの言語も実務経験がないという問題があった。 まずは処理の流れを大まかに把握した上で、言語固有の構文は公式ドキュメントを参照して、デグレ等発生させずにリプレイスを行うよう自分で方針を決めた。 PHPでの開発経験を基に既設の実装を読み解き、C#・Javaの固有構文や標準関数は都度公式ドキュメントを参照して進めた。 補助的にChatGPTも併用し、信頼性を高めた。 結果、実務経験のない言語からのリプレイスもデグレ等を発生させずに問題なく行えた。

■プロジェクト名 薬局関連ECシステム開発 ■プロジェクト概要 概要: 医療関係者（薬局・病院）向けに、医療用医薬品の不動在庫を医療関係者間で売買・マッチングできるBtoB ECプラットフォームの開発 チーム規模: 7名 自身の役割: SE（基本設計〜保守・運用までを担当） 開発手法: アジャイル（1週間スプリント） ビジネスモデル: BtoB ■担当工程 基本設計 / 詳細設計 / 実装 / 単体テスト / 結合テスト / 保守・運用 ■使用技術 言語: PHP 7 / JavaScript / SQL / HTML5 / CSS3 FW: FuelPHP 1.8 / jQuery 3 DB: MySQL インフラ: AWS（RDS, ECS） ツール: Git / Bitbucket / Backlog / Redmine / Slack / VSCode ■担当業務 ・基本設計書の作成（画面設計、ER図を含むDB設計、バッチ設計） ・詳細設計書の作成（テーブル設計、CRUD設計、メッセージ出力仕様、修正対象ファイル・関数の特定、修正/追加内容の設計、処理詳細、実装SQLの記述） ・検索画面の不具合対応 ・医薬品廃棄理由管理の機能追加対応 ・単体テスト仕様書の作成、手動実施、エビデンス取得 ・結合テスト仕様書の作成、手動実施、エビデンス取得 ・リリース前後対応 ■取組・実績 取組① 医薬品検索画面にて、本来表示されるべき医薬品が表示されないという問題が発生していた。 まずは、画面上に表示されている医薬品の一覧をエクセルにまとめ精査した後に、原因と思われるロジックの確認を行う方針を自分で決めた。 検索画面に表示されている医薬品の一覧をまとめていくうちに、同じ医薬品が重複されて表示されている別の不具合を発見した。 検索ロジックを追うと、本来検索用の医薬品名カラムを使用する必要があるにも関わらず、表示用の医薬品名カラムが使用されていた。 検索用の医薬品名カラムに修正することで、本来表示されるべき医薬品と重複表示されていた医薬品が重複なしに表示され、当初の不具合以外も解消することができた。 取組② 廃棄された医薬品の理由をエクセルで手動で管理する運用となっていて、非効率で管理業務コストが発生していた。 業務フローを明確した上で、設計に落とし込んで実装をする方針を自分で決めた。 PMや業務担当者から事前に業務フローや実際にエクセルに出力されている内容を共有してもらい、どの理由がどの既存処理に紐づくのかを整理し、改修が必要なバッチと画面を洗い出した。 整理の結果、実装方針としては、新規バッチや画面を起こすのではなく、既存処理に医薬品の廃棄理由と医薬品名、個数等の登録処理を追加する方針をとって進めた。 結果、改修範囲を最小化することができ、管理業務コストを削減することができた。

■プロジェクト名 検索連動型広告向け統合型運用プラットフォーム開発 ■プロジェクト概要 概要: インターネット広告代理店業における検索連動型広告運用の自動化・効率化を目的として、Google・Yahoo!等の検索広告媒体への入稿・入札・レポート出力を一元的に行う統合型運用プラットフォームの開発・保守 チーム規模: 4名 自身の役割: SE（実装担当メンバー／バッチ移行・実行環境移行・外部API対応・不具合改修を横断） 開発手法: アジャイル ビジネスモデル: BtoB ■担当工程 実装 / 単体テスト / 保守・運用 ■使用技術 言語: PHP 5 / PHP 8 / JavaScript / SQL / HTML5 / CSS3 FW: Laravel 9 / FuelPHP 1.8 / AngularJS DB: MySQL インフラ: AWS（Batch, ECS, RDS, S3, CloudWatch, EventBridge, Secrets Manager）/ Docker / Jenkins ツール: Git / GitHub Actions / Slack / Asana / Zoom / PhpStorm ■担当業務 ・FuelPHPで実装されたバッチ処理をLaravelに移行 ・旧環境のJenkinsから新環境のAWSへバッチ実行環境の移行 ・Google Ads API、Yahoo!広告 APIの仕様変更対応 ・カスタマーサポートからの不具合報告の調査および不具合改修 ・単体テスト仕様書の作成、手動実施、エビデンス取得 ・チーム内の相互コードレビュー ■取組・実績 取組① リプレイスを行うにあたって、設計書が存在せず、コードから仕様を読み解く必要があった。 なので、コードを読み解き処理内容を把握しつつ、旧環境と新環境で同じテストデータを使って、出力内容が変わることがないことを確認しながら進める方針を自分で決めた。 FW固有の記述などもあったため、移行先で同じ動きができるようコードを書き換え、実装を終えたらテストデータを作成し、移行前と移行後で出力内容が同じであることのテストを行った。 結果として、設計書のないレガシーバッチをデグレ等起こさず、Laravelへ移行できた。

■プロジェクト名 マンションオーナー向け中古マンションの相場・価格情報サイト開発 ■プロジェクト概要 概要: マンションの現在価値・騰落率・独自ロジックによるマンションスコア（資産性／立地／建物）をランキング形式で提供する、マンションオーナー向け会員制サイトの開発 チーム規模: 3名 自身の役割: SE（実装担当メンバー／SQLチューニング・Elixirからの言語移行・不具合改修・テストを横断） 開発手法: アジャイル（1週間スプリント） ビジネスモデル: BtoC ■担当工程 実装 / 単体テスト / 保守・運用 ■使用技術 言語: PHP 7 / Elixir / JavaScript / SQL / HTML5 / CSS3 FW: Laravel 5 / Vue.js 2 / jQuery 3 DB: MySQL / MongoDB インフラ: AWS（RDS） ツール: Git / SourceTree / PhpStorm / Backlog / Wrike / Slack / GitHub Actions ■担当業務 ・MySQLのスロークエリの調査およびSQLチューニング ・Elixirで実装された既存処理のPHP（Laravel）への置き換え ・問い合わせ起因の調査および不具合改修 ・単体テスト仕様書の作成、手動実施、エビデンス取得 ■取組・実績 取組① スロークエリログが複数出力されている問題が発生していた。 該当のSQLを共有してもらった後に、EXPLAINで実行結果を確認して改修方法を決める方針を自分で決めた。 具体的には、スロークエリログを共有してもらい、そこに出力されているSQLに対して、EXPLAINを実行し、インデックス使用などの有無を確認。 インデックスが効いてなく、フルスキャンが原因でレスポンスのパフォーマンスが落ちていることを確認したので、インデックスを作成し、作成後にフルスキャンが解消されていることを確認した。 結果、スロークエリログは出力されることはなくなり、パフォーマンス改善ができた。 取組② 一部の処理がElixirで実装されており、自身を含むチーム内でElixirの実務経験者がおらず、キャッチアップコストがかかっていた。 まずは、Elixirがなぜ使用されているのか、Elixirの強み等を理解した上で改修方針を固めるよう自分で決めた。 開発当初から携わっている開発者はおらず、Elixirの強みである大規模で何百といった同時接続を並列プロセスで捌く必要はなかったため、リーダーにPHPへの置き換えを提案した。 提案時にはElixirを活かしきれていない点、PHPへ置き換えることで保守性が向上する旨を提示。 提案が通り、改修まで自分で行った。 結果として、改修や不具合対応におけるElixirキャッチアップの工数を削減できた。

■プロジェクト名 動画制作プラットフォームの新規開発 ■プロジェクト概要 概要: SNS広告（Facebook／Instagram）を運用する企業向けに、動画クリエイティブをオンラインで発注できる動画制作プラットフォームの新規開発 チーム規模: 4名 自身の役割: SE（要件整理〜環境構築〜実装〜テストまでを担当） 開発手法: アジャイル ビジネスモデル: BtoB ■担当工程 要件定義 / 基本設計 / 詳細設計 / 実装 / 単体テスト / 結合テスト ■使用技術 言語: PHP 7 / JavaScript / SQL / HTML5 / CSS3 FW: Laravel 8 / jQuery 3 DB: MySQL インフラ: AWS（EC2、Route 53） ツール: Git / SourceTree / Chatwork / XD / PhpStorm ■担当業務 ・代表へのヒアリングおよび仕様調整 ・機能要件の整理・文書化（機能一覧／画面別機能要件の作成） ・基本設計書の作成（DB設計、画面設計） ・詳細設計書の作成（テーブル設計） ・WBS作成および進捗管理（代表・デザイナー・自身の3者のタスク調整） ・AWS（EC2、Route 53）を用いたサーバー環境構築 ・PHP（Laravel）を使用した管理者、ユーザー、クリエイター向け画面のバックエンド実装 ・HTML5を使用した管理者、ユーザー、クリエイター向け画面のフロントエンド実装 ・GMOペイメントと連携したクレジットカード決済機能の開発 ・単体テスト仕様書の作成、手動実施、エビデンス取得 ・結合テスト仕様書の作成、手動実施、エビデンス取得 ■取組・実績 取組① 新規サービスの立ち上げフェーズであり、代表が描いている要望を文章化をして設計に落とし込む必要があった。 代表とすり合わせしつつ、画面別機能要件と機能一覧のドキュメントを作成する方針を自分で決めた。 WEBで代表と打ち合わせを行い、どういったサービスでどのような機能が必要となってくるのかヒアリングを行った。 ヒアリング内容をもとに、画面ごとに必要な機能と機能概要などをドキュメントにまとめ、作成後も代表と認識齟齬がないか確認を行った。 結果、代表との認識齟齬を発生させることなく、設計・実装を行うことができ、スケジュール通りに遂行できた。 取組② 開発者は自分一人しかおらず、要件定義～リリースまで一気通貫で対応をする必要があった。 各工程の工数を出して、スケジュールを可視化し進捗状況を共有できるようにする方針を自分で決めた。 まずはAWSや決済周りの契約に伴う工数、フロントエンドのデザイン作成に伴う工数を代表やデザイナーとすり合わせさせていただき、そこから自分の担当領域である、インフラの構築工数とバックエンドの開発工数、フロントエンドの開発工数を出して、WBSに落とし込んだ。 スケジュールは都度、打ち合わせで代表に共有を行っていた。 結果、3画面分の機能実装と決済連携を含めたサービスをリリースまでやりきった。