EUCやEUDとは？EUC/EUDの基本的な考え方や情報システム部門での留意点について詳しく解説！
DXの広がりと相まってEUCやEUDと言うコンセプトが話題になる機会が増えていますが、EUC/EUDはメリットだけではなくデメリットも併せ持っています。
特に、システムの管理全般に責任を持つ情報システム部門とEUC/EUDの主体となる業務部門（情報システム部門以外の部門全般を指す）とではEUC/EUDに対する観点が違うことがあり、一概に「促進すべき」とも言えない部分があります。
本記事では、情報システム部門として知っておくべきEUC/EUDの留意点や考え方について解説します。
目次
EUC/EUDとは
EUC （End User Computingの略）は、情報システム部門以外に所属する従業員が、主にオフィスツール(Excel、Access等)を使用して、データ分析、レポート作成等、情報システム部門の管理対象である業務システムでは満たされない機能を実現することを言います。
これは、PCの普及に伴って発展してきたもので、当初は非定型、非構造的な業務を対象にしていました。
その後、EUCとは別に、オフィスツールだけではなく、マクロ言語や簡単なスクリプト言語、簡易データベース等を使用して、業務システムに近いものまでを組み上げるEUD(End User Development)という形態も現れてきました。
その結果、定型的な業務も対象とするケースも見られるようになりました。
また近年では、DXの盛り上がりがEUC/EUDを後押ししている状況にもなっています。
技術的側面として、ノーコード開発、ローコード開発という手法により、業務部門自身が簡単なシステム開発を行うことも可能になっていますし、AI(人工知能)やRPA(Robotic Process Automation)という技術も業務部門とシステム開発の距離を縮めていることが影響しています。
しかし、EUC/EUDがDXに直結しているケースだけではなく、ツールの利用そのものが目的化しているというケースも見受けられ、安易な利用促進には注意が必要です。
EUC/EUDの利用が推進される理由として、もうひとつの側面があります。
それは、「情報システム部門はビジネス感覚や業務知識が希薄である」という批判が業務部門に存在することです。
全ての企業ではありませんが、この感覚は、ITガバナンスがきかないEUCとなって現れることがありますし、ひいてはEUCのアウトソースや、業務部門によるITの直接調達にもつながる危険性をはらんでいます。
なお、近年では技術の発展によってEUCとEUDの区別がなくなりつつあります。そのため、当記事では、これ以降EUCという表現のみを使用して、両方を含めることとします。
EUCの留意点
先にも記述のとおり、EUCはメリットとデメリットを併せ持っています。
それらには、EUCの主体である業務部門から見たものと、情報システム部門から見たものの両方があります。ここでは、その裏表の関係を留意点として整理します。
1．部分最適に陥らせない
情報システム部門が提供するシステムは全体最適を目指す傾向が強くなりますが、EUCの場合は、それだけでは物足りない部門の個別要望を実現させることができます。
ここには、２つの問題が潜んでいます。
EUCによって実現される機能が組織全体の方向性を考慮したものであれば問題ありませんが、場合によって、部分最適のためにEUCによって実現される機能が全社の戦略やビジョンと一致しなくなる危険があります。
これは本末転倒であり、業務の見直しが優先されなければいけません。
また、それとともに、「属人化」のリスクがあります。 EUCは属人的な感覚で遂行されるケースが多くなります。
また、その属人性が特定の個人に限定されてしまうと「ブラックボックス化」してしまい、その担当者以外は運用もできず、変更をするにしても誰も手が付けられない状況になります。
これは、次項にも関係するポイントです。
2．品質を確保する
情報システム部門が開発案件として取り上げるものは「(企業にとっての)重要度、緊急度、戦略性、コスト」等のポイントと、「情報システム部門の人的リソース、予算、システムアーキテクチャ」を鑑みて優先順位付けされますが、EUCでは業務部門が考える優先順位で着手が可能なため、スピード感をもって機能を実現させることができます。
その反面、スピード感を優先するあまり、「品質」への意識が低くなることがあります。その結果、データの整合性、正確性が低下するという状況が発生します。
具体的には、 EUCが独自に計算した結果と全社システムが出力した結果が合わないケースが発生し、間違った意思決定がなされるという状況が考えられます。
これは、コード体系の不整合やデータの意味付けの違いなどと言うようなシステム品質の問題に起因します。
また、ドキュメントの未整備という問題も品質に関わるものです。
「どうしてこの機能が必要になったのか」「どのように運用すべきか」「システム変更が必要な場合はどうすればいいか」等のドキュメントが整備されないまま利用が開始されてしまい、スピード感はあるものの、システム全体としての品質が担保されないことになります。
3．コストを明確化する
EUCは情報システム部門の「要員」「予算」「時間」というようなリソースの不足を補うことができます。また、EUCは内部開発が基本となりますので、外部コストを抑制できる可能性があります。
しかし、ここにも「予算/コストが不透明になる」というリスクがあります。
情報システム部門が持つ予算の外側でEUCが実施されることになりますので、情報システム全体としての予算やコストは不透明にならざるを得ません。
また、EUCのコンポーネント自体にコストがかからない場合でも、EUCに携わる人にかかるコストは避けることができません。
人的コストについては、他にも留意点があります。EUCを担当業務としてしまうと、「社員を定常業務から、より付加価値の高い業務に移行させる」という目的に反することとなり、付加価値の高い業務への移行を阻害することになりかねません。
上記の3点に加えて「重要なデータを扱う際のセキュリティリスクが増大する」「データの二重入力により業務負荷が大きくなるケースがある」「他システムの変更やバージョンアップの影響を受ける」「問題が発生しても表面化しない」「BCP/DRPというリスク管理の対象外となる」等も留意点として挙げられます。
情報システム部門の役割
では、組織がEUCのメリットを享受するために情報システム部門は何をすればいいのでしょうか。
端的に言うと「デメリットをコントロールすること」となりますが、方法としては「ITガバナンスの確保」「技術面での指導」「プラットフォームの提供」が挙げられます。
ただし、それらの前提として、情報システム部門が既存システムの運用・維持に終始するというような守りの業務に追われる状況から脱する必要があります。
また、事業の価値を高めるために必要な業務部門のサポートをするという意識が求められます。
1．ITガバナンスの確保
前章で整理した留意点は全て「ITガバナンス不足」が起因していると言えます。つまり、EUCにおいてもITガバナンスを確保、維持しなければならず、そのために情報システム部門がとるべき対応は「教育と助言」「監査」だと言えます。
教育と助言
ITガバナンスに関する教育の目的は「意識付け」です。そして、それを補足するものが助言だと言えます。前章と重複する部分がありますが、教育と助言のテーマには以下のものがあります。
- EUCの目的や個別要件の明確化の必要性
- コンプライアンス、セキュリティ、情報保護の重要性
- 業務継続、システム継続の必要性
- システム品質、データ品質確保の重要性
- 見えないコストの透明化の必要性
監査
実際の監査を情報システム部門が行うことは時間的にも要員配置の観点からも難しいと思われますので、外部監査の対象に加えることも可能です。
また、情報システム部門としては、上記の全ての項目を細分化し、業務部門に対するアンケート調査を定期的に行うことで、それらの実施状況を確認するとともに、業務部門に注意喚起を行うという方法があります。
しかし、教育、助言、監査というアプローチを業務部門が素直に受け入れるとは限りません。むしろ煙たがられる可能性もあります。
「『情報システム部門はビジネス感覚や業務知識が希薄である』という批判がEUCのきっかけになっている可能性がある」と、「EUC/EUDとは」の章で解説しましたが、その感覚が、情報システム部門が行う教育、助言、監査の障壁となる場合があります。
そのために必要なことは「経営層の理解」です。CIO等上位者を通じ、経営層全体に理解を求めたり、経営層に情報システム部門の考えを伝える手段を持ち、全社的な取組としてITガバナンスを確保することは、情報システム部門にとって重要な課題と言えます。
2．技術面での指導
アクセスコントロール
EUCとして作成された仕組みが「誰が使うべきなのか」という観点が見落とされることが多くあります。
特に共有フォルダ等にその仕組みが格納されている場合などは、誰でもが利用可能な状況となる場合もあり、セキュリティインシデントにつながる可能性があります。
また、その仕組みを「誤って削除する」等の問題が発生することも考えられます。
このような状況に備えるため、情報システム部門では注意喚起だけではなく、共有フォルダ等の管理・利用方法についての技術指導が必要です。
開発ドキュメント、マニュアル、運用ドキュメントの整備
一般的に、業務部門はシステム関連のドキュメントを作成することがありません。しかし、そのことがEUCの属人化を招き、業務やシステムの継続性を阻害する要因にもなります。
情報システム部門はそれらの重要性を説くだけではなく、ドキュメントのテンプレートを提供する等適切なドキュメント整備のためのサポートを行う必要があります。
データバックアップ、システムバックアップ
「データが失われて業務ができない」「EUCの仕組みが壊れて業務がとまった」等の事態が発生することも考えられます。
そのような事態に対応するため、バックアップの必要性について理解を促すとともに適切なバックアップ方法についての指導・助言が求められます。
3．プラットフォームの提供
業務部門の求めるEUCがPC上のオフィスツールだけで進めることができるのか、追加のソフトウェアやデータベースが必要なのかを検討しなければなりません。
追加が必要な場合でも、それらが業務部門の自由裁量でインストールされることがあってはなりません。また、標準と定める以外のものについては規制の対象と考え、情報システム部門が全社的な視点で必要なツールの導入を検討すべきです。
サーバのリソースについても検討する必要があります。特に、大容量のデータを扱う場合や、複雑なクエリを実施する場合は、サーバのリソースを圧迫し、他業務に悪影響を及ぼす可能性があります。
また、情報システム部門の管理下にあるシステムからデータを抽出する必要がある場合等、インターフェースの提供が求められます。その際は、利用目的の明確化が必要になるとともに、参照系としての利用にとどめるガバナンスが必要となります。
技術動向とEUCの範囲
これまで記載したように、EUC発展の歴史はスプレッドシートを中心としたオフィスツールの活用から始まり、マクロ言語、簡易データベースによってEUDの形態となって、ますます広がるようになりました。
また、EUCの範囲ではありませんが、現在、SaaSのようなクラウドサービス、オープンソース(言語、DBMS)やRPA、AI等、業務部門が情報システム部門から離れて、独自にシステムを構築・利用できるような技術も広がっています。
このような流れの中で情報システム部門自身も変化していく必要があります。しかし、そのことを情報システム部門自身やその構成員が十分に認識していないケースや、認識はしていても、行動に移せていないケースも見受けられます。
しかしながら、情報技術が、今後、どのように進歩していくかにかかわらず、ITガバナンスの一部としてのEUCの統制は早急に着手すべきであることは間違いありませんし、それは、技術の変化に左右されないものだと考えます。
まとめ
EUCは古くて新しいテーマですが、技術の進歩やツールの変化に合わせて、その形態も変わってきています。また、DXやイノベーションと言うコンセプトがEUCを後押しする状況にもなっています。
情報システム部門としては、EUCが自分たちの要員不足を補ったり、部門ごとの個別の課題を解決できる可能性があることも視野に入れ、全社的な取り組みとして位置付け、業務部門と一体となって事業を盛り上げていくことが重要です。
そして、その基準となるように、プロアクティブな姿勢でITガバナンスを維持していくことが求められます。
この記事では、情報システム部門の観点からEUCにアプローチしましたが、事業の形態や情報システム部門の体制によっても対応方法は様々です。しかし、EUCに限らずITガバナンスの向上については、経営層の理解を得て、全社的な取り組みとすることが必要であることは間違いありません。
GPTechでは、組織の困りごとや課題に対し、ITガバナンス強化や情報システム部門強化を通して解決を支援します。ぜひお気軽にお問い合わせください。
この記事の編集者
下里 朋子
自治体で情報政策分野を9年間担当した後、IT調達ナビの運営会社である（株）グローバル・パートナーズ・テクノロジーに中途入社。ITコンサルティング業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するメディア運営業務にも携わる。
