2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
まつもとゆきひろ氏:じゃあ、始めます。Rubyを作り始めた記録が残っているんですが、その当時勤めていた会社の先輩にあたる人が、本を書くという話になったんですね。
その時に、彼は『プログラミング言語を作りながら学ぶオブジェクト指向』という本を書くと言ってきたんですね。編集の人と話をしていく中で「どういう企画でどんなのを書く?」という話になったそうです。
彼は、私がプログラミング言語に非常に興味を持っていることを知っていたので、「じゃあ、まつもとにプログラミング言語を作ってもらって、自分が原稿を書いて、それを合わせて本にしよう」という話を持ってきました。
もともとプログラミングが大好きですし、プログラミング言語を作りたいなとずっと思っていたんですね。これはいい機会だと思ってですね、その企画に乗ることにしました。
がんばって言語を作り始めたんですけど、しばらく経ってから先輩からメールで連絡がきて「企画は没になった」って言われて(笑)。
その本は日の目を見なかったんですが、すでに(Rubyを)作り始めていたので、ここで捨てるのも惜しいなと。ちょっと始めちゃったし、ということで続いたのが、本ではなくRubyだったので、非常に稀有な運命なわけですけれども。
そういうこともあり、その時の先輩と「新しい言語を作る企画の名前を何にしようか?」という話になった時に、当時Perlという言語が非常に人気が高かったんですね。Perlは真珠なので、なにか宝石の名前から取ろうと思って。
Ruby、Coral(サンゴ)とか、いくつか候補があったんですけれども、Rubyのほうが4文字で短くて、美しいし、Rubyのほうが高いので。
(会場笑)
価値があるのでRubyにしようと思ったんですね。
その名前が決まったのが1993年の2月24日。コミュニティではその日をRubyの誕生日と呼んでいます。その誕生日が2023年で30年ということで、2023年は「RubyWorld Conference」は15年、Rubyそのものは30年という、節目の年に当たるわけです。
そう思って、「30 Years of Ruby」というタイトルで提出したんですけども、考えてみたら「RubyKaigi」でも同じテーマで話していたんですね。
(会場笑)
なんかちょっとマンネリになる。同じ話を繰り返す講演者もいますが、私も時々やっちゃう(笑)。
きっとこの話は、来週行われるRubyカンファレンス(「RubyConf 2023」)でも話すんですけど。
(会場笑)
マンネリは良くないなと思って、RubyKaigiとは違う話をしようと思いました。
何かというと、過去、歴史から学ぶ教訓についてちょっと話そうと思います。
ご存じの方もいると思いますが、私自身、プログラミング言語が高校生ぐらいの時からすごく大好きで、プログラミング言語を勉強する中で調べるのもすごく好きだったんですよね。世の中に存在するいろいろなプログラミング言語を調べるのがすごく好きだったんですよ。
その中でおもしろい機能があったら、「いつか自分でプログラミング言語を作って、この機能を自分の言語に入れたい」みたいなことをずっと思っていたんですよね。
それを結集したのがRubyなので、そういう意味で言うと、私自身は「言語オタク」と呼んでもいいんじゃないかなと思います。
私は高校時代を鳥取県の米子市で育ったのですが、1980年代前半の話なので、周りにプログラミングをする友人がぜんぜんいなかったんです。プログラミングに興味がある人は当時すごく少なかったんですが、でも確かにいたんですね。コンピューター関係の雑誌とかも販売されていましたし。
プログラミングに興味のある半分ぐらいの人は、プログラミング言語にも興味があるだろうと思っていたんですね。
プログラミング言語に興味がある人の10人に1人ぐらいは、プログラミング言語を作りたいと思っているに違いないと思っていたんです。後に、高校を卒業して大学に入って、私の見積もりはだいぶ甘かったということに気がつきました。
実際に、プログラミング言語を好きな人はそれなりにいます。今でもJavaやPythonがありますよね。JavaScriptやPHPなどいろいろなプログラミング言語があって、それぞれのカンファレンスにたくさんの人が参加するので、プログラマーの人はプログラミング言語に興味があるんですね。
なんですが、「じゃあ、自分のプログラミング言語を作りたいという人はどんぐらいいるか?」というと、10人に1人と私は思っていたのですが、100人に1人どころか、1,000人に1人もいなかった。大学に入ってその事実に気がついた時にはもうだいぶ手遅れで、いつか(プログラミング言語を)作りたいなという気持ちは止められなかったんですね。
いずれにしても、私のプログラミング言語への興味、関心、愛が今のRubyにつながったと言えるんですが、例によって私の見積もりはいつものようにすごく甘かったということですね。
なので私自身は、Rubyに限らずいろいろなプログラミング言語が大好きなんですね。そういう雑学が大好きなので、まずは特に有名でないプログラミング言語の雑学から、教訓を引き出して今日は話したいと思いました。
ちょっとみなさんにおうかがいしたいんですが、みなさん、世界で最初に作られたプログラミング言語は何かご存じでしょうか?
ほとんどの方は、1954年に作られたFORTRANというプログラミング言語を思い出すと思うんですね。1954年より前の時代には、コンピューターをプログラムするために、アセンブラもなかったので、手でバイナリを書いて、それを入力するんです。私は大学の演習でやったんですが、どうやって入力するかというと、トグルスイッチが8つあって、パチパチパチとやって、ビットのオンとオフを書いて、9番目のスイッチをパチンと書くと、その該当のbitを書き込むというシステムになっていたんですね。やめてくれという感じですけども(笑)。
人間は当時バイナリでプログラミングしていたんですね。それはあんまりだろう、非人間的だろうということで、数式を含む表現をコンピューターが解釈するバイナリに変換するコンパイラという技術が誕生したのが、この1954年なんですね。
ですがこの時は、今まで人間がやってきた数式をコンピューターが理解できるバイナリに変換する技術だったので、これは人工知能であると言われたんですね。AI時代なんですよ。コンパイラはAIだったんだ(笑)。
それがみなさんの知っている歴史なんですが、実はそれより前にプログラミング言語は存在していたんですね。
それが1942年。第二次世界大戦中に作られた、Plankalkül、ドイツ語で「プランカルキュール」と発音するらしいですね。この時代には、まだプログラミングという言葉が存在していないんですよ。
「Plan」は日本語の「プラン」と同じで、「kalkül」は「計算」という意味なので、これは「計算計画」という単語らしいです。僕はドイツ語がよくわからないんですけど、これをもってプログラミングすると言っていたらしいです。
このPlankalkülをデザインした人は、コンラート・ツーゼというドイツのエンジニアの人で、当時彼は、「Z3」という名前の……ドイツ語でも「ゼット」ですね。「ゼットスリー」……「ゼットドライ」と言わないといけない(笑)……という名前のコンピューターを作っていたそうです。「Z1」「Z2」もあったそうです。
このコンピューターのためのプログラミング言語であるPlankalkülを、当時は設計だけされていたんですが、代入文があります。まぁ、当たり前っちゃ当たり前ですけど。if文もあります。ループもあるので、基本的にチューリング完全なんですね。
当時、まだFORTRANも持っていなかった構造体もあります。サブルーチンもあります。配列もあります。だんだんおかしくなりそうだぞ。アサーションがすでに存在していました。例外処理機能がありました、1942年に。
続いて、目的指向実行、つまりPrologとかがやるような実行機能があったと言われているんですね。「これ、オーパーツか?」という感じですけど(笑)。時代を無視している感じがするんですが。
しかし、1942年から1945年にかけてPlankalkülは設計されてレポートが書かれたんですが、そのレポートは誰にも注目されることがありませんでした。
実際にPlankalkülの言語仕様の仕様書が発表されたのは、それからずっと後の1972年ですが、それまで誰の眼にも留まりませんでした。このあたりでね、このあたりでFORTRANに追い越されているわけですね。残念。
さらに、Plankalkülのコンパイラが最初に実装されたのは、1998年でした。Rubyより新しい。世界で最初のプログラミング言語だったはずなのに。
このことから学ぶことができるのは、アイデアはすばらしいかもしれないけども、アイデアだけでは十分ではないということですね。みんなが使えるような実用的な実装が存在していて初めて意味がある。
インターネットのサービスもそうなんですね。最近はなくなりましたが、昔私がプログラミングをするということだけが知られていた頃、話し掛けてくる人がいたんですね。「私にはすばらしいビジネスのアイデアがあるんだけど、君、実装してくれないか?」とか「利益は折半ね」みたいなことを言うわけですよね。お前はアイデアだけかよという感じがするんですけれども(笑)、全部断ったわけなんですけれども。
アイデアだけだと意味がないんですよね。実用的なアイデアは最初から完成している必要はなくて、段階的に成長していけばいいんですね。
アイデアは重要だとよく言われますが、それだけではなくて、きちんと実装してみんなに使ってもらって、それがみんなと一緒に成長していくことが重要であるということを、最初の教訓としてお伝えしたいなと思います。
(次回へつづく)
「RubyWorld Conference 2023」が開催されたほぼ同時期に、島根県では「Ruby biz Grand prix 2023」が開催されました。 Ruby biz Grand prixは、プログラム言語「Ruby」を活用して開発されたサービスや商品に対して表彰されるビジネスコンテストです。第9回目となる今回は計29事例の中から、大賞2点と特別賞3点、ソーシャルインパクト賞4点が受賞しました。
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには