IBM i のウンチクを語ろう
～ その58：DXレポート2を読んでみた -2
皆さん、こんにちは。今回はIBM i のユーザーがDX推進のために心掛けるべき事を考えてみようと思います。前回紹介しましたとおり、平成30年（2018年）9月に「DXレポート」（以下本編）、その続編として昨年末に「DXレポート2」が経済産業省から公開されています。背景にあるのは危機感です。本編レポートは世間でも大分話題になったにも関わらず、90%以上の企業ではDXに未着手であり、全社的な問題意識も欠如していると続編は指摘します。そこでDX推進の本質はレガシーな企業文化からの脱却にある事を再認識した上で、デジタルプラットフォームを整備するべき事と、そのために踏むべき手順を示しています。当然の事ながら、経産省が何か特定の製品や機能を想定するわけではありませんので、このコラムではIBM i を意識しながら一歩踏み込んで考えてみようというわけです。
いきなり話が脇に逸れてしまい恐縮ですが、お役所文書の年号表記って何とかならないものかと思ってしまいます。本編表紙にある「平成30年」を見て、「今年は令和3年だから、何年前だったっけ・・・？」と一瞬思考が中断します。和暦表記を廃して全面的に西暦に置換えるべきとまでは言いませんが、せめてカッコ書きで良いので併記してもらえるとありがたいと思うのは私だけでしょうか。仕方ないので3つの数字、昭和は25、平成は88、令和は18、を西暦への変換用に憶えることにしています。例えば前回の東京オリンピックが開催された昭和39年は、39+25=64だから西暦1964年だった、という具合です。閑話休題。
前回コラムの復習になりますが、ITとしてやるべき事はデジタルプラットフォームの整備でした。まずは自社業務の強みとの関係性強弱の観点から、既存アプリケーションを二つに識別します。関係の薄い協調領域については自前主義をやめてコストを浮かせ、その分を関係の強い競争領域にまわして社内にアジャイルな開発体制を整備する、というのが方針です。
まずはプログラム言語から考えてみましょう。IBM i ユーザーのほとんどはRPG言語で記述されたアプリケーションを利用しています。そしてIBM i を取巻く各種テクノロジーの中で、最も多くの方が将来に対して不安を抱いているのもおそらくRPGについてです。実際にはRPGもIBM i と同様に技術革新を続けているのですが、開発当時のまま何も手を加えないプログラムがあるとしたら、それだけがタイムカプセルに入った状態にあるようなものです。タイムカプセルの中身だけを見て時代遅れと評価するのはナンセンスですよね。
ここで「技術的負債」（英語ではTechnical Debt）の観点から、それぞれのプログラム言語はどう評価されるのかを見てみたいと思います。耳慣れない言葉かもしれませんが、日本語・英語のどちらでもWeb検索をかけてみると様々な文書がヒットします。アプリケーション開発において、期限に間に合わせることが最優先、保守性は二の次といったような、やっつけ仕事的プログラミングを将来に対する借金に例えた用語です。直ぐに借金を返済できる、すなわち本来あるべきコーディングに修正できるのであれば良いのですが、規模が大きいとなかなか修正に乗り出せないものです。ようやく重い腰を上げてアプリケーションに手を入れようとしても、開発当時のことを憶えている人がいなくなったら、プログラムの理解に多くの時間を割く羽目になるかもしれません。利子がついて借金が膨らんだようなものです。多額の借金はDX推進の足枷でもあります。
CAST Research LabsによるTechnical Debt Estimation文書内のグラフ「Technical Debt within Each Technology」（テクノロジー毎の技術的負債額）を眺めてみましょう。RPGは測定されていませんでしたので、代わりにCOBOLに着目してみます。どちらも60年以上の歴史がある基幹業務用途のプログラム言語なので、代用しても「中らずと雖も遠からず」といった結果であろうとの想定です。これによると、技術的負債額が最大のものから順にJava、Visual Basic、C++か.NET（言語はC#だと思われます）と続いています。一方最小なのはSAP独自言語であるABAP、次いでCOBOLである事が示されています。RPGも似た様なところでしょうか。
グラフは160の組織、アプリケーション数1,400、総プログラム行数5億5千万、を分析した結果だとあります。縦軸はプログラム1000行あたりの負債額（単位はドル）、横軸に各プログラム言語（アプリケーション開発テクノロジー）が並んでいます。データ部分の細い縦線は最小と最大、串刺しになっている長方形の下端・上端はそれぞれ25または75パーセンタイル（全ての要素を小さい方から順に並べた時、全要素数の1/4または3/4番目の値）、長方形の中の白い筋は中央値（全要素の中央の値）を表します。集団の代表値として平均値がよく用いられますが、極端な値があるとそれに振られてしまう傾向があります。そのような時には中央値を見るのが一般的です。
オープンな言語の負債額が高くCOBOL は低いという結果は、多くの方にとって意外だったかもしれません。理由に言及されていませんが、いくつか考えられる点はあります。COBOLは英語文章をそのままプログラム言語化するという想定の元に開発されていますので、記号により近いJavaとかCに比べれば可読性・保守性は高そうです。RPGは英文よりも記号に近いですが、慣れれば開発生産性や可読性はCOBOLよりも優れていると言われておりました。また基幹業務用途という特性ないし文化的背景を考えると、後の保守作業に備えたアプリケーションの文書化にも注意が払われていると想像できます。
RPGもCOBOL同様に技術的負債は抑えられるとして、次に開発体制としてのアジャイル型は本当にメリットがあるのか調べてみたいと思います。参照するのはStandish Groupという独立系調査会社によるレポート「ENDLESS MODERNIZATION」（終わりなきモダナイゼーション）です。レポート・タイトルが示唆するように、終わりが無いアプリケーション刷新（フロー）プロセスを提唱しそのメリットを訴求しています。常にソフトウェアを刷新し続けるという点においてアジャイルの発展型と見て良さそうです。
ちなみにレポート表紙にあるゴールデンゲート・ブリッジは1937年に開通したのですが、現在でも常時30人の塗装工・機械工の方が最新状態を維持するために働いているそうです。基幹業務用アプリケーションもかくあるべし、というわけです。
想定された期日・予算・品質を達成したか否かという観点から、システム刷新時におけるプロジェクト・タイプ毎の成功率がページ2の表にまとめられています。スクラッチ開発（Developed from scratch）は25%、既存コンポーネントを流用した開発（Developed using components）は37%、既製ソフト採用（Purchased application（COTS））は44%、フロー・プロセスによる開発（Flow Like Modernization）は71%とあります。またエンドユーザーの満足度はページ5の表（CUSTOMER SATISFACTION BY PROJECT TYPE）にあります。「非常に」から「ある程度」まで満足したとした割合（Very Satisfied、Satisfied、Somewhat Satisfied）の合計が最も高いのもフロー・プロセスです。すなわちプロジェクト推進側ないしエンドユーザーの立場から、最も優れていると評価されているのが継続的取り組みである事が明らかにされています。
サーバーそのものについても、単にレガシーだからという理由だけでIBM i を例えばWindowsに移行してもメリットは得られない、というIDCによる調査レポートも忘れずにおきたいところです。むしろ現行サーバーを活かしてテクノロジー刷新、すなわちモダナイゼーションを検討した方が良い結果が生まれます。これについて詳しくは、当コラム「その53 : Windowsへの移行かモダナイゼーションか」を参照いただければと思います。
さて既存のRPGプログラムを前提にするとして、どのようにDXレポート続編が言うところのアジャイル体制構築、すなわちフロー・プロセスのような継続的取り組みを実現すれば良いのでしょうか。例えばJavaのような技術的負債の大きい他言語へと、わざわざリスクを負ってまで移行するのは得策ではなさそうです。またビジネス的要件があるならばまだしも、ハードウェア刷新やOSバージョンアップなど、インフラ側テクノロジーの変更がアプリケーションに影響が及ぶような環境である事も移行の否定的要因です。ビジネス要件とテクノロジーとは本来は無関係のはずです。これら観点からRPGを継続利用するにしても、ブラックボックス化しつつあるかもしれないプログラムを、どうしたら柔軟に修正可能な状態にできるのかという課題は残ります。
必要なのは二つの要件、すなわちアプリケーションを可視化・文書化して現状を容易に理解できるようにすることと、修正作業を実施する際にその影響範囲を容易に特定できるようにすること、だと思います。これらを同時に実現する実績豊富なIBM i 用のツールとして、X-Analysisを挙げることができます。従来は人手をかけて実施していたのかもしれませんが、それでは漏れも生じてしまいますし、迅速な変化というDXに求められる要件を満たすことは極めて困難です。RPGのみならず、COBOLやCLもサポートできる、IBM i にとってはDX時代だからこそ需要が高まるツールだと言えます。既存アプリケーション資産を活かしながら、このツールを利用して同時にDXも推進する、という一見矛盾したプロジェクトを推進できるのもIBM i ならではの優位性ではないでしょうか。
ではまた
