「いかに楽をするために苦労するか」が成長度合いを決めると思う
たまには仕事の話でも。
いってもタイトル通りで終わりなんだけれどね。
僕は仕事では「今後の楽をするために今の苦労で買ってるなー」とよく考えてます。
エンジニア用語？で、DRYというのがあります。
Don't Repeat Yourselfの略で、
「すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない。」
という意味です。
書き下された以下の方がわかりやすいかもです。
何故これがDRY原則なのでしょうか？
DRY原則を破るということは、同じ知識を２箇所以上に記述することです。この場合、片方を変更するのであれば、もう片方も変更しなければならないのです。さもなければ異星人のコンピュータのようにプログラムは矛盾につまづくことになるのです。これはあなたが覚えていられるかどうかという問題なのではありません。これはあなたが忘れてしまった時の問題なのです。
このDRY原則は本書中のコーディングに関係のない部分でも何度も登場します。我々はこれが達人プログラマーの道具箱の中にある道具のうちで最も重要なものの一つであると考えています。
もっと噛み砕くと、「2回以上同じことすんな。しそうだったら【型】にしろ」ということです。
型とは、フォーマットであったり、マニュアルであったり、自動的に同じことができるちょっとしたプログラムなんかもそうです。
これって、エンジニアに限った話じゃないと思うんですよ。
「むっちゃ手間かかるなー」とか「毎月この作業すげー時間かかるんだよなー」っていうことこそ、一回時間をかけてでも型にして自動化すべきです。
今ではGPTsとかで簡単に作れますしね。
結果的に、その瞬間は苦労しますが、あとあとには計り知れないくらいの恩恵を受けることができるはずです。
例えば3時間使う作業が毎月ある場合は3×12ヶ月で36時間、これを8時間かけて自動化して30分に短縮できれば、8時間+0.5×12で14時間です。年間で22時間も生まれるわけです。
ミスがあった場合でも、自動化されたどこかを修正すればよく、毎月人の手でミスが発生するというリスクを抑えることができます。
もっというと、その自動化したものを社内に展開すれば×人数分の時間が生まれることになります。
そして生まれた時間を自身の成長に充てることができる、ということになります。
よって、「いかに楽をするために苦労するか」が成長度合いを決めると思うわけです。
私が業務でやったことがあるのは例えば、
ミスが多発していたフォームから登録する内容を自動チェックするChromeアドオンを作る
1枚に3分ほどかかっていた業務委託の方の契約書の作成を、リストから自動作成してPDF化するスクリプトを書く
など、日常的にどんどん作っています。
これでかなり楽をしています。
ただし、作るときには説明書も一緒につけておくのを忘れずに。
自分がいなくなったときに誰も触れないとなると困るのでｗ
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？