月末なので忙しいです。
それでもなんとか定時に上がれるように、ぼくのかんがえた最強のタイムマネジメントを紹介します
仕事の仕方は人それぞれあると思うので、こういう考えの人もいるのかー、程度に思っていただけたら嬉しいです。

メリット

実践編

##「定時で帰る」意識をもつ

「定時に帰る」ということは、少なからずプレッシャーあります
帰った後にバグがみつかる可能性がありますし、適当なコードを書いたら、翌日から周囲から蜂の巣にされるでしょう。

そのため、以下のことを心がけるようになるはずです。

定時上がりの罪悪感を利用します
プレッシャーがあると副作用として焦りが生まれますが、焦らず急げと心に念じておきます

どんなに忙しくても、「定時後すぐの電車にのらないと間に合わない勉強会がある」などの理由があれば、なんとか定時までに全てを終わらせられるように集中していられます。

ポイントは、２つあります。

高速化と「はまる時間」は反比例します
- 標準APIは使いこなせるように訓練しておきましょう。
- gemのドキュメントやPJTのソースコードは空き時間を使って読んでます。
- 読むことに生産性はありまん。しかしレバレッジが効かせられます。
- コードの速読ができれば強いです。ぼくはできないので練習してます
並列処理
rspecやrubocopの実行。ブラウザリロードは自動化
Webサービスはルーチンで型が決まっていて、無意識でも可能です
無意識でいいなら、意識的に別の機能の設計を考えながらでOKです

ぼくの経験では、私自身が楽観的見積もった工数で、その通りにリリースできることはほとんどありませんでした。

たとえば、「この機能はいつまでに実装完了するか？」と質問された場合です。

楽観的に自分のスキルなら３日でできると思って、そのまま**「３日あればできます」**といってしまったなら、
なんとか３日で実装しなければという気持ちになります。

なぜなら、３日以内にできなければ無能だと思われるからです。
エンジニアとして、「無能」と思われるというのは、非常に居心地が悪く、避けたいものです。

しかし、上で述べたように楽観的に見積もった工数どおりにリリースできることは、ほとんどありません。ぼくの経験則的にもそうですし、人月の神話
もそう言ってます。

工数(リリース)間に合わないと感じたときから、プロジェクトの崩壊が始まります
(テストとリファクタの手抜き)

工数の何倍がちょうどいいかは個人差あるとおもいます。
楽観的見積もりは、着手からレビュー対応完了まで悩まず進んだ場合の作業時間です。

スキル不足かオーバータスク、または適材適所に問題があるので、その場はできる人にデリゲートor撤退or残業になります。

次は時間を守れるようにスキルアップに取り組みます
自己啓発本や技術書をよんだり、できる人のやり方を真似（エンジニアならgitのコード）して勉強することになります