ナナメガキ

本

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

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

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

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

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

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

1on1の第3の難しさ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

嬉しかったことを、ちゃんと嬉しかったと伝えたい

先日、我が家の定期点検がありまして。担当の方には懇切丁寧に隅々まで見てもらって、ちょっとした汚れは掃除までしてもらって、すごく助かりました。都度感謝は伝えられたのですが、具体的に僕がどれほど助かったかは伝えられていません。似たような例をもう一つ。インフルエンザワクチンを打ちに近所の医院に行ったとき、混んでいて忙しない雰囲気だったにも関わらず、終始笑顔で丁寧な対応をしてくれた受付の方。この方にも、僕がどれだけ居心地良く過ごせて満足しているかを伝えられていません。会計時に「

マネジメントの言語化にこだわる理由

僕はいったい何の仕事をしているのかそう思うことがしばしばある。特に採用活動に関わる度に。もし自分が採用される側だとしたら、何をしてきたと言えるのか。何を成し遂げた人だと認識されるのか。僕のことを知らない人に、僕のスキルや考え方や業務プロセスを知ってもらいたい場面はきっとこの先の人生で何度か訪れる。やがて来たるその日のために、僕は自分のマネジメント業務に纏わるあれこれを言語化したい。ここ最近のモチベーションの根底はほぼ言語化欲といっても過言ではなくて、本を読むのも

受け入れやすい変化とそうでないもの

最近の悩みの一つは、「変化の許容量が違うチームメンバー同士で、どうやってチームを改善し続けるか」だ。悩みの内訳については先日書いた。この件について、頼れる同僚がディスカッションに付き合ってくれたので、そこで出たアイデアをまとめておく。＊＊＊変化に耐え得る総量があるのではないか変化を受け入れられる総量が各々にあって、そのリソースを他の部分に割いているときはチームの改善をしにくいと感じる可能性があるかもしれない。例えば「新しい技術の導入にチャレンジしている途中だか

"変化に対するキャパシティ"のズレと改善活動の難しさ

スクラムチームにせよ、エンジニアチームにせよ、僕が属するチームには自分たちの開発プロセスを自分たちで改善する裁量がある。ありがたい話だ。ただ、誰もが僕みたいに反省や改善が大好きなわけではないし、僕より遥かにハイペースで改善し続けようとする人だっている。期待する改善のペースは人それぞれで、だからチームで取り組む改善活動は難しい。＊＊＊ところで、改善とは変化の連続の上に成り立つものだ。何かしらを改善しようと思ったら、新しい方法を試行して、データを集めて、検証して…