HAWK
2026 年 7 月 26 日午後 9:39
1
先週、この件について考える時間を割きました。これは、Meta 上で私たちのチームをより深く関与させることに関する議論の影響も一部受けてのことです。
プロダクトチームがコミュニティ内でお客様とどのように相互作用するかは、組織によって大きく異なります。ここでは、Meta での私たちの経験を基にお話しします。
私たちの状況は、お客様と共に製品をリアルタイムで「内部利用（dogfooding）」している点で非常にユニークです。プロジェクトの最初の数年間は、組織内の全員が直接製品開発に従事しており、コミュニティの一員であることが職務の不可欠な部分でした。しかし、時が経つにつれてその状況は変化し、現在ではサポートカテゴリ以外でのスタッフの参加を積極的に促す必要があります。
チームの一部のメンバーは、Meta で時間を費やしていない理由として、どう関わればよいか分からないと認めています。彼らは、答える資格がある質問がないと感じており、興味深い関連性の高い議論をリードするために必要な深い知識を持っていないとも感じています。以下は、私たちのチームが Meta により多く参加するのを妨げていると特定したいくつかの課題です。他の組織でも同様の課題を抱えていると確信しています。
質問に対する不正確、古すぎ、または一貫性のない回答。（正しい答えが分からないこと、または間違った答えをする恐れが、多くの人の参加を妨げています。）
声の大きいメンバーがチームに過大な影響力を及ぼす可能性があり、他のメンバーにとって不利になる場合もあります。（一部のメンバーと外交的にやり取りするには多大なエネルギーが必要で、全員がその忍耐を持っているわけではありません。）
ロードマップを十分なコミュニケーションなしに変更した場合、またはフィードバックを求めたにもかかわらずそれを無視しているように見えた場合、信頼は損なわれます。（一部の人は、満たせない期待を設定したくないため、プライベートで作業する方が安全だと感じています。）
人々が焦っているため、関係のないトピックに個人でメンションされることによる通知疲れ 。（一部のメンバーは、目に見える存在を、ストレスを感じている際に個人的なサポートを要求するための招待と見なしています。）
メンバーが自分の意見が聞かれていないと感じた場合のフラストレーションの管理。（誰も責められるべきではない場合でも、対立的な性質のために参加自体が負担になることがあります。）
あなたの組織では、直接のお客様とプロダクトの相互作用がどこでうまく機能し、どこで困難を伴うようになりましたか？
「いいね！」 11
これは興味深いですね。ソフトウェアを設計し構築する人々が、こうした種類の質問や議論に対応するのに最も適した人々であるはずだ、というのが自然な推測でしょう。この自信の欠如を促す要因は何なのか、より深く掘り下げて調査されましたか？
「いいね！」 5
chapoi
2026 年 7 月 28 日午後 12:17
3
チームメンバー全員がエンジニアやデザイナーというわけではありません
「いいね！」 5
プロダクトマネージャー、カスタマーサポート、エンタープライズサポート、マーケティング、セールスなどについても、同様の前提があると思います。必要な知識なしにこれらの仕事をうまくこなすのはかなり難しいでしょう。
「いいね！」 3
HAWK:
答える資格があると感じる質問がない
私たち全員が、時には多少そのような気持ちになることがあると思います。しかし、フォーラムベースのコミュニティには、ソーシャルメディアに対して優位性がある点があります。会話のペースが遅く、トピックの寿命が長いことが、他のユーザーの「雰囲気」を掴む機会を与え、最終的に参加しやすくなるのです。
「答える資格がある」というのは、どのような質問が投げかけられるかによります。ユーザーが全く知識がない場合、Discourseに関するわずかな知識でも持っていれば、誰でも助けになることがあります。反対に、非常に技術的なことについて非常に具体的なことを尋ねる場合もあります。そのような場合は、通常、質問に十分な情報が含まれていることを確認し、資格のあるメンバーがスレッドに訪れた際に、必要なものを揃えておきます（バージョン番号など）。
これもまた、ある意味で人間の本質的な部分だと思います。そして、皮肉なことに、興味深い会話は多くの予期しない場所から生まれるものです。
「いいね！」 5
Canapin
2026 年 7 月 28 日午後 5:22
6
このトピックに直接答えることは難しいかもしれませんが、Discourse に関連するいくつかの観察結果があります：
HAWK:
質問に対する不正確、古くなった、または一貫性のない回答。（正解を知らないこと、または誤った回答を与えることを恐れることが、多くの人を参加から遠ざけています。）
ソフトウェア自体の開発者や他の立場のチームメンバーでさえ、「ああ、[機能や Discourse に関する何か]については知らなかった」と言っているのを時折耳にしました。
最初は驚きましたが、すぐにその理由が分かりました。
Discourse を愛し、それを推奨し、時には自分自身で Discourse の管理者を務めるような熱心なファン（私のような人々）は、非常に優れた 一般的な Discourse の知識を持っており、ソフトウェアに関する多くの質問に答えることができます。場合によっては、チームメンバーよりも多く、あるいはより正確に答えることもあります。これは、CDCK のある種の成功や成果と見なせるでしょう
私は、Discourse 開発者でさえも、Discourse の機能について 何でも 知っているとは期待していません。知っておくべきことが単に多すぎるのです。その多くは、彼らが報酬を得ている業務とは無関係であり、Discourse に関する多くの質問は彼らの専門分野を超えている可能性があります。もちろん、それによって彼らの価値が低下するわけではありません。彼らはそれぞれの分野の専門家です。
もちろん、誰しもが自分の知識を過信し、質問に答えようとして、最終的に間違ってしまうことがあります。これはチームメンバーであれ、そうでない人であれ、誰にでも起こり得ることです。私自身も何度も経験しており、その時が一般ユーザーだったかどうかに関わらず、少し恥ずかしく感じたこともあります。
CDCK に在籍していた頃、ある顧客の CSS 問題に自信を持って飛び込み、簡単に速やかに解決できると考えていたことが思い出されます（それは私の仕事ではありませんでした）。しかし、私は完全に間違っていました。問題は予想以上に複雑で、最終的には専門家に任せて修正してもらいました。
さて、引用した内容に直接答えているわけではなく、今となっては単なるエピソードを共有しているに過ぎません。
HAWK:
メンバーが自分の意見が聞いてもらえていないと感じた際の不満の管理。（誰のせいでもない場合でも、参加が対立的な性質を持つため、負担になることがあります。）
これは双方向の問題です。一部のチームメンバーとの摩擦のあるやり取りが、Meta で常に（少しですが、大した問題ではありません）私を悩ませた数少ないものの一つだったと思います。初日から現在まで、時折そのようなことがありました。
これは単に人々の性格、気分、気質、そして文化の違いによるものだと思われます。多くの場合、時折厳しいやり取りをする人を責めることはできず、また責めようとも思いません。
まあ、トピックの唯一の質問には答えられなかったので、少し脱線してしまって申し訳ありません
「いいね！」 7
うん、これも覚えておくべき重要なポイントだと思う！何かを間違えてしまうことは、いかに frustrating（苛立たしい）で恥ずかしいことであっても、誰も手を出さないことの方がマシだ。爆発するようなものを作っているわけじゃないし、間違いが取り返しのつかない損害をもたらすケースはほとんどない。
少し忍耐強くやれば、解決策が見つかるし、その過程で何かを学べる……私の経験では、Discourse を使っていてここで議論に参加している人の 99％は、このことを理解している。
「いいね！」 4
Canapin
2026 年 7 月 28 日午後 6:38
8
私はゆっくりとオフトピックな方向に流れていますが、あなたの言葉は、著名な Trackmania ストリーマーが子供、失敗、そして学習について語った名言を思い出させます：
[子供たちは]恐怖も持ちません。子供たちは通常、考えすぎず、[…] 間違っていることを恐れません。それが最も良い学習方法です。何かが機能しないのを見てみましょう。しかし、大人になって新しいスキルを学び始めると、間違っていることを少し恐れてしまいます。子供たちは大人よりも試して失敗する willingness（意欲）が高いです。例えば、教師が「誰かアイデアある？」と尋ねたとき、自信を持って間違った答えを叫び出すような感じです。そして、この種のメンタリティがあなたがどのように物事を学ぶのかを形作ります。
覚えておくべきことですね
（オフトピック終了）
「いいね！」 4
HAWK
2026 年 7 月 28 日午後 7:34
9
ジェームズ、こんにちは。
調べました！ 参加に伴う隠れたコストの理解と、参加するためのフレームワークの両方が組み合わさっているのだと思います。
スタッフのエンゲージメントにおける内部コスト 意味のある参加には、実際に質問に答えるために費やす時間や努力以上のものが求められます。人々は情報へのアクセス、モデレーションのサポート、フォローアップのフレームワーク、エスカレーションの経路、そして何を議論できるか/どのような例を共有できるか/どの顧客を名指しできるかといった明確な指針を必要とします。
コミュニティチームは一般的に、この目に見えない作業を引き受けています。それは、どの専門知識を持つ担当者（SME）を巻き込むべきかを知っており、メンバーとの関係性を持っており、議論を生産的に保つためのスキルを備えており、何かが見落とされないように確認する時間を持っているからです。これにより、信頼レベルが維持され、コミュニティがすべての参加者に価値を提供することが保証されます。
私たちのチームは、その信頼の価値と、それを築くのにどれほど時間がかかるかを理解しています。そのため、信頼を損なうようなことをしてしまうという恐怖心が、一部の人々を参加から遠ざけるのに十分な要因となっています。
内部チームを圧倒することなく信頼を築く 信頼は、絶え間ない対応よりも予測可能な行動からより多く生まれます。プロセスへの信頼があれば、顧客やメンバーはチームへの継続的なアクセスを必要としません。彼らが知りたいのは以下の点です。
フィードバックを提供する場所
フィードバックがどのように処理されるか
誰がそれを読むか
どの議論に返信が届くか
意思決定がどのように行われるか
いつフィードバックが報告されるか
信頼できる継続的なフィードバックループの何らかの形態が必要です。高頻度で対応可能だが信頼性に欠ける状態よりも、境界線がありながら信頼できる状態の方が望ましいです。誰もしゃべる相手がいない虚空に向かって叫ぶような状況で、フィードバックを提供するために時間を費やす人はいません。メンバーのニーズを理解するための十分な直接的な接触と、すべての人がその対話から得られる価値を明確に把握できるだけの構造が必要です。
これは興味深いですね。@mae を呼び出して、技術的な製品に関する質問に答えることについてどう感じているか聞いてみましょう。結構目から鱗の発見があるかもしれません。
アンドリュー、あなたに同意します。だれでも答えられるいくつかの質問は常に存在する可能性がありますが、そのような場合に見つかりにくさ（ディスカバラビリティ）が問題になることがあります。他のチームがこれをどのように処理しているか、その方法を知りたいです。
Canapin:
（オフトピック終了）
オフトピックだとは思いません。そこから学べる貴重なものがあると思います。失敗を恐れる理由について、より深い理解が必要です。
「いいね！」 4
私は回答に自信がない場合、以下のようにしています。
まず第一に、その質問が未回答のままどれくらい放置されているかを確認します。
もし1、2時間程度しか経っていない場合や、週末であれば、少し様子を見ます。自分より頭の良い誰かが回答してくれるのを待つのです。
非常に具体的な質問で、24時間経っても誰も反応しない（カエルの鳴き声すら聞こえない
回答が分かったつもりだが、自信がない場合は、「多分…（I think…）」と言います。
回答が分かったつもりだが、100%確信が持てない場合は、「ほぼ確実ですが…（I’m almost certain…）」と言います。
全く見当がつかない場合は、「ただの推測ですが…（I’m just guessing here…）」と言います。
話題がしばらく放置されている多くの場合、どのような形でも誰かが返信することは、全くの無反応よりもましです。少なくともユーザーは、自分が無視されているわけではないことを知ることができます。そして、返信によってトピックが浮上し、他の人が参加することもしばしばです。
これは重要だと思います。（そして非常に良くまとめられています）自動返信のように見えるが、その後フォローアップしない超迅速対応のチームは価値がありません。
しかし、これも他のトピックで人々がコミュニティ参加の減少について言及していることに関連していると思います。サポートフォーラムが返信しない、または返信に数時間を要する場合、AIに質問して即時の回答を得ようとする誘惑はさらに強くなります。
ちなみに、メタはここで良いバランスを取っているのだと思います。
これこそが、コミュニティフォーラムが臨界点に達した瞬間だと思います！
コミュニティフォーラムを立ち上げようとしている者として、いつか達成したいのはこれです。
フォーラム、特にサポートフォーラムに十分な知識を持つベテランユーザーが参加し、ユーザーが質問すると、その楽しみのために質問に答える一団が常にいる状態になれば、本当に良い状態です。タイムゾーンが十分に分散されており、常に誰かが起きていて返信している状態になれば、まさに「ワールドワイドウェブ」の力を活用していることになります。
「いいね！」 7
興味深い記事でしたが、私が最も好奇心を持っていた主要な点についてはカバーされていなかったように思います。私は特にこの点に関心がありました：
これは直感に反するように思えます。それよりも多くのことを、そしてこれほど広範なサイトやユースケース全体を知っている立場にあるのは誰でしょうか。確かに誰もがすべてを知っているわけではありませんが、平均的な閲覧者（ルーカー）よりもずいぶん多くのことを知っているはずです。
製品からかなり遠い部署（財務、法務など）もあるでしょうから、このフィードバックが単にそれらの部署からのものならもっと理解できますが、もしそれだけで簡単に説明できることなら、あなたはもっと早く言っていたはずです。
これは何かの仕掛けのようです…
ただし、時間やリソースをどこに最も効果的に配分すべきかについては同意しますが、それは「参加したいのに参加できないと感じている」という問題とは別の話です。
「いいね！」 1
mae
2026 年 7 月 28 日午後 10:17
12
バスケットボールのコーチにテニスを教えてもらいますか？どちらもスポーツですが、実際にそのゲームをプレイしている人に教えてもらいたいですよね。ここでも同じ考え方で、私が答えられないような質問を誤って答えるよりも、適切な専門家をご紹介する方が良いでしょう。
ポジショニング、メッセージング、そして Discourse のストーリーをどう伝えるかについては終日話せますが、深い技術的な内容は実際にそれを構築している人たちに任せるべきです。
とはいえ、マーケティングと営業が Meta でより大きな役割を果たし、技術的な色彩の薄いコンテンツの推進役になるべきだと私は考えています。これは私の Q3/Q4 の優先事項です。
Meta で見たいと思う、技術的な色彩の薄いコンテンツに関するアイデアがございましたら、遠慮なくご連絡ください、またはトピックで私をタグ付けしてください。
「いいね！」 5
HAWK
2026 年 7 月 29 日午前 12:12
13
その通り、この考え方は素晴らしいと思います。完璧なアプローチだと思います。
非常に興味深い指摘ですね。間違いなくその通りだと思います。ただし、人々はここで（あるいは他のフォーラムで）ボットをデフォルトとして使うでしょうか、それとも完全に外部のサービスに頼るでしょうか。これを測定してみるのも面白いかもしれません。
私の回答は少し複雑でしたが、言いたかったのは特にこの点です：
補足ですが、参加に対するその特定の障壁を感じているのは、組織のビジネス側です。技術的な質問については実際には言及していませんでしたので、混同されていたようです。
その通りです。誰かが私にDiscourseに関する基本的な質問をしてくれば、かなり自信を持って答えられると思います。しかし、非常に高度な設定や、深く隠れたバグであることが判明するインストールエラーなどになると、それは私の知識の範囲を超えています。
数ヶ月前には、私がかなり投稿を控えていた時期がありました。単にいないからではなく（実際にはいて、毎日Metaを読んでいました）、質問が非常に技術的になり、タイムゾーンの影響でそれらを見るのがずっと遅くなったからです。非常に具体的なバグ報告や、私のインスタンスに適用しきれないほどに特化した質問などです。
そこで、私が知っていることは、実際の製品に取り組んでいる開発者や、MoinやLillyのような人々と比較すると、表面をちょっとなぞる程度に過ぎないことに気づきました。
私の言いたいことは？ Discourseに定期的に携わっていても、Discourseの柔軟な設定により、情報はほぼ無限です。カスタマイズしすぎている（ただし、悪いことではありません）ため、元のフォーラムの姿とはほとんど似ていません。したがって、スタッフがソフトウェアについてすべてを知っていないとしても、それは問題ありません：彼らは異なる部分に特化しており、それぞれの分野の「専門家」として相談することができます。
「いいね！」 4
mae:
バスケットボールのコーチにテニスを教えてもらいますか？どちらもスポーツですが、実際にその競技をやっている人に教わりたいはずです。ここでも同じことです。私が資格を持っていない答えを間違うよりも、適切な専門家をご紹介したほうが良いでしょう。
ポジショニング、メッセージング、そしてDiscourseのストーリーをどのように伝えるかについては終日話し合えますが、深い技術的な事項は実際に構築している人たちに任せるべきです。
ああ、可能性は低いことは承知していましたが、「目から鱗が落ちるような」という説明に始まり、Flarumのマイグレーションスクリプトに関する奥義やCloudflare Tunnelのセットアップについて何か知見を披露してくれるのではないかと期待し始めていました。
ただし、投稿の後半でおっしゃっていたように、専門的なDiscourseの知識を活かせる可能性のある、技術以外の分野も確かに存在します。少なくとも、当初の「自信の欠如」というフィードバックの対象には含まれていないようです。
企業は、コミュニティへの参加を期待する部門や人物について現実的である必要があります。画一的なポリシーや一律の期待は、小規模な組織であっても適切でない可能性が高いです。包含戦略を評価する際の重要な問いとして、「この部門や人物にとって、参加する利益は何ですか？」という質問は確かに鍵となります。
会話にそぐわない追加だと思っていました。
「いいね！」 7
HAWK
2026 年 7 月 29 日午前 8:26
16
あなたが何を言っているのか気になり、AIが関与していないはずなので、どこで導入されたのかを確認するために会話の最初から読み返さなければなりませんでした。でも、そうすると…
混同していました！なぜ「技術的な」という言葉を追加してしまったのか全くわかりません。読み返してみると、あなたが言っていたことを誤解していたとしか思えません。ここでは誰もマーケティングの質問をしたことがないので、誰もが製品知識を持っていると提案しているのだと思いました。私のミスです。
「いいね！」 5
「製品知識」と「技術的な製品知識」は、タマネギの異なる層だと考えています。マーケティングや営業担当者は、おそらく「製品知識」を持っているはずだと思っています。なぜなら、ほとんど知識のない製品をマーケティングや販売しようとするのは、かなり制限がかかるだろうと想像できるからです。
「どの部門か」と一緒に考慮すべき実用的な点として、参加を期待するスタッフの数、その活動度、そしてコミュニティが彼らを健康的に受け入れるのに十分な規模かどうかがあります。コミュニティの文化はそれぞれ異なり、コミュニティと企業の組み合わせによっても微妙に風味が異なるため、これは文脈に大きく依存します。しかし、20人、30人、50人のアクティブなチームメンバーをコミュニティに投入した場合にどのような影響があるかを考える価値はあると考えています。スペースを支配することが意図していることかもしれませんが、そうでない場合、この潜在的な結果に注意を払うことで、影響を和らげるのに役立つと思います。例えば、彼らの関与が最も適切に注がれるべきスペースやカテゴリを明確にしたり、コミュニティがまず発言するのを待つべきタイミングについてのガイドラインを設けたりするなどです。
これらのチームメンバーをコミュニティにオンボーディングするのを助けるためのサンドボックスとして、プライベートカテゴリを設定することも、移行をスムーズにするのに役立ちます。公共の領域に飛び込む前に、メディアにこっそり慣れることができる、少し離れた場所です。引用の仕方、投票の作成方法、既存のフォーラムの礼儀について学ぶなど、簡単なことから始めて、自信を持ち、全員が初心者のように突入しないようにします。
また、参加を義務付けるかどうかという問題について…個人的には、可能な限り避けるべきだと感じています。参加を強制されていると感じる人々は、しばしば間違った雰囲気を放ち、ぎこちない/不自然な/傲慢な相互作用は、長期的には害を及ぼす可能性が高いです。関与の利益を説得することが、より望ましい動機付けになると考えています。（ただし、これもコミュニティや企業文化に大きく依存します
「いいね！」 2
ええ、それは恥ずかしかったですが、正直言って大した問題ではなく、すぐに立ち直りました。
）場合、その人のことを実際に心配に思います。質問のテーマについてあまり詳しくなくても、助けようとします。そのような状況では、素早く検索して、彼らを導くことのできるドキュメントがないか確認します。彼ら自身でもできることですが、どんなに絶望的でもRTFM（Read The Fine Manual：マニュアルをよく読む）しない人は多いです。あるいは、バグの場合、それを再現しようとします。
