From リスキルテクノロジー 松田航
新宿本校にて、、、
『デスマーチ』という言葉は知っていますか？
今回はデスマーチについて話をしましょう。
IT業界だけではない
社会問題化しているデスマーチ
「デスマーチ」というのは
アメリカのプログラマーが提唱した
プロジェクトマネジメントに問題が発生している状態。
日本では略して「デスマ」とも言われています。
日本語にすれば、文字通り...
「死の行軍」
を意味し、
進んでも進んでも解決しない...
つまり、どれだけ開発を行っても
なかなかシステムが完成しない状況を意味します。
具体的に言えば、以下の様な状況に陥っています。
・残業時間が極端に多く、月間労働時間が300～400時間にも
・休日出勤は当たり前で、休みが取れない
時間がいけないというよりかはこれだけ働いても、
進まないことが問題でしょうか。
また、自らの意思がないことも。
私自身は上記２つとも、
常にやっていますね。
好きで。
個人的な話はおいておき、
このような状態が長期間続くことにより
プログラマーを始め多くの開発者が心身共に疲労しきってしまい...
体調不良で出勤できない者、
翌日から連絡なしに急に来なくなる者、
心の病になってしまう者など、脱落者が出るケースも。
まず、最初にお断りしておきますが、
この事象はIT業界に限ったものではありません！
むしろ業界は関係ありません。
どちらかというと
昔はIT業界でこのような状態が目立った為、
最近のIT業界ではデスマーチを避ける努力が行われています。
業界を問わず、
企業によってデスマーチと同様の事象が起きており、
社員が過重労働が強いられて労災問題にまで発展するなど、
近年、重大な社会問題とされているのです。
デスマーチはなぜ起こるのか？
デスマーチが発生する理由はさまざま。
ですが、最も簡単に表現するなら...
「安請け合いと状況把握能力の欠如」
...という言葉が妥当な表現になります。
IT業界において
デスマーチが発生する原因をいくつか挙げてみましょう。
(1)開発期間不足の問題
本来開発に1年は必要な案件を...
「3か月でできます！」
...と顧客に応えて受注してしまった。
つまり開発期間が圧倒的に足りていない。
(2)人的要員の不足
どう少なく見積もっても
SE2名、PG5名はプロジェクトに必要であるが、
実際にはSE兼PGが1名と初級PG2名しか要員が確保できない。
つまり開発に必要な人手が足りない。
(3)予算が足りない
開発に対する予算がなく
外部から開発要員を雇おうにも雇えない。
また開発するには
特殊な機器や必要となるが
それらを購入・レンタルする予算がない。
つまり開発に必要な運転資金がない。
(4)ユーザーニーズが多すぎる
ユーザーが開発システムに対し、
あの機能もほしい、この機能も欲しいと
多くの機能的な要求を提示してくることにより、
対応しなければいけない機能が膨大な量に膨れ上がる。
また、一度作った機能に対しても...
「やっぱりこうしてほしい！」
...と、頻繁に仕様変更を行うため、プログラム変更が頻発する。
つまり開発期間や開発要員、開発費用など、
それらに見合うもの以上の要求がユーザーから発生している。
デスマーチという状態は
これらの要素が複雑に絡み合って発生します。
共通しているのは、
ユーザーと話す立場の者（営業やプロジェクトマネージャなど）が...
・受注さえすれば何とかなる
・ユーザーの要求を鵜呑みにする
・現場の状況を把握できていない
...という傾向がある場合に
デスマーチは発生しやすくなります。
戦略案件という名のデスマーチ
しかし、あえてリスクを理解した上、
デスマーチ覚悟で案件を受けるケースもあります。
それは「戦略案件」と呼ばれる案件を
受注する場合です。
戦略案件とは、
今まで取引のなかった企業から
何とかしてシステム開発を受注したい場合や、
その企業と取引を開始することによって、
今後も継続的な受注が見込めそうな場合に言われる名称です。
例えば全国展開する
大手量販店の人事システム改定案件があったとしましょう。
システムの老朽化により
大手量販店がシステム改定を検討しており、
できるだけ安く、早くシステムを導入してくれる企業を探しています。
営業担当が何度か足を運び
SEも技術的はサポートとして営業同行し、
競合他社も多数ある中、最終候補企業にまで残ることができました。
大手量販店から要求された
予算と開発期間は、開発に必要な費用と開発期間を
大幅に不足していました。
今後のお付き合いができるなら！
運用保守まで当社にお任せいただけるなら！
いろいろな条件交渉をしつつ、
開発期間不足や赤字を覚悟した条件で
受注してしまうケースもあるのが現状です。
ここからがデスマーチの始まり。
要員の確保、
予算や運転資金の問題、
開発期間不足にともなう不十分なテストなど...
自らリスクを
わざわざ多くしているようなものです。
プロジェクトマネージャの手腕や
開発チームのスキルなどにもよりますが、
何らかのトラブルが発生するのは目に見えています。
もちろん、うまく納品できれば
戦略案件としては成功で万々歳なのですが...
だいたい何かしらの問題が発生します。
それでも取るのが、営業です。
また経営者もこちら側でしょう。
どちらの立場もわかる身としては、、、
うーん、でもまぁ取るでしょう。
やっぱり。
しかし、
ただ突き進むのだけはNG！
常に分析・提案を意識しながら進みましょう
一回経験しておいた方が、
確実に力はつきます。
なので、まだまだ経験が浅いうちは、
とりあえず頑張りましょう。
しかし、これが恒常的になると
よくありません。
IT技術者の飲み会などでは
デスマーチの経験自慢が聞かれることが
ままあります。
「あのプロジェクトでは月400時間いった」
「ええ！？400は行き過ぎでしょう？」
「負けた！俺は300時間程度しか経験ないや」
過酷な労働状況や
難しい案件を乗り切った場合、
困難を克服した達成感に満たされ、
このような話も出るのでしょう。
しかし、
働く時間が自慢の種になっている時点で
アウトです。
また、デスマーチは
マネジメントの観点から見ると、
明らかに失敗している状態であると言えます。
もし、あなたがIT技術者になって
デスマーチを迎えてしまった時には...
・何が原因となったのか？
・被害を最小限に抑えるにはどうすれば良いのか？
・人、物、金、時間のどれがボトルネックになっているのか？
・顧客に別の提案することで、被害を少なくできないか？
・開発チーム内だけで解決できない場合は全社問題として検討できないか？
...このような現状分析や提案事項の検討を
怠らないようにしてください。
ただあふれ出る作業に対応して乗り越えるだけでなく、
次に同じような状況を出さない為にはどうすれば良いか？
常に考えながら対応することを心がけてください。
常に考え続けることにより、
トラブルの対応方法を知ること、
トラブルを未然に防ぐ方法を知ること、
それこそが、何百時間働いたという充実感に勝るあなたの力になります。
あなたは今だけの技術者ではありません。
今後も技術者として活躍してゆく未来があるのです。
楽しく働いてゆきましょう。
リスキルテクノロジー
松田
PS
繰り返し言いますが
IT業界にデスマーチが多い訳ではありません。
近年では、
むしろ残業させないような、
休日出勤させないような仕組み作りに注力している企業が多いのです。
時代は変わって行きますね。
