クランチモードがスーパースターを平凡に

James Golick氏とReg Braithwaite氏は最近の一連の投稿で、チームを「クランチモード」（訳注：開発チームに追い込みをかけて高負荷状態で仕事をすること）に入れることが、実際にどれだけの *望ましくない* 結果を生じるかについて議論している。チームに圧力をかけるとプロジェクトが良くなるどころか悪くなってしまうという、様々な理由について2人は論じている。そして、チームとマネージャーは、異なるアプローチをとることでどのような利益を得られるのかについても触れている。

「クランチモード」の発動は、皮肉なことに全体の生産性を減少させることに最も効果がある。なぜならオールスターチームを平凡なプログラマの集団に変えてしまう(source)からだ。というのがJames Golick氏によって出された最初の仮説である。優れたプログラマを高度に生産的にしているプラクティスが、クランチモードによってまっさきに無視されるようになってしまうとGolick氏は主張する。

優れた開発者と、手間隙をかけてふるい落としてきた平凡な開発者の間の、恐らく最も大きな違いは、以下のようなものです;スーパースターの優先事項はコードです。しかし、平凡なプログラマの優先事項はとにかく帰宅することです。しかし、あなたがそのクランチモード・スイッチをONにした場合、優先事項は変わります。

期限までにタスクリストを終わらせようとやっきになっている場合、できるだけ多くの機能を短い時間でを完了させようと毎日作業することになります。プレッシャーがかかります。人々は手を抜き始めます。開発プロセスは崩壊します。どんどんテストを書かなくなり、リファクタリングもほとんどしなくなります。いとも簡単に、スーパースターチームが平凡なプログラマの集団になってしまいます。

Golick氏は続けて、チームに圧力を加えると悪い結果を招くことになってしまう、他の理由も説明している。

デスマーチにチームを送り込むと、プログラマはすぐに疲弊します。プログラマの疲弊は常に、悪いコードを意味します。さらに、開発者達はやる気を失い、燃え尽き、作っているものに関心を失って、（これが最も悪いことかもしれませんが）管理にうんざりすることになるでしょう。多くの場合、ひどいバグや、保守性が低下して書き直しを強いられることから、クランチモード開発者の総合的なアウトプットは低下してしまいます。

記事は次に、プログラマが「クランチモード」による敗北を避けるために気をつけるべき、2つの提案をしている。

1. プレッシャーを気にしないようにしましょう。まず第1に、製品をよりよくするプラクティスを中止してまで時間を節約するという、落とし穴を回避してください。
2. とにかくノーと言いましょう。あなたが一番やらなければならないのは、ステークホルダーに対して、品質を犠牲にして多くの仕事を要求すると、どんなひどい結果になるかを理解してもらうことです。

あなたは、クランチモードが終わった時(また、私たちは、きれいにするための時間が実際には決して得られないとわかっています)、この悪夢をメンテナンスしなければならないのです。あなたの会社は品質の悪いソフトウェアと、恐らくボロボロになっているリリースに対処しなければならなくなるでしょう。みんなが負けることになります。

Reg Braithwaite氏の以前の記事(source)でも、この「ノーと言いましょう」という第2のポイントに触れている。Braithwaite氏は、ソフトウェア専門家として、我々は製品を作り上げる方法を守る一定レベルの義務を持っているが、多くの場合には、ステークホルダのリクエストに応えるための落としどころが存在すると言っている。

決定の結果に責任を負う人が、自分たちの判断に従うよう主張するなら、私は本能には反してもその主張に従うことがあります。他方では、ユーザの個人情報を危険にさらすような不安定なソフトウェアを開発するように依頼された場合、私は、個人的にはノーと言う選択をするでしょう。

Golick氏の更新に応じて、Braithwaite氏は、マネージャーたちが「本当にこの一回だけだ」といって正当化しようとも、「クランチモード」の発動は例外的ではない(source)として、議論を重ねた。 Braithwaite氏は「クランチモード」が頻繁に起きたり、そのように事前に計画されていた場合、「クランチモード」は例外でないと主張する。そして「クランチモード」の発動や失敗したプロジェクトを、「計画されていないもの」と多くのマネージャーおよび開発者が一般に見なすことに対して反論している。

 私は、どんなバグが発生するか正確には分かりませんが、バグの発生や要求追加、見積もりミスがあることを統計的に知っています。ですので、「この振る舞いに対するビューが必要になるとは思いませんでした。他のものが期待通りに動作しないとは思いませんでした。だから、テストなしで開発を終わりにする必要があります」などと、私ならボスに言ったりしません。

私はこうしたことの発生を予測できるし、実際に予測します。したがって、私は対応策を準備することができるし、準備しなければならないと思っています。

なぜアジャイルプロジェクトで近道を回避するべきかについて他の視点を得たい場合、このInfoQニュース記事(参考記事・英語)を見て欲しい。

原文はこちらです：http://www.infoq.com/news/2008/02/crunch_mode_allstar_paradox