僕が社内ライブラリを OSS 化すべきだと思う3つの理由

こんばんは、台風がヤバいですね。

こんな風に命の危険がそこそこあるときは、なんとなく人生について考えてしまいます。私はどこからやってきて、どこへ消えてゆくのか……

そんなことを考えていた折に、「社内ライブラリって OSS にしてしまうべきだよなー」と、ふと思ったので、考えていることをメモしておこうとおもいます。

「社内ライブラリ」

とりあえずこの社内ライブラリの前提を並べると

1つまたは複数のプロジェクトが参照しているライブラリである
製品的なビジネスロジックを内包しておらず、汎用的で、利用されているプロジェクトと密結合でない
バージョン管理されている

の3点は満たしておく必要があります。例えばニコニコ動画を OSS にするのはちょっとアレですし、課金部分を OSS にするなんてもってのほかだなーと思います。

そんなプロジェクトがあなたの会社にあるかないかはわかりませんが、いわゆる「この言語での便利関数集」とかは案外これを満たすので、パッケージングして外出しできるんじゃないでしょうか。

3つの理由

だいたいこんな理由です。

利用されることによってエンジニアに「あの会社はいい会社だ」と錯覚させることができる
ソースコードの保守性を高めることができる
勝手にメンテされる

といことでちまちま詳細を書きます。

1. 利用されることによってエンジニアに「あの会社はいい会社だ」と錯覚させることができる

これがまず一点です。これは単純な話で、エンジニアは OSS とかライブラリとかいう言葉が好きで、そういったものを公開している会社に対して無条件に「なんとなく」いい会社だなと思い込む節があります。

経営者の方や、もっと利益について考える方からすると、労働状況や収益、今後の展望などが会社ひいては転職時に見るべき点でしょうが、エンジニアはとりあえずその会社がエンジニアリング的に「イケてるか」「イケてないか」を見ます。そんでもってそれが自分の納得する以上のものであった場合、その他の条件についても「そのへんも大体いいんだろう」と錯覚します。

これは結構マジな話で、僕もよくそう思います。 Google 日本法人がどれくらい素晴らしい労働環境なのか、全然知らないですけど、 Google だからなんとなくいい環境だろうなとおもいます。もちろん参考は Google Closure Compiler や V8 などを見ただけです。その他はよく知りません。給与的にもいい環境なのかわかりませんが、エンジニアリング的に素晴らしい場所で自分を高められるなら、多少給料が安くても「勉強代」だと思ってればまぁ払えるんじゃないでしょうか。

もちろん Google にかぎらず、 DeNA やそれ以外の OSS を公開している会社を、僕はなんとなく無条件に「いいところなんだろうなぁ」と思っています。この先入観は大事です。

その上、エンジニアは経済ニュースにまったく関心がないので、どんなに収益を上げたり決算前に予想収益を上方修正してもエンジニアがその会社の存在に気づくこともなければ、名前を覚えることもありません。転職エージェントに名前を言われて「なんかそんな会社が最近あるんだな」と思うぐらいが関の山です。

しかし Github の Hot Repository は見ています。いっそ RSS 見てる人もいるかも知れません。そうすると会社の名前が流れてきます。こうやってエンジニアは転職先を見つけるわけです。というかこれ以外にエンジニアが能動的に会社の名前を見るのは勉強会のスポンサーとかぐらいじゃないでしょうか。

勉強会のスポンサーになるのはお金がかかりますが、コードを公開するのに新規に発生するお金はそう多くありません。公開するものはすでに社内で使われているライブラリでいいのですし、すでにバージョン管理されているなら、それをアップするだけです。Github に Organization Account を作ってもタダです(OSS のみなら)。

2. ソースコードの保守性を高めることができる

さて、モジュールとして公開するのにお金はそう多くかからないという話をしましたが、それでもかかると思います。具体的には「公開できるようなソースコードにするお金」がかかります。

誰にも見られない(実際には社内の人から見られるのですが、コードレビューがたくさんある会社も稀だと思います)ソースコードを綺麗に書こうと思うことはありません。語弊がありました。期間も決まってるのに、エレガントな実装について悩んでる時間はそんなにたくさん確保されていません。

しかし、概ねエレガントでなく、泥臭く、手続き的な場当たり実装というのは保守性が低く、長期的な保守コストを高めていく結果にしかなりません。これは長期的な損失だと、僕は思います。かといってじゃあいますぐ美しいコードを書こう、と思うほど意識を変えられるかというとそううまくはいかないとおもいます。ですが、 OSS で公開するとなれば話は変わります。

これは僕だけかもしれませんが、世の中のエンジニアのなかの数割は OSS という言葉に対して、ある種神格化された認識を持っています。「私なんかが OSS に参加するなんて恐れ多い……」と思っている人もいるのではないでしょうか。そんな中で自分で OSS をリリースするとなれば、それはちょっと気合を入れなおして、自分のかける最善のコードを書く必要があります。

つまり、エンジニアに対して意識改革を促すことができる、というわけです。元エンジニアの現管理職の方、「最近のエンジニアが書くコードはどうもエレガントじゃないなぁ……」と思うことはないでしょうか。彼らの意識を変えるのに最も手っ取り早い方法だと、僕は思います。

そして OSS 化すると、そのソースコードは当たり前ですが家から書けるようになります。土日だろうと改善しようと思い立ったらその時、家の個人 PC から、エンジニアが修正をかけることができるのです。普段家で仕事なんかしたくねーよといっているエンジニアも、家で趣味のコードを書いている可能性は大いにあります。ならその趣味の対象を会社のライブラリにしてしまえばいいのです。簡単ですね。

3. 勝手にメンテされる

最後の理由ですが、 OSS でモジュールを公開すると、うまくすれば利用者がつきます。モジュールを使うユーザーは他のモジュールと同じようにあなたの会社の OSS を利用し、そして、勝手にバグを発見します。

バグを発見したユーザーがただの利用者であったばあいやってくるのは Issue (バグレポート)ですが、そのユーザーが他社やフリーランスのデキるエンジニアであった場合飛んでくるのは Pull Request (修正パッチ)です。つまり勝手に誰かが保守してくれる、というわけです。

モジュールは大体の場合、ある程度完成された機能を持ったら、そこで開発が終了して、あとは細かなバグが発生した時に手直しするような感覚になります。そしてその細かなバグというのを見つけるのは案外面倒な作業で、こういったものを効率化するために頑張っている人もいるくらいです。

それらを勝手に誰かがやってくれて、しかもバグレポートするために再現するためのサンプルコードまで作ってくれ、また運が良ければそれらのバグが修正されたパッチまで送られてきます。バカみたいな手軽さです。素晴らしい！

このように、 OSS で公開する利点というのは大いにあります。部下が OSS にしたいといったときは一旦話を聞いてみるのもよいのではないでしょうか？

まとめとネガティブな話

ということで僕は条件が整っていれば、 OSS として公開するのはいいことなんじゃないかなーと思っています。ですが、もちろん公開するのにリスクはあります。

例えば

ビジネスロジックが含まれているコードは外に出さないほうがいい
自分のところの特許技術だったりコア技術だったりするものは OSS 化しないほうがいい
逆に OSS 公開することで生じる、法務的な手間などがある

といったところでしょうか。 DeNA さんもなんかライセンス周りで一悶着あったりしましたが。

それでも、言ってみれば採用活動と企業アピールと社内の活性化と保守コストをちょっぴり安くできる、というリターンは割りと美味しい報酬なんじゃないかなーとおもいます。

ぜひぜひ、ご検討なさってみてください。それでは！

頂いたコメントとレスポンス

Twitterやはてブなんかでいろいろご指摘をうけているのでそれについてもちょこちょこ書いておこうとおもいます。

そう上手くいくわけなかろうに。90%のOSSは話題にもならずに消えていきます。それでもOSSにしておけば、勝手のフォークして別プロダクトに突っ込むのに社内調整が要りません。 / 僕が社内ライブラリを OSS 化すべきだと思う3つの理 URL

2012-06-20 09:20:58 via Hatena

そのとおりだと思います。公開すれば誰かが保守してくれるとは書いてみたものの、 Pull Request が飛んでくることなんてそう多くありません。僕も公開してるリポジトリで Pull Request が飛んできたのなんて git-tasukete ぐらいなものです。

ただじゃあ上手くいかないから公開しません。というのは、エンジニアがコードを綺麗にしたいのでリファクタリングしたいというのを、コードが綺麗になったからといってソフトウェアの品質が上がるわけでもあるまいし、と切り捨てるのと似たような感覚なのではないかなーと思ってしまうので、うまく行かなくてもとりあえず公開してみるのはいいことなんじゃないでしょうか。そこから使われるかどうかはおいといて、という話です。

あくまで公開してもそんなにデメリットないんだしできるものはしてしまえばいいんじゃないの？というスタンスなので、そうじゃないならすべきでないし、デメリットがないならやっとくかーぐらいの、正月の初詣くらいの気分でフラットにやっていいんじゃないでしょうか。

「勝手にメンテされる」んじゃねぇ、有志がこれは良いと思うから改善されていくんだよ。 > 僕が社内ライブラリを OSS 化すべきだと思う3つの理由 - 宇宙線 URL

2012-06-20 09:40:18 via Tweet Button

そのとおりだと思います。公開しても見向きもされなかったら、誰かが手直ししてくれることもなく、普通に自分でバグを踏んでそれを直すだけです。公開しない時とまったく同じ事をやるだけですから、それなら公開しておけばどこかの誰かがもしかしたら、と希望を持ってもいいんじゃないかなと思います。

まぁでも全体的に「OSS で公開したいっていうときどうやって上司を説得するかなー」と考えて書いた文なので、エンジニアのスタンス的にはかなりなげやりな文体にはなってます。よくないですね……

第三者にバグを突っ込まれ(それを元に自社プロジェクトが炎上した)場合に、誰が責任取るのかっていう問題があるのよねえ僕が社内ライブラリを OSS 化すべきだと思う3つの理由 - 宇宙線 URL

2012-06-20 10:07:55 via Tweet Button

バグを突っ込まれて即社内プロジェクトが炎上するという事態がいまいち想定できませんが、バグ一個でプロジェクトが炎上するモジュールは多分プロジェクトと疎結合ではないので、その手のリスクがあるモジュールははなから公開しないほうがいいんじゃないでしょうか。

「公開して増える面倒なこと」がなさそうな疎結合でビジネスロジックを含まないコードは公開してしまえばいいのでは、というだけの話なので、そんなに重要なコードは出さないでおいたほうが安全だと思います。

ああいや、恥ずかしいコードを公開して世間の笑いものになるリスクとかどこぞからパクってきてたことがバレるリスクもありましてですね / 僕が社内ライブラリを OSS 化すべきだと思う3つの理由 - 宇宙線 URL

2012-06-20 11:14:35 via Hatena

恥ずかしいコードで笑いものにされるのはむしろ歓迎されうるべきで、コードレビューをタダでしてもらえると思えばいいんじゃないですかね。マサカリなんてたってても飛んできますし、僻地で種籾を大事にしていてもモヒカンは突如やってくるものだと思います。新しくやってきたエースエンジニアが社内のコードをみて「まったく話にならない」と愚痴りながらやめていくより、外から叩かれて直してという過程を見せたほうが、周りの好感度はあがるとおもいます。

パクってきたコードが露見するというのは確かにあんまりいいことではないので、出来れば最初からパクってこないほうが……と思うのですが、OSS を一個公開してしまえば、外の OSS プロジェクトを利用するときの説得も多少しやすくなるんじゃないでしょうか？最初から外の OSS などの資産が使えるなら社内でわざわざ車輪の再発明をする必要は減るんじゃないかな……ちょっと楽観的すぎるけど。