ほんのりと検証っぽいことをしてみる

元ネタはこちら

「なにもしないから一割頂戴」とか思うわけですがまぁ本音はおいといて。
ちぃと内容が楽しいので、ほんのりと突っ込みを入れてみませう。

度重なる改修によって複雑に入り組んだ記録原本データベース（DB）の一元化

リファクタは「大切」ですが、難易度としてはウルトラC級ですねぇ。

検索や格納などの基盤機能と法改正の影響を受けやすい業務機能を分離し、保守性を高めるという野心的な目標

ンなもん「当然」だとは思うのですが、それを「野心的」って時点でいろいろと以下略。

一方で、全ての情報をXMLで管理するなど技術的難度が高く、十分な性能を出せないなどのリスクを抱えていた。

XMLってどちらかというと「最悪、に近いレベルでの悪印象」しかないんですが、ど〜なんでしょうねぇ実際。
「どんなもんでも書ける」からって「味噌も糞も区別なく盛り込む」ので、全体として「ものすごい糞の山」になりやすいような気がするのですが。

システムアーキテクチャーに詳しい情報システム部門のある職員（以下A職員）と、刷新の「可能性調査」を担ったIBMビジネスコンサルティングサービス（現・日本IBM）を中心に、調達仕様書を作成した。
-中略-
さらに仕様書の骨格が固まった2005年7月、A職員は異動となりプロジェクトを離れた。

まぁ「属人性バリバリ」ってのもコケるプロジェクトの一員ですねぇ。
「属人性バリバリ」ってつまり「管理がまるで出来ていない」ことへの暗示なので。

政府の調達指針では、大規模プロジェクトについては分割発注を原則にしていたため、システムの基本設計から詳細設計までと、業務アプリケーション開発以降の工程を分離した。

発注の分離はいいんだけどさぁだれが天沼矛持ちになるんざましょ？( http://d.hatena.ne.jp/gallu/20090111/p2 )

技術点では最低だったが、入札価格は予定価格の6割以下の99億2500万円。これが決め手となった。

これひとつでもう「おなかいっぱい」なくらいの死亡フラグ(苦笑
金子の高で見ている時点で終了確定ざます。

「現行業務の延長でシステムを開発してほしい」。
　業務プロセス改革（BPR）を前提にシステムを刷新するのではなく、現行システムに機能を追加する形でシステムを開発しようというわけだ。

「ジェンガ」って単語をしっているとこの選択肢はしないｗ

東芝ソリューションは現行の業務フローを文書化するため、2007年5月までに450人体制に増強した。だが、現行業務の把握に手間取り、作業が遅延した。

とりあえず「人月の神話」の朗読会をお勧めします B-p

東芝ソリューションは遅れを取り戻すため、2008年には1100〜1300人体制にまで増員した。人材派遣会社や協力会社を通じて、大量の人材を集めたという。これが、さらなる混乱をもたらした。

同上。
そも「人数を増やす」と増えるのは「失敗する確率」です。そこを肝に銘じなければいけません。

「東芝ソリューションには、協力会社を含め多数の開発要員を統率する経験がなかった」（関係者）。

いろいろと論外。

　設計チームが入居していたビルは一気に手狭になり、机の1人当たりのスペースは「ノートPCが1台置けるくらい」（同）に縮小した。

「物理環境の悪化」は「進捗にブレーキをかける」簡単なテクニックのひとつです B-p

2011年頃には、プロジェクトはほとんど「開店休業」となっていた。要員は500人に減った。プロジェクトの破綻は明らかだった。だが「開発中止」を認定・判断するプロセスがなかった。

「監視プロセス」って大切だよねぇ、と、心のそこから感じる瞬間。

まだまだ、笑える話はいろいろと転がってるんだろうなぁ…(遠い目

がるの健忘録