ID:79999さん

# 【サマリー】 大手美容室のOMO戦略の中核として、分断されていたEC・店舗のポイントシステムを統合するシステムを、**企画・設計・開発・インフラ構築まで責任者として単独でリードし、完遂しました。** 複雑な外部システム連携（Shopify, POS）を堅牢なアーキテクチャで実現し、ビジネスの成長基盤を構築したプロジェクトです。 ----- # 【プロジェクト概要】 全国に展開する大手美容室様の、ECサイトと実店舗のポイントシステムを統合する、OMO（Online Merges with Offline）施策の中核となるシステムを開発しました。 # サービスの価値と特徴 - **統合ポイント管理**: 店舗でのポイント獲得・使用とオンラインショップ(Shopify)でのポイント管理を一元化 - **リアルタイム同期**: 店舗とオンライン間でのポイント残高の即座な反映 - **バーコード決済**: スマートフォンでバーコードを表示し、店舗での決済に利用 - **LINE連携**: 既存のLINE公式アカウントとのシームレスな連携 - **PWA対応**: ネイティブアプリのような体験を提供するモバイルファースト設計 # 【自身の役割と担当範囲】 クライアントとの要件定義から、システム全体のアーキテクチャ設計、Ruby on Railsを用いたバックエンド開発、インフラ構築、そして運用・保守まで、**企画からリリース後までの一連のフェーズを、責任者として単独でリードし、完遂しました。** # 【技術スタック】 - **バックエンド**: Ruby on Rails 7.2.2, Ruby 3.3.6 - **データベース**: PostgreSQL（複合インデックス、外部キー制約） - **フロントエンド**: Tailwind CSS, DaisyUI, Vanilla JavaScript（Module Pattern） - **インフラ**: Puma, Nginx, Conoha VPN - **認証**: LINE LIFF SDK, Bearer Token認証 - **外部連携**: Shopify API, POSシステム連携 - **テスト**: RSpec, FactoryBot, Capybara（テストカバレッジ90%以上） # 【具体的な行動と工夫（アピールポイント）】 ## 1. ビジネスロジックの分離と整理（Interactor Pattern） **課題**: ポイント利用時のバーコード発行やPOSからの決済確定処理は、「DBへの複数レコード記録」「外部API連携」「ポイント増減」など、複数のステップにまたがる複雑なビジネスロジックでした。 **解決策**: **`Interactor Pattern`** を採用し、一連の処理を小さなサービスオブジェクトに分割・整理しました。 ```ruby # バーコード生成の一連の処理を管理するオーガナイザー module Barcodes class ManageBarcodeCreation include Interactor::Organizer organize CreateTransactionInteractor, # トランザクション作成 GenerateBarcodeInteractor, # バーコード生成 UpdateLockedPointsInteractor, # ロックポイント更新 CreateUpdateHistoryInteractor # 履歴作成 end end ``` **成果**: - 各ステップの責務が明確になり、トランザクション管理によってプロセス全体の整合性を保証 - テストが書きやすく、急な仕様変更にも「慌てず」対応できる、柔軟な構造を実現できました - 新機能追加時の影響範囲を最小限に抑制できました ## 2. 外部連携の堅牢化とセキュリティ（Service/Validator Pattern） **課題**: Shopify、POS、LINEといった複数の外部システムとの連携は、プロジェクトの最も不安定な要素でした。また、POSからのリクエストを受け付けるAPIのセキュリティ担保も必須でした。 **解決策**: 外部連携処理を **`Service Object`** として完全に分離し、APIリクエストの検証ロジックを **`Validator`** に集約しました。 **成果**: - POS向けAPIには **`Bearer Token認証`** を導入し、不正なアクセスを遮断 - 外部要因に強い、セキュアで再利用性の高い設計を実現 - 統一されたエラーハンドリングによる運用負荷の軽減 ## 3. 保守性とパフォーマンスを両立する設計 ## データベース設計の最適化 ```sql -- 複合インデックスによる検索パフォーマンス向上 CREATE INDEX idx_on_user_id_created_at_sequence_number ON transactions (user_id, created_at, sequence_number); -- 外部キー制約によるデータ整合性保証 ALTER TABLE transactions ADD CONSTRAINT fk_transactions_user_id FOREIGN KEY (user_id) REFERENCES users(id); ``` ## フロントエンド設計の工夫 ```javascript // Module Patternによるコンポーネント分割 const BarcodeModule = (function() { let isProcessing = false; // プライベート変数 return { async initUse() { /* 初期化処理 */ }, displayBarcode(barcodeData, pageType) { /* 表示処理 */ } }; })(); ``` **成果**: - 将来のデータ量増加を見越したパフォーマンスを確保 - コードの再利用性と保守性を大幅に向上 ## 4. ユーザー体験の最適化 - **モバイルファーストのUI/UX設計**: Tailwind CSSによるレスポンシブデザインと直感的な操作フロー - **リアルタイム同期機能**: 店舗とオンライン間でのポイント残高の即座な反映と取引履歴の詳細表示 # 【技術的な挑戦と解決】 - **ポイント整合性の保証**: ロックポイント機能、トランザクション管理、完全な監査証跡により二重使用を防止。 - **高可用性の実現**: 自動復旧機能と監視・アラート機能による早期問題検知。 - **セキュリティの強化**: 多層認証、入力値検証の徹底、セキュアなログ管理。 # 【結果・得られたこと】 ## 定量的成果 - **レスポンス時間**: 平均200ms以下 - **テストカバレッジ**: 90%以上 - **バグ発生率**: 月間0.1%以下 ## 定性的成果 - ステークホルダーが多い複雑なプロジェクトを、要件定義からアーキテクチャ設計、フルスタックな実装まで推進する能力を培うことができました。 - ビジネス要件を技術的ソリューションに落とし込む設計力が向上し、要件定義・設計・開発の工程を一人で「やり遂げた」ことで、技術的な自信はもちろん、ビジネスに対する責任感も格段に強くなりました。 ## 技術的成長 - **アーキテクチャ設計力**: 大規模システムの設計パターン習得 - **外部連携技術**: 複数システム間の連携設計・実装能力 - **運用・保守力**: 本格的な運用環境でのシステム管理経験

## プロジェクト2：大手ポイントサービスの運用保守開発 ### 【プロジェクト概要】 20年以上の運用実績を持つ国内最大級のポイントサービスの運用保守開発を担当。長年の運用による技術的負債（Oracle, C言語等）を抱えつつも、マイクロサービスとして分割された多数のコンポーネントの安定稼働と、システムの抜本的なモダナイゼーションをミッションとしました。 ### 【自身の役割と担当範囲】 運用保守チームの一員として、サービスの安定稼働に責任を持つと同時に、**全社的なミッションであった「脱Oracle」と「脱C言語」を推進する役割**を担いました。具体的には、DB移行に伴う影響調査、C言語で書かれたレガシーサービスのRailsでのリプレイス開発（設計・実装・データ移行）などを担当しました。 ### 【開発プロセスとチーム体制：アジャイル開発の実践】 開発は、複数のチームが連携する**大規模スクラム（LeSS）**のフレームワークに則って進められました。チームには専任のスクラムマスターが在籍し、1週間のスプリントで開発サイクルを回していました。このプロセスにおいて、私は以下の活動に主体的に貢献しました。 - **スプリントプランニング** ファシリテーターをチーム内でローテーションしながら、**プロダクトの大きなマイルストーンや各種バージョンのEOLといった厳格な期日、多岐にわたる外部システム起因のメンテナンス、そして日々発生する障害対応**といった、現実的で複雑な要求の優先順位付けを行いました。その中で、技術的負債の返済といった**「未来の生産性を高めるための投資」の価値をチームに説明**し、計画的にバックログへ組み込むことを推進しました。 - **スプリントレビュー** 自身が開発した機能について、プロダクトオーナーやステークホルダーに対し、デモンストレーションを実施。実装した機能がビジネス価値にどう繋がるかを自身の言葉で説明し、受け取ったフィードバックを次のスプリントの改善に繋げました。 - **レトロスペクティブ（振り返り）** ファシリテーターは持ち回りで担当し、その時のチームの状況に応じて最適なアクティビティ（KPT、Start-Stop-Continueなど）を選択する、自律的なチームでした。私たちのレトロスペクティブは、個別の事象の反省に留まらず、チーム全体の生産性向上を目的とした「開発の進め方」そのものを見直す重要な場でした。 例えば、頻繁な差し込み対応によるコンテキストスイッチがスプリントゴールの達成に影響を与えていることを課題として挙げ、「割り込みタスクへの対応フローの見直し」や「チーム内での情報共有方法の改善」といった、プロセスレベルの具体的な改善アクションを提案。 チームでの議論と合意形成をリードし、より効率的で集中できる開発環境の構築に貢献しました。 ### 【具体的な取り組みと成果】 #### 1. 大規模DB移行（脱Oracle）の推進とリスク管理 **課題**: 20年の歴史を持つ巨大システムであり、データベースはアプリケーションのロジックと密結合していました。 **行動**: 専門の移行チームと連携し、Oracle特有のSQLなど依存している箇所を特定。調査の過程で、**既に使われていない「不要機能」の特定も主体的に行い**、新システムのスリム化にも貢献しました。 **成果**: 事前にリスクと不要な機能を洗い出したことで、移行計画の精度を向上。**1年がかりの巨大DB移行プロジェクトを、大きな事故なく安全に完遂させることに大きく貢献しました。** #### 2. C言語で書かれたレガシーサービスのRailsによるリプレイス **課題**: 一部のサービスはC言語で書かれており、機能追加のスピードやメンテナンス性に大きな課題を抱えていました。 **行動**: C言語のレガシーサービスを**Ruby on Railsでリプレイスする開発を担当**。単にロジックを書き換えるだけでなく、Oracleに最適化されていたテーブル構造を**PostgreSQLに合わせて再設計**し、**新旧サービス間のデータ移行**までを一貫して行いました。 **成果**: 属人化していたサービスをモダンなRailsアプリへと刷新し、**開発生産性とメンテナンス性を大幅に向上させました。** #### 3. プロアクティブなシステム信頼性向上への取り組み **課題**: 障害発生時の調査に多くの時間を要しており、その根本原因は不十分なログや脆弱なエラーハンドリングにありました。 **行動**: 障害対応後、根本原因を分析し**再発防止策の実装までを担当**。具体的には、**ログ出力の体系的な改善**や、**冪等性を考慮したリトライ処理の追加**などを主導しました。 **成果**: 日々の差し込み対応を、**システムの弱点を特定し、継続的に品質を改善していく機会**へと転換。システムの安定稼働に大きく貢献しました。

# 【プロジェクト概要】 お薬手帳アプリのバックエンドAPI開発プロジェクト。システムは**マイクロサービスアーキテクチャ**を採用しており、その中核となる「外部お薬手帳システム連携サービス」の開発を担当しました。プロジェクトの立ち上げフェーズから参画し、技術的な課題だけでなく、チーム体制や開発プロセスの課題解決にも取り組みました。 # 【自身の役割と担当範囲】 4名の受託開発チームの一員として、要件定義から設計、開発、テストまでの一連の工程を担当しました。 それに加えて、チームが抱える技術的・プロセス的な課題を解決するため、実質的な**「Ruby技術のリード」**と**「開発プロセスの調整役」**という重要な役割を担いました。 # 【具体的な行動と工夫】 ## 1. Ruby技術のリードとチームのスキルアップ支援 * **課題**: 開発リーダーがJava経験者であったため、チーム内にRuby on Railsでの開発経験や知見が不足していました。 * **行動**: 私が主体となり、RubyやRailsのコーディング規約、効率的な書き方などについて**チーム全体へ知識共有を実施。** また、**全てのコードレビューを担当**し、具体的なフィードバックを通じてチームメンバーのスキルアップを支援しました。 * **成果**: チーム全体のRails開発スキルを底上げし、コードの品質を担保。 結果として、スムーズな開発サイクルを実現することに貢献しました。 ## 2. 開発プロセスの最適化（アジャイルとWFのハイブリッド） * **課題**: お客様はアジャイル開発を望む一方で、開発リーダーはウォーターフォール開発の経験が豊富という、開発手法のミスマッチがありました。 * **行動**: 私が両者の間に立ち、調整役を担いました。 お客様と密にすり合わせを行い、アジャイルのスピード感とウォーターフォールの計画性を両立する**ハイブリッドな開発プロセスを模索・提案**しました。 * **成果**: 全員が納得感を持って開発に進める体制を構築し、**「スピード」と「品質」を両立させることに成功しました。** ## 3. 不明瞭な要件と複雑なドメイン知識の攻略 * **課題**: 外部システム連携が前提のため仕様が不明瞭な点が多く、また「お薬手帳」業界ならではの特殊なドメイン知識のキャッチアップにチーム全体が苦戦しました。 * **行動**: プロジェクト初期段階のヒアリングから参加。 不明瞭な点を放置せず、**お客様への質問の仕方を工夫**したり、チーム内での**役割分担を明確化**したりすることで、効率的にドメイン知識を吸収・共有できる体制を構築しました。 * **成果**: 複雑なドメイン知識が求められるプロジェクトにおいて、**チームの学習速度を加速させ、手戻りの少ない開発を実現**しました。 ## 4. 保守性と拡張性を両立するAPI設計 * **課題**: マイクロサービスとして提供するAPIは、ドメイン知識が複雑である一方、将来の仕様変更に強い、保守性と拡張性の高い設計が求められました。 * **行動**: * 各APIエンドポイントが持つ複雑なビジネスロジックを、**サービスオブジェクトパターン**を用いて機能単位でカプセル化。責務を明確に分離し、見通しが良くテスト容易性の高い構造を徹底しました。 * 複数のAPIで繰り返し現れる定型的なコードを削減するため、**Rubyのメタプログラミング**を積極的に活用。動的にメソッドを定義するモジュールなどを設計し、DRYの原則に基づいた効率的な開発を推進しました。 * **成果**: コードの再利用性を高め、ボイラープレートコードを大幅に削減。**新機能追加時の開発スピード向上**と、**チーム全体のコード品質の底上げ**に貢献しました。 ### 【結果・得られたこと】 * **定性的成果**: * 技術的な課題だけでなく、チームのスキルギャップや開発プロセスのミスマッチといった、より複合的な課題を解決に導く経験を積みました。 * プロジェクトの立ち上げから、主体者としてリーダーシップやメンターシップを発揮し、チームを成功に導くことに貢献できました。 * **技術的成長**: * マイクロサービスアーキテクチャにおけるAPIの設計・開発経験。 * サービスオブジェクトやメタプログラミングといった、保守性・生産性を高めるための実践的な設計手法。 * 医療・ヘルスケア領域のドメイン知識と、機微な情報を取り扱うシステム開発のノウハウ。

# 【プロジェクト概要】 自社開発のWebスタートアップにて、2つの異なるSaaSプロダクト開発を担当しました。 - **自治体向けBIサービス（新規機能開発）** - **toC向け 飲食店×ユーザー マッチングサービス（保守開発）** 急成長する組織の中で、開発プロセスの構築やSRE体制の整備など、技術的な課題解決に留まらない役割を担いました。 # 【自身の役割と担当範囲】 6名の開発チームにおいて、フルスタックエンジニアとして開発全般に携わると同時に、**「インフラ/セキュリティ領域のドメインリーダー」**を兼務しました。 私のミッションは、新規機能開発をリードするだけでなく、**サービスの信頼性を担保し、事業の成長を支えるための技術基盤と開発プロセスを構築・整備する**ことでした。 # 【具体的な行動と工夫】 ## 1. インフラ/セキュリティ領域のドメインリーダーとしての牽引 - **課題**: 事業の成長スピードに対し、インフラの拡張性やセキュリティ体制の強化が追いついていない状況でした。 - **行動**: 私がインフラ/セキュリティ領域のドメインリーダーとして、**主要ライブラリのバージョンアップやAWSリージョン移行といった、サービスの信頼性に直結する重要プロジェクトを計画・推進**しました。外部パートナーへのタスクの切り出しや進捗管理も担当し、チーム全体のリソースを最適化しながらプロジェクトを完遂に導きました。 - **成果**: セキュリティリスクを低減し、システムのパフォーマンスを向上。将来の事業拡大に耐えうる、スケーラブルなインフラ基盤を構築しました。 ## 2. SRE体制の構築とサービス品質の向上 - **課題**: スタートアップ特有の「プロセスが未整備」な状態であり、障害対応が属人化し、サービスレベルも定義されていませんでした。 - **行動**: 障害発生時の**原因調査から恒久対応までをメイン担当**として受け持つ中で、場当たり的な対応から脱却するために**インシデント管理のワークフローを設計・構築**しました。さらに、**利用者に対する責務を明確化するためのSLA（Service Level Agreement）を、私が主体となって制定**しました。 - **成果**: 障害対応プロセスを標準化し、復旧までの時間を短縮。サービス品質の指標を定めることで、事業の信頼性向上に大きく貢献しました。 ## 3. 2つの異なるSaaSでのフルスタック開発 - **課題**: 自治体向け（BtoG）と消費者向け（BtoC）という、ドメインも開発フェーズ（新規開発と保守）も全く異なる2つのプロダクトを並行して担当する必要がありました。 - **行動**: 自治体向けBIサービスでは要件定義からリリースまで一貫して新規機能開発を担当。 マッチングサービスでは、ユーザーからのフィードバックを元にした改善や安定運用のための保守開発を推進。いずれもReact/TypeScriptによるフロントエンドから、Rails/MongoDBのバックエンド、AWSインフラまで、全ての領域に携わりました。 - **成果**: 異なるビジネスドメインや開発フェーズに柔軟に対応できる、高いキャッチアップ能力とフルスタックな技術力を証明しました。

【プロジェクト概要】 音楽好きのユーザーが、自身の好きなアルバム9枚を選んで共有できるソーシャルWebサービス「MyFavoriteAlbums」を、企画・設計・開発・リリース・運用まで全て一人で行いました。 プログラミングスクールの卒業制作として開発し、リリース後、最終的にユーザー数8,000人以上、総PV数56,000以上と、多くの方にご利用いただくサービスに成長。そのコンセプトとデザイン性が評価され、アートイベント「GEISAI#21」にも出展いたしました。 （※現在はTwitter APIの仕様変更に伴う維持費高騰のため、サービスはクローズ済です） 【開発の目的・背景】 モダンなWebアプリケーション開発技術を習得するため、以下の目標を掲げて開発しました。 フロントエンドとバックエンドを分離した実践的なアーキテクチャ（Nuxt.js SSR + Rails API）の構築 複数の外部API（Spotify, Twitter）を連携させた、付加価値の高いサービスの実現 企画からリリース、その後の運用まで、Webサービスのライフサイクル全体を一人で経験すること 【具体的な行動と工夫（アピールポイント）】 1. モダンなフロントエンド・バックエンド分離構成 行動: SEOとパフォーマンスを考慮し、フロントエンドにはNuxt.jsをSSR（サーバーサイドレンダリング）モードで採用。バックエンドはRailsをAPIモードで構築し、責務を完全に分離しました。 成果: 表示速度が速く、かつメンテナンス性と拡張性に優れた、モダンで実践的なWebアプリケーションアーキテクチャを実現しました。 2. 外部API連携による豊かなユーザー体験 行動: Spotify APIと連携し、ユーザーがアルバムを簡単に検索し、ジャケット写真や情報を取得できる機能を実装。また、Twitter APIを用いた認証機能や、自身のアルバム選択をシェアする機能も開発しました。 成果: 外部APIを効果的に利用することで、ユーザーの手間を省き、シームレスでリッチな体験と、SNSでの拡散力を両立させました。 3. ユーザー体験を重視したUI/UX設計 行動: コンポーネントフレームワーク Vuetify を用いて、直感的で使いやすいUIを設計。ユーザーが「自分の好きなアルバム一覧を、ずっと眺めていたくなる」ような、愛着の湧くデザインを目指しました。 成果: 誰でも簡単に操作できるUI/UXを実現し、多くのユーザーに受け入れられるサービスとなりました。 【結果と学び】 個人開発したサービスが、最終的に8,000人を超えるユーザーの手に渡り、実際に使われる喜びと、その反響の大きさを肌で感じることができました。 この経験を通じて、技術力はもちろんのこと、ユーザーからのフィードバックを元に改善を繰り返すグロースハックの視点や、サービスを安定稼働させ続ける運用・保守の重要性を深く習得しました。 また、サービスをクローズするという意思決定を通し、外部APIへの依存リスクや、個人開発における収益性と維持コストのバランスといった、サービス運営のビジネス的な側面も実体験として学ぶことができました。

【プロジェクト概要】 大手生命保険会社のミッションクリティカルな基幹システムである、販売管理システムおよび会計システムの開発に従事しました。 このプロジェクトの最大の特徴は、NEC製および顧客独自開発という2種類の独自フレームワークが採用されていた点です。 【自身の役割と担当範囲】 開発チームのプログラマー（PG）として、システムの機能開発を担当。 具体的には、営業担当者が使用する オンライン帳票画面の作成と、夜間に実行される会計データのバッチ処理開発という、特性の異なる2つの領域に携わりました。 【具体的な行動と工夫】 1. 独自フレームワークとレガシー言語への迅速な適応 - 課題： - 市場に情報がほとんどない、2種類の独自フレームワークとCOBOL・C言語を短期間で習得し、開発で成果を出す必要がありました。 - 行動： - プロジェクト参画後の初期研修に集中して取り組み、基本を徹底的に学習しました。 - その後、既存のソースコードを大量に読み解き、ドキュメント化されていない設計思想やコーディング作法を能動的にキャッチアップ。 - 不明点は積極的に有識者へ質問することで、知識の吸収速度を最大化しました。 - 成果： - 未経験の技術環境ながら、期間内に担当機能の開発を完遂。どのような技術スタックや開発環境であっても、迅速に適応し、自走できる能力を証明しました。 2. オンライン・バッチ両面の開発による処理方式への深い理解 - 課題： - ユーザーからの即時応答が求められるオンライン処理と、大規模データを正確に処理するバッチ処理では、設計思想や考慮すべき点が全く異なりました。 - 行動： - オンラインの帳票画面開発では、ユーザーの操作性を意識したUIとリアルタイムでのデータ整合性を考慮した実装を行いました。 一方、会計バッチ処理開発では、データの正確性、異常系処理、そして膨大なデータを効率的に処理するためのパフォーマンスを重視して開発に取り組みました。 - 成果： - 特性の全く異なる2つの処理方式の開発を経験したことで、システムの要件に応じた最適な処理方式を判断・設計できる、技術的な引き出しの多さを培いました。

# 【プロジェクト概要】 社会インフラである大手新聞社の情報システム部に所属し、紙面の新聞製作からデジタル配信（Web/アプリ）まで、事業の根幹を支える 全システムの安定稼働を担う、ミッションクリティカルな運用・保守業務に従事しました。 # 【自身の役割と担当範囲】 運用保守チームの一員として、オンプレミスのサーバーからAWS上のクラウドインフラ、ネットワーク機器まで、 多岐にわたるシステムの監視および障害発生時の一次対応を担当しました。 特に、デジタル配信（Web/アプリ）システムの担当チームに所属し、サービスの安定稼働に責任を持ちました。 # 【具体的な行動と工夫】 ## 1. 運用業務の枠を超えた、主体的な業務改善と開発への第一歩 - 課題: 日々の運用業務はマニュアルベースの定型的なものが多く、改善の余地がありました。 - 行動: 私は単に障害対応をこなすだけでなく、常に「どうすればもっと効率的になるか」を考え、業務改善に主体的に取り組みました。 - 具体的には、分かりにくいマニュアルの整備・更新を進め、チーム全体の業務標準化に貢献。 - さらに、非効率だった社内ツールの課題を自ら発見し、HTML/CSS/JavaScriptを用いて画面改修を提案・実施しました。 - 成果: チームの業務効率を改善すると同時に、「自ら作って改善する」経験が、私のキャリアが運用担当者から開発者へと向かう大きなきっかけとなりました。 ## 2. 大規模ハイブリッド環境でのインフラ運用保守経験 - 課題: システム環境は、伝統的なオンプレミスのデータセンターと、モダンなAWSクラウドサービスが混在する、大規模で複雑なものでした。 - 行動: ZabbixやJP1といった監視ツールを用いて24時間365日のシステム監視を行い、障害発生時にはLinux/Windowsサーバーの再起動やログの切り分けといった一次対応を迅速に行いました。 - オンプレミスの物理機器からAWSの各種サービス（EC2, S3, Lambda）まで、幅広い知識が求められる環境でした。 ## 成果 - この3年半の経験を通じて、アプリケーションが動く土台であるITインフラ（サーバー、ネットワーク、クラウド）に関する、深く体系的な知識を習得しました。 - この知識は、後のフルスタックな開発キャリアにおける、障害に強い安定したシステムを設計する上での強固な土台となっています。