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

開発生産性の多角的視点 〜開発チームから事業経営に開発生産性を波及させるには？〜 第2回　

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

以前の記事

• 【第1回】「開発生産性」はエンジニア"だけ"のモノではなくなった？──開発組織から経営層までが開発生産性を考える時代へ

2-1 "継続的なフロー状態"が、開発生産性を向上させる

　エンジニアリングの世界において、開発者が数時間にわたって集中し続けることができる「継続的なフロー状態」の創出は、ソフトウェアを作り上げるという作業の中で最も重要な部類に入ります。

　思考の流れが途切れず、問題解決やコードの実装がスムーズに進行する状態をフロー状態と言いますが、組織やチームで動いているエンジニアであれば、そのフロー状態（ゾーン）に入っている状態にもかかわらず、ミーティングの時間が来てしまい集中力が途切れてしまうといった経験をしたことがあるはずです。そのときの喪失感は大きく、ミーティングが終わって作業を再開してもうまく捗らないことがあります。

2.1.1 エンジニアは1時間に13回タスクを切り替えている

　あるデータを見ると、エンジニアは約6分間集中して、1時間に13回タスクを切り替えていることが分かります。ソフトウェア開発の多くはチームで作業をしているため、コードを書く以外にもSlackに返信したり、ミーティングをしたり、プルリクレビューをしたりします。

　"Developers reported that they usually feel most productive when they make progress on tasks and when they have only a few context switches and interruptions. However, observing developers’ workdays revealed that they constantly switch contexts, often multiple times an hour. For example, developers switched tasks on average 13 times an hour and spent just about 6 minutes on a task before switching to another one. "

　「開発者たちは、タスクの進捗を感じる時や、コンテキストの切り替えや中断が少ない時に最も生産的だと感じることが多いと報告しています。しかし、開発者の労働日を観察すると彼らは絶えずコンテキストを切り替えており、しばしば1時間に何度もこれを行っています。例えば、開発者は平均して1時間に13回タスクを切り替え、約6分間タスクに集中して別のタスクに移っています」

　引用 : Rethinking Productivity in Software Engineering Chapter Developers’ Diverging Perceptions of Productivity

　なぜ、こうしたフロー状態が継続的に生まれにくいのかについて、書籍『ハッカーと画家』で有名なポール・グレアム氏の記事「MAKER'S SCHEDULE, MANAGER'S SCHEDULE」の中で以下のように記されています。

　"There are two types of schedule, which I'll call the manager's schedule and the maker's schedule. The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you're doing every hour.

　~

　there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started."

　「スケジュールには 2 種類あり、マネージャーのスケジュールとメーカーのスケジュールと呼びます。マネージャーのスケジュールは上司向けです。これは、毎日が 1 時間間隔で区切られた従来の予定表に具体化されています。必要に応じて、1 つのタスクを数時間ブロックすることもできますが、デフォルトでは、1 時間ごとに実行する内容が変更されます。

　（中略）

　しかし、プログラマーやライターなど、ものを作る人たちによく見られる別の時間の使い方があります。少なくとも半日単位で時間を使うことを好むのが一般的です。1時間単位でうまく書いたりプログラムしたりすることはできません。それは始めるのにかろうじて十分な時間です」

　この記事で書かれている「メーカー」とはエンジニアといったモノを作る作業を行う人たちを指し、「マネージャー」はメーカーに指示を出して管理する人たちを指しています。つまり、エンジニアやデザイナーとマネージャー（開発マネージャーやPM、PdM含む）の関係性です。

　ポール氏によると、マネージャーの作業のスケジュールが1時間単位であることが多いのに対して、メーカー（エンジニア）は少なくとも半日単位で作業をすることが好ましいです。1時間では、大きな問題を解決する準備ができる程度です。

図1：タイムボックスの違い

　こうしたタイムボックスの違いによって、集中している時間や細切れに複数のミーティングが入っていたり、そもそも開発以外の時間が多いとフロー状態ができず、比較的静かな定時後に作業を行うことになります。すると残業が多くなり、メンタル的にも疲弊していきます。

　つまり、ミーティングとミーティングの間に1時間が2つある状態の開発生産性と、2時間まとまった空きがある状態での開発生産性は等価ではありません。その時間の連続性が非常に重要です。

図2：連続性がフロー状態を作る

2.1.2 「SPACE」でのフロー状態

　また、近年、有名になっている開発生産性のフレームワークでも「フロー状態」の重要性が述べられています。

　「SPACE」は、LeanとDevOpsの科学の著者の一人であるニコール・フォースグレン氏も著者に入っているフレームワークで、開発生産性を1つの次元（a single dimension）、または指標で表すことは難しいという部分を背景に、以下5つの指標を提示しています。最低でも3つはバランスを見て取り入れ、少なくとも1つはアンケートデータなどの定性的な指標を含めることも推奨しています。

※引用：Introducing Developer Velocity Lab to improve developers’ work and well-being

　また、個人のパフォーマンスではなく、3つの適用するレベル（個人、グループ、システム） で計測することを推奨しています。例えば、プルリクエストの数やマージまでの時間を計測する際、特定の誰かのパフォーマンスが高くてもチーム全体を見たときに低ければ意味がありません。

　コードレビューを疎かにして個人のタスクを高速に進めていれば個人の計測数値は上がりますが、その分コードレビューをしていないので他のメンバーの開発生産性、ひいてはシステムの改善が進んでいないことは往々にしてあります。

　この場合、バックログにWIPをかけて進行中タスク数に制限をかけるほか、トランクベース開発を導入して同期的なコードレビューを実現し、レビューワーはレビュー依頼がきたら今の作業を一時的に止めてコードレビューを行うといったルールを定着させるなどの改善策をとります。

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

　"Some research associates productivity with the ability to get complex tasks done with minimal distractions or interruptions. This conceptualization of productivity is echoed by many developers when they talk about "getting into the flow" when doing their work—or the difficulty in finding and optimizing for it."

　「ある研究では、生産性を『複雑なタスクを遮断や中断を最小限に押さえて完了させる能力』と関連付けています。この生産性の概念は、多くの開発者が自分の仕事をしている際に『フロー状態』に入り、またはそれを見つけて最適化することの難しさを反映させています」

2.1.3 「DevEx」でのフロー状態

　去年、「DevEx: What Actually Drives Productivity」という研究論文が発表され話題になりました（※DevEx＝Developers Experience : 開発者体験）。

　SPACE同様、測定範囲として「個人、チーム、組織レベル」といった幅広いレイヤーに対して焦点を当て、開発生産性を考えるべきだと提案しています。どういった観点で計測するべきかについて以下3つが提案されています。

#	指標	指標の概要	使用例
1	Feedback loops	フィードバックループは、行動に対する反応の速度と品質を指します。迅速なフィードバックは、開発者が作業を迅速かつスムーズに完了することを可能にします。	コードの再コンパイルやテスト実行の待ち時間の短縮 コードレビューの承認待ち時間の削減
2	Cognitive load	認知負荷は、開発者がタスクを遂行するために必要な精神的処理量を指します。不必要な障害を排除し、コードやドキュメントの整理によって認知負荷を減らすことが重要です。	よく整理されたコードとドキュメントの作成 開発者が利用する自己完結型のツールの提供
3	Flow state	フロー状態は、活動に没頭しているときの集中状態を指します。この状態は、生産性、革新性、従業員のスキルアップに繋がります。	会議の集中スケジューリングや計画外の作業の最小化開発者に自律性を与え、挑戦的なタスクへの取り組みを奨励

　ここでも「Flow state」という形でフロー状態が開発生産性に寄与する旨が提案されています。簡単ですが、2つの開発生産性に関するフレームワークを見ても、開発者のフロー状態を軽視もしくは改善の見落としたときに生産性に及ぼす影響はありそうです。