第６４話　総合システム移行計画の設計：２０２３年６月

（鈴木は、総合システム移行計画の設計に着手するが、難題があった）

2023年6月。東京。T商事オフィス。

総合システムへの移行計画は、技術的ではなく。組織との折り合いのつけ方が難題だった。最終的な出口は、ダマスカスと同等以上の利便性のあるシステム構築だ。しかし、この最終兵器は提案できない。最終兵器を提案すれば、明日から来なくてよい人が多数でる。そうなると、社内で支持を得られない。だから、現在より少しマシなステップ１のシステムを作る。そして、退職などで、人が減ったら、生首を順次システムに置き換える。これが、進んだら、次のステップ２のシステムに移行する。こうして、階段を一段ずつ上って行けば、最終兵器に到達出来る。もちろん、その間に、ダマスカスは更に進化して、差が大きくなる。そうして、会社がつぶれそうになった時には、生首を気にせずにシステム化の階段を駆け上るだろう。しかし、今、これは、できない。要点は、最終兵器は、頭の中にだけおいて、それを持っているそぶりをしないこと、改革を小出しにすることだ。

現在の幹部も、解雇を含めた組織改革の必要性はわかっている。解雇条件を雇用時に明示しなければ、不当な解雇か、そうでないかは分からない。だから、日本では、会社がつぶれそうにならない限り、解雇すると裁判に負ける。年功型雇用を採用している企業では、解雇は難しい。年功型雇用では、企業が沈没する寸前まで、解雇できない。そこまで、業績が悪化すると、企業の再生は難しい。とはいえ、ジョブ型雇用で、解雇に対する裁判をうけて立っているHAL社でも、裁判に勝てないのだから、解雇はご法度である。

問題は、ステップ１の設定である。汽車の連結器では、古い連結器で運行しながら、各車両に、新しい連結器を配置して、人海戦術で、瞬時に置き換えた。レガシー・システムは、古い連結器に、クラウド・システムは、新しい連結器に相当する。銀行の自動支払機でイメージすれば、古い支払機が並んだ壁と反対側に、新しい支払機を並べて、使用する支払機の列を入れ替える。

このイメージでは、クラウド・システムのインターフェースは、レガシー・システムに合わせる。しかし、クラウド・システムのインターフェースは、新しい世界統一方式にしたい。自動支払機のユーザーは一般の人である。そうすると、１日でインターフェースを変えられない。つまり、新旧のインターフェースの共存が前提になる。

一方、通信システムの２重化は、維持管理費用が増大するので、避けたい。
これから、１種類の新しい通信システムの上に、新旧の２種類のインターフェースを実装するシステム仕様になる。簡単にいえば、新しい支払機には、新しいインターフェースが実装されているだけでなく、古い支払機のインターフェースのエミュレーションモードも実装される。これで、顧客は、今まで通りの、古いインターフェースも選択できる。

自動支払機の場合には、古いインターフェースの使う顧客もお客様なので、コストがかかっても、配慮して、ユーザー離れを止める。一方、社内のシステム化では、古いユーザーインターフェースに対するエミュレータには、問題がある。

具体例を示そう。
ファックスで、データ送信している場合を考える。
原稿は、ワープロで作っているので、クラウドのファイル共有サービスを使っていれば、ファクスは不要である。クラウド以前でも、Eメールでも対応できる。これを、「ワープロ＝＞紙に印刷＝＞ファックスで送信」している。フックスの代わりに、Googleレンズでも送信できる。ここで、エミュレータと言っているのは、Googleレンズを立ち上げるとファックスの機械のアイコンが表示され、現在、ファックスであれば、この段階の操作をしていますと表示される機能である。確かに、この機能をつければ、今までと同じ感覚で仕事ができる。しかし、これでは、全く合理化にならない。しかし、この機能をつければ、ファックスの機械を廃棄してもらえる点だけは、前進かもしれない。

結局、ステップ１では、クラウドのファイル共有サービスとファックスのエミュレーションを機能を併設するようなシステム化を進めることにした。