ナナメガキ

本

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

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

#マネジメント

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

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

1on1の第3の難しさ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スクラムに感じた歪さとスプリントの再考

今までいくつかのスクラムチームに携わってきた。開発者として、スクラムマスターとして、はたまたスクラムチームメンバーのエンジニアリングマネージャーとして。何度実践しても腑に落ち切らなかったことが1つある。スプリントの長さだ。どのチームでも、どのプロダクトでも、自分たちにとって(比較的)適したスプリントの長さはこれだと言い切れたことが一度もなかった。プロダクトバックログの分割しやすい粒度と、計画しやすい期間と、割り込みをロックしスプリントゴールへ邁進したい期間と、レトロス

目の前の人を好きになれ、マネジメントの話はそれからだ

エンジニアリングマネジメント経験も3年目に突入して、自分なりの手札が少しずつ増えてきた。そして最近は、そのひとつずつを言語化していくことが楽しい。その過程で、かつての自分は決してしなかったがいつの間にかするようになっていたあることに気づいた。それは「目の前の人を好きになる」ということだ(念の為補足しておくと恋愛的な『好き』ではない)。他人が苦手で斜に構えがちだった自分が、新たに接点ができたメンバーに対して積極的に好意や敬意を持ち、その気持ちを正直に伝えたいと考えるよう

貢献感と成長感から考えるチームのあり方

自分の人生が充実していて幸福だと感じるために必要な気持ちは、貢献感と成長感なのではないだろうか。最近そう考えるようになった。貢献感とは、「人に貢献できている実感」だ。実際に貢献しているかや、周囲の人からどう評価されているかは関係ない。自分自身が「貢献できている」と実感できるかどうかが重要だ。貢献感という言葉は『幸せになる勇気』にも度々出てきた。おそらく貢献感と幸福度の関係は多くの人に適用されるものだろう。加えて、僕には成長感も必要だ。これは「自分が成長できている

僕は放任主義的マネジメントをしているのか

私のチームは放任主義的なんですけど、あろえさんはいろいろやっていますよね。と、ちょっと前にマネージャー同士で1on1をしたときに言われたのだが、僕も自分自身を放任主義的だと自覚していたので驚いた。だからといってネガティブな感情はないし、放任の善し悪しは人それぞれで意見があっていいと思うので今回は触れない。ここで言いたいことは、自己認識と評価が大きく食い違っていた背景が気になるってことだ。僕は自分のどういうところを放任主義的だと捉えていたのか考えてみる。＊＊