ナナメガキ

本

まっすぐ向き合ってナナメに書き捨てる、エンジニアリングマネージャーの思いのたけ。ナナメ読みするくらいがちょうどいい。

運営しているクリエイター: あろえ

マネージャーは”何でも屋”ではないが、なんでもする

エンジニアリングマネージャーになりたての頃、サーバントリーダーシップを履き違えて、はたまた部活動のマネージャーの「タオルやスポドリを選手に配る姿」だけを想像して、メンバーの雑用係を買って出るようなことをしてみたことがあった。マネージャーとしてできることなどあまりないのだから、せめて面倒事を片付ける”何でも屋”くらいの役割はしようと思っていたのだ。しかし、当然ながらマネージャーは何でも屋ではない。マネジメントの目的や責任を果たすために必要なことは何でもするが、”何で

EMとしてどのような実務をしているか - 自己紹介にかえて -

先日初対面のエンジニアと話す機会があった。EMをしていることを伝えると、その詳細に興味をもってくれて色々と質問してくれた(とても嬉しかった)。そういえばマネジメントを始める以前の自分もマネジメント業務の実態についてほとんど知らず雲を掴むような曖昧さを感じてたし、今でも隣の部署のマネージャーがどのような実務をしているか深く知らない。それを踏まえて、先日の会話を書き起こしながら私のマネジメント業務の一部を紹介してみようと思う。プレイングをしないマネージャーは日頃なにをし

あの日の僕らの1on1はなぜ無意味な時間だったのか

かつて僕はマネージャーとする1on1が大嫌いだった。僕にとってそれは役立たなかったし、時間のムダだったし、そもそも上司に自分の内面を知られたくなかった。自分がマネージャーになりチームメンバーと話をしたいと思うようになって散々試行錯誤してきた今、改めて当時のことを考えると、あの時間をなぜあれほど無意味に感じたのか言語化できる。 (当時のマネージャーを責める気はもちろんないですが、何様目線な表現が含まれる可能性があるので苦手な方はご注意ください) 1. 信頼関係がなかったか

人の問題を解決したかった20代、人を肯定したい30代

目先の問題をなにがなんでも解決してやりたい、という気持ちが、ここ数年は明らかに減ってきている。マネジメント業務でぶち当たる問題の中には「時間が解決するもの」「触れることでかえって悪化するもの」「自分が解決しないほうがいいもの」などがあって、そういうものに触れているうちに曖昧さに強くなりネガティブケイパビリティが高まってきたことも要因だと思う。でもそれは多少影響のある要素の1つに過ぎなくて、変化の本当の要因は、人生の主題が変わったことにあるのかもしれない。ふとそんなことを

僕が心理的安全性に代わって引き出したいもの

一時期から心理的安全性というものに懐疑的でいろいろ学んだり実践したりしてきたものの、やっぱりどこか腑に落ちない……。そう思いながら長年過ごしてきたのだけれど、最近は自然と悩まなくなりました。僕にとってチームの心理的安全性とは結果として現れるものであって意図的につくるものではなくなったからです。代わりに僕がマネージャーとしてチームから引き出そうとしているものは自律性です。チームメンバー一人ひとりが、チームとして高い成果を出し続けるために自発的に自身の活動をふりかえりアップ

仕事を "丸投げ" しないように気をつけていること

マネジメント業に就いて間もなくして、チームが自律することにこだわるようになった。マネージャーである自分が業務プロセスのボトルネックになるのは嫌だったし、高いスキルを持つチームメンバーが自律的に活動し続ければ僕には想像もつかない素晴らしい未来に到達するのではと思えたからだ(本気だ)。チームの自律度合いを高めるために僕にできることの1つは仕事を任せることだ。ただし丸投げではない。これらは僕が思う丸投げの例だ。仕事を任せるときにはもういくつかの要素を付け足したい。任され

1on1の第3の難しさ

マネージャーになり1on1を”する側”になってすぐに、第1の壁にぶつかることになる。何を話していいか分からないというやつだ。マネジメント業をデビューした直後はとりあえず1on1をしなきゃと無計画なまま予定だけおさえ会話がうまくできず後悔したり、「最近どう？」から始まり「特に何も」と返されどうにも盛り上がらない事態に危機感を覚えたりした。ここで1on1のやり方が書かれた本を数冊読んで、『相互理解』『傾聴』『承認』『フィードバック』に始まり数々の技やフォーマットを知り、それ

"やらされる目標設定"との付き合い方、そして目標設定の真の意味

やれと言われてやる目標設定にモチベーションとしての価値はないし、個人目標の達成度合いで人事評価をするのはアンチパターンだと思うけれど、それでもやれと言われればサラリーマンの僕は目標を設定するしかないし、マネージャーの僕はチームメンバーが正しく評価されるよう目標設定のサポートをしたい。そんなことを考えながら1ヶ月近く自分と身の回りの人の目標設定に向き合っていたら、ようやく「やらされる目標設定」との付き合い方が少しだけ上手くなった。少しだけ腑に落ちる答えを見つけた。ので書く。

スクラムマスターの壁 - 回復志向からの脱却

スクラムを始めたばかりのチームでのスクラムマスター業は"うまくいかない現状"との戦いだ。それもそのはず。チーム内外問わず関わる人達のスクラムに対する理解度もモチベーションもまちまちだし、スクラムであろうがなかろうが従来のやり方からの変化には戸惑うのが当たり前なのだ。そういった精神状態のチームメンバーやステークホルダーと共に、プロダクト開発を進行しつつ(成果を継続的に出しつつ)、スクラムを確立させていくためのあらゆる支援をするのがスクラムマスターなのだ。うまくいかない状態をど

初めてスクラムマスターをしたときにだけ味わう苦悩

初めてスクラムマスター業をやったとき、何からしていいか本当に分からなかった。あれこれ試して失敗した時期があれば、チームメンバーを失敗で振り回すのが怖くて何も試せない時期もあった。本や有識者の記事を読み漁って、今の状況にちゃんと照らし合わせながら取捨選択して施策を打ったりもした。だけれど手応えがいまひとつで「なんだ机上の空論か」と愚痴ることもあった。例えばチームビルディング的なアクティビティをしてみたり、レトロスペクティブにてもやもやを言語化してみたりすると、その時は盛

「あなたには向いていない」と伝える勇気

チームづくりをする上での僕の主なスタンスは『背中を押す』だ。具体的には、チームメンバーが何か行動を起こしたとき一番最初にフォロワーとなって、その行動が成功するように付き添う……といった具合だ。場合によっては軌道修正したり別の方向性を示したりするときもあるけれど、基本的には肯定して伴走することが多い。僕が『背中押すおじさん』になりきれているのは、つまりそのスタイルでチームがちゃんと前進しているのは、チームメンバーが優秀だからなのは間違いない。伴走で事足りるなんて恵まれている

2022年1月のあたまのなか | オンボーディング | エンジニアの刺激

マネジメントをするようになって、コードのような目に見えやすい成果が減り、あとから振り返ると何もせずにただただ時間だけが過ぎてしまった無能感に駆られることが増えました。だからnoteに考えを纏めるようになったけれど、纏まらない考えはいつの間にか雲散霧消してしまいがち。かと言って日記をつけるほどマメでも真面目でもないので、せめて月1回くらいは頭の中の棚卸しをしてみようと思います。エアー壁打ちのようなものです。過不足ないオンボーディングとは何か去年僕たちのチームはオンボーデ

失敗のコスパ、挑戦の計画性

喜ばしいことに、僕たちのチームでは、新しいことに挑戦しその経験を振り返って学びを得ることを、息を吸って吐くように実践している(やや盛った)。「試しに〇〇してみていいですか？」「△△をやってみたので、興味ある人フィードバックくれませんか？」といった具合に、気軽に試してみる習慣と、それにフィードバックし合う習慣があるおかげだと思う。＊＊＊それはそうとして、挑戦には失敗がつきものだ。失敗と言うと大げさだけれど、100点満点の結果にならないことはよくある。それが学びの余

100点を目指すより、所与の条件を変えることを目指したい

僕は決められた条件・環境下で最大限の結果を目指すことが比較的得意だ。というのは嘘で、真実は、「何が条件で何が自分の手の及ぶ範囲か」を無意識のうちに判断して手の及ぶ部分だけを最大化しようとする思考の癖がある。＊＊＊例えばマネジメント業務で言えば、今ここに集まったチームメンバーで、今使えるリソースを使って、どれだけいいプロダクト開発ができるかを考えようとする。「もっと時間があれば、もっと人がいれば」とは、思い返すとあまり考えたことがない。それよりもここに集まったチ