ID:82356さん

## 概要 薬剤師向けにコラムや掲示板等のコンテンツを提供するポータルサイトの保守・改善を担当。 ユーザーのアクティビティ向上と、自社転職サービスへの送客を目的としている。 ビジネスサイドと連携し、データ分析に基づく施策の起案から開発までを推進。あわせて、インフラ基盤の刷新や開発生産性の向上にも主導的に取り組んだ。 ### KPI CV(親会社エムスリーへの会員登録数)とMAUをKPIとして計測。 各ページの離脱率やリンクのクリック履歴を会員属性ごとに分析し、ビジネスサイドと連携しながら、CV・MAU向上に繋がる施策の起案とシステム開発を推進。 ## 開発実績:オンプレバッチサーバーのクラウド移行(プロジェクトを主導) ### 【課題】 - オンプレで稼働する約100本のバッチジョブについて、仕様が十分に整理されておらず、どのジョブがいつ・どのような入力で実行され、何を出力するのかが不明瞭な状態だった。 - ジョブの実行タイミングがコード上でしか管理されておらず、誰が見ても一目で把握できる状態になっていなかった。 - 技術的負債が積み重なった結果、保守・運用の属人化や、変更時の影響範囲の把握が困難という問題を抱えていた。 ### 【工夫・アプローチ】 - 全ジョブの仕様(入力・処理内容・出力・依存関係)を一つひとつ洗い出し、整理した。 - 既存機能を損なわないことを前提に、AWS上の構成を設計。 - EventBridge Schedulerで定期的にStep Functionsを起動 - ステートマシン内でECSタスクを立ち上げ、ジョブを実行 - 実行結果はSNS・ChatbotによりSlack・メールへ通知 - 数時間かかる長時間ジョブが存在するため、実行時間の制約があるLambdaではなくECSタスクを採用。ジョブごとに実行基盤を使い分けると運用の認知負荷が高まるため、ECSに一本化した。 - 約100本のジョブを一括で移行せず、依存関係を踏まえた段階移行計画を策定し、リスクを抑えて進める方針とした。 - 整理した仕様や移行方針を資料化し、上司やビジネスサイドに分かりやすく説明。非エンジニアにも理解できる形で共有することを重視した。 - 仕様整理、設計、移行計画、関係者への説明まで、プロジェクト全体を一貫して担当した。 ### 【成果】 - テスト環境での基盤構築を完了させ、約100本のバッチジョブの段階移行計画を策定。 - コード上にしかなかった実行タイミングを可視化し、特定メンバーの知識に依存せず、運用状況を誰でも確認できる状態に改善。 ## 改善実績:デプロイ認証のセキュリティ強化 強い権限を持つIAMユーザーの長期認証情報でデプロイしており、漏洩時のリスクが大きい状態だった。これをOIDC認証に切り替え、一時的なアクセストークンのみを利用する構成に変更した。 ## AI活用・開発生産性の向上 開発生産性の向上を目的に、AIを活用した開発フローをスキルとして整理し、チーム内に展開。AI活用開発フローの標準化を主導した。 ## メンバー数/役割 4名体制 / エンジニア

## プロジェクト概要 自社新規事業として薬剤師向け採用支援プラットフォームの立ち上げに参画。 Webアプリケーション開発を担うとともに、BigQuery等を用いたデータ基盤の設計・構築を推進し、事業KPIに基づくデータ活用を実施。 PdMやビジネスサイドと連携し、課題仮説の立案から優先度判断、実装、改善までを一貫して担当。 ## 担当業務 - PdMと連携し、数値データから課題仮説を立案。開発要否を含めた優先度判断を実施 - Ruby on Railsを用いたバックエンドAPIおよび業務ロジックの設計・実装 - Vue.js / Hotwireによるフロントエンド開発およびUI改善 - SalesforceとWebアプリケーション間のデータ連携機能の設計・実装 - BigQueryおよびTROCCOを用いたデータ基盤の設計・構築 - AWS環境下でのアプリケーション開発・運用 ## 開発実績:薬剤師採用支援プラットフォームの立ち上げ・グロース ### 【課題】 - 薬局側には「薬剤師を採用できない」という課題があったが、求人票・選考管理だけでは根本解決に至らず、事業として何を優先的に開発すべきか、仮説段階から検討する必要があった。 - 新規事業のため、開発の要否や優先度を判断する上での指標(KPI)や、その可視化基盤自体が整っていなかった。 ### 【工夫・アプローチ】 - PdMと連携し、数値データから課題仮説を立案。開発要否を含めた優先度判断を実施。 - 求人票・選考管理機能に加え、近隣薬剤師へのスカウトや相場データに基づく採用コンサルティング機能を、ゼロから設計・開発。 - BigQueryおよびTROCCOを用いてデータ基盤を構築し、事業KPIを継続的に可視化できる状態を整備。PDCAサイクルを推進できる体制を作った。 - MVPリリース後は、ユーザーアクティビティを分析し、特にスカウト機能を中心に改善を継続的に実施。 - ビジネスサイドの要望も踏まえ、期限と事業上の優先度のバランスを見ながら、実装方針や範囲を判断。 ### 【成果】 - ユーザー利用率と売上の向上に貢献。 - データ基盤の整備により、KPIを継続的に可視化し、PDCAサイクルを推進する仕組みを構築。 - 機能改善と業務効率化の積み重ねにより、利益向上および社内工数削減を合わせて約1,000万円の事業効果を創出。 ## メンバー数/役割 5名体制 / エンジニア

## プロジェクト概要 自社で運営している薬剤師向け転職支援サービスの保守開発を実施。 課題発見・施策検討フェーズから参画し、マーケター・デザイナーなど職種横断での改善を推進。 データに基づく課題仮説の立案から、開発の優先度判断、実装、制作フローの改善までを担当。 ## 担当業務 - マーケターと連携し、数値データに基づく課題仮説の立案・原因分析・改善提案を実施 - 開発要否を含めた優先度設計を主導 - バックエンド開発および既存機能の設計・改善 - フロントエンド実装および保守性向上 - デザイナーと協力し、開発体制および制作フローの改善を推進 - デザイナー向けAIエージェントおよびMCP導入の技術支援 - デザインデータのGit管理導入およびCI構築の推進 ## 改善実績:マーケター・デザイナーとの連携強化によるリードタイム短縮 ### 【課題】 - マーケターとエンジニア間の日常的なコミュニケーション不足から、施策の意図が正しく伝わらず、認識のズレによる手戻りが発生していた。 - 施策検討から実装までのプロセスが分断されており、データに基づく課題仮説の立案から改善提案・開発反映までのリードタイムが長期化していた。 ### 【工夫・アプローチ】 - マーケターと連携し、数値データをもとにした課題仮説立案および原因分析を実施。データドリブンな改善提案を継続的に行った。 - コミュニケーション不足という課題に対し、自身の席をマーケティングチームの隣に移して日常的な対話の機会を増やし、施策の意図を実装前に共有できる状態を作った。認識のズレによる手戻りを削減し、施策検討から実装までを一気通貫で進める体制を構築。 - 数値データを根拠とした意思決定を行い、開発要否を含めた優先度設計を主導。 - デザイナーとの連携では、AIエージェント・MCP導入の技術支援や、デザインデータのGit管理・CI構築を推進し、制作フロー自体の改善を図った。エンジニアが関わる範囲を、実装だけでなく制作フローの改善にも広げた。 ### 【成果】 - データドリブンな改善提案により、CVR向上に貢献。 - マーケター・デザイナーとの連携強化により、施策検討から実装までのリードタイムを短縮。 - AI活用およびCI整備を通じ、デザイナーを含むチーム全体の開発生産性の向上に貢献。 ## メンバー数/役割 6名体制 / エンジニア

## 概要 自社で内製している基幹システムの保守開発を担当。 チームリーダーとして、技術的負債の解消、バグ管理体制の構築、役員への報告まで一貫して推進。 ビジネス側とエンジニア側の橋渡し役も担い、事業運営を支える基幹システムの安定化に取り組んだ。 ## 担当業務 - チームリーダーとして、エンジニアのマネジメントおよび新入社員のオンボーディング - ビジネス側とエンジニア側の橋渡し、役員への不具合・技術的負債の状況報告 - 技術的負債の解消(Railsバージョンアップ、テストカバレッジ向上) - CI/CD環境の構築・整備 - 不具合対応およびバグ管理フローの確立 ## 改善実績:技術的負債を抱えた基幹システムの保守体制再構築 ### 【課題】 - 講師のシフトやレッスン料、会員情報等を一元管理する基幹システムが、多くの技術的負債とバグを抱えた状態にあった。 - 障害対応が特定のメンバーに依存する「属人化」した状態にあり、誰がどのバグにどう対応しているかが可視化されていなかった。 - Ruby/Railsのバージョンが古く、テストによる品質担保もされていないため、変更のたびに不具合が発生しやすい状態だった。 ### 【工夫・アプローチ】 - バグの発生から解消までをKPIとして管理するフローを新たに確立し、対応状況を可視化。属人化していた障害対応を、チームとして管理できる体制に変えた。 - Ruby/Railsのバージョンアップとテストカバレッジの向上に着手し、変更に強いコードベースへと段階的に改善(テストカバレッジ0%→約60%)。 - CI/CD環境を構築し、リリース作業を自動化(手動で約20分かかっていたリリース作業を約5分に短縮)。 - 不具合と技術的負債の状況を分析して資料化し、役員へ定期的に報告。ビジネス側が状況を把握し、意思決定できる情報を継続的に提供した。 - チームリーダーとして、メンバーへの技術指導や新入社員のオンボーディングを担い、個人に依存しない開発体制づくりを推進。 ### 【成果】 - 障害対応の属人化を解消し、安定した運用体制を構築。 - テストカバレッジを0%から約60%まで向上させ、バグを未然に防げる体制を実現。 - リリース作業を自動化し、リリースにかかる時間を約20分から約5分に短縮。 - 不具合と技術的負債の状況をビジネス側へ共有する仕組みを作り、保守開発に対する経営層の理解を得られる状態にした。 ## メンバー数/役割 4名体制 / チームリーダー

## 概要 自社基幹システムをベースとした、教育事業者向けSaaSプロジェクトに途中から参画。 ビジネス側と連携しながら、要件定義からリリースまでを一貫して担当し、保守運用体制の強化にも注力。 ## 担当業務 - ビジネス側との定例MTGでファシリテーターを務め、要件の優先順位付けや技術的な意思決定を主導 - 要件定義から設計・実装・リリースまでの一貫した新機能開発 - バグ対応および保守運用体制の強化 - CI/CD環境の整備 ## 改善実績:あいまいな要件の明確化とSaaS開発品質の向上 ### 【課題】 - ユーザー要件があいまいなまま開発が進められており、実装段階になって仕様の解釈違いや手戻りが発生しやすい状態だった。 - 既存の不具合も多く残っており、新機能開発と並行して対応する必要があった。 ### 【工夫・アプローチ】 - ビジネス側との定例MTGでファシリテーターを務め、あいまいだった要件をその場で明確化。優先順位付けや技術的な意思決定を主導し、実装前にビジネス側とエンジニア側の認識を揃える場とした。 - 既存不具合への対応と新機能開発を並行して推進できるよう、CI/CD環境を整備。変更を安全かつスピーディーに反映できる体制を構築。 ### 【成果】 - ビジネス側との連携体制を強化し、要件のズレによる手戻りを抑制。 - あいまいな要件を明確化しながら、既存不具合対応と新機能開発を並行して推進できる体制を実現。 ## メンバー数/役割 5名体制 / エンジニア