最近、社内でよく話をする内容についてまとめました。
企業がOSS化するといろいろメリットがあると思っていて、社内でもそこのコンセンサスはうちの技術横断部門のメンバー間では取れていたりするのですが、自社以外の人とかと話をする時もあるので、いろいろまとめておきます。
なお、この文章では本業をOSSにしつつビジネスを回そうみたいなElasticsearchとかMongoDBとかMySQLみたいな話題はとりあげず、本業が別にある会社がOSS化する、という部分に特化した話です。
9/13に追記
よく言われるメリットとデメリット
メリットは、公開することで開発が自然と進み、コスト削減になる。一方でノウハウの流出などのデメリットがある、みたいなトレードオフ、という理解をしている人が多いようです。
コストは削減にならない
OSS化したら多くの人に使ってもらいたいですよね？というのは考えるわけですが、その「普及」というのはかなり高いハードルです。
必ずしも、OSSのせいというわけではなく、SDKを配布して外部の会社に使ってもらうみたいな、自分の作ったフレームワークなり、ライブラリなりを普及させようとする活動はDeNA時代に、ngCoreに関わっていたのでもろもろ横で見ていました。新しく使ってもらおうとするにはそれなりの工数が必要です。雑誌の記事数本分の分量のドキュメントは最低でも必要でしょう。ブログをこまめに書いてきちんと新しいバージョンのPRをしたり、場合によってはイベントをしたり、営業をして売り込んだり、カスタマーサポートも必要です。
盛り上がればGitHubのIssueには大量にIssueが押し寄せ、Pull Requestも大量に来ます。それらに回答し、OSSのシステムの考える進化の方向性と合わない提案をリジェクトし・・・なかなか骨の折れる作業です。コミュニティマネージャを用意し、外部の貢献者のレピュテーションの高い人にもコミット権を与え・・・みたいなことも必要になるかもしれません。
普及させようとすると大幅に人手が必要になります。
で、そのようなコストをかけなければそこまで注目を浴びることもないですし、運良く浴びたとしても自社が望む方向性に勝手に進化してくれるかどうかもギャンブルですし、OSSにすれば工数削減になるかというと、そういう恩恵にあずかることができるケースはかなりまれかとおもいます。
ノウハウは流出しない
情報は出したところに集まる、みたいなことが言われたりもします。まあこの言い方自体、僕は好きじゃないというか情報が価値のあるもの、という域からは出てないのでいまいちだなと思っていたりします。
ソフトウェアに関する情報そのものはすぐに価値が薄れていくものですし、一番大事なのは「情報を出し続ける能力がある」というところだと思っています。出て来た情報そのものに価値があるわけじゃなくて、情報を生み出せる組織とメンバーがいることが何よりも大事であると。
OSS化することでノウハウが流出するかというと、それで流出する程度のノウハウというのはその程度なんだろうな、という気がしています。それを生み出せる会社や組織である、という方が大事。会計上、ソフトウェアの資産価値というのはそれにかけた工数に正比例するし、会計上は生み出したソフトウェアが大事、ということにはなりますが、経理上の価値とエンジニアの感じる価値は違いますよね？
ググれる
社内向けでも社外でもドキュメント整備は手間暇がかかります。
社内フレームワークとかだと、ドキュメントなどは内部で整備するしかありませんし、どのようなシステムで作るのしても、どうやってドキュメントを構成してどうやってアクセスしやすさを担保するかは時間も手間もかかります。
OSSになってしまえばドキュメントも公開できます。リファレンスはgithub pagesとかに乗っけたとして、チュートリアルはSEO力の強いQiitaとかに乗っけてしまうとかいいんじゃないですかね。そんな感じで使えるツールとかも多いし、検索もできるようになるし（ただし、他とぶつかる名前をつけない前提）、同じ手間をかけてもアウトプットの使い勝手は公開してしまった方が圧倒的に上がりますよね。
機能の変更がしにくくなる
9/13追記
OSS化することのデメリットとして、APIのシグネチャを変えたりとか変更が加えにくくなるということを言う人がいます。社外にユーザーがいる場合には、使っているコードを見ることも変更の提案ができないので、ただ破壊するのみになってしまうと。
とはいえ、これって社内でも基本的に同じです。情報統制的には「見る必要のある人だけが情報を見ることができる」というが原則になっていますし、社内の全部のソースコードにアクセスできるという会社は少数派だと思われます。B2C、B2Bに関わらず。もちろんサービス名==会社名のような会社であればオープンかもしれません。しかし、僕のいたDeNAでも基本的に開発中の別のタイトルの情報とか知れるわけではないし、コードを見たりもできませんでした。IPものとかあるし外部との契約もありますしね。そもそも全員がアクセスできるセントラルリポジトリを用意するというのもGitHub:eが出てきてからの風潮だし、それ以前だとGoogleのようなそこにきちんとお金を払う決断をした会社だけですよね。
そして、仮に全部が見えたとして、変更ができるかというと、ユーザー数が2-3チームぐらいのコードに対して「シグネチャ変えたからコード変えてよ」とPRを送るのが精一杯でそれ以上のチーム数になると面倒は見きれませんでした。相手のチームのリリーススケジュールとかもあって、それに合わせる必要があって、それに合わせてタイムリーに出しつつ説得が必要です。3チームが、ライブラリの普及に時間を使い切らずに、ライブラリの改善にも時間が払える限界という気がします。
もちろん、開発チーム側が責任をもって変えるべき、というのも一理ありますが（バージョン固定のできないGoの当初のGoogle社内の運用ルールはこれ）、それを2-3回もすると、「ライブラリを使っているのにコスト増が強いられる」と社内専用ライブラリに対する信用貯金はゼロになり、他のオープンなコードへのリプレースがされたり、ライブラリコードの勝手コピーがチームのリポジトリ内部に作られて、独自進化を遂げて、チーム間の互換性もなにもなくなる、とうことがおきます。開発チームに開発力があればあるほどそうなります。そもそも、共通ライブラリ開発チームというのは社内的にコストセンターです。それを使ってプロダクションコードを書いているチームが偉いのです。信用マイナスからのスタートですからね。
あまり言われないメリットとデメリット
社内固有ツールを社内でメンテし続けると心が折れるのを防ぐメリット
社内でのみ使われるツールを開発し続けるのを嫌がる人は多数います。DeNAの時もそういう声を多く聞きました。どうしても社内でのみの情報しかないため、何かトラブルが発生すると社内の少ない情報を頼りに解決しなければなりません。社外のオープンなツールやライブラリの方が魅力的に感じてしまうのは仕方がないことです。必ずしも無料のOSSが、というわけではなく、社内専用のゲームエンジンよりはUnityが使いたいというのは熊のレストランで有名なdaigoさんは昔から言っていました。
僕もDeNA社内でツールで作ったわけですが、そのうちの1つはソースは公開しなかったものの、外部向けの勉強会で紹介したことがあります。FINAL FANTASY Record Keeperのためのツールだったのでスクウェアエニックスさんに資料をレビューしていただいたりもして情報は公開しました。当時は別のタイトルでも利用していました。他の会社の人でも話題になってそのツールのクローンを作ろうみたいな話題が出たりもしたそうです。退職時には雑誌の記事を書くぐらいの勢いで引き継ぎドキュメントも整備しましたし、学習コンテンツとして四択クイズもドキュメントに入れたりしていました。しかし、その後引き継いだ人はおらず、並行で利用していたタイトルがクローズになったりとかの影響もあると思うのですが、誰もメンテしない特定のゲームタイトル固有のツール扱いなアドベントカレンダーの記事が出たりして、まあそうなるよな、という感じです。
社内固有ツールは普及しないのですし、メンテする人がいなくなって血流が滞ると一瞬で誰もわからないツールになってしまいます。僕自身は楽しくやっていましたが、モチベーションが上がらないという声は（daigoさんに限らず）多数聞きます。
スナップショットとしてのメリット
OSSにしても、ぽっと会社のorgにリポジトリが増えておしまいです。注目を浴びることもなく、Pull Requestが来てバグが直ったりもしない。大抵はそんなもんかと思います。
とはいえ、それ自体は悪いことではないと思います。そのスナップショットを作った時点ではREADMEなども整備するし、独立したコンポーネントとしてうまく切り出されているはずです。セットアップ方法はその言語のデファクトスタンダードな方法にしたがってミニマムなキャッチアップコストで学べるようなものになっているでしょう。それだけでも十分メリットです。
DeNAみたいに法務部が特許侵害とかライセンスの問題がないかの確認の手助けをしてくれる会社だとさらに良いですね。まあそこまでやってくれるところは少数な気がするので、各開発者が注意すべきところではあります。
アルバイトやインターンの人に触ってもらうコードベースとして
最近はアルバイトやインターンで学生にきてもらって・・・ということをやっているところは多いでしょう。OSSというのはその時に触ってもらうコードとしては最適です。なにせ、最初からオープンなので漏洩のリスクとかもかなり低いといえます（設計ドキュメントとかまですべて公開かどうかはまた別ですが）。特定のお客さん向けの情報にアクセスするためにいろいろ社内外の手続きとかもいりませんし。あとは、お客様から対価をいただくような仕事であればきちんとやりきるのが大切になるので、「授業が無い時に来れる時だけ来てね」というスタイルではメインとなるような面白いところを受け持ってもらうというのも難しいです。その点ではOSSは責任範囲は限定的なので、大きな仕事の中の小さい周辺の仕事をやってもらうだけではなく、小さいけどきちんとど真ん中で仕事をしてもらうという選択肢ができます。
今はGCPの運用改善とか、費用をSlackに通知みたいな運用改善ツールが中心だけど、設計や品質の改善ツールとか、新しいアーキテクチャ案を一緒に実装するR&Dをやるとかも面白いかなという話はしています。バイトやインターンの人に短期間でも成果として外から見える形になっていれば、将来、採用活動のときにもPRできるのでWin-Winですよね？
9/13追記
GoogleがOpen source and open dataというブログを公開しました。主なトピックはオープンデータの方で、オープンソースの方はおまけ程度に書かれていますが、メリットの3として、社外から入ってくる人が、すでに社内のテクノロジーを知った状態で入ってきてくれる、というのが書かれています。外と中がつながるからこそのメリットですね。フューチャーでもVulsチームに入ってくる人はそういう強い人がいたりします。まあ、あくまでも流行った技術なら、ではありますが・・・・
政治の道具
あまりここを戦略的にやっている会社は日本ではあまり多くはないように思います。
例えば、Googleは先日、robots.txtのパーサーを公開しました。25年前に一度robots.txtをRFC化しようとして、一度諦めました。今年の7/1に再度RFC化にトライしていますが、そのタイミングでコードを公開しています。robots.txtは独自パーサーなどが多く、なおかつ、それを解釈するのも検索エンジンのスパイダーなので、手元で動作の確認もかんたんではありません。
仕様化のタイミングでそれに従ったコードを公開することは、世間の仕様を統一化する流れの中では効率的です。他の言語に移植するにしても、参考コードがあったほうが、実際に動かしてエッジケースの挙動を確認したりととても助かります。
OSS以外の選択肢
今まではOSS前提で話はして来ましたが、別にOSS以外にも、このようなメリットが得られる選択肢はあります。ようするに、作った成果がなんらかの形で外に出れば良いのですので。
例えば、最近上場して話題になったSlackは、もともとゲーム開発をしていたが、その本業がうまくいかず、社内ツールのチャットのビジネスにピボットしてうまくいった例です。食べログも、社内の趣味で開発されたサービスがピボットした事例とのこと（先日、moco_betaさんに教えてもらった）。サーバー一台買うのにも稟議書スタンプラリー（or電流イライラ棒）をしていた時代とは違い、クラウドでスモールスタートしていた時代なので、さくっとサービス化とかSaaS化しちゃう、ということも不可能ではなくなっていますよね。AWSもAmazon社内でサーバー資源の管理をAPI化したところから出発みたいなのを見かけた気がします。
UnityやUnreal Engineも、ゲーム制作からゲーム制作ツールのビジネスにピボットして成功した例です（Unreal EngineのEpic Gamesは自身のゲーム開発でも成功しています）。これはSaaSではなく、ツールを公開という例になります。
もちろん、これらのように「新しいビジネス」として外に出そうとすると、今まで以上にクオリティも要求されるし、ドキュメント整備、サポート部門を立ち上げたり、投資も相当必要になりますね。でも、めちゃくちゃ夢はありますね。
まとめ
OSS化は外部の人が機能追加やQAを手伝ってくれるとか、そういうわかりやすい工数削減みたいなことには繋がらないと思います。多くのPull Requestが集まるぐらいに普及させようと思うと、それなりに工数をかけてドキュメントを整備する必要があります。期待する水準からすると、工数はむしろマイナスだと思います。
一方で、情報の流通は活発になり、会社の組織は強く太いものになる、という効果は期待できます。メインのビジネスとは違う補助的な部分は外に出すと、そのメインのビジネスをささえる部分が円滑に回るようになります。社内のWikiにいくら一生懸命書いても情報を読みにくる人はおらず、情報の多い社外のOSSをみんなファーストの選択肢として使おうとします。社員のモチベーションにも効果があるはず。
フューチャー全体ではないですが、少なくとも僕のいるTIGのDX-Unitの一部では、事業会社にコンサルしてシステムを作って・・・というビジネスじゃなくて、一緒にR&Dして作ったものをOSS化しちゃう、みたいな仕事ができたら面白いし、お客さんのIT部門の人もきっと楽しいんじゃないかという話はしています。今時はクラウドベンダーに使用料を払い、そのお金でクラウドベンダーがR&Dをする、みたいな分業制みたいになっていますが、その中でもEnvoyとかKafkaみたいなミドルウェアとかが事業会社から出て来たりしています。そんな感じの事業会社発のOSSが日本からバンバン出て来るようになったら面白そうだし、仕事しても事業会社のそういう手助けがしたいです。