QWINCS とは、主なコミュニケーションツールを述べた略語である。クインクスと読む。
QWINCS は以下を示す。
QWINCS は Tool というよりも Thought であり、 コミュニケーションツールは Slack や Teams といったチャットだけではない 点を強調している。チャット以外にも 5 種類存在しており、できるだけ多く使いこなせた方がコミュニケーションの幅が広がるのは自明だ。特に原始的な出社や会議への依存を減らせる。
ソフトスキル開発においても QWINCS は重要となる。概念を扱う関係上、言語的な読み書きによるやり取りの比重を増やさねばならないが、チャットだけでは難しい。もちろん出社や会議も非言語コミュニケーションがメインであるため上手くいかない。ソフトスキル開発者であれば QWINCS の 6 種類のツールはすべて理解し、使いこなせるようになりたい。
以降では各々の代表例、概要、どういうときに使えるかを整理する。
Q&A はいつでも誰でも質問を投稿し、また回答を書き込めるコミュニケーションツールである。QWINCS の中では唯一、まともなコミュニケーションツールが存在しないが、to C 向けには Stack Overflow や Quora などがある。
Q&A の真価は 「誰かが知っていること」を数の力で素早く解決すること にある。知らない人が自力でやると 1 時間以上かかるかもしれない情報を、知っている人が 2 分で回答できる。前後の確認やベストアンサー操作も含むと、5 分で終われるだろう。つまり単純計算で 1 時間から 5 分に削減できている――と、これはあまりに単純なたとえだが、Q&A が狙う効果である。
逆を言えば 数の力がないと成立しない ともいえ、コミュニケーションツールとして未だに開拓できていない理由でもある。少なくとも数千人、できれは万人以上のボリュームが欲しいが、そんな大企業はマイノリティだ。かつ、大企業は大企業で官僚的なので「全員誰でも Q&A ができる社内プラットフォーム」なるものは成立しえない。やるにしても部門やチームなど限定的な範囲だろうが、それだと数が足らない。
そういうわけで、もし Q&A を実現したいのあれば、千単位・万単位の社員全員を参加させるプラットフォームをつくらねばならない。あるいは、その規模の参加による「数の力」に匹敵するだけの回答の多様性とレスポンスの速さを実現せねばならない。どちらも難題だろう。
ここで「生成 AI があるじゃないか」と思われるかもしれないが、生成 AI に Q&A を代替できるポテンシャルはまだない。Google で調べてわかるようなことは解決できるが、より肝心なのは社内ドメイン――社内固有の知識である。社内ドメインに関する質問は、知っている社員でないと答えられない。「RAG が使えるじゃないか」と思われるかもしれないし、私もあと 2028 年くらいなら追いつくと思うが、2026 年現在では「知っている社員が素早く答える」のクオリティは出せない。あるいは出せても、そのような環境の整備には非現実的なコストがかかるだろう。コストが下がるにはある程度の時間を要する。
ウィキは歴史の古いツールである。元は情報をプレーンテキストかつブラウザ完結で素早く書き、かつリンクによりページとページをつないでネットワーク構造の利便性を享受するためのツールであったが、コミュニケーションツールとしても使える。
ウィキの真価は SSoT（信頼できる唯一の情報源）なコミュニケーションのエリア を実現できることにある。プレーンテキスト、ブラウザ完結、ページ単位で独立して扱えること、またリンクにより情報の使いまわしや動線の設計が自在に行えることなどが強みであり、体験を快適にする。快適は重要だ。快適だからこそ毎日高頻度にアクセスでき、したがって SSoT にできる。快適でない場所は SSoT にはならず、十中八九形骸化する。別の言い方をすると、SSoT の要件を満たしたコミュニケーションツールがウィキ なのである。
したがって、SSoT をつくりたければウィキに頼るべきである。
しかし既存のウィキは（SSoT 指向という意味では）出来の悪いものが多い。私が知るベストアンサーは Cosense である。まずは Cosense が使えないか検討し、使えない場合でもなるべく使えるよう粘ってほしい。それでもダメなら他のツールや自製を考えたい。それくらいに Cosense はウィキとしての出来が良い。
逆に以下のウィキはおすすめしない。
Issues とはチケット型サービスを指し、元は課題管理のためのツールであったが、コミュニケーションツールとして汎用的に使うこともできる。つまりは 1-チケット 1-話題でコミュニケーションをすればいい。事実、GitHub は Issues をベースとした Discussions をリリースしている。
Issues の真価は トピック指向かつタスク指向――一つの話題を一つのページに押し込めることができ、かつタスクとして「終わったかどうか」を扱えるところにある。特に非同期コミュニケーションにおいては、コミュニケーションそのものをタスクと捉えて、タスクを一つずつ独立させて扱うこと、かつ終了させることが肝となるが、その実現に Issues が必要なのである。
つまり非同期コミュニケーションをやりたければ Issues を導入するべきだ。Issues を導入し、使いこなせるかどうかで非同期メインの働き方の成否が決まる。具体的なツールとしては、GitHub Issues を使えば間違いはない。他にもチケット管理ツールは存在し、ひとまず Backlog を挙げているが、私も使ったことはない。本質的には軽量なチケット管理が、それこそ普段のコミュニケーションをカバーするくらいに重用できるポテンシャル（特に軽量さによる快適さ）があるのなら何でも良い。
Notes とは共同編集型のノートを指す。歴史的には Microsoft Word など静的なリッチテキスト文書から始まっており、技術の発展に伴って、クラウドベースで複数人が同時に編集できるようになったものである。一つのノートに複数にアクセスし、同時に編集を行える。また各人のカーソルも見えており、誰がどこに（どの行に）いるかもリアルタイムで見える。
Notes の真価は 一次元的なバーチャルオフィスとして使える ことにある。高いパフォーマンスや満足度の出し方として「皆で物理的に集まって密に連携する」方法が古くから知られているが、現代では非現実的なことも多かろう。そこで仮想空間にアバターで集まる発想が近年実装されており、バーチャルオフィスと呼ばれる。Gather や Spacial.Chat などが有名であり、日本でも軽量な手段として Remotty や Teracy があるが、Notes も実はこのカテゴリーとみなせる。
たとえばオフィスを模したページを一つつくり、メンバー全員が集まる。各自のセクションをつくって、そこにつぶやきや情報共有を書き込んだり、他メンバーの書き込みに反応や返信を書いたりする。重要事項や投票内容などは上の方にセクションをつくればいいだろう。このような「拠点ページ」は、一日一つつくるのがわかりやすい。今日が 2025/12/19 なら 2025-12-19 という名前のページをつくって、そこに皆が集まるのだ。
各メンバーのカーソルと書き込みはリアルタイムに見えるため、あたかも一緒にいるかのような体験ができる。無論、物理的にオフィスに集まるほどリッチではないし、従来のバーチャルオフィスほどリッチでもないが、バーチャルな集合自体は実現できている。そういうわけで、集合的な体験は欲しいが、従来のバーチャルオフィス以上だとリッチすぎるという場合に重宝する。
もう一つ使えるのが議論である。会議を開催する代わりにページを一つつくり、参加者はそこにアクセスして、会議時間中にコメントを書き込んでいく。ファシリテーターはコメントを促し、意思決定者は最終的な意思決定を書き込む――と、従来の会議とは全く異なる体験だが、より柔軟な働き方と広くて深い議論が可能となる。なんたって皆の発言を覚えておかなくていいし、もちろん張り付く必要もない。
と、このように、ページ単位でバーチャルに集まれるようになる。
最後に重要な話題をいくつか記しておく:
チャットとはビジネスチャットと呼ばれるもので、Slack や Teams や Discord といったチャンネルベースのチャットツールを指す。
LINE や SNS のダイレクトメッセージとは違い、ワークスペースやチャンネルといった組織単位で構造化できるのが特徴である。これゆえにビジネス用途に耐えらえるようになり、しかも直感的で便利なのでメールやインスタントメッセンジャーの後継となった。まず Slack がエンジニアの間で流行り、次にゲーム業界で Discord が成功し、パンデミックが来て Teams も出てきて、このジャンルが爆発的に普及した。
チャットの真価は 通知を送れる点 にある。設定次第だが、メンションを書けば相手に通知を飛ばせる。通知が飛べば気付いてもらえる。従来は直接声をかければ良かったが、リモートで同じことを行えるのが、このチャットというジャンルである。別にチャットに限らず、他の QWINCS にも通知機能はあるが、万人が使えるほど普及したものはチャット以外にない。チャットは現時点でコミュニケーションツールのデファクトスタンダードである。ゆえに 万人向けでリモートで通知を送る手段 となると、チャット一択になってしまう。
さて、ソフトスキル開発の観点では、通知は集中を邪魔するものでしかない。害悪である。一方で、通知無しで完結するのも現実的ではなかろう。なのでチャットは通知を送る手段に留めるのが良い。常時起動はしておくが、基本的には使わない。通知が届いたら確認する――と、この程度に留めるのである。
特に「すぐに見てほしいもの」や「忘れずに必ず見てほしいもの」は、ウィキや Issue やノートに書いただけでは気付いてもらえないことがある。そこで、それらの URL を添えて、メンションをつけて送ればいいのである。もちろん以降のやり取りは（チャットではなく）その先で行う。つまり チャットを通知送信装置として 使う。私はこのあり方を Chat And Away と呼んでいる。
Sticky Boards とは、Miro のようなデジタルホワイトボードを指す。QWINCS の言葉をつくるために強引にこじつけたものであり、わかりづらいかと思うがご容赦を。
ホワイトボーディングは元々アナログな模造紙と付箋紙で行われていたが、技術の発展によりデジタルでも可能となった。パイオニアは明らかに Miro だが、他のコミュニケーションツールやプラットフォームも類似機能を搭載し始めている。また Canva や Figma など作図ツールの共同編集という形で似るパターンもある。また、従来の「付箋を貼り付ける」スタイルから、付箋以外にも多様な情報（小難しく言えばオブジェクト）も扱えるようになった。パワーポイントレベルのグラフィカルな資料をつくったり、オンラインイベントの会場として使ったりする例も見られる。
Sticky Boards の真価は 二次元的なバーチャルオフィスとして使える 点にある。Notes は文書であり上下方向で一次元的だったが、Sticky Boards はキャンバスであり上下左右の二次元空間が使える。また、Notes は文書的だったが、Sticky Boards はもっと自由に様々なコンテンツを置ける。
使い所は Notes と同じだが、Notes よりも次元が多いため ワールド の概念を実現しやすい。ワールドとしてわかりやすいのはマイクラであり、初期出現地点から様々な建造物がつくられる。既存の建造物は勝手に壊してはいけない。要は土地の概念であり、Sticky Boards でもこのような世界観を構築しやすい。
ワールドの利便性については、実は私はよくわかっていない。私なら Sticky Boards を使うよりも前に QWIN が使えないかを考える。ソフトスキル開発は言語的に行うものであり、ビジュアルに寄りすぎた Sticky Boards はオーバースペックだからだ。しかしビジュアルシンカーと呼ばれるタイプがあるように、Sticky Boards だからこそ合う人もいるかもしれない。そういうわけで、もし QWIN が合わないのなら、Sticky Boards を積極的に試す価値がある。