Work In Progress

このプロジェクトで現在進行中の作業と、過去のスナップショットを記録する。

現在の状況

フェーズ: 設計を実装へ落とし込み中。

• リポジトリ初期化済み。三本柱の第3の柱として確定。
• リリース前ゲート v0.1 を 02-リリース前ゲート/ に配置済み。🔴HARD / 🟡WARN の二段、リリース種別で伸縮、という線引きは承認済み。
• 次の候補:
  1. ゲートの各項目の合格基準を「具体文」まで落とす（例: subnote の実装で何を計測してたら C.行動分析 が PASS か）
  2. ダッシュボード仕様の設計 — subnote の実データを App Store Connect / GA4 から試し引きして、出せる数字／出せない数字を確定
• 保留: 既存8アプリへのゲート遡及適用（「健康診断」）は後回し。
• 弱点メモ: Android（Google Play Console）はMCPがなく、インストール/売上は手動エクスポートが必要。

---

過去のWIPアーカイブ

（新しい「現在の状況」を書く前に、古いものをここに追記でアーカイブする。新しいものが上）

ロードマップ

今週

• リリース前ゲート v0.1 の各項目の合格基準を具体文まで落とす
• （任意）ダッシュボード仕様の素案 — subnote の実データを試し引き

今月

• 全社ダッシュボードを subnote でパイロット構築（売上/インストール/離脱率/MAU）
• Android（Google Play Console）の数字取得経路を確定（手動 or 別パイプライン）
• {app}-operation → product-operation の報告フォーマット定義

今四半期

• ダッシュボードを全アプリ（8本）に展開
• リリース前ゲートを既存アプリに「健康診断」として遡及適用
• 改善提案の定例（ASO月次会議に倣う）を回し始める

いつか

• リリース前ゲートを半自動化（チェック項目の機械判定）
• ダッシュボードの自動更新（cron + MCP）

意思決定記録

このプロジェクトで下した重要な意思決定を記録する。 最新が上に来る。

---

2026-06-30 運用担当の役割を「能動」と確定（成長機構の要求＋ストア要件のブリーフ）

背景: product-operation の役割が「リリース前に合否を付けるだけの受け身のチェック係」と読めてしまう懸念があった。実際に求めたいのは、プロダクトを成長させる責任を負う能動的な運用担当。

決定: リリース前ゲートで2つを能動的にやると定義。

• ① 成長エンジン監査（内向き・このリポで完結）: アクティブユーザーを取る／維持する機構（通知・オンボ・習慣化・シェア・招待・GA4計測など）が実装されているかをチェックし、無ければ「入れて」と要求して差し戻す。要求と合否判定はこのリポが持つ。
• ② ストア表現（外向き）: タイトル・概要・スクショ等の「何が必要か」を仕様化してブリーフ（作成指示書）を出すところまでがこのリポ。実制作（コピー・スクショ）は pr-manager に委譲。

理由: ストア素材の実制作は pr-manager（広報運用＝ASO方法論ハブ。ASO羅針盤・『戦わずして売る技術』を持つ）の領分。二重持ちを避け、product-operation は「要件・方向づけ・合否」に責任を絞る分担にした。代替案「product-operation 主導で制作まで」「完全に単独で完結」は、pr-manager の ASO 資産と役割が重複するため不採用。

2026-06-30 product-operation を第3の運用ハブとして新設

• 決定: ラマヌの運用を三本柱にする。会社運用（company-operation）/ 広報運用（pr-manager）に並べて、プロダクト運用ハブ product-operation を新設。
• 背景: サービス運用の実務が各 {app}-operation リポで個別に走っているが、横串で束ねる担当・統一ダッシュボード・リリース前の合否ゲートが存在しなかった。
• 立ち位置: 個別運用を奪わず束ねるハブ。pr-manager が広報の方法論ハブであるのと同じ構造。

2026-06-30 名前は product-operation に決定

• 候補: product-operation / service-operation / growth-operation / ops-manager / product-ops。
• 決定: product-operation。company-operation の完全な対で、「会社/広報/プロダクト」の三本柱が名前で並ぶ。{app}-operation（個別）と product-operation（横串）の対比が立ち位置を言い表す。

2026-06-30 リリース前ゲートは🔴HARD/🟡WARNの二段＋種別で伸縮

• 個人開発の出荷速度を殺さないため、全項目ブロッカーにはしない。
• 🔴HARD（未達なら出さない）は法務・クラッシュ計測・行動分析ゼロ・審査リジェクト級に限定。残りは🟡WARN（記録の上 You が判断）。
• リリース種別で伸縮: 新規・メジャー=フルゲート、マイナー=差分のみ。

2026-06-30 ダッシュボードのパイロットは subnote

• web / iOS / Android の3プラットフォーム本番。Android手動分とWeb課金の検証も兼ねられるため、最初の的に選定。

開発日誌

このプロジェクトでの作業を時系列で記録する。 最新のエントリが上に来る。

---

2026-06-30 リポジトリ初期化・設計の持ち込み

• pr-manager 側のセッションで product-operation の構想を設計し、本リポジトリとして実体化。
• 三本柱（company-operation / pr-manager / product-operation）の第3の柱として位置づけ。
• ライフサイクル構成（01-企画 / 02-リリース前ゲート / 03-リリース / 04-ダッシュボード）を company-operation に倣って作成。
• リリース前ゲート v0.1 を 02-リリース前ゲート/リリース前ゲート_v0.1.md に配置（🔴/🟡の線引きは承認済み）。
• ダッシュボードのパイロット対象は subnote に決定（未着手）。

product-operation（プロダクト運用ハブ）

概要

合同会社ラマヌのアプリ・サービスの「プロダクト運用」を横串で束ねる運用ハブ。 company-operation（会社運用）/ pr-manager（広報運用）に並ぶ第3の柱。

個別アプリの運用は各 {app}-operation リポジトリ（実行レイヤー）で走っており、本リポジトリはそれを奪わず、横串で束ねて全社的に管理する。

役割

1. リリース前ゲート（合否チェックリスト）— 02-リリース前ゲート/
2. 全社ダッシュボード（売上 / インストール数 / 離脱率 / MAU）— 04-ダッシュボード/
3. 改善提案（定例レビュー）

ディレクトリ

• 01-企画/ — 企画・会社方針との整合
• 02-リリース前ゲート/ — リリース可否チェックリスト
• 03-リリース/ — 公開・初動監視
• 04-ダッシュボード/ — 数字の集計・分析・改善提案