ID:83973さん

## プロジェクト概要 チームの研究業務の可視化とAI活用チャットボットによる自治体問合せ対応効率化を推進しました。 ## 役割・体制 ### 自身のポジションと役割 - エンジニアリングマネージャー兼バックエンド・機械学習エンジニアとして、チームの人的マネジメントと技術的課題解決を担いました。 - 研究活動の仮説設定から実験、意思決定までのプロセス整備と、AIチャットボットの設計・開発を主導しました。 - データ分析を活用し、研究進捗の可視化や解決率評価の仕組み構築を行いました。 ### チーム規模と構成 - エンジニア3名の小規模チームで、技術力の高いメンバーを率いて研究と開発を推進しました。 - マネージャーとしてチームの目標設定と進捗管理を兼務し、メンバーの技術的成長をサポートしました。 ## 背景・課題 - 研究チームの業務寄与が不明確で、仮説検証や意思決定のプロセスが曖昧であったため、組織全体での研究進捗が見えづらい状況でした。 - サポートチームが自治体からの質問対応に多大な時間を割かれており、効率的な問合せ対応の仕組みが求められていました。 - 研究評価指標が確立されておらず、研究活動が漫然と進行していたことが最大の課題でした。 ## 実際の取り組み ### 開発環境 - Pythonを中心にFastAPIでバックエンドAPIを構築し、Dockerを活用して環境の統一と効率的な開発を実現しました。 - pandas、NumPy、Jupyter Notebookを用いたデータ分析を実施し、研究進捗の定量的評価基盤を整備しました。 - OpenAIの生成AI技術を活用し、自治体問合せ対応のチャットボットを設計・実装しました。 ### 設計・改善内容 - 研究の仮説設定から意思決定までのサイクルを週次のミニマルなメモ形式で整備し、進捗の可視化と意思決定のスピード向上を図りました。 - 研究と開発のGo/Stop/Pivotの判断を分かりやすくする仕組みを設計し、チームメンバーのセルフマネジメントを促進しました。 - AIチャットボットの解決率を可視化する仕組みを導入し、サポートチームの負荷軽減に貢献しました。 ### その他アピールポイント - チームメンバーの研究活動を全社に見える化し、新技術獲得のヒント創出に寄与しました。 - 技術的課題解決とマネジメントの両面からチームの生産性向上を実現しました。 ## 成果・価値 - 研究チームの進捗が可視化され、メンバー自身が自身の停滞や課題を認識できるようになりました。 - AIチャットボットの導入により自治体からの問い合わせ解決率が向上し、サポートチームの時間負荷が削減されました。 - 研究活動の明確な評価基準を確立し、組織全体の研究効率と意思決定の質を向上させました。

## プロジェクト概要 精密機械工業向けに過去の不良品パターンを検索可能にする業務システムを受託開発し、品質向上に貢献しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとしてFastAPIとPythonを用いたAPI設計・実装を担当し、生成AIを活用したプロンプトチューニングを行いました。 - グラフRAG（Retrieval-Augmented Generation）手法の模索的導入に携わり、過去事例検索の精度向上を目的とした技術検証を実施しました。 ### チーム規模と構成 - エンジニア3名、マネージャ1名の計4名チームで、アジャイル開発手法を用いて短期集中的に開発を推進しました。 ## 背景・課題 - 精密機械工業における品質確保のため、過去の不良品発生パターンを効率的に検索し、類似トラブルの早期発見と対応を可能にするシステムが求められていました。 - 従来のRAG方式では過去事例の検索精度が不十分であり、類似度の高い情報抽出と文脈理解が課題となっていました。 - 品質問題の早期検知に向けて、より高度な検索技術としてグラフRAGの適用が検討されました。 ## 実際の取り組み ### 開発環境 - バックエンドはFastAPIとPythonで構築し、開発環境にWSL2とDockerを活用して効率的な開発体制を整えました。 - Azureクラウド環境を利用し、高可用性とスケーラビリティを確保しつつ、OpenAIの生成AIモデルを統合しました。 - アジャイル開発手法を採用し、約3ヶ月以内の短期間でのサイクルを回しながら継続的に改善を実施しました。 ### 設計・改善内容 - 過去のトラブル事例データベースからの情報検索において、標準的なRAG手法の限界を踏まえてグラフRAGを導入し、関係性を考慮した高度な検索機能の実装を試みました。 - プロンプトチューニングを繰り返し実施し、生成AIによる回答の精度と信頼性を向上させる工夫を行いました。 - バックエンドAPIの設計では検索クエリの柔軟性を重視し、ユーザーが直感的に過去事例を検索できるインターフェースを支援しました。 ### その他アピールポイント - グラフRAG導入の検証を通じて、生成AIを活用した高度な検索技術の業務適用可能性を示し、今後の技術展開への基盤を構築しました。 ## 成果・価値 - グラフRAGを導入可能であることを実証し、従来の検索手法に比べて過去トラブル事例の関連性抽出精度が向上しました。 - 精密機械工業の品質管理における問題検知の迅速化と対応精度の向上に寄与しました。 - プロジェクトを通じて生成AIとグラフRAGの実務適用に関する知見を蓄積し、今後のAI技術活用の指針を示しました。

## プロジェクト概要 空港職員向けに生成AIを活用したマニュアル検索システムを構築し、現場でのドキュメント保守性と利便性を向上させました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアおよびインフラ担当として、FastAPIを用いたAPI設計・実装とAzureインフラ構築を担当しました。 - ドキュメントメンテナンス機能の開発に注力し、空港職員が日常的に使用するRAG（Retrieval-Augmented Generation）システムの運用基盤構築を担いました。 - フロントエンド開発においても、ReactとTypeScriptを用いた管理画面の設計・実装に参画しました。 ### チーム規模と構成 - 約5名規模のチームで、バックエンド、フロントエンド、インフラを担当する複数のエンジニアと連携しながら開発を進めました。 - クライアントやユーザーである空港職員との密なコミュニケーションを通じて要件調整を行う体制でした。 ## 背景・課題 - 空港業務において、危険物リストの照合やラウンジ入室条件の確認など、職員がマニュアルを効率的に検索できるチャット型AIシステムの導入が求められていました。 - Azure AI Searchを活用したドキュメント検索機能の実装にあたり、ドキュメントのバージョニングがサポートされておらず、24時間稼働の空港業務においてダウンタイムを発生させずにドキュメントを更新する必要がありました。 - 従来は開発者が文書保守を行っていたため、業務効率や運用コストの改善が急務でした。 ## 実際の取り組み ### 開発環境 - バックエンドはPythonのFastAPIフレームワークを使用し、Azure AI SearchおよびBlob Storageを組み合わせてドキュメント検索基盤を構築しました。 - フロントエンドはReactとTypeScriptを用い、空港職員が使いやすいドキュメントメンテナンス用の管理画面を開発しました。 - DockerコンテナをWSL2環境で運用し、AzureのWindowsサーバー上でのデプロイと管理を行いました。 ### 設計・改善内容 - ドキュメントのバージョニング非対応という課題に対し、ドキュメントのハッシュ値をAzure AI Searchに保持させる設計を採用し、既存のドキュメントは変更せず、新規・更新分のみをインサートする方式でダウンタイムを回避しました。 - ドキュメントの更新処理をインクリメンタルに行う仕組みを実装し、24時間稼働の空港業務に影響を与えずに継続的な情報更新を可能にしました。 - RAGシステムの特性を活かし、チャット形式で危険物リスト照合やラウンジ入室条件の確認が可能なユーザーインターフェースを設計しました。 ### その他アピールポイント - 生成AIとAzure AI Searchを組み合わせた最先端技術の実装により、業務効率化とユーザーエクスペリエンス向上を同時に実現しました。 - 空港職員が直接ドキュメントのメンテナンスを行える体制を構築し、運用コスト削減と迅速な情報更新を両立させました。 ## 成果・価値 - 開発担当者から空港職員へのドキュメント保守権限の移譲を実現し、業務部門による運用負荷の大幅軽減を達成しました。 - ドキュメント更新に伴うシステムダウンタイムを実質ゼロに抑え、24時間稼働の空港業務の安定性を維持しました。

## プロジェクト概要 老舗レンタルサーバのホスティング事業部にて、Webアプリの保守運用と新規開発を担当しました。 ## 役割・体制 ### 自身のポジションと役割 - 主にバックエンドエンジニアとして、PHPやRuby on Railsを用いたサーバサイド開発を担当し、ユーザ情報管理やキャンペーン適用ロジックの設計・実装を行いました。 - フロントエンドやインフラ、QAの領域にも携わり、開発から運用・保守まで幅広く対応しました。 - アジャイルに近い開発手法の中で、継続的な機能改善と品質向上を目的とするチーム内コミュニケーションを推進しました。 ### チーム規模と構成 - 流動的ながら約10名規模のチームで、フロントエンド、バックエンド、インフラ、QAのメンバーで構成されていました。 ## 背景・課題 - 老舗のレガシーサービスであるため、既存のデータベース設計やSQLクエリが複雑化しており、ユーザ情報の取得やキャンペーン適用時のSQL操作が高度で負担が大きい状態でした。 - エンジニアの業務が保守中心となり、新規開発や改善に割く時間が不足していることが課題でした。 - 既存の業務プロセスが属人的かつ複雑で、非効率な作業が多発していました。 ## 実際の取り組み ### 開発環境 - 使用技術はPHP、Ruby、Ruby on Rails、JavaScriptを中心に、MySQLをデータベースとして活用しました。 - macOS環境でDockerを利用し、開発環境の統一と効率化を推進しました。 - SSL設定を含むセキュリティ面の運用保守も担当しました。 ### 設計・改善内容 - SQLクエリの複雑さを解消するため、ディレクターでも操作可能なSQLセットを作成し、簡単な組み合わせでユーザ情報取得やキャンペーン適用が行える仕組みを導入しました。 - バックエンドのロジック設計を見直し、保守性と拡張性を向上させることで、開発工数の削減に貢献しました。 - フロントエンドと連携した機能改善を継続的に行い、ユーザビリティとパフォーマンスの向上を図りました。 ### その他アピールポイント - 複数の技術領域を横断的に担当し、チーム全体の技術理解向上と業務効率化に貢献しました。 - 保守業務の効率化によりエンジニアの作業負荷を軽減し、新規開発への注力を可能にしました。 ## 成果・価値 - ディレクターがSQL操作を容易に行えるようになったことで、エンジニアの保守業務負担が軽減され、新規開発に専念できる環境が整いました。 - 保守から開発志向への業務シフトにより、プロダクトの機能改善スピードが向上しました。 - システムの安定稼働を維持しつつ、継続的な機能追加と改善を実現しました。

サービス内で用いる各メディア（DICOM, *.pptx, *.key, 動画, PDFファイル）をWeb用の画像等に変換する変換サーバを AWS 上に作成。仕様策定、Docker+PythonによるDICOM変換機能・ Windows サーバを用いた pptx変換機能・pdf変換機能の実装、ECSインスタンスのオートスケール実装、Amazon S3・AWS Lambda・Amazon ECSによるサーバレスアーキテクチャの構築、インフラ・コードのデプロイ作業のAnsibleによる一括記述、テスト項目の策定およびテストを担当。e-casebook開発メンバとしてスクラムマスターを務め、スクラムイベントを主催。