マクロの時代は終わった?マクロを止めるべき6つの理由

最近は、どんどんと新しいシステムや仕組みができています。 様々な会社がサービスを無料で提供していたり、APIなどで部分的な仕組みを提供している事もあります。 しかし、古い企業ほど「マクロ」が業務で多用されているのではないでしょうか。 個人的に、このマクロを継続して業務利用することはおすすめできません。 今回は、そんなマクロの業務利用について見ていきましょう。

マクロは業務で利用するべきではない?

マクロは業務で利用するべきではない?

マクロは業務で利用するべきではない? 冒頭でもお話しましたが、個人的にマクロを業務利用するべきではないと考えています。 確かにマクロは、エクセルのヘビーユーザーからすると非常に便利です。 エクセルを仕事で利用している会社は非常に多いですが、プログラムがわからない人でもエクセルは使えます。 そういった一般ユーザーの入力した情報を元に集計業務やグラフの作成、他のマイクロソフト製品との連携など、様々な事に活用できます。 しかし、このマクロによって多くの業務を自動化すること自体が、企業にとっては大きなリスクになる可能性があるのです。

マクロを止めるべき6つの理由

マクロを止めるべき6つの理由

マクロを止めるべき6つの理由 では、なぜマクロを止めるべきなのか。 その理由について見ていきましょう。

引き継ぎが困難になる

マクロは、プログラミング言語としての位置づけが非常に中途半端であると感じています。 というのも、システムを作る際には、通常データベースを利用して情報を管理します。 しかし、マクロの場合はエクセルのシート内にデータを格納することも多いです。 データベースによるデータ管理は非常に便利で、マスター管理や外部結合などでデータを自由に取得できます。 そのため、わざわざエクセルシートでデータを管理する必要性が有りません。 むしろ、データの読み込み速度や集計速度を考えると、データベース管理の方が優れています。 ですので、プログラムが出来る人間がわざわざマクロを勉強する意味合いは低いと考えられます。 反対に、エクセルを習得していく過程でマクロを勉強する人の割合の方が多いのではないかと考えています。 つまり、 ・プログラマーとしては学ぶ必要性が薄い ・エクセル利用者としては非常にハードルが高い というのが、個人的なマクロの立ち位置になります。 この中途半端な立ち位置のマクロは、すでに他のプログラミング言語を利用できる人間が、ソースを読む位なら少し構文を覚えれば出来るかと思いますが、自由に使うとなるとそれなりの勉強が必要です。 かといって、非エンジニアにマクロを習得させるのはハードルが高い。 これらの理由によって、引き継ぎが非常に困難であると考えられます。

環境の変化に合わせてソースの変更が必要になるケースが多い

作り方にもよりますが、他のファイルを参照するようなマクロは、そのフォルダ構造が非常に重要になるでしょう。 通常のプログラムでも、相対パスや絶対パスで参照先のソースパスを書くことはありますが、ソースは一般ユーザーが触れない場所にあるか、権限的に触れないようになっています。 しかし、マクロの場合はファイル自体がエクセルですので、そのマクロを利用する人が自由にファイルの場所を移動させることもできてしまうのです。 そのため、会社の方針でサーバー内のフォルダ構成が変わるなどの環境の変化に弱いという問題があります。

ローカルPCのスペックを圧迫する

最近のシステムは、多くがクラウド管理になってきています。 そのため、ネット環境さえあればどこにいても利用できます。 このクラウド管理のメリットの1つが、非常に重たい作業であっても、負荷がかかるのはローカルマシンではなく、サーバーという点です。 多くの企業では、ローカルマシンのスペックが高く有りません。 そんな状態の中で、マクロを利用すれば、場合によっては他の業務に支障が出るほどの負荷がかかる可能性があります。 そのため、社内システムをWEBシステムとして構築しておけば、サーバー1台だけを高いスペックにしておき、通常使用するPCは今まで通りのスペックでも問題なく動作します。 そのため、運用面を考えてもマクロは止めるべきなのです。

元ファイルが消えてしまう危険性がある

環境の変化に弱いという話の際に少し出てきましたが、本来システムは管理者以外がファイルを編集・削除する権限が無いのが正常です。 しかし、マクロはエクセルファイルとセットですので、そのファイル自体をユーザーが間違って削除してしまう・・・というような可能性があります。 また、マクロだけではなく、その中に非表示にしてある列に、多数の関数が埋め込まれている場合などもありますが、これらはユーザーの操作ミスや勘違いで消えてしまう可能性があります。 間違って編集してしまった場合でも、マクロが動かなくてエラーメッセージが出れば良いですが、仮に少し計算が違っているものの、動作はする・・・というような場合は、後々大きなトラブルになる危険性もあります。

属人化が進んでしまう

マクロは、通常のプログラムと比較しても、内容が 「ブラックボックス化」 しやすいと言われています。 それは、前述したようにプログラミング言語としての立ち位置が中途半端な事に加えて、セルのデータを活用するなど、データの自由度が高いため、解読に時間がかかるためです。 そのため、 「このマクロの内容はAさんに聞かないとわからない」 というような属人化が進んでしまうと考えられます。 その業務自体をマクロ化してそれほど時間が経っていなければ、手作業でやっていた時の手順自体を把握している人数も多いはずです。 その段階であれば、システム化もしやすいですが、仮に皆が手作業でやっていた時の作業手順を忘れてしまい、マクロに依存している状態になっていれば・・・。 その段階からシステムに移行しようとすると、どうしてもマクロの解読や、マクロを廃止した際にどの程度他の業務に影響が出るのかを調査する必要性が出てきます。

そもそも処理自体が遅い

エクセルファイルをデータベース代わりに利用するようなマクロの場合、データベースでの処理に加えて、単純に処理の速度が遅くなります。 データの量が増えれば増えるほど、その差は大きくなります。 また、前述したようにローカルマシンのスペックの影響を大きく受けます。 そのため、どうしてもサーバーでの処理に比べると時間がかかる可能性が高いです。

マクロを止めるための3つの手順

マクロを止めるための3つの手順

マクロを止めるための3つの手順 エクセルライクな会社では、数え切れないほどのマクロファイルが乱立しているというケースがあります。 では、それらのマクロを止めるためには、どのような手順が必要なのでしょうか。

業務担当者・責任者・業務手順の洗い出し

各業務に関して、担当者と責任者を明確にし、本来の作業手順を洗い出します。 この時の注意点としては、 「元々の作業に、必要のない工程があれば、思い切って削る」 ということです。 マクロでやっている事を、そのままシステムに置き換えても、十分にメリットはありますが、必要が無い仕事をこのタイミングで削ることができれば、システム化以上の価値があります。

一部分ずつをマイクロシステムとして開発

企業によっては、様々な業務をマクロにしているかと思います。 そのマクロを出来るだけ小さい範囲で、システム化していきます。 特に、 「このインプットが来たら、このデータを返す」 というように、小さい単位での仕様を決めたマイクロシステムとして開発するのがおすすめです。 部分的に機能をマイクロシステム化することで、通常業務への影響を最小限に抑えることができます。

業務に支障が出ない部分から徐々にエクセルを削除

1ヶ月程度システムに移行した状態で業務を行い、支障が出ない場合は、関連する次の業務のマイクロシステム化を行い、元のマクロを削除します。 不安な場合は、別の所に一旦保存しておいても良いですが、 「新しいシステムを使用するのが面倒くさい」 という現場の人間がいると、移行に多くの時間を費やしてしまうため、少なくとも一般ユーザーの権限が無いフォルダに格納しておくのが良いでしょう。

本当にやるべきIT化がわからなければAMELAがコンサルティングを行います

本当にやるべきIT化がわからなければAMELAがコンサルティングを行います

本当にやるべきIT化がわからなければAMELAがコンサルティングを行います マクロを使用することは、会社として大きなリスクがあります。 業務スピードが遅くなる事や、属人化した仕事になるために引き継ぎが難しくなることは、変化のスピードが早い現代社会では、非常に大きなリスクです。 特に、クラウド化しているか否かは、業務決定スピードに大きな影響を与える事も多いです。 スマホで色々な情報収集や仕事が出来る様になり、テレワークが盛んになるなど、 「オフィスで仕事をする」 という概念自体が無くなる可能性もあるでしょう。 そういった時代の変化に対応するためにも、是非この機会にマクロを始めとした古い業務をシステム化してみてはいかがでしょうか。 もちろん、従業員への負担や費用もかかります。 しかし、5年後10年後の仕事を考えると、可能な限りシステム化しておくことは、大きな先行投資になるのではないでしょうか。 ITコンサルティングを含めて、AMELAでは様々なシステム運用のサポートを行っています。 少しでも現状の仕事内容を変えたいと考えている方は、是非ご連絡ください。