この業界、デスマーチという用語が安易に使われすぎていると私は感じています。自虐的な表現が好きな日本で、この言葉はとてもウケが良かったのでしょう、他の IT 系ことわざに比べて極端に有名です。
が、そのために誤用も増えてきました。たんに自分の仕事がきつい状態になることを「デスマってる」と表現する人がいますが、本当のデスマーチはそんなものではありません。まず、「マーチ」である以上、個人の問題ではないというのが最重要点です。
デスマーチとは組織の病です。ソフトウェア開発プロジェクトを計画するトップが未熟だと、その素人見積のせいで、見えていない部分の労力に予算と時間を確保されないまま、プロジェクトがスタートしてしまいます。冷静に考えて、リソースが半分しかなければ、50% 以上の進捗が出るはずがありません。愚かな組織人はなぜか、その明らかな失敗を見通す合理的判断をタブー視し、不可能な催促をしたり、品質を犠牲にしろとさえ言い出します。雇われ開発者の最優先インセンティブは今月の給料なので、わかっていても逆らえません。遠い先の失敗より目先の生活のためにと、不健全なプロジェクト管理に付き合うことになります。すると、その不条理さは精神を蝕んでいきます。この疲弊はさらに不条理を慢性化させ、理性を麻痺させます。そうして、次々と脱落者を出しながら、プロジェクトは予算と時間を無駄に消耗し、絶対に成功しない道に突き進んで行きます。そしていよいよ、予算が尽きると起きるのは、無償のスケジュール延期です。こうした悲惨な状況で延々と延期を繰り返し続けることがデスマーチです。
- 決まった期日の仕事が多いのはデスマーチではありません
- 個人に負担が集中しているだけではデスマーチになりません
- ハードワークでもリソースが十分確保されているのならデスマーチになりません
- いさぎよく失敗を迎えられるのはデスマーチではありません
- 理性の欠如が慢性化していないのはデスマーチではありません
- 精神を病んだ脱落者が出る可能性がないのはデスマーチではありません
こう説明すると、デスマーチなんて起きないんじゃないかと思われるかもしれませんが、残念ながら現実には、きっかけさえあればすぐに、このすべてがいちどに押し寄せます。
この本当に病んだ組織のあり方を表すために、デスマーチという言葉を使って欲しいと思うのです。たしかに、時代とともに言葉は変わっていくのは一理あるのですが、かといって、「あ〜、今日は残業だからデスマだな」などと気軽に使うと、せっかくあった「組織の病である」という意味合いが失われてしまいます。
「デスマーチ=死の行進」の語源は、冗談じゃない本当の人の死です。ナチスがユダヤ人を移送したときの非人道的な行進、あるいは、太平洋戦争の東南アジアでの捕虜移送のさいは、米軍/イギリス軍の負傷兵だけでなく日本人までもが、無計画な強制行進によって、じっさいに多くの命が失われました。「デスマ」はこれに由来します。上層部の現場への無関心、明らかに足りない設備、理性を欠いた指示、疲弊が常態化した中での無謀な計画、そうしてバタバタと人が死んでいく有様。失敗プロジェクトとの類似点のなんと多いことか。
日本人として、この歴史を知ってなお間違った意味でデスマーチを使うかどうかは、みなさんの道徳心に委ねます。
ここまでのアンチパターンは、開発と設計に関するものでした。アンチパターン本にはこのあとにも同じぐらいの数のパターンが紹介されています。この後半部分は、主に組織論やプロジェクト管理に関するパターンとなっていますが、アドベントカレンダーの日数が足りないのと、楽しく読めるあるある話でなくなるため、シリーズはここで区切らせていただきます。ご容赦のほど...
その代わりとして、組織とプロジェクトのアンチパターンが行き着く先である、デスマーチを紹介しました。興味がある方はこちらのパターン集から、関係しそうな項目に目を通してみてください。
まとめ
日本で翻訳版のアンチパターン本が出版されたのは 2002 年ですが、原著が執筆されたのはなんと 1998 年です。おかしいですね。開発とアーキテクチャに関するアンチパターンを読んで、なにか気づくことはありませんか。
そう、これらのアンチパターンは 1998 年以前にすでに存在したにもかかわらず、その指摘する問題点は、ドメイン駆動設計やアジャイル開発、クリーンアーキテクチャの対象とする問題と同じなのです。さらに、アンチパターンの解決策を「リファクタリング」と呼んでおり、ブロブのリファクタリング工程などは、ファウラーのリファクタリングそのものです。
ドメイン駆動設計の原著は 2002 年です。この数には 2 つの驚きがあります。DDD がそんなに古い本なのかということと、アンチパターンはさらにその 4 年前だということです。(ちなみにデスマーチは 1996 年です)
1998 年の時点で、すでにこれだけの問題が見つかっていたというのが真実です。プログラマーのみなさんなら、問題を発見しさえすれば、解決策はすぐにわかるはず、という理屈はご存知ですね。アジャイル開発や DDD には、実は、何ら新しい発見はなく、90 年代からわかっていた問題の解決策を、たんに強い力で実行に移しただけのものと理解できると私は思うのです。
ではなぜ、20 年経った今なお、アンチパターン的問題が起きつづけ、その解決にアジャイルだの DDD だのクリーンアーキテクチャだのが持ち出されるのか。それは、アンチパターンが人と組織の性 (さが) から生まれる普遍的なものだからだと思うのです。
デザインパターンは、前提とするプログラム言語が発展したことで、GoF パターンのあれは価値が下がっただの、あれを取り入れるべきだだの言われ、時代とともに変化する側面があります。いっぽうアンチパターンは、人間が変わらない以上、新しい人が業界に増えるたびに、いつまでも繰り返されるように思うのです。
マンガでは、当時の表現でプロプライエタリ製品となっている箇所を、意図的に「フレームワーク」や OSS ライブラリに置き換えて表現しました。すると、驚くほど、ごく最近のあるある話になりました。初回に言った、アンチパターンはデザインパターンより偏在するというのは、上手い下手がその理由というだけでなく、時代を超えて人からつねに発生するものだという意味もあります。
冗談のような古典の紹介に見えるアドベントカレンダーでしたが、アンチパターン本の前半が語っていたのは、いまをときめくアーキテクチャだのパラダイムだのの、根源にかかわる話だと伝えていたつもりでした。このメッセージがみなさんに届くとよいのですが。