名著を読む「デスマーチ」

名著を読む

システム開発にまつわる著書を読み込んでいた時期がありました。その中で、名著と思われるもの、名著と呼ばれているものを紹介していきたいと思います。
IT業界自体が3K職場と言われる中で、デスマーチがどのように生まれ、どのように対応していくべきか。ということに対するヒントになる内容が書かれている本です。

デスマーチ ソフトウエア開発プロジェクトはなぜ混乱するのか

著者:エドワード・ヨードン
初版:1997年

この本は、以前、紹介した「人月の神話」「ピープルウエア」と比較すると新しい著書です。それでも、初版から20年以上を経過しています。この中では、デスマーチが発生する原因を、技術的な問題でだけではなく「ピープルウエア」でも描かれていた社会学的な問題であることを示しています。

デスマーチの定義

デスマーチは過酷な労働を強いられているプロジェクトを指す物ですが、著書「デスマーチ」のかでは、以下のようにデスマーチを定義しています。

デスマーチ・プロジェクトとは『プロジェクトのパラメータ』が正常値の50%以上超過したもの

「第1章 はじめに」より引用

例えば、正常に見積もられた作業期間を半分にされたもの。正常に見積もられた要員の人数を半分にされたもの。といったものがあげられます。「人月の神話」の中にあった妊婦の例え話で「妊婦が10人いれば、1ヶ月で子どもが生まれる」というのを、そのままやろうとしているのと同じようなことです。妊婦が何人いても子どもが生まれるには十月十日かかるのには変わらないのに、この常識に挑戦をしようとするものです。

また、デスマーチが発生する原因としては政治や楽観主義、競争激化など様々な要因があるとされています。そして、デスマーチ・プロジェクトに参画する人々がどのような人か描写されています。

デスマーチ・プロジェクトで行われていること

デスマーチ・プロジェクトは、酷い状況であっても中止されずに進行されている。というものでもあります。通常は、赤字に陥ってします。もしくは、確実に赤字になるのが分かっていれば、プロジェクトは中止されます。それでも、中止されずに進行するということは、そのプロジェクトは政治的な意味をもったものになっています。

このような政治劇の中の登場人物を把握し、プロジェクトのスタイルを把握すること、プロジェクトマネージャとメンバーがプロジェクトに対してどれくらい貢献できるかを把握することがデスマーチプロジェクトを乗り切るために必要なこととされています。

この政治劇の中で、いろいろな交渉ごとも行われるのですが、もし交渉に失敗した場合は「辞める」というのが取りうる手段ということです。

打開不可能な状況になったり、交渉相手が一切の譲歩を拒否したのなら、会社を辞めるのが合理的な行動

「第3章 交渉」から引用

日本のような会社ありきでの雇用体系であれば、異動や転勤を申し出ることができる会社もあると思いますが、アメリカのIT関連で仕事をする場合によくあるプロジェクトに所属するために雇用契約をするという雇用体系であれば、失敗が確実なデスマーチ・プロジェクトには参加する意味がない。となるものと思います。

デスマーチへの対策

デスマーチ・プロジェクトに対する対策として記されているものに「トリアージ」がある。

デスマーチ・プロジェクトではユーザが求めているものをすべて実現するだけの十分な時間はない

「第5章 デスマーチ・プロセス」から引用

私自身、入社して数年でプロジェクトリーダとして、お客様とリプレースするシステムに実装する機能についてお客様と打ち合わせをした際、お客様から要望された機能をすべて実現するのが優れた技術者だと勘違いをしており、ただでさえリプレース対象システムを導入した際の費用の半分しかないリプレース費用にもかかわらず、言われたものを何でもやります。と答えてしまい。とんでもない状況にしてしまったことがあります。

お客様のなかで誰がプロジェクトの成否を判定するのか、その判定条件は何なのか、ということを考えて、何とを取り組むべきか(トリアージすべきか)を考える必要があります。

機能不全に対する対策

デスマーチが起きている状況は、顧客、エンドユーザ、利害関係者、組織全体の機能不全として、クリティカルチェーンと制限条件(TOC:Theory Of Constrains)が挙げられていた。この二つの単語は情報処理技術者試験でも頻出のものであったので、言葉自体は知っていましたが、このような使い方をするんだ。と知った内容でした。

この中ではスケジュールの中にバッファを取ることが記載されていましたが、機能不全の組織の中では、バッファがある中、予定通りのスケジュールで終わると「工数を水増ししただろ」と上層部から指摘を受けるという記載もありました。確かに昔はこのようなことがあったと思います。今は、コンティンジェンシー予備費とかを事前に見積もっておくことが普通になっているので良いのですが、昔は各WBSに少しずつ分配して目立たないように予備費を作っていたりしていた方が多いかと思います。

ツールについて

デスマーチ・プロジェクトにいると、ついつい「銀の弾」を探したくなるものです。でもフレデリック・ブルックスの論文「銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項」にあるように、そんなものはないのです。

特にデスマーチ・プロジェクトの渦中で、所属している組織で実績がないものを使うのは危険です。どのような高機能な開発ツールであってもプロジェクト管理ツール、システム運用ツールであっても、使いこなせるようになるまで、どうしても時間がかかります。このようなものは、正常なプロジェクトで試行すべきものです。

デスマーチ・プロジェクトには、どんなツールであれ、まったく新しいツールを導入してはならないことを警告しておきたい

「第10章 デスマーチのためのツールと技術」から引用

例えば「テストを自動化したい」という衝動にかられたことがあります。今でこそCIツールに適合した単体テストプログラムを作るのは一般的ですが、その衝動にかられた時は、今のようなデファクトスタンダートと呼ばれるようような使い勝手の良いCIツールも存在せず、メンバーもテストプログラムを作ったことがない状況でした。このような状況で「テストを自動化したい」という漠然としてものをデスマーチ・プロジェクトに取り込んだら混乱に拍車をかけるのが目に見えています。

このようなものは正常なプロジェクトで実績を積み上げて、組織にとって必要なツールとなるまでは、デスマーチ・プロジェクトに取り入れるべきです。

読んでみて感想

この著書は、デスマーチ・プロジェクトに参画している時に読んだ著書でした。この著書の中ではプロジェクトマネージャやメンバー、いろいろな立場での振る舞いが描かれており非常に参考になった記憶があります。この著書の中でも記載されている「スカンクワーク」は試したことがあります。自社にいると余計な仕事が増えるので、メンバー丸ごと、パートナー様やお客様のところに場所を借りて、自社で仕事をしないようにする。といったことをしました。

いろいろなアイデアやヒントが溢れた内容で、初めて読んだときは衝撃を受けた覚えがあります。
近年は働き方改革もありデスマーチ・プロジェクトは減っていると思いますが、デスマーチ・プロジェクトにならないように、様々な交渉や対策を行っての結果だと思っております。この著書では、その部分にもフォーカスされていますので、是非、読んでみてもらいたいと思っておりました。

コメント

タイトルとURLをコピーしました