継続的なプロダクト開発のための失敗しないライブラリの選び方

遅めの梅雨入りでやっと蒸し暑くなってきました昨今、いかがお過ごしでしょうか。 DX事業本部で開発基盤エンジニアをやっております、@k_bigwheelこと西田和史です。

さて、Speeeでもそろそろ来年度入社の新卒エンジニアの入社前アルバイトが始まっているのですが、先日そんな一人と話していて以下のような質問が出ました。

どのような基準でライブラリを選定していますか？

その場で僕含め数人で主な観点を共有したのですが、確かにライブラリの選定はホビープログラミングと企業での開発で大きく違う点です。とてもよい質問ですし、せっかくなので観点を記事としてまとめることにしました。

f:id:den8:20210620224152j:plain — 特に本文と関係ありませんが、これは最近気に入って使っているキーボードです(Halberd + Alpaca + Tai-hao Sakuramichi)

ホビープログラミングと企業での開発でのライブラリ選定の違い

ホビープログラミングと企業での開発におけるライブラリ選定の違いは大きく2つあると考えています。 1つがコンプライアンス遵守の観点と持続性の観点です。

1. コンプライアンス遵守

法令遵守とも言われるこれは、簡単に言ってしまえば利用するライブラリの利用規約・ライセンス規約を守りましょうということです。私達が昨今利用するライブラリはOSSのものが多いですが、OSSであっても無制限に使用できるわけではありません。例えばGNU General Public Licenseのライブラリ(ソースコード)を含んだアプリケーションをユーザーへ提供する場合は(ユーザーから要望があった場合)そのソースコード全体もユーザーへ提供する義務があります。

これらはたとえホビープログラミングであっても軽視していいものではありませんが、企業での開発では特に守らなかったときのリスクが高いです。例えば自社ソフトウェアでライセンス違反が発覚した場合、それが機密性の高いものであったり非公開であることが競合優位性につながっているようなものであってもソースコードをユーザーへ公開する必要が出てきます。またライセンス違反をしていたということ自体が自社の評判を落としユーザーからの信頼を損なうでしょう。

MITライセンスやBSDライセンスなどが溢れる中ではこのリスクは実感しづらいかもしれませんが、Railsでもライセンス違反をきっかけに3月頃世界中のrailsアプリケーションが一時ビルドできない事態が起きたり(RailsのGPL混入問題についてまとめ（mimemagic） - Qiita)、クラウドベンダーとのいざこざの結果非オープンソースライセンスへ移行したElasticsearchやMongoDBなどライセンスによるトラブルは思った以上に身近なものです。

f:id:den8:20210531084952j:plain — 朝8時過ぎ、まだ人が少ない時間帯の僕の席から見える風景

2. 持続性

もう1点、大きく違うのが持続性の観点です。ホビープログラミングの場合、作成したサービスやプログラムに対する責任はほぼありません。リリースしたアプリにバグがあっても修正するかどうかは開発者の自由ですし、フレームワークのメジャーバージョンアップなどにも追従する必要はありません(個人情報を扱っている場合のことは一旦例外とします)。

しかし、企業での開発を行う場合ライブラリの持続性(安定性)は最重要と言ってもいい観点になります。基本的に企業での開発の場合ホビープログラミングよりずっと長い間高い品質でサービスを提供し続ける必要があります。一度作ったアプリケーションをまったく変えなければ問題ないのでは？と思うかもしれませんが、昨今のソフトウェア開発事情としてプログラミング言語のセキュリティパッチが古いメジャーバージョン向けには提供されません。その結果PaaS(GAEなど)やFaaS(AWS Lambdaなど)で古いメジャーバージョンはサポートが一定年数で打ち切られます。これは言語だけでなくウェブフレームワークでも同様です。

しかし、完全な後方互換¹を持つ言語はほとんどなく、バージョンアップがなされるごとにライブラリも新しいバージョン向けに修正・ビルドが必要です。しかし、もし使用しているライブラリのメンテナが1人もいなくなってしまっていると代替ライブラリへ移行するにしろフォークして修正するにしても大きなコストがかかることになります。

具体的に見るべき点

上記の話を踏まえつつライブラリを選定する上で見るべき点を挙げていきます。

1. GitHubのスター数で比較する

GitHubのスターの数は端的にそのライブラリの人気度を定量的に表しています。人気のあるライブラリというのは利用者もメンテナーも多い傾向にあります。もしある目的で2種類のライブラリがあり、そのスター数に10倍の開きがあるとしたらスター数が多い方を使うのが良いでしょう。

ただしこのスター数が2,3倍程度だと注意が必要です。もしスターが少ない方のライブラリが後発ライブラリであるとしたら、先発ライブラリの設計を改良したより良いものでいままさにスター数で追いつきつつあるのかもしれません。そういった場合は後発のライブラリを選んだほうが良いことが多いです。

また、言語・分野によってスター数の平均は大きく異なります。利用者の多い言語だと人気のあるライブラリは軒並み数千スターいくものが、利用者の少ない言語だと安定して開発されていてもたかだか100スターといったことは珍しくありません。スター数の比較はできる限り同じ言語の同じ機能・分野のライブラリ間で行いましょう。

2. ライセンスのチェック

前述の通り、ライセンスは企業で開発する上で非常に重要です。ウェブサービスを提供する上では主要3ライセンス(MIT, BSD, GPL)のどれでも問題ないケースは多いですが、アプリケーションを配布する場合やそれ以外のライセンスなどは気をつけたほうが良いです。個人的な経験則としては、スターがたくさん付いているような人気のライブラリは制約の少ないライセンスであることが多かったです。

3. 開発元の規模

OSSのライブラリも開発元の規模は様々です。一個人が仕事とはまったく無関係に開発しているものもあれば、Amazonのような大企業が自社サービスの関連ライブラリとして開発しているものもあります。

もし他の評価項目が同じぐらいの場合、個人開発よりは企業開発のもの、そして中小企業よりはGoogleやNetflixなど大企業が開発しているものがよいです。もし一個人が開発しているようなライブラリの場合、開発者のライフスタイルの変化や不慮の事故などにより継続開発ができなくなるようなリスクがあります。また、主観ですが企業開発でも小規模な企業より大企業のほうが高い品質で継続的にメンテナンスされる可能性が高いように感じます。理由を考えると、そのような大企業は優秀なエンジニアを高給で継続的に雇いつづけるだけの安定した利益を出しており、OSS貢献という直接企業利益につながらない活動を行ってもレピュテーション向上でペイするだけの規模を持っているためではないかと考えています。これが個人や中小企業の場合、優秀なエンジニアをOSS開発へ割いてもそれによるレピュテーション向上はそこまで効果的ではなく、事業がうまくいかなくなるとOSS開発へ割く人員を減らしたり、OSSをプロプライエタリライセンスへ変更したりしやすいです。