2015年に実感したことつらつらと
全部バラバラなことだけど、自分の中で腑に落ちたこと。
分析するべき数値の定め方
よく「見るべき数値を定める」とか、「数値を目標に」などよく言われていると思うけど、漠然と何の数字を見ればいいかとかを考えるより、課題の洗い出しのMTGなどをしながら、そういえばここの数値ってどうなってるんだっけ?って時にSQL叩いたりGA見たりして見るべき数値を出していったほうが結果的に、その後にも役に立つ指標を作ることができたりする。
論理派と感覚派の違い
これは以前下記に書いた記事の通り。
musclehustle.hatenablog.com
管理するんじゃなくて信頼する
よくマネジメントの話では出てくるような気がするけど、自分のチームメンバーがミスをするとかサボっているんじゃないかというのが気になって、それを防ぐために管理することがある。でも、自分の考えを伝え、目指すべき頂上を共有しながら同じ方向を向いて、それぞれ自分で考えながら、やるべきことを見つけるのが本質的。理想論のように聞こえるけど、去年のチームは徐々にそういう状態に向かっていた気がするし、リーダーになる人はとにかく根気強くチームに伝えられる人じゃなきゃ務まらないということもわかった。
イライラを抑えるためには客観視
下に貼った本に書いてあったことを元に自分なりに意識したこと。どれも数ヶ月続けてようやく効果が出てきた。
イライラしたら一旦、外から自分の状態を見てみる。
「ああ、今自分◯◯にイラついたな」みたいな言葉で自分を表してみる。これを続けていると、すぐにイライラが収まるようになってきた。
仮想敵を作らない
もしあの人がこういう発言したら、行動したら、というのを想像してイライラすることがあったので。これも上のように自分を客観視することで徐々に抑えられるようになる。
反応しない練習 あらゆる悩みが消えていくブッダの超・合理的な「考え方」 (中経出版)
- 作者: 草薙龍瞬
- 出版社/メーカー: KADOKAWA / 中経出版
- 発売日: 2015/07/29
- メディア: Kindle版
- この商品を含むブログを見る
作業の時間を増やすことが効率化ではない
エンジニアであれば、コードを書く時間を増やすというのがこれに当たるが、それが必ずしもパフォーマンスを最大限に発揮するための最適な方法ではないということ。人それぞれだと思うけど、自分は自身の目で見て耳で聞いてやってみないと納得できなかったりするので、作業の時間を減らしてでも自分の足で見たり聞くことで、エンジニアとして設計するときやコードを書くときのパフォーマンスも上がることを実感した。