IBM i のウンチクを語ろう
～ その68：ITの分断が招く「ひとり情シスもどき」
皆さん、こんにちは。最近よく聞く言葉に「ひとり情シス」というものがあります。一人だけの情報システム部ということで、私自身もこれまでに何度かそのような立場の方向けに、IBM i の最新の製品動向を説明する機会がありました。もちろんそうだとわざわざ確認したわけではなく、やり取りの中で「どうやらこの方もいわゆる『ひとり情シス』なのだな」と感じるのですが。
メーカーであるIBMは、RPG言語を始めとするこのシステムに、今後も投資を継続する意思を明確にしています、とばかりに、ロードマップを示しながら将来性の確かさを納得いただくことが訪問時の主な狙いです。もちろんそればかりでなく、DX推進のためのシステムの新たな活用法として、多くの方が関心を寄せるようなこんな新機能、あんなソリューションも併せて紹介します。日常のシステム運用ばかりでなく今後のビジネスの成長に役立つだろう、そうすれば結果として我々の売上も拡大するだろう、と信じての説明なのですが、時として「そういった新しいことは別の部門でやっているので・・・」といったコメントを聞くことがあります。IBM i とRPGプログラムは現状のまま将来も健在であることが確認でき、それなりの資料を入手できればご自身の目的は達成なのでしょう。それはそれとして、「ひとり情シス」とはいっても、実際にITに携わっているのは全社を通じて一人だけとは限らないケースもあるようです。
旧来の情報システム部とは別の枠組みの中に、そこではしばしばDXがキーワードになっているのですが、ITを活かした新しいことに取り組む人達がいるのでしょう。IBM i 上で稼働する既存の基幹業務アプリケーションはDXとは無縁とされ、それを担当する「伝統的」情シスのスタッフは一人だけが配置されている、という構図です。だからといって基幹業務を担っているが故の重要性に変わりは無く、IBM i においてもやるべきことは目白押しです。日々の運用やアプリケーションの保守、さらには各種の法や制度改定への対応だけでなく、セキュリティ対策だとか運用の効率化も推進せねばなりません。我々ベンダーの役割の一つは、このような取り組みをお手伝いすることにあります。その一方で、「ひとり情シス」のように見えていながら実態は一人ではない、「ひとり情シスもどき」が何故生じてしまっているのか、ITの分断が招いた現象ではないのか、といった素朴な疑問に囚われたりもします。IBM i に携わっている方がDXと距離を置いているとしたら、私にとっても嬉しいことではありません。
この「モヤモヤ感」は、従来アプリケーションからの連続性を考慮せずにDX推進に取り組もうとするのは果たして意味があるのだろうか、という疑問から来るものです。刷新なのだから過去に囚われる必要は無い、という発想に一理はあるのでしょう。新しい事を始めるのにゼロベースで物を考えることは時として必要ではありますが、目の前の現実、これまでに実施してきた業務プロセスとの整合性の取り方も同時に検討するべきではないのか、と思うわけです。既存アプリケーションには、長年にわたって積み上げてきた業務ノウハウ、当の企業にとっての強みが凝縮されているはずです。テクノロジー面で評価すればただの古びた遺産に見えるのかもしれませんが、内包されているビジネス・ロジックはそれなりに評価できるのだと思います。テクノロジーとビジネス・ロジックとは別の評価軸だということです。だからこそ既存アプリケーションは長寿命でしたし、だとするならば、既存のビジネス・ロジックをDXに活かさない手は無いのではないでしょうか。
そのような状況をわかってはいても、後継者をうまく育成できなければ、そして保守してきた人が退職を迎える時期が迫ってくると、旧来のアプリケーション資産を廃棄するしかないという判断に傾きがちです。保守要員不在となる事態には耐えられないので、IBM i のような歴史の長いシステムはいずれその役割を終える時が来る、ということなのでしょうか。いずれ新たにオープン系システムを立ち上げるつもりなので、その際には既存IBM i とRPGプログラムから脱却したい、今回導入するのが最後のIBM i、と発言される方も少なからずいらっしゃいます。テクノロジーの世代交代は必然とも言えますが、例えばパッケージ導入を検討してみると、従来業務を支えられるほどの各企業独自のビジネス・ロジックが実装されていないことがほとんどです。嵩上げされたカスタマイズ量を受け入れてプロジェクトのリスクを高めるか、ビジネス・ロジックの一部を放棄するか、という選択を迫られます。結果的にIBM i からの脱却がうまくできず、あわてて延命に動くケースも少なからず見聞きします。
どうやら人的にもテクノロジーの観点においても、新旧アプリケーションの間には明確な境界線と言うよりも断絶に近いものがあって、両者は互いに別次元の代物とされるケースがある様子がうかがえます。安井の先入観に過ぎないと指摘されたらうまく反論する術を持たないのですが、DX推進が上手く行っているケースを見ると、新旧の「分断」ではなく「統合」がキーワードとして浮かび上がってくるのではないかと思うのです。
少々事例を見てみましょう。当コラム「フリーフォームRPGは本当に効果があるのか -2」の中で紹介した事例では、固定フォームILE RPGで記述された既存の基幹業務アプリケーションを保守するベテランと、フリーフォーム RPGで新しいアプリケーションを開発する若手が連携してプロジェクトを進めました。若手はC、Java、JavaScriptの経験はありますが、IBM i もRPGも携わるのは初めてです。今更古いテクノロジーの固定フォームILE RPGアプリケーションを開発したくなかった一方で、それまでに蓄積してきた旧来のプログラム資産量が30,000本以上もあって、全面的に刷新するのはそもそも不可能でもありました。結果的に新旧アプリケーションを連携させようという結論に落ち着き、それぞれを担当する世代の異なる人材を巻き込んだ共同作業を行ことになりました。
もう一件、オープンなテクノロジーを活用した日本サニパック様の事例を見てみましょう。LINEをユーザー・インターフェースとして採用し、LINE上のチャットを管理するために、「KUZEN」というクラウドサービスとして提供されるAIチャットボット・システムを採用しています。基幹業務側は、企業間の決済をスムーズに行うために「クロネコ掛け払い」というBtoB決済クラウドサービスを採用、そしてバックエンドの販売管理アプリケーションとしてIBM i 上の既存RPGプログラム、が主な構成要素です。これら全体をスムーズに連携させるために、Python で新たに開発したAPIをIBMクラウド上に展開しています。
上記二件の事例に共通しているのは、ビジネス変革を支えるシステムを構築するにあたって、新旧テクノロジーを上手く組み合わせていることだと言えます。新しいテクノロジーにはフリーフォームRPGもありますし、外部のクラウドサービスもあります。テクノロジー世代が古いからといって単純に排除するのではなく、必要と判断すれば既存のレガシーなアプリケーションも構成要素の一つとして取り入れています。そして世代の異なる人材が共同して取り組むDXプロジェクトの方が、より地に足のついたものになるのではないでしょうか。
IBMのホワイトペーパーの中で述べられているとおり、IBM i を活かして新旧テクノロジーを統合するのは、製品戦略の一つとして明確に位置付けられています。そして昨今充実しつつある様々なクラウドサービスを活用するには、連携のためのテクノロジー、すなわちAPIがキーになってきます。上記事例ではお客様環境向けに最適化されたものを開発しましたが、他にも開発環境を備えていたり、多岐に渡る接続性を備えていたりする、IBM i を活かせる多様なAPIパッケージ製品があります。DXを検討される際には、是非「統合」とか「連携」を一つのキーワードとして念頭に置かれてはいかがでしょうか。ベル・データでも個別開発やパッケージ導入など、最近APIの実績が増えてきています。
ではまた。
