Asanaはどのように「work about work」を共有グラフへ変えたか

Dustin MoskovitzとJustin Rosensteinが、Facebookで感じた「work about work」への苛立ちから始めたAsanaは、タスク管理を超えて、人間とAI agentが同じ仕事の文脈で動くWork Graphへ進んだ。出典

創業：調整のための仕事を減らす

Dustin Moskovitzは「We started Asana because we felt frustrated by how hard it was to get clarity on our teams through endless update meetings, email and chat threads, and project-status spreadsheets」と振り返っている。出典

Facebookで働いていた二人は、夜と週末に社内のwork management systemを作り、それがチームの生産性を押し上げる可能性を見た。出典

転機：社内ツールを製品にする

Asanaは、個別のToDoを並べる場所ではなく、誰が何をいつまでに、なぜ進めるのかを共有する仕組みとして外へ出た。

2018年にはGeneration Investment Managementが主導するSeries Dで7,500万ドルを調達し、企業・非営利組織への展開を広げた。出典

成長：計画を組織の記憶へ

初期の価値は透明性と説明責任だった。

現在のAsanaは、task、project、goal、dependencyをつなぐAsana Work Graphを中核に、複数の人間とagentが同じ計画で動く設計を打ち出している。出典

企業向けには大規模導入、governance、既存ツールとの連携を用意し、開発者にはAPIとApp Directoryを開いている。出典 出典

現在：人間とagentの協働へ

Asanaが作ろうとしているのは、AIが個人の文章を補助するだけの機能ではない。

共有された仕事の構造にagentのidentityと権限を組み込み、人間が確認しながらworkflowを進める作業環境だ。出典

これは、創業時に解こうとした「状況確認のための会議やメッセージ」を、組織全体の実行基盤へ広げる延長線上にある。

Asanaは、会議・メール・chat・status spreadsheetに分散した調整作業を、shared planとWork Graphへまとめたいチームに刺さる。

創業者がFacebookで同じ痛みを経験し、社内toolとして使い始めた原体験がproductの一貫性になっている。出典

単なるToDo管理ではなく、goal・dependency・portfolioまで接続するため、部門横断の業務を標準化したいenterpriseに広がる。

AI agent時代には、個人の生産性ではなくチームのshared contextを扱う点が再評価されると考えられる。出典

Work Graphに蓄積されるtask・goal・dependencyの関係と、組織内workflowの習慣がswitching costになる。

API・App Directory・integrationsも周辺の業務データをつなぐ。

ただしデータ移行や標準化が容易な領域では、強固なnetwork effectとまでは言い切れない。出典

強さは中程度。

複数人が同じprojectで働くほどAsanaの価値は上がるが、利用者同士が直接新規利用者を増やすmarketplace型ではない。

App Directoryと共有workflowがteam単位の拡散を補助する。出典

複数部門のprojectを管理するmanager、Marketing・Product・Operations・ITのteam、業務workflowを統制したいenterpriseが主対象。

個人の単純なメモや一時的なToDoだけを求める人にはover-specifiedになりやすい。出典

原体験に根ざしたcoordination problemを、毎日使うshared planに変えたことが第一。

次に、同じWork Graphをtaskからgoal・portfolio・enterprise governanceへ広げたこと。

さらにAPIとintegrationsで既存stackと共存し、導入時の切替コストを下げたことが再現可能な要因だ。出典

work managementはmonday.com、ClickUp、Jira、Notionなどと競合し、機能追加だけでは差別化が薄くなる。

AI agentを組み込むほど、誤実行や権限管理の説明責任が増える。

enterprise governanceを強めることは必要だが、中小チームには複雑さとして跳ね返るリスクもある。出典

free tierで小さく始め、team内の共有利用、部門横断、enterprise governanceへ拡張するland-and-expand型。

APIと100以上のfree integrationsで既存stackに入り、営業は大規模展開に集中する。

無料の使いやすさとenterprise機能の複雑さを両立するトレードオフがある。出典

主要チャネル: content, integrations, enterprise-sales, free-tier

社内toolを外販する際は、機能の便利さよりも、組織が繰り返し払っているcoordination costを起点にするとproductの芯がぶれにくい。

Asanaはtaskを並べるだけでなく関係をWork Graphとして表現したため、goal・automation・agentへ拡張できた。出典

日本企業では、会議・稟議・部署間調整を一つのworkflowとして可視化する導入が考えられる。

全社導入を急がず、商品開発など一つの業務でdecision ownerと期限を明確にし、権限・日本語テンプレート・既存グループウェア連携を整えるのが現実的だ。