ID:84697さん

# プロジェクト概要 ### 背景 代理店舗の数の拡張と共に、利用している予約SaaSの料金が上昇し、コスト上昇が問題になる。また、内製開発チームの経験蓄積のためでもあり、店舗予約システムを構築することにした。 ### 目的 - 今後の運営コストを抑える - 内製開発チームの実績と宣言を作る ### チーム構成 - PM：1名 - PMO：１名 - テックリード：１名 - エンジニア：５名~9名 ### 担当した役割 テックリードを担当、プロジェクトの技術全般の責任を持つ。主な業務は： - アーキテクチャー設計と基本設計 - システム基盤の理解と現行の開発プロセスをメンバーに伝承 - 開発における規約・ノウハウをメンバーに指導 # プロジェクトのエピソード ### アーキテクト設計 【課題・問題点】 - 利用しているSaasと比べたら、それほど規模システムではない - 予約全般対応のSaasと違って、銀行サービスの相談予約専用でいい - 早く内製開発チームの実績と宣言を作りたいと、部長からの要望 - システム基盤が複雑で、新卒メンバーにとって吸収に限度がある 【打ち手・使用した技術】 - エンドユーザー向けのサービスと店舗・権利者向けのサービスに分けて、簡易なSOA構成にした - サービスごとに、SPAフロントエンドとモノリスのバックエンドAPIサービスで構成 【成果】 - メンバーのアーキテクチャーへの理解は早くできた - サービスに分けたことによって、影響範囲をある程度区切りできる - 簡易なアーキテクチャーなので、開発速度が安定で、見積もりもしやすかった ### 未経験エンジニアの育成 【課題・問題点】 - 企業の実際の開発経験・知識があまりない - 実装以外の思考はまだない 【打ち手・使用した技術】 - 再確認のコツや担当範囲外の時の取るべき行動などの働き方を教えた - ペアプログラミングを行っい、一緒にコードレビューした - ある程度慣れてもらったら、クロスデビューを少しずつ行った - 内製開発プロセスや、設計資料の基準を作成した - 機能の要件・仕様を伝えた度に、少しずつ設計思考を教えて、仕向けた 【成果】 - 少しずつ設計の思考ができるメンバーがいた - 自走型の内製開発チームを形成できた ### 他部署とのコミュニケーション 【課題・問題点】 - 他部署は今までベンダーとする思考・やり方に慣れ切った - 内製開発チームで開発するのは初めて - メンバーが外国籍なエンジニアばかりで、日本語能力はまだまだ 【打ち手・使用した技術】 - 内製開発チームから主導にコミュニケーションを取ることにした - 最初はテックリードとPMOだけで行っい、少しずつメンバーを参加させ、コミュニケーションできるように指導 【成果】 - コミュニケーションラグによる遅延を抑えられた - 難しい課題でない限り、新卒メンバーも対応できる

# プロジェクト概要 ### 背景 元々業務を効率化し、生産性向上する課題は前からあり、AI活用は流行っているので、AI活用する課題を投げられた ### 目的 - AI活用の実績・ノウハウを得たい - 業務を効率化し、生産性向上する - 内製開発チームの実績と宣言を作る ### チーム構成 - PM/PL：1名 - テックリード：１名 - エンジニア：3名 ### 担当した役割 テックリードを担当、プロジェクトの技術全般の責任を持つ。主な業務は： - PoC実装 - アーキテクチャー設計と基本設計 - 方針決定 # プロジェクトのエピソード ### 何にAI活用する 【課題・問題点】 - 業務を効率化し、生産性向上するという目的は幅広すぎる - AIが何ができるか、そこまでできるかは未検証 【打ち手・使用した技術】 - 業務内容を理解し、エンジニア観点から自動化・改善できそうな部分を一覧化 - 情報共有しながら、本業務に関わる人からモヤモヤな点や、苦労している点を聞き出す - 色々PoCをした 【成果】 - AI活用できそうな業務・課題を洗い出せた ### 方針決定 【課題・問題点】 - RAGを採用するに、機密情報や個人情報を含むかもしれない社内情報をどこまで利用できるかの問題 - MCPを採用するに、AIエイジェントのミスによる影響範囲を特定し、防止・被害減少する問題 【打ち手・使用した技術】 - リスク部と一緒に検討した - MCPで操作できるシステムのリスク管理度と復旧難易度を設定した 【成果】 - 社内マニュアルと各説明資料のみに自由にRAGに使う方針になった - 複数のMCPをもって、「ナレッジ系」「リソース系」「行動系」に用途で分けた - リスク管理度と復旧難易度が低いシステムから、「行動系」MCPを開発する方針になった

# プロジェクト概要 ### 概要 国内出張や出張費を管理できるシステムを改善・運用。基本の管理機能以外、各サプライヤー（航空会社や宿泊サービスや鉄道会社など）のシステムと連携し、当システム経由で空港券や宿泊などの予約を行える機能も提供するシステム。 ### チーム構成 - PM：1名 - システムエンジニア：2名 - オフショア開発エンジニア：2~10名 ### 担当した役割 システムエンジニアを担当。主な業務は： - システムの監視・運用 - 機能開発およびテスト - 不具合対応 - リリース作業および障害対応 - 顧客の問い合わせ対応・サポート - 基本設計と詳細設計の作成 # プロジェクトのエピソード ### サプライヤーのデータ連携 【課題・問題点】 - 連携先のサプライヤーは多数あり、独立のデータ構成や仕組みがある - 請求に利用するデータなので、データの完全性や制度が必須 - 連携先のメンテナンスや障害などのコントロールできない要素 【打ち手・使用した技術】 - 冪等性を意識しながら、連携処理を設計・実装した - 冪等性を保証できる処理を設計するため、サプライヤーのデータ構成・仕組みをできるだけ把握した - 請求に計算するため、システム独自の請求データ構成を設計し、サプライヤーのデータ構成事にマッピングを作成した 【成果】 - 請求データが不完全なことはなかった - 同じ条件で連携処理を実施しても、同じデータの状態になれた - 連携が失敗した時、同じパラメーターで処理を再実施すれば済むことができた ### リリース作業の効率化 【課題・問題点】 - アジャイル開発で、リリース頻度はかなり多い - 構成の制約で、CI/CDのCDを活用できない 【打ち手・使用した技術】 - 手順をまとめて、資料にした - 手順書を元に、自動化スクリプトを作成した 【成果】 - デプロイアーティストを特定の場所において、スクリプトを実行するだけのリリース手順になった - リリース作業のミスをなくした

# プロジェクト概要 ### 概要 薬品・化学物質などを販売するECシステムを構築。システム全体は大まかに2つ部分に分けられる。注文の管理を行うサイトと、商品の閲覧と購入を行う各カタログサイト。エンドユーザーは各カタログサイトから商品を購入し、管理サイトで注文を管理できる。販売側は管理サイトで在庫確認・出庫などの業務を行う。 ### チーム構成 - PM：1名 - システムエンジニア：2名 - オフショア開発エンジニア：2~6名 ### 担当した役割 システムエンジニアを担当。主な業務は： - システムの監視・運用 - システム構築 - 機能開発およびテスト - 不具合対応 - リリース作業および障害対応 - 顧客の問い合わせ対応・サポート - 基本設計と詳細設計の作成 # プロジェクトのエピソード ### 検索速度のチューニング 【課題・問題点】 - 当時は600万の商品があった - キーワード検索だけではなく、全文検索と類語検索が要件だった 【打ち手・使用した技術】 - 一般のSQLデータベースの提供する機能やベストプラクティスを色々試した - 当時の先輩と一緒に調査した - 商品データの特徴や運用の特徴を洗い出した - 検索エンジンのインデクシングの運用を調査した 【成果】 - Apache Solrという検索エンジンにたどり着いて、採用した - 検索エンジンの利用によるトレドオフした結果、全文検索と類語検索で600万以上で1~2秒で結果が返すようになった - インデクシングの時間かかったが、数か月に一回ぐらい公開商品データを更新する頻度なので、運用に問題なかった ### アーキテクト設計 【課題・問題点】 - 商品件数が多く、カタログの実装がかなり課題 - 人数が少なく、期限の問題もあった 【打ち手・使用した技術】 - 注文管理のシステムとカタログサイトに分けた - 注文管理のシステムはOdooという既存のフレームワークで開発することにした - カタログサイトは検索エンジン以外の部分、簡易なモノリスのアーキテクトにした 【成果】 - 納期に間に合った - システムを分けたおかげで、サブシステムごとに課題にを集中できる