EUC開発とは・・・そしてその問題点 | システムエンジニアライフ

EUC開発とは・・・そしてその問題点

ヘッダー広告
スポンサードリンク
EUC(End User Computing)とは
名前のままのとおりエンドユーザーが自分達が使うシステムを、自分達自身が開発する。

というものです。
ここで言うエンドユーザーというのは、ユーザー企業の中の実際にシステムを使用する人達のことを表しています。
例えば、銀行なら窓口の人、コンビニだったら各店舗で働く人、飲食店であれば料理を作る人が、自分の作業を効率化するためにシステムを作ることを言います。

通常のシステム開発では、各企業のシステム部門であったり、外部ベンダーに依頼をして開発を行うことが多いと思います。
しかし、自分達が使用するシステムを実際に作業を行う人達が作ったり、もしくはユーザー部門の予算を使用して、システム部門を通さずに直接システムエンジニアを雇って(派遣させて)開発をしてもらうことがEUC開発です。

システム開発

①各ユーザー部門から経営部門へシステム開発要望をあげます。

②経営部門は集まったシステム開発要望から本当に必要だと考えるものをいくつかピックアップする。場合によってはシステム部門の協力を得て、優先順位を考える。

③システム部門を中心に、外部のシステム開発会社へシステム開発の発注する。(ここは場合によってはグループに内のシステム会社の場合もある)

EUC開発


①ユーザー部門は開発したいと考えたときに、そのユーザー自身がシステムの開発を行います。もしくは、ユーザー部門から直接システム開発会社へ発注を行います。

このときに、経営部門・システム部門が及ぼす影響は比較的少ない。

私は以前の職場で、ユーザー部門に派遣され、EUC開発を行っておりました。
その経験から、EUC開発がどのようなものなのか。何のために行われるのか。そして、EUC開発の問題点は何かを記載したいと思います。

EUC開発がどういうものか


①開発環境、開発言語
EUC開発は、ユーザーが開発を行い、そして自分達が使用するため、開発環境は基本的には自分達が使用しているパソコン(ほぼWindowsだと思います)になります。
また、同じ理由から開発言語は多くがEXCELやACCESSのVBAとなります。
時々batファイルを作成したり、VBSを開発したりはあります。
いずれも初心者が操作しやすい環境かつ、覚えやすい言語と言えるため、何か困ったことがあればすぐに開発を行えて、機敏性に優れているといえます。

②案件管理
通常のシステム開発では、各ユーザー部門から集まったシステム開発要望の中から、部門長、システム開発部門、役員などが費用対効果や予算などから、開発対象を決めます。
EUC開発の場合は、本当のユーザーが開発を行っている場合には、各ユーザーが困った時(思いついた時)に開発を行います。
ユーザー部門にEUC開発を行う為のSEがいる場合には、ユーザー部門の中で開発対象の選定を行います。
費用対効果や予算などを意識することは少ない為、発言力のあるチームの開発が優先になりやすいと感じます。

③開発規模、開発体制
EUC開発は、簡易言語を使用していることや、着手のしやすさから、比較的小さな規模の案件が多い傾向にあります。
具体的には1人月未満の開発がほとんどだと思います。
より大きな規模の案件や、外部システムとのファイルの送受信が発生するものや、複数人が同時に更新を行うなどの開発は、外部のベンダーに依頼をして開発を行うことが多いです。
(EUCで開発することもあります)

そのため、私が所属していた現場でのEUC開発は、案件ごとにメインの担当者がいて、基本的には1人で開発を進めていました。
テストだけは、第三者の目線でチェックするために別の人が行っておりました。

また全体としての進捗管理などは、開発者全体での共有や開発リーダーがいましたが、基本的にはそれぞれの案件担当者が責任を持って管理していました。
各案件で進捗に遅れが発生した場合には、その案件のユーザー担当者と話して了承をいただくことで遅れても問題なしとしておりました。

④作成対象成果物
私のいた現場では、設計書の作成も行っておりました。
ただ、基本的には作成しない現場が多いのではと思っております。
私のいた現場で作成していた成果物は、「要件定義書」「外部設計書」「内部設計書」「詳細設計書」と「テストケース」「テストエビデンス」そして、その他「開発申請書」など管理用のドキュメントを作成しておりました。
「要件定義書」や「外部設計書」はある程度しっかり作りますが(とは言っても他の開発と比べると全然少ないです)、「詳細設計書」などは比較的適当であったり、人によっては実際のプログラムと全然違うなどもありました。
ただ詳細設計書を確認するくらいであれば、直接プログラムを見てしまった方が全然早かったりするので、体裁上やシステム監査のために適当に作る人が多かったです。

以上がEUC開発の現場となります。
なんとなく雰囲気は伝わりましたでしょうか?
おそらく他の現場でも大きく変わることは少ないのではないかと思います。

なぜEUC開発を導入するのか


続いて企業側からみたEUC開発を導入するメリットなどを記載します。

開発速度


EUCの導入を行う一番のメリットは、開発速度の部分だと思います。

上記に記載しましたが、外部ベンダーに開発を依頼する場合には、全社の開発要望の中から選ばれなくてはいけないため、システム部門や役員への説明などが不可欠になります。
そこだけでも時間がかかりますが、実際に開発に入ってからも、今度は外部ベンダーへ現状の業務からどのように開発を行いたいのか説明しなくてはいけません。
また、外部ベンダーも品質を担保する必要があるため、十分な(余裕のある)スケジュールで対応を行います。
そのため規模の小さな開発であっても、リリースまで何ヶ月もかかるのが当たり前と言えます。

しかしEUC開発であれば、役員等への説明は不要ですし、近くで業務を見ているSEへの説明となるため開発要望を伝える時間も少なく済みます。(後述します)
開発する期間も1つの案件に集中すれば、ほとんどが1ヶ月以内に完了するものです。
またSEの開発案件が多く余裕がなかったとしても、優先順位も相談しながらすぐに変更できるため、本当に急ぎのものであれば、かなり早く対応可能です。

SEの業務理解


SEはユーザーと同じ場所で働き、普段から同じユーザーの開発を行い、また時にはユーザーの業務を行うこともあるため、ユーザーの業務を深く理解していることが多いです。
SEが業務を理解しているということは、開発にあたっての説明が短時間で終わり、また認識相違が発生する可能性が低くなります。
ウォーターフォール開発において、上流工程でのミスは大きなトラブルにつながりますので、業務理解しやすい環境というのは大きなメリットだと思います。

また開発を行っていく中での不明点も気軽に確認でき、ユーザーにとって求めていたシステムがそのまま作成されるといえるでしょう。

低コストでのシステム導入


EUC開発は低コストであるといえます。
外部ベンダーに開発を依頼すると、1人月100万円、PMには150万円程度かかると考えると、規模の小さな開発であっても、1,000万円を超えてしまうようなものも多々あるかと思います。
しかしEUC開発であれば、プログラムの難易度も低いため、比較的単価の安いエンジニアが集まりやすいと思います。
具体的には、新卒のSEや小さな規模の会社のSEなどを入れて、60万程で集めることも可能です。
また、若手であればプログラミングだけでなく、業務理解も早く、指示にも素直に従うことができ、そして在籍してくれる可能性も高いため、ユーザー企業にとってはかなり嬉しい点だと思います。

また進捗管理は各案件の担当者(ユーザー・SE双方)が行なうため、お金がかかりやすいPMは多くの場合不要となります。

上記の理由から、EUC開発では、開発コストを低く抑えて業務効率化を図ることが出来るといえます。

SEにとっての利点


EUC開発は、SEにとっても利点があると考えています。
①開発の感覚をつかむことが出来る
EUC開発は比較的難易度の低いプログラミング言語を使用しているため、プログラミング経験の浅い人や苦手な人には最適な現場であるといえます。
また、一人で開発を完結させることが求められるため、要件定義~テストまでの全ての工程を経験することが出来ます。

②ユーザー業務を理解出来る
実際の業務を行う方々と一緒に働けるため、業務理解が深まります。
ある程度同じ現場にいれば、同じ会社の人のように比較的気軽に話しかけられるので、他の現場ではなかなか身につかない業務の深い部分まで理解出来ると考えております。
これは私達SEにとっては大きな利点で、業務理解があればあるほど重宝される人材であることは間違いないです。

③ユーザー企業の方々と親しくなる
一緒の場所で働いているので、当然普段からコミニケーションを多くとります。
また飲み会などにも呼んでいただけるので、ユーザー企業の方々とはとても仲良くなれます。
私は転職した今もそこで出会った方々の飲み会に呼んでいただいております。

仲良くなることで、ユーザー側が何を考えているのか。困っていることは何か。今後その業界がどう変化していきそうなのか。
など伺うことができ、仕事に大きく役立つと考えております。

④様々な取り組みができる
これは現場の雰囲気や、個人の能力、やる気にもよるのですが、やろうと思えば様々な取り組みを主体的に行うことが可能です。
ユーザーの方々はITに関する部分はある程度任せてくれると思います。
そのため私達SEは、比較的自由に色々なことを実施することが出来ます。
例えば私が行った活動としては、設計書のフォーマットを整えたり、開発のフローを変更したり、ユーザーの業務フローを大きく変えるような提案(コンサル的なもの)を行ったりしました。
このような取り組みを行うことで、ユーザー側も喜んでいただけますし、SEとしても良い経験となります。

以上のような点が、SEにとっての利点と考えております。

EUC開発の問題点


上記まででどちらかといえばEUC開発の良い点をあげたつもりですが、反対に問題だと思う点もいくつかあります。

保守性の悪さ


これはEUCで起こりやすい問題としてよくあげられますが、EUC開発では1人で開発することが多く、また開発後も開発した人自身が修正を行うことがほとんどだと思います。
その為、その人自身はドキュメントを作成しなくてもある程度把握出来るため、きちんとしたドキュメントを作成しようという意識が低いもしくは、ドキュメントを作成しようとはしていないことがほとんどだと思います。
また上記と同じ理由で、詳細は後述しますが、プログラム自体も後々の保守性を考えた作りになっていないことがほとんどだと思います。

このような状態では、作成者が異動などでいなくなってしまった際に、どのように修正を行えば良いのか、そもそもなぜそのようなロジックになっているのかまでわからなくなってしまいます。

私自身ここには大変苦しめられた経験があります。
前任者が作成したシステムのドキュメントが残されていないということは、システムの利用者に対して、現状の業務内容をヒアリングしなくてはいけません。
本来であれば、今回システムで実現したいことを中心にヒアリングを行いたいのに、それ以前の業務内容の確認を行う時間に多くかかりすぎてしまいます。
また、ユーザー側もシステムの中身を忘れてしまうこともあり、ドキュメントがないということは相当苦労することになります。

品質の悪さ


EUC開発では品質が悪くなりやすいと感じます。
ここでいう品質というのは、作成されたシステムの中身(プログラム)の問題です。

システムは、プログラミング初心者が作成することが多く、行き当たりばったりで作って、動いたからそれでよしとしたり、ネットでみたコードがそのまま使用されているなど、かなり煩雑とした読みにくいコードとなっていることが多いです。
開発担当者はリファクタリングによる動作速度の向上や、保守性への意識などが低いと考えています。

EUC開発を導入するのであれば、いかにして品質をあげるのかを考えないといけないと思います。

スケジュール通りに進まない


受託型のSeirにいると、スケジュールに対する意識はかなり高く、少しでも遅れると大きな問題となることが多いですが、EUC開発では異なります。

私が経験した中では、1年以上も完了予定をオーバーしたものなんかもあります。
システムを使うエンドユーザー、システム開発者だけでスケジュールを管理しているため、当初に立てた予定がなぁなぁになりやすいのだと考えます。

EUC開発で、緊急性の高い開発を行うことは少なく、多少手間はかかったとしてもシステムを使わなくても同じことは出来るという案件が多いため、SE、ユーザーどちら側からもスケジュールに対する意識は低いです。
また、エンドユーザーと近い距離にいるため、仲良くなりすぎてしまい、簡単にスケジュールを変更出来ることもスケジュールが遅れる原因です。

ユーザーにとって効果の高いシステムが少ない


私はこれがEUCにとっての一番の問題だと考えています。

本来システム開発というのは、企業が利益を出して成長していくために、必要だと判断されて導入されるものです。
近年では、経営の三大要素である「人」、「もの」、「金」に加えて、「情報システム」も重要だと考えられています。
そのために、企業は大変高いお金を使って、本当に必要なシステムに経費をかけて開発しているのです。

しかしEUC開発は、ユーザー部門に開発の管理を任せてしまっていることが多いため、本当にかけるべきところにお金をかけているか見えにくくなっています。
またユーザー部門でも、現場の担当者が必要だと強く言うならば、そこをシステム化しようと考えてしまうので、それより先の本当に一番必要なところ(効果の高いところ)に着手出来ず、無駄なお金を使っているのではと考えます。

ここの部分はまだまだ伝えたいことが多くあるので、別記事にてお伝え致します。

ここからはSE側からみた問題点を記載します。

SEとして成長出来ない


EUC開発を行っているSEの一番の問題点は、このSEとしての成長が止まってしまうことだと思います。

EUC開発は簡単な言語開発を行うので、新人でも早期に習得できます。
VBAなんかは、ネットを漁ればすぐに書き方が分かりますし、コピペでほとんどのことが出来てしまいます。
そのことから、それ以上深くまで理解しようとせず、前に作ったロジックを永遠同じように書いていくことが多いです。

また、今後市場価値を挙げていきたい場合に、VBAしかやっていないようであれば、なかなか単価を上げにくいと思います。
実際私の転職の際も、VBAしかやっていないことで、多くの企業からシステムスキル面での能力が不安だと言われ、今までの経験に対して残念だと言われていました。

これはSEとして成長出来る機会、市場価値をあげるチャンスを捨ててしまっていると言えるのではないでしょうか?

EUCでは全ての工程を経験でき、若いうちからユーザーの方と接する機会も多くあり、学ぶことも多いのは間違いないとは思いますが、システム開発者としての市場価値は上がっているとは言いにくいです。
そういう現場にいながらも、いかに成長出来るのか、何をすればお客様から喜んでもらえるのかを考えて行動していくことが、SEとしての成長に繋がります。

ちなみに上記ではプログラミングスキルのみを記載しましたが、開発工程も結構適当で、各現場ごとにガラパゴス化している部分も多いと思ってます。

他にも、派遣契約が多く下請けを使えない、元々の単価が低く何年もいることを求められるなどの理由から、利益が出にくい。SE自身あまりスキルが身につかないことが分かっているため、モチベーションが低く、色々変えようという意識が低いなどの問題もあると考えています。

これらの多数の問題点から、私個人としては企業にとってEUC開発は導入すべきではないと判断しています。
本来のシステム開発と比較し、1つ1つのシステムで見れば比較的安い金額で開発を行えます。
しかし、開発した多くのシステムが費用に見合う効果が表れる前に、使われなくなるシステムが多くあり、結局トータルで考えると大きな損失となっているのではないでしょうか。

それでも、普段の定常作業にとても時間がかかっているなどの理由から、EUCをどうしても導入したい場合にはどうすればよいでしょうか?
EUC開発のメリットを引き出すためにどのようにすればよいのかを考えました。

問題点への対策


SEを雇いすぎない


SEを多数雇うことで多くの案件を対応することが可能ですが、案件のほとんどは効果の低いものがほとんどです。
多くのSEを雇って多くの案件を対応するのではなく、少ない人数の厳選されたSEが費用対効果の高いシステムを開発することがEUC開発で費用対効果を最大限あげる方法の一つだと考えています。

システム導入後の効果測定


これはEUC開発に限らずだと思っておりますが、システム開発後の定期的な効果測定がかなり重要だと考えています。
ほとんどのケースは、システムを開発してから実際に使用してみて、なんとなく効果があるなぁ。ないなぁ。程度の測定しか行っていないか、なんとなくルールとしてあるから効果を記載するというようなものだと思います。

しかしシステム開発には大きな金額がかかっていて、その一つ一つのシステムが経営の成否を大きく左右すると言って間違いないと思います。
人がシステムを開発している以上、時には役に立たないシステム、思った以上に効果の出ないシステムというのは時折出てくると思います。
だからこそそういったシステムを減らしていき、より費用対効果の高いシステムを多く作るためにも、開発後の定期的な効果測定と、その結果に基づいた対応をしていく必要があるのです。

どんなに小さな規模の開発であっても、システム開発を行うということはなにか目的があって行われていて、その目的を達成するために予算をかけているので、効果測定を行いシステムの価値を図っていくことが重要です。

するとそのうち、効果が高くないものは一旦開発しないとなり、本当に効果の高い部分により多くの開発する時間が使えます。

システム部門による監査の導入


EUC開発ではシステム開発が各SE個人任せになってしまうことが多く、後々の保守性が低下してしまうことが問題になりやすいため、会社全体としてシステム部門主導によるシステム監査を行うことが望ましいです。
具体的には、ドキュメントの整備状況を確認し、ドキュメントはそろっているか、他の人にも分かりやすいドキュメントなのか、コードとソースは一致しているかを確認したり、ソースコードがルールに従っているか、読みやすいコードかなどを行うことです。

実際に私が所属していた企業でも、定期的なシステム監査を実施しており、ドキュメントの提出やチェック等がシステム部門の指示によって行われておりました。

ただ、決まりとしてやっている感覚になっていたので、そうならないようシステム部門がもっとEUC開発に対して問題意識をもって、より具体的な対策を実施する必要があると考えております。

以上が、私が考えるEUCを導入する場合に、問題を少なく方法となります。

EUC開発については、私も働く中で色々と感じて危機感や問題意識を感じながら転職してきたので、この後も様々なことを記事にしたいと思います。

システム開発を行うものとして、自分達が作ったシステムが企業(社会)の役に立てるように、どのようにするのが正解なのか日々考えながら業務を行っていきたいと考えています。

今EUC開発を取り入れている企業やEUC開発を行っているSEには、今回の部分を考えてもらいながらよりよい解決策を見つけてもらいたいと考えております。

以上、若手SEが未熟ながら生意気な意見を言わせていただきました。
フッター広告

スポンサードリンク



シェアする

  • このエントリーをはてなブックマークに追加

フォローする