やったことの、記録。
扱う領域の一覧はトップページにあります。ここに置くのは、実際に何が問題で、何をして、何が変わったかの記録です。事業の性質上、固有名は伏せています。抽象化した結果あたりさわりのない話になるくらいなら、書かないほうがましだと考えているので、判断の分岐点だけは具体的に残しました。
IPと、その内側
Entertainment Enterprise問題。アーティストの世界観を保護しながら、事業としては拡大する必要がありました。この二つは放っておくと衝突します。加えて、良い表現がなぜ生まれるのかは特定の人間の感覚の中にしかなく、組織の知識として残っていませんでした。
判断の分岐点。ここで最も重要だったのは、何をデータで扱わないかを先に決めたことです。楽曲そのものの是非は、最後までアーティストの裁量に置きました。数値で語れる領域を広げれば分析は強くなりますが、創作の判断まで数値が侵食した時点で、守るべき対象そのものが壊れます。
そのうえで、ライブの動員やファンの反応といったマクロな局面だけを可視化し、表現が生まれる背景にある文脈をナレッジとして蓄積しました。
結果として、創作領域に立ち入らないまま、チームとして意思決定できる体制になりました。踏み込まなかったことが成果である、という種類の仕事です。
引き算のメディア
Digital Asset Incubation問題。PV至上主義と広告トラッキングが前提の現代のWeb環境では、読めば読むほどブランド体験が削られていきます。一般的な解は「バランスを取る」ですが、その配分を決める指標がそもそも短期の数値しかない、という構造的な問題がありました。
判断の分岐点。自社メディアであることを利用して、収益化の時期を意思決定から外しました。いつ黒字化するかを判断材料にしないと決めた瞬間に、ノイズを排除するかどうかで迷う理由がなくなります。制約を増やすことで、判断が速くなった例です。
読者の没入を阻害する要素を排し、数値化しきれない世界観を保護するアーキテクチャを採りました。
「儲けを急がない」ことそれ自体を、掲げている哲学の実践例として位置づけています。自社で実演できない哲学を、他社に勧めることはできません。
成果物
Deliverables現場で再利用されることを前提に作るため、成果物の形式はおおむね次の三つに収束します。
- 01
- Executive Map
- 経営課題、主要指標、施策仮説、リスクを一枚で確認できる意思決定マップ。
- 02
- Data Blueprint
- ログ、テーブル、DWH、BI、権限、運用を結ぶデータアーキテクチャの設計図。
- 03
- Operating Ritual
- 週次・月次で何を見て、誰が判断し、どう施策に戻すかの運用サイクルの型。