ソフトウェアの再利用が難しい・・・というか難しかったというのは歴史的には事実で, たとえば ICSR / International Conference on Software Reuse とかいう学会がある。 どんな論文が書かれていたのか検索すると 2005 年の Software Reuse Research: Status and Future という論文が 950 citation くらい。もっと引用されている同系統の論文もないではないけど古すぎるので割愛し、 この論文をざっと眺めてみると・・・そういうのあったわーという単語がいっぱい出てくる。COM とかね。 (知らない人向けに補足すると COM というのは C++ で Java みたいなことをしたくて色々苦し紛れにがんばったテクノロジだとご理解ください。）
この頃のソフトウェア再利用、色々厳しい雰囲気が論文をチラ見するだけで伝わってくる。 今から考えるとムリっぽい暗黙の前提があると思う。三つくらいに分けて雑に整理してみたい。
ひとつ目の前提: ソースコードが非公開。
この頃はまだコードは出さないのが普通。
コードが見られなかったらそりゃ再利用大変でしょ。 エラーがおきても原因を調べられないし、ワークアラウンドもできないじゃん。
しかも形態が共有ライブラリだったりする。HTTP でプロセス境界を切ったりしない。 いちおう分散コンピューティングはあったが EJB とか CORBA とか DCOM とかの分散オブジェクトがマインドシェアを持っていた。 こいつらはマジ密結合で厳しく、SOAP だなんだと退化して結局 REST くらいに落ち着いたのを我々は事後的に知っている。
ふたつ目の前提: 再利用に課金したい。
ソフトウェア、仕事で書いてるので再利用したらちゃんと現金で対価をで払ってほしいと思っていた。
でもね、ライブラリでカネとるとか相当大変。現代でも数少ない例外を除き基本的にはできていない。 金をとりたいからひとつ目のソースコード非公開が必要なのだけれど、 使う側からするとそんなブラックボックスにわざわざ金払ってロックインされたくない。悪循環。 (じっさい成功しているライブラリ業者はソースコードも提供していることが多い。)
しかも昔はライブラリを作る側も使う側もソフトウェアのリリース・デプロイが頻繁じゃなかったので、 課金も subscription based ではなく買い切りだった。なので質が高いほど継続的な集金が難しい。 純粋な技術的障壁だけでなく、ビジネスモデルが辛い。
みっつ目の前提: 方法論があればなんとかなる。
2000 年代前半って、ソフトウェア工学といえばプロセス、開発方法論というような雰囲気があった(例: RUP)。 方法論というとちょっと限定的すぎで、たとえば形式化手法とか標準化とか、そういうやつね。 良い方法論と、そのためのツールを整備すれば再利用含め色々なことが上手くいく・・・といいな・・・と人々は期待していた。 先の論文でも chapter 6 によくわかんない methodology が列挙されている。(著者のバイアスな気もするが・・・)
しかしなかなかヒット作は生まれなかった。 Scrum とか良くも悪くもヒット作だけど、ソフトウェアの再利用は助けてくれそうにない。
オープンソースの台頭
こういう問題を解決したのがオープンソースである。 というか先の ICSR 論文が書かれた 2005 年の時点で UNIX の上ではオープンソースの C 言語のライブラリが割と再利用されたいた。 C 言語での再利用、現代の水準からみると大したことなく見えるけれど、C という言語の圧倒的しょぼさを考えるとめちゃ再利用されている。
オープンソースは先に書いたような伝統的再利用願望に潜む前提をぜんぶひっくりかえしている。
まず by definition でソースコードにアクセスできる。 だからドキュメントが多少しょぼくてもなんとかなるし、手元で自分の都合にあわせて直すことも、やりたくはないができる。
課金も、基本的にはしない。 オープンソースのソフトウェアを売って仕事にしようという個人/企業は Red Hat をはじめ今も昔も一定数いるけれど、 総体としてはオープンソース開発者のうちコードから直接の収益を挙げているのは少数派だと思う。 それでも色々な時代の力でコードが書かれ、使われている。
C 言語の再利用はさすがにだいぶ原始的で厳しかった。 でもかずよしさんのいうように後発のモダン言語では CPAN のようなパッケージマネージャが当たり前になり、 ソースコードあり・基本無料というオープンソースの強さをひきだすインフラができた。
しばらくは「ライブラリの再利用はできてもフレームワークは難しいですよね」とか言う人もいたが、 Rails を皮切りに何をするにもまずはフレームワーク探しから、みたいに風向きが変わった。 ウェブ以外ではここまで極端じゃないけれど、そうはいってもフレームワークだって再利用できるよね。コードが読めれば。
GitHub の台頭
オープンソースすばらしいけど現実には報酬がないと続かないですよね just for fun とはいえ・・・という問題も、段階的に解消された。
一つの解決は、企業が 補完材をコモディティ化 するためにオープンソースをやる事例。 つまりハードウェア企業がそのハードウェアを上手に使うためのソフトウェアをオープンソースにするだとか、 広告企業がトラフィックの入り口をオープンソースにするとか、 広く使ってもらうことで間接的に利益があるソフトウェアをオープンソースで開発する企業が現れた。 もともとは草の根だったプロジェクトも、それを補完材にできる企業がスポンサーしてくれたりする。 これがゼロ年代。
もう一つの解決は、プログラマや企業の名声をオープンソースに紐付けること。 つまりオープンソースで書いたソフトウェアが有名になれば開発者の実力は広く知れ渡り、 会社員やフリーランスであれば雇用や契約につながるし、企業であればプログラマ採用の糧になる。
名声や関心をソフトウェアの対価にするこうした流れはゼロ年代から少しはあったけれど、 2010 年代以降 GitHub によって大きく後押しされた。 今では GitHub のアカウントがレジュメにないとかっこ悪いみたいな水準に至っている。 (なお森田の GitHub は今年に入ってからちょっと緑っぽくなってきたけどぜんぶ Message Passing なのだった。プログラマとしての成果ゼロ。リクルータよ騙されるな！)
クラウドの台頭
オープンソース以外にもソフトウェアの再利用を推し進めたものがある。それはクラウド。 クラウド、最初は VM やストレージなど仮想化されたハードウェアを貸し出すビジネスという触れ込みで始まった。 人々はハードウェアに金を払うのは当たり前だと思っているので、 本来なら一括で大金を払わないと買えないハードウェアを従量課金で借りられるクラウドには大喜びで金を払った。
その後クラウド業者は VM やストレージのように比較的プリミティブな部品の上に段々と付加価値のあるサービスを積み増して行った。 今はもうサーバーレスとか言ってる。 (このレイヤリングが圧倒的に見事な AWS については CTO のありがたいお言葉を読んでみんなで感心しよう。)
ソフトウェアの再利用という視点で見ると、 クラウド業者は再利用可能なソフトウェアをハードウェアと抱き合わせて売ることに成功した。 純粋なソフトウェアには金を払わない人々も、ハードウェアと抱き合わせるとそれなりに納得して買ってくれる。 しかも買い切りじゃなくて毎月金を払ってくれる。
クラウドにはハードウェアだけでなく運用もついてくる。 というか現代的な価値観だとクラウドからは運用を買っている感覚のほうが強い気がする。 ソフトウェアやシステムの運用は昔から重要ではあったけれど、 ほぼ全てのソフトウェアに運用が伴うようになったのはインターネット以降。 だから「再利用可能なソフトウェアと運用を抱き合わせて売る」というモデルも、それなりに新しい現象だと言える。
そして運用が必要で再利用可能なソフトウェア、いわゆるインフラのソフトウェアはライブラリでもフレームワークでもないことが多い。 データベース…は昔からあるとして、CI, CDN, キュー、Functions… これらを「再利用する」感覚は、2005 年にはそんなになかったんじゃないかな。
冒頭の残念な三つの前提に立ち戻ると、クラウドは主に三個目の前提「方法論がなんとかしてくれる」に答えをくれた。 必要だったのは形式化手法でも標準でもなく、売る側も買う側もソフトウェアをインターネットに載せることだった。
まあインターネットは技術標準なので TCP/IP/HTTP/TLS/JSON が偉かったと言ってもそんなに間違ってはいないかもしれない。
積み残し
こうしてみると、ソフトウェア開発は随分遠くまで来たなと思う。 「ソフトウェアは再利用できない」とはもう誰も思ってないからね。
もちろん再利用が常に簡単とは言えず、 たとばバージョニングのような構成管理の問題もあるし、 クラウド業者へのロックインも場合によっては気になる。 オープンソースプロジェクトの持続可能性はいつだって心配。
とはいえもう時代が逆戻りするとも思えない。 15 年後に振り返って「いやー当時は他人のコードに依存しすぎだったねワッハッハ」とか言うこと、なさそうだよねえ。