働き過ぎが生産性に与える影響
Ron Jeffries氏によるImpact of Overtime on Productivityという記事を例によって無断かついい加減に邦訳してみた。
働き過ぎが生産性に与える影響
Ron Jeffries04/14/2006より多くの機能を実装することで、収益や顧客満足度を向上させるなどの効果が得られる。そのために、より一所懸命に長時間働くというプレッシャーが現場にかかってくるわけだ。これは明らかに「馬鹿げた考え」なんだけど、ここではその証拠と、プレッシャーが強すぎるかどうかを知るための方法を提案してみよう。産業災害と職業プログラマ
XPプラクティスの一つ「持続可能な開発速度」では、開発チームは着実かつ継続的な速度で成果を出し続けることを求めているよね。開発チームは必要と判断すれば残業もするけど、毎週毎週生産性を最大にすることが求められるわけだ。より多くの成果を出すという要求はビジネスの世界においては常識とも言える。これは至極当然な考え方だ。結果として、プログラマ達は「より多くの成果を出すために」長時間労働することが期待される。もちろん、どこかに労働時間の上限はあるだろう。でも、その上限をどうやって決めれば良いのだろうね？
テレビで産業災害に関する番組が放映されていた。その番組を観ているうちに、産業災害のデータからなんらかの結果が得られるんじゃないかとひらめいたんだ。そして産業災害についていろいろ調べていたら、とても明快な証拠が得られた:
産業災害は週40時間労働（一日8時間労働）を越えたあたりから一気に発生頻度が増えるんだ。そして、産業災害の半分以上は残業時間中に発生している。その理由の仮説として一般的に言われているのは、疲労による事故なんだ。
医療実習生の長時間労働による影響、という新しいデータがある。長時間勤務したあとの医療実習生が交通事故を起こす確率は二倍、事故を起こしそうになった確率は５倍ということなんだ。一ヶ月に渡る長時間勤務は、３〜４杯飲んで運転するのと同じような効果を与えているんだ。
もし自分が救急医療室に担ぎ込まれたら、担当医が何か決断を下す前に「最近、どれくらい残業してましたか？」と聞きたくなるような話だよね。でもここでは、こういった研究がプログラミングではどうなるかを考察してみよう。
プログラミングで精神集中は必要か？
プログラミングは気合を入れて精神集中しないとできないようなものだろうか？ 当然のことだけど、そのとおり。プログラミングとは心の労働だよ。プログラミングをしているときは、頭の中でいろいろな細かい事を並行して考えていく必要がある。プログラミング言語のことから、開発しているプログラムの部分部分のことまで。そのプログラムは、おバカさんや友達から構成される奇妙な共同体が書いているようなもんだ。労働時間が8時間から12時間に増えることで労働災害が生じるリスクが倍増するのであれば、開発しているコードにバグが混在するリスクはどれくらい増えるのだろう？ 産業災害の場合、測定可能な事故が生じる以前の段階から、作業している人達は効率が低下し、いろいろなミスをおかしているはずだよね。そういうちょっとしたミスが、ちょっとしたミスじゃなくなって、事故という形で具現化するわけだ。自分の経験から言うと、バグが混在する確率は労働災害が生じる確率とは比べ物にならないくらい高いはずだ。労働災害の統計をプログラミングにあてはめて考えると、疲れきったプログラマが致命的なバグを残す確率が二倍になるのは確かだろうけど、そこまで至らないバグを残す確率は非常に高いものになるはずだ。
不具合が与える多大な影響
不具合というのはソフトウェア開発においては致命的なものだよね。労働時間の三割から半分をバグ修正に費しているチームなんてのは、極々普通のはず。この修正時間は、本来なら新機能の開発にも使えたはずなわけだ。もしこういったバグがなければ、このチームは1.5倍から2倍の機能を提供できたわけだよ！まだある。不具合の修復というのはとても読みにくい作業だよね。バグ修復の平均作業時間が数時間というチームが、修復に数日から数週間必要なバグに遭遇する、なんていうのは珍しくない話でしょ。このことからも、バグ潰しというのは非常に重要だというのはわかるよね。そうでもなければ、何週間もかけてバグ潰しする必要なんかないわけだから。
こうやって考えると、バグを予防するというのは、バグを作ってから潰すよりも、はるかに時間と費用を節約できるというのは自明な話だよね。軍事ソフトウェア工学雑誌Crosstalkの最近の記事で、「バグの検出と修正は、大規模システム開発工程において最もコストがかかる要素だ」という記述がある。
もし不具合を残さずにプログラミングできれば、ソフトウェア開発は、より早く、より見積りしやすいものになるわけだ。Agile手法では、不具合を残さないためにプログラマによる網羅的な単体テストや顧客による受入テストをすることになっている。こういう工夫は、長時間労働環境ではどうなるだろうか？
プレッシャーのもとでは揺らいでしまうプラクティス
長時間労働というプレッシャーのもとに開発チームを放り込むと、品質への集中が減って、「ただコードを書く」ということに焦点がうつってしまうことが知られている。みんな頑固になって、助け合いをしなくなり、テストで手を抜き、リファクタリングしなくなり、結果として「ただコードを書く」ということになっちゃうんだ。その結果は明確で、不具合率が上昇し、コードの品質が下がり、実労働時間あたりの作業効率はどかんと低下しちゃうわけだ。Circadian社は最近ホワイトカラー層労働者の生産性を調査している。それによると、労働時間が10%増えただけで、ホワイトカラーの生産性は2.4%低下する。そして、週60時間労働となると生産性は25%も落ちるそうだ。
こういった研究からは、労働時間の上限がどのあたりにあるかということを見極めることはできない。ただし、一日12時間労働(週60時間労働）になれば、コードの品質が低下し、不具合率が上昇するであろうことは確実に言える。
じゃ、どうすればいいの？
高いプレッシャーのもとで長時間労働を強いる結果は明確。生産性は落ち、不具合は増える。悲しいことに、不具合率を測定できるのは、不具合が生じてからなんだよね。テストを減らすほど、不具合について知ることができなくなる。プレッシャーと長時間労働は、テストという我々が最も必要とする手段を奪いとってしまうのだ。じゃあ、どうしたら良いかという私の見解だけど、管理職も顧客も、ほんのちょっとのプレッシャーをかけるだけにしてほしいんだよね。それで開発チームのみんなに気合が入り、努力するようになる、というくらいのプレッシャー。ちょっとした脅しは、たとえそれがユーモアのつもりであっても、物事を一日は遅らせることになると私は思うのだよ。なので、「これを終わらせないとクビになるよ」みたいなことは、例え笑いながらでも言わないほうがいいだろうね。そんな言い方は役にたつとは思えないな。
でもこれを読んでいる人は僕じゃないんだから、受け止め方は異るかもしれない。プレッシャーが強すぎるとか、労働時間が長すぎるとかいったことを「測定」する手段はないものかね？ 僕にもよくはわからないんだ。でも、いくつかの案はある。
まずは、自分達がやるべきことはやった状況を想像してみよう。網羅的な単体テスト、各機能の受入テスト、継続的なビルド環境も構築し、ビルド失敗時にはその通知もされる、などなど。その上で、物事が変な状況に進んでいることを知らせる指標がないだろうか。例えば:
- テスト行数とコード行数の比率が下がってないか？
- 受入テスト件数と機能の比率が下がってないか？
- バグ修復に費す時間が増えてないか？
- ペアプログラミング率が落ちてないか？
- モジュール連結にかかる時間が増えてないか？
- ビルド失敗の回数が増え、その修復にかかる時間が伸びてないか？
- コードをきれいに見せる工程が省かれてないか？
- リファクタリング作業板が警告カードで埋まってないか？
- 開発部屋が以前より散らかってないか？
- ゴミ箱の中に捨てられた食事カスが以前より増えてないか？
- 朝会において状況説明を求める質問が増えてないか？
- そもそも朝会開催をやめちゃったりしてないか？
- ケンカ腰で議論する人が増えてないか？
たぶん、どの項目も簡単かつ非公式な「状況目安表」に記載できるでしょ。どの項目も、追跡して被害がでるわけじゃなし。でも、これらは確かに物事が悪くなる時の良い指標になり得るよね。
プレッシャーや労働時間が多すぎるときの指標として、他に何が挙げられるだろう？ 他にもあったら教えてほしい。この記事に付け加えていくから。 ということで、あまり頑張りすぎないように。無駄骨だから。
原文を読んで、かなり考えさせられてしまった。プログラミングはまだテストによる検証ができるのが救いかも。実際にはそのテストをする時間も意欲も奪いとっている*1のが多くの仕事場での現実なんだろうけど...
実装によってしかテスト検証ができないドキュメント書きをする人と、その実装をする人とが分業されているという非Agileな開発現場というのは、実は最初から生産性も品質も望みようがない方向に突進しているのではないかなぁ。
*1:テストを別チームに担当させる、ということ
