Qiitaコミュニティガイドライン

えーっとそろそろ時間切れなんですが、ガイドラインの話をしなかったら、めちゃくちゃ怒られる気がするので、先にガイドラインの話をしましょうか（笑）。

編集リクエストの話だったりとか、Contributionの改善の話とも関係はしていて、記事の情報をユーザーの間でどういう風に評価してもらうか、どのように扱うのか、というところでガイドラインがあります。

ネタ的なところでいうと、あれ私の最後仕事だったんですよね。辞める前にちゃんと公開してから辞めよう思ったら、辞めた後にいろいろとご指摘をいただくことがあって、どうしようって感じだったんですけど。

その時、私はGoogle I/Oでアメリカにいたから、みなさんが対応してるのをみて、アタタタという感じでしたね。ガイドラインは多少誤解を生んでしまった部分はあるんですけど、新しい何かを決めたつもりはなかったんですよ。

今まで実際にみなさんがこういう形で使っていただいてますよねというものだったり、もしくは、報告いただいたものを社内で判断して、作者の方に連絡する時の判断基準になっているものが暗黙のうちにあり、多くのユーザーにも理解されるべきことを明文化しましたということだったんですね。

ただ言葉の定義だったり、あえて言語化した時に、言語って非常に冷たいものなので、これによってIncrementsは何かやろうとしていると捉えられてしまった部分があったのが、反省です。ガイドラインで何か新しい規制を作ろうとしたりってことはなかったんですね。

誤解を生んだプログラミング関係の情報に限りっていうところも、よく見ていただくと分かる通り、プログラミングに関する情報共有をしようということがサイトに書かれていたりとか、いろいろなところに書いてあるのを、あらためて書き起こしたものに過ぎなかったので、正直それがそんなに誤解を生むとは思わなかったんです。

でも言語化すると、先ほど言ったように、非常に冷たい形で無機質になってしまったんですね。それは反省しています。今までと基本何も変えていなかったんですが、暗黙のものだったのをきちんと明文化することや、その背景にある、創業者であるやおっちの「こういう世界を作りたい」と言ったところを明確にするのが大事だと思っていたんです。

その作り上げたい世界はIncrementsだけでは作り上げられませんから、一緒に作っていただける人たちに、やって欲しいことややって欲しくないことを書く必要があるのではないかというのが、ガイドラインが必要となった根本です。

実は、コミュニティガイドラインはいろいいろなサービスを参考にしたんですね。コミュニティガイドラインって基本、禁止事項しか書いていないんです。でも、Qiitaのガイドラインは、みなさんが楽しく学び合い成長できるような場になるということで、やって欲しいことをちゃんと書いているんです。

禁止事項だけじゃなくて「ぜひこういうことを積極的にやってみませんか？」っていうのを投げかけているところに、無機質にならないように魂を込めたつもりだったんですけれど、それが通じきらなかったのかな、というところはあるかもしれないですね。

ガイドラインについては、いろいろなフィードバックをいただいた中で、僕が個人的に刺さったのは、ガイドラインも大事だけど、それを体現した状態にQiitaを持っていくのが先だろうという厳しいツッコミをいただいて、まあそれは確かにそうなんですよ。

さっきの編集リクエストの話なんかもそうですけど、やっぱり僕らの中でも、ガイドライン的な内容を外に向けて発信するというのをこれまであまりやってこなかった訳ですよね。なので、そこを、ちゃんと明文化するってことで、僕らもどういうものを作りたかったのかって、一本軸が通るのかなという風に思っていたんですが、その辺ちょっとまだまだ足りないと思っています。

言葉だけって怖いんですよね。だからそこは必要以上にケアしないといけないなって思いました。ガイドラインの話は、いまの話だけじゃ納得できないとか、聞いてみたいことがある方もいるんじゃないかと思うので、時間がもし許されるんだったらTwitterに書き込んでいただいてもいいですし、手を上げていただいてもいいので、意見を聞きたいです。

ほかにガイドラインに関しては、プログラミングの定義が曖昧という話もありましたね。これは我々も悩んでいるところもあって。最初は我々もプログラミングに関するtipsっていうのが増えていく中で、いろいろ人に使っていただくようになって。

プログラミングに代わる言葉は何だろう？

 

悩んでいるので、この後、懇親会で酒飲みながらみなさんに聞きたいんですよ。要はプログラミングじゃなくてもいいとは思うんだけど、コミュニティってどっかでスコープが必要だと思うんですね。

何でも書いてもいいですよって言ったらただの汎用プラットホームになるんですが、我々はスコープを作ることによって、情報密度を高くしたり、コミュニティとしてより話しやすい雰囲気ができるのではないかと思っています。ただ、問題は、そのスコープを表現する言葉を持ち得ていないのです。何をやる人を対象にしていて、どういう内容は書いて欲しいというのに適した言葉を持っていないんです。

今回、プログラミングって言ってしまうとあまりにも狭すぎていて、多くの人に誤解を与えるし、みなさんが書きにくいということは分かりました。なので、プログラミングって言葉じゃない方がいいだろうっていうのは見えてきているんだけれど、じゃあどう呼べばいいんだろうっていうのは、まだ悩んでいるところです。

うまく対応する言葉が見つかっていないですね。ソフトウェアなのかもしれないですし、コードとか再実行できる何かかもしれないし。そこをうまく表現できていなくて。ただ元々の思いとしては、プログラミングは汎用性が高くて、その知識はある環境だけでなく、いろいろな環境で使えます。

その汎用性が高い情報を共有することで、プログラミングを効率よくできたり、バグに何時間もハマることなく、自分のサービスや自分の開発の価値をどう作るかってことに、もっと頭を使えるじゃないかと。そういう思いがあってQiitaを始めたんです。

汎用性の高い情報をQiitaで共有して、個人にとどまらず、コミュニティとしてメンテナンスしていくのがプログラミングにとっていいんじゃないだろうかっていう、そういう思いで始めているので、当初は狭義のプログラミングを的にしていました。でもそれ以外の周辺領域でもそうした汎用性の高い知識ってのはいろいろあるというところで、まだカバーしきれるようないい表現が見つかっていないですね。

ほかにも、プログラマーが喜ぶ内容ではなくて、プログラミングに関係する内容にしてくださいっていう言い方も、誤解を生んだと聞いています。分かりやすい例では、プログラマーが好きな食事のレシピを上げますと言われた時に、さすがに違うだろって我々は思って、それは辞めてくださいとかそんな感じだったんですね。ただ、この例も含めて、どこが境界なのか分からないんですね。

結局、我々もいろいろ追求したんですけど、綺麗な線引きはどうしても難しいですね。例えば政治やスポーツなどまったくプログラミングに関係ない記事が書かれてしまった場合に、一旦記事を限定共有投稿の状態にするという処理を取らせていただいて、プログラミングに関係のあることを投稿するコミュニティなので、そういう風に修正して再度公開してくださいねとお願いすることがあります。

この点をよく「消された」と言われてしまうんですけど、結局その線引きがどこになろうと、ユーザーのみなさんにとってはすごく辛い対応じゃないですか。書いた記事がクローズされてしまうのはすごく辛い。まぁ実際には消えるわけではなくて、URLを知っている人は見られるという感じではあるんですけれども。

なので、結局その線引が難しいのであれば、例えば非公開という対応以外に、Qiita内での評価や見え方でコントロールするようにするとか、まだいいアイデアは見つけられていないんですが、その対応自体の改善もセットで考えないといけないのではないかと思っています。

downvote（よくないね）を実装しない理由

そうですね。いま東峰さんが話してくれたのも思想的で、ほかの例も含めて言いたいんですけど、基本的にIncrementsの人たちっていうのは、インターネット的な性善説に基づいているんですね。

例えばあるふさわしくないと思われる記事があったとしても、こういうような記事をコミュニティが求めているので、これに書き直してもらえませんかという形での対処となるので、記事は削除していないんです。一旦、非公開化ということにして、作者の方と相談する形になり、変更していただき、再公開という流れにするのが理想なんです。

確かに、「ユーザーの方から報告を受けて、中身を確認したところ、確かにかくかくしかじかの理由でふさわしくないと思われます」とお話しすると、分かりました方針が違いますとなって、独立した他のところに記事を書かれる方もいます。一方、ふさわしい形に記事を変更する方もいます。

似たような例が、いいねの機能に関連して、たまに意見が来るんですけど、downvote（よくないね）の話です。downvoteはもしかしたら将来的に入れるかもしれないんですけど、私がいるときにも社内で何度か議論したんです。

downvoteって基本的にあまりイメージ良くないというのもあるんですけど、それ以前の問題として、記事にしても、コメントにしても、両方ともQiitaは変更が可能なんです。ですから、良くないって言われたものが、その後にいいねに変わる可能性があるんです。

でも一度、downvoteされてしまったものは消えない。リセットされない形になってしまいます。ならばdownvoteではなくて、どこが良くないかをコメントで書き、その人に変更を促して、いい記事を育てていけば良いと思うんですね。それはコメントでもいいし、編集リクエストでもいい。

一緒に育てていきましょうということをやる時に、downvoteっていうのはネガテイブな方向にしか進まないんですね。お互いがお互いに刺し合う形になってしまう。そうではなく、一緒にいいものを作ってく時には、downvoteではなくて、編集リクエストを使いやすくしたり、コメントでそういうことを言い合えるような、そういった文化であろうということで、downvoteを入れない判断をしたんです。

だから、これも同じように性善説に則って、一緒にコミュニティやコンテンツを良くしていきましょうというのがあるので、思想的な部分では大事なものなのかな、と思います。

今はチェックして合わないと思うものには、こちらからお願いしています。downvoteではないけど、編集リクエストがたまってたら、編集したほうがいいですよというのをこちらから突っついてあげたりなど、民主主義的な、分散管理的な方向でうまく回せるといいんですけど。

機能がまだちょっと追いついてないので、現状ではスタッフがチェックして、適切ではないと考えてるものは編集をお願いするという体制になっています。

Stack Overflowは、ライバルなんですが、めちゃくちゃ良くできてるんです。やっぱりスコープの線引きがしっかり決まっているのと、コミュニティマネジメントって言われている民主化が進んでいて、社員だけがやってるんじゃないんですね。

コミュニティに対して貢献がある人にバッジシステムでちゃんとレベル付けがされていて、上のレベルの人たちが、自分たちでコミュニティを運営するという民主的なシステムができ上がっているんです。Stack Overflowはそこが非常にうまいです。

そうですね。参考になるものがたくさんありますね。

>> 次ページ　今後のロードマップについて