読者です 読者をやめる 読者になる 読者になる

ボクココ

サービス開発を成功させるまでの歩み

ライブラリの利用を減らしていくことの重要性

ども、@kimihom です。

最近の運用フェーズでの開発で意識していることの一つ、「Gem ライブラリの利用を減らす」ことについて思うことを書く。 記事の内容は Ruby 周りに最適化されているけど、他の言語でも同様のことが言えると思うので適宜置き換えて読んでいただきたい。

初期フェーズによるライブラリの利用

新サービスを作る段階では、「いかに早く機能を作り、検証しながら機能を作り直していくか」が大事になってくる。その時にいちいち機能をゼロから自分で作っているようでは時間の無駄だ。第三者が作ってくれた、ライセンス的に問題ないライブラリをシステムに組み込み、作っては壊しての繰り返しで機能検証していくことが大事になってくる。サービス開発初期でライブラリを使う理由は「機能を素早く実現するため」にある。だからちょっとした機能でも Gem で入れまくることになる。

これは全く問題ない。むしろ推奨されることだと思う。開発スピードを強みすることが第三者(特に大企業)と差別化する上で重要になる。小規模チームでの小回りの速さは確実に武器になる。

プロダクトマーケットフィット後のプロダクト

しばらくして見事サービスがプロダクトマーケットフィットの段階になれば、今度はサービスを集中して磨き上げることが大事になってくる。そこではより確実に素早くソースコードを改善していくことが求められる。

わけがわからんが、なんとなく動いている。” そんな状態を少しずつ無くしていこう。例えば以下のような時に役立つ。

サービスの最適化に役立つ

基本的にライブラリは、あらゆる利用を想定した作りになっているため、カスタマイズ項目がたくさんある。そしてそのぶん、ソースコードは Fat になり複雑になる。ライブラリの機能がさほど複雑なロジックを必要としない場合には、自前で実装することで無駄な処理を実行することがなくなる。より速く効率的な実行速度を実現でき、今後の独自の拡張性を見込める機能を実現することができる。

独自の拡張性は、今後のサービスの差別化に役立つ。プロダクトマーケットフィットの段階以降は、サービスに最適化された機能を多く増やしていくことが大事になってくる。競合が出て来ても、簡単には真似できないようなサービスをコツコツ実現していくのだ。

まずはマイナー系のライブラリから最適化することをお勧めする。そのようなライブラリは基本的に自前でも十分実装できるからマイナーなままであるパターンが多いからだ。 ちょっとした実装で実現できそうな Gem ならわざわざ使わずに自分で作った方が適したものになる可能性が高い。

反対に視点を変えるとライブラリを使い続けることで、Gem 自体がコミュニティの力でどんどん進化していくという側面がある。てことでライブラリを使用する/しないの見極めが必要だが、まずはほとんどアップデートの無いライブラリから削除することを検討するようにしている。

起動時の使用メモリを省略できる

起動時に大量のライブラリを読み込むと、そのぶん大量のメモリを必要としてしまい、無駄にサーバーリソースを消耗することになる。ライブラリを減らさずに増やし続けてしまうと、それがいつか限界を迎えて Out of Memory のエラーが発生することがある。

使用メモリを把握するには、Derailed Benchmarks などの Gem をインストールして調査してみよう。あまり使っていない Gem が案外無駄にメモリを消耗していたりする。そういうのは優先的に外していって自前で実装していくようにしよう。

GitHub - schneems/derailed_benchmarks: Go faster, off the Rails - Benchmarks for your whole Rails app

Gem のほとんどの機能は使わないけど、どうしてもその Gem を使わないといけないような場合、 require するものを最小限にとどめることで対応が可能だ。例えば、 rack-cors を入れる時には require で読み込むものを限定している。以下ような書き方で、ライブラリの利用を最小限にとどめることができる。

gem 'rack-cors', :require => 'rack/cors'

こうしてより多くのアクセスを少ないサーバーリソースで運営することもできるようになる。そして何より、自分の理解している範囲でコードが動いているという安心感。問題が起きても自力でデバッグすることができるだろう。

独自実装でオープンソース公開の機運ができる

独自に実装した何かが第三者に公開できるようなものが出てくる場合がある。その時はコミュニティに貢献するチャンスだ。うまくライブラリ化して逆に公開しよう。そしてうまく実装してマーケティングもうまくいけばスター数がつくかもしれない。そのようなライブラリを持つことを増やすことがエンジニアの価値だと考えている方にとってはまさに理想的なオープンソースの公開方法ではないだろうか。

オープンソースで公開すると、どうしてもカスタマイズでオプションをたくさん作るようなことが必要になるかもしれないが、その方針を決めて作るのもコミッタであるあなた次第だ。そんな自由なオープンソース活動を実現することができる。

終わりに

改めて注意書きするけど、最初からライブラリの利用を減らすべきとは書いてはいない。あくまでプロダクトマーケットフィットを達成した後のサービスの最適化の段階でやっていくべきだ。だからサービス初期のエンジニアと、サービス成熟期のエンジニアの求められる役割は違う。

ライブラリの利用を減らして、独自の価値を持つサービスがどんどん増えていくといいなと思っている。