FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
役割とStory単位のdeliveryを一つの運用へ揃える
Narrative、creative content、法務、進行可視化の責任境界を再構成する
目的
Narrative DesignとWritingが別の役割に分かれていたことで、意味を設計する作業と言葉へ仕上げる作業の境界が曖昧になり、制約の受け渡しと確認が重複していた。一方、動画、音楽、画像、3Dモデルなどのcreative contentには、制作と配布をまとめて扱うdomain leadがいなかった。
進行面でも、Taskごとにdelivery単位が分かれることで競合が起きやすく、伝言時の解釈差、承認待ちの見えにくさ、法務だけでは覆いきれないcomplianceとreputation riskの判断が残っていた。役割、指示伝達、作業単位、確認gateを一つの組織運用として整えることが目的だった。
実装
Shioriの責任をNarrative DesignからWritingまでへ広げ、message architecture、記事、台詞、script、見出し、CTAを同じversionで扱うようにした。旧Writing専任のagentとSkillは削除し、意味の設計と表現の推敲の間にあったhandoffをなくした。
Sosukeはcreative contentのContent Directorへ再定義した。動画、音楽、画像、3Dモデルなどをプロダクトとは別の表現領域として扱い、要求、Epic、User Story、Task、制作計画、配布計画を所有するtop-level domain leadとした。これにより、corporateとproductに加えてcreative contentにも入口と統合責任を置いた。
- 一つのUser Storyを一つのdelivery単位へまとめ、後続作業は同じ成果物へ合流させる契約にした。
- delivery責任者を一人に定め、StoryとTask、完了条件、依存関係、適用後の扱いをmanifestで照合するようにした。
- 準備・適用・完了更新の各直前に必要なgateを全件確認し、未確認、古い状態、不一致が一つでもあれば停止するfail-closed判定を追加した。
MakoはCEOと各roleの原文を変えずにrelayし、進め方や要件の再設計はdomain leadへ残す責務へ限定した。その一方で、agent lifecycle、進捗、承認待ち、重要gateの可視化は中央で維持した。起動時にはtechnical threadとagentの識別、元のTask、状態、取得できるhost・location、確認方法をreceiptとして示すようにした。
- technical threadを取得できる場合だけ、確認済みの識別子から
codex://threads/<thread_id>を構成する。 - 識別子を取得できない場合はlinkを作らず
unavailableとし、host・locationと別の確認方法を示す。 - Ayaの長時間作業は経過時間だけで停止せず、完全に応答がない場合もCEOの確認前には停止しない。
Yasuの責任をLegal & Complianceへ広げ、法制度に加えてcomplianceとreputation riskを扱うようにした。顧客向けのWebサイト、アプリ、contentでは、成果物確認にもlegal riskとreputation riskを加えた。これらをagent定義、運用文書、Skill、checklist、hook、rule、現在の組織図と公開境界へ横断して同期した。
- PRを伴うdeliveryでは、原則として対象repositoryごとに1 User Story / 1 branch / 1 PRとし、同一Storyの全Taskをdomain leadが作った同一branchへ順序付きで統合する図を描画しています…
確認したこと
確認結果
旧Writing専任agentとSkillはなくなり、ShioriがNarrative DesignからWritingまでを同じversionで担当する構成になっていた。
Content Directorがcreative contentのtop-level domain leadとして追加され、3つのdomain入口と6つのspecialistから成る9 roleのinventoryに揃っていた。
Story単位のdelivery、単一owner、manifest、fail-closed gate、原文relay、task可視化、Ayaの停止境界がagent定義・運用文書・Skill・ruleで一致していた。
technical threadを取得できない場合のunavailableが誤ってfailureになり得る不一致を検査で発見し、取得可否に応じたlink・fallback・blocker条件へ統一した。
TOML、JSON、hook syntax、Skill frontmatter、rule、cross-reference、差分形式の検査は成功し、cutoff時点で新しい組織運用は対象へ反映されていた。実際のremote環境でのtask link表示と承認待ち表示は、このActivityでは起動確認していない。
完了とした根拠
役割定義、Story単位のdelivery契約、原文relayと進捗可視化、法務・compliance・reputationのgateが関連する設定・文書・Skill・ruleへ一貫して反映され、構文・inventory・判定条件・横断参照の検査に成功したことをもって完了とした。