Asana：ワクワクWork Graph

ナチュボン起業家の第二章はServiceTomorrowとなり得るか？

らんぶる 2022.04.11

読者限定

先週のMonday.comの記事が思ったより反響があったので、今回は同じ業界の隣人であるAsanaについて調べることにした。まずはAsanaの成り立ちとその製品戦略について少し解析した後、Mondayと比較するかたちで上場後の業績と今後の展望を分析していこうと思う。

2010年、すでに高い評価額を得て上場も時間の問題となったFacebook。経済的自由を手に入れた元社員の中には、自分の手で事業を始める者も少なくなかった。その中でも当時話題になった会社が二社ある。ひとつはQ&AサービスのQuora。もう一社が今回取りあげるAsanaだ。

Facebookの共同創業者Dustin Moskovitz氏と、StanfordからGoogleを経て鳴り物入りでFacebookに入社したJustin Rosenstein氏が立ち上げたスタートアップという創業ストーリーのインパクトは中々のもので、プロダクトが出る前からDustinとJustinで何を作るんだろうと方々で噂されていた。失礼な話だが、満を持して2011年11月にローンチされたプロダクトがプロジェクト管理ツールだった時には、拍子抜けした人も少なくなかっただろう。

少なくともシリコンバレーのエンジニアの間で当時注目を浴びたのは、プロダクトそのものよりも、その記述を助けるためにAsanaのエンジニアたちが開発したドメイン特化型言語（DSL）LunaScriptの方だった。既にLunaScriptを説明したページは無くなっており、LunaScriptそのものも頓挫しているが、React.jsもなかった当時、リアルタイムに複雑なデータの依存関係を処理できるDSLを書くなんて流石Dustin & Justinと盛り上がった。

今のAsanaはReact.jsで書かれているが、LunaScript発表当時からあった「依存関係を定義することで処理の記述を大幅に減らす」という哲学そのものは、ローンチから10年少し経った今でも脈々と引き継がれている。上場後最初のearnings callからMoskovitz氏を引用する（強調は筆者）。

Asana solves the problem of team coordination and gives teams clarity. The Asana Work Graph is the data model that makes this team coordination possible. It enables a complete, fully-connected, accurate and up-to-date map of work in your organization. The Asana Work Graph represents all of the units of work like tasks, ideas, goals, agenda items; information about that work like relevant conversations, files and status information; how it all fits together; and importantly, who's responsible for each piece. It’s a living system of clarity for work that emerges in real time and expresses a team's past, present status and future plan.

https://s25.q4cdn.com/783494463/files/doc_financials/2020/q3/Asana-Transcript-Third-Quarter-Earnings-conf-call-FINAL.pdf

上場したSaaS企業は何百社とあれど、一発目のearnings callでデータモデルの話をするCEOはDustin Moskovitzくらいだろう。このWork Graphだが、製品名ではない。概念である。なんで概念の話をするかというと、Asanaが考える自社の差別化の大きな部分が、競合よりもより先進的な視座で製品開発をしている点だからだ。

ではこのWork Graphは何なのって話だが、要は「タスクを人と見立てた時のソーシャルグラフ」だ。SNSなどにあるソーシャルグラフ上では人と人が繋がっており、その繋がりが時間軸に対して変化していく。Work Graphに於いては、人の代わりに「タスクやゴールといった仕事の概念単位」同士が繋がっており、人はそこに付随するメタデータのひとつとして存在している（少し専門的な話をすると、ここでいうグラフというのは棒グラフとかグラフではなく、数学のグラフ理論のグラフ、つまりモノとモノとのつながりについて研究する分野に由来している）。

プログラミングの世界に於いて、モノ同士の依存関係を定義し、一つのモノに変化があった時、それに依存するモノに自動的に変更を加えるというのは、よくある作業である。と同時に、これを簡潔かつ効率的にやるのは中々難しい。実はここにLunaScriptの当初の哲学が如実に反映されており、2013年にReactがリリースされた時に一気に話題になった理由でもある。

なんか難しそうな話をしていてご苦労様という感じだが、このWork Graphの概念を明確に打ち出し、Asanaが注力するのはCoordination、つまり依存関係処理だとポジションを取ることで、証券アナリストの意地悪い質問にもエレガントに回答できる。例えばMicrosoftを競合としてどう見てるかと聞かれた際、Moskovitz氏はこう答えている（強調は筆者）。

When we think about the overall collaboration landscape, we tend to talk about it in terms of the three C’s, so content, communications and coordination. We’re really a coordination layer, so answering the key question, who’s doing what by when. For the overall collaboration market, I think Microsoft would agree with us, that the addressable market, in the long run, is much larger, even in their 250 million. We think of it as 1.25 billion knowledge workers globally.　Content and communications, those categories have been around a lot longer, so they’re further adopted. Really, I think about Office 365 as mostly in the content category, and then Teams is a little bit more in the communication. There’s still an enormous greenfield opportunity to reach the rest of the TAM in all three categories, but coordination is the most nascent.

https://s25.q4cdn.com/783494463/files/doc_financials/2020/q4/Asana-inc-q4-and-fiscal-year-2021-earnings-call-Transcript.pdf

Moskovitz氏の主張はこうだ。

仕事というのは三つのCでできている：まずはContent（成果物）、次にそれにまつわるCommunications（やりとり）、そして最後にそれら全てのCoordination（調和・調整）
Microsoftが注力してきたのは最初の二つ：Office=ContentでTeams=Communications
Asanaがやろうとしているのは三番目だから直接的な競合ではない

この主張は、それだけでは苦し紛れの詭弁に聞こえかねない。しかしMoskovitz氏は一貫してAsanaの差別化はWork Graphだと言い続けているので、なるほどとこの辛辣な僕でも納得してしまった。もちろんCoordinationの世界にも競合は多数存在するし、これからMicrosoftも機能をどんどん出して（そして足して）くるだろう。しかし最初からそこに注力しているAsanaに一日の長があるというのは、定性的ではあるが明確なポジション取りと言える。

この記事は無料で続きを読めます

続きは、3794文字あります。