マガジンのカバー画像

ナナメガキ

23
まっすぐ向き合って、ナナメに書き捨てる。
運営しているクリエイター

記事一覧

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

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

スキ
4

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

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

スキ
2

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

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

スキ
5

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

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

スキ
7

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

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

スキ
8

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

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

スキ
1

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

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

スキ
2

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

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

スキ
1

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

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

スキ
3

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

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

スキ
6

僕たちにとって"KPT"は武器か、それとも呪いか

かつての僕はふりかえりといえばKPTのことだと思っていたけれど、もちろんそんなことはない。KPTは手段の一つに過ぎない。ではいったいどんな効果を持つ手段なのだろうか。 「KPTは頼れる手段だが濫用は危険」これが僕の最近の考えだ。 差分認知といって、人は多くのことができていても僅かなできていないことに目を向けてしまう性質があるそうだ。それ故Problemを起点としたKPTでは意見を集めやすくふりかえりの効果を実感しやすいが、反面、ふりかえる切り口を狭めてしまうリスクがある。

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

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

スキ
3

失敗から学ぶために本当に必要な"失敗"とは何なのか

失敗から学ぶ、つまり「経験をもとに得た知識や教訓を自身に定着させる」ためには、失敗を経験することが必要だし、それをふりかえることが必要だろう。 ふりかえりの具体的な方法論については本で学んだり実践したりして知見を溜めてきたけれど、どんな経験をふりかえれば良いのかについては考えたことがまだなかった。なので今日ここでチャレンジしてみる。 ちなみにふりかえりの方法論はこの本にびっしりと載っている。チームのふりかえりをレベルアップさせるにはもってこいの一冊だと思う。 * * *

スキ
3

テクニックではなく気持ちのあり方から考える「傾聴」と「承認」

マネジメントに関する情報を集めていると「傾聴」や「承認」といった言葉がよく出てくる。それらのテクニックを駆使することでチームメンバーとの関係性を深められると聞き、僕も実践を試みたことがある。 結局奢りのようなぎこちなさを感じてしまって、ほどなくして実践をやめた。 当時はテクニックとしてしか認識できていなかったそれらだが、しかし今の自分をふりかえってみると人間関係を築くときの根底には似たものがあると感じる。 というのも理屈は簡単で、傾聴や承認は敬意の体現手段のひとつなのだか

スキ
5