ID:62196さん

# 【内製/月57h削減】GCP Natural Language APIを活用した、書類選考の自動トリアージシステム ## 【概要】 月間数百件の応募書類（自由記述欄）をAIで解析し、候補者の熱量をスコアリングして優先順位付け（トリアージ）を行うシステム。 現在はプロトタイプとして保守性を重視し **GAS (Google Apps Script)** で運用していますが、応募数が月間10,000件を超えた場合のスケーラビリティを考慮し、**Google Cloud Functions (Python)** への移行設計および実装も完了しています。 ## 【技術的なこだわり・工夫】 **1. フェーズに合わせた技術選定 (Right Tool for the Right Job)** - **Phase 1 (MVP)**: 開発スピードと学習コストを最優先し、認証周りが容易な **GAS** を採用。数日でのリリースを実現し、月57時間の工数削減効果を早期に実証しました。 - **Phase 2 (Scale)**: 将来的な高負荷（月1万件〜）や処理時間の制約（GASの6分壁）を見越し、**Python (Cloud Functions)** によるバックエンドコードを設計・実装済みです。 **2. Pythonバックエンドの設計思想** リポジトリ内の `cloud_functions/` ディレクトリに実装済み。 - **Production Ready**: 環境変数の分離 (`os.environ`)、構造化ロギング、型ヒント (`Type Hinting`) を採用し、エンタープライズ品質のコード記述を行っています。 - **Serverless Architecture**: `functions_framework` を用いたイベント駆動型アーキテクチャを採用し、スケーラビリティとコスト効率を両立しています。 **3. スコアリングロジックのハイブリッド判定** APIの `Sentiment Score` だけでなく、自社の採用要件（特定の技術スタックやカルチャー）に合致するキーワードが含まれる場合にスコアを加重補正するロジックを独自実装し、False Positive（誤検知）を抑制しています。 ## 【使用技術・スタック】 - **Current**: GAS, Spreadsheet, Slack API - **Future (Ready)**: Python 3.10+, Google Cloud Functions, Flask (functions-framework) - **AI/ML**: Google Cloud Natural Language API

# 【完全サーバーレス】Repositoryパターンと排他制御を実装した、堅牢なニュース収集・配信エージェント (GAS) ## 【概要】 Google News RSSを定期的にクローリングし、重複排除を行った上でDB（スプレッドシート）に蓄積。ユーザーが指定した時間に、興味関心に基づいたHTMLレポートメールを配信するパーソナルエージェントです。 ## 【技術的なこだわり・工夫】 **1. アーキテクチャ：責務の分離** GAS開発で陥りがちなスパゲッティコードを防ぐため、**Repositoryパターン**を採用。 - `SheetRepository`（データアクセス）、`NewsApp`（ビジネスロジック）、`RssService`（外部通信）とクラスを明確に分離し、保守性とテスタビリティを担保しました。 **2. プラットフォーム制約の克服：MD5ハッシュによるキャッシュキー生成** GASの `CacheService` にある「キー長最大250文字」という制約を回避するため、長いURLをそのままキーにせず、**MD5ハッシュ化して固定長のキーを生成するロジック**を実装。 これにより、長大なURLを持つニュース記事でも確実にキャッシュヒットさせ、厳密な重複排除を実現しました。 **3. 信頼性の設計：排他制御とResiliency** - **排他制御**: `LockService` を実装し、トリガーが重複発火した際の競合状態（Race Condition）を防止。 - **自動リトライ**: 外部RSS取得時のネットワークエラーに対し、**Exponential Backoff（指数バックオフ）** アルゴリズムを用いた待機・リトライ処理を実装し、夜間バッチの安定性を高めました。 **4. 型安全性の確保** TypeScriptを用いない環境下でも、JSDoc（`@typedef`, `@param`）を厳格に記述。型定義を明示することで、IDE（VS Codeなど）での補完を効かせ、開発効率とコード品質を向上させました。 ## 【使用技術・スタック】 - **Language**: Google Apps Script (ES6+) - **Architecture**: Repository Pattern - **Libraries/Services**: CacheService, LockService, UrlFetchApp, GmailApp, Spreadsheet API - **Others**: MD5 Hashing, Exponential Backoff Algorithm

# 【多拠点一括管理】分散する3つのDBを自動統合し、店舗別採用KPIを可視化するデータパイプライン (GAS) ## 【概要】 多店舗展開を行う事業において、散在していた「店舗マスタ」「新店開業スケジュール」「応募者データ（ATS）」の3つのデータソースを自動で収集・統合。 「現在OPEN中で、かつ採用活動を行っている店舗」のみを自動抽出し、直近1ヶ月の選考フェーズ別KPI（応募・書類通過・面接・内定・辞退等）を日次で集計・出力するデータパイプラインです。 ## 【技術的なこだわり・工夫】 **1. アーキテクチャ：Service/Repositoryパターンの採用** GAS開発において、コード量が増えると可読性が下がる問題を解決するため、レイヤー分けを徹底しました。 - `SheetRepository`: スプレッドシートのCRUD操作（データアクセス層） - `RecruitmentService`: 店舗の抽出やKPI計算ロジック（ビジネスロジック層） - `Main`: エントリーポイントと設定注入 これにより、例えば「データソースがスプレッドシートからBigQueryに変わる」といった変更があっても、Repository層の修正のみで対応可能な疎結合な設計にしています。 **2. データの整合性担保：優先順位付きステータス判定** 採用選考では「内定辞退」や「選考途中での不合格」など、複数のステータスフラグが混在するケースがあります。 本システムでは、`入社 > 内定 > 辞退 > 不採用 > 選考中` という優先順位ロジックをコード内で定義し、KPIのダブルカウント（二重計上）を防止。正確な歩留まり分析を可能にしました。 **3. セキュリティと運用設計** - **機密情報の分離**: スプレッドシートIDなどの環境依存値はコードにハードコーディングせず、GASの `Script Properties` で管理し、セキュリティを確保。 - **設定の集約**: カラム位置やシート名は `CONFIG` オブジェクト（`Object.freeze`）で一元管理し、シート側のレイアウト変更に強い構成にしました。 ## 【使用技術・スタック】 - **Language**: Google Apps Script (ES6+) - **Architecture**: Service / Repository Pattern - **Logic**: Priority-based State Machine - **Ops**: Script Properties for Environment Variables

# 【採用実務効率化】候補者リスト読込・PDF自動添付・メール一括送信ツール (GAS) ## 【概要】 カジュアル面談後の「お礼メール」および「体験入店案内」の送信オペレーションを自動化するツール。 スプレッドシート上の候補者リストを読み込み、候補者ごとのステータス（未送信/送信済）を判定した上で、Google Drive上のPDF資料（マニュアル等）を添付した案内メールを一括送信します。 ## 【技術的なこだわり・工夫】 **1. 堅牢なバッチ処理設計（Robust Error Handling）** 一括処理系のスクリプトで最大の課題となる「途中での処理停止」を防ぐ設計にしました。 - **行ごとの独立性**: ループ処理内で `try-catch` ブロックを使用し、例えば「1人のメールアドレスが不正」などのエラーが発生しても、後続の候補者への送信処理は止めずに継続します。 - **ステータス管理**: 送信結果（成功/エラー内容）を即座にスプレッドシートの行に書き戻すことで、どこまで処理が完了したかを可視化し、再実行時の二重送信を防いでいます。 **2. セキュリティと保守性** - **機密情報の分離**: 送信元アドレスや企業名はコードに直書きせず、GASの `Script Properties` で管理。GitHub等でコード共有しても情報漏洩しない設計です。 - **責務の分離**: メール本文の生成ロジックを `MailTemplate` クラスに切り出し。本文の変更があっても送信ロジック（`MailService`）に影響を与えない疎結合な構成にしました。 **3. 運用への配慮** - **添付ファイルの動的取得**: スプレッドシート上で指定された `File ID` を読み取り、Google Driveから動的にPDFを取得・添付する仕組みを実装。候補者や店舗によって送付資料を変える運用にも対応可能です。 ## 【使用技術・スタック】 - **Language**: Google Apps Script (ES6+) - **Services**: GmailApp, DriveApp, SpreadsheetApp, PropertiesService - **Pattern**: Template Method Pattern (Mail Body Construction)

# 【Gmail完結】専用アプリ不要のサーバレス猫体重管理・給与計算システム (GAS) ## 【概要】 愛猫の健康管理を「面倒くさい」から「日常のついで」に変えるため、Gmailのみをインターフェースとした管理システムを開発。 リマインダーメールへの返信（空メール or 数値入力）だけで、食事記録・体重推移の記録・給与量計算・健康アドバイスの受信が完結する、UX重視のサーバーレスアプリケーションです。 ## 【技術的なこだわり・工夫】 **1. UI/UX設計：枯れた技術の活用** 「毎日必ず開くアプリ」であるGmailをUIとして採用。 - **フリクションレスな入力**: 「空メール＝食事記録」「数値入力＝体重記録」というシンプルな分岐ロジックを実装し、アプリ起動のストレスを排除。 - **即時フィードバック**: 入力値（体重）に応じ、サーバー側でRER/DER計算を行った上で、「今日の推奨給与量」や「ダイエット進捗」を即座にメール返信します。 **2. アーキテクチャ：保守性の確保** 個人開発の小規模ツールであっても、将来的な拡張を見越して責務を分離しました。 - `DietCalculator`（計算ロジック）、`SheetRepository`（DB操作）、`MailService`（Gmail操作）とクラスを分割。 - `ContentService` では、外部API（Cat Fact API）と翻訳API（Google Translate）を連携させ、単調になりがちな記録作業に「豆知識」というエンタメ性を付加しました。 **3. マネージドサービスの活用** - **LanguageApp**: 英語のAPIレスポンスを日本語に自動翻訳し、ユーザー（飼い主）に届けるパイプラインを構築。 - **Time-based Trigger**: 分単位のトリガーを使用しつつ、処理が必要なメール（未読＆特定件名）がない場合は即終了させることで、GASの実行時間制限（Quotas）を回避する設計にしました。 ## 【使用技術・スタック】 - **Language**: Google Apps Script (ES6+) - **Interface**: Gmail (MailApp, GmailApp) - **External API**: Cat Fact API, Google Translate API - **Logic**: RER/DER Metabolic Calculation

# 【独自SQLエンジン搭載】Google Sheets × GASで構築する、サーバーレス新卒採用BIダッシュボード ## 【概要】 「スプレッドシートをDBとして扱い、SaaS並みの分析体験を提供する」ことをコンセプトにした、新卒採用向けBIツール。 GASのHTML Serviceを用いた**SPA（Single Page Application）風のUI**と、スプレッドシートのデータに対してSQLクエリを実行できる**独自のクエリエンジン**を実装し、高度なデータ分析をサーバーレスで実現しました。 ## 【技術的なこだわり・工夫】 **1. 独自SQLパーサ＆クエリエンジンの実装** スプレッドシートのフィルタ機能では不可能な柔軟な抽出を行うため、`SELECT`, `WHERE` (AND), 演算子 (`=`, `!=`, `LIKE`, `>`, `<`) を解釈する**簡易SQLパーサをGAS（JavaScript）でフルスクラッチ開発**しました。 - 正規表現を用いたトークナイザと、条件判定ロジックを自装し、シート上のデータに対して「SQLによる問い合わせ」を可能にしました。 **2. フロントエンド：SaaSライクなSPA構成** GASの制約（サーバーサイドレンダリング）の中でリッチなUXを提供するため、`HtmlService` を活用。 - **コンポーネント指向**: タブ切り替え、モーダル表示、非同期データフェッチ（`google.script.run`）を組み合わせ、スプレッドシート上とは思えない「SaaSの管理画面」のような操作性を実現。 - **SQLテンプレート機能**: SQLが書けないメンバーでも、「プルダウン選択＋パラメータ入力」だけで複雑なクエリを自動生成・実行できるUIを構築し、データ分析の民主化を図りました。 **3. Infrastructure as Code (IaC) 的なアプローチ** 手作業でのシート作成を廃止し、スクリプト実行一発で「DB定義」「マスタ」「集計用数式が入ったダッシュボード」を自動生成する初期化ロジック（`initializeRecruitBI`）を実装。 誰でも、どのスプレッドシートでも同じ環境を再現可能にしました。 ## 【使用技術・スタック】 - **Backend**: Google Apps Script (ES6+) - **Frontend**: HTML5, CSS3 (CSS Variables for theming), Vanilla JS - **Core Logic**: Custom SQL Parser & Query Engine - **Architecture**: Server-Side Rendering with Client-Side Hydration

# 【Series D】採用ROIを最大化するデータドリブン・リクルーティングとオペレーション構築 ## 【背景・課題】 事業の急拡大に伴い、月間数百名の応募対応と多職種（エンジニア・コーポレート・店舗）の採用が並行。 「気合と根性」の採用活動からの脱却と、Series Dフェーズに求められる「再現性のある採用インフラ」の構築が急務でした。 ## 【施策内容：Ops & Marketing】 **1. 採用マーケティングの科学（A/Bテスト）** 「求人票は一度書いたら終わり」という通説を廃し、マーケティング視点を導入。 - 媒体ごとのCTR/CVRを週次で計測し、タイトル・訴求ポイント・アイキャッチ画像のA/Bテストを実施。 - スカウト文面においても、エンジニア向けには「技術的負債への向き合い方」、ビジネス職には「事業のLTV」など、ターゲットごとの"刺さる変数"を特定しました。 **2. 採用歩留まりのボトルネック解消** 選考フェーズごとの通過率（歩留まり）を可視化し、離脱ポイントを特定。 - **課題:** 書類選考〜一次面接の接続率が低迷。 - **対策:** 候補者の熱量が冷める前の「即レス」を徹底するため、GASによる自動日程調整ツールを導入し、リードタイムを平均3日から0.5日へ短縮。 - **施策:** 候補者体験（CX）向上のため、面接確定時に「会社の裏側がわかるNotionページ」を自動送付し、面接前の動機付けを強化。 **3. コスト適正化** 利用中のATS（採用管理システム）や媒体のROIを試算し、ベンダーと交渉。 - 3年契約スキームへの切り替えや、利用頻度の低いオプションの解約を行い、機能は維持したまま大幅なコストダウンを実現。 ## 【成果】 - **Web応募数 2.3倍増:** 月間40件→90件へ増加し、ダイレクトリクルーティング依存からの脱却に成功。 - **採用コスト削減:** 媒体費の最適化とATS契約の見直しにより、年間換算で数百万円規模のコストカットを実現（ATS単体でも約120万円削減）。 - **店舗出店計画の達成:** 地方エリアを含む月8店舗の出店ペースに合わせ、採用充足率100%を維持。

# 【Global】エンジニア採用におけるSLA導入と、市場適応型の人材要件定義（HRBP） ## 【背景・課題】 グローバルIT企業の日本拠点において、本社の意向と日本市場のギャップにより採用が難航。 特に「ハイスキル×語学力×出社」という高難易度要件により、母集団形成ができず、選考リードタイムも長期化（平均60日以上）していました。 ## 【施策内容：HRBP & Stakeholder Management】 **1. データに基づく要件定義の再構築（Reality Check）** 現場マネージャーやGlobalのステークホルダーに対し、日本のエンジニア市場データ（給与レンジ・リモートワーク希望率・有効求人倍率）を提示して交渉。 - 「Must要件（絶対必要）」と「Want要件（育成でカバー可能）」を切り分け、語学要件や出社頻度の緩和を実現。 - 「市場にいない人材」を探すのではなく、「自社で活躍できるポテンシャル層」へターゲットを再設定しました。 **2. 選考プロセスのSLA（Service Level Agreement）策定** 「面接結果の連絡が遅い」ことによる候補者離脱を防ぐため、採用チームと面接官の間でSLAを締結。 - **ルール:** 面接実施から3営業日以内のフィードバックを義務化。 - **運用:** 期限超過時のアラート体制を構築し、評価入力の負荷を下げるための評価シート簡素化も併せて実施。 **3. 評価基準のグローバル標準化** 多国籍な面接官による評価のバラつき（主観評価）を是正するため、構造化面接を導入。 - コンピテンシーごとの質問集と評価ルーブリック（採点基準）を作成し、英語・日本語でのトレーニングを実施。 ## 【成果】 - **内定承諾率 78%維持:** スピーディーな選考体験により、競合他社への流出を阻止。 - **リードタイム短縮:** 平均60日以上かかっていた選考期間を30〜45日程度へ短縮。 - **採用充足:** 見直した要件定義に基づき、難航していた組み込みエンジニア等の採用に成功。

# 【1人目人事】0→100名フェーズにおけるエンジニア採用基盤構築とDevRel活動 ## 【背景・課題】 創業初期の組織拡大フェーズ（数名→100名規模へ）において、知名度不足と採用リソースの欠如が課題。 また、SES事業特有の「帰属意識の希薄化」や「キャリアパスへの不安」による内定辞退・早期離職のリスクがありました。 ## 【施策内容：0→1 Setup & DevRel】 **1. "Geek"層に刺さる採用ブランディング** 知名度で勝てない大手に対抗するため、ターゲットを「技術好きなエンジニア（Geek層）」に設定。 - KubernetesやDockerを用いたハンズオン勉強会を企画・運営し、connpass等で集客。 - 「採用説明会」ではなく「技術共有会」として接点を持つことで、転職潜在層へのアプローチに成功。 **2. SESの構造的課題を解決するキャリアパス設計** 候補者が抱く「客先常駐＝スキルが身につかない」という不安を払拭するため、営業・エンジニアリーダーと連携してキャリアパスを可視化。 - 「どの案件で、どの技術を、どれくらいの期間経験すれば、次のステップ（単価アップ/自社開発等）に行けるか」というロードマップを面接段階で提示。 **3. 労務・採用インフラの0→1構築** 1人目人事として、採用フローの確立だけでなく、入社手続き・勤怠管理・就業規則の運用フローまでをゼロから構築。 - スプレッドシートやチャットツールを活用した、コストをかけないミニマムな管理体制を整備。 ## 【成果】 - **採用数:** 年間数十名ペースでのエンジニア採用を実現し、組織を100名規模へ拡大。 - **採用コスト:** 技術イベント経由の採用（リファラル・ダイレクト）を確立し、エージェント依存度を低減（イベント集客100名超、採用決定4名）。 - **内定承諾率向上:** キャリアパスの可視化により、他社SESとの差別化に成功。

# 【RPO】複数クライアントの採用オペレーション標準化と、多様な技術領域のハンティング ## 【背景・課題】 RPO（採用代行）コンサルタントとして、スタートアップから大手SIerまで常時5社前後の採用を並行担当。 クライアントごとに異なるフロー、ATS、コミュニケーションツールが混在し、オペレーションミスや対応遅延のリスクが高い状態でした。 ## 【施策内容：Standardization】 **1. 採用オペレーションの「型化」と標準化** 各社の採用プロセスを分解し、共通項を括り出して「標準オペレーションフロー」を策定。 - 候補者対応のSLA設定、スカウト文面の型化、レポーティングフォーマットの統一を行い、マルチタスク環境でも品質を落とさない体制を構築。 **2. 多様な技術領域へのキャッチアップとスカウト** Web系（Go/Rails）、SIer（Java）、研究開発（Python/R&D）など、全く異なる技術スタックの採用を同時並行で遂行。 - エンジニアごとの「技術的なこだわり」や「キャリアの志向性（技術重視か、マネジメント志向か）」をGithubやQiitaから読み解き、パーソナライズされたスカウトを送付。 ## 【成果】 - **大量採用の完遂:** 大手SIerのプロジェクトにて、年間数十名規模のエンジニア採用目標を達成。 - **高難易度採用:** 素材メーカーのR&D職など、市場に候補者が少ないニッチ領域での母集団形成に成功。 - **顧客満足度:** 「言われたことだけやる代行」ではなく、「プロセス改善を提案するパートナー」として信頼を獲得し、契約継続に貢献。