paint-brush
ビデオゲーム会社から Slack が誕生したのは偶然ではなかった に@grant
941 測定値
941 測定値

ビデオゲーム会社から Slack が誕生したのは偶然ではなかった

Grant Magdanz
Grant Magdanz HackerNoon profile picture

Grant Magdanz

@grant

Subscribe to learn about how successful startups built pre product...

7 分 read2023/07/04
Read on Terminal Reader
Read this story in a terminal
Print this story

長すぎる; 読むには

2009 年、共同創設者のスチュワート バターフィールド、カル ヘンダーソン、エリック コステロ、セルゲイ モウラチョフは、これまで構築できなかったビデオ ゲームの構築に着手しました。
featured image - ビデオゲーム会社から Slack が誕生したのは偶然ではなかった
Grant Magdanz HackerNoon profile picture
Grant Magdanz

Grant Magdanz

@grant

Subscribe to learn about how successful startups built pre product market fit. Co-founder of Perch (joinperch.com)

0-item

STORY’S CREDIBILITY

Original Reporting

Original Reporting

This story contains new, firsthand information uncovered by the writer.


Slack については説明の必要がないので、すぐに説明します。これに協力してくれたCal Henderson 氏Keith Adams 氏、およびAli Rayl 氏に感謝します。


これは私の無料ニュースレター「Monolith」の号です。私は、成功した企業がプロダクト マーケット フィットを確立する前に、どのようにしてプロダクトを構築したのか (そしてルールを破ったのか) について書きます。


簡単な歴史:失敗したビデオゲーム会社からの Slack の誕生は、現時点ではバレーの言い伝えとなっています。すべての言い伝えと同様、一般的な話はセンセーショナルに伝えられます。


2009 年、共同創設者のスチュワート バターフィールド、カル ヘンダーソン、エリック コステロ、セルゲイ モウラチョフは、2002 年に開発に失敗したビデオ ゲームの構築に着手しました。2010 年のカンファレンスでのスチュワートとカル:

(転写):


以前にも失敗したことがあるので、成功する可能性は非常に高く、同じことで二度失敗する確率はかなり低く、そう、天文学的です。 2002 年に私たちは Ludicorp という会社を設立し、Game Neverending というゲームを作ろうとしていました。同じことです。2002 年であることを除けば、Web ベースの大規模マルチプレイヤー ゲームです。多くの点が異なっていました。その主な理由は、当時はドットコム暴落後、ワールドコム、エンロン、ご存知のとおり、9月11日以降、資金調達がはるかに困難な時期だったため、消費者向けのインターネットスタートアップのために資金を調達することが不可能だったことです。ゲームの制作途中で、テクノロジーを使って別のことをしようとしたときのことです。それとは別のものはFlickrでした。 Flickr は Yahoo に買収され、私たちはそれに数年を費やしました。 Flickr チームの 4 人が新しい会社 Tiny Speck を立ち上げ、Glitch を作っています。


グリッチ、画像はTechCrunchより

グリッチ、画像はTechCrunchより

彼らは撤退に成功し、資金調達環境も変わったため、資金調達は容易になりました:

(転写):


私たちは望むだけお金を集めることができました。それは簡単でした。デッキすら作らなかった。私たちが「お金が欲しい」と言うだけで、人々は私たちにお金をくれました。


チームは 2010 年に Accel から 500 万ドルを調達し、2011 年に Accel と a16z からさらに 1,000 万ドルを調達しました。Glitch は 2011 年 9 月に開始されました。2012 年末までに、ゲームが動作しないことが明らかでした。彼らはグリッチを閉鎖した。彼らには 500 万ドルが残っており、社内コミュニケーション ツールが残されていました。


最初から、 Tiny Speck のチームは分散されていました


Tiny Speck の経営陣は、北米各地のさまざまな都市に拠点を置いていました。バターフィールドとモウラチョフはバンクーバーに住み、ヘンダーソンはサンフランシスコにキャンプを構え、コステロはニューヨーク市から顧客開拓を管理していました。


コミュニケーションをより簡単にするために、彼らは IRC を中心とした内部システムを構築しました:

(転写):


私たちはゆっくりと、会社のあらゆるコミュニケーション方法の基礎となるシステムを開発しました。これは本当に有益であり、ああ、私たちの誰もこのようなものなしでは二度と仕事をすることはできない、8 人のソフトウェア開発者からなる他のチームもおそらく同様に気に入るだろうということに気づきました。 。それで私たちはそれをやろうと決めました。

Slack のパブリック プレビュー Web サイト

Slack のパブリック プレビュー Web サイト


次の 2 年間はロケットのような日々でした。


Slackは2019年に157億ドルの評価額で上場した

発達

Slack の初期の内部バージョンは、IRC の単なるラッパーでした。インターネット リレー チャット(IRC) は、80 年代後半のプロトコルです。 Tiny Speck チームは IRC を使用しましたが、いくつかの大きな欠陥がありました。このプロトコルは永続的なメッセージ、検索、ファイルのアップロードをサポートしていなかったので、チームは既製の IRC サーバーを中心に必要な機能を構築しました。スチュワートより:

(転写):


私たちは Slack の原型となるシステムを開発しました。繰り返しますが、1992 年に私が使用したネットワーク ツールの 1 つは IRC またはインターネット リレー チャットでした。 Tiny Speck では IRC を使用しましたが、これは非常に古いテクノロジーです。

ほとんどのメッセージング システムには、ストア アンド フォワードの概念があります。あなたにメッセージを送信したいが、クライアントに接続していない場合、メッセージは保留され、次回接続したときに転送されます。 IRCにはそれがありませんでした。私がメッセージを送信した瞬間にあなたが接続していなかった場合、あなたはそれを受信することはできないでしょう。そこで、メッセージを記録するシステムを構築しました。しかし、メッセージをデータベースに保存したら、それらを検索できるようにしたいと考えました。そこで私たちは検索を構築しました。そして、少しずつ、機能ごとに、ファイル サーバーと統合するものを構築しました。これにより、誰かがファイルをアップロードすると、そのファイルが IRC にアナウンスされたり、データセンターでアラートが発生した場合に IRC に入力されたりするようになりました。


チームは Glitch を開発する際、IRC を強化するために切実に必要な機能を定期的にリリースしていました。再びスチュワートから:

(転写):


明らかにチャンスがあり、それを活用しないわけにはいかないときは、それに最小限の時間を費やしてから、またそのチャンスに戻ります (グリッチの開発)。そのプロセスの最後に、私たちが使用していた完全に設計された製品が完成しました。これはひどい実装であり、ゼロから始めた場合に行うものではありませんでしたが、これが非常に価値のあるものであることは明らかでした。


2012 年後半にチームが方向転換したとき、Slack をゼロから構築する間、2 か月間社内の IRC バージョンを使用し続けました。製品が社内で使用できる状態になると、彼らは移行しました。


MVP は、最大 10 名を超えるチームの UX の問題を抱えていました。当初、彼らは他の会社の友人に、それを試してフィードバックを提供するよう「懇願し、説得しました」。彼らは6〜10社からスタートしました。 Rdio は従業員約 120 名で最大規模です。 Slack よりも規模の大きなチームでは、この製品の動作が大きく異なることがすぐにわかりました。


Cal より:

(転写):

他の人に使用されてからの最初の数日間は、非常に膨大で豊かなフィードバックの期間でした。私たちは仕組みをよく知っていたので考えもしなかったことがたくさんありましたが、本当に愚かなこともありました。会社に「マット」という名前の人が 2 人いる場合、両者を区別する方法はありません。また、チームに 20 人いる場合、8 人のチームだったのでスクロール リストはありませんでした。


Slack チームはそのフィードバックを製品に組み込み、さらに多くのチームを参加させ、引き続きそれを製品に組み込みました。この反復的な製品サイクルは、Flickr から学んだものです。


再び Cal から:

(転写):

私たちが Flickr から得た明白な教訓は、優れたソフトウェア製品を見ると、優れた製品は最初からそのように始まったわけではないということです。彼らはまったく異なる方法でスタートし、製品はまったく異なる方法で提示され、ユーザーはさまざまな方法で対話し、チームは今日の状況に到達するまでに、時には大規模な反復を繰り返しました。すべては、顧客が何をしているのか、顧客が抱えている問題、何を達成しようとしているのかを理解し、それをソフトウェアの設計に折り込み、優れた、人々に愛される製品を目指して反復するというフィードバック ループにかかっています。 。


Slack のアーキテクチャはオンライン ゲームのアーキテクチャに似ており、 Slack クライアントはすべてをキャッシュしました。起動時に、rtm start と呼ばれる単一の API リクエストを作成します。これにより、チャネル、メンバー、チャネル メンバーシップなど、ユーザーのワークスペースに関するすべてがダウンロードされます。次に、クライアントは WebSocket 接続を開いて、ローカル キャッシュとの更新を送受信します。

2016 年から 2020 年まで Slack のチーフ アーキテクトを務めた Keith Adams が、メディアがオンライン ゲームから Slack への転換点を語るのを好む様子について語っています:

(転写):


通常、人々はこれを面白いこととして言及するだけです。「ああ、彼らはゲーム会社だったんですね。クッキーが時々崩れるのはおかしくないですか?」。それは事実ですが、実際には特定の方法で戻ってきます。目を細めて首を傾げてみると、Slack の実際のアーキテクチャは、大規模なマルチプレイヤー オンライン ゲームのアーキテクチャに似ています。あなたには、自分が活動する「世界」、つまりチームがあるようなもので、その世界を永続的であり、世界の他の物事とインタラクティブに変更できるように見せるために、最終的にそこで何が起こっているかについてのかなり分厚いキャッシュを作成することになります。そうすれば、その世界の変更に対する低遅延の更新を取得する方法が得られます。 「ああ、オンライン ゲームのようなものだ」というその種の精神的パラダイムは、Slack について多くのことを説明します。たとえばロード画面があるのはそのためです。ビデオゲームにロード画面が表示される傾向があるのと同じ理由です。


image

私の見解

Slack は彼ら自身の問題を解決するために構築されました。 Nomad Listと同様に、製品の初期バージョンは作成者の真のニーズから生まれました。


シンプルなものでも、計り知れない価値を生み出すことができます。 Slack はオープン プロトコルの拡張にすぎませんでしたが、適切なユーザーに計り知れない価値を提供しました。これも、非常に価値のあるものを生み出すのに技術革新がまったく必要なかったケースです。


Slack がゲーム会社から生まれたのは単なる偶然ではありません。これは、単なる技術的なアーキテクチャを超えて関連します。 Slack は仕事とは思えません。それが人々に愛される理由の一つです。 MetaLab は Slack の初期 UI の多くをデザインしました。 MetaLab 創設者アンドリュー・ウィルキンソンより:


混雑した市場で注目を集めるには、人々の注意を引く方法を見つける必要がありました。ほとんどのエンタープライズ ソフトウェアは、70 年代の安っぽいプロム スーツのように見えます。どこもかしこも落ち着いたブルーとグレーです。そこで、ロゴから始めて、Slack を紙吹雪の大砲が鳴り響いたように見せました。エレクトリックブルー、イエロー、パープル、グリーンが全面に。企業コラボ商品ではなく、ビデオゲームのような配色にしました。

リンク/リソース


ここでも公開されています。


L O A D I N G
. . . comments & more!

About Author

Grant Magdanz HackerNoon profile picture
Grant Magdanz@grant
Subscribe to learn about how successful startups built pre product market fit. Co-founder of Perch (joinperch.com)

ラベル

この記事は...

Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite
Also published here