ID:82877さん

# 新規メニュー「海外旅行保険」システム開発 ## プロジェクト概要 トラベルコ（旅行比較サービス）における海外旅行保険メニューの新規立ち上げ。 自社初の保険商品比較・検索機能として、要件定義〜設計〜実装〜リリースまでを システムメイン担当として一貫して主導した。 SP版を先行リリース後、PC版を追加リリース。 ## チーム情報 - 全体：14名（ビジネスサイド：10名 / 開発：4名） - 役割：開発リーダー（サーバーサイドメイン担当） - フロントエンド（React）はメインは別担当。自身はサーバーサイドをメインとしつつ、要所でReact改修も対応。 --- ## 開発・実装内容A：保険料自動計算ロジックの設計・実装 ### 概要 競合他社調査をもとに、自社オリジナル機能として「検索条件に応じた保険料をリアルタイム自動計算し、 複数保険会社のプランを比較一覧表示する」仕組みを設計・実装した。 ### どのような機能の開発・実装か ユーザーが旅行先（国・地域）・旅行期間・加入タイプ（一人／家族／グループ）・人数を入力すると、 各保険会社のプランごとの保険料をサーバーサイドで動的に計算し、比較一覧として表示する機能。 ### 課題・問題点 保険料の計算ルールが複雑で、単純な「基本保険料 × 期間」では対応できなかった。 具体的には以下の仕様が絡み合っていた。 - 加入タイプ・人数による料率の違い：一人・家族・グループでそれぞれ料率が異なる - 国・期間の組み合わせによる変動：渡航先の国と旅行期間の組み合わせで保険料が変わる - 複数国周遊時の仕様：複数の国をまたぐ場合、最も保険料の高い国のプランが適用される - 要件が開発途中で変化し、設計変更に柔軟に対応する必要があった ### 対応・実装内容・使用した技術 上記の複雑な計算仕様に対し、以下の設計で対応した。 - 加入タイプ×人数の配列管理：加入タイプ（一人／家族／グループ）と人数をキーとした配列を保持し、 該当人数が存在する場合に料率を掛け合わせる方式を採用。 タイプごとの分岐をシンプルに管理できる構造とし、仕様変更にも対応しやすい設計とした。 - 周遊時の最大値選択ロジック：複数国が選択された場合、対象国リストの中から 保険料が最高となる国のプランを自動選択する処理を実装。 - DB設計：国・期間・加入タイプをキーとした料率マスタテーブルを定義。 営業担当と連携してデータを棚卸しし、GASを用いたマスタ登録フローも整備。 - 使用技術：PHP（サーバーサイド）、PostgreSQL、React（フロントとのAPI連携・要所の改修） ### 成果 - 複雑な料率体系を持つ複数の保険会社プランを横並びで比較できる一覧表示を実現 - SP版を先行リリース後、PC版も追加リリースを完遂 --- ## 開発・実装内容B：国・地域マスタおよびLP自動生成の設計 ### 概要 SEO・LP展開を見据え、国・地域マスタデータから検索結果ページ（LP）を 自動生成する仕組みを設計した。 ### どのような機能の開発・実装か 国や地域ごとのマスタデータを登録すると、対応するLPの検索結果が自動で構成される仕組み。 手動でLP個別対応する運用工数を削減することが目的。 ### 課題・問題点 - 対象となる国・地域数が多く、個別対応ではスケールしない - スケジュール制約の中で、LP自動生成ロジックと検索ロジックを並行開発する必要があった - 要件定義会議でシステム側として実現方法・工数・スケジュールを即座に提示する必要があった ### 対応・実装内容・使用した技術 - 国・地域マスタのDB定義を設計し、パラメータに基づいて検索条件を自動セットする処理を実装 - 要件定義会議にシステム担当として参加し、実現方法・工数・スケジュールの観点から提案・主導 - GASを活用してマスタデータ登録・管理フローを整備し、手動入力コストを削減 ### 成果 - マスタデータ登録だけで対応LPが展開できる仕組みを構築し、運用効率を向上 - リリース後の国・地域追加対応をエンジニア工数なしで対応できる設計を実現 --- ## プロジェクト全体の成果 - 自社初となる保険比較メニューの立ち上げをシステム面から主導し、新規事業の基盤構築に貢献 - 要件変更が続く中でもスケジュールを守り、SP版・PC版ともにリリースを完遂 - 使用技術：PHP、PostgreSQL、React、GAS、Linux

# ツアーAPI検索 ## プロジェクト概要 トラベルコにおけるツアー商品情報のリアルタイム更新基盤の設計・開発。 当初はリアルタイムAPI連携を目指して設計を進めたが、外部要因による方針転換を経て、 各旅行会社の入稿頻度を最適化する形でデータ鮮度を向上させるシステムを構築した。 ## チーム情報 - 全体：18名（ビジネスサイド：13名 / 開発：5名） - 役割：開発リーダー（進捗管理・タスク割り当て・設計・実装） --- ## 開発・実装内容A：リアルタイム取得基盤の設計（ポーリング方式） ### 概要 旅行会社の商品情報をリアルタイムに取得・反映するため、 ポーリング方式によるデータ取得基盤を設計・実装した。 ### どのような機能の開発・実装か 自社サーバーから旅行会社のAPIに対して約3秒間隔でポーリングを行い、 最新の商品情報を取得する仕組み。取得したデータはキャッシュ用DBに一時保存し、 表示側はキャッシュDBを参照することでAPIへの直接負荷を避ける構成とした。 ### 課題・問題点 - 連携先の旅行会社がリアルタイムでのAPI提供に対応できないことが判明 - ポーリングの実装は完了していたが、相手側の制約により本番運用ができない状態になった - リアルタイム連携を前提とした設計・実装をゼロベースで見直す必要があった ### 対応・実装内容・使用した技術 - キャッシュ用DBを別途設計し、ポーリング取得データの一時保存・参照の分離構造を実装 - 連携先企業の制約が判明した段階で即座に方針転換を判断し、代替案を設計・提案 - 使用技術：PHP、PostgreSQL（キャッシュDB設計）、Linux --- ## 開発・実装内容B：方針転換後の入稿頻度最適化による情報鮮度改善 ### 概要 リアルタイムAPI連携が困難となったため、旅行会社側にファイル形式での定期入稿を依頼する方式に切り替え。 各社の入稿頻度を最適化することで、商品情報の鮮度向上を実現した。 ### どのような機能の開発・実装か 旅行会社が定期的にファイルを配置し、自社バッチがそれを取り込む形式の拡充に変更。 各旅行会社の対応状況に合わせてバッチの実行間隔を個別に設定し、 情報鮮度を最大化する運用設計とした。 ### 課題・問題点 - 旅行会社によって入稿対応能力が異なるため、一律の頻度設定では対応できなかった - リアルタイム連携から切り替えても、ユーザーが閲覧する商品情報の鮮度をできる限り保つ必要があった ### 思考プロセス リアルタイムAPIが使えない以上、次善策として「入稿の頻度を上げること」が 鮮度向上の最短経路だと判断。旅行会社ごとに対応可能な頻度を確認し、 最大で15分に1回の取り込みを実現できる会社については短サイクルで設定。 対応状況に応じて柔軟に頻度を変えられる設計とすることで、 全社一律ではなく各社最適の鮮度を担保した。 ### 対応・実装内容・使用した技術 - バッチ処理の実行間隔を旅行会社ごとに個別設定できる構成に変更 - 最大頻度：15分に1回（対応可能な旅行会社に対して設定） - RUNDECK を用いたバッチスケジューリング管理 - 使用技術：PHP、PostgreSQL、RUNDECK、Linux ### 成果 - 旅行会社ごとに最適化された入稿頻度を実現し、商品情報の鮮度を大幅に向上 - ユーザーが閲覧するツアー情報の更新タイムラグを短縮し、利便性向上に貢献 - 外部要因による大幅な方針転換を、スケジュールを守りながら代替設計で吸収

# SEOランディングページ作成（国内／海外） ## プロジェクト概要 トラベルコにおける国内・海外向けSEOランディングページ（LP）の新規開発。 ツアーメニューのメイン施策として、国内・海外それぞれ約1〜2ヶ月という短納期で 要件定義から実装・リリースまでをリーダーとして主導した。 ## チーム情報 - 全体：42名（ビジネスサイド：27名 / 開発：15名） - 開発チーム内訳：ツアー担当7名のほか、ホテル・オプショナル・航空券など各メニュー担当チーム、デザインチームが並走 - 役割：開発リーダー（自チーム7名の進捗管理 + 全体システムの進捗管理） --- ## 開発・実装内容A：LPページ全件バッチキャッシュによる表示速度改善 ### 概要 SEO向けLPページは複数メニュー（ツアー・ホテル・オプショナルツアー・航空券等）の 情報を横断的に取得・表示する必要があり、描画速度がボトルネックになっていた。 フレームワークのURL単位キャッシュ機能を活用し、全LPページを事前にバッチでキャッシュ生成する方式を設計・実装した。 ### 課題・問題点 - 複数メニューの情報を集約するため1ページあたりのデータ取得量が多く、描画まで5秒以上かかるケースが多発 - SEOの観点からページ表示速度は検索順位に直結するため、速度改善は必須要件だった - LPページ数が多いため、個別対応ではなくスケーラブルな解決策が必要だった ### 思考プロセス リクエストのたびにDBアクセスと複数メニューのデータ取得が走ることが遅延の根本原因と特定。 動的生成をやめ「全ページを事前にキャッシュとして生成しておく」方式に切り替えることで、 表示時はキャッシュを返すだけにする設計を採用。 フレームワーク（PHP/Laravel系）が持つURL単位のキャッシュ生成機能を活用し、 バッチで全LPページ分のキャッシュを定期的に再生成する仕組みを構築した。 ### 対応・実装内容・使用した技術 - フレームワークのURL単位キャッシュ機能を利用し、全LPページをバッチで事前キャッシュ生成 - データ更新タイミングに合わせてキャッシュクリア＆再生成バッチを実装 - 使用技術：PHP、PostgreSQL、Linux、RUNDECK（バッチスケジューリング） ### 成果 - LPページの描画時間を5秒以上 → 1秒以下に短縮 - SEO観点での表示速度改善を実現し、検索順位向上の技術的基盤を構築 --- ## 開発・実装内容B：国内・海外LPの要件定義と他チームAPI連携設計 ### 概要 国内・海外でLP構造が異なる中、競合他社調査をもとに仕様を早期に固め、 他チーム（ホテル・オプショナル・航空券・デザイン）との連携を主導した。 ### どのような機能の開発・実装か - 海外LP：渡航先の「国」単位でLPを構成。各国ページにツアー・ホテル等の情報を集約表示 - 国内LP：出発地→目的地（例：東京→大阪）の「区間」単位でLPを構成。 海外とは異なるURL・パラメータ設計が必要だった ### 課題・問題点 - 国内・海外でページ構造・パラメータ体系が根本的に異なるため、設計を分けて進める必要があった - 複数チーム（各メニュー担当・デザイン）が並走するため、API仕様の認識ズレが手戻りリスクになっていた - 国内・海外それぞれ約1ヶ月という短納期のため、要件定義の遅れが開発全体に波及するリスクがあった ### 思考プロセス 仕様決定の遅れが最大のリスクと判断し、競合他社のLP構成を分析して 「自社でも実現可能な仕様の暫定案」を先に作成。 ビジネスサイドとの合意を早期に取りつけることで、開発着手を前倒しした。 他チームへのAPI連携については、画面描画に必要なパラメータを自チームから先んじて提示し、 各チームの実装を待たずに並行して開発を進められる体制を作った。 ### 対応・実装内容・使用した技術 - 競合他社事例をベースに仕様の暫定案を作成し、要件定義を早期に確定 - 他チームへはAPIレスポンスの暫定仕様（必要パラメータ・データ形式）を先出しで提示し、手戻りを削減 - 国内LPは出発地・目的地の区間をキーとしたDB定義・パラメータ設計を担当 - 海外LPは国単位のDB定義・パラメータ設計を担当 - SEO向けパラメータのDB定義、パラメータ振り分け実装を担当 - 使用技術：PHP、PostgreSQL、Linux ### 成果 - 国内・海外それぞれ約1ヶ月のタイトなスケジュールで遅延なくリリースを達成 - 他チームへの先行仕様提示により手戻りを削減し、42名規模PJTの円滑な進行に貢献 - リリース後、Google Search Console上で海外LPの検索順位が20位台 → 10位台に改善 - 使用技術：PHP、PostgreSQL、RUNDECK、Linux

# AIチャットサービスのデモ開発 ## プロジェクト概要 新規toC向けサービスの技術検証として、AWS BedrockとClaude APIを組み合わせた RAG（検索拡張生成）基盤のプロトタイプを開発。 「AIが人のようにふるまい、ユーザーと自然な会話ができるか」を検証することが目的。 技術選定・設計・実装・デモ提示までを一貫して担当した。 ## チーム情報 - 全体：4名（経営陣：2名 / 開発：2名） - 役割：システム主担当（技術選定・RAG構築・プロンプト設計・画面実装） --- ## 開発・実装内容A：RAGパイプラインの構築とデータソース設計 ### 概要 自社のAmazon Connect（クラウド型コンタクトセンター）に蓄積された通話記録を ナレッジベースとして活用し、AWS Bedrockのナレッジベース機能でRAGパイプラインを構築した。 ### どのような機能の開発・実装か - Amazon Connectの通話記録をデータソースとしてAWS Bedrockのナレッジベースに登録 - ユーザーの問いかけに対し、通話記録から関連情報を検索・抽出してClaudeが回答を生成するRAGパイプラインを実装 - チャット形式のUI（Laravel + Vue.js）を構築し、AIが営業担当のようにふるまうデモ画面を作成 ### 課題・問題点 - 通話記録には短すぎる会話や情報量の少ないデータが混在しており、 そのまま学習データとして使うと回答精度が下がるリスクがあった - 「AIが営業のようにふるまう」という抽象的な要件を、具体的なシステム仕様に落とし込む必要があった ### 対応・実装内容・使用した技術 - 通話記録の品質フィルタリングとして、回答品質を4段階で評価するロジックを設計・実装。 短すぎる会話や情報量が不十分なデータはナレッジベースへの登録対象から除外する仕組みを構築した - 使用技術：AWS Bedrock（ナレッジベース・RAG）、Amazon Connect、Claude API、Laravel、Vue.js ### 成果 - 通話記録の品質フィルタリングにより、精度の高いナレッジベースを構築 - RAGパイプラインを通じて、蓄積された営業ノウハウをAIが参照できる仕組みを実現 --- ## 開発・実装内容B：プロンプトエンジニアリングとデモ検証 ### 概要 「AIが人のようにふるまう」という体験を実現するため、 自社の営業フローに沿ったシステムプロンプトを設計・最適化した。 1〜2日ごとに経営陣へデモ画面を提示しながらフィードバックを反映する アジャイルな進め方でプロトタイプを開発した。 ### どのような機能の開発・実装か - 自社の営業トークの流れ・質問順序をシステムプロンプトとして構造化 - AIの回答品質を4段階で評価するフェーズ設計を実装し、精度の低い回答を抑制 - チャット形式のデモ画面上でAIが順を追って質問・提案を行う会話フローを実現 ### 思考プロセス 単なるQ&A型AIではなく「人のように会話を主導する」AIを実現するには、 回答の精度だけでなく「会話の流れ」をコントロールする必要があると判断。 自社の営業フローを分解し、フェーズごとにAIがとるべき発話・質問内容をプロンプトに落とし込んだ。 また、回答品質の評価を4段階に設けることで、 短すぎる・的外れな回答がユーザーに届かないようにする品質管理の仕組みも組み込んだ。 ### 対応・実装内容・使用した技術 - 自社営業フローを分析し、会話の流れを構造化したシステムプロンプトを設計 - 回答フェーズを4段階に分け、各フェーズで品質基準を満たさない回答をフィルタリング - 1〜2日ごとにデモ画面を経営陣に提示し、フィードバックをもとにプロンプトを反復改善 - Claude Codeを活用したAI駆動開発により、通常2週間相当のモックアップを3日で完成 - 使用技術：AWS Bedrock、Claude API、Claude Code、Laravel、Vue.js、AWS（ECS・S3） ### 成果 - 通常2週間を要するモックアップ作成をAI駆動開発により3日で完成・提示 - 1〜2日サイクルの反復デモにより、経営陣の意思決定を迅速にサポート - toC領域における生成AI活用の実現可能性とUXを早期に検証し、事業化判断を支援 - 現在は他プロジェクト優先により開発一時停止中（基盤・デモは完成済み）

# 自社SaaSサービス リニューアル ## プロジェクト概要 昨年リリース予定だったプロジェクトが要件リニューアルとなり、 プロジェクトマネージャーとして立て直しを主導。 社長・営業メンバーとの仕様確認、AI機能の要件整理、 外部ベンダーコントロール、既存システムの障害対応、自身による開発まで 技術とマネジメントの両面から推進している。 ※現在担当中のプロジェクトです。 ## チーム情報 - 全体：10名（ビジネスサイド：5名 / 開発：5名） - 役割：プロジェクトマネージャー兼開発担当 --- ## 開発・実装内容A：AIを活用した入力チェック機能の設計・実装 ### 概要 営業担当が作成する顧客向けドキュメントの品質を、AIが自動チェックする機能を開発。 単純なAIチェックではなく、これまで社長自身が行ってきたチェック観点・指摘パターンを 学習データとして活用し、社長目線の品質基準をAIに再現させる仕組みを構築した。 ### 課題・問題点 - 顧客向けドキュメントのチェックを社長が個別に行っており、属人化・工数集中が課題だった - 単純なルールベースのバリデーションでは、文脈や表現の質まで判定できなかった - 社長のチェック観点を明文化・構造化し、AIに伝わるプロンプトに落とし込む必要があった ### 思考プロセス 「AIにチェックさせる」だけでは精度が安定しないと判断。 社長がこれまで行ってきた指摘内容を収集・分析し、 チェック観点をカテゴリ別に整理したうえでシステムプロンプトに組み込むことで、 属人的な品質基準をAIで再現できる設計とした。 ### 対応・実装内容・使用した技術 - 社長の過去チェック内容をもとにAIの指摘観点を整理・構造化 - Claude APIを用いたドキュメントチェック機能を実装（Laravel + Vue.js） - AI駆動開発（Claude Code）を活用し、実装速度を大幅に向上 - 使用技術：Claude API、AWS Bedrock、PHP（Laravel）、Vue.js、AWS（ECS・S3） ### 成果 - 社長によるドキュメントチェック工数の削減を実現 - 属人的だった品質基準をAIで再現し、営業担当が自律的に品質確認できる仕組みを構築 --- ## 開発・実装内容B：既存システムのスロークエリ改善 ### 概要 マーケティング担当が解析用に実行していたクエリが原因で、 画面が固まる障害が断続的に発生。根本原因を特定し、クエリの改善を実施した。 ### 課題・問題点 - 解析用クエリがSELECT絞り込みなし・インデックス未使用の状態で実行されており、 処理時間が最大120秒超に達していた - 重いクエリがどんどんキューに積み重なり、画面が固まる障害が頻発していた - マーケティング担当が業務で使用しているクエリのため、改修時の影響範囲の考慮が必要だった ### 思考プロセス 障害の根本原因はクエリの非効率さと判断。 EXPLAINでクエリの実行計画を確認し、フルスキャンが発生している箇所と インデックスが効いていない箇所を特定。 SELECT句の絞り込みとインデックス追加を組み合わせることで、 最小限の変更で最大の効果を得られる改善策を実施した。 ### 対応・実装内容・使用した技術 - EXPLAINによる実行計画の分析でボトルネックを特定 - SELECT句を必要カラムのみに絞り込み、不要なフルスキャンを排除 - 適切なインデックスを追加し、クエリの実行効率を改善 - 使用技術：Amazon RDS（Aurora）、PHP（Laravel）、AWS（ECS・EC2） ### 成果 - クエリ処理時間を120秒超 → 7秒に短縮（約94%改善） - 画面固まりの障害が解消し、システムの安定稼働を実現 - マーケティング担当の解析業務を止めることなく改善を完遂 --- ## 開発・実装内容C：外部ベンダーコントロール（外部メッセージングサービス連携） ### 概要 自社SaaSへの外部メッセージングサービス連携機能の追加にあたり、 外部ベンダー4社への見積もり依頼から、最終的に2社への正式発注・進捗管理までを担当した。 また、開発体制強化のためSES 2社への発注も並行して進め、現在交渉中。 ### 課題・問題点 - 外部メッセージングサービスとの連携仕様を自社開発チームだけでは対応しきれないため、外部発注が必要だった - ベンダー選定にあたり、自社サービスの仕様を正確に伝える説明資料の作成が必要だった - 複数ベンダーとの並行折衝・進捗管理をPMとして一人で担う必要があった ### 対応・実装内容・使用した技術 - 自社SaaSの仕様概要および連携要件をまとめた説明資料を作成し、4社へ見積もり依頼 - 見積もり内容・技術的妥当性・コストを評価し、2社に絞って正式発注 - 発注後は定期的な進捗確認・課題発生時の折衝・仕様調整を担当 - 開発体制強化のためSES 2社へ発注をかけ、現在契約交渉中 ### 成果 - ベンダー選定から進捗管理までを一貫して主導し、外部連携開発を円滑に推進 - 説明資料の整備により、ベンダーとの認識齟齬を最小化 - SES追加による開発体制の強化を並行して推進中