0001ノチラ ★2017/10/30(月) 05:08:57.96ID:CAP_USER
「バルス」。スタジオジブリ制作のアニメーション映画『天空の城ラピュタ』のラスト近くで、主人公たちがその言葉を唱えると城が崩壊し……。宮崎アニメのファンならずともあまりに有名なシーンだが、実は現実の世界にも“滅びの呪文”がある。「ゲンコウドオリ」だ。システム刷新プロジェクトの際にIT部門がこの呪文を唱えると、開発プロジェクトは崩壊するが、実は滅びはそれだけにとどまらない。
「ゲンコウドオリ」は本当に強力な呪文だ。客のIT部門が唱えてITベンダーが受け入れることで、この滅びの呪文は効力を発揮する。大規模なシステム刷新の場合だと、プロジェクトは壮絶なデスマーチとなり、何人もの技術者が心身を病んで途中で倒れたりする。挙句、プロジェクトはまさにラピュタの城のごとく空中分解する。ITベンダーと客の信頼関係も木っ端微塵になり、訴訟沙汰に一直線という滅びの道をたどる。
誠に恐ろしい。多額のカネや技術者の膨大な労力、そしてプロジェクトに費やした時間などの全てがムダになる。だから昔からITベンダーだけでなく、力のあるIT部門の技術者たちは滅びの呪文、つまり「現行通り」は絶対にダメだと言い続けてきた。だが今でも、システム刷新の際に「現行のシステムと全く同じ機能を新システムでも実装してくれ」と要求するIT部門が後を絶たない。
ITproの読者には「なぜ、それがいけないの？」と疑問を感じる人はいないと思うが、客は逆に「現行通りで当然」と思っている。利用部門としては、システム刷新なんて知ったことじゃない。日常の業務で使っていた便利な機能が新しいシステムで使えればそれでよいし、使えることが絶対条件だ。それに技術に詳しくない利用部門にすれば「今のシステムと同じものを作るのは難しくないはずだ」とも思うだろう。
問題なのは、利用部門から「現行通りでお願い」と要求されたIT部門までが、その危険性を顧みることもなく、ITベンダーに現行通りでシステム刷新するのを要求してしまうことだ。そしてなぜかITベンダーも受け入れる。その結果、滅びの呪文が効力を発揮する。どうして、そんなことになるのか。そして「ゲンコウドオリ」の本当の恐怖について、いつもの暴論調で順を追って説明しよう。
現行通りのシステムをゼロから作る
まずは、なぜ現行通りが危ないかをおさらいする。問題になるのは基幹系システムの刷新。新しいシステムでも「現行通り」でよいとする企業は、システム刷新で業務改革に取り組むといった発想が無いから、現行のシステムを10年、20年と長く使い続けてきた。しかも、IT部門が利用部門の要求のままにプログラムを改修してきたから、利用部門からすると基幹系システムは現場の仕事を楽にする便利ツールそのものだ。
ただ、長年改修を続けた基幹系システムの中身はグチャグチャ。「田舎の温泉宿」に例えられるツギハギだらけのシステムとなり、コードもスパゲティ状態となっている。開発してから長い年月を経ているため、IT部門には開発当時を知る人は誰もいない。下手をすると仕様書など当時の開発ドキュメントは散逸し、残っていたとしても場当たり的な改修の連続で、もはや用をなさなかったりする。
つまり、刷新するシステムは複雑怪奇なシロモノだ。IT部門のリストラで、プログラムを改修してきた保守運用担当者もわずかしかいないとなると、システムの大部分がブラックボックス化してしまっている。それを「現行通り」に刷新するのだから恐ろしい。もちろん、移行ツールを使ってシステムをブラックボックスのまま移行する手があり、それならば滅びの呪文が効力を発揮しない可能性もある。
IT部門が本来ならやらなくてもよいシステム刷新に取り組むのは、ハードウエアやOSの老朽化だけが理由ではない。現行システムがグチャグチャで半ばブラックボックス化しているとはいえ、利用部門が機能追加の要求を控えてくれるわけではなく、利用部門からの「高い」「遅い」「出来が悪い」といった不満を解消させようとする理由もある。とは言え経営者は“何一つ変わらない”システム刷新に多額のIT投資をすんなりとは認めない。
で、新システムでは現行の機能をそのまま引き継ぐだけでなく、利用部門が以前から要求していた新機能も追加しようといった話になる。新機能を追加しなくても、システムの田舎の温泉宿状態、コードのスパゲティ状態を解消して、今後の改修を容易にすべしと考える。そうなると「現行通り」のシステムをゼロから作り直すに限る……。これで滅びの呪文「ゲンコウドオリ」が効力を発揮することになる。
以下ソース
http://itpro.nikkeibp.co.jp/atcl/column/14/463805/102600162/
「ゲンコウドオリ」は本当に強力な呪文だ。客のIT部門が唱えてITベンダーが受け入れることで、この滅びの呪文は効力を発揮する。大規模なシステム刷新の場合だと、プロジェクトは壮絶なデスマーチとなり、何人もの技術者が心身を病んで途中で倒れたりする。挙句、プロジェクトはまさにラピュタの城のごとく空中分解する。ITベンダーと客の信頼関係も木っ端微塵になり、訴訟沙汰に一直線という滅びの道をたどる。
誠に恐ろしい。多額のカネや技術者の膨大な労力、そしてプロジェクトに費やした時間などの全てがムダになる。だから昔からITベンダーだけでなく、力のあるIT部門の技術者たちは滅びの呪文、つまり「現行通り」は絶対にダメだと言い続けてきた。だが今でも、システム刷新の際に「現行のシステムと全く同じ機能を新システムでも実装してくれ」と要求するIT部門が後を絶たない。
ITproの読者には「なぜ、それがいけないの？」と疑問を感じる人はいないと思うが、客は逆に「現行通りで当然」と思っている。利用部門としては、システム刷新なんて知ったことじゃない。日常の業務で使っていた便利な機能が新しいシステムで使えればそれでよいし、使えることが絶対条件だ。それに技術に詳しくない利用部門にすれば「今のシステムと同じものを作るのは難しくないはずだ」とも思うだろう。
問題なのは、利用部門から「現行通りでお願い」と要求されたIT部門までが、その危険性を顧みることもなく、ITベンダーに現行通りでシステム刷新するのを要求してしまうことだ。そしてなぜかITベンダーも受け入れる。その結果、滅びの呪文が効力を発揮する。どうして、そんなことになるのか。そして「ゲンコウドオリ」の本当の恐怖について、いつもの暴論調で順を追って説明しよう。
現行通りのシステムをゼロから作る
まずは、なぜ現行通りが危ないかをおさらいする。問題になるのは基幹系システムの刷新。新しいシステムでも「現行通り」でよいとする企業は、システム刷新で業務改革に取り組むといった発想が無いから、現行のシステムを10年、20年と長く使い続けてきた。しかも、IT部門が利用部門の要求のままにプログラムを改修してきたから、利用部門からすると基幹系システムは現場の仕事を楽にする便利ツールそのものだ。
ただ、長年改修を続けた基幹系システムの中身はグチャグチャ。「田舎の温泉宿」に例えられるツギハギだらけのシステムとなり、コードもスパゲティ状態となっている。開発してから長い年月を経ているため、IT部門には開発当時を知る人は誰もいない。下手をすると仕様書など当時の開発ドキュメントは散逸し、残っていたとしても場当たり的な改修の連続で、もはや用をなさなかったりする。
つまり、刷新するシステムは複雑怪奇なシロモノだ。IT部門のリストラで、プログラムを改修してきた保守運用担当者もわずかしかいないとなると、システムの大部分がブラックボックス化してしまっている。それを「現行通り」に刷新するのだから恐ろしい。もちろん、移行ツールを使ってシステムをブラックボックスのまま移行する手があり、それならば滅びの呪文が効力を発揮しない可能性もある。
IT部門が本来ならやらなくてもよいシステム刷新に取り組むのは、ハードウエアやOSの老朽化だけが理由ではない。現行システムがグチャグチャで半ばブラックボックス化しているとはいえ、利用部門が機能追加の要求を控えてくれるわけではなく、利用部門からの「高い」「遅い」「出来が悪い」といった不満を解消させようとする理由もある。とは言え経営者は“何一つ変わらない”システム刷新に多額のIT投資をすんなりとは認めない。
で、新システムでは現行の機能をそのまま引き継ぐだけでなく、利用部門が以前から要求していた新機能も追加しようといった話になる。新機能を追加しなくても、システムの田舎の温泉宿状態、コードのスパゲティ状態を解消して、今後の改修を容易にすべしと考える。そうなると「現行通り」のシステムをゼロから作り直すに限る……。これで滅びの呪文「ゲンコウドオリ」が効力を発揮することになる。
以下ソース
http://itpro.nikkeibp.co.jp/atcl/column/14/463805/102600162/