つぶやきソリュエイ（9月24日）「EUCの効果的な活用」

本日のつぶやき
固定化した要件はパッケージで試行的流動的要件はEUCで実現させる組み合わせが業務システム活用の最適解

長い期間、膨大な費用を費やして業務システムを導入するも、関連業務すべてをシステムに組み込むができず、エンドユーザコンピューティング（利用者によるシステム開発・運用、以下EUC）に頼っているという状況はどんな会社にも見られると思います。なぜそのようなことになるのか？パッケージ利用、スクラッチ開発とどちらにしても大きくは以下の理由の組み合わせかと思います。 

①自社に合わないパッケージを選択した
自社の事業が先進的で同業他社がいないなどの理由で、もともとその業界向けのパッケージシステムがない、もしくは少なくて、類似他業種向けのパッケージを無理やり利用した場合や、実際は最適なパッケージが他にあったのに見つけることができなかった、社内政治等でそのパッケージを選択できなかったなどの理由で自社システム化要件をすべてカバーしきれないパッケージシステムを選択した結果、システム外管理業務が増えてしまう状況です。

②要求がパッケージで対応できないほど特殊
最近のパッケージシステムはかなり汎用的にユーザのアウトプット要求に応えられるよう進化してきていますが、それでもすべてのユーザの要求に対応できるわけではなく、営業がその時勢に合わせて（もしくは単なる思い付きで）作った価格決定ロジックや経営者が要求する複雑な条件分岐の結果算出される採算管理表などがこのパターンです。

 ③開発の予算がとれない
①②の場合でもスクラッチ開発でも、人間が想像してルール化できる以上、潤沢な予算と期間があれば（良し悪しはともかくとして）すべてのシステム化要望の実現はできます。しかし、たいていの企業ではシステム化予算は限られており、特定の人しか利用しない、要求していることが利益に結び付くと思えないと判断された場合は、仮に要求者がどれだけ切に願っても、開発予算が取れません。とくにパッケージを利用していてアドオン開発でこのような特殊な要件をシステム化するのは採算性が非常に悪いため高額な金額を提示される場合が多くますます実現が難しくなります。

これらの理由により、現実的にはEUCをなくすことはほぼ不可能に近く、ベンダー提供のシステムとEUCをうまく組み合わせて運用することが求められます。この時に問題になるのは、ベンダー提供システムとEUCの切り分けです。以下にベンダー側に開発を依頼した方が良いポイントを示します。
・ベンダー提供システムのデータを変更する機能はベンダーに依頼する。
→ユーザ側で勝手にデータを変えてしまうと保守が受けられなります。追加するだけならよいかと思うかもしれませんが、どんなデータが追加されるかわからない状況ではベンダーは適切の保守ができないのでこちらもお勧めしません。例外としてあるのはデータの取り込み口がベンダー提供機能として用意されていて、その手前でデータを成形する場合です。
・アウトプットする情報、帳票で継続的に利用することが確定できるものはベンダーに依頼した方が良い
→ベンダーがサポートしてくれる、一つのシステムから出力できることはユーザ側にもメリットがあります。
したがってEUCで対応するのは、（上記例外を除けば）特殊かつ試行的データ活用に絞られます。経営者や管理者が時勢に基づきいろいろな角度から分析したいといったときです。このように一過性のものはEUCで対応し、固定化されたものをベンダーに開発依頼する が一番リーズナブルな活用と思います。

これらのことから、EUC（エンドユーザーコンピューティング）は自由度が高く、比較的開発が容易にできるものがよく、Excel VBAやAccess、その他ノ（ロ）ーコードツールあたりがそれにあたるかと思います。そして、EUCは必須だということを理解したうえで ユーザ企業の経営者の方々にはもっとこれらを扱える人材を育成、活用するとともに、評価していただきたいです。