概要

プロジェクト利用する依存ライブラリのメンテナンスを放置すると、セキュリティ、パフォーマンスの問題もさることながら、ライブラリの数もどんどん増え続けます。これを放置すると生産性の低下にも繋がります。この問題に対処するべく開発したCLIツールstay_or_goの紹介とそれを利用したソリューションの提案をします。

‣

目的

プロジェクトで利用している依存ライブラリのスコアリングして、依存ライブラリの棚卸しをすることで、フレームワークやプログラミング言語のアップグレードを迅速に行えるようにしたり、生産性の向上を図ります。

対象読者

CTOやSRE、リードエンジニアなどを技術的負債の解消についてプロダクトオーナーや決裁権のある人に説明責任がある人対象とします。

PR

UZUMAKIではアジャイル開発で新規事業の開発から、大規模Webアプリケーションのアーキテクチャ更新などの開発をしています。

お問い合わせはUZUMAKIのHPのお問合せフォームから

株式会社UZUMAKI

UZUMAKI（うずまき）はエンジニア・デザイナー・ディレクターで構成されるギルド型開発チーム。成長するWebサービスやアプリのリニューアル・リファクタリングに強みがあります。

uzumaki-inc.jp

本文

こちらは、そのライブラリ、続投?それとも解雇?「stay_or_go」で素早く決断! 🚀と題して

ゆるSRE勉強会 #8 というSREの勉強会でLTをした際の登壇内容を補足したものです。

LT登壇資料はこちら

ライブラリの更新の放置がプロジェクトに与える影響

まず初めに技術的負債について簡単に振り返りましょう。技術的負債は、短期的効率優先の妥協が長期的なメンテナンスコストやリスク増大につながる現象です。今回はその中でも依存ライブラリの放置に焦点を当ててその対策を方法をご紹介します。

ライブラリの更新の放置の悪影響

事例1: セキュリティ脆弱性の増加

古い依存ライブラリの使用はセキュリティリスクを高めます。

例: タリーズコーヒージャパンのECサイトでは「slick.min.js」の脆弱性によりクレジットカード情報漏えい。(参考)

事例2: プロジェクトのスケールが難しくなる

更新されないライブラリは互換性を失い、新機能開発が停滞。

フレームワークや言語アップグレード、開発者採用にも悪影響。

確認事項:

利用しているライブラリの最終更新時期はいつでしょうか？

定期的にチェックしていますか？
常に最新版にしていても、更新が止まっていることを意識しているプロジェクトは少ないのでは？

フレームワークや言語のアップグレードの際に、古いライブラリがアップグレード作業の足かせとなっていませんか？

依存ライブラリを放置すると技術的負債は拡大しますが、適切なツール・戦略で抑制可能です。その鍵の一つとして私が開発したstay_or_goがあります。

stay_or_goがもたらす安心

stay_or_goとは依存ライブラリを可視化・整理し、リスク低減を支援します。

1. 問題解決へのアプローチ

依存ライブラリを定義するファイル。RubyではGemfileやGo言語ではgo.modをスキャンしてすべての依存ライブラリを後述する方法でスコアリングしレポートを作成します(多言語にも対応予定)。

この事により

更新優先度不明: スコアで明確にし、客観的な指標を提示します
合意形成困難: レポートでチーム内に論点を共有します

2. stay_or_goのユニークポイント

(1) ライブラリ評価

ライブラリがホスティングしているGitHubのリポジトリ情報をGithub APIを使い下記の観点で計測し、それらに係数をかけてスコア化します。

スター数、ウォッチ数、フォーク数で人気度を計測
オープンしているIssue数、最終更新頻日からの経過日数で活発さを計測
アーカイブされているかで、メンテされているか否かを計測

これらのスコア化する係数はデフォルの戸の係数以外にもymlファイルで独自に変更することが可能です。

(2) レポート出力

Markdown形式のテーブル、CSV、TSV出力でチーム共有容易。

Markdown形式のテーブルにすることで、Notionのデータベース化できます。

CSV・TSVでエクセル等に貼り付けることもできます。

Markdown形式のテーブルでの出力結果例

Name	RepositoryURL	LastCommitDate	...	Score
activeadmin	https://...	2024-11-25T21:00:24Z	...	1282
active_decorator	https://...	2024-11-04T14:51:22Z	...	121
active_decorator-rspec	https://...	2017-03-15T12:48:01Z	...	-137
activerecord-import	https://...	2024-11-16T06:00:21Z	...	466

フルのデータはこちらをNotionのリンクを参照して下さい

https://x.gd/KvPY5

(3) 簡易な導入

CLIツールとして手軽に導入可能。ミドルウェアなどは必要ありません。

導入した際の動は下記のデモのように動かします。

このデモ動画では、CLIツールを実行し、markdownのテーブル形式で出力した結果を、Notionのデータベースに変換しています

3. 他アプローチとの比較

Rubocopなど静的解析ツール: コードの書き方をチェック
Coverbandなど本番環境カバレッジ: 使われていないコードを見つけ出す
dependabotなど脆弱性診断ツール: 脆弱性が発生したライブラリを報告

stay_or_goは依存ライブラリ管理に特化し、他ツールと補完関係。

結論: stay_or_goの独自価値

stay_or_goで依存ライブラリの放置による技術的負債を最小化し、チームを安全・効率的な開発へと導きます。

ぜひ導入を検討してください。

ストーリー形式の紹介: stay_or_go導入で解決への道筋

問題の発見: 限界に近づいたプロジェクト

中規模ECプラットフォームを7年以上運用し、依存ライブラリは約150。

結果として以下が顕在化:

脆弱性の放置: 2年以上更新なし
アップデート困難: 依存ライブラリの互換性問題で工数増、フレームワークやプログラミング言語のサポート終了から数年経過
開発速度低下: 古い実装方法と新しい実装補方法が混ざりコーディング規約が崩壊し、新機能リリースに1.5倍時間要
メンバーの定着率の低下: ベテラン社員がモダンな環境を求めて退職、中堅以上の中途採用も古めかしい環境のため決まらない

行動の第一歩: stay_or_goの導入

依存ライブラリ整理のため、チームはstay_or_goを導入。

ステップ1: 状況可視化

依存ライブラリを一覧化してスコアリングし、問題を明確化。

ステップ2: 指標の策定と、優先順位決定

スコア下位20%を調査、改善対象とする

ステップ3: 改善アクション

利用確認: 不要ライブラリ排除
アップデート: 最新版へ更新
置き換え: 信頼性ある代替へ
削除: 不要ライブラリ除去

ステップ4: 定期検診

ステップ1-3を3ヶ月〜6ヶ月毎に実施

成果

依存ライブラリ数を15%削減: 約150→約130
開発速度10%向上

プロジェクトでの適用方法

stay_or_goは依存ライブラリ管理問題を効率解決します。

1. 初期設定

インストール

下記のgo installやstay_or_goのgithubリポジトリのリリースからDL。

go install github.com/uzumaki-inc/stay_or_go@latest

GitHubトークン取得

GitHub Personal Access Token取得、PublicリポジトリRead権限付与。

2. プロジェクトへの適用

スキャン実行例

stay_or_go ruby -i Gemfile --format markdown --github-token YOUR_GITHUB_TOKEN

i: ファイル指定
format: 出力形式指定
github-token: GitHub トークン

結果確認

stay_or_go table 出力結果例フル

このスコアを参考に更新・置換・削除決定。

定期スキャン

CI/CD統合で継続的監視(GitHub Actions対応も検討中)

結論: 今日から始める技術的負債解消

簡単な設定で負債を可視化し、改善行動へ移せます。

ぜひstay_or_goを活用してください。

stay_or_goが生み出す結果

セキュリティリスク軽減
開発効率向上
負債予防
チーム内連携強化

stay_or_goで楽しい開発体験を目指しましょう。

UZUMAKIではツールだけでなく包括的支援を提供

さて、実際にstay_or_goでスキャンしたあとに、低スコアな調査対象のライブラリがわかりました。

そのライブラリが実際に使われているのか？またどこで使われているのか？
そのライブラリは代替ライブラリに置き換え可能か？比較してパフォーマンス計測をどうするのか？
そのライブラリは簡単なメソッドやクラスに置き換えられないか？

などなどなかなか骨の折れる作業です「ではこれらの作業を実際に誰が行うか」という悩みに、我々UZUMAKIがツール＋サポート＋知識共有で応えます。

1. 包括的サポート

専門家コンサルティング

スキャン結果分析で改善計画提案。

事例:

B2Bプラットフォームで半年15%削減、リリース速度20%向上。

ワークフロー改善

CI/CD統合やレポート活用で負債管理を定着化。

2. 継続進化

機能拡張

ベストプラクティス反映、改善継続。

カスタマイズ

特定フレームワーク対応や大規模環境最適化。

事例:5,000超ライブラリ管理、ダッシュボード活用で迅速決定。

3. コミュニティ活用

課題共有

フォーラムやSlackで成功事例・課題共有。

ベストプラクティス共有

ケーススタディ、技術記事で常に最新情報入手。

4. 成果で語る価値

中規模プロジェクト: リリースサイクル1.5倍化
エンタープライズ: 3年以上放置ライブラリ整理でセキュリティ大幅改善

PR

XではUZUMAKIの新しい働き方や日常の様子を紹介！ぜひフォローをお願いします！

noteではUZUMAKIのメンバー・クライアントインタビュー、福利厚生を紹介！

UZUMAKI｜note

株式会社UZUMAKIです。主に代表の工藤が投稿してますが、ほかのメンバーもたまに投稿します。https://uzumaki-inc.jp/ 受託開発を生業としてますが、リモートワークを通じて、今までにない組織形態での働き方を模索、実践しています。

note.com

UZUMAKIではRailsエンジニアを絶賛募集中です。

↓の記事を読んでご興味を持っていただいた方は、ぜひ応募よろしくお願いします！

UZUMAKI 採用情報

これを実践するには、通常の社会で求められる上司による部下の管理が必要という前提が不要になってきます。例えば、時間管理をしない、圧倒的な性善説で動く、メンバーは自発的に動くということをUZUMAKIでは当たり前のように行っております。現在は、コーポレートサイト記載の企業 ...

job.uzumaki-inc.jp

是非応募宜しくおねがいします！

依存ライブラリの肥大化にお困りのあなた「stay_or_go」で棚卸し！

概要

目次

目的