2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
個人と企業とオープンソースの距離感(全1記事)
リンクをコピー
記事をブックマーク
まつもとゆきひろ氏(以下、まつもと):まつもとです。(スライドを示して)自己紹介はもういいかなという気もするんですが、こんなアイコンで活動しています。英語圏ではMatzと名乗っていますが、Rubyを作った人として知られています。
今日も「Rubyを作った人だったらオープンソースについてなにか知っているだろう」ということで呼んでもらいました。Rubyのおかげで、(私が)日本人で一番有名なプログラマーなんだろうなと思います。海外で「日本人のプログラマーを誰か知っていますか?」と聞いたら、たぶん私が最初に出てくることが多いんじゃないかなと思います。
当時はまだオープンソースという言葉がなかったので、Rubyはフリーソフトウェアとして公開していました。だから、オープンソースより古い時代からオープンソースをやっていたことになるので、経験者と言ってもいいと思います。
1995年にRubyをリリースしてから今に至るまでの二十数年ぐらいの間、オープンソースのプロダクトのオーナーであり、オープンソースに関する経験もあるだろうということで話します。
距離感ってすごく難しくて。空気を読むのと近い感じがあって、私自身も人間との距離感がなかなかつかみづらいところがあるんですけども。オープンソースと企業や個人がどういうふうに距離感を持つかを話す前に、そもそもオープンソースとは何かという定義からちょっと話してみようと思います。
「オープンソースの定義」という文章があるんですね。オープンソースという言葉が生まれた1998年に、同時にオープンソースの定義も生まれました。(スライドを示して)この文章にアドレスが書いてあります。opensource.org/osd.htmlというファイルですね。ここを見ると、オープンソースとは何であるかという定義が書いてあります。
オープンソースの定義は開発スタイルでもコミュニティでもなくて、ライセンスによって決まるんですね。そのライセンスが何を満たしているかということです。
まず、無償も含みますが、再配布が自由である。それからソースコードが公開されている。オープンソースという単語から、これだけをイメージしがちですが、実はほかにもいっぱいあるんですね。
派生物を許容する。差別を禁止する。追加ライセンスを禁止する。差別の禁止というのは、例えば今、戦争をしている国があるので、侵略をした国の人たちには使ってほしくないという条件をつけたくなる人たちもけっこういるかもしれませんが、そういう条件をつけると、オープンソースの定義から外れてしまうんです。
それから、特定の商品へ依存してはいけない。ほかのソフトウェアを妨害してはならない。技術的に中立なライセンスでなければならないとか。厳密にはOSD(The Open Source Definition)を見てもらいたいのですが、全部で10項目の定義があって、その定義を満たすライセンスをつけて配布されているソフトウェアが、オープンソースソフトウェアなんですね。
ということは、例えば誰が開発しているか、どんな組織が開発しているか、どういう動機で開発しているか、どういう開発体制で開発されているかは、ぜんぜん関係ないんです。ソフトウェアを公開する時に、どういうライセンスをつけて公開しているか。これだけが条件なんです。
ということは、オープンソースは、基本的にはライセンスによって決まるんです。そうすると、個別のプロジェクトごとにぜんぜん違うんですね。適切なライセンスであれば、意図や経緯は無関係です。ということは、背景も動機もモチベーションもさまざまなんですね。芝生の道をいろいろな人が歩いていくうちに、自然に道ができるような感じです。
オープンソースっぽい雰囲気のものって、例えば“バザール開発”みたいなことを言われたりします。それはオープンソースソフトウェアでなければならないわけでもなく、オープンソースソフトウェアの条件でもなんでもなくて。
オープンソースソフトウェアという体制があると、なんとなくそういうことをする人が多い。「こうやっている人はうまくいくことが多い」というだけで、オープンソースの条件の1つではないんです。だから、伽藍とバザールのバザール開発みたいなことも言われたりしますが、それも条件ではない。
あるいは「オープンソース的なんとか」みたいなことを言われたり。例えばオープンソースハードウェアとか、オープンソースポリティックスとか、“オープンソースなんとか”という言葉はすごく多いです。でも、ほとんどはあまり意味がない。あるいは、GitHubを中心にしたコミュニティっぽい開発。そういうものも定義に含まれていないんです。
ということは、個別のオープンソースソフトウェアごとに何をしていいのか、どういうふうにしてもらったらうれしいのか、どういう距離感で接してくれたらうれしいのかみたいなものは、バラバラなんですね。
今日は一般論として話をしていますが、一般論にしづらいんですよ。個人で開発しているオープンソースソフトウェアもあります。例えば初期のRubyとかそんな感じですよね。
それから、企業が開発しているオープンソースソフトウェアもあります。自分たちのコアなものをオープンソースソフトウェアとして公開しているスタートアップ企業さんもあります。それから、団体としてオープンソースを開発しているところもあります。
だから、動機もバラバラなんですね。趣味で開発をしている人もいれば、「自分の会社はこのオープンソースソフトウェアを大々的に公開して活用しています」みたいなことで広報をしている、あるいはブランディングとしてオープンソースソフトウェアを活用しているところもあります。あるいは、これは社会貢献だと思ってオープンソースソフトウェアを応援しているところもあります。そういうふうに、すごくバラバラなんですよね。
なんだけど、そのオープンソースソフトウェアに対して、開発をしている開発者もやはり個別の人間なので、やってほしくないことは共通してあるんです。
よく日本の言葉では、「お客さまは神さまです」みたいな言い方をする人たちがたくさんいますが、そんなはずがないわけです。そもそもオープンソースソフトウェアの利用者はお客さまではないんですよ。だって、お金を払っていないんだもん。
にもかかわらず、「利用してやっているんだ」みたいな感じで詰め寄る人たちはいるんですね。「お前のソフトはこんなこともできないのか」とか言い出す人がいるんです。
だいたい金を払わない客。まあ本当は客じゃないんだけど、金を払わない人たちは、だいたいタチが悪いんですよね。
よく商売では「タダで物を配るな」と言われますが、金を払わない人のほうが文句を言うんですね。タダ乗り精神みたいなものがあって、「タダでこれをくれたからには、ありとあらゆるサービスは無料で提供すべきだ」みたいなことを言い出す人がいるんです。
もっとタチが悪いのは、「お前が作ったソフトウェアは、こんなにもたくさんの人に使われていて、社会的責任があるのでなんとかしろ」と言う人たちもいるんです。「社会的責任とか道義的責任を感じないのか」とか。「なんで自分の作ったソフトウェアが人気が出て、たくさんの人に使ってもらったら罰を受けないといけないのか」と作っているほうとしては思いますが、こんなことを言うんですね。
こういうのは、つまり「誰かの作ったオープンソースソフトウェアから搾り取ってやれ」という、搾取の精神がどこかにあるんですね。
こういうことをされるとやる気が破壊されます。「こんなことを言われるんだったらオープンソースソフトウェアを作りたくないな」みたいに思うわけです。
オープンソースソフトウェアにおいて最も大切なリソースはやる気、モチベーションなので、悪口を言われたり文句を言われたり、あるいは「お前には社会的責任がある」とか詰め寄られたりすることでやる気を失って、そのオープンソースプロジェクトは消え去っていく、みたいなことはしょっちゅう起きているんです。
(スライドを示して)これは『xkcd』という漫画です。モダンデジタルインフラストラクチャーが、下のほうにある誰からも感謝もされないでメンテナンスをしてきたソフトウェアに、実はみんなが寄りかかっているという話です。
例えば最近だと「log4j」に酷いバグがあったという話がありましたが、そんな時に、「こんなセキュリティ問題を残しておくとは何事だ」みたいなことで詰め寄る人たちがいますが、結局はオープンソースソフトウェアなので、「そんなことを言われても」という感じでもあるわけです。
よくよく見れば、オープンソースソフトウェアはライセンスがすべてだと言いますが、ほとんどすべてのオープンソースソフトウェアライセンスには無保証と書いてあるんですね。
(スライドを示して)これはMIT(Massachusetts Institute of Technology)ライセンスから取ってきたものですが、「NO WARRANTY」と書いてあるわけですよ。「どんなセキュリティ問題があったとしても、自己責任で使ってください」と。「その代わり、タダで使っていいし、自由に使ってもいいし、ソースコードも公開します」という感じです。
ほぼすべてのオープンソースソフトウェアライセンスが無保証ですよね。これは、搾取されたくないと。誰かが「社会的責任だ」とか、「俺が扱ってやっているんだ」みたいなことを言ってきても、「俺は知らんがな」と言えるという伝家の宝刀なわけですね。
でもそれってあんまりいい関係じゃないですよね。利用者が文句を言って、開発者が「無保証だから」と言ってバンってはねてしまうのはいい関係ではないです。
正しい、しかも、生産的な関係、距離感がどこにあるかというと、搾取の反対にあるんじゃないかなと思います。つまり、リスペクトですよ。
開発者としてリスペクトをする。プロジェクトとしてリスペクトをする。プロダクトとしてリスペクトをする。こういう関係が必要なんじゃないかなと思います。
オープンソースソフトウェアに限りませんが、「このことについては叩いてもいい」という雰囲気が醸成されると、なんか叩きたがるんですよね。
「Rubyは毎年死んでいる」という話がありますが、Rubyはものすごく話題になっていた時期はちょっと終わって安定期に入っているので、昔に比べると人気が落ちたみたいに見えるし、歴史的な事情から直せないような問題とかが残っていたりします。
そうすると、「Rubyはもうダメだ、死んだ」みたいな文句を言ってくるんですけれども、これもそんな感じですよ。ネットとかで誰かがよくない発言をすると炎上して叩くみたいなことがありますが、こういうのはよくないと思うんですね。
そういう免罪符みたいなものは、本当は存在しません。そうやって、何か落ち度がある、あるいは最新ではないものに対して叩いていくことによって、コモンズの悲劇、つまり共有しているものが結局は衰退してなくなってしまう。みんなが損をすることが起きるわけです。なのでリスペクトが必要だと。
もう1つ必要なのが、参加することではないかと思います。つまり、オープンソースソフトウェアの進歩、発展、それから継続を自分ごととして捉えることが必要なんじゃないかと思います。
昔は(人間は)動物や魚を捕まえる狩猟をしていましたが、人口規模が増えて産業規模が大きくなると、だんだんサステナブルじゃなくなるんですね。
オープンソースソフトウェアもそんな感じで、世の中にはたくさんオープンソースソフトウェアがあるので、どこかから勝手にダウンロードして勝手に使うような感じになっています。どんどんオープンソースソフトウェアの利用度合いが増えてきたり、社会全体のオープンソースに対する依存度合いが高まってくると、それはサステナブルじゃなくなってくるんですね。
そうすると、オープンソースソフトウェアを見つけてきてただ使うという一方向な関係から、参加して自分ごととして捉える、双方向の関係が必要なんじゃないかなと思います。
「オープンソースソフトウェアを利用することも貢献だ」という人たちもいますが、作っている側からしたら、「利用するのはどうぞ勝手にしてください」という感じなんです。
ですが、その後、例えばバグが見つかったら報告をするとか、改善案が見つかったら報告をするとか、あるいは改善した時にプルリクエストとかパッチを送るとか、コミュニティの活動に意見を交換するかたちで参加するとか。場合によっては、スポンサーになって経済的な支援をするとか、いろいろな参加の仕方があると思うんですね。
度合いはそれぞれだと思いますが、みんながみんな、すべてのオープンソースソフトウェアに対して経済的な援助をする必要があるかというと、それはプロジェクトごとに違うので、全部にはぜんぜんしなくてもいいんです。
ただ、自分の使っているオープンソースソフトウェアに対してリスペクトをすることと、それから自分ごととして捉えるという2つは、距離感を維持する上で大事なんじゃないかなと思います。
これからのパネリストがどういう発表をするか、私はまだ聞いていませんが、この人たちもきっと、それぞれのオープンソースに対してのリスペクトをしているのだと思います。
それから、オープンソースソフトウェアをただ拾ってきて使うだけではなくて、参加するというかたちで関わっていってくださっているんじゃないかなと。ふだんの活動をちらちらと見る限りでは、そのように推察します。
ちょっと短めのお話でしたが、こんな感じです。オープンソースソフトウェアの定義とは、ライセンスである。そして事情は、個々のオープンソースソフトウェアによってバラバラであると。しかし、オープンソースソフトウェアは、基本的に無保証であると。
我々とオープンソースソフトウェアとの関わり方は、リスペクトすること。まあリスペクトすると言っても、祭り上げる必要はありませんが、同じ人間として尊重するということです。
それから、段階はそれぞれあるんだけれど、そのオープンソースソフトウェアの関わりを“参加”というキーワードで考えてみるといいんじゃないかということをお話ししました。
以上になります。今日はどうもありがとうございました。
関連タグ:
2024.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05