ID:71936さん

# 中古トラックBtoBネットオークションサービス「トラッカーズオークション」の開発・運用 ## プロジェクト概要 中古トラックを出品する事業者と、国内外のバイヤーをつなぐBtoBネットオークションサービス「トラッカーズオークション」の開発・運用を担当しました。 既存のオークション機能に加え、新たな販売方式の追加、車両情報登録の効率化、障害対応やセキュリティ対策の改善に取り組みました。 チームリーダー兼CREとして、営業・オークション運営担当者へのヒアリング、要件整理、既存仕様の調査、設計、実装、コードレビュー、リリース、障害対応、運用改善まで一貫して担当しました。 機能開発では、依頼された内容をそのまま実装するのではなく、出品、購入、成約など既存の業務フローへの影響や、将来の保守性を考慮して設計しました。 ## チーム情報 - エンジニア：3名 - 自身の役割：チームリーダー兼CRE - 主な連携先：営業担当、オークション運営担当、カスタマーサポート - 担当工程： - ヒアリング - 要件整理 - 設計 - 実装 - コードレビュー - リリース - 障害対応 - 運用改善 ## 使用技術 - Ruby on Rails - TypeScript - React - GraphQL - AWS - RDB - Datadog - GitHub - GitHub Actions - Trivy - Devin - MCP ## 開発・実装内容1：専売・即決価格機能の開発 ### 概要 従来のオークション方式に加えて、中古トラックの販売機会を増やすための専売・即決価格機能を開発しました。 営業・オークション運営担当者へのヒアリングから、要件整理、設計、バックエンド・フロントエンドの実装、リリースまで担当しました。 ### 課題 従来のオークション方式だけでは、出品者と購入希望者の条件が合わず、販売機会を逃す場合がありました。 一方、新しい販売方式を追加するにあたっては、既存の出品、購入、成約などの処理へ影響を与えないようにする必要がありました。 また、販売方式によって利用できる操作や画面表示が異なるため、バックエンドとフロントエンドの双方で条件を整理する必要がありました。 ### 自身が行ったこと 営業・オークション運営担当者へヒアリングを行い、専売・即決価格機能に必要な業務ルール、利用条件、例外ケースを整理しました。 既存の出品・購入・成約処理を調査し、新しい販売方式を追加した場合の影響範囲を確認しました。 Ruby on Railsで販売条件の判定やデータ更新などの業務ロジックを実装し、GraphQLを通じてフロントエンドへ必要な情報を提供しました。 TypeScript・Reactでは、販売方式に応じた情報表示や操作制御を実装しました。 リリース前には、既存のオークション方式を含む各販売フローを確認し、既存機能へ影響を与えないことを検証しました。 ### 使用技術と使用場面 - **Ruby on Rails** - 販売条件の判定 - 出品・購入・成約に関する業務ロジック - データ取得・更新処理 - **GraphQL** - 出品車両や販売条件に関するデータの取得 - 購入操作に必要なAPIの提供 - **TypeScript・React** - 販売方式に応じた画面表示 - 利用可能な操作の制御 - 購入時の入力・確認画面の実装 - **RDB** - 出品情報、販売条件、購入・成約情報の管理 - 既存データへの影響確認 ### 成果 従来のオークション方式に加えて、新しい販売手段を提供しました。 出品者と購入者の取引機会を増やし、サービス全体の成約率向上に寄与しました。 ## 開発・実装内容2：AIを活用した車両情報の入力補助・異常検知 ### 概要 中古トラックを出品する際の車両情報登録について、AIを活用した入力補助機能と異常検知機能を開発しました。 ### 課題 中古トラックの出品情報には多数の入力項目があり、入力作業の負担や、入力漏れ・誤入力が発生する可能性がありました。 車両情報に誤りや不整合があると、購入を検討するバイヤーの判断や、その後のオークション運営業務へ影響します。 そのため、入力担当者の負担を減らしながら、登録情報の品質を向上させる必要がありました。 ### 自身が行ったこと 車両情報の入力業務を確認し、AIによって補助できる項目や、異常候補として検知すべき情報を整理しました。 AIが出力した内容をそのまま確定値として登録するのではなく、入力担当者が内容を確認・修正できる補助機能として設計しました。 また、登録された車両情報について、通常と異なる可能性がある情報を検知し、担当者が確認できる仕組みを開発しました。 AIの判定だけに依存せず、最終的には担当者が確認することで、業務上の安全性を確保しました。 ### 使用技術と使用場面 - **Ruby on Rails** - 車両情報の取得・更新 - AI処理との連携 - 入力補助結果や異常候補の管理 - **TypeScript・React** - AIが生成した入力候補の表示 - 利用者による確認・修正操作 - 異常候補の画面表示 - **AI** - 車両情報の入力候補生成 - 登録情報の異常候補検知 - **RDB** - 車両情報、入力結果、確認結果の管理 ### 成果 車両情報登録にAIを組み込み、入力担当者の作業を支援しました。 また、異常候補を事前に確認できる仕組みを提供し、登録情報の品質向上に貢献しました。 ## 開発・実装内容3：AIを活用した開発プロセスの改善 ### 概要 設計、実装、Pull Requestレビューなどの開発工程にAIを導入し、少人数の開発チームにおける生産性と品質の向上に取り組みました。 ### 課題 少人数のチームで、機能開発、問い合わせ対応、障害対応、コードレビューを並行して行っていました。 特定のエンジニアへ調査やレビューが集中すると、通常の機能開発が停滞する可能性がありました。 一方で、AIの出力を無条件に採用すると、不正確な設計やコードが混入する危険があるため、人間による確認を前提とした利用方法を整える必要がありました。 ### 自身が行ったこと AIを以下の開発工程に導入しました。 - 既存コードや仕様の調査 - 設計案の整理 - コードの生成・修正 - テスト観点の洗い出し - Pull Requestのレビュー支援 AIの回答をそのまま採用するのではなく、既存仕様との整合性、影響範囲、セキュリティ、保守性をエンジニアが確認したうえで利用しました。 AIへ渡す情報や依頼内容を整理し、開発者ごとに利用方法が大きく異ならないよう、チーム内で活用方法を共有しました。 ### 使用技術と使用場面 - **生成AI** - 設計案や実装方針の整理 - コード生成・修正支援 - テスト観点の抽出 - Pull Requestレビュー支援 - **GitHub** - Pull Request上でのコードレビュー - AIが提示した修正内容の確認 - 変更履歴の管理 ### 成果 調査、設計、実装、レビューの一部をAIで支援し、少人数チームにおける開発負荷を軽減しました。 人間による確認を前提とすることで、品質を維持しながらAIを開発プロセスへ組み込みました。 ## 開発・実装内容4：DevinとDatadog MCPを利用した障害対応の一部自動化 ### 概要 サービス運用中に発生した障害について、Datadogの監視情報とDevinを連携させ、初期調査の一部を自動化しました。 ### 課題 障害発生時には、エンジニアがDatadogを確認し、対象のエラー、関連ログ、発生条件、影響範囲を調査する必要がありました。 その後、コードベースから関連処理を探し、原因候補や修正方法を検討していました。 少人数のチームでは、障害調査によって通常開発が中断されることがあり、初動に必要な情報収集を効率化する必要がありました。 ### 自身が行ったこと DevinとDatadog MCPを連携し、AIエージェントがDatadogからエラーやログを取得できる仕組みを導入しました。 障害発生時に、以下の作業を支援できるようにしました。 - エラー情報の取得 - 関連ログの確認 - 発生条件や影響範囲の整理 - 関連コードの調査 - 原因候補の提示 - 修正案の作成 AIが作成した調査結果や修正案は、エンジニアが内容を確認し、必要に応じて修正したうえで対応しました。 AIが自動的に本番環境を変更するのではなく、人間によるレビューと承認を必須としました。 ### 使用技術と使用場面 - **Datadog** - エラー監視 - アプリケーションログの取得 - 障害の発生状況や影響範囲の確認 - **MCP** - Datadogの監視情報をDevinから参照するための連携 - **Devin** - ログとコードベースの調査 - 原因候補の整理 - 修正案の作成 - **GitHub** - 修正差分の確認 - コードレビュー - 変更履歴の管理 ### 成果 障害調査の初動に必要な情報収集と原因候補の整理を一部自動化しました。 エンジニアがログや関連コードを手作業で探す負担を減らし、障害対応にかかる運用負荷を軽減しました。 ## 開発・実装内容5：Trivyによる脆弱性検知の自動化 ### 概要 依存ライブラリやコンテナイメージの脆弱性をリリース前に検知するため、Trivyを開発プロセスへ導入しました。 ### 課題 脆弱性確認が開発者による手作業や個別の確認に依存しており、確認漏れが発生する可能性がありました。 また、リリース直前や定期的な確認だけでは、脆弱性を含む変更がコードベースへ取り込まれた時点で検知できませんでした。 ### 自身が行ったこと TrivyをGitHub Actionsへ組み込み、すべてのPull Requestで脆弱性スキャンを自動実行するワークフローを作成しました。 Pull Requestの作成・更新時に検査を行い、開発者が通常のコードレビュー工程の中で検出結果を確認できるようにしました。 脆弱性が検出された場合は、対象となる依存ライブラリやコンテナを確認し、必要に応じてバージョン更新や修正を行う運用としました。 ### 使用技術と使用場面 - **Trivy** - 依存ライブラリの既知脆弱性検知 - コンテナイメージの脆弱性検知 - **GitHub Actions** - Pull Request作成・更新時の自動スキャン - 検査処理のCIへの組み込み - **GitHub** - 検出結果の確認 - コードレビュー - 修正履歴の管理 ### 成果 脆弱性確認を開発者個人の任意作業から、標準の開発プロセスへ組み込みました。 すべてのPull Requestを継続的に検査し、脆弱性をリリース前に検知できる状態を構築しました。

# 運送会社向けクラウド業務支援システム「トラッカーズマネージャー」の開発・運用 ## プロジェクト概要 運送会社の日常業務を支援するクラウドサービス「トラッカーズマネージャー」の開発・運用を担当しました。 既存サービスの機能改修、顧客や社内担当者からの問い合わせ調査、障害対応、運用改善に従事しました。特に、トラックドライバーに対する法定12項目の安全教育を支援するeラーニング機能の改修を担当しました。 チームリーダー兼CREとして、利用者や社内担当者へのヒアリング、要望の背景確認、既存仕様の調査、要件整理、設計、実装、コードレビュー、リリース後の確認まで一貫して対応しました。 依頼された内容をそのまま実装するのではなく、実際の業務上の課題、既存利用者への影響、他社でも利用できる共通性、将来の保守性を踏まえて対応方針を判断しました。 ## チーム情報 - エンジニア：3名 - 自身の役割：チームリーダー兼CRE - 主な連携先：顧客企業、営業担当、カスタマーサポート、社内運用担当 - 担当工程：ヒアリング、要件整理、設計、実装、コードレビュー、リリース、障害対応、運用改善 ## 使用技術 - Ruby on Rails - TypeScript - React - AWS - RDB - Datadog - GitHub ## 開発・実装内容1：安全教育eラーニング機能の改修 ### 概要 運送事業者がトラックドライバーへの法定安全教育を実施するためのeラーニング機能について、既存機能の改修を担当しました。 運送会社が日常業務の中で継続的に利用する機能であるため、画面や処理を変更するだけではなく、実際の教育手順や既存データへの影響を確認しながら対応しました。 ### 課題 顧客や社内担当者から、既存のeラーニング機能に関する問い合わせや改善要望が寄せられていました。 一方、依頼された変更だけを実装すると、実際の教育運用上の問題を解決できなかったり、既存の受講フローや利用中のデータに影響したりする可能性がありました。 そのため、利用者がどのような手順で教育を実施しているか、どの時点で問題が発生しているかを確認したうえで、改修範囲を判断する必要がありました。 ### 自身が行ったこと 顧客や社内担当者へのヒアリングを行い、要望の内容だけでなく、現在の運用方法、問題が発生する条件、利用者が期待する結果を整理しました。 既存コード、画面遷移、データ構造を調査し、変更対象となるバックエンド処理、画面、既存データへの影響範囲を確認しました。 Ruby on Railsによる業務ロジックとデータ更新処理、TypeScript・Reactによる画面表示や操作処理を改修しました。 リリース前には既存の受講フローへの影響を確認し、リリース後も問い合わせやエラーの有無を確認しました。 ### 使用技術と使用場面 - **Ruby on Rails** - eラーニング機能の業務ロジック - データ取得・更新処理 - 既存機能の改修 - **TypeScript・React** - 利用者向け画面の表示制御 - 入力処理 - 操作フローの改修 - **RDB** - 受講情報などの既存データ確認 - 改修による影響範囲の調査 - **AWS** - Webサービスの実行環境 - **Datadog** - リリース後のエラーや動作状況の調査 ### 成果 利用者の実際の教育業務を踏まえて既存機能を改善し、運送会社が継続して利用できるサービスの維持・改善に貢献しました。 また、ヒアリングから実装、リリース後の確認まで一貫して担当することで、利用者の要望と開発側の認識のずれを減らしました。 ## 開発・実装内容2：顧客問い合わせを起点とした既存機能の改善 ### 概要 CREとして、顧客企業や社内担当者から寄せられる問い合わせ、不具合報告、機能要望について、調査と改善を担当しました。 ### 課題 顧客からの問い合わせには、さまざまな原因が混在していました。 - システム上の不具合 - データの登録状態に起因する問題 - 既存仕様と利用者の認識の違い - 操作方法や社内運用に起因する問題 - 新たな機能開発が必要な業務課題 問い合わせ内容だけを見て機能を変更すると、根本原因を解決できなかったり、特定顧客専用の処理が増えて保守性が低下したりする可能性がありました。 ### 自身が行ったこと 利用者が行った操作、対象データ、発生日時、期待していた結果などを確認し、問題の再現条件を整理しました。 Datadogのログ、データベースの状態、既存コードを調査し、不具合、データ、仕様、運用のどこに原因があるかを切り分けました。 改修が必要な場合は、以下の観点から対応方針を検討しました。 - 他の顧客にも利用できる共通機能にできるか - 既存機能への影響を抑えられるか - 設定や運用方法の変更で対応できないか - 将来の保守負荷が過大にならないか 設計・実装後はコードレビューと動作確認を行い、リリース後の問い合わせやエラーも確認しました。 ### 使用技術と使用場面 - **Ruby on Rails** - 業務ロジックの調査 - 不具合修正 - 既存機能の改修 - **TypeScript・React** - 画面上の問題調査 - 表示・操作処理の改修 - **Datadog** - エラー発生時刻の確認 - ログ、例外情報、処理状況の調査 - **RDB** - 対象データの状態確認 - 処理結果やデータ不整合の調査 - **GitHub** - 変更履歴の管理 - コードレビュー - 修正内容の共有 ### 成果 問い合わせを一時的な個別対応で終わらせず、必要に応じて既存機能や運用方法の改善につなげました。 技術面と業務面の両方から原因を整理することで、不要な個別開発を抑えながら、利用者の課題解決とサービスの安定運用に貢献しました。 ## 開発・実装内容3：障害調査と安定運用 ### 課題 既存サービスでは、利用者からの申告だけでは、システム不具合、データ状態、操作方法のどこに原因があるか判断できないケースがありました。 少人数のチームで機能開発と運用を並行していたため、障害調査を効率的に進め、通常の開発への影響を抑える必要がありました。 ### 自身が行ったこと Datadogのエラー情報やアプリケーションログ、データベースの状態、関連コードを確認し、発生条件と影響範囲を特定しました。 緊急性が高い場合は暫定対応と恒久対応を分け、まず利用者への影響を抑えたうえで、原因となった処理の修正や再発防止を行いました。 修正時には、同様の処理やデータで同じ問題が発生しないかを確認し、影響範囲を限定したうえでリリースしました。 ### 成果 問い合わせや障害に対し、原因の切り分けから修正、リリース後の確認まで継続して対応し、既存サービスの安定運用に貢献しました。

# 人材紹介会社における社内システム・データ基盤の開発 ## プロジェクト概要 人材紹介事業を運営する株式会社プレックスにて、コーポレートエンジニアとして社内システムの開発・運用を担当しました。 社内約200名が利用する業務環境を対象に、社内ユーザーへのヒアリング、業務課題の整理、要件定義、設計、実装、リリース、運用まで一貫して担当しました。 主な取り組みとして、求職者から届くLINEメッセージをSlackへ連携する社内システムの開発と、KintoneのデータをBigQueryへ連携するためのAirbyteコネクタの開発・データ基盤構築を行いました。 各施策について、要件整理から設計、バックエンド・フロントエンドの実装、リリースまでを単独で担当しました。 ## チーム情報 - チーム人数：4名 - 自身の役割：コーポレートエンジニア - 対象利用者：社内約200名 - 主な連携先： - 人材紹介事業の各部門 - キャリアアドバイザー - 営業担当者 - 社内システム利用者 - 担当工程： - 社内ユーザーへのヒアリング - 業務課題の整理 - 要件定義 - 設計 - 実装 - テスト - リリース - 運用・改善 ## 使用技術 - Ruby on Rails - React - Python - LINE Messaging API - Slack API - Heroku - Vercel - BigQuery - Airbyte - Kintone - GitHub ## 開発・実装内容1：LINE Messaging APIとSlackを連携したメッセージ確認システム ### 概要 求職者からLINEで届くメッセージをSlackへ連携し、社内担当者が普段利用しているSlack上で確認できる社内システムを開発しました。 バックエンドにはRuby on RailsとHeroku、フロントエンドにはReactとVercelを使用し、要件整理から設計、実装、リリースまでを単独で担当しました。 ### 課題 人材紹介業務では、多数の求職者とLINEを通じて継続的にコミュニケーションを取っていました。 一方、求職者から届いたメッセージの確認経路と、社内で日常的に使用しているコミュニケーション環境が分かれていたため、担当者がメッセージを確認する際の負担や、確認漏れが発生する可能性がありました。 社内担当者が普段利用しているSlack上で求職者からのメッセージを確認できるようにし、既存の業務フローへ自然に組み込む必要がありました。 ### 自身が行ったこと 社内ユーザーへのヒアリングを行い、求職者からのメッセージを誰が、どのタイミングで、どのように確認しているかを整理しました。 ヒアリング結果をもとに、LINE Messaging APIで受信したメッセージをバックエンドで処理し、対応する情報をSlackへ通知する仕組みを設計しました。 バックエンドをRuby on Railsで実装し、Heroku上で運用しました。 フロントエンドはReactで実装し、Vercel上へデプロイしました。 設計から実装、テスト、リリースまでを単独で担当し、リリース後も社内ユーザーからのフィードバックを受けて改善しました。 ### 使用技術と使用場面 - **Ruby on Rails** - LINEから受信したメッセージの処理 - 社内データとの連携 - Slackへ送信する通知内容の生成 - バックエンドAPIの実装 - **LINE Messaging API** - 求職者から送信されたメッセージの受信 - LINE上で発生したイベントの取得 - **Slack API** - 求職者から届いたメッセージのSlackへの連携 - 社内担当者が確認するための通知処理 - **React** - 関連する社内向けWeb画面の実装 - フロントエンドの表示・操作処理 - **Heroku** - Ruby on Railsで開発したバックエンドの実行環境 - **Vercel** - Reactで開発したフロントエンドのホスティング環境 ### 成果 求職者からLINEで届いたメッセージを、社内担当者が普段利用しているSlack上で確認できるようにしました。 メッセージ確認の導線を日常的な業務環境へ統合し、社内約200名規模の人材紹介業務における情報確認を支援しました。 定量的な削減効果は計測していませんが、複数のサービスを行き来してメッセージを確認する負担や、確認漏れが発生するリスクの軽減に貢献しました。 ## 開発・実装内容2：KintoneとBigQueryを連携するAirbyteコネクタの開発 ### 概要 社内業務で利用していたKintoneのデータをBigQueryへ取り込み、分析や集計に利用するためのデータ基盤を構築しました。 KintoneのデータをAirbyte経由でBigQueryへ連携するため、Pythonを使用してAirbyte用のKintoneコネクタを開発しました。 要件整理、データ連携方式の設計、Pythonによるコネクタ実装、BigQueryへのデータ取り込みまでを単独で担当しました。 ### 課題 人材紹介業務に関するデータがKintoneなどの社内システムに保存されていましたが、システム内に分散した状態では、複数のデータを組み合わせた集計や分析を行いにくいという課題がありました。 KintoneのデータをBigQueryへ集約する必要がありましたが、AirbyteからKintoneのデータを取得するための連携処理を用意する必要がありました。 また、単発でデータを移行するのではなく、業務で更新されるデータを継続的に取り込める仕組みにする必要がありました。 ### 自身が行ったこと 社内ユーザーやデータ利用者へのヒアリングを行い、分析対象となるデータ、必要な項目、更新方法を整理しました。 Kintoneのデータ構造とAPIの仕様を調査し、Airbyteからデータを取得するためのコネクタをPythonで設計・実装しました。 開発したコネクタをAirbyteへ組み込み、Kintoneから取得したデータをBigQueryへ連携できるようにしました。 BigQuery上では、取得したデータを分析・集計に利用できるよう、データの格納方法や利用単位を整理しました。 要件整理、設計、実装、接続確認、リリースまでを単独で担当しました。 ### 使用技術と使用場面 - **Python** - Airbyte用Kintoneコネクタの開発 - Kintone APIからのデータ取得処理 - 取得データをAirbyteで扱うための変換処理 - **Airbyte** - KintoneからBigQueryへのデータ連携 - データ取り込み処理の実行基盤 - **Kintone** - 人材紹介業務に関する社内データの管理 - BigQueryへ連携する元データの取得 - **BigQuery** - Kintoneなどの社内データの集約 - データ分析・集計に利用するための保存基盤 ### 成果 Kintoneの業務データをAirbyte経由でBigQueryへ取り込める仕組みを構築しました。 既存の社内システムに保存されていたデータを、BigQuery上で分析・集計に利用できる状態にしました。 また、Airbyteの標準機能だけでは不足していたKintoneとの接続部分をPythonによる独自コネクタで補い、データ連携基盤を拡張しました。 ## 開発・実装内容3：社内ユーザーへのヒアリングを起点とした業務改善 ### 概要 コーポレートエンジニアとして、社内約200名の利用者から寄せられる要望や業務上の課題を確認し、社内ツールの開発・改善を行いました。 ### 課題 社内から寄せられる要望は、必ずしもシステム改修だけで解決できるものではありませんでした。 要望された機能をそのまま実装すると、特定の利用者だけに適した処理となったり、既存業務との重複や保守負荷の増加につながったりする可能性がありました。 そのため、要望の背景にある業務上の課題を確認し、システム開発、既存機能の変更、運用方法の見直しのうち、適切な対応を判断する必要がありました。 ### 自身が行ったこと 社内ユーザーへのヒアリングを行い、現在の業務手順、利用中のシステム、手作業が発生している箇所、期待する状態を整理しました。 ヒアリング内容をもとに、システムで対応すべき範囲を定義し、必要に応じて画面、API、データ連携処理を設計・実装しました。 開発後は実際の利用者へ確認を行い、業務上の問題が解消されているかを確認しながら改善しました。 ### 成果 依頼された機能をそのまま作るのではなく、業務上の課題や利用者の運用を確認したうえで、社内システムの開発・改善を行いました。 LINE・Slack連携やデータ基盤構築を通じて、社内約200名規模の人材紹介業務を技術面から支援しました。

# 高速バス予約管理システム「発車オーライネット」の開発・運用 ## プロジェクト概要 高速バスの予約・運行業務を支援する「発車オーライネット」の開発・運用を担当しました。 既存のWindowsアプリケーションからWebアプリケーションへのリプレース、高速バス予約サイトと接続するコントローラーの開発、外部のダイナミックプライシングサービスとのAPI連携、リリース後の障害調査・改修に従事しました。 チームリーダーとして、バス会社ごとの業務要件のヒアリング、顧客との仕様調整、他部門との連携、開発方針の整理、進捗管理を担当しました。自身も設計・実装・データ移行・リリース後の不具合対応を行うプレイングリーダーとして開発に参加しました。 既存の業務を停止させずにシステムを移行する必要があったため、旧システムの仕様やデータ構造を調査し、既存利用者への影響を抑えながら段階的にリプレースを進めました。 ## チーム情報 - エンジニア：4名 - 自身の役割：チームリーダー兼開発担当 - 主な連携先： - バス会社の担当者 - 社内の営業・導入支援部門 - 他システムの開発担当者 - 外部サービス事業者 - 担当工程： - 顧客ヒアリング - 要件整理 - 仕様調整 - 設計 - 実装 - データ移行 - コードレビュー - 進捗管理 - リリース - 障害調査・改修 ## 使用技術 - VB.NET - C# - Angular - RDB - 外部Web API - Windowsアプリケーション - Webアプリケーション ## 開発・実装内容1：WindowsアプリケーションからWebアプリケーションへのリプレース ### 概要 VB.NETで開発された既存のWindowsアプリケーションを、C#とAngularを使用したWebアプリケーションへリプレースしました。 顧客へのヒアリング、既存仕様の調査、要件整理、設計、実装、データ移行、リリースまで担当しました。 ### 課題 既存システムはWindowsアプリケーションとして構築され、バス会社ごとの専用環境や専用線を前提としていました。 そのため、次のような課題がありました。 - 専用端末や専用線に依存しており、利用場所や端末に制約がある - バス会社ごとに異なる業務要件や運用方法が存在する - 長期間の機能追加により、既存仕様や処理の依存関係が複雑になっている - 新システムへの移行時も、既存業務と既存データを維持する必要がある - リプレース期間中も、現行システムを安定して運用する必要がある 単純に既存画面をWeb化するだけではなく、実際の業務フローを確認し、Web化に合わせて処理や操作方法を再設計する必要がありました。 ### 自身が行ったこと バス会社の担当者へヒアリングを行い、既存システムの利用手順、会社ごとの業務要件、操作上の問題点を整理しました。 既存のVB.NETコード、画面、データ構造を調査し、新システムへ移行する機能と、変更・廃止する機能を整理しました。 バックエンドをC#、フロントエンドをAngularで構築し、Windowsアプリケーションに依存していた処理をWebアプリケーションとして再実装しました。 また、既存システムから新システムへデータを移行するため、旧DBと新DBの項目対応やデータ形式の差異を確認し、移行対象と変換方法を整理しました。 チームリーダーとして、メンバーへのタスク割り当て、進捗確認、設計・実装内容の確認を行いながら、自身も設計・実装を担当しました。 ### 使用技術と使用場面 - **VB.NET** - 既存Windowsアプリケーションのコード調査 - 現行仕様と業務ロジックの把握 - リプレース対象機能の特定 - **C#** - Webアプリケーションのバックエンド処理 - 業務ロジックとデータ取得・更新処理の実装 - 既存処理の移植と再設計 - **Angular** - 利用者向けWeb画面の実装 - 入力、検索、一覧表示などの操作処理 - タブレットを含むWebブラウザからの利用対応 - **RDB** - 旧システムと新システムのデータ構造調査 - データ移行 - 移行前後のデータ整合性確認 ### 成果 WindowsアプリケーションからWebアプリケーションへのリプレースを行い、専用線を前提とした構成からインターネット経由で利用できる構成へ移行しました。 これにより、専用線に関する運用コストを削減するとともに、タブレットからの利用を可能にし、乗務員や現場担当者の業務負担軽減に貢献しました。 また、既存コードと業務ロジックを整理しながら再実装することで、技術的負債を解消し、保守性とリリース後の安定性を向上させました。 ## 開発・実装内容2：ダイナミックプライシングサービスとのAPI連携 ### 概要 高速バスの販売価格を需要などに応じて変更するダイナミックプライシングサービスから、価格情報を取り込むためのAPI連携機能を開発しました。 外部サービスのAPI仕様を確認し、発車オーライネット側のデータ構造や既存処理との対応関係を整理したうえで、データ取り込み機能を実装しました。 ### 課題 ダイナミックプライシングサービスが管理する価格情報を、高速バス予約システムへ正しく反映する必要がありました。 一方、外部サービスと発車オーライネットでは、路線、便、運行日、座席、運賃などのデータの持ち方や識別方法が異なるため、APIから取得した情報をそのまま利用することはできませんでした。 また、次のようなケースも考慮する必要がありました。 - 対象となる便や運行日を特定できない - 外部APIから想定外のデータが返される - 外部サービスと内部システムでデータの更新タイミングが異なる - 取り込み後の価格が既存の予約・販売処理へ影響する - リリース後に、外部仕様やデータ状態に依存した不具合が発生する ### 自身が行ったこと 外部サービスのAPI仕様と、発車オーライネット側の既存仕様・データ構造を調査しました。 APIから取得する価格情報と、路線、便、運行日などの内部データとの対応関係を整理し、取り込み時の判定処理とデータ更新処理を設計・実装しました。 顧客や他部門と連携し、どの時点の価格をどの処理へ反映するか、データを特定できない場合にどのように扱うかなどの業務ルールを整理しました。 リリース後に不具合が発生した際には、APIのリクエスト・レスポンス、対象データ、既存コードを調査し、外部サービス側と自社システム側のどこに原因があるかを切り分けました。 原因を特定したうえで処理を改修し、影響範囲を確認して再リリースしました。 ### 使用技術と使用場面 - **外部Web API** - ダイナミックプライシングサービスからの価格情報取得 - 外部サービスとのデータ連携 - **C#** - API呼び出し処理 - 取得データの変換・検証 - 発車オーライネット側へのデータ反映処理 - **RDB** - 路線、便、運行日、価格情報の対応付け - 取り込み前後のデータ確認 - 不具合発生時の対象データ調査 ### 成果 外部のダイナミックプライシングサービスが算出した価格情報を、発車オーライネットへ取り込めるようにしました。 リリース後に発生した不具合についても、外部API、内部データ、既存処理を横断して原因を調査し、改修から再リリースまで対応することで、連携機能の安定運用に貢献しました。 ## 開発・実装内容3：技術的負債の解消と保守性向上 ### 課題 長期間運用されてきたシステムでは、機能追加や顧客別対応の積み重ねにより、処理の依存関係が複雑になっていました。 既存仕様がコード上で明確に分離されていない箇所もあり、機能改修時の影響範囲が分かりにくく、不具合を生む原因となっていました。 ### 自身が行ったこと 機能追加や不具合対応の際に、対象箇所だけを修正するのではなく、関連コードやデータ構造を確認し、重複処理や複雑な条件分岐を整理しました。 既存の動作を維持する必要があるため、一度に全面的な変更を行うのではなく、影響範囲を限定しながら段階的にリファクタリングしました。 リプレース開発では、旧システムの仕様をそのまま移植するのではなく、現在の業務で必要な処理を整理したうえで、新しい構成に合わせて再設計しました。 ### 成果 リプレースと継続的なリファクタリングを通じて、既存システムの技術的負債を解消し、機能追加や不具合対応を行いやすい状態へ改善しました。 変更による影響範囲を把握しやすくすることで、保守性とリリース後の安定性向上に貢献しました。

# 宿泊業向け予約サイトコントローラー「手間いらず」の開発・運用 ## プロジェクト概要 宿泊施設が複数の予約サイトやホテルシステムを一元管理するための、宿泊業向け予約サイトコントローラー「手間いらず」の開発・運用を担当しました。 8名の開発チームのメンバーとして、外部の予約サイトおよびホテルシステムとのAPI連携を担当しました。連携先企業との仕様調整、既存システムの調査、連携仕様の策定、設計、実装、テスト、リリースまで一貫して対応しました。 担当した連携先は3システムで、PHPおよびSymfonyをベースとした独自フレームワークを使用して、REST APIやXML形式のデータを扱う連携機能を開発しました。 リリース後には、APIの通信内容、アプリケーションログ、MySQL上のデータなどを調査し、不具合の原因特定、改修、テスト、再リリースまで対応しました。 外部システムごとにAPI仕様、データ形式、項目の定義、更新タイミングが異なるため、双方の仕様を整理し、「手間いらず」側の共通的なデータ構造や業務処理へ変換することを重視しました。 ## チーム情報 - チーム人数：8名 - 自身の役割：開発メンバー - 担当した連携先：3システム - 主な連携先： - 外部予約サイトの開発担当者 - ホテルシステムの開発担当者 - 社内の営業・導入支援担当者 - 担当工程： - 外部サービスとの仕様調整 - 既存仕様の調査 - 連携仕様の策定 - 設計 - 実装 - テスト - リリース - 不具合調査 - 改修 - 再リリース ## 使用技術 - PHP - Symfonyベースの独自フレームワーク - MySQL - REST API - XML - Git - Jenkins ## 開発・実装内容1：予約サイト・ホテルシステムとのAPI連携開発 ### 概要 外部の予約サイトやホテルシステムと「手間いらず」の間で、予約関連データを連携する機能を開発しました。 連携先企業と協力しながらAPI仕様を確認し、外部システムと「手間いらず」のデータ構造や業務ルールの違いを整理したうえで、連携仕様の策定、設計、実装、接続試験、リリースまで担当しました。 在籍期間中に、合計3システムとのAPI連携開発を担当しました。 ### 課題 予約サイトやホテルシステムごとにAPI仕様やデータの持ち方が異なっていたため、外部システムから受信したデータをそのまま「手間いらず」へ登録することはできませんでした。 同じ予約関連情報でも、連携先によって次のような違いがありました。 - 項目名やデータ形式 - 必須項目と任意項目 - 外部システム側の識別子 - 予約の登録・変更・取消の表現方法 - APIを実行するタイミング - エラー時のレスポンス形式 - REST APIやXMLの構造 また、「手間いらず」は複数の外部システムと連携する既存サービスであるため、新しい連携機能を追加する際にも、既存の予約処理や他の連携先へ影響を与えないようにする必要がありました。 ### 自身が行ったこと 連携先企業の開発担当者と、連携対象となるデータ、APIの呼び出し方法、処理の実行タイミング、エラー時の取り扱いについて調整しました。 外部APIの仕様と「手間いらず」側の既存コード、データ構造、業務処理を調査し、次の内容を設計しました。 - 外部データと内部データの項目対応 - 外部システムのIDと内部データの対応付け - REST APIのリクエスト・レスポンス処理 - XMLデータの解析・生成処理 - 外部データを内部形式へ変換する処理 - 必須項目や値の検証処理 - 予約の登録・変更・取消に応じた処理 - 外部APIでエラーが発生した場合の処理 - 既存の連携機能へ影響を与えないための実装方法 PHPおよびSymfonyベースの独自フレームワークを使用して、APIの呼び出し、XMLデータの解析、データ変換、検証、MySQLへの登録・更新処理を実装しました。 実装後は連携先企業と接続試験を行い、正常系だけでなく、必須データの不足、想定外の値、予約の変更・取消なども含めて、双方のシステムでデータが正しく処理されることを確認しました。 Gitでソースコードを管理し、Jenkinsを利用した既存の開発・リリースフローに沿ってテストとリリースを行いました。 ### 使用技術と使用場面 - **PHP** - 外部APIの呼び出し - リクエスト・レスポンス処理 - 予約データの変換・検証 - MySQLへのデータ登録・更新 - エラー処理 - **Symfonyベースの独自フレームワーク** - API連携機能の実装 - 既存の予約処理やデータアクセス処理との統合 - 既存システムの構成に沿った機能追加 - **REST API** - 外部予約サイトやホテルシステムとのデータ送受信 - 予約関連情報の取得・登録・更新 - **XML** - 外部システムとの連携データの解析 - APIへ送信するデータの生成 - 外部形式と内部形式の相互変換 - **MySQL** - 予約情報や外部システムとの対応情報の取得・更新 - API連携前後のデータ確認 - 不具合発生時の対象データ調査 - **Git** - ソースコードと変更履歴の管理 - チーム内での変更内容の共有 - **Jenkins** - 既存の継続的インテグレーション環境でのテスト - ビルド・リリース作業 ### 成果 3つの外部予約サイト・ホテルシステムとのAPI連携機能を開発し、「手間いらず」が対応できる外部サービスの拡充に貢献しました。 連携先企業との仕様調整から設計、実装、接続試験、リリースまで担当し、異なるシステム間の仕様やデータ形式の違いを吸収して、既存サービスへ連携機能を追加しました。 ## 開発・実装内容2：リリース後の不具合調査と改修 ### 概要 API連携機能のリリース後に発生した不具合やデータ不整合について、原因調査、改修、テスト、再リリースまで担当しました。 ### 課題 外部システムとのAPI連携では、開発時の接続試験だけでは網羅できないデータや、連携先固有の運用によって不具合が発生することがありました。 不具合の原因として、次のような複数の可能性がありました。 - 「手間いらず」側の実装 - 外部システム側の実装 - 双方の仕様認識の違い - XMLの構造や値の違い - 想定していなかった予約データ - MySQL上のデータ状態 - APIを実行する順序やタイミング - 予約の変更・取消に関する処理 そのため、自社システムのコードだけでなく、外部APIの通信内容やデータベースの状態を横断して原因を調査する必要がありました。 ### 自身が行ったこと 不具合発生時には、対象となる宿泊施設、予約データ、連携先、発生日時、実行された処理、期待される結果を確認しました。 REST APIのリクエスト・レスポンスやXMLデータ、アプリケーションログ、MySQL上のデータ、関連するPHPコードを調査し、問題の発生箇所を切り分けました。 連携先の確認が必要な場合は、発生条件、対象データ、実際の通信内容、期待する結果を整理して共有し、連携先企業と協力して原因を調査しました。 自社側に原因がある場合は、既存の予約処理や他の連携先への影響範囲を確認したうえで改修しました。 改修後は、問題が発生したデータだけでなく、正常な予約、変更、取消などの既存処理もテストし、Jenkinsを利用した既存のリリースフローに沿って再リリースしました。 ### 使用技術と使用場面 - **REST API・XML** - 外部システムとの通信内容の確認 - リクエストとレスポンスの仕様確認 - 送受信されたデータの調査 - **PHP** - 不具合が発生した処理の特定 - データ変換や条件分岐の改修 - エラー処理の修正 - **MySQL** - 対象となる予約データの確認 - API連携前後のデータ比較 - データ不整合の原因調査 - **Git** - 修正内容と変更履歴の管理 - **Jenkins** - 改修後のテスト - 再リリース作業 ### 成果 外部システムとのAPI連携で発生した不具合について、通信内容、XMLデータ、MySQL上のデータ、PHPコードを横断して原因を調査しました。 連携先企業とも協力しながら原因を切り分け、改修から再リリースまで対応することで、API連携機能の安定運用と宿泊施設の予約管理業務の継続に貢献しました。