0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エンジニアよ、カンファレンスに行こう!~Qiita Conference 2024 Autumn:まつもとゆきひろ氏の基調講演(勝手に)レポート

Last updated at Posted at 2024-11-23

はじめに

11/14-15にかけて、Qiita Conferense 2024Autumnがオンライン開催されました。皆さん、参加されましたか?

かくいう私は、参加予定で申し込みはしたのですが、残念ながら時間が合わず(夕ご飯の用意とか後片付け、仕事の残処理などで、嵐のように忙しい時間帯なんすよ・・・)、後日メールで連絡をいただいたYoutubeの録画で拝見しました。

私が特に見たかったのは、Rubyの生みの親ことまつもとゆきひろ氏の基調講演、そして東京都知事選に出馬された安野さんの基調講演の2つ。

視聴してみて、非常に多くの学びを得たなあと満足感でいっぱいになりました。カンファレンスって、いいよね。

カンファレンス、みんな参加してる?

こういうエンジニア向けの技術カンファレンスや勉強会って、全国各地で頻繁に開催されていますが、実際に参加している人って結構限られている気がします。

私のように、最先端技術とか割と縁遠い感じでひっそり働いている"よわよわ"エンジニアにとっては、技術カンファレンスってそもそもハードルが高い。参加したくてもなんか怖いんですよね。

ぶっちゃけ、私みたいな"よわよわ"エンジニアじゃなくても、毎日の仕事が忙しくて時間が取れない、仕事終わりは何も考えずに休みたい!など、さまざまな理由から、「カンファレンスに参加したい気持ちはあるけど、参加できない」って人、意外と多いんじゃないでしょうか。

せっかくどれも素晴らしい講演だろうに、そして興味があるのに、視聴できないまま流れていってしまうのは実にもったいないことです。良い技術、役に立つ技術は、未来のエンジニアたちのためにも広く共有されたほうが絶対いいのに。

いきなり自己紹介

申し遅れました、私はエンジニア兼ライターをやっており、翔泳社様の媒体『Codezine』では技術カンファレンスのレポート記事を執筆しています。

もともと私はどちらかというと"意識低い"系のエンジニアでして、20年ほど前に文系新卒から仕事がなくて仕方なくエンジニアになり(就職氷河期の一番酷かったころ)、結婚を機に退職。その後育児が一段落したとき、たまたま今の会社の社長から「エンジニアやってみない?」と声をかけていただき、まさかの復帰を果たして今に至ります。

なので、最新技術使ってみようとかの意欲はどちらかというと低く、ChatGPTも出た当時「ふーんそういうのがあるのね?」ぐらいの関心の低さでした。

そんな"よわよわ"エンジニアな私ですが、ご縁があってCodezine様のレポート記事を担当することになり、生まれて初めてぐらいの勢いでカンファレンスを視聴しました。そして驚きました。

――こんなにも発見と驚き、ワクワクが得られるのか。技術の進歩ってすごい。何という激動の時代を、私たちは生きているんだろう。

仕事に直接関係がない話でも、1つの話を聞けば、必ずなにかの発見と気づきがあるのがカンファレンス。最新技術なんて興味ねえやと思っていた私でしたが、いくつものカンファレンスを聞いているうちに、「これからの時代、AI使えないと仕事にならない!やばい!」と焦り、大慌てでChatGPT課金ユーザーになりました。今では生活に欠かせない相棒になっています。

技術カンファレンスが、私の人生にとって大きな分岐点となったのです。

カンファレンスを文字化すれば、知見はもっと広がるはず

カンファレンスに参加したいけど、ちょっと無理。体力的に、あるいは気力的に。アーカイブ残してくれるのもありがたいけど、長いし難しかったりするから開けない。――そんな人、いませんか?(まあ過去の私なんですけど)

そんな人に役立つのが、文字コンテンツ。いわゆるレポート記事、上記でご紹介したような私の仕事です。文字ならサラッと流し読みできるので、動画だと視聴する時間がなくても、なんとなく流し読みするだけで内容を把握できますよね。タイパに非常によろしい。

アーカイブ化と文字化を同時にすることで、よい技術や知識がより広がっていく思うんですよ。それを若手エンジニアが吸収すれば、日本のエンジニアリングはきっともっと向上するし、そうすれば私たちの生活ももっと豊かになるはず。

だからこそ、もっと多くの技術カンファレンスが、あるいは勉強会やLTなんかの有益なコンテンツが、文字として残ってほしいと切に願っています。そして私の仕事も増えるといいな。

生のカンファレンスはいいぞ

とはいえね、やっぱりカンファレンスは"ナマ"に限るんです。文字で読むより、圧倒的に自分で視聴したほうがいい。得られるものが、刺激が違います。

私のような"よわよわ"エンジニアでも、いや、"よわよわ"エンジニアだからこそ、生のカンファレンスにもっと刺激を受けるべきだと思うんですよ。ワクワクすっぞ。

だからぜひエンジニアの皆さん、積極的にカンファレンスに行きましょう。オンライン参加やアーカイブ視聴でもいいから、登壇者のナマの声を聞きましょう。実際に見て聞いて、なんなら現地の空気や熱気を感じて、そこでしか得られないものを持ち帰りましょう。

私は今のところオンライン参加しかしたことがないけど、いつか会場に行って、雰囲気も含めてナマで体感して、登壇者の姿を見て「おおお!」ってなりながら、技術の進化の素晴らしさを実感したいと思っています。

Qiita Conference 2024 Autumn基調講演(勝手に)レポート

多くのエンジニアの皆さんに、カンファレンスに参加してほしい。そんな願いの一つの導線として、今回のQiita Conference 2024 Autumnの基調講演の1つをレポート記事としてお届けしたいと思います。長くなっちゃったのでかなり短めにしましたが(それでも長い)、大まかな流れと言葉をここに残します。本当は安野さんの講演も書きたかったけど、長くなったので今回は割愛・・・。

ぜひ皆さんも実際に動画を視聴してみて、まつもとゆきひろさんのナマの声と姿を見て、その雰囲気や言葉の重みを体感してください。「すごいな」「おもしろいな」「ワクワクするな」って、時代の躍動感を感じられると思います。

プログラミング言語デザインケーススタディ|まつもとゆきひろ氏

世界中のソフトウェア技術者から支持を集めるプログラミング言語「RUBY」。日本生まれのこの言語は、まつもとゆきひろ氏が「人間にとって使いやすい言語」を目指して開発したものであり、登場から四半世紀を経た現在も進化を続け、愛され続けている。しかし、世界には数百を超えるプログラミング言語が存在する中で、長きにわたり利用され、進化を続ける言語はほんの一握りだ。その違いはどこにあるのか。技術者にとって魅力的な言語を生み出すためには、どのような視座が必要なのか。本講演では、まつもと氏が自身の経験をもとに、RUBYを成功に導いたデザインの背景や、言語を設計する際の具体的な考え方を事例として解説した。

言語デザインの魅力と課題

1993年に開発を開始したRubyは、現在も進化を続ける日本初の世界的プログラミング言語だ。その知名度を示す指標として、インターネット検索ベースの「TIOBEインデックス」では18位、Redditなどのオンライン議論を元にした「RedMonkランキング」では9位にランクインしている(カンファレンス開催当時)。数十万とも言われるプログラミング言語の中で、この順位は驚異的な成果と言えるだろう。

「プログラミング言語を作りたい」という願望を抱く開発者は多い。実際、言語を作ること自体は、基礎的なコンピュータサイエンスの教育の中で課題として取り上げられるほど、技術的には特別難しいものではない。しかし、まつもと氏は「成功するかどうかは別問題」と指摘する。世界中で利用され、進化を続ける言語を作るためには、技術以上の戦略と経験が求められるという。

残念ながら、日本人で世界的なプログラミング言語を生み出した実績を持つのは、まつもと氏が唯一の存在だ。これは、次のような理由に起因するとまつもと氏は分析する。

  • 言語を広める活動の不足:作って満足するケースが多く、利用者に使ってもらうための努力が少ない
  • 経験の蓄積不足:成功したデザインや戦略を学び、次に生かす文化が未成熟である

「言語を作ることは難しくない。しかし、それを世界で使われるものにするには、戦略と経験が必要だ」――Rubyの成功は偶然だけではない。まつもと氏は、試行錯誤の中で「うまくいった」要素が多く含まれていた点を強調する。その具体例をケーススタディとして共有し、新たな成功例を生み出すためのヒントを提示することが、本講演の目的である。

ターゲットの設定とRubyの設計哲学

まつもと氏は「万人向けのプログラミング言語は存在しない」と断言する。成功する言語を作るには、ターゲットとなるユーザーを明確に定め、そのニーズに焦点を当てた設計が不可欠だという。このターゲットユーザー像を「ペルソナ」として具体的に描き、それに基づいて言語を最適化することが重要だ。

Rubyのターゲットは、まつもと氏自身のような「プログラミングが大好きなプログラマー」であり、「高い生産性を好み、自由を求める開発者」であった。

「プログラミング言語を使うことで、一見偉大に見えるようなことを簡単に実現できて、『俺ってすげー!』という自己肯定感、ポジティブな感覚を持てるようなプログラミング言語が欲しかった。そういう言語があれば、モチベーションを高め、生産性を向上させるポジティブな循環を生むはずだ」(まつもと氏)

このような思想のもとで生まれたのが、さまざまなRUBY哲学だ。その一つが、「制約の少なさ」である。既存クラスのメソッドの上書きや追加が可能な「オープンクラス」など、開発者に自由を与える設計が特徴的だ。一方で、この自由は自己責任を伴う。「1 + 1 を 3 にするメソッドを書いても構わない」という例示は、Rubyがいかに開発者の意思を尊重する言語であるかを物語っている。

Rubyの根底にあるテーマは「エンパワーメント」、つまり開発者に力を与えることだ。柔軟性と自由、そして適切に設計されたツール群が、開発者に「自分がすごいことを成し遂げられた」という感覚を与える。まつもと氏は、「このポリシーの徹底こそがRubyの成功につながった」と振り返る。そして、それを可能にする基盤として、「ターゲットオーディエンスの選定」がいかに重要であるかを改めて強調した。

保守と革新のバランスの重要性

新しいプログラミング言語を作る際、全く新しい概念ばかりを詰め込むのは得策ではない、とまつもと氏は指摘する。その理由は、「ほとんどのプログラマーが、新しいことを覚えるのに負担を感じる」からだ。学習コストを考慮すると、既存のプログラミング言語に似た要素を取り入れ、「どこかで見たことがある」と感じさせる設計が重要になる。

しかし、既存の言語に似すぎていると、新しい言語を使う理由が失われてしまう。このため、保守的でありつつも、適切な箇所で新しい価値を提供する「革新」を組み込むことが必要だ。

まつもと氏は、「言語を作る人の多くは手段と目的を取り違えているが、ほとんどの場合、言語自体は退屈なもので構わない。それを使うことで何が便利で、どんな価値をもたらすかが重要だ」と指摘する。

Rubyは「エンパワーメント」を設計思想の中心に据え、開発者に力を与える言語として機能している。こうした哲学のもと、使い慣れた設計に基づきながらも、独自の革新を適切に取り入れてきたからこそ、多くの支持を得てきたのである。

長期的な視座――変わらない哲学、変わる設計

ソフトウェア業界の中でも、プログラミング言語の寿命は特に長い。まつもと氏は「10年経っても新参者と呼ばれる」と語り、言語設計においては、短期的な流行ではなく、長期的な視座が求められることを指摘した。例えば、GoやRust、Elixirなどの比較的新しいとされる言語も、実は登場からすでに10年以上が経過している。一方で、Rubyは30年以上の歴史を持つベテラン言語となった。

しかし、この間にプログラミングの流行は大きく変化してきた。1990年代はオブジェクト指向が主流であったが、近年では関数型プログラミングや型システムへの注目が高まっている。まつもと氏も「動的型付け言語が全盛期だった頃の議論が、今ではすっかり静的型付け寄りにシフトしている」と、20年間の流行の変遷を振り返った。

プログラミング言語の設計においては、流行に安易に飛びつくべきではないというのがまつもと氏の見解だ。「プログラミング言語の寿命は長い。流行に振り回されるのではなく、その本質的な価値を見極め、取り入れるべきものを選ぶ必要がある」――このアプローチは、時代の変化に対応しながらも、言語の特質や哲学を失わないバランス感覚が必要だということを意味している。

まつもと氏は「基本的には保守的であるべき」としつつも、「場合によっては大胆な決断が求められることもある」とも指摘する。Rubyの長い歴史の中でも、まつもと氏は新しいトレンドを注意深く観察し、言語の根幹を損なわない範囲でその利点を取り入れる努力を続けてきたのだ。

プログラミング言語の寿命の長さは、その設計者にとって課題であると同時に、設計の質を問う機会でもある。時代ごとのトレンドに柔軟に対応しながらも、言語の哲学や本質を守り続けることが、長期的な成功につながるだろう。

コミュニティが支える言語の成長

まつもと氏は、プログラミング言語が広く使われるためには「キラーアプリ」の存在が重要だと指摘する。言語の特性や利点を引き出し、「このアプリケーションを作るならこの言語」と人々に思わせるものが必要だという。

Rubyにとってのキラーアプリは2004年に登場したRuby on Railsだった。Ruby on Railsはその高い生産性と話題性で開発者の関心を一気に集め、これがRubyの普及を後押しし、言語としての人気を飛躍的に高めた要因となったのだ。

言語が普及し続けるには、キラーアプリだけではなく、活発なコミュニティが必要である。まつもと氏は「コミュニティは、個人の知識や発想力の限界を補うもの」と述べ、Rubyの成功もコミュニティの存在に大きく支えられていることを強調する。

まつもと氏は、「現在のオープンソースソフトウェアにとって、コミュニティは必須だ。**コミュニティがない、構成できないソフトウェアは生き残れない。**おそらく、商用プロダクトにおいても、活発なコミュニティが形成されなければ生き残るのは難しくなるだろう」と語る。

ビジョンがもたらす求心力

コミュニティの成長には、言語やプロダクトを支える哲学やビジョンが不可欠である。Rubyの場合、「楽しいプログラミング」や「自由と責任」などの理念が、その基盤となっている。この哲学が開発者にとっての指針となり、コミュニティ全体の求心力をドライブする原動力となるのだ。

まつもと氏は、「良い言語とは何か」を言語化し、その理想と現実のギャップを埋め続ける努力が、言語開発の本質だと述べる。このビジョンが明確で説得力を持つほど、コミュニティの結束力が高まり、結果的に言語やプロダクトの発展につながる。

「良いを定義し、それを言語化することがビジョンである。それがプロダクトを導き、コミュニティを形成する」

表面的な改善に留まらず、本質を見抜き、具体的な形に落とし込むことが重要だという。この哲学が、Rubyの進化と支持を支えている。

継続する力がもたらす成功

プログラミング言語の設計において最も重要なのは「継続する力」だ、とまつもと氏は強調する。Rubyは開発から10年もの間、注目を浴びることなく「泣かず飛ばず」だった。「10年かかって初めて、Rubyは注目されるようになった。それを乗り越えるには、続ける力が不可欠だ」

プログラミング言語の世界では10年はまだ新参とされるほど、寿命が長い。流行に乗ることも大切だが、それ以上に長期的な視点を持ち続け、改良を重ねる努力が必要だ。

ここまで解説してきた6つの原則――「ターゲットオーディエンスの明確化」「保守と革新のバランス」「長期的な視座」「コミュニティの形成」「ビジョンの提示」「継続する力」は、プログラミング言語に限らず、どんなプロダクトを作る際にも適用できる、とまつもと氏は指摘する。ターゲットの設定や革新性、コミュニティとの連携、ビジョンを持って継続的に改善を重ねることは、すべてのプロジェクトに共通する成功の鍵になると言えるだろう。

講演の締めくくりとして、まつもと氏は「明日から何かを作るときに、この6つの原則を活かして、ぜひ素晴らしいプロダクトを生み出してほしい」と呼びかけた。プログラミング言語に興味を持つ人々だけでなく、ものづくりに携わるすべての人にとって、まつもと氏の知見は未来へつながる重要な指針となるだろう。

技術カンファレンスはエンジニア全体の資産である!

Qiita Conference 2024 Autumn、まつもとゆきひろ氏の基調講演レポートをお届けしました。かなり短めにまとめてあるので、ぜひ実際に皆さんご自身が視聴してみて、一つ一つの言葉の意味を感じ、エンジニアとしての未来につながる「なにか」を考えるきっかけにしていただければと思います。

同時に、カンファレンスは素晴らしいけれど、時間がない、体力が続かないから参加できない人向けに、レポート記事などで残しておく取り組みも非常に大切だと思います。Qiitaも含めてカンファレンスや勉強会、コミュニティなどを主宰されている皆様、ぜひ多くの技術や知見を文字コンテンツとして残し、未来のエンジニアの学びへつなげてください。

私も今後さらにたくさんのカンファレンスに参加して知見を広げ、エンジニアとしてのキャリアに対する何らかの答え、何らかの学びを得られるように頑張っていこうと思います。安野さんの講演もレポート書きたいけど、時間あるかな・・・。

:hatching_chick:技術カンファレンスや勉強会などのレポート化に興味のある方は、お気軽にお問い合わせください!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?