
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
個人と企業とオープンソースの距離感(全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つは、距離感を維持する上で大事なんじゃないかなと思います。
これからのパネリストがどういう発表をするか、私はまだ聞いていませんが、この人たちもきっと、それぞれのオープンソースに対してのリスペクトをしているのだと思います。
それから、オープンソースソフトウェアをただ拾ってきて使うだけではなくて、参加するというかたちで関わっていってくださっているんじゃないかなと。ふだんの活動をちらちらと見る限りでは、そのように推察します。
ちょっと短めのお話でしたが、こんな感じです。オープンソースソフトウェアの定義とは、ライセンスである。そして事情は、個々のオープンソースソフトウェアによってバラバラであると。しかし、オープンソースソフトウェアは、基本的に無保証であると。
我々とオープンソースソフトウェアとの関わり方は、リスペクトすること。まあリスペクトすると言っても、祭り上げる必要はありませんが、同じ人間として尊重するということです。
それから、段階はそれぞれあるんだけれど、そのオープンソースソフトウェアの関わりを“参加”というキーワードで考えてみるといいんじゃないかということをお話ししました。
以上になります。今日はどうもありがとうございました。
関連タグ:
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
2025.02.05
エンジニアとして成功するための秘訣とは? ひろゆき氏が語る、自由な働き方を叶えるアプリ開発とキャリア戦略
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
PR | 2025.02.04
能登半島地震で自宅は全壊、「これでどうやってDXするねん」 被災したサイボウズ社員と支援者らが語る災害支援のノウハウ
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10
片付けパパ対談【特別編】 整理術×行動術×メモ術で、仕事も人生も自在にデザイン!
2024.12.16 - 2024.12.16