Struct は運営を続けるつもり。バックエンド、デザイナー、フロントエンドの3人で作っている小さなチームなので、資本集約的な製品でもない
期待しているロードマップには、音声／ビデオ通話とウェビナー、コミュニティ向けのスパム制御、AI ボットと回想機能の改善およびコスト削減、Struct で共有された文書のインデックス化とアクセス制御を維持した AI 回答などがある。Struct が面白いのは、チームチャットとコミュニティチャット、作業管理システム、ChatGPT、個人の TODO リスト、公開インデックス可能な知識ベースをまとめて置き換えるから。システムが忘れないと信頼できるときに可能になることは驚くほど多い
とても同意します。業界は「魔法のボタン」パラダイムにとらわれていて、AIはそのボタンを押して初めてすごいことをします
AIが会議の録音文字起こしから自動要約を作れるなら、次のステップやアクション項目まで後続処理できない理由はありません。次のステップが Janine が Carlos と会議を設定することなら、AIが Carlos に連絡して日程調整を手伝えばよいのでは、と思います。今は考え方が小さすぎます
会議を減らすべきだというのは妥当です。チャットプラットフォームや Loom のようなツールも、結局は必要な会議数を減らすためのものだと見ています
ただしメトカーフの法則も避けられません。現代の仕事のほとんどはチームで行われ、チームサイズが N なら O(N^2) のコミュニケーションコストを支払う必要があります。全体のコミュニケーションが減るとは思えず、より効果的に処理するための適切なツールが必要です
1件のコメント
Hacker News の意見
「自分が注目すべきもの」を選んでくれるというツールは多かったが、自分やチームにぴったり合ったことはなかった。Struct は何が違うのか気になる
Struct のランディングページの動画を見ながら書き留めた質問：チャンネルはスレッド／フィードの出発点のように見えるが、単にユーザーをまとめる概念なのか、チャンネル内でチャットもできるのか気になる。リアルタイムフィードに表示されるスレッドだけをユーザーが見る構造なら、活動は多いがシグナルの低いスレッドがスペースを占め、重要だが活動の少ないスレッドを押し出してしまう問題にどう対処するのかも知りたい。タグはフィルタリングに重要だが、JIRA のタグのように似ているが微妙に違うテキストのまとまりで散らかりやすい。これを管理する方法があるのかも気になる。別々のユーザーが同じテーマで独立して作ったスレッドはどう扱うのか、1対1の非公開会話についても動画では短くしか出ていなかったので、もっと知りたい。ツール自体には確かに可能性がありそう
チャンネルに入ってチャットする構造ではない。フィードではスレッドごとに高さが固定されているため、活動の多いスレッドが無限にスペースを食うことはなく、スレッドを一定時間保存したりミュートしたりする機能も追加予定。タグはスレッドごとに個数制限があり、文脈の追加やカスタムフィードの作成に使われるほか、タスクの優先度追跡にも活用して軽量な作業管理システムのように使っている。似たタグはマージできるようにし、新しいタグの作成をモデレーターだけに許可するといった制御も可能。似たスレッドはマージでき、スレッド内の一部チャットを選んで新しいスレッドにフォークする機能も準備中で、スレッド間のリンクは維持する予定。非公開会話は相手にしたいユーザーをメンションすればよく、@struct をメンションするとボットとの DM、自分自身をメンションすると TODO やメモ用の「セルフ DM」が作られる。チャットプラットフォームがあふれる市場なので Struct が「また別のチャットアプリ」のように感じられるかもしれないが、他のプラットフォームが当然やるべきだと思っていたことを何年待ってもやらなかったため、自分たちで作ることになった
誰かがこちらの注意を求めるなら、新しいスレッドを作るなどして、結局は注意を奪う方法を探し続けることになる
初めて興味を引かれた Slack 競合の一つで、方向性は正しいように思える。動画を見た印象は全体として好意的だが、どこか個人的なつながりが薄いツールに見えた
Slack の部屋はデジタルな「部屋」のように感じられたが、Struct はオフィスの掲示板のような印象を与える。会社が完全に Struct に乗っている状態で新入社員として入ったら、同僚との個人的なつながりを作るのがより難しそうだという第一印象がある。理由は正確には分からないが、デモを見てそう感じた。以前シリコンバレーでエンジニアリングリーダーとして働いていたときに経験したコミュニケーションの混乱を考えると、最後の会社にこういうツールがあればよかったと思う
フィードベースのプラットフォームは概して非常に非同期的で、ほとんどフォーラムのようになりがち。そこで Struct のリアルタイムフィード設計では、「今この部屋にこの人たちがいて、すぐそこで話している」という感覚を強調しようとした。新しいスレッドが現れたり、新しいチャットがフィードに表示されたりする瞬間はかなり楽しく、興味を引く。オンラインの人の一覧を見せれば会話を始めたくなるかもしれないし、他の人が参加している様子を見せるだけでも役に立つ可能性がある。会話がより始まりやすくなるよう最適化する余地は確かにある
それでも、新入社員が温かく歓迎されていると感じられるようにすることは、どの組織にとっても重要で、リモート勤務の比率が高い組織では特にそう。@random チャンネル、@club-channels、@annoucements のような場を作って、面白いリンクや告知系の資料を共有し、同僚を知るための場として使える。@struct の内部はかなり仕事中心で、作ることは好きだが、楽しさも取り入れる必要がある
とても良い。チャンネルは維持しつつ集中したスレッドを使うというアイデアが気に入ったし、デザインも良い
ただ、長期計画が気になる。こうしたサービスに大量のデータを入れる前に、ベンチャーキャピタルの資金で成長させた後に売却して放置するようなものではないと知っておきたい
期待しているロードマップには、音声／ビデオ通話とウェビナー、コミュニティ向けのスパム制御、AI ボットと回想機能の改善およびコスト削減、Struct で共有された文書のインデックス化とアクセス制御を維持した AI 回答などがある。Struct が面白いのは、チームチャットとコミュニティチャット、作業管理システム、ChatGPT、個人の TODO リスト、公開インデックス可能な知識ベースをまとめて置き換えるから。システムが忘れないと信頼できるときに可能になることは驚くほど多い
有望に見える。ただ、価格表示はもう少し練り直してほしい
自分で計算するには複雑で、議論が突然盛り上がって費用も爆発するのではないかと心配になる。例を出して表形式で見せてくれるとよい。ユーザーに考えさせないでほしい。Struct 名に最低6文字の制限があるのも疑問。4文字からで十分ではないかと思うし、3文字を超える国際標準ももうないのではないかと思う。それから macOS アプリのアイコンは、他のアプリのように単色にしてほしい
月額基本料金は9.97ドルで、ユーザー数やスレッド数、チャット数ではなく、AI 使用量にのみ課金する。基本価格には20万トークンが含まれており、スレッドタイトルと要約の生成程度にしか使わない小規模組織には十分。実ユーザーでは Typesense の平均使用量がその程度で、Apache Druid は月40万トークン程度を使っている。1,000トークンは3セントなので、20万トークンは基本料金の上に6ドル追加される程度。どちらも Struct を知識ベースとして使っている。課金を強制し始める際には、月間支出上限を設定できるようにして予想外の請求が発生しないようにする予定で、基本料金以降の費用は望むだけ低く抑えられる
製品リリースおめでとう。昔のフォーラム時代を覚えているくらいの年齢だけど、正直なところフォーラムを再発見したもののように見えた
更新があると上に上がってくるスレッド構造のこと。大きな違いは、UIがよりチャット/Facebookっぽく、フォーラムは管理者が静的に構造化していた一方で、Structでは多くのトピックが同時に動く大きな組織で必要になるフォルダのようなスレッド構造化があまり見えない、という程度だった。一方メールは、ある程度「会話」としてまとめられるし、個人フォルダでも構造化できる。「AI」が付いている点も、最近は疲れる感じがする。スレッドの動的要約自体には意味があるが、スレッドがチャットのように単純なら要約は不要だし、メール/フォーラムのように長いなら実際にどれほど機能するのか確信が持てない。なので、これがAIという流行語を付けたチャット型マーケティングアプリなのか、それともフォーラムのスレッドやメールの会話とは根本的に違う何かを自分が見落としているのか、よく分からない
メールを含むすべてのフォーラムにはスレッドとフィードがあるが、フォーラムは非同期的で、リアルタイムチャットを中心に設計されてはいない。スレッドとフィードの概念をチャットプラットフォームに適用するときの難しさは、それをリアルタイムにしなければならない点で、Structが解決しようとしているのもまさにそこだ。「チャットなら要約は必要ない」という意見には少し同意しにくい。延々と続く会話には十分すぎるほど参加してきたし、小さなチームでも数百件のメッセージが飛び交うスレッドがある。要約は実際かなり役に立つし、少なくともタイトルがあるだけでもフィードはずっと理解しやすくなる。タグでスレッドを構造化し、そのタグを中心にフィードを作ることができ、これがフォルダに相当する。Gmailが登場したとき、人々がラベルをSMTPのフォルダに対応させて理解する必要があった頃を思い出す。StructのスレッドとDiscourseのスレッドの違いは、Structが短くリアルタイムに行き来する往復コミュニケーションを重視し、Discourseは長く熟考された単発の投稿を重視する点だ。前者はチャットで、後者はフォーラムだ。Structの設計が難しい理由も、構造、知識、リアルタイム性のバランスにある
いつも議論の核心を完全に外して、とんでもない要約を作ってくれるので、何時間も笑いの種になった
「CEOのスレッドからフィードを作成し、会社の最新のビジョンと目標に足並みをそろえましょう。適切な返答で会話に飛び込み、当然の昇進を手に入れましょう」という文言には苦笑させられた
結局重要なのは、何をするかではなく誰がそれを見るかなのだと改めて思い知らされる
最初の職場だったGoogleでは作り続けるばかりで、自分が作っているものがなぜ重要なのかを伝えるのに苦労した。最初のマネージャーは私以外のチーム全員を昇進させ、今でも痛みとして残っている。チームとマネージャーを変えると、自分がいるべきレベルより2段階低く評価されていたと聞かされた。結論は、そういう会話に参加しろということだ。押しつけがましく振る舞う必要はないが、存在感は知らせるべきだ
従業員が上司に自分を売り込むために時間を使うよう促すのは、会社にとっても利益にならない。こういう光景はよく見るが、たいていのマネージャーがこの部分でうまく仕事をできていないサインに見える
runForThread.executeReq.Get.messages: executeReq.client.Do: Get "[https://api.openai.com/v1/threads/thread_*******/messages?li...](<https://api.openai.com/v1/threads/…;)": context deadline exceeded (Client.Timeout exceeded while awaiting headers)いつか新しい製品がOpenAI依存なしでも出てくるようになるといい
OpenAIは気に入っている。GPT-4は本当にうまく動く。もっと安い他のモデルも試したが、品質はそこまで良くなかった
.aiドメインをブロックしてしまおうかと思う真面目な話、この製品は「…そしてAI」という文言を見るまでは本当に面白そうに見えた。たぶん自分はターゲット顧客ではないのだと思う
要約はAIが本当に得意なタスクの1つなので、この製品は素晴らしいと思う
どんな技術を使っているのか気になる。内部でdgraphやbadgerが使われているのか、ホスティングはビッグ3なのか他の場所なのか、Kubernetesを使っているのか、Elastic Searchを使っているのかも気になる。それからStructがSlack/Discordをオンラインでスクレイピングするツールなのか、今あるいは今後、独立したチャットアプリになろうとしているのかも気になる
最大のコストはOpenAIから発生していて、embeddingsはOpenAIではなくMicrosoft E5を使っている。Typesenseは検索に使っており、Structのユーザーでもある。Postgresの代わりにBadgerを使うのは適切ではなかったが、別の用途ではBadgerを検討している。内部ではristrettoとroaring bitmapsを多用している。StructはSlackとの統合がかなりよくできていて、Slackインターフェースのように使える。同僚はSlackを使い、私はStructで返信する、Gmail向けのSuperhumanのような感じだ。Discord統合もしっかりしており、どちらもオープンソース企業がSlack/Discordの会話から公開ナレッジベースを作るために使っている。[1]: https://github.com/struct-chat/embedding
生産性を間違った形で最適化しようとしているのではないか、と時々思います。コミュニケーションのノイズを管理するツールよりも、そもそもコミュニケーションを減らしながら必要な仕事をきちんと終える方向のほうが、より大きな利益が出るかもしれません
たとえば会議が何十件もあるとしても、議事録をうまく追跡できるように最適化したいとは思いません。数は少なくても、より効果的な会議が望ましいです
AIが会議の録音文字起こしから自動要約を作れるなら、次のステップやアクション項目まで後続処理できない理由はありません。次のステップが Janine が Carlos と会議を設定することなら、AIが Carlos に連絡して日程調整を手伝えばよいのでは、と思います。今は考え方が小さすぎます
ただしメトカーフの法則も避けられません。現代の仕事のほとんどはチームで行われ、チームサイズが N なら O(N^2) のコミュニケーションコストを支払う必要があります。全体のコミュニケーションが減るとは思えず、より効果的に処理するための適切なツールが必要です
素晴らしいです。Discord は情報を検索したりスレッドを追ったりするには最悪です
同じ質問に何度も繰り返し答えているように感じます