0060 号 巻頭言
初稿：2019-08-18
ruby-jp とコミュニティのあり方
Rubyist Magazine 第 60 号をお届けする。
まず最初に触れておきたいこととして、Ruby Prize 2019 のノミネート者の推薦募集を行っている。
推薦は自薦・他薦どちらも可で、8 月 23 日が締め切りとなっている。興味のある方は上記URLの「ノミネート者の一般推薦はこちらから」から応募していただけるとありがたい。
20 年以上も昔のことになるが、大学での計算機実習でメールとネットニュースを使ってみるという演習があった。 今にして思えば、それがインターネットアプリケーションに触れた最初の機会だった。
ネットニュースには学科内のローカルなニュースグループがあり、そこで学内の人とコミュニケーションがとれた。 当時はまだ Web が広まってないどころか、そもそも World Wide Web の存在を知ったのはそのニュースグループだった、という時代である。 インターネット自体がまだ一般的ではなかったその当時、初めて使うネット上のコミュニケーションサービスはとても新鮮だった。 暇に任せて他愛のないことを書いたり、どうでも良かったり良くなかったりする議論をしたりしていた。 時には荒れ気味になることもあったが、そもそも書いた人が特定され、しかもまったく知らない人ではなく同じ学科の学生だったこともあり、 それほどひどい事態にはならなかった。とはいえ、今読み返してみる機会があればきっと赤面ものだろうという発言もあった気がする。 ログはすでに失われているので、確認できないのが残念でもあるが、それ以上に闇に葬られていて安心、という思いもある。
あれから時は流れて 2019 年、Slack に「ruby-jp」というワークスペースができた。 このワークスペース自体は新しく生まれたものではない。以前は RailsDM というイベント用に使われていたものが、再利用する形で使われている。
表に出たのはおそらく 7/31 の下記のツイートが最初のもののようだ。
RailsdmのSlackを使って、初心者がWebアプリケーションを書くにあたっての、コードレビューなどのサポートみたいのをボランティアでやるので、興味ある方は👇からjoinしてください
それから 1 週間あまりたち、8/7 の時点で参加者数が 1000 人まで増えた。 8/15 現在では、参加者数は 1,400 人以上、チャンネル数は 160 以上の比較的大規模なワークスペースになっている。
もともと Ruby のコミュニケーションの場としては、各種メーリングリストがあり、これは現在でも続いている。 中でも ruby-dev メーリングリストは https://bugs.ruby-lang.org/ との相互乗り入れが行われ、頻繁にメールが届く。 とはいえ一時期と比べると、あまり活性化できていない。いろんな理由があるとは思うが、メールではない形でのコミュニケーションの需要が高いのは事実だろう。
その他、ネット上で Ruby について情報収集・情報交換できるサービスとしては、掲示板サイト、IRC、ブログ、Qiita、Stack Overflow や teratail などの質問サービス、あるいは Twitter や Facebook などが思いつく。 ruby-jp のワークスペースはそれらと比較しても大変活発であるとは言えるだろう。 企業内の Slack やユーザグループ等の閉じた枠組みであれば活性化している場所は他にもありそうだが、誰でも参加の門戸を開いているしくみとしては重宝する場になりつつある。
もちろん、今後の課題もあるだろう。 誰でも参加は可能とされていても、登録しなければ一切閲覧できないというしくみは一面閉鎖的にも見える。 また、Slackの特性上ログが流れてしまうため、素のままではアーカイブとしては使うことができない。
しかしながら、必ずしも全て公開するのが最適解とは言い切れないのは、否定できないところではある。 ある程度狭く、後腐れなく書き捨てられるプラットフォームの有用性というものもある。 冒頭でローカルなニュースグループについて書いたのも、そのような場所からネット上でのコミュニケーションを始めたことがその後の糧になったという個人的な体験があるためである。 さらに現在、もっともオープンで活発なプラットフォームは Twitter だと思っているが、一方で数年前と比べても、Twitter が荒れたり剣呑な雰囲気になりやすくなっている感覚はある。 プラットフォームとして誰にでも使いやすいものであるとは言い難い側面もある。 そんなこともあり、ruby-jp のような場が求められていることも理解できる。
その上で、ruby-jp などで得られた知見や成果物は、最終的にはオープンな場、誰からでもアクセスできるところへのアウトプットされることも期待したい。 Ruby はそもそもがオープンソースソフトウェア・フリーソフトウェアであり、オープンで自由な文化を背景としてここまで成長してきた。 とはいえすべてがオープンでなければならないという道理もないわけで、パブリックなものとプライベートなものが相互に影響しあい発展することが現実的な落とし所だろう。 新しいしくみで生まれたものが、参加者の成長はもちろん、これからの Ruby の発展に役立つきっかけになることは素直に期待したい。
他にも過去ログのライセンスや取り扱いといった問題なども起こりそうだが、それらを含めてルールやマナーといったものが、今後参加者の間で作られていくのだろう。 このようなポリシーには正解はない上に、参加者自体がトラブルに巻き込まれ、そもそも何が問題で何が解決なのかを自分たちで考えるという体験を担うことが必要なのかもしれないとも思いつつある。 言い換えると、しくみの中にあらかじめ失敗する要素を組み込んでおき、「適切」に「失敗」することが望ましいのではないか。 こう言うと、安全安心を優先するしくみが多い中、車輪の再発明のように一見無駄なことにも思われたり、場当たり的な措置に思われたりするかもしれない。とはいえ、過去の知見や既存の風習を踏襲しようとするよりも、その時代とその参加者にあったルールが生まれ、育てていくのは、一定のコストをかける価値もあるだろう。
いずれにしても、たいへん興味深い試みであると思っている。今後の発展を見守っていきたいし、また参加者・運営双方に対して致命的なトラブルが起きないことを望みたい。