どうでもいいプログラム研究所

とある編集者によるIT、Web、ソフトウェア、プログラミングに関する雑記と覚え書き

情シスから嫌われないエンドユーザーコンピューティングのために

f:id:tdyu5021:20210207231150p:plain

情シスではなくエンドユーザー自身でプログラムを作って業務を効率化することをエンドユーザーコンピューティング(EUC)といいます。エンドユーザーにITのスキルがあれば会社にとって大きなメリットですが、本当に問題点はないのでしょうか。エンドユーザーと情シスの関係性で私が感じたことを書きます。

エンドユーザーコンピューティングの再来か

一般的に会社は情シス部門みたいなところがITツールの運用だったりプログラム開発を行っていますが、EUCという言葉があるように業務部門の1ユーザーが自分でプログラムを開発したりして業務を効率化しているケースもあります。

ちなみに私は5年前から現職(IT業界専門の制作会社)に転職し、IT業界を取材し続けていますが、実際のところ最近はこの言葉はあまり使われていないようです。この用語で検索しても過去の記事がたくさんヒットしますし、取材の中で「EUC」という言葉を言及する人は割と上の世代が多い印象です。

EUCの定義は私も厳密には把握しておらず間違っているかもしれませんが、最近は改めてEUCの流れが来ているように思います。

というのも、最近はエンドユーザーがITを取り入れるハードルは明らかに下がっています。Twitterを見ていると、直近では「ノーコード/ローコード」も頻繁にタイムラインに流れてくるので、これからそうしたツールはますます流行ってくるでしょう。DXの流れもあり、ノンプログラマーシステム開発に携わるチャンスは増えてくるかもしれません。

IT製品導入だって情シスのお世話にならずとも、いまや勝手にクラウドサービスを契約して利用することだってできます(シャドーITの別の問題が出てきますが)

あと、これは目新しいものではありませんが、どの人のパソコンにも入っているExcelでもVBAを使ってれっきとしたプログラミングができます。持っているユーザーは限られそうですが、Accessなどを使っても簡易的なシステムが作れます。

エンドユーザーコンピューティングにデメリットはないのか

Excel VBAによって業務を効率化した話はちまたに腐るほどありますし、そのメリットはいまさら語る必要もないでしょう。エンドユーザーがプログラムをわかっているに越したことはありません。ただ今日の記事の本題はその先です。

エンドユーザーがプログラムを作れることが当たり前の時代になったとき、どのような問題がでてくるかということです。

問題の1つは「シャドーIT」のリスクです。シャドーITとは広義には情報シスの管轄になくユーザー自身が業務で勝手に利用しているITのことです。わかりやすい例として「会社で正式認められていないが勝手にSlackを導入してチーム内のコミュニケーションに使っている」というのがあります。自分で密かにプログラム開発しているというのもその例です。

Slack程度なら会社内で許可をもらうことはそこまで難しくないかもしれません。もっとたちの悪い狭義のシャドーITは、商用利用前提でないものを業務で使うことです。例えば「私用のスマホの個人LINEで業務連絡する」というイメージです。

シャドーITを問題だとに認識するのはほぼ100%情シス部門です。一方で現場で勝手にシステムを作ったり使ったりする当のエンドユーザー本人はほぼこの問題に関心はないでしょう。

それも無理はありません。会社全体のITを管理下に置きたいのが情報システム部門の思いですが、エンドユーザーからしてみたら「自分の周辺の業務が効率化できればいい」というくらいにしか思っていないからです。

ですが、そうした感覚は非常に危険であり、今すぐにでも是正されなければならないと私は考えています。その理由は次の項で書きます。

とばっちりを受ける情シス

そもそも、エンドユーザーが勝手にシステムを導入したりプログラムを開発した場合、「その面倒を誰が見るのか」という話がつきまといます。いわゆる運用の問題です。もしEUCによって導入されたプログラムが社内に広まったとき、開発者はエンドユーザーであるにもかかわらず、付随する問題が生じて情シスに質問が寄せられるケースは往々にして存在します。

情シスからしてみたら「なんで自分がこの問い合わせ対応しないといけないんだよ」と思うわけです。ほかの人が勝手に始めたIT活用で自分の仕事が増えたらたまったものではありません。

もう1つがトラブルの対応です。情シスが絡んでいないシステムやプログラムに何か問題があり、それによって業務に影響が出たとします。Excel VBA程度ではあまりない思いますが、もしセキュリティの事故が発生したら、会社への影響は大きなものです。

ですが、そのときに情シスとしては「このプログラムはエンドユーザーが勝手に入れたものだから私たちは知らない」とは簡単にいかないわけです。情状酌量くらいにはなるかもしれませんが、情報システムに関する尻拭いは残念ながら情シスなのです。

つまるところ、EUCによってプログラムが作られたとき、それに対する責任が取れなければ社内に逆にいろんなところに迷惑になってしまう可能性があるというのが問題点なのです。

こうしたリスクを指摘したところで、実際には当のエンドユーザー本人の心にはそこまで響かないでしょう。会社全体や情シスに起こりうるリスクへの良心の呵責が大きければ響くかもしれませんが、現実的にそれは、リスクを気にせず勝手なシャドーITを入れて業務効率化するメリットを上回ることはないでしょう。

「会社の全体最適を目指すべき」とか「情報システム部門に迷惑をかけてはいけない」などの正論ではなく、自分の仕事やその回りの業務が楽になるかという自分へのメリットがあるかどうかの判断で人は動いてしまいます。

ここで念のため付け加えますが、もちろん情シスの統制の範囲内にあり、セキュリティリスクのない簡易かつ自分自身の業務を効率化する用途のVBAのプログラム程度であれば問題ありません。ここで私が想定しているのは、情シスが管理していなく、なおかつ社内のいろんな人がそのプログラムを使って、それがないと業務が回らないようなものを想定しています。

エンドユーザーが知っておくべきこと

ただ、エンドユーザーとしては短期的には業務効率化ができたとしても、長い目で見て自分に跳ね返ってくるデメリットもあります。とっつきやすいエンドユーザーのプログラミングとしてExcel VBAを例に考えてみましょう。

いくら自分が業務を効率化してメリットがあったからといって、それが間接的に情シスの迷惑となったらどうでしょうか。そしてそれが世の中のいろんな企業で起こっていたとしたらどうでしょうか。

結局「Excel VBA」はいつまで経っても「中途半端なシステム」として情シスやプログラマー界隈からないがしろにされるだけです。Excel VBAは正しく扱い、特定の用途には効果を発揮します。しかし、その領域をわきまえずそれで何でもそれで構築しようとすると、エンタープライズのシステムではどこかで限界が生じます。

それはいろんな企業のシステム導入事例で「脱Excel」というスローガンが叫ばれていることからもよくわかります。(※注:脱Excelは、VBAピンポイントの話ではなくワークシートでの情報管理から脱却する、という話が多いですが)

Excel VBAが嫌われてしまう理由

情シスだったりプログラマーの人からの意見として、Excel VBAは低い評価を受けることがあります。それはExcel VBAプログラミング言語として貧弱だからという単純な理由だけではないと私は考えています。

ネガティブな印象が出る理由として私が推測するに、おそらくExcel VBAとは、「ITがわからないところに1人だけVBAがよくできる人がいて、その人がどんどん1人で開発していった」というシーンで使われやすいことに関係があると感じています。

これはどういうことか、次のような流れを考えてみましょう。

まずVBA愛用者(VBAer)は、ITがわからない従業員ばかりの職場の中でバリバリ開発してヒーローのような存在になったとします。しかし、それは本格的なシステム開発をしていたり、全社最適なシステムを考える人達にとって中途半端な部分最適なシステムに見えてしまう可能性があります。

そのVBAerもせいぜい「セミプロ」のような存在に映ってしまうかもしれません(もちろんスキルによります)。

ですが、当のVBAer本人はIT音痴な職場を救った達成感や使命感に誇りを持つわけです。そしてそういう人は「情シスに頼らなくても、この部署のIT化は俺がなんとかする!」と思うに違いありません。

こうした「詳しい自分1人でなんとかする」タイプのエンドユーザーが、全体最適のITシステムと相容れないことは想像に難くないでしょう。こうして生まれたプログラムは部分最適を突っ走る形になり、それによってExcel VBAも煙たがられるのだと私は思います。

よくExcel VBAは「属人化しやすいからダメ」という批判があります。それに対する反論として「属人化するリスクはほかの言語でも変わらない」という意見があります。この反論は確かにもっともだと思うのに、なぜExcel VBAだけが属人化批判のやり玉に挙げられてしまうのでしょうか。

それは言語自体の問題ではなく、まさに上に書いた「俺1人でなんとかする」タイプの人(特にエンドユーザー)によってExcel VBAが愛されるせいで、不運なことにもExcel VBAにそういう印象ができてしまった偏見と先入観の問題、というのが私の見解です。

エンドユーザーはどんなマインドを持つべきか

ですから、プログラムができるエンドユーザーにとって、情シスのことを考えなくても自分の業務効率化には関係ないから気にしなくてよい、と考えるのは長い目で見て得策ではありません。

つまり、業務効率化をしようという意識は、辺にプロ意識を持つことで全体最適を考える情報システム部門からは煙たがられてしまい、皮肉なことにもVBA使いであったとしたら、自分の誇りにしているVBAの評価すら下がってしまいかねないからです。

VBAに限らず自身が使用して頑張っているものに対する世の中からの評価が下がってしまうのは悲しいことではないでしょうか。

ではどうすればよいのか。私は情シス担当者でもありませんし、コンサルでもありませんが、おそらくきっと大事であるだろうと信じていることをまとめてみます。

情シスを理解しようとする

EUCを実践するエンドユーザーだって、情シスだってITを使って社内を効率化しようと考えている点で同じです。つまり同志であるはずです。それぞれ対話もないまま独自の取り組みが進んでしまうから、どんどん溝が深くなってしまうのだろうと思います。

これは世の常ですが、エンタープラズシステムの構築において、エンドユーザーが重要だと考えていることと、情シスが重要だと考えていることは必ずどこかに乖離があります。対話がなければその乖離はどんどん広がります。

このことは先日このブログで書いた以下の記事のTwitterの一連のいざこざで強く感じたことです。この物議を醸し出した元ツイートへの引用リツイートを見ると、エンドユーザーと情シスの間で明確に意見が違うことが見て取れます。

tdyu.hatenablog.jp

だからこそ真剣に話し合える環境は必ずお互いのために役立つはずだろうと考えています。

相手のためを思う

いざ情シスと対話するときに、EUC担当は「業務を効率化したい」という思いから「情シスがなんとかしてくれよ」という意図がにじみ出てしまうかもしれません。これが危惧すべきことです。シャドーIT的なことをやっていたり、もしくはEUCで頑張っているということは、裏を返せば情シスがITを整備してくれていないからそうなっているはずです。

つまり、EUCが業務効率化への思いを吐き出す対話の機会があるとしたら、それは高確率で「情シスへの不満」がにじみ出てしまいます。こうなってしまえば対話の空気感は非常にまずくなってしまいます。

しかし、EUC担当と情シスは同志であるはずです。EUC担当側としては「情シスができないなら自分たちで何かできることはないか。情シスが忙しくてできないならリソースをお互い分け合ってできる効率化の仕組みがないか」という対話の仕方をするべきではないかと私は考えています。

システムと業務のトレードオフを理解する

あと、「情シスがITを整備してくれていないからそうなっているはず」と書きましたが、そこには情シス側の事情があります。情シス側がどうにかしたいと思っていたとしても、社員が多ければエンドユーザー全員が楽になるシステムなどそうそうありません。

経営者や情シスにとって便利なシステムを導入したら現場のシステム操作の負担が重くなったなどしょっちゅうあることです。それは仕方ない、ということを私は言いたいのではなく、エンドユーザーは「情報システムはどこかで必ずトレードオフがあるということを理解するべき」ということです。この前提がわかっていないと全体最適なシステムなど作れません。

また、そもそもの話として、単にエンドユーザーが困っているということを情シスが把握していない可能性があります。この場合は情シスに文句をつける前にまずは要望を伝えることから始めなければなりませんが、とにかくお互いが対話するしかないと思います。

情シスを便利屋と思ってはいけない

エンドユーザー自身として「自分が何ができるか」と考えることは、エンドユーザーと情シスの関係に限ったことではありません。当たり前の話ですが、人に何かをしてもらいたいときに、一方的にこちらの要求をつきつけてもうまくいくはずがありません。本気で何かを変えたいのなら、自分もしっかり汗を流すこと、相手がやりやすいようにこちらからも何かできることを提示するべきではないでしょうか。

しかし残念なことに、ITシステムとはインフラのようなものになり、「動いて当たり前」の世界になってしまいました。これは喜ばしいことですが、それに携わる人にとっては悲しい一面もあります。

インターネットがつながって当たり前、PCのトラブルは直ぐに解決できて当たり前……残酷なことに情シスに対しても「社員を助けてくれて当たり前」のように知らぬ間に思ってしまうわけです。

システム導入についても「要件さえいえばあとは情シスが勝手に整備してくれる」と思っている人すらいるでしょう。もっと最悪のケースは「要件もシステム作る人が考えてよ」という思考です。

しかし、そんな態度をする人に優しくできる人間などこの世にいないでしょう。ですから、情シスを「便利屋」のようにこき使うのではなく、労いを持って接するべきではないかと思っています。

まとめ

だらだら長くなり、最後EUCとも少し離れましたが、ここで言いたかったのは以下の4点です。

  1. EUCによる独自プログラムは、業務の属人化や「シャドーIT化」が発生しリスクとなる可能性がある。
  2. 独自にプログラムを組めるEUC担当は、使命感と自尊心が変な方向にいくと、IT部門と相容れない存在となる可能性がある。それはExcel VBAでも起きやすい。
  3. だからこそEUC担当と情シスは対話と連携を行うべき。
  4. その際にエンドユーザー側としては情シスに「助けてもらう」という姿勢ではなく、双方にメリットのあるITによる業務効率化を実現できるように、エンドユーザー側でできることはないか、という相手を思う視点を持つべき。情シスはエンドユーザーのために都合よく動いてくれる便利屋だと思ってはいけない

私もユーザー部門のIT導入や情シスの声を取材し続けてきた外野の人間でしかないので、的はずれなこともあるかもしれませんが、ひとまず私が感じたことをまとめてみました。