イベント「Increments、Qiita の振り返りと未来への挑戦 2017」レポート（詳細編・後半）
後半はQiitaの機能や思想、海野によるIncrementsの今後の取り組みなどについて語られました。
2017年6月26日にイベント「Increments、Qiita の振り返りと未来への挑戦 2017」が開催されました（イベントの簡易レポートとしてダイジェスト編レポートも公開しています）。
昨年はあまりユーザーのみなさまとの接点を持つような機会が得られなかったといった反省もあり、これからはIncrementsやIncrementsのサービスを知ってもらうための情報発信をしていこうという思いからイベントを開催するに至りました。Incrementsの歩み、Qiita（キータ）やQiita Team（キータチーム）の開発思想、これからの取り組みについて紹介していく内容となりました。前半に続き後半をお届けします！
文／Qiita Zine編集部
＜目次＞
プログラマー人口
前半はQiitaの振り返りとして、Qiitaが生まれてこれまでの流れをお話しいただきました。後半は昨年から今年にかけてQiitaで起きたことをベースに、僕らの考えを伝えたいなぁと思っています。最初にQiitaの近況について報告させていただきますが、会場からもお話しをうかがっていきたいですね。Twitterのハッシュタグ（ #workq ）も表示するのでぜひつぶやいてください。
さて、現状についてですが、数字的にはQiitaは順調に伸びていて、ユーザー数、投稿数どちらも増えています。こちらのグラフに出てるのが月間のユニークユーザーなんですけど、いま300万人を超えています。国内のITエンジニアは100万人前後と言われているので、まあ使われているのかなというところです。ただ、登録者数は十数万人なのでまだまだアプローチできていない層もたくさんいます。
Qiitaの月間ユニークユーザーは2016年に約300万人となりました。
僕は2014年にIncrementsに入ったんですけど、Googleアナリティクスで見られるリアルタイムにアクセスしている人数が、2014年当時は300人くらいだったのが、いまは6800人になっていて、かなり増えたなぁと感じています。というところで、去年から今年にかけてのQiitaに関する話をしたいのでお二人ともよろしくお願いします。
突っ込んでいいですか？ まず国内のITエンジニアの人数が100万人前後ってのがあまり正確じゃないと思うんですね。プロダクトを出す時は、きちんとターゲットとなるマーケットサイズを確認することが必要なので、以前調べてみました。
QiitaはいわゆるB2CのWebサービスですけど、一般の方を対象にしたものではないんですね。基本、ソフトウェア開発者を対象としているんです。このプログラマー、もしくはソフトウェア開発者の国内人口なのですが、調べると100万人いないんですよ。多くて80万、おそらく50万くらいなんです。
これ、どうやって調べるかっていうとIPA（独立行政法人 情報処理推進機構）が出している『IT人材白書』がありまして、（明確にプログラマーの人数が掲載されていないため）プログラムするだろうという人たちを足し算して、だいたいマックスでも80万ちょっとくらい、そんなにいないから50万くらいなんじゃないかと予想できるんです。
そして、同じように国内のプログラマー人口を知りたがっている会社との情報交換を行わせてもらって、「御社はどれくらいだと推定していますか？」と聞くと、だいたいブレてはいなくて、50万から多くて80万くらいってところです。
で、このプログラマーっていう呼称の問題っていうのが、コミュティガイドラインでも話題になったところですね。「オレはプログラマーじゃないからQiitaを使っちゃいけないのか」という。
その通りですね。僕とかやおっち（※）とか、やはり周りにWebのエンジニアがたくさんいる環境なので、ついそういう人たちを思い浮かべてしまうこともあるのですが。実際にはもっと広い範囲で捉えなければいけないんですね。では、さっき言った通り、去年から出した機能の代表的なものを並べてみました。
※：IncrementsのCEO海野のこと。社内ではyaotti（やおっち）と呼ばれている。
Qiitaの機能と思想――ストックといいね
2016年以降にリリースされた主な機能。
どの話にみなさん興味ありますか。スライド機能の話を聞きたい人は？ 人気の投稿について話を聞きたい人は？ Contribution（コントリビューション）v2、v3って、完全に社内用語だから、誰も分からないね（笑）。Contributionってあるじゃないですか。v2って呼んでるのは、前は完全に投稿のストック数だけで見ていたのを、編集リクエストに対して、少し足し算できるようにしたものです。v3は、いいねの機能に合わせて、その部分を少し変えたところがあります。
そういったContribution周りのところの思想だったり、背景だったりを知りたいな人はどれくらいいますか？ それと関係して、いいねとストックの話を聞きたい人はいますか？ Advent Calendarの今後の話を聞きたい人は？
Organizationもちょっと改変したんですけど、その話を聞きたい方は？ ガイドラインの話を聞きたい方は？ 結構いますね。Qiitadon知ってますか？ Qiitadonの話を聞きたい方いますか？ 結構いますね。
いいね、ストックとガイドラインの話が多かったですね。
その辺は思想的なところがあるから、その話をしましょうか。思想の柱であるやおっちはどういう想いで、どう改変したか聞きたいですね。
前半でQiitaの最初のころにあった機能の話をしたんですが、ストック機能もかなり初期に作った機能で、意図としては、技術情報をQiita上で見た時に、後で読み返したいと思ったものとか、これは将来的に使えそうだと思ったものを保存しておくためのものとして、ストック機能を入れたんですね。
ストック機能を提供して、その後にどんどんQiitaが伸びていく中で、いろいろな人が「ストック機能を自分は使わないけれども、いいなと思ったものにフィードバックとか、記事を書いた人へのフィードバックとして使う」という声もどんどん出てきてですね。コメントするほどではないけれども、「見たよ」とか「良かったよ」ということを伝えるという意図で、ストック機能を使う人たちが増えてきたというところがありました。
「自分用に保存しておく」というのとは、違った文脈で使われることが増えてきたので、それを分けられた方が、投稿者としてもたくさんフィードバックもらえるようになります。読む側としても、これはいいねっていう、良かったよという反応を返す機能と、これは自分用に取っておきたいという機能を分けることで、もっと使いやすくなるんじゃないかと。
なかなかその切り分けっていうところは着手できていなくてですね。実は昔、LGTMってプログラマーのコミュニティで使う単語がありますけど、LGTM機能という名前で、いいね機能っぽいのを出したことがあったんです。
ちょっと名前がギーク過ぎているので、あまり使われなかったので閉じちゃったんですけど、それをもう一度やり直すというところで、投稿者にフィードバックを返すための機能として、いいね機能を提供したのが去年でした。
そうした思想で２つの意味を持っていたストック機能というところを切り分けようというところで、いいね機能とストック機能に分類しました。
Twitterもそうだったと思うんですよね。ファボ（Fav）って言われていたものが、たぶん保存用といいねの意味を２つ持たせていたのを、それを明確に変えたというところで、混乱もしたんだけれど、そういうのがありましたね。
確かにストックって、ユーザーに聞いてみると「長い記事を後で読もうということで、一時的にストックを付けました」という使い方をしている例も結構、見受けられて、それと記事に対する評価を一緒にするのは、設計上ちょっと無理があるなってことで、分離をしたというのが実際のところです。
それから、今年の初めにユーザーにヒアリングして、その時に「ストックはあんまりしない」という人がいらっしゃいました。なぜストックしないかと聞いてみると、ブラウザのブックマークなり、EvernoteにQiita以外のソフトウェア開発の情報をまとめて保存していらっしゃるんですね。
このようなことが明らかになってきた中で、保存するという機能と評価するという機能が一体化しているのが本当に良いのかと考え、分離させました。
まだ多少混乱しているかもしれないんですけど、基本的にサービスのUIを変更すると文句しか言われないんですよ（笑）。新しいUIに満足されていたりする方って、わざわざ「これいいね」ってことを、あまり言ってくれないんですよね。Twitterとか見ると、本当に凹みます。
この時、変えたことを後悔するべきなのか、それともひたすら我慢するのがいいのかの判断は難しいです。実際、いいねとストックを分離させたときは、多少UIを変えたんですよね。フィードバックを見てのイテレーションを繰り返してました。
それからContributionに関していうと、思想的には、やおっちさんにぜひ話して欲しいんだけれども、編集リクエストをContributionに入れたっていうのは、思想面で非常に大事なところなんですよね。
Qiitaの機能と思想――編集リクエスト
Qiitaの特長的な機能として挙げられる編集リクエスト。
そうですね。Qiitaの特長的な機能のひとつに編集リクエストがあるんですけれども、これをどう考えて、どのような思いでできたかというとですね。Qiitaの記事は、誰か個人が「こういう技術のノウハウがあるよ」とか、「こういう問題が起きたらこういう風に解消するといいよ」というところで、ある程度、その人の経験に紐付いて書かれた記事がどんどん増えていくわけです。
でも技術情報ってバージョンアップとか、やり方は常に変わり続けるので、その場合にどうしても情報が古くなるんですね。このバージョンではこの情報は使えないですとか、新しいバージョンになってしまったらこれはそのまま使えなくて、こうしなくてはいけないということがよく起きるんです。
それを例えば読んだ人がわざわざコメントで「新しいバージョンではこういう風にした方がいいですよ」っていうのは、なかなかできないなと感じていて、一方で読んだ人にとっては、この情報はこのバージョンでは使えないというところが分かっているので、そこを何とかして投稿に取り込みたいという想いがあって、編集リクエストという機能を作ったんです。
なので、コンテンツは最初は書いた人のものということになるんですけど、それがある程度時間が経っていくと、それを使う人たちであったりとか、参照した人がこういう情報もあるっていうところを、何かしら価値を付加できるはずです。そこでQiitaならではの機能として、編集リクエストという形で、コンテンツがどんどん良くなっていくようなコミュニティによって、コンテンツがブラッシュアップされたり、鮮度を保つたの機能を入れたんです。
そうした思想なので、編集リクエストとして記事にさらに新しい情報だったり、価値を与えた人も、Qiitaや技術領域に貢献したという風に考えるのが正しいのではないかと考えました。編集リクエストの貢献をした人にも、Contributionという数値がちゃんと付与されるようにしたのが、Contribution v2ですね。
編集リクエストっていうのは、最初に聞いたときすごくいいなって思ったんですね。特にやおっちさんの説明がよくて、まあいま言ってくれたことの言い換えになるんですけど、個人でブログをやられている時っていうのは、書いた内容に対する責任っていうのは、その作者がずっと持ち続けることになるんです。
例えば私の経験でいうと、ブラウザのオフラインストレージに対する、いろいろな制限に関して、Firefox/Chrome/IEで比較する記事を以前自分のブログに書いたことがあるんですけど、標準がまだどんどん変わっていて、1年後に見たときに全然正しくなくなってるんです。まあその時はGoogleのChromeの担当だったので、もう一回1年後にやるわけですよ。でも今やってくれって言われたら正直厳しいわけです。
もしそれがQiitaの記事だったら、詳しい人が「この内容の間違っているところを直しましたよ」ってリクエストを送ってくれて、私が同意してそれをアップデートしたら、常に最新の仕様に即した状態になっているわけです。
コンテンツに対しての正確さとか最新状態になっているかというのをただ1人が負うのではなく、コミュニティ全体できちんと負っていきましょうっていう考え方は、非常に素敵だなと思うんです。これがもっと使われるようになったらいいですね。
今日来ている方ってみなさんQiitaのアカウント持ってると思うんですけど、編集リクエストを使ったことある方ってどれくらいいらっしゃいますか？（10人ほど手が挙がる）あ、すごい。2、3人しかいないかと思った。
それは自信なさすぎますよ（笑）。
いや、実際の数値はそんなもんなわけですよ。
まだまだ機能的に分かりづらいところはあるので。でも、これは嬉しいですよね。
思想があって、それに基づいた機能があったとしても、まだまだ使いにくいところがあるわけですが、これはじっくり育てていけるといいかなって思いますね。
記事がやっぱり個人の方のブログ的な、個人の所有する記事であるというニュアンスがすごく強いので、それに対して編集リクエストを送るのはハードルが高くて、誤字脱字程度であれば使えるけど、それ以上の踏み込んだことはしにくいって話はよく聞いたりします。
よくあるのが、試してみた系の記事で、その通りやったけど動かなくて、調べてみたらここ間違ってるって気付いた場合。それ編集リクエスト送ればいいんですよね。そういうネタ結構あるんですよ。