はじめに
実はワークルールというものを大切にしています。 大切にしているという割に久々に整備しようと思って改めて整備してみました。
そもそもワークルールって？
以前いた会社で、「ワークルール」というものがありました。働く上で生産性を上げるためのルールみたいなものです。 設計は単純ですが、すごく効きます。シンプルに週次で「達成できたかできなかったか」を振り返るだけです。
これの秀逸さは抽象に落とし込んで具体に転用するという設計が自然にできて、振り返りによって習慣化できることです。
失敗する→失敗した原因の本質をさぐる（抽象）→具体のエピソードで振り返る（転用）
という感じですね。
以前いた会社では、特に大事だなと思ったことを会社ブログの記事として書いていました。
エンジニアが身につけておきたいMyワークルール3選 | 株式会社divx（ディブエックス）
最新Myワークルール
最新はこんな感じです。
- [ ] 事実に基づき判断する（推測よりもログ、datadog、Sentry）
- [ ] 横着しない
- [ ] 認知負荷を下げる
- [ ] 意図を持つ
- [ ] アウトプットの最適化（FIgma, システムガイド, シーケンス図, スプレッドシート）
- [ ] 推測を減らす
- [ ] 解決すべき課題の照準を絞る（無駄な確認作業、リターンの少ないチューニング）
- [ ] 抽象的な仕事は解釈の余地のないゴールを設定する
- [ ] 結論や前提を疑う
- [ ] MTGは「全員が納得している」状態
- [ ] 本を読んだらアクションプランを決める
- [ ] 話題は細分化する
- [ ] N + 1
解説
自明なものは除いて、いくつかピックアップしてみます。
認知負荷を下げる
たとえばソースコードだけがあるプルリクエストよりも、Issueの背景や設計の方針などがほどよくまとまった資料があるとわかりやすいですし、定例MTGなども共通の注目物などを用意しておくだけで認知負荷が下がるなということを常に意識しておきたいものです
意図を持つ
コード書いた理由、質問をSlackで送る際の背景などが、すべて自分の中で意図として言語化された状態で存在することが大事だなと思っています。 壁打ちなどは別ですが
結論や前提を疑う・話題は細分化する
先述した記事に書いています
