IBM i のウンチクを語ろう
～ その86：アプリケーション保守ツールの価値を経営層に訴求するには
皆さん、こんにちは。アプリケーションを効率良く保守するためには、ドキュメントを常に最新状態に保たなければならないとされています。ところが長い間には組織が変わり人の出入りもあり、せっかくのドキュメントが所在不明になってしまったり、さらにはアプリ改修が相次ぐうちに、維持されないままになっていたりするケースは意外に多いようです。プログラミングが好きという人はいても、ドキュメントを書くことも含めて好き、という人をあまり聞かないことも理由の一つなのかもしれません。このような事態からの脱却を図るために、またはこのような事態に陥るのを未然防止するために、アプリの保守ツールは極めて有効なのですが、IT部門と経営層とで受け止め方に違いがあるといつも感じています。
決して安い製品ではありませんし、視点が違えばツールに対する評価の仕方も違うのは、当然と言えば当然です。IT現場の方は機能を知ればその利便性や効果を理解いただけることが多いのですが、直接アプリ保守に関わっていない、またはそのような経験が無い経営層の方に同じことを期待するのは無理があります。ライセンス料金や保守料金のように社外に出てゆくカネがある一方で、アプリ保守作業の負荷軽減という効果は、売上増に直結するわけではありません。これまでツール無しで過ごしてきたのだから、それで致命的な何かが生じることはあり得ない、という理屈もあるでしょう。各社の事情を鑑みながら、何とか数値化を試みるというやり方もあるのかも知れませんが、少し違った視点からこのツールの価値を理解する必要がありそうです。今回のコラムは、様々なお客様とのやり取りを重ねてゆく中で、こんな説明をすれば良いのかもしれない、という安井個人の考えをまとめてみたものです。
結論から先に言うと、経営的視点から見たアプリ保守ツールの効果は、DX推進と後継者不足解消だと言えるでしょう。ITの内製化とアジャイル体制の構築を実現することでDXを推進し、長期的には後継者育成に寄与することが期待されるというわけです。どういうことなのか、順を追って説明していまいりましょう。参考までに、アジャイル（Agile）には「機敏な」とか「頭が切れる」といった意味があり、アジャイル体制があればアプリ保守を機敏に行えるようになるものと想定しています。
「DXレポート2中間とりまとめ」の「4.3.1 デジタルプラットフォームの形成」セクションに目を向けてみましょう。ここではDXを推進するためのITをどのように構成するべきかを説明しており、着目したいキーワードとして「内製化」と「アジャイル体制」の2つを挙げたいと思います。自社の強みであるビジネス領域を見極め、そこを支えるためのITを内製化し、投資を行って、環境の変化に応じて柔軟に機能強化を実現するための体制を作り上げるべき、というわけです。その一方で、自社の強みとは関係の薄い領域、他社との差別化要因にはならないような業務領域については、クラウド・サービスやパッケージ・ソフトを利用することでコスト削減を図ります。ちなみにDXレポート2では、自社の強みの源泉となっている業務を競争領域、強みとは関係の無い業務を協調領域と呼んで識別しています。
レポートではコスト削減と投資とがセットになっているのですが、実際には協調領域におけるコスト削減だけが実施されているケースが多いように感じています。DX推進の途上にあると言うよりも、ITコスト削減圧力による結果だと考えるべきなのでしょう。その状態を基準にするならば、IT投資は純増することになります。DX 推進におけるハードルが一つ増えることになってしまうのは、やむを得ないように思います。
伝統的（?）ないわゆるウォーターフォール型プロジェクトにおいては、アプリ開発は要件定義から始まって、コーディングを経てリリース・運用に至るまでの一連の作業で構成されるとしています。プロジェクトは水が落下する滝（Waterfall）のように後戻りすることなく進捗しますので、完了した時に実現されるのは過去に定義した要件であり、必ずしも最新のビジネス環境に即したものにはなりません。プロジェクトが必要とする要員数も、そのフェーズに応じて大きく変動しますので、ITベンダーは要員プールとして機能することが求められます。
一方のアジャイル体制においては、渦潮（うずしお）に例えられるように、無期限に小規模な改修を繰り返してゆきます。自社の強みを維持・強化するためには、アプリも最新のビジネス環境の変化に迅速に追随してゆかなければなりません。必要となる要員数の変動は、ウォーターフォール型のような大きな波ではなく、ある一定水準を維持する小さな波が続いてゆくようなイメージになります。この時にアプリ保守を外部委託して、改修が必要になる毎に要件定義書を作り見積もりを取得し・・・とやっていてはスピード感が犠牲になってしまいます。それを避けるためにも内製化が望ましい、というわけです。この場合にITベンダーは、ユーザーと並走するアドバイザの役割が期待されることになります。
しかしながら、一人情シスのように人員配置が伴っておらず、急に人が増えることが期待できなければ、内製化はどうやっても不可能です。そのような時にアプリ保守迅速化のための次善の策として考えられるのは、ベル・データが提供しているアプリケーション保守サービスの活用です。外部委託であることに違いはありませんが、時間制の契約なので、時間内であれば新規のアプリ改修・開発にも対応できます。内製ほどではないにしても、「準アジャイル的」と言えるのではないでしょうか。
さて、自社による迅速なアプリ改修を目指すにあたって何が必要になるでしょうか。保守に携わっている開発者はその約50%の時間を既存プログラムの理解に費やしている、というデータを見たことがあります。権威ある調査の結果というわけでもなさそうなのですが、実際にこの数字を何社かのお客様に提示したところ、概ね違和感無く受け取っていただけているようです。パーセンテージはともかく、プログラム理解に最も多くの時間が費やされているのであれば、その部分の効率を高めることが改修作業を迅速化する上での早道だと言えるでしょう。さらに正確さという要素が加わるならば、改修するべき範囲を漏れなく特定することも容易になるはずです。そのためにはドキュメントを常に最新状態に保つべきという正論はあるのですが、冒頭に述べたとおり、そうはなっていないケースが多いのが現実です。現在は何とかできていたとしても、将来においても継続するためには、人手に頼るだけでは不安が残ります。アプリ保守ツールが効果を発揮しそうですね。
ここでX-Analysisというアプリ保守ツールを活用されているお客様のケースを、簡単に紹介したいと思います。IBM i 上でRPGプログラムを自社開発・保守されているのですが、ツールを活用するようになって、2つの点が大きく改善されたそうです。各種ドキュメントを自動生成してくれるので、既存プログラムを迅速に理解できるようになったことと、改修範囲を機械的に漏れなく見極めてくれるので、改修時テストの品質が向上したことです。従来はテスト実施の段階になって改修漏れが発覚することが何度かありました。改修範囲の特定は、地味ですし、誰もが前向きに取り組みたくなるような作業ではなかった、というのも事実でしょう。
極めて高機能なツールなのですが、IT要員が不足しているお客様の中には、ライセンスを購入して習熟するだけの余裕がないところもあろうかと思います。この部分は先に紹介したアプリケーション保守サービスの中で補うことができますので、次善の策として検討いただければと思います。
ツールを活かすなどして最新のドキュメントを生成できれば、プログラム保守を担う後継者育成においても役立つかもしれません。他人が開発したプログラムを保守するのは困難だとよく言われますが、ドキュメントの不備がその原因となっているケースは多いようです。アプリ保守ツールはこれを解決する手段になります。手間のかかる機械的作業をツールに委ね、人はより生産性の高い仕事に携わるようにできるのが理想的ですね。
後継者育成においては、RPGなどのプログラム言語の学習は前提として別途必要になります。フリーフォームRPGの採用が有効な対策になり得ること、そのような事例が増えつつあることは、当コラム「フリーフォームRPGは本当に効果があるのか -1」とその続編に述べておりますので、あらためて参照いただければと思います。いずれにせよ、DX推進と後継者育成のため、という視点でアプリ保守ツールを評価・検討していただければ幸いです。
ではまた
