ID:75195さん

### プロジェクト概要 - **目的**: パーソルキャリア社員約6000人が利用する社内向け生成AIチャットサービスの開発。 - **人数・体制**: フロントエンド2名、インフラエンジニア1名、私を含むフルスタックエンジニア兼テックリードの4名のエンジニアで構成。他に推進チームと分析チームがあり、チームを跨ぐPMの方と連携しながらプロジェクトを推進しました。 ### プロジェクトにおける自身の役割 - 機能開発において、フロントエンド、バックエンドの実装、インフラ構成の改善を行うと同時に、チームのテックマネジメントを担当しました。具体的には、事業部側へのヒアリング、他チームとの認識合わせ、要件定義、詳細設計、実装、レビューを実施し、プロジェクト全体の技術的な推進を担いました。 ### 当時の背景/抱えていた課題等 - **課題**: 当時、ルールベースの社内向けチャットボットしか存在せず、非整形の質問形式で問い合わせができるサービスが社内に存在しませんでした。そのため、会社規模の拡大に伴い、全社的な業務効率向上を図るため、全社員が生成AIを活用できる環境が求められていました。 ### 課題に対して自身が発揮したバリュー及び成果 - **工夫**: Azure基盤を活用し、LangChain、Azure OpenAI、Azure AI Searchを駆使して生成AIを活用した社内チャットサービスを構築しました。特に、GPT-3.5の最適化手法を導入し、高パフォーマンスを維持しつつ運用コストを抑えることに成功しました。（現在は最新モデルであるAzure OpenAI GPT-4oに移行が完了しています。） - 普及率というKPIを達成するため、AIに慣れていない社内メンバーへの浸透が課題となっていました。そのため、特に利用率の高い2つの事業部と定期的にヒアリングを行い、事業部側の推進メンバーの課題感を抽出し、機能拡充の方針を決定しました。 - 開発・推進・分析チームの連携が重要であったため、一日合宿を実施し、全体として現状のデータを可視化し、事業部や職種ごとの利用率の差異を明確にしました。その結果、ユーザー層を分類し、ユーザー層ごとのアプローチを見直しました。 - 社内のSharePoint上の全社員が閲覧可能な文書データをAzure Blob Storageに転送するパイプラインをAzure Functions上で構築しました。この仕組みにより、よりリアルタイムに近い形で全社内文書をRAGで参照し、回答ができるようになりました。 - 事業部とのヒアリング結果を基に、プロンプトを共有するためのURL共有機能を実装し、さらに生成AIのチャットサービスに不慣れなメンバーのために、事業部ごとの初期画面に定型のプロンプトを表示する機能や、チャットの回答を進めると次に質問するプロンプトをサジェストする機能を実装しました。これにより、普及率向上に寄与しました。 - **成果**: 社内文書から自動で回答を生成する機能を持つサービスを成功裏に開発し、事業部側とアナリティクスチームとの連携をシームレスに行い、スケジュール通りにリリースを達成しました。この結果、業務効率の向上やUXの向上に大きく貢献しました。また、継続的に事業部側の推進メンバーと連携を取り、普及率向上のための機能拡充を推進し、現在では普及率が60~70%程まで向上しています。

### プロジェクト概要 - **目的**: パーソルキャリア社内における法人データの分析基盤を構築すること。 - **人数・体制**: BIクエリを実装するメンバー、インフラを担当するメンバー、私を含むデータエンジニア3名で構成。他にデータマネジメントチーム1名、PM1名と連携しながらプロジェクトを進めております。 ### プロジェクトにおける自身の役割 - 既存のDenodoを使用した仮想データベースの分析基盤をGoogle CloudのBigQueryに移行するプロジェクトを推進いたしました。特に技術領域でのソリューション提案および実装を担当し、業務フローの抽出・整理を行い、移行前後の影響を最小限に抑えました。また、転送パイプラインの構築および運用管理も担当いたしました。 ### 当時の背景/抱えていた課題等 - **課題**: DenodoをAWSのEC2上で管理していたため、コストの増大とパフォーマンスの限界に直面していたため、私がGoogle Cloud上への基盤移行を提案し、業務フローへの影響を抑えつつ、コスト削減を実現できることをPoCで確認し、その結果、移行を決定いたしました。 ### 課題に対して自身が発揮したバリュー及び成果 - **工夫**: Google Cloud上に分析基盤を移行することで、コスト削減とパフォーマンス向上を図り、影響を最小限に抑えるためのPoCを実施いたしました。 - データ基盤の業務フローを明確にし、Denodoで実現できていた機能をGoogle Cloud上で再現できるかを検証いたしました。 - 業務フローでは、Denodoから参照するために行っていたファイルアップロード処理を、Cloud StorageへのファイルアップロードをトリガーにEventarc経由でCloud Workflowsを実行し、Cloud Run Jobsでデータの前処理を行い、BigQueryに転送する仕組みに再構築いたしました。 - 日本語のExcel・CSVファイルをBigQueryのテーブル・カラム名にマッピングする必要があり、データマネジメントチームが作成したマッピングファイルを参照する仕組みも構築いたしました。 - データ品質を確保するため、カラムやレコードの差分を検知する仕組みをCloud Run Jobs上で実装し、Slackに通知する機能を導入いたしました。 - 今後、Salesforceからのデータ転送が必要になるため、TroccoとのPoCを推進いたしまして、機能実現が可能であることを確認し、導入を進めましたが、先方の契約プランの変更によるコスト増大のため、CDataやFivetran、Informatica等の移行先を検討中です。 - **成果**: コスト削減とパフォーマンス向上を達成し、今後の分析基盤拡充に向けた重要な基礎を築きました。また、移行前の業務フローを新しい環境でも実現し、データ品質の担保や長期的な運用に向けた技術選定に貢献いたしました。

### プロジェクト概要（目的・人数・体制） 社内でセキュアに利用可能な生成AIチャットサービスの開発（SaaS）を行いました。開発体制はアジャイル開発で、メンバーは全員がフルスタックエンジニアであり、計4名で構成されていました。私は副業としてテックリードの役割でジョインいたしました。 ### 自身の役割 機能開発において、フロントエンド、バックエンドの実装、インフラ構成の改善を行いながら、チームのテックマネジメントも担当いたしました。開発では、要件定義、詳細設計、実装、レビュー、テックマネジメントを行いました。Google Cloudのインフラ基盤を、サービス開発当初からゼロベースで構築いたしました。 ### 課題 生成AIを活用した社内向けチャットサービスをSaaSとしてリリースするにあたり、セキュアでスケーラブルなインフラ構築が求められていました。 ### 工夫 - 社内での知見が強いVercelやFirebaseに依存せず、Google Cloud上でインフラをゼロから構築いたしました。 - プロトタイプはVercelとSupabaseで構築されていましたが、Vercelのコスト面（プライベート接続にはProプランからEnterpriseプランへの乗り換えが必要）を考慮し、Cloud RunとCloud SQLでより低コストで同様の仕組みが実現できることを確認し、移行を実施しました。また、SupabaseはBaaSとして最低限の機能を提供していましたが、メール送信テンプレートの数が固定されていたり、SDKがトランザクションに対応していなかったりするなど、長期運用において問題があると判断いたしました。これを受け、メール送信にはResend、認証・認可にはNextAuth.js、ORMにはDrizzle ORM（TypeScript）、Gorm（Go）、SQLAlchemy（Python）を言語ごとに選定し実装いたしました。 - フロントエンドにはNext.jsを、アプリケーションサーバーにはEcho（Go）、LLMサーバーにはPythonのgRPCサーバーを使用して構築いたしました。 - 前提として、スピード感のある開発が求められていたため、社内知見を活かしつつ最適な技術選定が求められていました。 - フロントエンドには社内知見の多いReactベースのフレームワークであるNext.jsを選定。 - バックエンドにはまずベースのアプリケーションサーバーにはGoを採用いたしました。これは、ベースとなるサーバーで型安全性、並行処理の強み、ビルドスピード、コンテナイメージの軽量化等のメリットをバランス良く享受できる点が理由です。 - LLMサーバーはベースとして依存リソースへの処理を抽象化できるLangChainを採用しているため、技術選定がPythonかNode.jsとなりますが、今後ローカルLLMや独自LLMを利用する可能性を考慮し、Pythonを選択いたしました。 - オブザーバビリティの観点から、GoとPythonサーバーにはGoogle Cloud Traceを導入し、API内の各処理のボトルネックを可視化できるようにいたしました。 - 負荷対策とセキュリティの柔軟性を考慮した設計を行いました。 - **負荷対策**： - ファイルアップロードをGoogle Cloud Storageの署名付きURL付与後、フロントエンド側でアップロードを実施する仕組みにし、ファイルがアプリケーションサーバー上でメモリ展開されることを回避する設計にしました。 - ファイルアップロードをPub/Sub経由で処理することで、ファイルの複数アップロードによるCloud Runのスケール限界に到達するリスクを軽減する設計としました。 - 現状はコスト削減のため、Cloud SQLに対し、ベクトルDBとメタデータDBの役割を持たせていましたが、今後リードレプリカを導入し、Read/Writeの負荷を分散させる予定です。 - **セキュリティ**： - Cloud Load Balancingに対し、Cloud ArmorによるWAFを適用し、不正なアクセスを検知できるように設計いたしました。 - 以降の処理はCloud Run同士の通信はIAMで、Cloud RunからCloud SQLへはAuth Proxyによる接続とすることで、通信において外部から公開アクセス可能な状態を回避する設計としました。 ### 成果 - サービスのゼロからの立ち上げに成功し、現在もtoBサービスとしてスケールを続けられる仕組みを構築いたしました。 - サービスのスケーラビリティとセキュリティを両立させ、利用企業の生産性向上に寄与いたしました。

### プロジェクト概要（目的・人数・体制） 契約書や帳票をデータとして管理できるAI搭載の管理サービスの開発(SaaS)に従事いたしました。開発体制はアジャイルで進行し、メンバーはフロントエンドエンジニア2名、バックエンドエンジニア4名の正社員6名で構成されていました。さらに、マネージャーや業務委託メンバー、企画メンバーとも連携を図りながらプロジェクトを推進いたしました。 ### プロジェクトにおける自身の役割 私は、機能開発においてフロントエンドおよびバックエンドの実装、インフラ構成の改善を担当すると同時に、技術面での開発リーダーの一員としても活動いたしました。具体的には、要件定義、詳細設計、実装、レビュー、リリース、運用保守を主導いたしました。 ### 当時の背景/抱えていた課題等 当時、サービスは0→1フェーズを終え、1→10へのスケール段階にありました。このスケール段階において機能拡充が求められておりましたが、サービスのスケール性には限界がありました。特に、AI搭載の処理サーバーがKubernetesのポッド上で動作していたものの、直列処理しかできなかったため、AWS Lambdaに基盤を移行することでコストダウンとスケール性の向上を同時に実現する必要がありました。 ### 課題に対して自身が発揮したバリュー及び成果 - **工夫**: - **チームの知見強化によるサービス品質向上**: - 毎週の輪読会を主催し、TypeScriptやGo言語、システム運用に関する文書や書籍を題材にチーム内の知見を深め、共通の参照基盤を構築いたしました。これにより、サービス開発速度と品質の向上に貢献いたしました。 - さらに、TypeScript、Go、Pythonのテストコード基盤を改善・構築し、カバレッジを向上させ、サービスの品質向上にも寄与いたしました。 - **機能拡充**: - 企画メンバーと連携を図り、間接的に顧客ニーズを把握し、また一方で、顧客からの問い合わせや不具合通知に迅速に対応するための運用体制を構築いたしました。 - 権限管理機能の開発では、権限判定のコアロジックを実装し、これをチームに展開することで、開発の効率化を図りました。 - 電子署名サービスとのAPI連携機能の開発に際しては、DocuSignとの連携時に先方とのミーティングをファシリテートし、機能実現に向けた課題を解決いたしました。 - **スケール対策**: - AWS Lambdaを用いて基盤を再設計し、並列処理の導入によるスケール性向上とコスト削減を実現いたしました。 - チーム内で4つのLambdaを構築し、R&Dチームとのインタフェースを共有しながら開発を進行させました。 - PythonとGoのLambdaを基盤で構築し、チームに展開することで、開発を効率的に進めました。 - 負荷テストを行った際に、バルクインサート処理でデッドロックが発生する問題がありましたが、インサートのソート順とトランザクション分離レベルの見直しによって問題を解決いたしました。 - **成果**: - 成功裏に基盤移行を完了し、これによりサービスのスケール性とコスト効率が大幅に向上いたしました。移行後も安定したサービス運用を継続し、新たな機能を迅速に追加できる体制を整えることができました。