ユーザーと情シス，両方の味方 ALZETA

この記事を読んでいただきたい方

* ALZETA を使ってみたいなと思っている人
* ALZETA を使ってみたいんだけどとユーザーに言われたシステム担当の人
* ALZETA でのデータ処理に興味を持っている人

前回は，ALZETA をお使いいただくにあたって，情報システムご担当（以下，情シス）の方に知っていただきたい ALZETA の機能や仕組みについてお話ししました．しかし情シスにとって，新しいソフトウェアを導入するというのは，非常に手間がかかるものです．本当にこれが導入して意味があり，効果が期待できるソフトウェアなのか？また情シス以外の従業員（以下，ユーザー）にとっては，今まで Excel でなんとかなってきたものを，しぶる情シスさんを説得する努力をしてまで導入をお願いするソフトウェアなのか？

ユーザー vs 情シス

その前に，ユーザーさんと情シスさん，関係はどうですか？これまで私がいろんなお客様とお話をしているなかで，ユーザーと情シスが「良い関係だな！」と感じさせてもらったことは，残念ながら少ないと言わざるを得ません．お話を聞いていると，なんだかよそ者が夫婦喧嘩の仲裁に入っているような感じがすることもあります．なので，実は冒頭の「この記事を読んでいただきたい方」に挙げている，「ALZETA を使ってみたいんだけどとユーザーに言われたシステム担当の人」というのは，ほとんどあり得ないシナリオではないかと ^^; 思ったりもするのですが，それはともかく，それぞれお互いに対して抱いている不満は以下のような感じではないでしょうか？

ユーザーの言い分

* 頼んでもどうせ１〜２年もしないと情シスは実現してくれない
* 要望を上げているはずなのに，期待と外れたシステムしかできてこない
* 技術的に実現できない理由を説明されるが，その内容がまったくわからない
* シャドウ IT の撲滅とか言いながら，部門サーバーを取り上げられた

情シスの言い分

* システムのことをわかっていないから，無理な要望を上げてきたり，要件を後出ししてくる
* 関連部門がそれぞれわがままで，要件がまとまらない
* せっかく用意したシステムを全然使ってくれてない
* 部門サーバーを勝手に立てた後，（詳しい人が部門からいなくなったという理由で）運用を激フリされた

Excel に代わり，管理／引継ぎ可能な EUC ツールとして提供／利用できる ALZETA

EUC（End User Computing）は，1997年に社会人になって 2000年に IT 業界デビューした筆者には実はほとんど馴染みのない単語ですが，ユーザーが情シスに依頼することなく，自分で所望の情報処理を作り込んで動かすことを指します．

基幹系システムは，多くの従業員が共通で使用したり，また主要商取引や会計処理でなくてはならないものなので，大きい予算配備をし，情シスの要員を多数アサインして開発，運用にあたります．しかし，会社業務はそういった基幹システムだけで進められるものではなく，一部の部門で一部の従業員が行う多数の個別業務もやはり存在します．ただし，小規模な個別業務は，予算もつけられず情シスの要員も割けませんので，そういった業務のコンピュータ利用は，情シスの手を借りなくて済む EUC に流れます．情シスにとっても，ユーザーが自身でシステム開発をしてくれるのならば手間がかからなくてありがたいことです．EUC の導入によって，ユーザーと情シスの間にあった前述の問題をかなり解決することができます．

その EUC で多くの会社で使われているのが Excel（+VBA）なのです．ただ EUC は本来，情報処理知識の少ないユーザーでもデータ処理が可能であることが望ましいので，文字でプログラムを書かずともデータ処理できるべきです．その点では，VBA を用いた Excel データ処理は，３回目の記事に書いたように実は文字プログラムを書いているので，EUC としてはかなり厄介な代物です．

厄介というのは，個々のユーザーが文字プログラムを書かなければいけないということはもちろんですが，文字プログラムであることから，運用や引継ぎに際して必ず問題が生じてしまうということです．情シスの仕事であれば，成果物であるプログラムには仕様書が必ず（！）存在し，プログラムの変更があれば必ず（！）それが仕様書に反映されていますので，引継ぎが可能な状況になっているはずです．しかしそれをユーザーの個々の VBA 作成の際にルールとして強制できるかというと，現実には無理と言わざるを得ないでしょう．

またもうひとつ厄介なのは，個人レベルではなく，ある程度部門内や部門間の業務で有用な VBA の場合，それがコピーされて流通し，どの従業員に行き渡っているのか把握できないことです．

ALZETA の場合，基本処理をつなげたフローでデータ処理を作成しますので，仕様書が整備されていなくても，その処理内容は簡単に把握することができます．また，データもデータ処理も，その流通は全てサーバー内で行われてログが残りますから，誰にどう使われたかまで調査することができます．

システム構築（要件定義）に使える ALZETA

ALZETA は EUC の位置付けで，ユーザー自らがデータ処理するツールとして使うことができますが，これを発展させると，情シスが提供するシステムを構築する際にも便利に活用いただくことができます．

おそらくシステム構築の上で一番大事で難しいのが要件定義です．ユーザーも情シスも，お互いの発言や主張がすんなりと理解できません．特に，小規模なプロジェクトですと，情シス側の業務理解に大変手間がかかると思います（大規模なコアプロジェクトなら，情シス側にも対象業務を熟知したプロがいるでしょうが）．そうして，相互に全てを理解し合っていない状態で，情シスは設計書を起こしてソフトウェアを開発しますが，ユーザーは設計書をレビューしてもその内容を完全には理解できませんから，結局はそのソフトウェアが完成してからでしか，本当に所望の処理が実装されているかが分からないのです．この問題を解決しようとしているのがアジャイル開発ですが，アジャイルであっても結局ソフトウェアの挙動はユーザーにとってはブラックボックスですので，希望と実装のすり合わせには時間がかかってしまいます．

ここで，ALZETA をプロトタイプ兼要件定義ツールとして使ってください．ユーザーと情シスが同じ ALZETA の画面を見ながら Web 会議でも行えば，
1) 文字プログラムではないこと
2) フローでデータの流れがわかること
3) 中間ファイルプレビューでデータの変化の様子が完全に理解できること
から，ユーザーはデータ処理フローが自分の所望する内容になっているかがわかります．最終的なシステムは ALZETA を使わず Java で開発したりするにせよ，入力データと出力データ確認済みの ALZETA プロトタイプが存在すれば，機能要件上はおそらく失敗しようがないと思います（実際，IPOC がお客様企業の情シスさんの代わりに ALZETA フローを Zoom 会議でユーザーさんと確認しながら作成する，ということも行っており，大成功しています）．

またさらに，EUC としての ALZETA を使いこなしているユーザーであれば，フロー開発までをユーザーが実施し，あとの運用（データ接続や定期実行など）だけを情シスで請け負うという使い方も可能です．

まとめ

ALZETA がユーザーにとっても情シスにとっても有用に使えるツールであり，相互理解にも貢献できることを説明しました．

考えてみればユーザーと情シスの関係に限らず，企業活動のためには複数の部門間の協業や，複数の従業員の共同作業が必要ですが，そのためにやり取りする情報は，もちろん会議，メール，各種コミュニケーションツールでの日本語／英語による口語や文書（あとは見栄えよくまとめられた PowerPoint のスライド？）がほとんどです．ただそれは，共同作業においては残念ながら間接的な情報で，たとえるなら，自転車の乗り方を子供に教えるときに，言葉だけで指示を与えるようなものです．子供のとき自転車の乗り方をどうやって教えてもらったでしょうか？ハンドルやサドルを握って支えてもらったり，ペダルを漕ぐ補助としてサドルに乗ったお尻を押してもらったりしなかったでしょうか？

共同で目的を達成するために，言葉以外の手段を使って，部門と部門，人と人との重なりを増やす糊代のように，互いに理解を深めるツールとして ALZETA を使っていただければ，それは最高の使われ方をしているのかなと考える次第です．