- 今日のプログラミングは、90年代や2000年代初頭よりもはるかにストレスが多い
- 当時は締め切りの近くでだけ仕事が狂ったように忙しくなり、それ以外の時期は比較的穏やかだった
- ここ数十年でストレスが増えた理由を考えてみた
- 競争、市場の変化、厳しい締め切りのせいではなく、スプリント方式の作業のせいである
1. スプリントは止まらない
- スプリントは終わりのない連続的な締め切りである
- ウォーターフォール方式は実際の締め切りやイベントに合わせられていた
- スプリントは人工的な締め切りであり、自然な休息時間がない
- 短期的なストレスは健康によい場合もあるが、長期的なストレスは身体に有害である
2. スプリントは自発的ではない
- チームが自発的に2週間ごとにコードをデプロイするのとは異なる
- スプリントのあらゆる側面が規定されている
- 自律性は作業体験において重要な役割を果たす
- 強制的な作業はストレスと不快感をもたらす
3. スプリントは重要な支援活動を無視する
- スプリントは次の作業を準備する時間を与えない
- 作業を行うには準備時間が必要である
- スプリントは準備と実行を切り離そうとするが、これはストレスを引き起こす
スクラムフォール: 現実の（そしてより悪い）構図
- ほとんどのスクラム実装はウォーターフォールとスクラムの混合である
- 大きな締め切りが常に背景に存在する
- 大きな締め切りが近づくとスクラムは中断され、ストレスが増加する
結論
- スプリントには休みがなく、自律性が不足し、準備時間も足りない
- 開発者は自分の仕事とプロセスをコントロールできるべきである
- そのためには倫理的な組織を構築するか、フリーランスに転向するなどの努力が必要である
GN⁺のまとめ
- この記事は、スクラム方式が開発者に継続的なストレスを与える理由を説明している
- スプリントの連続的な締め切り、自律性の不足、準備時間の不足が主な原因である
- 開発者が自分の働き方をコントロールできるようにするべきである
- 類似の機能を持つ他のプロジェクト手法としてKanban方式がある
8件のコメント
SIや公共分野などのプロジェクトを進めるときでさえ、phase 1、2、3…という具合に休みなく追い立てられています。そして、その個々のphaseごとにまた大きな変更が次々と発生します。これでは、開発を成功させるためのscrum本来の目的も決して達成できません。ただただ混乱したこの修羅場のような落ち着かない雰囲気の中で、開発者だけがすり減っていきます。
現職のPMです。
うまく機能していると感じたアジャイル／スクラムでは、主要なスプリントが終わると振り返りを行い、休息の時間が与えられていました。開発チームも企画チームも、次のことを準備する前に休めるタイミングがありました。
本文と同じようにうまく機能していないと感じたやり方では、ウォーターフォールで降りてくるデッドラインの下で、プロダクトチーム内部でもスクラム方式を同時に回していたためストレスが増大しましたし、デッドライン自体が変更不可だったので、休息や振り返りの時間もなく毎週走り続けることになり、終わりのないランニングのような感覚がありました。
ウォーターフォールの意図は、できるだけ要件を早い段階で特定し、設計・実装・テスト作業の間には依存関係があるのだから、仕事を順番に進めようということ、そしてアジャイルやスプリントの意図は、ウォーターフォールで事前に設計したり実装したりするには量が多すぎる仕事を小さく分割してやってみようということだと、私は理解しています。どちらにも長所と短所があり、方法論を教条的に追求するよりは、状況に合わせて必要なものだけ取捨選択してもいいのではないかと思いますね。記事で主張しているように、休息も必要でしょうし、技術レビューやプロトタイプを作るための準備時間も必要でしょう。誰が作業の順序を決めるにせよ、阻害要因を理解し、実務の流れに沿って優先順位を決めさえすれば、開発者の自律性の有無もそれほど関係ないのではないかと思います。
開発経験はまったくないのに、開発方法論の手順を盲目的に適用しようとするマネージャーが海外で大量に生まれているので、海外ブログにこういう記事が載るのでしょうか。まるで、現場の実務をまったく知らない企画担当者と開発者の間の対立を見ているようですね。
実務の流れに従って優先順位を最もうまく決められるのは開発者自身のはずですが、自律性を奪ってそれを他人が代行するというアプローチ自体が、むしろ実務とチーム計画の分断を引き起こす原因だと思います。
マネジメント自体も一つの専門分野だとするなら、たとえ開発経験のないマネージャーであっても、開発リソースのマネジメントがうまくいかなくなる局面に直面したとき、その状況への答えはマネージャーが適応または対応すべきだと考えます。ところが、この責任の所在が個々の貢献者に転嫁されるのをあまりにも多く見てきましたね...
最終的な責任はマネージャーが負うべきですよね。けれど、現実はどうもそうではないようです。まるで、経営しかできないCEOが会社の事業をまったく理解できず、しばしば会社を潰してしまうように。
ただピンポンしているだけのPMが多すぎます……
Hacker Newsの意見
Rich Hickeyの言葉を引用しつつ、プログラマーは短距離走者のように、100ヤードごとに号砲を鳴らして新しいスプリントを始めるやり方で問題を解決しているわけではないと述べている
ソフトウェアプロセスが嫌いになった。チーム規模を適切に設定し、開発者に目標を達成できるよう権限を与えれば、管理主導の生産性フローがなくてもうまくやれる。Agile などは、管理者が自分の給料を正当化するために存在している
「スプリントが自発的ではない」とはどういう意味なのか気になる。チームがスプリントの性質を選ぶのであって、ランダムに割り当てられるわけではない。リーダーシップ、チームメンバー、チーム外のステークホルダーの協業である。なぜスクラムがそれほど硬直的なのか説明してほしい
スクラムが最初に出てきたときから、開発者がずっとスプリントし続けるという考えはおかしいと思っていた。スプリントは短く速いもので、その後には休息が必要だ。すべての作業をスプリントにするのは狂っている
スクラムは実際には、よりひどい「スクラムフォール」に変わってしまうことが多い。最初はリモートチームのコミュニケーションのためにスクラムを使っていたが、次第にマーケティング主導の目標とストレスの多いスプリントへと変質した。開発者の燃え尽きは明らかだった
2000年代初頭には、エンジニアチームがプロジェクトマネージャーなしで自律的に働いていた。ソフトウェアは今ほど相互接続されておらず、デプロイサイクルも長かった。現在は CI/CD と継続的デプロイによって、すべてが速く進む。SCRUM はストレスを与える
ほとんどの会話は、「自分の職場のスクラムは X、Y、Z のせいでいまひとつだ」と「それは理想的なスクラムではない」に要約できる
40年間ソフトウェアを開発してきたが、どんな方法を使うにしても、作業を分割し、目標達成を示さなければならない。小さなチームでは単純なコードベースなら Kanban で十分かもしれないが、大きなチームや複雑なソリューションでは報告が必要だ
Agile、Scrum、Standups などは使っていない。週1回の会議で優先順位を再設定し、チケットシステムで進捗を追跡している。開発者が自律的に働けるようにしている。会議や TPS レポートよりも、コーディングにもっと多くの時間を割くべきだ
8社で働いた結果、Basecamp の Shape Up アプローチが最も成功していた。「何日かかるか」ではなく「どれだけの時間を投資するか」を問うことが重要だ。Shape Up は 6週間のサイクルの合間にクールダウン期間を設けており、一貫して成功する製品を提供している