公開直後に気づいたミス
5月1日の夜、Zennに技術記事を公開しました。
公開した直後に読み返していたら、マークダウンの強調記号がそのまま表示されてしまっている箇所と、画面配置の説明で数を数え違えている箇所に気づきました。決して大きなミスではないのですが、見つけてしまうと気になるものです。
普段は「完璧にしてから出す」スタンス
自分の中には、公開前に完璧な状態にしてから出す、というスタンスがずっとありました。
ミスがある状態で人の目に触れさせたくない、という感覚が強くて、公開前の見直しにはいつも時間をかけています。今回も、ミスに気づいた瞬間はその感覚が真っ先に出てきました。
今回は、出したまま直すことを選んだ
ただ今回は、公開したものを一旦そのままにして、気づいたミスをその場で直して再pushする、という流れを選んでみました。
Zennの記事はGitHubリポジトリと連携していて、修正をpushすれば数分後には反映される仕組みになっています。修正してから読み返すと、特に違和感なく直った状態になっていました。
なぜ抵抗なく直せたのか、を観察してみると
振り返ってみると、修正してpushすれば数分で反映される、という仕組みがすでに整っていたことが大きかったように思います。
修正のコストが低いと、公開前に完璧を求める必要性そのものが薄れていく感覚がありました。「完璧に仕上げてから出す」ではなく「出してから整える」でも十分に機能する、という体感を持てたのが今回の収穫です。
仕組みが心理を変える、という気づき
このやり取りを通じて感じたのは、公開への心理的なハードルを下げているのは気合いや慣れではなく、仕組みそのものかもしれない、ということです。
直す動作から反映までの距離が近いほど、公開への抵抗も自然と小さくなっていく気がします。CI/CDや自動デプロイの威力を、規模は小さいながらも自分の発信の中で体感できた出来事でした。
Zennだけでなく、このLife Builderでも同じような仕組みを整えられたら、公開のハードルはもう少し下がるかもしれません。「まず出す→直す」を支える仕組みづくりは、これから学んでいくフロントエンドエンジニア的な考え方にも近いところがある気がしています。
