2024.11.29
“マニュアル作成が進まない問題”をAIで解決 管理者の負担も軽減できる、先進AIツール活用法
個人と企業とオープンソースの距離感(全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.11.26
タスクの伝え方が部下のモチベーションを左右する マッキンゼー流、メンバーが動き出す仕事の振り方
2024.11.25
論理的に「詰める」マネジメントでは本質的な解決にならない マッキンゼー流、メンバーの理解と納得を得る接し方
2024.11.25
仕事はできるのに、なぜか尊敬されない人が使いがちな言葉5選 老害化を防ぐために大切な心構えとは
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.27
何もせず月収1,000万円超…オンラインゲームにハマって起こした事業 大学中退し4社立ち上げ・2社売却した起業家人生
2024.11.27
仕事中の「今ちょっといいですか」が苦痛… いしかわゆき氏が語る、ADHD気質にマッチした働き方のヒント
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.26
仕事の質を左右する「ムダな習慣」トップ5 忙しくなる前に棚卸ししたい“やめたほうがいいこと”とは
2024.11.22
40歳以降の「つみたてNISA」と「iDeCo」運用の優先順位 老後のための資産形成のポイント