目次

自己紹介

持続可能なITとは

持続可能なIT実現に向けて

自己紹介

みなさま、はじめまして!
日本IBMで「IBM i カスタマーサクセスアドバイザー」という職務を担当しております、久野と申します。

まずは自己紹介から。中学生の時に、はじめてPC (当時は「マイコン」が一般名称でした) に触れて、プログラミングでお小遣いがもらえることに味をしめて、毎年、小売店舗の催事で使うようなゲームソフトを受託開発していました。大学1年生の時には、ITベンチャー (当時は「ソフトハウス」と呼ばれていました) の設立に参画、その後大学卒業とともに、日本IBMに入社しまして、営業職として日本中の様々な業種のお客様とお付き合いさせていただいてまいりました。

今回、縁がありまして、システム管理者の会のみなさまに、わたくしの小文をご覧いただく機会を頂戴いたしました。これから、2回の予定で、ブログを寄稿させていただきます。お付き合いいただけましたら有難く存じます。よろしくお願いいたします。なお、当ブログの掲載内容はわたくし自身の見解であり、必ずしもIBMの立場、戦略、意見を代表するものではないことを、初めにお断りしておきます。

持続可能なITとは

みなさまも日頃、目にされている通り、IT市場には、たくさんの製品・サービスが存在します。ひとつの目的を達成するために、いくつものソリューションが選択肢になります。それらのソリューションのベースとなる製品・サービスは、時と共に消滅したり、他の製品・サービスに統合されたり、バージョンアップしたりして、導入した当初と互換性のある後継製品・サービスがなくなってしまうことが多々あります。
これら製品・サービスの提供元にとってはビジネス機会を最大化することも重要なわけですから、互換性よりも新機能を重視した新製品を提供する、いわゆる「リセット文化」で新鮮味をアピールして早期の入れ替えビジネスや、入れ替えに伴う追加サービスを創造していきたいことは理解できます。

ですが、ユーザー視点では、投資予算は新たな価値を創造するために使いたいものです。既存のアプリケーション資産の維持にキャッシュを使ってしまっては、自社のビジネスに貢献できません。「IT予算配分」などのキーワードでネット検索すると、IT予算の7割から8割が既存ITの維持に費やされているとの記事が表示されます。これでは、持続可能なビジネスを実現するための、DXへの投資が十分にできないのではないでしょうか。「2025年の崖」をホラーストーリーのバズワードとして利用しているベンダーの貴社への提案は、「2025年の崖」を多大な「リセット」コストをかけて、単に「2030年の崖」に先送りするものではないでしょうか。

持続可能なITを保持するためには、アプリ導入後の長期に亘る維持管理のコストをアセスする必要があります。例えば、アプリ稼働インフラとなるHWやSWがサポート終了 (EoS) しても、すべてのそれらコンポーネントに、後継製品があり、かつ、後方互換性と、コンポーネント相互のサポートが担保されていれば問題はありませんが、貴社の場合はいかがでしょうか。
結局のところ、この悪しき「リセット文化」は、ユーザー企業の「既存ITの維持」コストの固定化もしくは増加につながり、企業価値創造のための新しいビジネスの取り組みをITが支援するに際して、足枷になってしまっています。

もちろん、アプリケーションコードが誰でも読みやすく、かつ、連動するコンポーネントの機能スペックが明確に理解されている環境であれば、「リセット文化」においてもHW・SWのEoSに伴う移行費用を始めとするIT維持費用は低減できるでしょう。他方、コンポーネントのみならずアプリケーションロジックまでがブラックボックス化している (場合によってはRPAによって運用・業務オペレーションまでもがブラックボックス化している) ケースにおいては、コスト低減の方法としては、ITベンダーに対する値下げ交渉か自らの労働コスト削減しか方法がありません。止めるという選択肢以外には。

持続可能なITには、アプリケーションの仕様が見える化されていること、後方互換性が担保されていること、の両方が欠かせません。ここでは、いくつかのレイヤーに分けて、この点を考えていきましょう。

1) 業務オペレーションレイヤー
現在の現場業務オペレーション、例えばあるデータの入力画面の操作方法や、日次、月次などの締め作業における操作のプロシージャーが明確になっていて、かつ、アプリケーションレイヤー以下のリプレースに際しても、業務オペレーションに変更がなければ、現場の負担は生じません。他方、取引先様の要請、サービス品質の向上など改善活動、経営戦略の変更や品ぞろえの追加など、ビジネス上の要請に伴う変更は、当然生じます。これはまさしく必要な変更です。このような変更に際したトレーニングにのみに現場はワークロードを投入すべきです。

2) アプリケーション/データベースレイヤー
もし貴社の現行システムが、貴社コンピテンシーを支えるテーラーメイドのアプリケーションで成り立っているのであれば、「ベストプラクティス(という名のアプリ仕様)」を内包したERPパッケージへの変更は、「ベストプラクティス(という名のアプリ仕様)」採用による現場業務の混乱や負荷増や企業としてのコンピテンシーの棄損を、ERP、すなわち全社資産配置の最適化、による効果が上回る場合においてのみ正当化されます。よく「既存システムがブラックボックス」で「アプリを保守できる要員がいない」ことが、ERPパッケージへの変更理由として挙げられますが、導入しようとしているERPの「ベストプラクティス(という名のアプリ仕様)」が果たして貴社のコアコンピテンシーを棄損しないのか、逆にERPに貴社のコンピテンシーを実装するために、どれだけのカスタマイゼーションを必要とするのか、事前に検討されることをお勧めします。
ユーザー企業自身がパッケージを精査して、パッケージ本体に手を付けずにパラメーター設定の変更と、パッケージが持つAPIを利用したアドオンのみを、実施するのであれば、「現場部門の要求丸のみ」カストマイズと「丸投げ」カストマイズによって生じるアプリケーションのブラックボックス化は避けられるでしょう。
そうでなければ、結局のところ、「プラックスボックス」の現行アプリケーションを、多額の費用と時間と労力をかけて、費用対効果も期待できないままに、現行と同様の「ブラックボックス」の新アプリケーションに置き換えるだけになります。現行システムに対して企業コンピテンシーの向上に必要なアップデイトを加えるプロジェクトに比べて、コスト面でも、スケジュール面でも、使い勝手でも、アプリの見える化でも、劣ってしまいます。
もし、経営トップが全社最適化を要求されるのであれば、現行の現場業務システムと、ヒト・モノ・カネをマネージできる管理会計パッケージをAPIでつなげる方法もあります。人事管理・給与や財務会計などはユーザーが限られていてかつ現場には関係ないですし法令対応の必要もありますからこれらについてはパッケージやSaaSによる部分最適がよい選択肢になると思います。
自社のコンピテンシーをサポートするアプリと、そうではないアプリに区分けし、前者は現行アプリのアップデイトによる機能強化、後者は現行継続とパッケージ/SaaSを比較検討して最適解を利用することで、「2025年の崖」をバズワードに使う提案に無駄な投資をする事態を回避できます。

3) ミドルウェア・OS・HWレイヤー
アプリケーションやデータベースの移行作業が生じる理由の多くは、これらを支えるOSやミドルウェアのサポート切れです。
起点がHWのEoSであることも多いでしょう。

現行HWのサポート切れ (EoS)
↓
新HWでは現行OSをサポートしていないので新HWにあわせてOSもバージョンアップ
↓
新OSでは現行のミドルウェア、ユーティリティー、アプリケーションフレームワークをサポートしていないので、これらも新OSにあわせてバージョンアップ
↓
新ミドルウェア、ユーティリティー、アプリケーションフレームワークと、現行のアプリケーションプログラム環境との互換性が確保されていない場合には、アプリケーションプログラムの修正・単体テスト・全体テストにワークロードと時間とお金を投入という事態に陥ります。

過去のアプリケーションが新しい環境でも稼働保証されていればよいのですが、組み合わせされた新OSと新ミドルウェアの中の一つのコンポーネントでも後方互換性が担保されていなければ、過去のアプリケーションの稼働確認のために、修正・単体テスト・全体テストが必要となります。貴社の環境では、どれくらい後方互換性が担保された組み合わせをご利用でしょうか。

持続可能なIT実現に向けて

各レイヤー視点で持続可能なITを見てきました。ご理解いただき易くするために、現行システム対ERPパッケージで記載しましたが、もちろんテーラーメイドで新たなアプリを開発する方法もあります。コンピテンシー実装の実現方法として、現行システム拡張や、ERPなど業務パッケージの利用、そしてテーラーメイドでの新規開発、それぞれに長所と考慮点があります。何を目的とするのかによって、何を実施するのかによってご判断は変わるかと思います。
しかしながら、いずれの手段を利用したにせよ、いったん構築した基幹システムは、長期的に利用されるケースが大半のはず。その期間において、EoSに伴う移行コストやメンテナンスコストを最小化しつつ、時々刻々発生する「ビジネスで成功するための」新規アプリ開発に最大限コストを費やすことができるようにしていくべきかと存じます。この投稿が貴社にとって少しでも役立ったのであれば、この上ない幸せでございます。

読者の方のなかには「パッケージ利用に対して辛口ではないか」とのご印象を持たれた方もいらっしゃるかと存じます。わたくしの経験や学びが投稿に反映されています。ひとつの意見としてご寛容のほどお願いいたします。

さて、「持続可能なITについて考えてみた」は、次回「これからのITに求められる「持続性」とは何か、も考えてみた」に続きます。お楽しみに！