-
SNS/マップ導線を意識したLP制作（React）
■ プロジェクトの目的
SNS（Instagram）/Googleマップ等からの流入を想定し、予約・問い合わせに繋がる導線を整えた1ページLPを用意する。
■ 体制・人数
基本は1人で設計〜実装〜公開まで一貫して対応。
■ 自分のポジション・役割
要件整理／構成設計（FV・CTA）／Reactでの実装／フォーム導線の調整／公開作業。
■ 課題
素材（文章・画像）が未整備な状態でも、短期間で“公開できる形”にまとめる必要がある。
■ 取り組み
ヒアリングを元に叩き台を作成し、相談しながら優先度を調整。軽微修正を積み重ねて完成度を上げた。
■ 成果
短納期で公開し、インスタ/マップ→LP→問い合わせ/予約の導線を分かりやすく整備。
-
重複データ・入力ミスの検知をGASで自動化（品質担保）
■ プロジェクトの目的
スプレッドシートで運用している顧客/案件/問い合わせ等のデータについて、重複登録・入力ミス・表記揺れを自動検知して品質を担保し、後工程（集計・請求・連絡・分析）の手戻りを削減する。
■ 体制・人数
2〜4名（運用担当者、管理者、開発担当＝自分）
※現場の入力フローを確認しながら段階的にルールを整備。
■ 自分のポジション・役割
開発・改善担当として、対象データの定義、入力ルールの策定、検知ロジック実装、通知/修正フロー設計、運用定着（マニュアル化・改善）までを一貫して担当。
■ 目的を達成する上での課題
同一人物/同一案件が別名・別表記で複数登録される（表記揺れ、全角半角、スペース、記号）
メールアドレスや電話番号の形式ゆれ・桁不足など入力ミスが混入する
どこが問題か分からず、発見が遅れて後工程で手戻りが発生
運用担当が目視でチェックしており、工数が増大・属人化している
■ 課題に対して取り組んだこと
重複判定キー（例：メール/電話/顧客名＋住所/案件IDなど）を定義し、シート構造を整理
正規化処理をGASで実装（トリム、全角半角統一、ハイフン除去、カナ/英数字の揺れ補正など）
入力バリデーション（必須/形式/桁数/禁止文字/選択肢）を設計し、誤入力を抑制
重複・異常検知を自動実行（編集時トリガー/日次バッチ）し、該当行にフラグ付与
条件付き書式やチェック結果列で「どこがNGか」を可視化し、修正しやすい導線を作成
管理者へサマリー通知（件数・対象リンク）を自動送信し、修正対応の漏れを防止
ログを残して検知精度を改善（誤検知パターンの調整、例外ルール追加）
■ ビジネス上の成果
重複登録・入力ミスの早期発見により、集計/請求/連絡など後工程の手戻りを削減
目視チェック工数を削減し、運用負荷と属人性を低下
データ品質が安定し、KPI集計や分析の信頼性向上に寄与
ルール化・自動化により、チーム増員・運用拡大にも耐える基盤を整備Google Apps Script（GAS）, Googleスプレッドシート, データクレンジング, 入力バリデーション設計, 重複検知ロジック, 正規化（文字種・表記揺れ）, 条件付き書式, Apps Scriptトリガー（onEdit/時間主導）, Gmail通知, ログ設計, 業務フロー改善, 運用設計
-
問い合わせ受付〜担当割当〜通知をGASで整流化（初動を最短化）
■ プロジェクトの目的
社内外からの問い合わせを「フォーム→一覧化→担当割当→通知」まで一連で整流化し、担当者の見落とし・対応遅れ・重複対応を防ぎ、初動（一次返信/受付）を最短化する。
■ 体制・人数
2〜5名（依頼部門の担当者、管理者、開発担当＝自分）
※運用担当と合意しながら段階的に改善・追加要望を反映。
■ 自分のポジション・役割
開発・運用設計担当（GAS実装/改善の主担当）として、要件整理、データ設計、通知設計、権限/運用ルール策定、リリース後の保守改善までを一貫して実施。
■ 目的を達成する上での課題
問い合わせがメール/口頭/チャット等に分散し、対応漏れ・遅延が発生
担当者が不明確で、割当が属人化・たらい回しになりやすい
対応状況が可視化されず、管理者が進捗を追えない
同じ内容への重複対応や、引き継ぎ時の情報欠損が起こる
■ 課題に対して取り組んだこと
Googleフォームで受付窓口を統一し、必須項目・カテゴリ・優先度を定義
スプレッドシートに受付データを自動記録し、ステータス（未対応/対応中/完了）を設計
カテゴリや条件に応じた担当者自動割当ロジックをGASで実装（例：部門別/内容別/当番制）
担当者/管理者へメール通知（受付時・割当時・期限前リマインド）を自動化
対応履歴・コメント・添付リンクを残せる運用にして、引き継ぎや監査に耐える形へ改善
エラー時のログ記録・再送処理など、運用で詰まりにくい仕組みを整備
■ ビジネス上の成果
初動（受付連絡/一次返信）までの時間を短縮し、問い合わせ対応のリードタイムを改善
対応漏れ・見落とし・重複対応を抑制し、運用の安定化に寄与
ステータス管理により、管理者が進捗を可視化できる状態を実現
仕組み化により属人性を下げ、担当交代時も運用を継続しやすくしたGoogle Apps Script（GAS）, Googleフォーム, Googleスプレッドシート, Gmail（自動通知）, Googleドライブ, 業務フロー設計, 要件整理, 運用設計, 権限設計, データ整形, ログ設計, 保守・改善
-
在庫の見える化と棚卸作業の効率化を実現する管理システム開発
■ プロジェクトの目的
在庫状況をリアルタイムに「見える化」し、入出庫・棚卸・調整を一元管理することで、欠品／過剰在庫／在庫差異を減らし、現場運用の負荷を下げること。
■ 体制・人数
少人数（1〜2名）で推進。関係者（現場担当／管理者）から要件ヒアリングしながら短いサイクルで改善。
■ 自分のポジション・役割
要件整理〜画面設計〜実装〜リリース〜運用改善まで一貫して担当。
現場の運用フロー（入力ルール、権限、例外処理）も含めて整備。
■ 目的を達成する上での課題
・在庫が複数の管理方法に分散し、更新漏れ・二重入力が発生しやすい
・棚卸結果と理論在庫の差分が追えず、原因特定に時間がかかる
・入力が面倒だと運用が定着せず、データの信頼性が落ちる
■ 課題に対して取り組んだこと
・入出庫／調整の「理由付き記録」と履歴管理で、差分の追跡を可能にした
・棚卸を「差分確認→確定」まで迷わず進められる導線にして作業を簡略化
・検索・絞り込み・一括登録（CSV等）を用意し、入力負荷を下げて定着を促進
・権限や更新ルールを明確化し、現場で迷いが出ない運用に落とし込んだ
■ ビジネス上の成果
・在庫状況の可視化により、欠品や過剰在庫の判断が早くなり機会損失を抑制
・在庫差異の原因追跡が容易になり、棚卸後の修正・確認の手間を削減
・入力・運用が定着し、在庫データの信頼性が上がって日々の業務が安定化在庫管理（入出庫/棚卸/調整/履歴）,在庫の見える化（一覧/検索/差分）,欠品対策（下限アラート/通知）,運用設計（ルール化/権限/定着）,データ連携（CSV入出力/自動化）,運用改善（継続チューニング）
-
テイクアウト領域で出店者向け販売プラットフォームの立ち上げ責任者（スピードリリース）
■ プロジェクトの目的
コロナ禍で増えたテイクアウト需要に対応し、**誰でも簡単に近くのキッチンカーを見つけられる**マッチングプラットフォームを構築。ターゲットは**キッチンカー事業者**と**利用者（キッチンカーを探すユーザー）**。
■ 体制・人数
企画：1名、開発（ソフトウェアエンジニア）：1名（自分） ※計2名
■ 自分のポジション・役割
立ち上げ責任者 / ソフトウェア最高責任者。要件整理、設計、実装（React + Firebase）、UI/UX改善、運用方針の決定まで主導。
■ 目的を達成する上での課題
最大の課題は**事業者側（キッチンカー）の獲得＝マッチング成立の起点作り**。広告では十分に届かず、初期の供給（登録店舗）を増やす必要があった。
■ 課題に対して取り組んだこと
広告依存から切り替え、**InstagramのDM等で直接アプローチ**し登録を促進。プロダクト面では**UI/UXを複数回作り直し**、最終的に**Googleマップのような地図UI**で「探しやすさ」を最優先に改善。技術面はFirebaseによりバックエンド負担を最小化し、短期間で安定稼働させた。
■ ビジネス上の成果
事業者登録が**徐々に増加し、口コミで加速**。登録事業者の増加に比例して利用者も増え、プラットフォームとしての成長サイクルを作れた。
スピード立ち上げ, 出店者向け管理画面, 商品登録・注文受付, 受取/キャンセル対応, 決済導入サポート, 通知（受付/完了）, 運用フロー整備, 数値改善と継続改善