デスマーチはビジネスモデルの破綻でなければ、マネージメントの失敗から産まれる

私は、デスマーチはビジネスモデルの破綻でなければ、マネージメントの失敗から産まれると思っている。

そもそも、会社の任務は何か？
最高の商品を最低の価格で売り、従業員に最高の給料を払うこと。(ヘンリー・フォード)

最高の給料を払うためには、最高の売り上げを上げる必要がある。
最高の売上を最低の労力で仕上げるにはどうすればいいか？

ここで、人件費を削ると判断した企業は、
名誉あるブラック企業として歴史に名を刻むことになるだけだし、
経費を削減しまくると指揮が低下するだろう。

人 * 時間 = 製品なんだから
人を削減しないなら、時間(工程)を最適化するしかない。
ソフトウェアだと原材料なんて無視してもいいぐらいだろうしな。

受託開発ではなく、自社内開発の場合を想定して書いてみる。
(私は受諾開発に未来はないと考えているので、受諾開発なんて頭にないw)

そもそも、ユーザ全員を幸せにすることなんてできない。
今できる最良の手を短時間につくるしかない。

開発者が手動で機能を作るわけではない場合、企画者がいるだろう。
企画者が詳細な機能要求一覧を出すときに、企画書には最低これくらいは欲しい。
・タスク名
・機能説明
・それが必要なわけ
・得られる利益(直接、間接を含めた利益/年)
・機能が未実装の場合の不利益
・優先順位

それを受け取った開発者は、それぞれに見積り時間を記入するだろう。

・タスク名
・機能説明
・それが必要なわけ
・得られる利益(直接、間接を含めた利益/年)
・優先順位
・開発見積り(new)
・見積から計算するコスト(new)

んで、企画者と開発者が話し合いどれを実装するか決めるはずだ。
見積から計算するコストと、得られる利益、予算、スケジュールから、どの機能を実装するか決まるはずだ。
これは投資によく似ていると思う。(っていうか、プロジェクトって会社から見れば投資だよね)
その後、開発者側の開発がスタートするって感じだ。

もちろん、この後に機能が変更されたらスケジュールも変更される。
スケジュールのケツが決まっているなら、どれかの機能を削減するしかない。

これって会社の不利益にならないの？
ならない。ふつー変更することによる利益が、諦める機能より大きいから変更するわけだろう？
より、会社の利益に貢献しているはずだ。

んで、ふつーにこれが廻っているなら、デスマーチになることなんてないはずだ。
高い給料をもらい、全員が定時で退社し、ゆとりのある人生を歩んでいるはずだ。
そして、最良の機能を搭載した最良の製品が世の中に出回っているはずだ。

デスマーチになるということは、この工程のどこかがおかしいわけだ。

企画者/営業側の権力が強すぎて、彼を納得させるための機能を無茶なスケジュールで作らなきゃならなかった、
開発者がデバッグやテスト工程を考えない、見積りをしてしまったり、
仕様が変更されたのにスケジュールが修正されなかったり、
来るはずだった応援メンバーが、プロジェクトに参加できなくなったのにスケジュールがそのままだったり、
ずっと大丈夫と言い張っていた人が納期をブッチした、

とか、大抵そのへんのたぐいだろう。

・企画者/営業側の権力が強すぎて、彼を納得させるための機能を無茶なスケジュールで作らなきゃならなかった

現実に合わせたスケジュールを引くべきだ。

他にも、ビジネスモデルの失敗した企業とかもこれになりやすいと思う。
これもこれもと闇雲に機能をつけすぎて、保守開発工程が恐ろしいことになってしまうだろう。

そもそも、これって、開発部門が弱い立場に置かれている企業なわけで、
そんな企業で開発をやってもなんの徳にもならないので、速攻逃げるべきだろう。

・開発者がデバッグやテスト工程を考えない、見積りをしてしまった

他人よりも早く実装することが優秀だと考えている人が多い、、、(私もそのたぐいなんだろうが、、)
これは無謀というか、若さゆえの過ちだ。
私たちは、お金をもらって動くソフトを提供するために雇われているプロなんだから、
ちゃんと、動くソフトを期日までに納品しないといけない。
そのためには、テストやデバッグ工程をちゃんと考えて見積りをしなければいけない。
それがプロの仕事だ。

工数を見積もる方法はいろんな方法論があるだろう。
そこら辺をちゃんと学ぶべきだ。

・仕様が変更されたのにスケジュールが修正されなかった

明らかにマネージメントの失敗から来る問題だ。
その開発現場は要求の整理もされていないのではないか？

・来るはずだった応援メンバーが、プロジェクトに参加できなくなったのにスケジュールがそのまま

これもマネージメントの典型的な失敗の例だと思う。
人のアサインができなければ、スケジュールは後ろにずれるのは当然だ。

それとも、「大丈夫。全員が不眠不休で3ヶ月働けば穴が埋められますよ！」とか考えているんだろうか。
なぜマネージメントの失敗の尻拭いを開発者がしてあげなきゃならないの？
(なぜ自分より多く給料をもらっている人の尻拭いを、給料の少ない人がしてあげなきゃいけないの？)

・ずっと大丈夫と言い張っていた人が納期をブッチした

今すぐそいつをクビにしろよ。。。
確認のマイルストーン不足だったのかもしれない。
ソース管理などを使って、他人の作業の進捗を見なければいけないのかもしれない。

思うんだが、テストをちゃんと描いている開発だったら、どこまでテストケースが造られたかで
完成度がわかりそうなもんだが、、、

と、ここまで見ていて、デスマーチを生む原因に技術がなかったのが興味深い。
もちろん、見たこともないような新技術を利用しなければいけなく、
当初の見積りを遥かに超える労力を要した場合もあるんだろうが、、、

ふつーのソフトウェアにおいて、
見たこともないような新技術を使わないと実装できないものって結構少なくなっていると思う。
OSコアのフック層を使わないといけないような、フックドライバーとか、そーゆー者を開発しなければいけないとか、ハードウェアべっとりな実装をしなければならないみたいな感じがなんだろうけど、、そんなの滅多にないような気がする。。。

ビジネスモデルの破綻について

ビジネスモデルの破綻というのは、薄利多売みたいに、安い賃金でたくさんひたすら作り回らないと回らないようなビジネスモデルです。
たとえば、創業間際で信頼性がまだないベンチャーが他社から案件を勝ち取るために、安い金額で、仕事を受けざる終えないみたいな。
中国やインド、ブラジルの新興国と戦うために、彼らと同じぐらいに低い給与体系で、長時間の違法残業(サービス残業)をやらざる終えないよーな環境がそれに該当すると思う。
それをやらないと、事業が回らないのだ。
こーゆー戦略を取らざる負えなくなった、ビジネスモデルは、もう破綻していると思う。

こーゆー場合でもデスマーチが発生しますが、その業界自体の先が短いような気がするので、そんなのとはかかわらないのが一番だと思う。
これって、別の付加価値を生むようにビジネスモデルにシフトしないと、いづれ焼き切れて倒れるだけだと思うんだよな。。。

ソフトウェア的なアプローチができないか

このプロジェクトは明らかにやばいというのを、作っている本人たちは分かっているんだけど、周りはフタを開けるまでわからないことがある。
隣の部門が超絶忙しいのに、それを誰も知らなかったり。

ここらへん、グループウェアやプロジェクト管理ツール、チケット管理ツールなどが機能してくれればいいんだろうが、なかなかしっくり来るものがないんだよなぁ。
一番マズイのが、それぞれの機能が独立して連動していない所だと思う。
現実の作業はチケット管理ツール、バグ管理ツールで把握されているのに、プロジェクト管理ツールで引いた線は、現実を反映しておらず、、、みたいな。
ないなら作ればいいヂャんって所なんだけど、、、