コンピュータおじさんはコラボレーションの夢を見るか?

Groove

サーバーに依存しないP2Pコラボレーションの夢にLotus Notes的なフォーム型データベースをトッピング。まだ通信環境はPHSだったなあ。（Air H”だっけ？）

[

Ray Ozzie - Wikipedia

Wikimedia Foundation, Inc.Contributors to Wikimedia projects

](https://en.wikipedia.org/wiki/Ray_Ozzie)

Salesforce Chatter

データベースレコードにチャットを生やすという構造化データと非構造化データの革命、だったのだが。デスクトップアプリをAdobe Airで作ったばっかりに…。もしマルチバース設定なら、SlackベースのChatterクライアントを開発してよ。

Quip

修飾の制約という美、Markdownに通じるものがあったが、合掌。オンラインのホワイトボードルームという夢を見せてくれた。

[

Quip (software) - Wikipedia

Wikimedia Foundation, Inc.Contributors to Wikimedia projects

](https://en.wikipedia.org/wiki/Quip_\(software\))

Slack

アップデートのたびに重厚長大化し、通知が飛ばないトラブルが頻発してなんか信頼がなくなったところに、チャネルとDMの概念設計が変わっていき、コラボレーターに課金したところで、Microsoft Teamsに対するコスト優位性が逆転。

Microsoft Loop

Quipの正当な後継者で、本家の夢（Salesforce Slack Canvas）を追い越した。ただ、宗教上の理由でTeams禁忌の方が大杉だし、マイナーなまま。

そして大規模言語モデルと生成AIの時代におじさんが見る現実

• オンラインコラボレーションエディタでは：
  • LLMと生成AIの支援がツール側の対応になってしまい機敏性がない。
  • ドキュメントの散逸問題を解けない
• Markdown + Mermaid on Visual Studio Code + Markdown Preview Enhanced + GitHub でいいんじゃないかという。
• 今風に言えば Mono Repository。

図に必要なコンテキスト

図とコード（文章）って格納されるコンテキストが違う気がする。なので、コードから図を生成していくのが、パラダイムシフトなのかもしれない。