星取表のアンチパターン

技術選定をしていると、よく星取表を見かけることがあります。こういうのです。

	FeatA	FeatB
LibA	☓	◯
LibB	◯	☓
LibC	◯	◯

これだけみると LibC がよく見えますね。

オープンソースのライブラリ比較や、エンタープライズな SaaS が競合に対する優位を見せたいときに星取表が使われることが多いです。
中立な立場でライブラリを選定する過程として出てくることがあります。

自分はこれに全く意味がなく、むしろ競争的な立場では出した側が負けるものと認識しています。

星取表を作る側の意図

よく見かけるパターンがこれです。

1. 開発自体は長いため機能が豊富だが性能に劣る先発が、後発を貶めている
2. 恣意的な項目選定で、そもそも負けている
3. そもそも比較対象としての土俵が違う(全部入りのフレームワークと単機能なライブラリの比較)

特に 1 と 2 の組み合わせが多く、この裏では非機能要件で圧倒的に負けていることが多いです。例えば A は機能は豊富だけどビルドに 30秒で、Bは機能は足りないけど3秒だといった場合、多くの場合ではまず B を検討すべきです。特にパフォーマンスのハンディキャップは時間経過による負債と機能追加で劣化することが多く、A 側の改善は困難なことが多いです。

そもそも A の多機能性はレガシーなものに対して向けられていて B では作る必要がなかったりします。そして機能が足りないことは時間が解決することが多く、 SaaS なら売上が伸びて雇用が増えることで解決し、OSS なら B の方が人気を博して周辺ツールが揃うことで解決するでしょう。問題があるとしたら、自分が OSS に貢献しない限り、実装されるまでの時間が見積もれないことでしょうか。

中立な立場での星取表も、その作成者が何を大事に思っているかの表明であって、一般化できるものは少ないです。思考過程を参考にする程度でしょうか。

エンタープライズから出てくるものはもっと悲惨になりがちで、当人達は認知バイアスで真っ当な判断が下せる状態ではないため、より歪んだものになります。

何が言いたいかと言うと、いずれにせよ完璧に中立な星取表はなく、生まれた時点で恣意的だということです。

結論

先発から後発に対して出る星取表は断末魔