タイトルはチキったので予防線を張っている。
前記事の続き。
続きを読む
マネージャー視点で見た自己評価と目標設定
マネージャーになるとメンバーの評価という業務がつきまとう。
マネージャーになって3回目までの評価とフィードバックを終えて、よい自己評価と目標設定というものを完全に理解したので残しておく。
ただしあくまで評価という業務を行う上でよいと思ったことであり、評価制度をハックしたりこうすれば成長できるというものではないです。
続きを読む
来た球をすぐ打たない
外から指摘されたことをすぐにやってはいけない。
「外」はいろいろあるけど例えば会社内の他部署他チームだったり実際にサービスを使ってくれているユーザーだったりがある。
なぜすぐやってはいけないのか。
まず大前提として普段の仕事ではある程度の期間単位で何をやるかを計画しているはず。外からの指摘とはいわば「差し込み」であり予定外の仕事である。
本来の計画を遅らせてでもやる価値があるのかをちゃんと計画する必要がある。もちろん計画した結果、本来の計画を変えてでもやるべきとなったならやるべき。
ただ来たからといって脳死でそれに対応するということで本来のゴールから遠ざかっていないかは意識する必要がある。
すぐ対応できそうだなと思って軽い気持ちで手を付けたら実は影響範囲がひろかったとか思ったよりやることがたくさんあったとかいう経験はないだろうか？
ではなぜすぐやってしまうのか。
そもそも普段の仕事はある程度はちゃんと時間を使って計画している（はず）なのになんで外からの指摘はそれをすっ飛ばしていいと思ってしまうのだろうか？
個人的には来た球をすぐ打ち返すのはやってる感が出るからだと思っている。
もっというとタスクをやって実際にユーザーに与えた価値よりも、来た球をすぐ打ち返したという行動の方が社内の周りの人間に対してわかりやすくよく見えるから、だと思っている。
この感覚は勘違いしやすいので粘り強く指摘し続けることが必要なのだと思う。
あとはやはり外からのフィードバックは刺激的に映る。
わざわざ指摘してくれたんだからやらなきゃと思ってしまいがち。
その指摘はどういう意図をもって寄せられたのか？をちゃんと知る必要がある。
特に直さなくても困らないけどせっかくだから言っておくかぐらいの軽い雑談レベルで言っただけかもしれないし、指摘されたとおりにやることが絶対に正しいかどうかはわからない。
また、やった方がいいかどうかというだけで判断してはいけない。
大抵の場合、やった方がいいかでいうとやった方がいいという判断になってしまう。
だが当たり前だけどリソースは有限なので、コストと得られるメリットまで含めて考えると必ずしも今やる必要はないかもしれない。
ユーザーにプラスになるからだけで考えると上記のやってる感につながってしまう。
ちなみにここまで書いてなかったけど、これが障害だったら話は別。
手を止めてすぐに対応する必要がある。
不具合はちょっと難しい。
個人的にはエッジゲースだったり、ユーザーが代替手段で回避できるなら一旦置いてもいいかなと思うけど、こういう判断は個人ごとに揺れやすいので基準を決めておくのがよいと思う。
リリース日に間に合わせるということについて考えていた
最近リリース日というものについてずっと考えてしまっているので文章に書いて頭の中から放出する。
まず自分の考えとしてはリリース日は必達しなくてもいい・変更してもいい派（法令対応だったり相手の都合がある場合は必ずしもそうではない）
これはリリース日というものはリリースに必要なタスクの計画からなる結果だからというのが理由。
タスクが一通り出揃って見積もられてチームが1日にこなせる量がわかっていればそれで計算するだけ。まずこれがわかってないと間に合わないかどうかもわからない。
だからやることが増えたり減ったりする、あるいは差し込みなどでチームが1日にこなせる量が減れば完了日は変化する。
基本的にはやることを増やさないのと、こなせる量を増やすことが「間に合わせる」につながると思う。
やることは増やそうと思えば無限に増やせてしまう。やらないことを決めるというのが大事。
こなせる量を増やす方法は自分たちが成長してやれることや量を増やすのとリリースのために不要な差し込みなどをやらないというのがある。
成長に関しては例えば毎週読書会をするだとかいろいろある。
差し込みに関してはリリース日の事情を説明してお断りするとかリリースよりあとに回してもらえるよう根回しするとかがある。
この手の話をするとMTGを削って作業時間に充てるという話に必ずなるけど、削るMTGを慎重に選んだほうがいい。
特に成長に関わる営みを削ると木こりのジレンマでもっと長期に効いてくる。
本当に最後の追い込みで削るくらいならいいが、1回スキップされると再開されずそのままズルズルとたち消えになるのはよくあること。
勉強会系は自分たちの都合だけで決められるから気軽に消されやすいというもある。
これは偏見だけど、そんな微々たる作業時間を確保するために勉強会を削らなきゃいけないようではそもそもやり方云々以前に仕事が下手くそなのだからちゃんと時間使って勉強したほうが短期でも効果があると思う。
そもそもなぜ間に合わせないといけないのか。
リリース日を変えてもいいというと「どれだけ遅らせてもいいのか」とか言われることがあるけどそういうわけではないし、早く出せるならそれにこしたことはない。
上述の通りリリース日は結果なのだからそれを構成するものの意思決定で決まる。
そこで何を守るか次第。
それは自分たちの評価（期限を守るということが重要）だったら品質捨てたりデスマしてでも間に合わせる選択をするだろうし、ユーザーに届ける価値や品質だったらそのために遅らせる判断もあり得る。
個人的にはゴミをリリースするくらいなら期限を守る以前にリリースしないほうがマシだと思っている。（だからゴミかもしれないとわかったなら立ち止まったり捨てたりすることが必要だがそれは別の話）
仕事の仕方に興味を持とう
普段仕事をするとき自分の仕事の仕方を改善はみんな当たり前にやっていると思う。
一方で自分を含めたチームや組織レベルでの業務の改善や設計まで考えようとする人は意外と少ないのだなぁと最近思う。
業務の設計などと言っても大層なことではなくちょっとした仕事の仕方を決めるだけでもいい。
例えば意思決定の伝達が口頭で行われて言った言わないの話になるなら決めたことを残しておく何かを用意するというのでもいいし、Web会議なら録音や録画をするという手もある。
録音録画では長過ぎて見られないなら要約した議事録を残してもいいしそれでも読まれないなら内容を全員に伝えるミーティングを設定するなど、これだけでもいろいろやり方を決められることがあるのがわかる。
そしてこのやり方は日々自分たちで自由に変えられるはず。
慣れてきたらミーティングはしなくてもよくなるかもしれないし、音声をAI要約させたらいい感じになるかもしれない（しらんけど）
これは持論だけど、製品を作って売る場合、お客さんの業務や行動を分析して売れそうな機能や製品を作っているはず。
ならば自分たちの業務の場合、自分たちが一番よく知っているはずなのだからそれに一番効果がある（ありそう）なことを見つけられなければいけないと思う。
なので仕事の改善は自分のことだけじゃなくて自分たちチームや組織の行動をどう変えるかを考えなければならない。
そしてそのためには自分たちの業務、チームや組織の人が何をやっているのかを知る必要がある。チームの仕事に興味を持とう。
チームで一人だけ別拠点で働いていて起こったこと
2022年12月に転職してから丸2年間所属していたチームから異動することになった。
2年の間に少しずつ人が入れ替わっていってとうとう自分の番という感じではあるけど、今回の異動に至るまでにチームと自分の状態についていろいろ相談していたことを受けての異動なので顛末とかを記録に残しておこうと思う。
続きを読む
