なぜ、エンジニアの"フロー状態"は見落とされるのか？ 継続的なフロー状態が開発生産性を高める

前回は「開発生産性」という言葉の広さから、きちんと組織のレイヤーを構造化しながら用語を分けてオーバーラップする部分を繋げていきましょうという話を紹介しました。第2回となる今回は、開発チームに焦点を当てていきます。ソフトウェア開発の現場では、Four Keysを中心とした「開発生産性のメトリクスはどうあるべきか」 や「認知負荷を下げるエコシステムはどう設計するべきか」といった議論が頻繁に行われています。こうしたソフトウェアアーキテクチャから生まれる開発生産性に関する議論はとても重要であり効果が高いものです。本記事ではそうした議論とは少し離れ、「エンジニアの継続的なフロー状態が生む開発生産性への重要度と、組織が開発チームに対する不安の定量化によるフロー状態の軽視がなぜ起こるのか」という観点で解説します。 以前の記事 【第1回】「開発生産性」はエンジニア"だけ"のモノではなくなった？──開発組織

[syu-m-5151]

プログラマー脳にもフロー状態についての言及が欲しかったと思っていた。

[dorapon2000]

“SPACEと本記事の関連性を見ても 「Efficiency and Flow」 にある通り、生産性＝作業の中断や遮断をどれだけ最低限を抑え、「フロー状態」に入れるかを定義しています。”

[softstone]

フローに入ってゆっくり１００まで数えよう（短い）

[mohri]

開発者体験はついに「DX」と略すのをあきらめて「DevEx」って表記されるようになったのかー

[gogatsu26]

浮浪状態