Kubo

## プロジェクト概要 商業施設向け管理SaaSの開発全般に関して、オーナーシップを持って開発・運用に着手しています。 ## 役割・体制 ### 自身のポジションと役割 - 参画当時(2025年6月)はメンバーとして主にバックエンドとインフラを開発していました。 - 2025年11月からテックリードとして、SaaSのフロントエンドからインフラまで管理しています。 - チーム内のエンジニアリングマネジメントやエンジニア採用を行っています。 - 現状はPoCですが、FDEとして開発のみではなくクライアント様に直接訪問して課題をヒアリングして解決することも行っています。 ### チーム規模と構成 - エンジニア4名（うち業務委託2名）とカスタマーサクセス2名（うち1名がPdM兼任）の計6名体制です。 ## 背景・課題 - テナント数が1年で2倍程度（数万店舗単位）に増える過程で、レシートOCR処理周りが滞留するので解決する必要がありました。 - 11月当時テックリードが2ヶ月で2人辞め、当時もう1名がジュニアエンジニアだったので私が主導してドメイン知識を吸収しながらサービスを安定稼働させる必要がありました。 - メンバーが不足したため、業務委託や正社員採用を早急に行う必要がありました。 - チーム内の安定稼働と同時並行でクライアント様からの要望や新機能作成でのアップセルを含めて営業利益の目標を達成する必要がありました。 ## 実際の取り組み ### 設計・改善内容 - Google CloudのWorkflowsとClloud Tasksを用いてリアーキ＆深夜の再実行Jobを追加することで、滞留時のdeadletter発生を0件にしました。（他のプロジェクトで詳しく書いてます。） - ロードマップの見直しで取捨選択を行いエンジニアのタスクマネジメントを実施することや、Claude Codeを活用して外部連携や稼働しているJobの詳細等のドメイン知識を体系的に調査しpluginとして配布することで安定稼働に貢献しました。 - カスタマーサクセスの方と2人で主導してエンジニアの業務委託・正社員採用を実施することや、社内の採用ワークフロー策定等を実施しました。 - 安定稼働のための施策と並行して、OCR結果のリアルタイム自動入力やレシート画像でのハイライト表示等、アップセルを行うための追加施策を実装し売上アップに貢献しました。 ## 成果・価値 - インフラ基盤の安定性向上により、OCRサービスの信頼性が向上し、クライアントの業務効率化に寄与しました。 - 私がリードを務めてから、新規機能やインフラ改修等を行なった上で重大なインシデントは発生してません。 - 業務委託の方を採用開始から2ヶ月で2人採用し、現在も稼働いただいています。 - 正社員はロードマップから進捗が遅れていますが、母集団形成等を行い内定者も出しています。 - 社内の4つのプロダクトで唯一、毎四半期の売上や営業利益の目標を達成しています。

## プロジェクト概要 商業施設向け管理SaaSのインフラ技術負債を解消し、Pub/Sub処理の安定化と復旧自動化を実現しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンド・インフラ・SREエンジニア兼テックリードとして、Google Cloud上のPub/Sub処理の技術的意思決定と技術選定を主導しました。 - 要件定義から設計、コーディング、テスト、運用・保守まで一貫して担当し、特に非同期処理のオーケストレーションと復旧自動化に注力しました。 ### チーム規模と構成 - エンジニア4名（うち業務委託2名）とカスタマーサクセス2名（うち1名がPdM兼任）の計6名体制です。 ## 背景・課題 - レシート撮影OCR時にGoogle Cloud Pub/Subの複数サブスクリプションで値取得、金額の整合性チェック、外部へのデータ連携等を非同期で処理していたのですが、ピークタイムに滞留しdeadletterの発生やPubSubの複数回subscription等の重複処理が生じていました。 - 利用テナント数が月毎に1,000件弱増えていくため、加速度的に滞留が加速しており早急に解消する必要がありました。 - OCR処理の滞留やdeadletterにより深夜に異常レコードを手動で修正する必要があり、運用負荷が高く業務効率を著しく低下させていました。 - クリティカルなインフラ構成変更を伴うため、社内でのQAやブルーグリーンデプロイメントによる段階的リリースを慎重に進めなければならない課題がありました。 ## 実際の取り組み ### 設計・改善内容 - Pub/Subの滞留発生時にdeadletterが発生しないよう、WorkflowsとTasksで処理フローをオーケストレーションしつつ、適切な待機時間を確保して同期的に処理することで滞留を緩和しました。 - 従来手動で行っていたPub/Subの重複配信やOCR失敗に対する復旧作業を、Jobとして自動化し、深夜の手作業を完全に排除しました。 - AIで代替可能な部分（設計レビューの壁打ちや実装、動作確認等）を補いながら実装することで、2ヶ月程度の期間で実装が完了しました。 - ブルーグリーンデプロイメントを用いた段階的リリースを実施し、リスクを最小化しながら新インフラ構成を本番環境に適用しました。 ### その他アピールポイント - 技術的負債の解消により、システムの安定稼働と保守性向上を実現し、将来的な拡張に耐えうるインフラ基盤の土台を構築しました。 ## 成果・価値 - Pub/Sub処理の滞留問題を解消し、deepletter発生を防止したことで、深夜の手動復旧作業をゼロに削減しました。 - インフラ基盤の安定性向上により、OCRサービスの信頼性が向上し、クライアントの業務効率化に寄与しました。

## プロジェクト詳細 アルバイトの求人で求められる強みや適性と、ユーザが設定した強みや適性、希望条件からマッチ度を測定し、マッチ度が高い求人をレコメンドするサービスの企画から開発までを行っています。 2024年の6月から開始したプロジェクトで、スクラム -> ウォーターフォールでサービスを開発しています。 プロダクトマネージャー、スクラムマスター、デザイナー、エンジニア2名で構成されたチームでスクラムを行っております。 6月から7月でサービスの企画からMVPに必要な機能の選定まで行い、11月上旬に1st MVPをリリースしました。 8月初旬からはスクラムではなくウォーターフォール形式で開発を進めていましたが、リリース後は検証スピードを上げるためにスクラムに戻しています。 ### 開発言語 - フロントエンド：Typescript(Next.js) - スキーマ駆動開発のためにopenAPIを使用 - 保守性とテスタブルな設計にするため、AtomicデザインとBCDデザインを合わせたアーキテクチャで構成 - バックエンド：Go(Echo) - スキーマ駆動開発のためにopenAPIを使用 - 保守性とテスタブルな設計にするため、オニオンアーキテクチャを採用 - バッチ処理：AWS Lambda、OpenSearch - S3バケット内にあるCSVの更新をトリガーとしてDBに情報を保存するバッチの作成 - 企業が求める適性、強みとユーザの適性、強みを加味して類似度を測定するためにOpenSearchを使用 - ORM：Gorm - DBの起動、infrastructure層でのDB接続に使用 - マイグレーションはバージョン管理を行いたかったためAtlasを採用し、gormタグを付与した構造体からマイグレーションファイルを生成、DBに適用 - インフラ：AWS - コンテナ管理しているため、ECSでフロントエンド、バックエンドにデプロイ - DBはRDS(MySQL)を使用 - デプロイはGitHub Actionsから起動させたCodePipelineを使用 - CI/CD：GitHub Actions - CIでは、フロントエンドで静的解析と脆弱性チェック、バックエンドでは静的解析とテスト、脆弱性チェックとマイグレーションチェックを行う - CDではAWSのECRにイメージを送信し、CodePipelineにて行う - 開発環境：Docker - 環境の差を無くすために利用 - フロントエンド、バックエンド、DBをコンテナ管理 ## 課題に対する工夫 ### 課題1：自分に合った求人を知りたいニーズに沿えていない 本サービスの潜在層（高校生や大学生）にユーザインタビューを行ったところ、「どういった仕事があるのか分からない」や「自分に合った仕事を知りたい」というニーズがあることに気が付きました。 「どういった仕事があるか分からない」に関しては適職診断サービスをリリースしたのでアプローチ出来ていますが、「自分に合った仕事を知りたい」というニーズに対してはアプローチ出来ていませんでした。 ### 工夫1：求人とユーザのマッチ度を測定し、高いものを自分に合った仕事として紹介する 企業の方が設定した「どういう人材を欲しているか」とユーザの方が設定する「どのような価値観、希望条件か」をキーとしてOpenSearchでベクトル検索を行うことで、ユーザの希望と近い求人をオススメすることを考えました。 ベクトル検索で行うことでルールに頼らない類似度を測定できるので、より普遍的にユーザが求める求人を紹介することができるのではと考えています。 ### 課題2：開発体系をスクラムに固執していた 前のPJでスクラムを行っていたことから、そのままの体制で本PJもスタートしました。 しかし、以下の点からこのPJはスクラムには向いていませんでした。 - まずはMVPを完成させることが最優先 - 納期が10月末と初めから決まっていた - 裏側の処理から作り始めていたので、レビューでステークホルダーに見せれるものが無い ### 工夫2：積極的に働きかけ、開発体制をウォーターフォールに変更 上記を踏まえて、納期が決まっているならウォータフォールが最も良い選択だと考えチームやステークホルダーに投げかけを行いました。 ステークホルダーとしては納期に間に合う＆品質の良いものであればOKとのことだったので、チームメンバーと相談して開発体制をウォーターフォールに変更しました。 それにより、遅れていた進捗が開発に集中できることで巻き返すことができ、10月初旬にある脆弱性診断までにMVPの機能を完成させられる余裕が出てきました。 ## 出来ること - 0-1でのサービス開発 - カイゼン思考での開発 - 企画、設計、開発 - フロントエンド、バックエンドを問わない開発 - インフラ構成の検討 - OpenSearchを用いたベクトル検索の実装

## プロジェクト詳細 アルバイトサイトにおけるユーザのCV率を上げるため、バイト応募前後に抱える問題を解消するためのサービスを開発し、検証するプロジェクトになっています。 昨年8月から開始したプロジェクトで、スクラム開発でサービスを開発しています。 プロダクトマネージャー、スクラムマスター、デザイナー、エンジニア2名で構成されたチームでスクラムを行っております。 11月まではビジネスサイドの方と企画検討や、サービスの設計を行い、11月から開発が始動しました。 ### 開発言語 - フロントエンド：Typescript(Next.js) - スキーマ駆動開発のためにopenAPIを使用 - 保守性とテスタブルな設計にするため、AtomicデザインとBCDデザインを合わせたアーキテクチャで構成 - SPA風のフォームを作成するためNext.jsを利用 - App Routerでreact-hook-formやzodを用いたフォームを作成 - Server ActionsでバックエンドのAPIにリクエストし、レスポンスによる表示の内容を変更 - バックエンド：Go(Echo) - スキーマ駆動開発のためにopenAPIを使用 - 保守性とテスタブルな設計にするため、オニオンアーキテクチャを採用 - ユニットテストの作成 - 診断コンテンツの設問取得APIや、各フォームの回答結果送信API、診断コンテンツの結果取得APIを作成 - SendGridを使用した結果送信メール機能の作成 - ORM：Gorm - DBの起動、infrastructure層でのDB接続に使用 - マイグレーションはバージョン管理を行いたかったためAtlasを採用し、gormタグを付与した構造体からマイグレーションファイルを生成、DBに適用 - インフラ：AWS - コンテナ管理しているため、ECSでフロントエンド、バックエンドにデプロイ - DBはRDS(MySQL)を使用 - デプロイはGitHub Actionsから起動させたCodePipelineを使用 - CI/CD：GitHub Actions - CIでは、フロントエンドで静的解析と脆弱性チェック、バックエンドでは静的解析とテスト、脆弱性チェックとマイグレーションチェックを行う - CDではAWSのECRにイメージを送信し、CodePipelineにて行う - 開発環境：Docker - 環境の差を無くすために利用 - フロントエンド、バックエンド、DBをコンテナ管理 ### これまでに作成したサービス - 応募後連絡が来ない等の困り事を解決するコンシェルジュサービス - 初めてのアルバイトをする方向けの、自身の強みと推奨職種を診断するサービス - 企業に質問したいことを匿名で質問出来るサービス ## 課題に対する工夫とバリュー ### 課題1：アルバイトの面接応募後に企業からの返信が来ないユーザが一定数存在 アルバイトまでの仕組みとしてはユーザが働きたい企業を見つけると、その企業に電話 or Webサイト上で面接の申し込みを行います。 しかし、応募したユーザの中でそもそも企業から返信メールが返ってこない課題が存在しており、既存の相談フォームにも全体のユーザの0.02%ほど寄せられていました。 しかし、潜在層も含めるとたくさんの方が困っている現状がありました。 ### 工夫とバリュー1：相談フォームを一新＆ユーザが見つけやすいようにサイト内のUI改善 既存フォームだと何が相談できるか＆どこにフォームが存在しているか把握しづらかったため、相談フォームで何が出来るか説明するLPをアルバイトサイト上の応募履歴画面上にポップアップ表示させるようにしました。 また、相談フォーム自体も親近感があるデザインで作成し、なるべくユーザが相談しやすい環境を整えました。 SPA風のフォームとステップ数の表示を行うことで、ユーザの回答送信までの離脱率を減らす工夫をしました。 結果的に、既存のフォームと比較して7倍の利用率となりました。 （PoCなので、検証は東京エリアのみに限定していました。） ### 課題2：求人詳細画面で知りたい情報を全て知ることが出来ない 求人詳細画面では、基本的な情報にプラスして職場の雰囲気や業務内容などを掲載していました。 しかし、ユーザインタビューを行った結果「髪色指定はあるか？」であったり「シフトはテスト期間等に調整できるか？」などの疑問が面接に行くまでは知ることが出来ず、ミスマッチが発生していることが判明しました。 ### 工夫とバリュー2：匿名で質問できるフォームの作成と周知 求人詳細でそれらの情報を全て網羅することは不可能に近いため、質問があればフォームで受け付け、企業に回答してもらうというフローを作成しました。 SPA風のフォームと設問数の表示により、ユーザの離脱率を減らす工夫をしました。 以前作成した相談フォームをコンポーネント化し、再利用することで1Sprintで開発、リリースを行いました。 また、ユーザがなるべく求人情報を閲覧できるように、フォームへのリンクを求人詳細画面の右下に配置しました。 その結果、東京エリアで1ヶ月に100件の質問があり、相談後に応募した方が相談件数全体の約60%という数値になりました。 これは、ミスマッチを応募前に防ぐと同時に応募へのサポートが行えたのではと考えています。 ### 課題3 利用者層として高校生、大学生がボリューム層となっているのですが、初めてアルバイトを行う方にとってどのような職種があるか、また自分にはどのような仕事が合っているか分からないという事実をユーザインタビューで判明しました。 しかし、自分に合っている仕事を知る手段が現状ありませんでした。 ### 工夫とバリュー3：自身の強みによるオススメ職種診断サービスの開発 アルバイト診断サービスを開発することで、アルバイト未経験の方でも職を探しやすくなるようにしました。 ロジックはルールベースにすることで開発速度を上げ、いち早くPoCを回せるようにしました。 回答結果は自身の強みが分かりやすいようにグラフ化しました。 オススメ職種の体験談を同時に掲載することでオススメ職種の仕事イメージが持ちやすいようにしました。 診断結果で自身の所在地を入れることで、その近辺でのオススメ職種の求人一覧が出るためユーザが探す手間を省く工夫をしました。 バリューとして、東京エリアでの限定公開で平均50件/日ほど利用していただいています。 その中で、およそ5%ほどが未来が広がるアルバイト診断経由での求人応募を行っています。 ## 出来ること - 0-1でのサービス開発 - 大規模サービスのカイゼン - 企画から設計、開発、運用まで経験 - スクラム開発によるスピード感のあるサービス開発とカイゼン - フロントエンド、バックエンドの両方での開発 - インフラ構成の検討

## プロジェクト詳細 毎年夏、冬に開催されるハッカソン型インターンシップで使用するサービスの開発を行うプロジェクトです。 今年の2月から始まったプロジェクトで、インターンシップに参加する学生の方がこれまでに開発したポートフォリオを登録出来るサイトを作成しました。 先月の5月下旬に完成し、納品することが出来ました。 フロントエンド、バックエンド、インフラ、デザインチームに分かれて開発し、自分はバックエンド開発を担当しました。(バックエンド3名) ### 開発言語 - フロントエンド：Typescript(Next.js) - Atomicデザインを採用し、各コンポーネントを再利用する形で開発 - 学生が理解しやすいようにPage Routerを採用 - バックエンド：Typescript(Node.js) - 学生が理解できるように、フロントエンドと同様の言語を使用 - 基本的なMVCモデルに沿うように設計 - 認証、プロフィール、ポートフォリオを一通り操作するためのAPIを作成 - ORM：Prisma - Prismaを利用してマイグレーションファイルのバージョンを管理 - 開発環境：Docker - 開発環境を統一するために利用 - フロントエンド、バックエンド、DBをコンテナ管理 ## 課題に対する工夫とバリュー ### 課題1：既存のハッカソン用サイトだと、学生がカイゼンできる事が少ない 既存のサイトでは、人生年表というサイトをハッカソンで利用していましたが、このサイトでは学生が短期間で追加できる機能は限られていました。 例えば、デフォルトの人生年表作成画面では６つのポイントしか記述出来ない所を可変にしたり、UIをカイゼンする程度のことしか出来ませんでした。 また、アーキテクチャも適当であったために学生が理解しづらい事も機能改修が上手く行かない原因にもなっていました。 ### 工夫とバリュー1：シンプルな作りのサイトを作成＆学生が理解しやすいアーキテクチャを設計 今回作成したポートフォリオサイトは、認証、ポートフォリの閲覧と作成、プロフィールの閲覧と編集、いいね機能程度の最小限のサイトにしました。 これにより、学生が想像力を働かせて様々な機能を実装できるようにしました。 また、フロントエンドとバックエンドを同じ言語に統一し、バックエンドのアーキテクチャも学生が理解しやすいMVC設計にすることで、既存のサイトより可読性が向上しました。 ### 課題2：サイト作成の期限が4ヶ月＆全員片手間での実装になる 今年度の夏インターンまでにリハーサルするため、開発期限は6月いっぱいまでに設定されていました。 さらにバックエンドとフロントエンドのAPIを連携させるために、バックエンド側の実装は4月中に終わらせて欲しいとの要望もありました。 また、急遽発足した任意参加のプロジェクトであるため、参加して頂いたエンジニアは全員業務時間内の僅かな時間を利用して開発に参加せざるを得ませんでした。 ### 工夫とバリュー2：開発に参加しつつバックエンドチームのプロジェクト管理を実施 バックエンドチームは3名のみでしたが、実装する機能は多く無かったため、私がバックエンドチームの管理を行うことで納期に間に合うようにしました。 具体的には、タスクを全て洗い出した後Github Projectを利用して進捗管理を行いました。 業務が忙しい方にはなるべくタスクを減らしてもらうことで、タスクの依存関係によるブロッキングを発生しないように努めました。 その結果、バックエンドはエンジニア3名で納期までに全ての機能を実装出来ました。 また、修正依頼も無かったためスピードだけでなく品質も良いものになりました。 ## 出来ること - 0-1でのサービス開発 - Node.jsでのバックエンド開発 - 学生が理解できるようなアーキテクチャの検討とハンズオン作成 - 小規模チームのプロジェクト管理 - エンジニア採用の協力