Journal

単体バイナリで配れるだけで、ソフトウェアは少し信用しやすくなる

私はメインPCでWindowsを使っています。小さな道具を足すたびに思うのですが、インストーラの説明が長いソフトは、それだけで少し警戒します。何を入れるのか、どこへ入るのか、消すときに何が残るのかが見えないと、その時点で少し引きます。その説明が曖昧なまま進む道具は、便利そうでも手が止まります。

もちろん、全部が単体バイナリで済むわけではありません。GUIが重い道具もありますし、ランタイム前提のソフトにも事情があります。ただ、自分のPCで毎日使う小さな道具くらい、もっと話が早くていいと思っています。ファイルを置けば終わります。消すときもそのファイルを消せば終わります。この単純さは想像以上に効きます。

インストーラの説明が長いと、それだけで身構える

最近のソフトは、使い始める前に文化圏ごと連れてこようとします。ランタイムを入れて、アップデータが常駐して、設定用のディレクトリが増えて、気づくと何が本体なのか見えにくくなります。私はあの感じがあまり好きではありません。大きなアプリならまだ納得できますが、数秒で済む作業のための道具まで同じ顔をしていると、さすがに重いです。

これは好みの話でもあります。ただ、好みだけではありません。自分の所有物なのだから、自分で触れて、自分で消せて、自分で把握できるほうが健全です。少なくとも私はそう思います。中身を見たいときに見られること、置き場所を自分で決められること、その程度の自由は最初からほしいです。

単体バイナリの道具は、その点で説明が短いです。配布するときに「これを置いて実行してください」で済みます。アンインストールの説明も短く終わります。こういう短さは、手抜きではなく礼儀に近いです。相手の環境へ余計なものを持ち込まない、という態度が最初から見えます。

Goで小さな道具を書くと話が早い

少し前に、ダウンロードフォルダの更新ファイルを新しい順に5件だけ出す小さなCLIをGoで30分ほどで書きました。派手なものではありません。でも朝に一回叩くだけで、昨日何が落ちてきたのかすぐわかります。こういう道具は、凝った機能より起動の速さと説明の短さのほうが大事です。

Goが好きなのは、この手の小ささをそのまま配りやすいからです。コードが特別おしゃれだからではありません。main関数を書いて、ビルドして、できたものをそのまま置けます。この素直さがかなり大きいです。私はGoのことをときどき「現代のC言語」くらいの気分で見ています。OSに近いものへ触りやすいのに、昔ほど神経を削られません。

記事を書く前に、Dockerで本当に雑な確認だけしました。ホスト側を汚したくなかったので、`docker run –rm` だけ使っています。

docker run --rm -v /tmp/hasilan-go-verify:/src -w /src golang:1.24 \
  go build -trimpath -ldflags='-s -w' -o recent-linux-amd64 main.go

docker run --rm -v /tmp/hasilan-go-verify:/src -w /src \
  -e GOOS=windows -e GOARCH=amd64 -e CGO_ENABLED=0 golang:1.24 \
  go build -trimpath -ldflags='-s -w' -o recent-windows-amd64.exe main.go

wc -c /tmp/hasilan-go-verify/recent-linux-amd64 \
      /tmp/hasilan-go-verify/recent-windows-amd64.exe
file /tmp/hasilan-go-verify/recent-linux-amd64 \
     /tmp/hasilan-go-verify/recent-windows-amd64.exe

返ってきたサイズは Linux 版が 1,433,784 バイト、Windows 版が 1,531,392 バイトでした。`file` の出力では Linux 側が statically linked と出ています。たったこれだけです。小さなCLIなら、配布の説明もかなり短くできます。

AIにボイラープレートを書かせること自体は、いまの私は普通にやります。退屈なところまで全部手で打ちたいわけではありません。ただ、最後に配る形まで曖昧だと、一気に冷めます。実行に何が要るのか、自分で追えない道具は、自分のものになりきりません。

配れる形が、そのまま態度になる

ソフトウェアの印象は、機能表より先に配り方で決まることがあります。単体バイナリで渡されると、それだけで作者が何を省いたか見えます。依存関係を減らしています。説明を減らしています。相手の環境に踏み込む量も減らしています。その節度はかなり信用できます。

逆に、ちょっとした補助ツールなのに常駐プロセスや分厚いランチャーがついてくると、私は身構えます。動けばいい、では済まないからです。毎日触る道具ほど、起動までの体験や消しやすさがそのまま評価になります。ここを雑に扱うソフトは、長く手元へ残りません。

非エンジニアがAIに丸投げして道具を作る話も増えましたが、配布の段階まで来ると急に化けの皮がはがれます。動いた画面は作れても、どう置くのか、どう消すのか、壊れたらどこから見るのか、そのあたりで一気に苦しくなります。そこを他人任せにしたままでは、自分のPCの上で起きていることを理解できません。

だから私は、小さな道具を書くなら最後は単体バイナリへ寄せたくなります。全部をそうすべきだとは言いません。でも、自分で使うもの、自分の友人に渡すもの、そのくらいの距離のソフトなら、その単純さはかなり強いです。速いですし、迷いません。何より、自分のPCへ置く理由を自分で説明できます。私はその説明が短い道具を、長く手元へ残します。

Previous