本記事は日頃筆者がパッケージアップデートという活動に関して思っていることを書き出した記事です。ちなみに筆者はこういうものです (Wantedly, Inc. 所属)

はじめに

筆者の所属する会社でも「なぜ我々はパッケージアップデートを行うのか」「どういう戦略でパッケージアップデートを行うのか」についてたびたび議論されています。これはなかなか難しいトピックで完全に全員の意見が一致したり、深く整理しきれないまま先に進むことも多いです。

さて、筆者もそんな状況にのまれてしまっていた一人ではありましたが先日公開された@autotaker1984 さんのソフトウェアはなぜバージョンアップしなければならないのかという素晴らしい記事を読んで心にくるものがありました。見事に触発されてしまったので筆者も一度自身がパッケージ (ソフトウェア) アップデートに対して思っていることを書き出してみようと思います。^[1]

記事まとめ

パッケージアップデートの必要性は「事業の継続性の確保と長期的なコスト (リスク) 削減のため」だと考える
- ソフトウェアには有効期限がある
- 事業は継続する
- パッケージをアップデートするコスト (リスク) は時間経過と共に指数関数的に増加する
この整理に当てはめると必ずしもパッケージアップデートは必要とはいえない
- ソフトウェアに有効期限がないケース
- 時間経過によるコスト増加がみられないケース
- 事業の継続が怪しいケース
バージョンアップデートによる新機能の獲得は個々のバージョンアップでは目的化される可能性はあるが、日々の活動そのものの目的にはならないと考える
パッケージをアップデートするコストとは「人・時間・金・リスク」だと考える
ソフトウェアの有効期限を予測する技術、コスト増の速度を考慮する技術がある
何はともあれ組織文化が大事

パッケージアップデートが止まると事業が止まる

前提としてソフトウェアは絶えず変化し、事業を継続する^[2]ためにはその変化に対応していく必要があります。パッケージアップデートはその最たる例です。

ソフトウェアはなぜバージョンアップしなければならないのかでも述べられていますが、ソフトウェアには「有効期限」が存在します。具体的には以下のような有効期限です。

脆弱性の発見
他のパッケージやライブラリとの連携の問題
開発サポート終了

これらの問題に対応しないまま時が過ぎてしまうと、事業として提供している機能は徐々に壊れ始め、やがてサービスとしての価値提供は止まってしまいます。

パッケージアップデートにかかるコスト

とはいえパッケージアップデートを行うには一定のコストを支払う必要があります。筆者はパッケージアップデートにかかるコストは「人・時間・金・リスク」だと考えています。

1. 人的リソース

パッケージアップデートではその性質上、作業の過程で専門知識が求められる場合が多いです。特に複雑なシステムやライブラリを使用している場合、その知識を持ったエンジニアの時間は貴重です。またアップデートによって新しい技術や機能が導入される場合、チームメンバーにその知識を伝えるためのトレーニングが必要となることがあります。

2. 所要時間

パッケージアップデートによる変更を加えること、それ自体は大抵の場合、各技術プラットフォームに付随するパッケージマネージャ等を用いれば一瞬で済みます。しかしそれでも、アップデート後のシステムの挙動を確認するためのテストは欠かせません。特に大規模なアップデートの場合、これにはかなりの時間がかかることがあります。

また一部の特殊ケースではアップデート内容を理解するための前調査や問題が発生した場合の原因調査などに更なる時間を要することもあります。

3. 金銭コスト

特にインフラ領域のパッケージアップデートで多い話ですが、パッケージアップデートには少なくない金銭コストがかかる場合もあります。

例えば Kubernetes クラスタの運用に AWS のフルマネージドサービスである EKS を採用している場合、EKS のバージョンアップには node の入れ替え作業などが必要になり 1 クラスタあたりおよそ 10 万円~ ほどの金銭コストが発生します。

4. アップデート時のリスク

リスクは果たしてコストと言えるのか？という議論はありそうですが筆者はリスクもコストの一つだと考えます。

一般的にリスクとは、未来の不確実性に関連する潜在的な問題や悪影響を指します。これに対して、コストは上でも挙げたように資源、時間、お金などの犠牲や損失を指します。
しかしリスクが現実のものとなる場合、それは具体的なコストとして現れることが多いです。例えば、ソフトウェアのアップデートにおけるリスク（例: 予期せぬバグの出現）が現実化した場合、その対応に追加の人的リソースや時間が必要になることが考えられます。

そのため事業を継続させるためには、リスクを事前に潜在的なコストとして評価し、それを回避または最小化するための動きが求められます。

次章で詳しく扱いますが、これらの要因を適切に評価・管理しなければ、事業のために行うパッケージアップデートが逆に事業の負担となってしまうリスクが高まります。

パッケージアップデートにかかるコストを最適化するために

ここで抑えておくべき前提として 「ソフトウェアのアップデートにかかるコストは、時間の経過とともに指数関数的に増加する」 という特性があります。

ソフトウェアはなぜバージョンアップしなければならないのかでも「バージョンアップは先送りにすればするほど難易度が上がる」と述べられていますが一般的にソフトウェアがアップデートされない期間が長くなると一度に大量の変更を取り込む必要が出てきます。

この結果、アップデートにかかる時間やリソース、リスクが指数関数的に増加します。

そのため我々はよほど事業に余裕がない限りはパッケージアップデートにかかる時間やリソース、金銭、リスクといった諸々のコストを最適化するためにソフトウェアの有効期限の中でコスパの良いパッケージアップデートのタイミングを見極める必要があります。

例.

コスト軽減のために小まめにパッケージアップデートを行うケース
- このパッケージは変更追従の難易度が高いので、パッチバージョンが 1 つあがったらすぐにあげる
時間経過によるコスト増加の流れを読んでパッケージアップデート頻度を調整するケース
- このパッケージはほとんど breaking change が存在しないので、メジャーバージョンが上がったタイミングで上げれば問題ない

例外は存在する

ここまでパッケージアップデートの必要性について「ソフトウェアの有効期限・時間経過によるコストの増加・事業継続」の 3 本の柱に基づいて議論してきました。

当然これらの柱が崩れるケースではここまでの議論に例外が発生します。

ソフトウェアに有効期限がない

このようなソフトウェアは珍しいですが、完全に独立して動作し外部のリソースやライブラリに依存しないソフトウェアが該当するかもしれません。その場合、アップデートの必要性は低くなります。

時間経過によるコスト増加がない

ソフトウェアが絶対に breaking change を持たない場合、またはバージョンアップデートが非常にスムーズである場合は、アップデートのタイミングは柔軟に考えられます。

事業の継続が怪しい

事業の継続が不確実な場合、中長期的な戦略よりも短期的な戦略に重点を置くことが考えられます。高コストのアップデートよりも、即座の問題解決や新機能の追加に重点を置く方が良いかもしれません。

例.

一時的なプロジェクトやキャンペーン用のサイトやアプリで、一定の期間後にサービスを停止する予定のもの
短期間での ROI を重視するスタートアップやプロジェクト

新機能獲得はパッケージアップデートの目的？

ここまでの議論で登場しなかった視点として「パッケージアップデートの目的は新機能の獲得である」という意見があります。

たしかにこの意見で述べられている事実は正しいと思いますが、あくまで筆者は新機能の獲得は 「個々のパッケージアップデートにおける目的」 であると考えます。

あくまで事業観点で見ると新機能の獲得は日常のアップデート活動の主要な目的としては位置づけにくく、ソフトウェアの有効期限に紐づく安定性やセキュリティの維持が重要であると感じます。
^[3]

次の章で触れますが、この章の内容は日頃のパッケージアップデート戦略に組み込むことができます。

パッケージアップデート戦略を考えてみる

せっかくなのでここまでに整理したパッケージアップデートの必要性と特性をもとに具体的なパッケージアップデート戦略を考えてみることにします。

あくまで学習的な試みであり、一つの戦略案でしかないことに注意してください。

基本: ソフトウェアの有効期限切れを起こさない / パッケージの特性を理解して適切なアップデートのタイミングを決定する

事業を継続するために、ソフトウェアの有効期限が切れる前に必ず必要な対応を行う
- ソフトウェアの有効期限の監視のために GitHub 社の Dependabot alerts などを適宜導入し自動化を行う
- 有効期限が切れる前に必要な対応を行えるように組織内でパッケージアップデートにかかるコストについて認識を合わせて準備をしておく
長期的なパッケージアップデートコストの削減のために、パッケージの特性を理解して適切なアップデートのタイミングを決定する
- ruby や npm パッケージ群などのアップデートコストが増加しがちなパッケージはパッチバージョンが新たに出るたびに追従する
- golang のような breaking change が発生しないようなパッケージはメジャーバージョンが新たに出るたびに追従する

また以下の例外ケースでは個別のパッケージでアップデートの必要性が生じるまでパッケージアップデートの優先度は落とす。

例外ケース: 継続の予定がない事業

一時的なプロジェクトやキャンペーン用のサイトやアプリで、一定の期間後にサービスを停止する予定のもの
短期間での ROI を重視するスタートアップやプロジェクト

例外ケース: 特殊なパッケージ

独立して動作するソフトウェアやライブラリで、外部依存がない、かつ breaking changes がないもの

何はともあれ組織文化が大事

ここまでパッケージアップデートの必要性や戦略について議論を行ってきましたが、これらの整理を行っただけではパッケージアップデートは円滑に進みません。

実際には組織内の各部署がパッケージアップデートの必要性に関して共通認識を持ち、お互いの取り組みを理解しながら時に協力し合う必要があります。

ソフトウェアはなぜバージョンアップしなければならないのかでも記事冒頭でバージョンアップの必要性を共通認識とすることの難しさが指摘されています。

「今は忙しいからバージョンアップを先送りしてほしい」「このバージョンはスキップしてもよいのでは？」なんて声が各部署から聞こえてきます。バージョンアップの価値を各部署に理解してもらうのは大変です。

また部署を超えて手を取り合いながらパッケージアップデートを行うための文化の構築については、筆者は異部署間の協働という点でまさに DevOps と通じる部分が大きいと考えています。 DevOps に関する考えはそれだけでまた記事が書けてしまうくらいには分量があるのでここではあまり深追いはしないでおきます (また別の機会で)。

参考

脚注

Discussion