意義が感じられない業務があるとしたら、それは構造的に捉えられていないだけかもしれない

目標設定とか評価とか、いわゆるピープルマネジメント的な仕事が苦手だ。

評価の時期になるたびに「給料もらうために必要だから仕方なく」とか「これをやったからって良いものが作れるんかいな」という天邪鬼な気持ちが心をよぎっていた。

最近は自分でチームを立ち上げてプレイングマネージャー的なロールをやっているが、「メンバーの目標設定やってくださいね」と言われて「まぁ苦手だけどやるかぁ……」と後ろ向きだった。

今日VPoEの藤倉さんと1on1をする機会があり、上記の考えを共有して相談してみた。その結果少し頭がマルくなった感触があったので言語化してみたいと思う。

大きなシステムを作るとき、目標とするアーキテクチャを描いて、それに向けて現在のシステムを近づけていくというアプローチを取る。

組織をエンジニアリングする場合も同様で、少し未来にあるべき組織のアーキテクチャ（どのようなスキルを持った人が何人ずつ必要なのか、各チームはどのようなインターフェースでコミュニケーションすべきなのか）を決めて、そこに到達するための具体的な道筋を考える必要がある。

いままで僕が単発の業務として感じていた目標設定や評価は組織アーキテクチャを変えていくための実装手段だったわけだ。

単発の業務として捉えていると、どうしてもそこにかかるコスト（時間もそうだし、心理的なコストも）が気になってしまうが、業務全体を構造的に捉えることができれば、表面上面倒に見える業務も意義を理解しやすいかもしれないと感じた。

---

もうひとつ重要なポイントは、目標設定や評価の意義を構造的に説明してくれたマネージャーもいたはずなのだ……

いままでのマネージャーに心のなかで謝りつつも、ものごとを構造化して捉える素地が自分の中に出来てきたことを実感して少し嬉しくなったGWの中日だった。