前回はそもそもの組織論やベクトルの視点での話となったが、せっかくなのでもう少し実態に目を向けた見方をしてみよう。
（その１はこちら
ネット情報では、
・巨大な化け物のようで誰も全体を掌握できてない
・旧行の各ベンダーが据え置かれたので話がややこしくなってる
など言われており、前者はむしろ調査報告で指摘されて明るみになるポイントだと思うが、後者は確かに日本のIT界では多くの人が直接的または間接的にお世話になった企業が名を揃えるような形になっている。
もしも要点が前者である場合は、そもそも誰も全体掌握できてないのにシステム刷新をしてしまったということになるので、確かにこれでは「ベクトル」以前の話であって、むしろ分かりやすい結論であろう。
（敢えて言えば、これだけのシステム刷新をするには成熟した組織・チームと、それをまとめ上げる力量を持った正に人たらしたるPMかつ経営陣とも100%ベクトルが揃ったPMが必要だったが、それよりも先に必要に迫られ、組織と人材の確認をする間もなく動き出さざるをえなかった、と言ったところだろうか？）
前回、システム刷新については極論すると「設計書は無いものと思え」と書いたが、例え設計書がすべて完璧に揃っていたとしても、その事を忘れると痛い目を見るのである。（その教訓を学ぶのに4,000億円はあまりに高すぎるが。また「システム刷新は慎重に行うべき」とさらっと書いてしまうと、その重みもなかなか伝わらないが、こういう事例を目の当たりにしてこの言葉の意味が再認識されるのだろうな。）
また、プログラムソースコードの言語の切り替え（乗せ替え）も軽く考えられがちである。特にシステムに詳しく無い経営陣には「プログラムなのだから機械的に１対１で新しい言語に変換すれば良いだろう」とか考えられたり、逆に開発陣が安易にそういった説明をしたりして、プロジェクトが走ってしまい実際蓋を開けてみると一筋縄ではいかず、結局昔のソースを追って手動で新しいソースを書き起こす羽目になり、当初予定をはるかにオーバーしたりする。
しかもCOBOLなど古い言語だと、現在の言語では整備されたライブラリがあったり１行で書けたりする処理であっても、古い言語は昔ながらの書き方しかできないのでせっかく新しい言語にしても回りくどい書き方で書かざるをえず、無駄だらけのソースになったりする。
また、業務的にも古いやり方やデッドコードが残っていて、ちゃんと業務視線で見直せば削ったりスッキリ書き直せる箇所も、意味もなく１対１で新しいソースに整形しなければならない。
更に言うと、１対１変換の方針とは旧システムをブラックボックスとみなして、それをそっくりそのまま新しいブラックボックスに乗せ替えるようなものであり、いざある程度うまく１対１変換できたとしても、試験の段階で何かバグがあると結局旧システムのソースを当たらなければならなくなるのである。どれだけ１対１変換がうまくいったか次第ではあるが、例えば見直し箇所が全体の5割りとかになってしまうと、最初から全体を見直してた方が良かったと「悟る」だろう。（そしてその時点で悟ってもかなり手遅れということにも気づく。）
そこまで行くと「安易に１対１変換方針にせずに、肝を据えて要件定義からやってた方が良かった」と後悔することになる。先ほどの例で言うと試験時点で実質要件定義の見直しをする羽目になってるにも関わらず、１対１変換方針であるから「改善」も許されず意味の無い（とまで言わないまでもかなり無駄な）ソースを作り続けなければいけないのである。これほど後ろ向きな作業も無いわけで、１対１変換という機械的作業を人がやってるような作業になってしまう。
そして最後は必ず試験を実施するのだが、例え１対１変換で旧ブラックボックスから新ブラックボックスに乗せ替えられたとしても、結局は試験の段階で、そのブラックボックスの中身に関わる所を見ていかなければならないのである。
システムがものすごく単純であれば、INとOUTだけチェックすれば良いだろうが、複雑なシステムだと様々なパターンや、システム全体を通しての試験をする必要があり、そういった試験をこなす時に技術者は「ここはブラックボックスなので動きは分かりません」とは言えるわけが無いのである。
つまり試験段階で最上位レベルの要件やシステムの「意味」まで把握する作業は当然である訳で、それを当然知っているのであれば、どちらの方式で対応するか判断するときの重要な要素になるだろう。
試験段階でどっちみち現在把握しきれてないシステムのソースレベルの意味まで調べることになるので、それならば要件定義・基本設計から業務を洗いなおして、古臭いやり方をしてる箇所でまとめられる箇所はまとめ、デッドコードも削ってすっきりと作り直した方が良いと判断するか。
または、試験段階でどっちみち現在把握しきれてないシステムのソースレベルの意味まで調べることになるが、工数削減のためあくまで１対１変換でいくと判断するか、である。
この工数というのも、ベテランPMであれば分かると思うが、隠れパラメータとして「どれくらい幅があるか」というポイントがあり、ある種取り扱いが危険な数値だと知っているだろう。
先ほどの例だと、前者は要件定義・設計・製造と大きな見積もりとなるが、幅としては「それほどぶれないだろう」と分かる。
後者だと、確かに設計・製造は小さい見積もりが出てくるだろうが、幅としての不確実性はものすごく大きい。（と、少なくとも嗅ぎ分けられるPMや、経営者側の人間がいなければならない。）
これまで説明した通り、蓋を開けるとうまく行かず、見直し箇所の方が大きい割合を占めると、当初見積もりの何倍にもなって、下手すると素直に前者でやってた方が安上がりだったという、目も当てられない結果になる。（おまけに作業は「こっちの穴を塞げば、あっちから水が出る」とう、凄まじく後ろ向きな作業となる。「士気」とかに直接結びつける気は無いが、前回書いた「ベクトル」という意味でいくと、果たしてこんなことになったとしたら、現場の一人一人は果たしてこのシステム刷新に対する熱量やベクトルを保ったまま作業できていたのだろうか？と思う。また、そこまで行くと「負の逆伝搬」が発生する。つまり現場が燃え上がると、それこそ「見栄」とか「ばれたら怒られる」という、「何とか抑え込もう」という非健全な力が発生するのである。小さなプロジェクトならもちろん押さえこめるのだが、今回のような超大規模プロジェクト、超多段階層となると、上層に行けば行くほど「もう手遅れ」になって、さらなる「蓋に蓋をする」事態になってしまうのである。（さすがにこれも基本事項としてPM教科書に書いてそうだが。）特にこういう時に「言われた通りやっており、その点は言われてないので当然やってません」という言い訳を準備しがちである。）
