最終更新: 2026/06/22 18:56
commonid: rq-067type: researchstatus: active
pageauthor: [email protected]audience: both

課題ディープダイブ・シート（問題空間スキャン）

作成日: 2026-05-14
用途: Customer Insight エージェントのペルソナ定義 + D1 スキャンの基底知識
対象: 代表取締役（唯一の顧客＝唯一のユーザー）

0. 前提情報（スコープ）

  • ターゲット顧客: 一人法人の代表者（社長・経理・エンジニア・営業を兼任）
  • 対象プロセス（JTBD）: 月次決算（証憑取込 → 仕訳 → 消込 → 財務諸表生成）
  • 特定された最大のボトルネック: 証憑（領収書・請求書PDF・銀行CSV）の取込・突合・消込作業の手作業残存と、処理の途中停止リスク

① 顧客の行動（ドキュメンタリー記述：As-Is）

「いつ・どこで・何のツールを使い・どう動いているか」映像として記述。

  • 発生タイミング: 月末〜翌月第3営業日ごろ（月次締めのたびに集中発生）
  • 作業環境: Mac + VS Code（clasp 経由でGASにデプロイ）+ Google Sheets（dev/prod 2環境）+ Claude Code / Gemini をターミナルから並走
  • 具体的な行動ステップ:
    1. 月中に溜まった領収書PDFをGoogleドライブのフォルダに集約し、GASのOCR機能（Gemini API）を実行
    2. OCRの読み取り結果を目視確認。かすれ・傾き・手書き文字はOCR失敗扱いとなり、手動で仕訳を入力しなおす
    3. クレカ明細CSVを所定のシートにインポートし、INVと突合・消込を実行（Pass 1: 完全一致 → Pass 2: 合算マッチ → Pass 2.5: ソフト合算）
    4. 銀行口座CSVをインポートし、STL自動作成 → Action A（仕訳エンジン）→ Action B（自動仕訳生成）を順に実行
    5. 財務諸表マート（P/L・B/S・CF）を再構築し、数値を目視確認
    6. 異常値（現預金の乖離・計画B/Sと実績の差異）が出ると、INVを遡って原因を特定し修正 → 再生成

② 代替手段（ワークアラウンド）と限界

現場が独自に行っている「涙ぐましい努力」とその代償（ペイン）。

  • 現在の独自の工夫（代替手段）: GASシステム自体が「自前のワークアラウンド」。かつてのExcel手作業をGAS+Sheetsに置き換え、RPA・仕訳エンジンを自作。Claude Code / Gemini で開発を加速している
  • 払っているコスト・限界:
    • 時間: OCR精度の限界（読み取り失敗分の手入力）・消込の手動確認・異常値調査に毎月数時間を消費。バグが出ると原因特定だけで半日かかることもある（MAS-302: フィルター適用中のsilent-fail等）
    • 技術的: システム改修にかかるエンジニアリング工数が、経理作業そのものと競合している。「直す時間があれば手作業で終わった」という逆説が月末に毎回発生する
    • 心理的: 「自分がバグを埋め込んで自分で気づけない」という監査リスクへの緊張感。特に本番データへの不可逆操作（STL削除・列削除等）は毎回慎重な確認が必要

③ 根本原因（Root Cause）と見えない制約

なぜその非効率が放置されているのか？「なぜ？」を深掘りした構造的・心理的原因。

  • 表層的な課題: 手作業が多く時間がかかる、途中でエラーが出ると全体が止まる
  • 構造的・システム的要因:
    • 一人法人のため全工程を一人でこなす必要がある。委任する経理担当スタッフが存在しない
    • GASのAPIクォータ・実行時間制限（6分・90分/日）という技術的天井があり、大量処理をチャンク化しないと止まる
    • Google Sheetsのフィルター適用中のsetValueがsilent-failするなど、プラットフォーム固有の罠が多く、デバッグに時間を取られる
  • 見えない制約（構造的・心理的壁）:
    • エンジニアとしての自分と、経理担当としての自分が同一人物であるため、「システムへの信頼」と「自分の判断への信頼」が分離できない。バグを発見したとき、それがシステムのバグか自分の経理ミスか、最初は判断できない
    • 監査要件（法人会計）があるため、「だいたい合っていればOK」という割り切りができない。1円の乖離も根本原因を特定する義務感がある
    • 開発を進めるほど「後で直そう」と思ったままの技術的負債（未修正バグ4件・追跡不能RQ 38件）が積み上がっており、月次のたびに踏む地雷が増えていく

④ 補足：過去行動の定量記録（Mom Test エビデンス）

BUG_tracking・changelog から抽出した「実際に起きた痛み」の記録。

発生日痛み影響
2026-05-01銀行消込でフィルター適用中にsilent-fail（MAS-302）。決済日_実績が書き込まれずAction Bが起動しない二次被害月次締めが止まり、手動で状態を確認・修正する対応が必要
2026-04-30Action A で acc is not defined エラー（MAS-298）。財務諸表マート再構築が完了しない原因特定に時間を要し、月次締め全体が遅延
2026-04-13prod→devデータ同期時にフィルターが有効なままコピペしてデータ欠落（MAS-288）気づかずに進めると財務諸表の数値が狂う
継続中73_bs_plan（計画B/S）が実績71_bsと乖離（cash plug過小・MAS-300）経営判断の数値が信頼できない状態が続く
継続中スマホから月次財務諸表が判読不能（MAS-362）外出先でのクイック確認ができない

⑤ Customer Insight エージェントへの指示

このシートを読んだエージェントが D1 スキャンで参照すべき観点。

あなたは「代表取締役の業務ログを熟知した観察者」です。
以下のファイルを読み、「先月どこで何回詰まったか」を Mom Test 形式で整理してください。

読むべきファイル:
- docs/_internal/BUG_tracking.md（未修正バグ・発生頻度）
- docs/_internal/changelog.md（直近30日の障害対応・修正内容）
- docs/_internal/TODO_future.md（未着手案件のうち月次運用で痛みが言及されているもの）

出力形式（D1 候補リスト）:
- 痛み名（動詞+目的語で1行）
- いつ・何回発生したか（定量）
- 現在のワークアラウンドとそのコスト
- D2 起案候補か否か（☆ or —）と理由