はじめに
こんにちは、テクノロジー戦略本部開発1部の稲川と申します。
私が所属しているチームでは、Ruby on Rails（以下、Rails）を使用してシステム開発を行っています。私が担当しているプロダクトで履歴管理が必要となった際、最初は独自実装することを考えました。しかし、チームで話し合った結果、独自実装すると設計に時間がかかりすぎるため、ライブラリを導入しようということになりました。
私はこのシステムにAuditedというライブラリの導入を任され、その過程で得た学びを記事として紹介したいと思います。
Web上ではライブラリ選定の考え方については多く見受けられますが、実際の導入までに必要な対応について具体的に書かれている記事は少ないようです。それが、今回の記事作成の動機となりました。
システム開発中に新しいライブラリをどのように選定、導入すれば良いかわからないと悩んでいるエンジニアの方々がいましたら参考になれば幸いです。
取り組んだこと
ライブラリの導入経験のあるチームメンバーに確認した結果を整理して、以下の優先度に基づいてライブラリの導入を検討しました。
優先度： 高
- ライセンスの確認
まず、ライセンス情報が記載されているライセンスファイルを確認します。一般的に、ライブラリのリポジトリ内に提供されるファイルには、ライブラリの使用条件やライセンスのテキストが記されています。
次に、ライセンスの種類を確認します。代表的なライセンスにはMITライセンス、Apacheライセンス、GPLなどがあります。ライセンスの名前が明記されている場合は簡単ですが、そうでない場合はライセンスのテキストを読んで特定する必要があります。（ライセンスごとの確認内容の詳細については本記事では割愛させていただきますので他の記事をご確認ください）
その次に、ライセンスの使用許諾条件や再配布に関する制約、著作権表示に関するライセンスの要件を確認します。ライセンスが適合するかどうかを判断するためには、これらの要件を理解する必要があります。
最後に、一部のライセンスでは商用利用を制限している場合があるため、その条件がないかを確認します。他にも商用利用時にライセンス料が必要な場合は、導入後に想定される使用頻度や効果を明確にし、プロジェクトの運営費用内で収まるかどうかを確認しましょう。
- メンテナンス状況の確認
ライブラリを選定する際の重要な要素の一つとして、メンテナンスの活発さがあります。例えばGitHubで公開されているライブラリは、Fork数や最近のコミット、ISSUE、プルリクエストの活動状況を確認することで判断できます。さらに、コミュニティフォーラムやメーリングリストが存在していれば、必要に応じてサポートを受けられる可能性があります。
- 多くの開発者が関与しているか
多くの開発者が関与し、活発にメンテナンスされているライブラリを選ぶことを推奨します。GitHubで公開されている実績のあるライブラリは開発者が約500人以上いるものが多いので個人的には開発者数が500人以上いるかどうかも目安の１つになるかと思います。
逆にメンテナンスが活発でないライブラリや開発してからかなりの時間が経過しているライブラリを使用する場合、導入後に思わぬタイミングでサポートが終了するリスクがあります。これはシステムの運用に影響を及ぼす可能性があり、例えば開発言語や依存ライブラリのバージョンアップなどに影響をあたえます。こういった場合は想定していた工数以外に代替ライブラリの再導入の検討からやり直さなければいけない可能性があるため、注意が必要です。
- 代替となるライブラリは他にもあるか
ライブラリを選定する際には、導入後のライブラリのバージョンアップ時に依存関係が原因でライブラリの利用が不可能になった場合のことを考え、複数の候補を挙げておくことが重要です。代替となるライブラリを選定する際も、この記事で説明した検討事項を参考に選定を行うと良いでしょう。
優先度： 中
- 導入コストや、ランニングコストは高くないか
ライブラリの導入コストは、導入時の作業内容と作業コスト、特にライブラリが有償の場合は導入後の使用量、使用年数、利用者数に応じた費用などのランニングコストも考慮に入れる必要があります。導入時のシステムやプロジェクトの状況によりますが、対応に必要な時間が少なく、かつ費用的なコストも抑えられるライブラリを選択することを推奨します。
- READMEに細かく記載があるか
ライブラリのREADMEに仕様、導入方法、使用方法が具体的に記載されているものを選ぶことを推奨します。さらに、機能拡張やバージョンアップの方法などが詳細に説明されているものが望ましいです。
優先度： 低
- ISSUE数が多いか、ISSUEは消化されているか
GitHubで公開されているライブラリの場合、ISSUEが多く、かつそれらが適切に対応されているかを確認します。ISSUEが長期間対応されずに残っている場合（解決やマージが行われていない場合）は、メンテナンスに時間がかかっているか放置されている可能性があります。
実例紹介
実例を挙げて説明します。
以下の内容は、私がRailsで開発を行っているシステムに、ライブラリ（以下、gem）を導入する際の具体的なプロセスです。
私が担当しているプロダクトでは、初期に履歴管理機能を独自に実装することを考えていました。しかしチーム内から、独自実装すると仕様変更や機能改善の際に多くの改修が必要になり、メンテナンスが困難になるという意見が出ました。
最終的に、多くのユーザが導入した実績のあるライブラリを検討することになりました。実績のあるライブラリの導入でDB設計やリリース後の履歴管理に関する改修をほぼゼロにして、今後の機能改善や新規機能開発にかかるコストを減らす方が良いという判断です。
チーム内からAuditedというgemが提案されたので、すでに導入ずみのbulk insertのgem（activerecord-import）との相性を中心に検討しました。
導入時に検討したこと
プロダクトの要件や目標をよく理解した上で、必要な機能や機能セットを明確にしました。その後、検討内容を優先順に整理し、ライブラリの導入を決定しました。
1. rubygems.orgにて次の点を確認
導入を検討しているライブラリがどれだけ利用されているかを確認しました。ダウンロード数が1,600万件と多いものは、それだけ多くの利用者から情報が得られると考えられます。また、導入後にライブラリが利用ができなくなった時のことを考慮して、類似のライブラリが存在するかも確認しました。この時類似ライブラリの検討も同じ観点で行いました。
優先度順の確認結果
| 優先度 | 確認内容 | 確認の進捗 |
|---|---|---|
| 高 | 1. ライセンスの確認 | - |
| 2. メンテナンス状況の確認 | - | |
| 3. 多くのコミッターが関与しているか（GitHub上のライブラリであれば、スター数が多いか） | - | |
| 4. 代替となるライブラリは他にもあるか | 完了 | |
| 中 | 1. 導入コストや、ランニングコストは高くないか | - |
| 2. READMEに細かく記載があるか | - | |
| 低 | 1. ISSUE数が多いか、ISSUEは消化されているか | - |
2. 該当のgemのページを開き以下を確認
ライセンスの種類や、バージョン履歴のリリース日から直近のメンテナンス状況（直近のリリースから１年以上経っていないか）を確認しました。また、Star数からどの程度開発者の注目を集めているかも確認しました。
優先度順の確認結果
| 優先度 | 確認内容 | 確認の進捗 |
|---|---|---|
| 高 | 1. ライセンスの確認 | 1/4 |
| 2. メンテナンス状況の確認 | 1/4 | |
| 3. 多くのコミッターが関与しているか（GitHub上のライブラリであれば、スター数が多いか） | - | |
| 4. 代替となるライブラリは他にもあるか | 完了 | |
| 中 | 1. 導入コストや、ランニングコストは高くないか | - |
| 2. READMEに細かく記載があるか | - | |
| 低 | 1. ISSUE数が多いか、ISSUEは消化されているか | - |
3. GitHubにあるgemのリポジトリを開きTOPページを確認
Fork数をチェックして、ライブラリのメンテナンスに関わる開発者の数を確認しました。さらに、ソースコード一覧の更新日付から、メンテナンスの活発さやサポートが終了する可能性がないかを確認しました。
優先度順の確認結果
| 優先度 | 確認内容 | 確認の進捗 |
|---|---|---|
| 高 | 1. ライセンスの確認 | 2/4 |
| 2. メンテナンス状況の確認 | 2/4 | |
| 3. 多くのコミッターが関与しているか（GitHub上のライブラリであれば、スター数が多いか） | 完了 | |
| 4. 代替となるライブラリは他にもあるか | 完了 | |
| 中 | 1. 導入コストや、ランニングコストは高くないか | 1/4 |
| 2. READMEに細かく記載があるか | 1/3 | |
| 低 | 1. ISSUE数が多いか、ISSUEは消化されているか | - |
4. ISSUEからメンテナンスの活動状況を確認
CloseされたISSUE一覧を確認し、最後にCloseした日付が最近のものかを確認しました。CloseされたISSUEの日付が年単位で古いものしかない場合は、メンテナンスが終わりかけているか、すでに終わっている可能性があります。そのようなライブラリは避けることを推奨します。
次にOpen状態のISSUEの数と日付を確認しました。ISSUEに対しての議論が活発にされているかどうかを見ることでも、メンテナンスの活発さを判断できます。
優先度順の確認結果
| 優先度 | 確認内容 | 確認の進捗 |
|---|---|---|
| 高 | 1. ライセンスの確認 | 2/4 |
| 2. メンテナンス状況の確認 | 3/4 | |
| 3. 多くのコミッターが関与しているか（GitHub上のライブラリであれば、スター数が多いか） | 完了 | |
| 4. 代替となるライブラリは他にもあるか | 完了 | |
| 中 | 1. 導入コストや、ランニングコストは高くないか | 1/4 |
| 2. READMEに細かく記載があるか | 1/3 | |
| 低 | 1. ISSUE数が多いか、ISSUEは消化されているか | 完了 |
5. READMEに記載されたgemの導入方法を確認
導入方法が記載されているか確認しました。なるべく簡単に導入できるものが好ましいといえます。それ以外にも、稀にメンテナンスの中止や、別ライブラリの導入を推奨するような記載があるため、それらサポート終了に関する記載がされていないかも確認しました。
優先度順の確認結果
| 優先度 | 確認内容 | 確認の進捗 |
|---|---|---|
| 高 | 1. ライセンスの確認 | 3/4 |
| 2. メンテナンス状況の確認 | 3/4 | |
| 3. 多くのコミッターが関与しているか（GitHub上のライブラリであれば、スター数が多いか） | 完了 | |
| 4. 代替となるライブラリは他にもあるか | 完了 | |
| 中 | 1. 導入コストや、ランニングコストは高くないか | 2/4 |
| 2. READMEに細かく記載があるか | 2/3 | |
| 低 | 1. ISSUE数が多いか、ISSUEは消化されているか | 完了 |
6. READMEに記載された利用方法を確認
gemのREADMEには、利用方法の詳細が記載されているかを確認しました。併せて、機能拡張に関する記載があるかどうかもこの時点で確認しました。
優先度順の確認結果
| 優先度 | 確認内容 | 確認の進捗 |
|---|---|---|
| 高 | 1. ライセンスの確認 | 完了 |
| 2. メンテナンス状況の確認 | 3/4 | |
| 3. 多くのコミッターが関与しているか（GitHub上のライブラリであれば、スター数が多いか） | 完了 | |
| 4. 代替となるライブラリは他にもあるか | 完了 | |
| 中 | 1. 導入コストや、ランニングコストは高くないか | 3/4 |
| 2. READMEに細かく記載があるか | 完了 | |
| 低 | 1. ISSUE数が多いか、ISSUEは消化されているか | 完了 |
7. テストコードからライブラリの仕様やメンテナンスの状況を確認
gemのREADMEに記載された利用方法だけでは不明瞭な動作があったため、テストコードから具体的な仕様を把握しました。具体的には、どのようなタイミングで履歴が登録されるのか、登録された履歴を取得した際のデータ構造はどのようになっているのか、データの変更を行わずに更新を行った場合の履歴はどうなるのか、といった内容です。
優先度順の確認結果
| 優先度 | 確認内容 | 確認の進捗 |
|---|---|---|
| 高 | 1. ライセンスの確認 | 完了 |
| 2. メンテナンス状況の確認 | 完了 | |
| 3. 多くのコミッターが関与しているか（GitHub上のライブラリであれば、スター数が多いか） | 完了 | |
| 4. 代替となるライブラリは他にもあるか | 完了 | |
| 中 | 1. 導入コストや、ランニングコストは高くないか | 3/4 |
| 2. readmeに細かく記載があるか | 完了 | |
| 低 | 1. issue数が多いか、issueは消化されているか | 完了 |
8. ローカルPCでの導入と動作確認
gemのREADMEに記載されている通りに導入や拡張が行えるかを確認しました。また、既存のシステムに導入されているbulk insertのgem (activerecord-import)との互換性も確認しました。
特に、Auditedで行っているActiveRecordのCallback経由での履歴処理が、activerecord-importでCallbackなしのbulk insertを行った際に、履歴登録が実施されないなどの問題が発生しないかどうかの確認が必要でした。
動作確認をした結果、bulk insert時にはCallbackが行われず履歴が登録されないという問題点が見つかりました。チームメンバーにこの問題点を共有し、履歴が必要となるテーブルが今後bulk insertの対象になるかどうかを調べた結果、問題ないという結論に至りました。
私が所属しているチームでは、ライブラリを導入する際に検討資料を作成し、コードレビューでその内容を確認してもらうようにしています。これにより、Callbackなしでbulk insertを実施した際の問題点をチームメンバーと共有することができました。また、資料を残すことにより、新規メンバーが参加した時でも、今後の開発で問題が発生しないように情報を共有できます。
優先度順の確認結果
| 優先度 | 確認内容 | 確認の進捗 |
|---|---|---|
| 高 | 1. ライセンスの確認 | 完了 |
| 2. メンテナンス状況の確認 | 完了 | |
| 3. 多くのコミッターが関与しているか（GitHub上のライブラリであれば、スター数が多いか） | 完了 | |
| 4. 代替となるライブラリは他にもあるか | 完了 | |
| 中 | 1. 導入コストや、ランニングコストは高くないか | 完了 |
| 2. readmeに細かく記載があるか | 完了 | |
| 低 | 1. issue数が多いか、issueは消化されているか | 完了 |
まとめ
今回のライブラリ導入を通じ、必要な検討事項に優先度をつけて整理することで、安全にライブラリを導入することができました。今後、ライブラリの導入をする際には、この整理した検討事項をもとに効率的、かつ、安全にライブラリを導入しプロダクトの改善をおこなっていきたいと思います。
プロジェクトごとにライブラリ導入の基準が変わることは想定されますが、もし私と同じくライブラリの選定に悩んでいる方がいれば、この記事が少しでも助けになれば幸いです。
最後に、BuySell Technologiesではエンジニアを募集しています。ご興味のある方は、ぜひご応募ください。
