なぜ、エンジニアはコミュニティに貢献するのか 〜Qiita Engineer Festa 2022 Online Meetupレポート
2022年7月29日、昨年に引き続き2回目となる「Qiita Engineer Festa 2022 Online Meetup」が開催されました。
Qiita Engineer Festa 2022とは、Qiitaにおける記事投稿キャンペーンとライブ配信イベントから構成される複合型イベントのことで、今年はスポンサー企業のテーマやQiita運営のテーマごとの豪華プレゼントのほか、Organization対抗戦やライブ配信イベントが用意されました。
本記事では、その中のいちコンテンツであるライブ配信イベントの様子をレポートします。当日は、「Rubyの父」と呼ばれるまつもとゆきひろ氏によるスペシャルコンテンツをはじめ、QiitaTop ContributorによるトークセッションやQiita運営チームによる各種情報発信など、Qiitaコミュニティにとって非常に充実した時間となりました。
目次
Rubyを通して見たこの30年間の変化（まつもとゆきひろ氏）
イベント冒頭の講演を担当したのは、島根県松江市の名誉市民であるまつもとゆきひろ氏。日本人で最も有名なプログラマーと言っても過言ではない人物です。今回は、プログラミングのレジェンドから、「Rubyを通して見たこの30年間の変化」というタイトルでお話をしていただきました。
登壇者プロフィール
誰かの「大丈夫」を信じてはいけない
Rubyの開発がスタートしたのは1993年2月24日。一緒に開発を進めたまつもと氏の先輩が記録を残していたことから、正確な開発開始日が分かったとのことです。2023年2月でちょうど30年を迎えることになり、本記事の読者の中には、まだ生まれていない方もいらっしゃることでしょう。
1993年は、ちょうどバブルが崩壊した直後で、その頃のまつもと氏はシステム開発会社の社員として社内システム開発に従事していたと言います。社内のエンジニアは生産性を高めるためのツール開発を行うチームだったのですが、売上に直結する部署でなかったことから、景気の悪化に伴ってチームそのものが解散に。しかし、それが結果としてRubyの開発のきっかけになったとまつもと氏は振り返ります。
「当時の社内の開発環境のスペックがこちらで1台200万円くらいするマシンでしたね」
当時では珍しく、全台がイーサネットに接続されており、その上で、マルチメディアメール（現在でいう添付ファイル機能）が搭載されたメールシステムや、設計用の絵を描けるようなツールなどの社内向けツールを開発していました。全社同一OSで同一CPUという、まさにホモジニアス（均質）なソフトウェア環境だったと言えます。
「そんな中ソースコードを見たら、ネットワーク越しに構造体をバイナリコピーしていたんです。大学の頃にそれはやっちゃいけないことだと教わっていたので、これ、同一OS、同一CPU、同一コンパイラだったら問題ないですが、違うアーキテクチャが入ってきたら破綻しますよね？』と先輩に言いました。すると先輩は『我が社のシステムはホモジニアスであることが前提となっているので、想定しなくても大丈夫』とのことでした」
その時はそのまま放置していました。しかし、数年後、違う系統のOSと別CPUのマシンが入ることになります。具体的には、SystemⅤ系やIBMのPowerPC、リトルエンディアンなどがやってきたことで、結果、当時の社員総出で対応に追われたと言います。
「ここからの教訓は、誰かの『大丈夫』を信じてはいけない、ということです。想像もつかないようなことが未来では起こるものなので、長期的予測はそもそも困難なのです」
大事なことは「ツールの継続性」
まつもと氏は「特に重要なことがツールの継続性」だと強調します。
「商用ツールの罠ということで、ソフトウェアの寿命が長い場合は特に要注意です。10〜20年使われる可能性を考えると、サードパーティー製を使う場合、何かあったら自分でメンテするという心意気がないと困る可能性があります」
ソフトウェアの寿命は想像以上に長いです。たとえばIBM社が開発した再構造化拡張実行プログラム（REXX）言語について、設計者であるマイク・カウリショウ氏は、開発から20年経ったソースコードに対するフィードバックがきて驚いたという逸話を語っています。「自分はちょっとしたプログラムを作ったつもりなのに、それが20年間も動いてしまった」と。
「考えてみたらRubyも一緒で、まさか30年後もメンテしているとは思いませんでした。予想外です。ソフトウェアの未来に関する予想は、だいたい外れます。そのため、できるだけ変わらないもの、変わりにくいものを押さえておくのが肝要かなと。長く生き残ったものは、これからも長く続く可能性が高いと思います。
オープンソースソフトウェアの場合は、ソースコードが手に入っているので、何かあったときには最悪、自分でメンテできる点がメリットです。たとえばLinuxやFreeBSDは長くメンテされているので、明日なくなることは心配しなくて良いし、いざとなったら自分で中身を見ることもできます。鳴り物入りの商用ソフトの方が、長期的なロックインとしては危ない気がしますよ」
容量が増えれば「当たり前」も変わっていく
変化という観点で考えると、ハードウェアの容量は飛躍的な進化を遂げています。先ほど、まつもと氏が挙げた「当時の開発環境（SONY NWS-831） 」と「現在のまつもと氏が使っている開発環境」について、それぞれのマシンスペック を比較したものが以下となります。
| 1993年 | 2022年 | |
| CPU | 68020 | Ryzen9 3900XT |
| クロック | 16MHz | 4.0GHz（250倍） |
| コア数 | 1 Core | 12 Core（12倍） |
| メモリ | 8MB | 64GB（8,000倍） |
| ハードディスク | 156MB | 1TB（6,400倍）※これ以外に外付けも沢山あり |
「思えば40年前、まだ僕が中学生くらいだった時は240KBのフロッピーディスクを使っていて、当時はそれが無限の容量に思えたわけです。でもそんなことはなかったんですね。今は数テラの外付けハードディスクを使っているので、240KBなんて秒で吹き飛ぶわけです。つまり、容量が増えれば『当たり前』も変わり、バランスが変化することになります」
まつもと氏によると、この30年間で「2番目くらいに」大きく変化したものが「Thread（スレッド）」の価値だったと言います。
「Rubyは早い時期からThreadを提供していたのですが、シングルコアだった時代にThreadを実装したときは、アルゴリズムの表現手段としてThreadを考えていました。正直にお伝えすると、その時はパフォーマンスというものについてはさほど気にしていませんでした。でも現代においては、Threadは処理を複数にオフロードして全体的なパフォーマンスを向上させるために使われることが圧倒的に多くなったわけです。そうなると、RubyがもっていたThreadやFiberはシングルコア時代の設計になっているので、あまり向いていないことになります。よってRubyの場合は、Ractorという新しいデータ構造を使ってマルチコアを使えるようにした経緯があります」
1995年は「プログラミング言語の当たり年」
では、最大の変化は何だったのか。まつもと氏は「アプリケーションドメインの変化だったと思う」と語ります。
「Rubyを開発した時、スクリプト言語として開発しました。それが、Webアプリケーションに徐々に使われ方がシフトしていきました」
冒頭でお伝えしたとおり、Rubyを開発し始めたのは1993年ですが、実際にインターネットで発表したのは1995年です。現在は60万行ほどのプログラムコード量になっていますが、当時は数万行程度だったと言います。この1995年という年は「プログラミング言語の当たり年」だと、まつもと氏は続けます。
「これを言ってるのは私だけなのですが（笑）、たとえばJavaのソースコードが正式に公開されたのは1995年ですし、PHPが誕生したのも1994年〜1995年あたりです。JavaScriptの公開も1995年ですよね。このようにRubyも含めて、インターネットを構成する言語のうち重要なものがたくさん登場したのが1995年なのですよ」
アプリケーションドメインの変化に付随したものとして「これらのプログラミング言語へのニーズの変化も大きかった」とまつもと氏は言います。1995年といえばMicrosoft社より「Windows95」が出た年。これによって、サードパーティーのライブラリやハードを購入せずともインターネットに接続できるようになりました。
「それに伴って、ザ・インターネットを使う人が大分増えたので、Webアプリケーションへのニーズも増加したと言えます。当時はCGIと呼ばれていましたが、動的なWebページが爆発的に増えはじめたのも1995年で、こうやってRubyもこの領域でものすごく伸びたことになります」
そんな経緯を知っているまつもと氏だからこそ、現在はまた変化のタイミングに来ているのではないかと言います。
「最近ではGoやRustなど、様々な新しい言語が出てきています。これらの言語は静的な型をもっていて、ほとんどがネイティブコンパイラで、システムプログラミング領域を狙っているという特徴があります。そう考えると、また同じくらい大きな変化があるかもしれないと思っていて、いま静的言語が大流行だから未来永劫続くというのは予想が硬直していると思います。動的言語なんだけれども静的型チェックはあって、抽象度の高いハイレベルな言語がもう一回流行る可能性があると思います。そのときにまだRubyがいて、また人気が出るといいなと思っています」
30年の間を見ても「質的な変化」については意外と小さい
このように振り返りながら考えると、この30年間で起きた変化は、ハードの要領については飛躍的ではあるものの、「質的な変化については意外と小さい」とまつもと氏は意見を述べます。
「たとえばコアになっているUNIX API システムコールみたいなものは、私がまだ20代だったときと同じものがあるので、劇的な変化というわけではないですね。1990年代には、UNIXみたいなOSを作ろうという動きが盛んだったわけですが、結果としてほとんど生き残れませんでした。UNIXでいいやと。意外と変化しなかったなとという感想です」
プログラミング言語についても、PerlやPython、PHPなどはしっかりと残っており、またCOBOLについても、場所によってはまだしっかりと現役で帳票出力をしています。つまり、プログラミング言語も30年のスパンであっても意外と生き残っているものです。
「ハードの変化についても、容量こそ劇的に変化していますが、そうは言っても連続的変化ではあって、物理的実態は違うが、ソフトウェア的なアクセスとしては変わらないと感じています」
そんな中、まつもと氏が30年間で唯一「不連続だった」と感じるのは、Webアプリケーション領域だと続けます。
「30年前は、アプリのほとんどがインストール型のデスクトップアプリケーションでした。でも現代では、ほとんどのケースはWebで済みます。ソフトウェアの作り方が大規模に変わり、非常にエポックメイキングな変化だと思います。
私が社会人になった1990年代くらいは、汎用なアプリケーションプラットフォームを配り、それに対してスクリプトやプログラミング言語を送りつけるとアプリが動くという世界をみんなで夢見ていたし、そういう商品がたくさんあったわけです。でも、それって誰も使わないし面倒ですよね。
冷静になって考えると、元々はWorld Wide Webを見るためのツールだったブラウザが、今や汎用のWebアプリケーションプラットフォームになったので、90年代の夢は形を変えて叶ってしまったということになります。
それってすごいことだなと思いますが、逆に言うとそこまでなんです。30年かけて何が変わったかと言うと、実はそんなでもないなと。もちろん、来年くらいにいきなり量子コンピューターが実用化することもゼロではないでしょうが、変化は意外とゆっくりなんじゃないかなと思います。したがって、未来は決して怖くはありません！」
「未来は怖くない」
最後に、まつもと氏は参加者へメッセージを送り本セッションを締め括りました。
「未来は予想できませんが、現在には対処できます。RubyのRactorも、マルチコアに対応すると言ってから何年もやって、ようやく実装した経緯があります。つまり、継続は力なりということです。
大きな変化としてオープンソースでのソフトウェア開発もあると思うのですが、私が大学生だった頃にはすでにフリーソフトウェアの変化が起きていました。つまり、世界の片隅にあったものが一気に広がることが起きるわけです。未来はすでにどこかにあるが、均一に分散していないので、あるところにあるということだと思います。
繰り返しお伝えすると、未来は怖くないです。未来は予測できないものですが、現在起きている事象には対処できます。だからこそ、継続することが大事だよということです。本日はありがとうございました」
Qiita運営からのお知らせ
続いては「Qiita運営コンテンツ」ということで、直近のQiitaによるアップデート機能や取り組み内容の紹介と、今後の方向性の発表、そしてプレゼントテーマ企画・Organization対抗戦の結果発表などが行われました。
登壇者プロフィール
今期の各種取り組み
まずは直近の取り組みとして、2つのアップデート機能の紹介と、コミュニティ関連活動の紹介がなされました。
直近のアップデート機能としては、まずはQiitaトップページのリニューアルです。より発見体験を得られるUIを目指し、以下の観点での改善・機能追加等が目下進んでいる状況となります。
● ナビゲーションヘッダーの追加
● Qiitaコンテンツの集約
● UI改善
また、記事投稿のエディターについても、より記事を書きやすくする為に、以下の改善や機能の追加等をしたベータ版が提供され、イベント前日（7月28日）に正式版がリリースされました。
● 同時スクロールの位置同期
● 複数行のインデント
● 検索機能の追加
さらに、Qiitaユーザーの顧客体験向上を考え続ける「CX向上グループ」も、新たにQiita社内で発足しました。前述の機能をはじめ、Qiitaで記事を書いたり読んだりする体験をよくすることが、Qiitaの未来ひいてはエンジニアの未来を豊かにするという思想のもと、以下の取り組みを進める組織体となってると、清野氏は説明します。
● エディタの改善：執筆体験を良くするため（先述）
● タグのミュート機能：表示するもの・しないものを選べるのも、気持ちの良い利用体験につながる
● パフォーマンスアップ
● メールマガジンやヘルプなど、あまり手を入れられていなかった箇所の改善
● 皆さまからの意見をもとにした機能開発・改善（GitHub DiscussionsやTwitterでのコミュニケーション・ユーザーインタビューの実施等）
LGTMをいいねに戻す
もう1つ、Qiitaの利用体験に関わる大切な発表として、2020年3月より新たに実装された「LGTM」ボタンが、従前の「いいね」ボタンに戻ることも発表されました。
これについて清野氏は、以下のように説明します。
「LGTMを実装した当時は、プログラミングに関連しないような投稿にもいいねが集まって評価に乗るということが顧客体験の課題としてあったので、しっかりと記事を読んでリアクションをしてほしいという意図を込めてLGTMに変更しました。
一方で先日、2021年4月にQiitaのコミュニティガイドラインを改定し、投稿して良い記事の多様性を拡大したことに併せて、現在のQiitaのスタンスとLGTMの役割が少し食い違う状態になりました。LGTMの場合、レビュー承認のニュアンスが含まれることになり、現在のQiitaでユーザーが行えるリアクションとして最適な表現になっていないということです。このような課題を解決するために、Qiita社内で議論を重ね、LGTMをいいねに戻すことにしました」
いいねがLGTMに変更された経緯、及びLGTMがいいねに戻される経緯について、それぞれ以下の記事で詳しく説明されているので、ぜひ併せてご覧ください。
▶︎Qiitaの「いいね」が「LGTM」に変わります（2020年3月12日）
▶︎Qiitaの「LGTM」を「いいね」に戻します（2022年7月29日）
QiitaTop Contributorによるトークセッション
続いては、Qiitaユーザーランキング上位の方々によるパネルディスカッションが行われました。エンジニアがコミュニティに貢献する理由や、Qiitaの良い点・リクエストなどのテーマについて、ユーザー目線でのパネルディスカッションが行われました。
登壇者プロフィール
『 一歩先行くJava入門 (翔泳社、共著、絶版）』や『Java入門 雑誌連載 (ASCII出版netPC、廃刊)』の著者。
なぜエンジニアはコミュニティに貢献するのか
――最初のテーマは「なぜエンジニアはコミュニティに貢献するのか」ということで、なぜ皆さんは無償で強制されることがなくとも貢献活動をするのか、その理由や気持ちを教えてください。
広木 : 昔の製造業などを考えると、資源が有限で、情報は隠した方が得するという要素が少しあるわけです。ですが、ソフトウェアの業界はコピーすればするほど増えるものなので、情報をオープンにする方が得することが多いのかなということを、オープンな活動が増える度に感じています。
実際、自分たちの事業もオープンなところから生まれていて、LinuxやSQLなどオープンなものに支えられて自分たちの食い扶持があるなと体験していると、それに対して還元するのは当たり前だという感覚になると思っています。
ただ現状は、無償であることの限界も様々な形で来ていると思っていて、無償だからいいというわけではなく、情報を共有すればするほど増えていく感覚が染み付いてる界隈だからこその行動なんだろうと思います。
――たとえばQiitaで考えると、しらかみゅさんは他の人の記事への編集リクエストを多々行っていらっしゃると思うのですが、それはなぜ行われているのでしょうか？
しらかみゅ : もともとソフトウェアエンジニアをやっていたところからサイバーセキュリティ業界に入りました。そこで、Webプログラムを多く書くことになり、その中でC#やJavaScriptを勉強する必要があったため、私の場合はQiitaさんの記事で随分と勉強させていただきました。
それに対してお返しをしたいと思ってのことです。一方でオフ会などに参加すると「最近のQiitaは記事の質が落ちてきている」という声を聞くことがあって、それはどうなのかと思い、記事を読んで修正した方が良いと思った内容のものについては編集リクエストを出させていただいています。Qiitaのガイドラインにも「みんなで質を高めていこう」という趣旨のことが書いてあるので、それを実践している形です。
――ミノ駆動さんも、どういう原動力で活動をされているのでしょうか？
ミノ駆動 : Twitterでは怨念じみたことばかり呟いていますが（笑）エンジニアの風通しをよくするためなんじゃないかなと思います。僕は現状4社目ですが、会社はエコーチェンバー効果が特に強いと考えていて、先進的な技術に比べて遅れていたりチープな技術を使っていても、その中に入っているとなかなか気づけないことがあると思っています。外に出ていくことによって自分たちの使っている技術が妥当かなどの評価がよりできるようになると思うので、健全な技術を進展させていくのにとても必要な活動かなと考えています。
――貢献をした結果として得た価値や新しい体験としてはいかがでしょうか？
広木 : 知り合いは増えますよね。このイベントもそうですし。純粋に楽しいし、それがきっかけになって仕事の機会につながることもあります。あと記事にすると、「これ読んでおいて」というのをやりやすいんですよ。しっかりと解説する時間がないときでもすぐに情報を共有できるので、何か書きたいことや伝えたいことがある場合は、整理をして再利用性の高いパーツとしてアウトプットしておくと、日々のふとした時に使えると思います。なので、反応の有無は置いといて、アウトプットはすごく役に立つことだなと思っています。
しらかみゅ : 同じく、自分が書いた記事を見た方から講師依頼があったり、知り合いは増えたり、あとTwiterで転職のお誘いを多くいただきます。
ミノ駆動 : 自分の場合は本の執筆の糧になったというのが一番大きいです。あと、すごく自信につながるところがあったと思います。Qiita記事を見ていると、自信なさげに書かれている記事が結構見受けられて、もっと自信を持って書けばいいのにと思います。僕自身、3年前にWeb系へ来る前はずっと十数年間組み込み系プログラマーでした。Web系で果たして自分の技術は通用するのか自信はなかったですが、Qiitaさんの記事でバズったりすると、通じるところがあるんだと自信を持てたので、そこも大事なところだと思います。
――貢献活動をする場としてQiitaを運営させていただいているのですが、エンジニアにとって最適な場所になれているのかという点について、率直にご意見を伺いたいです。まずは、先ほど発表した「LGTMをいいねに戻す」という話を聞かれて、正直どのように思われましたか？
しらかみゅ : LGTMは、自分が本当に使えると思った記事に対してだけ押すようにしているのですが、それが「いいね」になると、たとえば内容についてじゃなくても「頑張ったね」という意味合いで押すこともありそうなので、押す機会は増えるだろうなと思います。私的にはポジティブに捉えていますが、技術記事以外にいいねが集まりやすくなって、前みたいな課題がまた出てくる可能性もあるのかなとは感じました。
――そこは運営としてもすごく議論しているところで、その一つの取り組みとして「タグミュート機能」をベータ版として公開しています。特定のタグがついたコンテンツを非表示にできるので、一人ひとりが読みたいと思える記事を読んでいただけるような取り組みを進めています。ミノ駆動さんと広木さんはいかがですか？
ミノ駆動 : 自分の場合は「いいね」でいいと思います。LGTMって僕の印象では、Web系の方言みたいなものかなという印象がありまして、組み込み系からWeb系に移った時に初めて知った言葉でした。組み込み系でもQiitaさんの記事を見にくる人がいらっしゃるので、LGTMが通じるのかなという疑問を感じたところはありました。であれば、普通に「いいね」でいいかなと思いました。
広木 : 僕は、あまり意識していなかったです（笑）大々的に発表しているのが不思議な印象で、ラベルによってクリックの仕方が違うよねというのはあると思いますが、読んで「いいね」と思ったら「いいね」を押すで別にいいんじゃない、くらいに思っています。ユーザーからいろんなフィードバックをいただけているということは、それだけ多くの方が使っているということで、いいことだなと思います。
――ありがとうございます。最後に、今後のQiitaへの期待や、こうなっていってほしいといったご要望があれば教えてください。
ミノ駆動 : 記事を投稿する際に、パターン別のテンプレがあってもいいんじゃないかなと思っています。現状記事を投稿するときは、まっさらな状態から書かないといけませんが、わかりやすい文章を書くのって、慣れていないと骨の折れる作業ですし、要点をまとめるのは難度が高いと思っています。たとえば「背景→課題→解決するための仮説→効果」といったテンプレがいくつか用意されていれば、もっと投稿が活発になるんじゃないかなと思いますね。
――たしかにQiitaだからこそできることですね。社内に持ち帰ります！続いてしらかみゅさん、いかがでしょうか？
しらかみゅ : Qiitaの使い方的なガイドラインがあまり読まれていないのかなと思っていて、たとえばURLだけ書かれているような記事もあったりして「Qiitaはブックマークじゃない」と思うこともあるんで、導入部分を手厚くした方がいいのかなと思います。
――広木さんはいかがでしょうか？
広木 : 大きく分けて3つくらい、あったらいいなという機能や要望を考えてみました。
まず、1つ目は技術的なシェルのコマンドやコードがあると思うのですが、CLIから実行したりダウンロードできる機能があったら嬉しいなと感じました。
「zx」という、JavaScriptをシェルの代わりに使えるGoogleのOSSがあるのですが、マークダウンの形式で保存しても実行できてすごく便利なんですよね。READMEを書いておくと、そのREADMEがそのまま実行できるみたいに。Qiitaも同じように、書かれた記事が何かのチュートリアルとして実行可能になったり、インタラクティブに実行しながら経過を見れたら嬉しいなと思っています。
2つ目は細かいところですが、やめ太郎さんやミノ駆動さんみたいな方々は例外として、大半の記事ってタイトルを見ただけでは誰が書いたかわからないと思います。だから、その記事が結局誰の記事だったかに気付ける人が、ブログと比べると相対的に少ないと感じています。そんなに目立たせる必要はないと感じますが、どこの誰が書いている記事なのか、もう少し意識しやすい作りになってても嬉しいのかなと思っています。求職のために使っている人もいたりすると思うので。
そして3つ目ですが、最近のQiitaは「ちゃんとしたものを書かなきゃいけない」というプレッシャーが大きいなと感じます。どんなサイトも記事などを書いている人たちによって支えられていると思うのですが、書いたものに対して「自分にとって関係がないものはノイズだ」と言うコミュニティになってしまうと、誰も書きたくなくなってしまうと思うんですよね。
書く人を大事にして、訂正や議論ではない「くだらない話」をする人に対しては、「ダサいよね」とする空気をもうちょっと出した方がいいなと思いますし、Qiitaとしてももっと強く打ち出してもいいかなと感じました。。
Qiita代表挨拶
最後に、イベントの締めとして、Qiita株式会社 代表取締役社長の柴田 健介氏よりメッセージが送られました。
僕たちはQiitaを運営している存在ではありますが、Qiitaのコミュニティそのものは会社の持ち物ではなく、本日ご登壇いただいた方々やイベントをご覧いただいている皆さま、普段Qiitaに記事を投稿したり読んだ理してくれている皆さまによるアウトプットや行動によって成り立っていると本当に思います。
そして、そういう「パブリックなものである」という認識を持ちながら、自分たちがコミュニティへどうやって貢献できるかを考えながら行動しています。今日のトークセッションでいただいたお話や、普段のQiita Discussionsの場でいただくようなご意見をしっかりと運営として受け止めながら、Qiitaをより良い場所にしていきます。今しがたのディスカッションから出てきたご要望についても、さっそく社内のSlackでリアルタイムで意見を出し合っている状況です。
今後もQiitaとしては、本日の発表内容やイベントの場を含めて、コミュニティに貢献できるようにやっていきたいと思っていますので、今後ともQiitaを宜しくお願いいたします」
なお、Organization対抗戦については株式会社ゆめみが4635LGTMを獲得して1位となりました。こちらは以下の公式ページで詳細が発表されています。
https://qiita.com/official-campaigns/engineer-festa/2022
また、記事投稿キャンペーンの受賞記事については以下にまとめてあるので、こちらも是非ご覧ください。
https://blog.qiita.com/qiitaengineerfesta-2022-presents/
イベントアーカイブ動画（Qiita公式チャンネル）
編集後記
今回も盛りだくさんのコンテンツとなりました。スペシャルコンテンツを担当されたまつもと氏は、別イベントでもレポート記事を担当させていただいたのですが、毎回含蓄のあるお話で大変勉強になります。「DXだ、トランスフォーメーションだ」と言われる昨今ですが、経験に裏打ちされた「30年間で技術における不連続変化は実はほとんどない」というお話は、私たちに「まあ落ち着きなさい」とおっしゃっているように感じた次第です。またTop Contributorの皆様によるパネルディスカッションも、改めてコミュニティに対する貢献のあり方を考えさせられる内容となりました。「エンジニアにとって再利用性・汎用性の高い情報が集まる場」に向けて、引き続きQiitaの動向を注視していきたいと思います。
取材／文：長岡 武司