前回、DX時代の基幹システムは、Fit to Standardによる標準導入が重要であること、そして足りないものは「作る」から、クラウドなどを活用し「組み合わせる」ことで日本では実現が難しいといわれてきた「Fit to Standard」によるアプローチが可能であることを述べたうえで、DX時代の基幹システムに要求される3つのポイントの概要」と、その一つ目としてクラウド活用のメリットと注意点を解説した。

　今回は、残り2つのポイントとして、Fit to Standardの基幹システムのデメリットとされる「定着化課題・運用負荷の低減」をみていく。

　DXレポートに対応した基幹システムを検討中・構築中の方々が考え方の整理、あるいは自社活動のチェックとしてご活用していただければと思う。

＼ SAP ERPに関連したおすすめイベント・セミナー ／

▼目次
・基幹システムの刷新だけではDX化は失敗する！ストレスフリーな仕様と定着化を目指すには？
・クラウド化によるデメリットである「運用負荷」を軽減するには？

1. 基幹システムの刷新だけではDX化は失敗する！ストレスフリーな仕様と定着化を目指すには？

　DX時代における基幹システムの導入形態「Fit to Standard」のデメリットを具体的に解説しつつ、これを排除するアプローチについて解説する。

• ちょっと待った！そのシステム、従業員がストレスフリーに使いこなせていますか？
• 従業員がスムーズに使いこなせるシステム構築「３つの打ち手」
• 認証基盤の整備
• UIUXと内製化（ベンダー依存からの脱却）

1-1. ちょっと待った！そのシステム、従業員がストレスフリーに使いこなせていますか？

　例えば、ブラウザで動作するシステムとクライアントソフトで動作するシステムが存在して、これらを業務の進捗を確認するために見比べながら仕事をする。各々にログインして業務を遂行するときに、画面を切り替えた瞬間に「セッションが切れました」と再度ログイン画面に飛ばされた、などという経験はないだろうか。

　あるいは、ある業務を複数のシステムでステータスを確認するため、照会画面を立ち上げたとする。同じ情報を複数のシステムで横断して保有しているので仕方がないのだが、システム毎にほんの少し切り口（情報の抽出方式）が異なったり、指定の順序が異なったりする。メニューからの導線も、システム毎によって異なるので「あれ、どこから入るのかな」と毎回迷いながら操作することもある。

　忙しい中でオペレーションをしているため「なんだかわからないけどこっちの画面でとりあえずこの値を指定しておけば、自分の業務は回る」とか、「選択肢が多すぎてわからないから、似た様な過去の入力例から参照起票するけれども、指定値の意味合いはよくわかっていない」ということもよくある。オペレーションを暗記しているだけなので、少しでも異なることが発生すると応用が効かない。

　そもそも既製品は汎用的に作られているのでやれることが多い。実質自分が使うものはそのうちの5～10程度のメニューで事足りるのだが、複数のシステム各々で「自分が使うメニュー」を探して覚えておく必要がある。

　「この処理をするためには、ここからたどってこのメニューを立ち上げる」と、探し回るのも、意外に時間を消費していることがある。

　このように、複数の既製品を組み合わせて使う場合、実際に使うユーザーは「ちょっとした不都合」を体験しながら「とにかく自分の業務が遂行できるように」と努力している。

　「DX時代の基幹システムは、組み合わせて使うので、事業環境が変化したら、疎結合なのでシステムの取り換えも容易にできる」とは言うものの、現場で仕事をしているユーザーは「やっと今のシステムで何をしたらいいか（パターン暗記は）理解できたのに、またやり直すんですか」と、うんざりする。


　日々の業務で少しずつ時間を浪費し、IT進化の度に暗記し直し。

　これでは、システムの定着化がおぼつかず、せっかくのシステムも十分な効果を発揮できない。

　もう少し、システムと従業員（ユーザー）の関係性を改善できないだろうか。

1-2. 従業員がスムーズに使いこなせるシステム構築「３つの打ち手」

　ここでの打ち手は大きく3つだ。

• ポータルを使う
• ノーコード・ローコードの画面改善
• デジタルアダプションという考え方の導入

1-2-1. ポータルを使う

　ポータルサイトという言葉は聞いたことがあるかと思う。「複数のシステムに横断していたとしても共通の入り口を用意すれば、ユーザーはシステム切り替えをする必要がない」という考え方だ。

　SAPの場合にはBTP上にポータル（Launchpadという言葉も同等の意味）という機能が提供されている。

　このポータルは、基本的にはメニューを構成する機能であり、権限ロールに従って、必要な人に、必要なメニューを表示させるよう設定することができる。基本的にはノーコードで実現可能なため、学習コスト低く自力で構築できることが魅力だ。

　SAPのポータルには追加で嬉しい機能がついている。

• メニューのタイル表示
• タイルに業務上重要なメッセージを表示できる（「まずは、今、何をすべきか」が分かるようになっている）
• 例えば、受注した伝票の一部に後続で問題が発生している場合、警告を発することができる
• メニューのパーソナライズ
• よく利用するメニューをトップに表示できる
• モバイル業務を視野に入れたときに、非常に便利

1-2-2. ノーコード・ローコードの画面改善

　標準画面に存在する膨大な入力項目のうち、自社で使うものはほんの一部であるとか、入力の順序を変更したいといった要望、あるいは照会系で、自社の業務に合わせたちょっとした情報の組み合わせをいつでも見られるようにしたい、という要望があると思う。

　今まで、こういった場面では「ベンダーと要件定義して、見積もりを取って、相当な金額を支払って、実現できるのは半年後」というのが「あるある」ではないだろうか。

　SAP S/4HANAでは、以下の機能がBTP上で提供されている。

• Screen Personas（スクリーン ペルソナ）
• 画面のレイアウトを変更機能
• Fiori Elements（フィオリ エレメント）
• 照会画面をノーコードで作成する機能いずれもノーコードの機能

　ノーコードでできることは、ある程度パターン化されたものに留まるが、それでもプログラミング経験が乏しいメンバーでも、試行錯誤しながら挑戦できる点は魅力だ。ベンダーに頼らず内製化できるなら、まずは作ってみて、早くリリースして、改善する、といったアジャイルの取り組みを、低いハードルから開始することもできる。


　「機能は標準のまま、画面動作を変更することで業務効率を上げたい」ということもある。

　例えば、複数の画面を統合したり、逆に一つの入力で複数の伝票を投入するといったこともある。バーコードによる入力効率化も、よくあるニーズだ。

　こういった場面では、専用の仕組み（例えばLiquid UI）を使ってローコードで実現することができる。これも、標準に手を加えずに実現できるうえ、教育さえ受ければ内製化が可能なものだ。

1-2-3. デジタルアダプションという考え方の導入

　ITの進化速度が速くなって、変化に強い基盤を搭載し、先進的な機能が搭載されても、人はそんなに変化に強くない。日本人の平均年齢は高くなるし、介護などのために時短勤務も発生する。これからは、従業員の構成も様々な人種を想定するべきだ。こういった人たちに、ITの変化を受け入れてもらう必要がある。

　デジタルアダプションとは、このように多様な従業員全員が、継続的に変化する先進技術を使いこなす＝定着化させるためのテクノロジーである。

　システムに関するマニュアルは、作る方の負荷はもちろん、読んで理解する方の負荷も非常に高い。また、場合によっては「ヘルプデスク」の設置などコストがかかる。デジタルアダプションは、これをテクノロジー支援する。典型的なものとしては、ユーザーの操作に合わせて画面をガイドするボットが動作し、あたかも利用者に寄り添って「次はこちらの機能入力も忘れないで」とか「こちらのシステムも入力して」といった具合で誘導してくれるものがある。

　前回、システム間連携の中で触れたように、チャットボットがユーザーの意思決定を問いかけて、質問に答える形で業務を遂行していくというのも、一つのデジタルアダプションの形と言える。

　全社員・全ユーザーにとって使いやすく、分かり易い、ということと同時に、「外部環境やテクノロジーの変化に応じて、システムが変化しても、あるいは利用者が多様化しても、ストレスなくシステムを使い続けられる」ということは、デジタルトランスフォーメーション（DX化）推進において、絶対に視野に入れておく必要がある。

1-3. 認証基盤の整備

　ポータル、ノーコード・ローコード、デジタルアダプションと紹介してきたが、これら全体に共通するシステム基盤がある。認証認可だ。シングルサインオンと、権限管理と言い換えても良い。複数システムを横断して、違和感なく使っていくためには、システムの境界線がユーザーにあまり意識されないようにしたい。

　そのはじめの一歩が認証基盤の整備だ。

　また、権限に関しても、システム個別ではなく、統一的な考え方で 制御をした方が良い。認可の基盤の整備も必要となってくる。

1-4. UIUXと内製化（ベンダー依存からの脱却）

　ユーザーの使い勝手を改善してコントロールする分野は、多くの場合ユーザー企業で対応可能であることが多い。そういうことが可能な仕組みが数多く提供されてきているというのが主な理由だ。

　一方、使い勝手の部分はユーザーからの要望も多いところであり、どこから手を付けるべきだろうかという話もあるだろう。要望発生組織のバランスとか、効果が高い順序といったことも当然あると思われるが、内製化が可能なのであれば、まずは完璧を目指さない点も重要だと思われる。

　なぜなら、要望ひとつ取っても、複数の要件に分解できることが多い。

　「これなら簡単に実現できる」といったところから対応し、すべての要望に完璧な対応を望まないことが肝要だ。実際、ノーコード、ローコードの仕組みは、やれる範囲に制約があり、作ってみたら実現できなかったということも多い。実現できる範囲で素早く利益を享受するというスタンスでなければ、結局、相当な作り込みを行うことになるので、注意が必要だ。

2. クラウド化によるデメリットである「運用負荷」を軽減するには？

　Fit to Standardにおいては、基幹システムとクラウドと組み合わせることによって機能要件を満たす考え方であるが、クラウド活用のデメリットの排除の方法についても触れておきたい。

• クラウドのブラックボックス化を未然に防ぐ
• クラウド活用は、統合監視で「見える化」すれば安心
• マルチクラウドの運用負荷はアウトソースが最適
• DX時代は、開発運用の仕組みが必要である
• CI/CD導入のススメ

2-1. クラウドのブラックボックス化を未然に防ぐ

　複数のシステムやサービスを組み合わせて使う場合、運用上真っ先に思い浮かぶのは「複数プロバイダの登場」だろう。複数プロバイダによる組み合わせ運用はこれまでも存在していたかと思うのだが、SaaSやPaaSといったクラウドが登場すると、「ブラックボックス化」がより顕著になる。

　例えばSaaSからデータを取得してJavaでデータ加工を行い、結果を帳票PaaSのAPIでPDF化したとする。一つの処理が失敗した場合、登場人物は、SaaS事業者、Java開発会社、帳票PaaS事業者と3社だ。ユーザーは、この3社に対して原因に該当するのかどうかを投げかけるか、自分で調査しなければならない。しかも事業者によっては「自分のところに責任がある場合にはご連絡ください」というスタンスも多い。これまでバッチ系のシステム間連携でのみ発生していたような「たらいまわし」が、より多くの場面で発生しうるようになると理解してもらいたい。

　また、「プロバイダが増える」だけでなく、「同一プロバイダに対する契約が細分化される」ということも、クラウドを活用し始めると発生する。

　単純に「ERPを使うサブスクリプション契約を結ぶ」ということではなく、下記が行われていたりと、気が付くと多くの契約となっていることがある。

• 「外部からの伝票連携が年間XXX件以内」といったオプショ
• データ連携基盤は、その基盤のIN/OUTのデータ容量による課金

　中には、全社的に共通で契約しているAPIが存在しているが、蓋を開けてみると想定していたほど使われていなかったり、逆に「その使い方したら、別途オプション契約必要になってしまう・・・」といったことが発生するなど、契約管理が複雑化することがある。

　また、SaaSやPaaSなどのクラウドサービスは、常時、最新機能がリリースされることが魅力ではある一方、その影響範囲の特定と対応が必要になる場面があることも事実である。アップデートサイクルも、サービス毎に異なるため、逐次、関係者へ注意喚起（場合によっては検証依頼）するだけでも運用負荷が上がることが予測される。

2-2. クラウド活用は、統合監視で「見える化」すれば安心

　こういった運用負荷を低減させる手段としてAPMを検討したい。

　APMとは、「Application Performance Monitoring」の略で、アプリケーションパフォーマンス管理のこと。これまで監視といえばインフラ監視であることがほとんどであり、あとはジョブ監視がアプリケーション領域ではよく使用されていたのではないかと思われる。

　これに対して、クラウド上のアプリケーションを制御するためには、ひとつのプログラムが、複数のコンテナ、複数のデータセンター上で動作することを前提としなければならず、しかもこれらのプログラムが複数連動して動作するようになった。こういったアプリケーションの状態を監視する必要性から、クラウド上に分散する各仕組みのログをリアルタイムで収集して「見える化」するAPMが登場した。

　SoRの文脈でAPMが活躍する場面は、まずはシステム間連携や、拡張開発などの複数システムが連動する仕組みに対して、「何がどこまで動作して、その瞬間連動する各システムはどういった状態だったか」がビジュアルで横断的に把握できる点である。APMが動作する環境においては「たらいまわし」リスクを低減することが可能だということだ。

　また、「どのステップで何秒所要したか」といったところまで追いかけられるため、ユーザーからの「画面がすごく遅くて使えない」といった意見に対しても、ボトルネックの特定が極めて容易であるという点は得難い。

　APMはNewRelicやDynatraceといったサービスが有名である。

　不可避に複雑化するシステム運用の負荷を低減するために、まずは検討してほしい。

　ただし、APMも万能ではない。SaaS・PaaS・iPaaSと並べたとき、特にSaaSに関しては、APMが利用できるAPIを公開していないケースがある。またPaaS・iPaaSにおいても、目的に適したAPIが公開されていなかったり、セキュリティポリシー上、APMのエージェントの導入を許可していない仕組みも存在する。実際には、一つ一つのサービスについて利用可否を確認しながら導入する必要がある。

　そういった場合には、並行してサービス事業者が提供する監視の仕組みも確認した方が良い。一般には公開されていない内部的なデータを活用して、必要な監視機能を提供していることがある（SAPの場合には、ALMがこれに当たるようだが、未だサービスが提供され始めて間もなく、活用範囲を確認しながら進める必要がある）。

　非常に特殊な監視の仕組みを持っているサービスも存在する。サービスそのものの負荷がある閾値を越えた場合に、メールを送信するといった仕組みを持っている場合だ。ここまでくると無理にAPMで対応するために個別の作り込みが発生することが想定されるため、メールを処理する何らかの既存の仕組みを活用した方が良い。多くのリモート監視サービスには、メールをインプットとする監視メニューがある。

2-3. マルチクラウドの運用負荷はアウトソースが最適

　DXレポートでは、内製化率を高めるべきだと提言しており、総論、その通りである。

　しかし、今回のブログテーマで見てきたマルチクラウドの運用負荷低減策は、むしろアウトソースすべき内容だろうと考える。

　マルチベンダー、マルチサービスのシステムを横断的に管理して全体最適を図る役割を、SIAM（SIAMとは、マルチベンダーの運用管理やシステムライフサイクル管理の知識体系のこと）では「サービスインテグレータ」と呼んでいる。これまでの保守運用は個別システム毎に管理をベンダーに依頼していたが、個別システムの内製化を進める一方で、横串の管理対応は、まさにこの「サービスインテグレータ」に依頼した方が良い。

　このサービスインテグレータは、これまでの個別システム・サービス単位の監視から、業務を実現するすべてのシステム・サービス監視までスコープを広げる必要がある。また、複雑化した契約を管理し、全社的な視野で適切な利用状況であることを監視できた方が良い。この場合、厳密にはAPIがどのように呼び出されているかと言った粒度で管理が必要となるが、APMを活用すればある程度対応は可能だ。結果としてAPI管理までアウトソースが可能となる。

　サービスインテグレータは、運用体制の議論に含まれるが、これを実現するための武器となるAPMはアーキテクチャとしてあらかじめ定義しておいた方が良いため、アーキテクチャ検討段階から俎上に載せておいた方が良い。

2-4. DX時代は、開発運用の仕組みが必要である

　もう一つの「運用負荷」とその対策について触れておきたい。

　それは「開発運用」と呼べる領域だ。

　DX以前は、基本的にシステムは構築したら、次のシステム更改までは「維持保守」としてひたすら保全（と、ごく一部改修）に留まっていた。一方、DX時代においては、常に刷新される事業環境や技術環境に対応して、システム変更をし続けていくことが前提となる。そのスピード感に対応できるような「開発運用」の仕組みが必要だ。

2-5. CI/CD導入のススメ

　こういった文脈で、「CI/CD」というワードが登場する。

　CI/CDとは、「Continuous Integration／Continuous Delivery」の略で、日本語では「継続的インティグレーション／継続的デリバリー」という。これは、ソフトウェアの変更を常にテストして自動で本番環境にリリース可能な状態にしておく、ソフトウェア開発の手法を意味する。

　PaaS、iPaaSを組み合わせた基幹システムでは、部品が数多く存在する。認証基盤・ポータル・ノーコードアプリケーション・ローコードアプリケーション・データ連携フロー等、それぞれに開発・検証・本番の環境が存在し、本番環境については、冗長化のために複数のインスタンス（コンテナ）が存在する。物理的なサーバをベースに考えていたものと大きくは変わらないが、部品が多く、各々の部品がコンテナ（小さなサーバと考えて良い）として独立して存在することと、拡張性が格段に柔軟である（負荷状況によってコンテナが増えたり減ったりする）ことが大きく異なる。

　これら多くの分散した部品群が、各々常時何らかの改修のためにバージョン管理されている状況を想像してほしい。どのセットが、いつ、どこのコンテナに配布されるのが正しい運用であるのかを完全に制御しようとすると、相当な注意と工数が必要となることは想定できると思う。また、そのように分散したシステムと分岐したバージョン毎の品質保証も、大きな負担となるだろう。

　CI/CD（「Continuous Integration／Continuous Delivery」＝「継続的インティグレーション／継続的デリバリー」）のうち、CIは、定義された組み合わせで常に最新のソースコードやライブラリを結合し、各種テストを自動化することを指す。CDは、適切な配布先へ前提テスト済みのオブジェクトを自動配置し、その結果を確認することを指す。

　自動化するテストの範囲は、対象のオブジェクトによって異なるが、一般的には単体テスト、結合テストまでを自動化することが多く、場合によっては負荷テスト、システムテスト、それからコンテナそのものの脆弱性診断などを入れることがある。

　こういったタスクを可能な限り自動化することで、運用負荷の大幅な低減や、システム変更容易性と品質向上を両立させることができる。結果として属人化も排除できることになる。

　CI/CDは、オブジェクトバージョン管理（リポジトリ管理）とタスク自動化の機能で成り立つ。要件管理もCI/CDと密接に関わるため、仕組みは統合しておいた方が良い。

次回予告

　連載2～3回目の記事で、DX時代の基幹システムを、様々な製品サービスの組み合わせで実現する際のポイントを確認してきた。

　次回は、これまでの議論を踏まえたシステム構成の全体像の確認と、このシステムが実現されたときに、「DX時代の基幹システム」はいったい何ができるようになるのか、という点をお話したい。

　尚、本記事の続きやバックナンバーは、以下よりご覧いただきたい。