memorandums

日々の生活で問題解決したこと、知ってよかったことなどを自分が思い出すために記録しています。

ACM Tech Talk

以下を視聴した。

The Death of Work: Leading Effective Engineering Teams

エンジニアリングチームのリーダーの心得的な話だったと思う。スライドが絵のみだったのでなかなか理解が追いつかなかったが。。。以下の著書の紹介があった。より理解したいならこれを見る必要があるかと。Kindleで2000円。まだ読んでない。エンジニアを管理する立場でもないのでなかなか動機を感じにくいのが問題。。。

冗長だけどレビュー動画を見るという手はあるかも。

www.youtube.com

この著者がエンジニアが活躍するにはフロー状態が大事でリーダーはその環境作りが大事だと主張しているようだった。たぶん、そうだと思う。いかに気持ちよく集中してもらうか、これは大事だと思う。

コツは以下の7つ挙げられていた。

1 Flow state can exist when there is clarity of purpose
2 Flow state can happen when the work is challenging, but not impossible.
3 Flow State is associated with trust
4 A person in flow state should get immediate feedback on their process
5 A person will struggle to reach flow state if they are not compensated fairly
6 A manager has to believe in their staff
7 Reduced context shifting and interruptions

DeepLで訳したのが以下。

1 フロー状態は、目的が明確なときに起こりうる。
2 フロー状態は、仕事がやりがいのあるものであっても、不可能ではない場合に起こりうる。
3 フロー状態は信頼と関連している
4 フロー状態にある人は、自分のプロセスについて即座にフィードバックを得るべきである
5 公正な報酬が得られないと、人はフロー状態に到達するのに苦労する
6 マネージャーは部下を信じなければならない
7 コンテキストシフトと中断を減らす

チームとしての目標を明確にし、皆でその目標に到達することの意義を共有し、お互いがお互いを信頼する。大事ですね。。。チームっていう感じがします。

できるだけ迅速なフィードバックも重要ですね。なかなか返事というか応答くれない人いるからなぁ。。。

面白いと思うのは「公正な報酬」。同じ仕事やってもあいつの方がたくさんもらえるんだぜ。。。となるとやる気なくしますわね。。。コンテキストシフトか。。。無駄な打ち合わせとか最小化したいですわね。。。部下を信じる。できそうでできませんね。。。だってリーダーは最悪を想定してプランするものだと思いますし。。。それと信頼しないことは別かもですが。。。どうでしょう。

エンジニアリングチームに限らず、組織で心地よく働くために目標とされる規律のような気がします。なかなか実現できている組織はなさそうですが。。。