新しいツールを保存する前に、試用カードを一枚書く

ツールの紹介記事を読むと、新しい名前はすぐに覚えられる。難しいのは、そのあとで判断することだ。軽い、強力、見た目がよい、と説明されても、ページを閉じた読者にはまだ問いが残る。自分のどの作業を助けるのか。何を差し出すのか。試したあと、残すか消すかをどう決めるのか。

新しいものを見つけるのは私も好きだ。ただ、ブックマークが一つ増えるだけなら、記事ができることは少ない。「試す価値がある」と言うより、試す前に書ける小さなカードを渡したい。

製品名より先に、困りごとを書く

一行目には、いま起きている問題だけを書く。たとえば「引き継ぎの前に二つの設定を手で照合していて、項目を見落とすことがある」。「設定管理ツールを探したい」より狭いが、そのぶん確かめやすい。

次に、現在のやり方を書く。スクリプトかもしれないし、表や十分間の目視確認かもしれない。新しいツールは、この実際の基準と比べる必要がある。元の負担が分からなければ、「効率が上がる」は響きのよい形容詞で終わってしまう。

最後に、受け入れられない負担を挙げる。データを第三者に渡す必要はあるか。既存のファイル形式を変えるか。チームで保守できる人が一人だけにならないか。万人に共通する正解はない。同じツールでも、個人の実験にはよく、共有の作業には重すぎることがある。

試用カードには、反証できる二つの文を加える。

コピーしたデータで具体的な作業を終え、結果を自分で確認でき、やめても元の方法に戻れるなら、残すことを考える。

導入と移行にかかる時間が節約できそうな時間を超える、または重要な結果を確認できないなら、そこで止める。

「コピーしたデータ」が大切だ。捨てられる材料なら失敗を観察できる。毎日使う手順を最初から新しいツールに預けると、試用はいつの間にか「使い続けるしかない」状態になる。

時間の区切りも決めておく。まずは三十分とし、終わったら何ができたか、どこで止まったか、次にどれだけ手間が要るかを記録する。三十分で製品の良し悪しを決めるわけではない。好奇心が知らないうちに長期の約束へ変わるのを防ぐためだ。

試用のあと、長いレビューを書く必要はない。三行あれば足りる。

三行目は形式だけの断り書きではない。あとで読む人に、その結論がどこまで使えるかを伝える。動かしていないなら、文書の例を自分の体験として書かない。紹介を読んだだけでも、「検証してみたい案だ」と正直に残せる。

このブログはこれまで小さなプロジェクトを数多く紹介してきた。これからも、面白いと思った GitHub のツールを書くことはある。ただし、プロジェクト名を毎日の出発点にはしない。読むこと、書くこと、小さなサイトを維持すること、時間をかけて考えたい問いも、記事にできる。

何を書くにしても、確かめられる事実を一つ、適用できる範囲を示した判断を一つ、まだ答えのない問いを一つ残したい。今日の試用カードはその最初の練習だ。次に「保存」を押したくなったら、先に解決したいことを書いてみる。書けないなら、いま必要なのは別のツールではないのかもしれない。