特許庁のデスマーチに対する駄文
http://fumit.blogspot.com/2012/01/55.html
http://blogos.com/article/30357/
これはヒドイ.
もちろんブログの方がね.*1
SOLは平成18年に60人体制で設計を開始したが、翌年初めには遅延が始まったため、順次増員。平成19年3月には200人、5月には450人体制に膨れ上がる。増員しても作業効率の向上には繋がらなかったのだが、TSOLは更に大幅な人員の増強で工程の遅れに対処しようとし、平成20年11月以降には1,300人もの体制を整えたが、このような急激な増員は、かえって設計指示の不徹底や実施手順の不統一を招き、設計成果物の 「品質の不均一」 が生じることとなった。こうして混乱が続き、
このブログの主は,これを「尋常ならざる事態」と思って引用したのかもしれんけど,初期開発メンバーの10〜20倍規模なら,ごく普通のデスマーチだよね.酷い事は酷いけど,よくある事でもあるのでコの業界の人間ならそんなに驚かないレベルだと思う.*2 *3
それと中途半端な人員追加が混乱を招くのも,むしろ事態を悪化させるだけなのも常識.だけどお役所仕事だと,人員追加くらいしか対策がないものなんだろう.追加するエライ人はともかく,される方だってされたくて追加されてるわけじゃない.
人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)
- 作者: フレデリック・P,Jr.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子
- 出版社/メーカー: アジソンウェスレイパブリッシャーズジャパン
- 発売日: 1996/02/01
- メディア: 単行本
- 購入: 4人 クリック: 126回
- この商品を含むブログ (49件) を見る
。。。と言っているうちに、次々と不祥事が発覚していった。
(中略)
つまり、特許庁の職員が色々リークしたおかげで受注できた会社が、設計を開始したが実力不足のために遅延と増員(設計段階で60人体制から1,300人体制まで膨れ上がり)でぐちゃぐちゃになり、不祥事も次々発覚して、使った55億円を「水の泡」にして開発を中断した、という経緯が「開発の遅れは、主に設計の不備が原因」という一言でまとめられてしまったってこと?
たぶんハズレ.
少なくとも「つまり」の部分で論理が飛躍しすぎていて,因果関係が何も示されてない.あなたの単なる憶測,或いは願望を書き綴ってるだけ.0点.
汚職は悪い事だろうけど,それとプロジェクトの成否との関係は不明だよ.犯人捜しをしたい気持ちは理解できなくもないが,犯人なんていなくても,そのくらいのデスマーチは日常的に起こってる.
- 作者: 日経コンピュータ
- 出版社/メーカー: 日経BP社
- 発売日: 2011/07/28
- メディア: 単行本
- 購入: 2人 クリック: 466回
- この商品を含むブログ (18件) を見る
この人は携帯電話の軍曹さんの話も聞いた事ないのかもな.
実話かどうかは知らないけれど,IT業界ならこのくらいはあっても不思議じゃない.
http://b.hatena.ne.jp/entry/fumit.blogspot.com/2012/01/55.html
- id:NOGjp 直感的に思うのは、最大1300人7年で55億って安すぎねぇか?
軍曹さんの一件のように,赤字垂れ流しでボーナスも人月単価もカットされていったのだろうか.
便宜上「設計工程」と呼ばれてるだけで,ようするに要件定義や御用聞きの比率が高いよね.*4
特許庁の偉い人が「何をどうする」って鶴の一声で決めれば一日で終わる事を,あっちの部署では「あーでもないこーでもない,やっぱそれはこーしてくれ.」といい,こっちの部署では「いや今のは待った.やっぱしあーする.」と言い,さらにはエライ人に確認したら「先月のアレだけどやっぱし無し.むしろこうしてくれ」とエライ人奥義ちゃぶ台返し.
こんなのを毎日やってれば,1300人いても1万人いても完成しないだろう.一歩進んで二歩下がる.
「その会社は老舗の小売店でした.十年ほど前に業務システムを入れ替え,以来その時のリプレース業者が継続してシステムを見ているという話でした.我々の仕事は肥大化する一方の情報システム予算を削減する事.そのために現状調査含め現場に入ったのですがーー」
- 作者: 夏海公司,Ixy
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2011/01/06
- メディア: 文庫
- 購入: 17人 クリック: 786回
- この商品を含むブログ (95件) を見る
「ひどいものでした.各システムの中身は完全ブラックボックス.ユーザーに開示されているドキュメントは何一つ無く運用要員の数も非公開*5.挙げ句に月額費用はアウトソーシング一式×千万と丸められている有様です.資料公開を求めても業者は『サービス設備』だからと拒否する始末,運用要員も同じく『シェアード窓口』と言って誤魔化される有様でした.」
「顧客内部にシステムの内情を知ってる人間はいません.インフラの規模,月刊の運用稼働,現状の構成,全てがブラックボックスです.そんな状態でどこのベンダーがリプレース提案をかけられるんですか.最適構成を見積もれるんですか.」
私達はーー
「最善を尽くしました.現地サーベイを行い,ヒアリングを実施し,過去の資料を漁り,必死になってシステムの全貌を明らかにしようとしました.ですが……無駄でした.内情を知る既存ベンダーの協力なしに現状調査を行う事は不可能だったんです.」
「私達は……負けました」
たぶん今回はこのパターンだと思う.ラノベのネタにされるくらいの典型的な定番の失敗パターンの一つで,情報システムを軽視するお役所や日本企業ではとても良くある話.
特許庁の情報システムについて
http://myatsumoto.hatenablog.com/entry/2012/01/26/082554
http://myatsumoto.hatenablog.com/entry/2012/01/26/082554
http://www.jpo.go.jp/cgi/link.cgi?url=/shiryou/toushin/kenkyukai/jyouhou_iinkai.htm
ついでにメモ.
業務流れ図 - http://www.jpo.go.jp/torikumi/system/pdf/system_optimize_re/shourai_1_3.pdf
あーもー,なんか失敗原因がすごく理解できた気がする.なるほど.orz
*1:話としては一応こっちの続きになるのかな.http://d.hatena.ne.jp/JavaBlack/20120124/p2
*2:「路面が凍結していて十数台の車が玉突き衝突」みたいな.1〜2台の事故に比べれば大事故だけど,毎年のように発生しているレベルの「良くある大事故」でしかない.例のフェラーリ等14台が大破した「世界で最も高額な自動車事故」くらいになれば,また別なんだろうけどね.
*3:そもそも大手SIerの唯一の強みは技術力でもマネジメントでもコミュニケーション能力でもなくて,イザとなれば100人でも千人でも奴隷を集めることができるという部分だから,これこそがSIerの本領発揮と言えなくもない.技術力なら陵駕できても,これだけは中小企業には真似できない部分です.
*4:ソフトウエア開発における本当の設計はプログラミングそのもの.
*5:ここは必ずしも人数を公開する必要はないと思う.必ずしも「専属で何人」と決まってるとは限らないから.