diff --git a/content/post/実装を義務とする.md b/content/post/実装を義務とする.md
index c8cd252..8caf7c9 100644
--- a/content/post/実装を義務とする.md
+++ b/content/post/実装を義務とする.md
@@ -11,11 +11,11 @@ tags: ["essay", "diary"]
 
 特にエディタを用いる一括リネーム機能は以前から様々なツール（たとえば[mmv](https://github.com/itchyny/mmv)は有名だ）で世話になっていたこともあり、この機会に自分の手で実装して処理を把握しておきたいモチベが強かった。今回の開発を通して最低限の勘所を掴めたと感じている。
 
-あまり頻繁にリネームをしない人はピンと来ないかもしれないが、GUIベースで数十ものファイルの命名規則を合わせたり一貫性を持たせるのは意外に大変だ。その都度、前提条件に沿ったルールを作成したりいちいちスクリプトを書くのも面倒くさい――しかしエディタを――とりわけVimを――自由に扱えるなら話は別だ。どんなファイル群でも秒でケリがつく。
+あまり頻繁にリネームをしない人はピンと来ないかもしれないが、GUIベースで数十ものファイルの命名規則を合わせたり一貫性を持たせるのは意外に大変だ。その都度、前提条件に沿ったルールを作成したりいちいちスクリプトを書くのも面倒くさい。しかしエディタを――とりわけVimを――自由に扱えるなら話は別だ。どんなファイル群でも秒でケリがつく。
 
 とはいえ、もともとライブラリの豊富な言語を使っているだけに、機能面の実装に困るところはさほどなくコーディングコストの大半はエラーハンドリングに費やされたように思う。つまり、この開発にチャレンジングな要素は本質的には皆無と言って差し支えない。
 
-にもかかわらず、あえて手を動かさざるをえなかったのは教本を片手にサンプルコードを真似しているだけでは習熟度が緩やかすぎること、業務として振られてから学びはじめていては遅すぎるキャリアになりつつあることなどが挙げられる。
+にもかかわらず、あえて手を動かさざるをえなかったのは教本を片手にサンプルコードを真似しているだけでは習熟度が緩やかすぎること、業務として振られてから学びはじめていては遅すぎるキャリアになりつつあることなどが挙げられる。なにかを事前に作り上げておかないと感覚が間に合わない。
 
 今回、実装にTypeScriptを採用したのも別にこの言語が好きだからではない。興味ありきならたぶんGoとかを選んでいた。春先に投入されるRailsの案件においてフロントエンド部分がTypeScriptで実装される予定であり、弊社の規模感からいって開発チームの完全な分業化は難しいと考えられるためだ。まず十中八九、フロント側もやらされる羽目になる。