こんにちは。IT忍者です。 ITエンジニアとしていろんな案件に関わると思いますが、最近はデスマーチなる言葉が飛び交ってないですが、日々戦っているITエンジニアの人がいるかと思います。更に近年メテオフォール開発スタイルが台頭しているとも聞きます。 私の今の仕事も、実はメテオフォール開発ぽいですからね。ｗ ちょっとしたIT開発あるあるの雑記読み物系です。
メテオフォール型開発スタイルは昔からあった？
メテオフォール開発の詳細は、下記EIKI`さんのブログ記事で、 端的でかつ非常にわかりやすく、素晴らしい適切な表現がされており、内容そのものが神レベルです。是非一読頂きたい！（※外部リンクになります）
本題ですが、 今まで経験したことがなかったのですが。昔からあったかというと私の経験にはなかったですが、 冷静に見ると 一部の開発現場では、昔からあったのかもしれないですね。
デスマーチプロジェクトは確かにあった！
一方で、ふと振りかえるとデスマーチプロジェクトは確かにありました。その要因も比較的分析しやすいのですが、下記の複数条件が多ければ多いほどデスマーチプロジェクト率が高くなり当てはまる気がします。
・開発に無知な営業が、受注実績欲しさに提案した不可能な工期と金額
・開発工数で使われる雑な人月計算
・チーム全体の技術力不足
・マイルストーン無視の過度な仕様変更
・開発システムの業態/目的に合わない開発スタイルの推進
・物理的に不可能なのに、気合と根性論を持ち出す
・顧客にNOを言えない
・要件が定まらない
・リクエストのトレードオフを説明をできない
・土日/残業を最初から標準プロジェクトの工数として見ている
・チームリーダー陣やプロジェクトマネージャーが毎日定時ダッシュ
・本当はTASKが完了していないの、80％、90％で「完成しました」を鵜呑みにする
などなど
特に危険な体制の例
人月計算で1人辺りXXX万とかで金額を見積って、外部チームを作成すると、「IT土方」の流れに知らないところで進んでいるとかありますよね。
頭数だけそろえればいいとか、考えてしまう人もいるのですが、100人のレベル1の戦士タイプコーダーがいるより、キチンと考えらることが出来て攻撃魔法と回復魔法両方使えるレベル50の魔法剣士やナイトが、10人いる方が、遥に戦力になるわけですよ。 何かあっても小回りも効きますし。
みんな大好きウォータフォール開発
ですので、いくつもの負の要素が溜まって来てスケジュール、マイルストーンの意味を持たないとなり、開始時間？昼休み？帰宅時間？休日？なんだそれとなり、もう納期まで日数ないから、納品すれば終わる的な幻想にさいまれて、強制勤務からの進捗を追いかけると。。いつ爆発するかわからない時限爆弾が埋まってるみたいな。納期直前で爆発。 唯一責任を被る人を、筆頭に指示が飛びデスマーチが始まると。 さらに、みんな大好きウォーターフォール開発ですから、致命的な要件漏れとか、無理な仕様変更で矛盾が起きてるとか、後で気が付きもう戻れない♪※アジャイル開発：スクラムやFDDとかで進んでても、同じになる気がします。
メテオフォール型開発は性質がデスマと違う
デスマのような分析結果の要因分析が当てはまらない新手の開発手法ですねー。分析不可の要素は非常に多い。
さらに冷静に分析すると内的要因の方が多い？
特にメテオフォール何起きやすい環境としては、経営判断が非常に早く舵を柔軟に切れる企業さんでかつ、中間層が、今方向転換するとヤバイ事に、気がついていてわかっているのに、自分自身の考察を強制停止させて、上からの命令だと言い換えて、開発内容を強引に変更していくと起こりやすいのかもしれませんね。
そりゃ普通のサラリーマンには難しいよね
判断と決断が早い経営層は、切れ者の方が多いですから、普通のサラリーマン生活が長ければ、長いほど異議を唱えないですよね。だっていい顔してるほうが自分が社内の立ち位置悪くしないですもん♪逆に顧客だろうが、社長だろうが、取締役だろうが、役職に関係なくキチンと顧客/会社のための、メリットデメリット＆トレードオフを説明して納得させられる事ができる人。そんな中間層の人がいたら次期幹部候補へ据えたほうが良いと個人的には思います。
別な神も・・
あえて、ある程度と防げるかも と言ってもおきます。株主や企業オーナーという別な神もいるので。すべてを根本から壊すメテオの破壊力は強烈です。
メテオフォール型開発への防衛策極論
極論、内的要因が大きければ、発生の元を断つで、自分が他の神に負けない神になればいいでは？と考えます。まぁそんな簡単ではないと思いますが、それが一番のメテオを防ぐ手段かもしれませんよね♪
