デスマーチの原因

ソフトウエア開発は毎日のように終電近くまで続き、週末出社してもまだ開発がスケジュールに追いつかない。

IT業界ではそんな話はいくらでもあって「デスマーチ」なんて呼ばれています。

デスマーチは毎日遅刻して午後から出勤するプログラマとか、何日も欠勤するプログラマとか、会社を辞めてしまうプログラマを生み出します。

そんな状態でまともな開発なんてできるわけがなく、デスマーチとプロジェクトの失敗はほぼイコールです。

デスマーチでしたけどスケジュール通り終わりました、なんてプロジェクトもリリース後のサポート作業で失敗だったことが証明される運命にあります。

デスマーチの言い訳

デスマーチに陥ってるプロジェクトのメンバは大体こんなふうに言い訳します。

仕様変更が多すぎた

仕様が変わってばかりだからこうなった。

前の仕様でせっかく実装したコードを捨てて新しいコードを書くために時間をとられたのが原因だ。

そもそも仕様が決まってなかったし。

でも・・・

仕様変更の追加費用と追加工数をなぜ要求しないのでしょうか？

それに仕様が変わっても対応できるように設計できます、って言ってませんでしたっけ？

そもそも仕様がない、て・・・見積工数に仕様書作成が入ってますが。

デバッグにはまった

ソフトウエア開発ってのは複雑なバグがつきもの。

そんなバグがある程度出ればデバッグにはまってデスマーチになる。

でも・・・

何十年か前はそんな話もありましたね。

低級言語と低機能なデバッガで開発してたのですから。

でも、ポインタとか関係ない言語で高機能なフレームワーク使ってなぜデバッグにハマるのでしょうか？

デスマーチの原因の調べ方

デスマーチプロジェクトをテコ入れする場合、遅れているタスクを前に進めるとか当座の対策は当然必要ですが、デスマーチに陥った原因を明確にする必要があります。

これは別にデスマーチの犯人探しが目的でなく、原因が顧客にあるなら顧客に改善要求を出すなり、工数(=金)を出してもらうなりの交渉が必要になりますし、自社に原因があるなら当然解決方法を探る必要があるからです。

デスマーチの原因もわからないまま応援の人員を入れるなどすればどうなるかは目に見えています。

1. プロジェクトのマイルストーンをリストアップする
2. マイルストーンごとにソースコードをビルド
3. マイルストーンごとに機能確認

プロジェクトのマイルストーンをリストアップする

ここでいうマイルストーンとは、

• 機能実装終了
• 結合の直前
• 仕様変更の直前
• 時間のかかったバグ処理の直前
• 他

みたいな感じです。

ここで「マイルストーンがわかりません」なんて言うメンバがいたら、それがデスマーチの一因です。

マイルストーンごとにソースコードをビルド

え？デスマーチの原因究明にビルドなんて細かい「作業」が必要なの？

と思う人はソフトウエア開発のプロマネには向きません。

ソース管理システムからマイルストーンに対応するソースコードを複数組、取得してビルドしてもらいます。

「ソースがバージョン管理されていません」なんて話もあります。

バージョン管理すらできないならデスマーチになるのは当然です。

結構よくあるのが機能実装終了後のソースが「ビルドできません」ってパターンです。

少なくとも機能実装終了後のソースは機能単位ではビルドできるはずです。

なぜなら最低限、プログラマレベルでの動作確認がされなければ「実装終了」になるわけないのですから。

にもかかわらず動作確認以前にビルドすらできない。

これはマイルストーン未達ですからスケジュール遅れということです。

しかし、報告書ではオンスケジュールだったりします。

実際にコードをビルドさせず、メンバからヒアリングするだけではこういったことは見えてきません。

マイルストーンごとに機能確認

ビルドしたモジュールを実際に動作させ、そのマイルストーンで実装予定だった機能が全部動作するか確認してもらいます。

全部動作しなければ、そのマイルストーンは達成できていなかったことがわかります。

ビルド同様、デスマーチプロジェクトではそんな状態でも報告書ではオンスケジュールとなっていたりします。

「バグがあるからまだ動かせなかった」とか「単体では動かせなかった」なんて言い訳が出てきたらこう説明します。

• 単体実装完了とはコードを書き終わったことではありません。
• プログラマレベルでの単体動作確認ができないのなら、マイルストーン未達と報告してください。

よくある本当のデスマーチの原因

こうして原因を調べていくとデスマーチの本当の原因が見えてきます。

実際、よくある本当の原因はこれです。

仕様変更やらバグ処理以前に実装ができていないのです。

仕様変更だのデバッグだの以前にプログラマに実装スキルがないのですから、デスマーチになるのは当然です。

プログラムが書けないプログラマ

ここで言っている「実装」とはプログラマを書くことです。

プログラマを書くのがプログラマの仕事です。

でも、実際の開発現場にはプログラムを書けない(実装できない)プログラマが多数います。

なぜプロの現場にそんな人が？

って思っちゃう人はIT業界をよく知らない人でしょう。

いるんだから仕方ありません。

実装できない、つまり仕事ができないなら仕様書を読み、言語仕様を読み、ライブラリ仕様を読み、などをやってからプロジェクトに参加するのが筋。

しかしIT業界でプログラムできない自称プログラマがいきなり実戦でとりあえずプログラムを作り始め、行き詰ってまた作り直し、また作り直し・・・、

という試行錯誤で膨大な工数を浪費、ってのはよくあることです。

顧客へは「素人がプログラムしてるんで工数がかかるんですよ」とは報告できませんから、別なところに原因を押し付けるしかありません。

デスマーチからの脱出

当たり前のことを当たり前にやればデスマーチから脱出できます。

まともにスケジュールを引く

こんなことをするのがマネジメントスキルだど本気で信じている自称プロマネは多いです。

顧客にとってはそんな見積で2倍の金をボッタクられるんだからたまったものではありません。

しかもそんなプロマネではどうせ2倍の工数を浪費してもまともな品質のシステムはできないでしょう。

機能毎にプログラマに実装方法を簡単な図解にしてもらうことです。

それによってプログラマも頭が整理され、問題点や正確な工数が見えてきます。

まともに進捗管理する

• ビルドエラーだがとりあえずソースコードをコミットした。90%実装終了。
• 実装できてない機能はあるが90%できている。次の工程に進もう。

まともに進捗管理されていないプロジェクトではこんなことが行われています。

90%終了、10%だけ残して「ほとんど終わりです。ほとんどオンスケです。」

とはデスマーチに陥る前のプロジェクトでよく聞かれる話です。

100%できてないなら、マイルストーン未達とし、残り10%の対策をするのが本来の管理です。

この残り10%でプログラマが先に進みたがる理由は疑いなく「ここは実装が難しいから後回しにしたい」だからです。

テスト品質云々は全部実装できてから

テスト、品質は重要です。

しかし、それら以前に当然できていなければいけないことがあります。

プログラマとしてソフトウエア会社としてこのあたり前のことができるか否かわからない状況……

・・・であればテスト品質云々する意味なんてありません。

実装すらできない人達が実装以上のスキルが要求されるテストをまともにできるわけがないからです。

テストと品質のための工数は確かに重要ですが、それをデタラメな進捗管理と報告の免罪符として無理矢理テストフェーズに進めればデスマーチを生み、結果的に最悪の品質となります。

デスマーチから脱出する方法

仕様変更など発注側の責任にされがちなデスマーチですが、同じような仕事を受注していてもデスマーチになる会社とならない会社があります。

ここまで述べてきた通り、デスマーチの主な原因がプログラマのスキル不足にあるからです。

とくに複数のソフトウエア会社で開発する大きなプロジェクトではデスマーチ常習会社は結構目立ちます。

そんなデスマーチ常習会社でデスマーチから脱出する方法は？

・・・会社を辞めて転職するかフリーランスになることです。

冗談で言っているのではありません。

デスマーチ常習会社でも自分が役員(「役職」でく「役員」です)など重要な地位にいれば前向きな改革もできるかもしれません。

一社員が会社のデスマーチ体質を改善するのがどんなに難しいかは、数年間デスマーチ常習会社を見ていればよくわかります。

逆に「社員がどんどん辞めていく」というのはデスマーチ常習会社にとってはプラスに働く場合もあります。

なぜ辞めていくのか重要な地位の人達に考えるきっかけを与えるからです。

デスマーチから解放されれば、はじめてプログラマーの本来の仕事である「開発」ができるようになります。

「徹夜する」とか「毎日終電で帰る」なんてのは「開発」でもなんでもありませんからね。

フリーランスなら参画も撤退も自由

経験豊富な人ならデスマーチとなるのが明らかだとわかるプロジェクトがあります。

そんなプロジェクトでも「会社の指示」であれば嫌でも参画しないといけません。

SESの契約切れでデスマーチプロジェクトから撤退可能でも「会社の指示」であれば契約更新しなければなりません。

そんなデタラメな指示をする理由は「とりあえず現場に社員を突っ込でおけば金になる」と考えているからでしょう。

それが会社員の悲しい宿命でが逃れる術はあります。

フリーランスになることです。