ソフトウェア開発ツールがチームを速くするわけではない
ツールがチームを速くするのではない。
チームが速く動けるのは、そこにいる人々、明確な目的、そしてプロセスがあるからだ。ツールがこれらを生み出すことはできない。
正しいツールが果たす役割はたった一つ。チームの足を引っ張るのをやめることだ。
多くのエンジニアリングチームは、悪いサイクルに陥っている。スピードが遅いと感じ、新しいツールを導入し、メトリクスを追跡する。しかし結果はまちまちだ。彼らは「ツールが間違っていた」と結論づけ、さらに別のツールを購入する。
このアプローチは間違っている。スピードを「足す」ためのツールを探すべきではない。摩擦を「取り除く」ためのツールを探すべきなのだ。
スピードを求めると、多機能でベンチマークの高いツールを買ってしまう。こうしたツールは往々にして複雑だ。それ自体に専門知識が必要となり、新たな摩擦を生んでしまう。
摩擦を取り除くことを目指すなら、地味なツールを選ぶことになる。一つのことをうまくこなすツールを探すのだ。既存のスタックと統合でき、メンテナンスの手間がかからないものだ。
最もコストのかかる摩擦は、IDEやCIプラットフォームの中にあるのではない。それらの「間」にあるのだ。
開発者がコードを書く。コミットをプッシュする。CIパイプラインが走る。結果がチャットアプリに表示される。人間がこれらのツール間で情報を移動させるたびに、時間は失われていく。
ツールを単体で評価するのはやめよう。摩擦は単一のツールの中に存在するのではなく、ツール同士の間に存在するのだ。
ツールを選ぶときは、次の4つの問いを自分に投げかけてほしい：
- チームは具体的にどこで時間を失っているのか？
- その特定の損失を解消するために必要な最小限のツールは何か？
- このツールは、現在使用しているものと統合できるか？
- システムの成長に伴い、どの程度のメンテナンスが必要になるか？
ツールの乱立（tool sprawl）を避けよう。同じ問題を解決するためにツールが多すぎると、混乱を招く。オンボーディングを困難にし、インシデント対応のあらゆる場面でスピードを低下させる。
最良のツールは、目に見えないものだ。実行し、報告し、そして邪魔をしない。機能し続けるためだけに絶えず注意を払わなければならないツールは、助けにはならない。
機能を買うのはやめよう。摩擦を取り除くことから始めよう。