この記事はRegional Scrum Gathering Tokyo 2023のセッション、「デスマーチから身を守るたったひとつの方法」のサポート記事で、荒ぶる四天王ことQCDSについて、「トレーダビリティ」、つまりトレードオフできるかどうかについて考察したものです。

「トレーダビリティ」という語は思いつきで、軽くググったところソフトウェア開発の文脈では用いられていないようでした。それ以外は既知の事柄を独自の解釈で再構築したものなので、特に目新しい内容はないと思います。ご意見や間違いの指摘などフィードバックがありましたらお寄せいただけると幸いです。

TL; DR

  • 書籍「アジャイルサムライ」に定義された「荒ぶる四天王」とは…
    • Quality : 品質
    • Cost : 予算
    • Deliver : 時間（スケジュール）
    • Scope : スコープ（何をどこまで作るか）
  • スケジュールの達成が見込めない状態になった場合…
    • 品質を犠牲にしても達成できない
    • 予算を追加しても達成できない
    • 稼働時間を増やすことで達成できる（かもしれない）
      • いわゆる「デスマーチ」が発生する
  • デスマーチを避けるためには…
    • 時間を延ばす
    • スコープを削る
  • 時間もスコープも調整できない場合、できることは…
    • デスマーチに突入する
    • 逃げる

順に考察していきます。

荒ぶる四天王

「アジャイルサムライ」P.86より

スケジュールの達成が見込めない状態

ソフトウェア開発の進捗をごく単純にモデル化したものが以下の等式です。

スコープ = 速度 x 時間

開発速度に開発時間を乗じたものがスコープ、つまり成果物の量であるというシンプルな計算です。

与えられた時間では要求されたスコープを達成できないことが予想された場合、なんらかの手立てを講じる必要があります。「荒ぶる四天王」のいずれかをトレードオフすることを検討することが多いでしょう。

ソフトウェア開発においては、「なにを、いくらで、いつまでに」という約束が取り交わされている場合があります。トレードオフの対象として「時間」と「スコープ」を選びにくい、選べない、という状況を経験された方も多いのではないでしょうか。

「時間」と「スコープ」を調整しないという選択をした場合、開発の「速度」をあげるしかありません。では、何らかの手段で、短期的な開発速度を手に入れられるのでしょうか？

品質を犠牲にしても達成できない

近年、和田卓人さんの講演「質とスピード」によって、「内部品質を犠牲にしても速度は得られない」ということが知られるようになってきました。

ここでは「損益分岐点は1か月以内にやってくる」と論じられています。ソフトウェア開発プロジェクトの規模を考えると、期間内に損益分岐点が訪れるケースが大半ではないでしょうか。

ここまできちんと論じなくても、「単体試験を手抜きした結果、結合試験や総合試験でで大爆発」という事態を体験した方も少なくないと思います。品質を犠牲にして得られる速度の向上は実に微々たるもので、たいていの場合プロジェクト終了前に損益分岐点が訪れ、遅延をさらに大きくしたり、遅延するよりもっと悪いことの原因になったりします。

予算を追加しても達成できない

品質を犠牲にしても速度は手に入りません。では、予算を追加すると速度は手に入るのでしょうか？

「進行中のプロジェクトに予算を追加する」が意味することは、ほぼ間違いなく「人員の追加」です。そうでない予算の追加（たとえばコンピューティングリソースや開発環境への投資）による生産性の向上が見込めるのであれば、それによって速度が向上する可能性があります。もちろん最初から準備しておくほうがよいのですが。

では、人員を追加すると開発速度は上がるのでしょうか？この問いに対する答えも、おそらく No です。「ブルックスの法則」によると…

  • 「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」
    • 新たに投入された開発者が生産性の向上に貢献するまでには時間がかかる
    • 人員の投下はチーム内のコミュニケーションコストを増大させる
    • タスクの分解可能性には限界がある

実際の開発現場での経験からも、この法則を否定する材料には思い当たりません。オンボーディングにはリードタイムが必要ですし、コミュニケーションパスが増えると意思疎通に時間がかかりますし、カップ麺の完成を待つお湯を入れてからの3分間を並列処理で短縮することはできません。

オンボーディングのリードタイムとコミュニケーションコストが不要なスーパーエンジニア、という存在が増員されるのであればその限りではありませんから、そんなエンジニアを確実にアサインできる方法があったらぜひ教えてください。

中長期的には人員を追加・訓練することによってチームの開発力を高め、その結果として速度を向上させることは可能ですが、「いつまでになにをつくる」という約束がピンチになるような場面では、即効性のある速度向上を期待するのは無理がありそうです。

稼働時間を増やすことで達成できる（かもしれない）

開発速度を向上させる施策に即効性のあるものは、どうやらなさそうです。そんなときに取りうる最後の（そして最悪の）手段が、「稼働時間を増やす」、つまりデスマーチです。

速度（単位時間あたりの生産量）は変わらない、スケジュール（デッドエンドとなる日時）も変えられない、スコープ（こなさなければいけない作業量）も変えられない。であれば、デッドエンドまでの期間中できるだけ長く稼働することで、より多くの作業量をこなすことができるはず、というとても無邪気な発想が、デスマーチを発生させる原因となるのです。

達成できる「かもしれない」とカッコ書きをしたのは、長く稼働しても同じだけの速度を維持できるかどうかに疑問があるからです。長時間稼働によって気力や体力、集中力は漸減していくでしょうから、その影響で速度や品質も低下するでしょう。

デスマーチを避けるには

速度を短期的に向上させるのとても難しいので、無理のあるスケジュールを達成するためには無理のある長時間稼働、つまりデスマーチが発生しそうです。デスマーチを避けるために、どんな対策があるでしょうか。

時間を延ばす

スケジュール（デッドエンドとなる日時）をより未来にずらすことで、1日あたりの稼働時間を増やすことなくトータルの作業時間を増やすことができます。同じスコープの成果物を得るのは先のことです。

スコープを削る

スコープ（作る範囲）を減らすことで、作業に必要な絶対的時間が減少します。1日あたりの稼働時間を増やさないのであれば成果物の総量は減少します。

時間もスコープも調整できない場合、できることは…

しかし、前半で述べたように「時間」と「スコープ」に強い制約がある場合も多いでしょう。そのような場合に、以下の二択が発生します。

デスマーチに突入する

漫然と開発を続けていれば、いずれ稼働時間でスケジュールとスコープをカバーする「デスマーチ」が発生します。

デスマーチが発生すると長時間労働が常態化し、心身の健康や身近な人間関係に大きな悪影響があります。その結果としていったい何が得られるのでしょうか？エンジニアとしての成長の機会である、という側面は確かに存在します。しかし、その代償として払わねばならない悪影響の大きさを考えると、とてもリスクとリターンの収支が釣り合っているとは言えないでしょう。

逃げる

デスマーチは、それを強いている側からすると都合のいい状態です。単純なコストとしての「残業代」を支出するだけで、無理のあるスケジュールとスコープを達成できる（かもしれない）からです。なので、時間と共に解消することを期待するのは無邪気すぎるでしょう。

現状がデスマーチであり、回避するための手段が自分の側に残されていないのであれば、心身の健康と人間関係を守るためには逃げるしかありません。

ということで

「荒ぶる四天王」が引き起こすデスマーチから身を守るためのたったひとつの方法として「逃げる」をご紹介しました。

Regional Scrum Gathering Tokyo 2023のセッション、「デスマーチから身を守るたったひとつの方法」もお楽しみください！