【ITニュース解説】I graded every package for how badly it wants to leave

あるプログラマーが、自身が作成した「go-tool-base（GTB）」というフレームワーク内の各部品（パッケージ）を、他の場所で再利用するためにどのように評価したのか、その過程とそこから得られた教訓について解説する。システムエンジニアにとって、既存の大きなシステムから特定の機能を切り出して再利用することはよくある課題であり、この記事はその課題解決への実践的なアプローチを示している。

GTBは、ログ記録、設定管理、通信、コマンドラインインターフェース（CLI）など、多岐にわたる機能が最初から連携するように設計された「オールインワン」のフレームワークだ。しかし、開発を進めるうちに、筆者はこのフレームワークの特定の部品をGTBの外でも使いたいと考えるようになった。例えば、署名関連の機能は既に独立して利用できる状態になっていたという。この目的は、GTBというフレームワーク自体を壊して分解することではない。あくまで、GTBの優れた統合体験を維持しつつ、フレームワークから独立しても価値のある部品を見つけ出し、それを分離するためにどれくらいの作業が必要になるかを明確にすることにあった。

特定の部品を切り出すという課題に対し、プログラマーは直感で判断することがある。しかし、直感は往々にして、その週に最も不便を感じたものや、目の前の作業の容易さに左右されがちだ。そこで筆者は、この課題に客観的に取り組むため、GTB内の二十七のパッケージ全てに対し、四つの異なる観点から十点満点で評価する手法を考案した。

その四つの評価軸とは次の通りである。まず「抽出（Extraction）」は、そのパッケージがそもそも独立したモジュールとして存在するべきかどうかの総合的な推奨度を表す。次に「パッケージ価値（Package value）」は、そのパッケージをフレームワークなしで使いたい人にとってどれくらいの価値があるかを測る。例えば、特定のAPIと連携するライブラリなどがこれに該当するだろう。三つ目の「コード品質（Code quality）」は、プログラムの構造がどれだけ整っているか、テストしやすいか、他のプログラムから利用しやすいインターフェースを持っているか、といった技術的な成熟度を評価する。これら三つの評価軸は、一般的に期待されるものであり、概ね互いに高い相関を示す傾向がある。品質が良いコードは価値があり、価値のあるものは丁寧に作られていることが多いためだ。

そして四つ目の軸である「デカップリングの容易さ（Ease of decoupling）」は、他の三つとは異なる、この評価の肝となる項目だ。これは、そのパッケージをフレームワークから切り離すために、どれだけフレームワーク固有の依存関係を取り除く必要があるかを測る。つまり「独立させるべきか」ではなく「独立させられるか」を評価する。この「パッケージ価値」と「デカップリングの容易さ」という二つの異なる問いを分けて評価することが、この取り組みの重要なポイントであった。

この評価によって、興味深い事実が明らかになった。例えば、「chat」というパッケージは、複数のAIプロバイダーと単一のインターフェースで通信するGo言語ライブラリであり、フレームワークに依存せずに利用したいというニーズが高く、パッケージ価値は最高の十点満点だった。しかし、デカップリングの容易さの評価では、二十七個のパッケージの中で最低レベルの四点という結果になった。これは、chatパッケージがGTBのHTTPヘルパー、設定管理、認証情報、ログ記録といった様々な内部機能に深く依存していたためである。個々の依存関係は小さいものでも、それらが積み重なることでパッケージ全体がフレームワークに強く固定されていたのだ。

一方、「redact」や「regexutil」といったパッケージは、デカップリングの容易さで十点と評価され、短時間で分離できる見込みがあったものの、そのパッケージ単体での価値はchatパッケージに比べて低いとされた。この結果は、「価値の高いものが必ずしも簡単に分離できるとは限らない」という直感に反する事実を示している。直感では「chat」のような価値の高いパッケージを何とかしたいという漠然とした感情が生まれるが、それが「最初にやるべきか、最後にやるべきか」という具体的な行動計画までは導き出してくれない。しかし、このように数値化し、価値と容易さを分けて評価することで、どの作業から着手すべきかという「作業の順序付け」が明確になるのである。

具体的な作業順序としては、まずフレームワークとの結合度が低い、いわゆる「リーフユーティリティ」と呼ばれる簡単なパッケージ（redact、regexutilなど）から着手する。次にユーザー向けのCLIヘルパー、さらにセキュリティや実行時の基盤となるパッケージを分離していく。そして、最も価値が高く、しかし分離が困難だったchatパッケージは最後に手がけることになる。これは、「簡単なものから先に片付ける」という考え方に基づいている。簡単な作業を進めることで、フレームワーク全体の結合度が徐々に下がり、最終的にchatパッケージの分離に必要な作業量が減っていくためだ。つまり、最初の作業でchatパッケージのデカップリング評価が低かった原因の一部が、それまでの作業で自然と解消されることを意味する。

また、この評価は「どこまで作業を行うか」という判断基準も提供した。例えば、評価点が五点以下のパッケージは、今回の分離対象から完全に除外するという決定を下すことができた。このような基準がなければ、全てのパッケージがTo-Doリストに残り、どれから手をつけるべきか、あるいは本当にやるべきかという議論が尽きなくなる可能性がある。

しかし、この評価方法も万能ではないという教訓も得られた。例えば、デカップリングの容易さで高得点だった「logger」や「forms」といったパッケージは、実際には分離されずに削除されたり、フレームワーク内に残されたままであったりする。筆者が最も自信を持っていた「デカップリングの容易さ」の評価が、結果的には間違っていたという意外な結末になったのだ。価値の高いchatパッケージに関する予測が外れることは予想できたが、簡単に分離できると判断したパッケージについての誤りは、客観的な数値評価であっても、完全に正確な未来を予測することは難しいということを示している。

このように、この取り組みは、大規模なソフトウェアから特定の機能を切り出して再利用するという、システムエンジニアが直面する具体的な課題に対し、客観的な評価軸を設定し、数値に基づいて判断することの有効性と限界を教えてくれる。特に、作業の優先順位付けや、どこまでやるかの判断に評価が役立つ一方で、評価結果を過信せず、常に現実の状況に合わせて柔軟に対応する重要性も示唆している。