VBAはオワコンなのか?

VBAがオワコンなのか?という話題がTwitterで流れていたので、私の考えを纏めておこうと思う。

VBAの生い立ち

Visual Basic for Applications(以下VBA)の話しをするときに、Visual Basic(以下VB)のことを抜きにすることはできません。VBAは、いまはサポートが終了しているVBという開発言語を元にして生まれました。VBは、いまもMicrosoftが提供しているVisual Basic.NET(以下VB.NET)とはまったく異なる開発言語です。VBはWindows専用の開発言語として広く支持を集めました。その開発の平易さから、特に受託開発の現場で多く使われてきました。利用者がが増えれば、対応する事業者も増えます。多くのサードベンダーがVB用のコンポーネントを提供しており、当時としては開発しやすい環境が整っていたのです。

VB最後のバージョンとなるVB6.0はComponent Object Model(以下COM)に準拠し、Microsoft開発言語の中核となりました。どのような言語であってもにCOMに準拠したコードを書けば、使用する言語によらず機能を呼び出せるようになります。オーバーヘッドも比較的小さく、単にライブラリを呼び出せるだけでは無く、プロセス間の通信や、ネットワークを介してサーバー間の呼び出しも行えるものでした。多くのコンポーネントがCOMに準拠したものに置き換わり、様々なサードベンダーが提供するようになっていきました。

ところがその後にCOMの欠点が問題になっていきます。VB 6.0の発売された1998年はインターネットの黎明期にあたりました。今ほどセキュリティへの要求は厳しくない時代に設計されたため、セキュリティへの設計面での配慮がほとんど無かったのです。Microsoftはその後に多くのセキュリティ問題に苦しむことになります。

VB 6.0の発売から4年後、セキュリティを強化して再設計したVB.NET 7.0がリリースされます。Microsoftはそれまで、二年ごとに新バージョンを提供していたことを考えると、相当に苦労したことがうかがえます。ですがVB.NETにはVB6.0との互換性は全くありませんでした。互換性の問題からVB6.0からVB.NET7.0への移行は進まず、Windows 11となった今もVB6.0のランタイムライブラリがOSと共に提供され続けています。

VB.NET7.0が発表された後、当然ながらVBAについても多くの議論が巻き起こりました。セキュリティを考慮するならVB.NET7.0を基礎としたものに作り替えた方が良いのは分かっています。でも現実問題として互換性の全くない言語への移行は困難を極めるのは明らかでした。それに対する結論として現在の状況があります。

MicrosoftはVBAはその互換性を維持して提供し続けることを選択しました。同時に、セキュリティの問題に対応するためにデフォルト設定ではマクロ機能を無効にし、また電子署名を付けた出所の明確なマクロ以外では警告を表示するようにしました。拡張子もxlsx(マクロ無し)とxlsmx(マクロ有り)と分ける事でユーザーがマクロの有無を意識しやすくしました。ユーザーはマクロを利用するために設定を変更する事になりますが、それに伴うリスクはユーザーが負うものとなりました。

最近でもセキュリティ強化は続いていて、インターネットからダウンロードしたファイルや、共有フォルダ上のファイルについては、デフォルトではマクロが実行されないような改善が行われています。

VBAに変わる機能を提供する試みも繰り返し行われています。ファイル仕様が公開されオープン化したことにより、xlsxファイルを編集する事のできるライブラリが様々な言語で利用できるようになりました。またOffice製品を操作するために、Microsoft Office Interop、Visual Studio Tools for Office、Apps for Office、Excel REST APIと何度か新たなツールを提供を試みていますが普及には至っていません。Windows OSに比較的容易に使える開発言語としてPythonを組み込むと言ったことも行われています。最近あらたに提供しているのはPower Automateですね。

VBAを使い続ける事の何が問題なのか?

セキュリティ上のリスク

マクロの実行を許可することに伴ってキュリティリスクが発生します。VBAが含まれたファイルがコンピューターウィルスの感染経路となっている事は知られていることと思います。リスクを認識して電子署名の無いマクロの実行を禁止する等の対策を取っているなら良いのでしょう。ですが、VBAを使っている企業では利便性を優先して、どんなマクロも実行許可しているのが実情でしょう。

機能面の貧弱さ

VB6.0の頃には様々なベンダーがCOMコンポーネントを提供していました。これにより2008年頃までは拡張性の高いパワフルな言語となっていましたが、今は殆どのベンダーがCOMコンポーネントの提供から撤退しています。VBAで出来る事が縮小していっているのが実態です。

VBAの言語機能どのものの拡張も20年単位で行われていません。この20年間で多くの言語に取り込まれてきたような機能、完全なオブジェクト指向や無名関数、並列化などの機能が追加される見込は無いでしょう。ソースコード管理システムとの連携が極めて困難なのも生産性を大きく下げてしまいます。

本当に何処でも実行出来るのか?

VBAを利用する理由のひとつに「Excelはどのパソコンにもインストールされており、どのパソコンでも利用できる」というのが有る。Microsoftはサブスクリプションモデルへの移行を目指しており、従来の買切り型ライセンスのOffice製品は2025年でサポートを終了することになっている。現在はデバイスライセンス下で複数の従業員が共有しているパソコンについても、2025年移行はユーザーライセンスに移行する事が求められる。例え利用時間が月に30分でも、アルバイトが20人いれば20ライセンスを購入することになるが、はたして購入し続けるだろうか?

また年々セキュリティ意識が高まっていく中、VBAを実行するためにセキュリティ設定を緩めて貰う事が、いつまで受け入れられるでしょうか?VBAを完全に禁止している会社も少なからずあるのが実情です。

またランタイムを追加で導入する必要が無く、何処でも実行可能であることがVBAを選択する理由なら、JavaScriptでもPythonでも良いはずです。

VBAを使い続ける上で必要なこと

VBAを使い続ける上で必要なことは、リスクを正しく認識する事だと考えて居ます。以下の様な問題があることを踏まえた上で、バランスを取りつつVBAと付き合っていく必要があるわけです。

  • VBAを使うためにセキュリティリスクを高めていること。
  • VBAの生産性を高めるような言語機能の拡張は20年ほど行われておらず、多言語と比較して生産性の低い開発言語となりつつあること。
  • VBAには将来に向けたロードマップが無く、今後もサポートが縮小していく可能性が高いこと。
  • セキュリティ問題、ソフトウェア資産管理上の問題から、VBAの利用を禁止している企業も少なくない。

少なくとも僕個人の方針として、今から積極的にVBAで書かれたソフトウェア資産を増やしたり、今からVBAを学ぶというのは、リスクに対してベネフィットが合わなくなる可能性が高いと捉えています。

VBAによるソフトウェア資産の総量を、VBAを止める必要が生じたときに速やかに他の開発言語に移植できる程度の量に納める必要があるでしょう。ソースコードの総量をメンテナンス可能な範囲に納める必要があるいのはVBAに限った話しではありませんが、VBAの場合には生産性の低さや将来性のなさから、より少ない量に抑える必要があるはずです。

マクロの実行を有効にする上で、セキュリティリスクを下げるため、ウィルス対策ソフトを使用するのは当然として、それ以外にもアクセス権管理やコンテンツフィルタなど、多層防御できる態勢を整えておく必要があるでしょう。新しいウィルスがウィルス対策ソフトのパターンファイルをすり抜ける事は珍しく無いのです。

WevDAV上のExcelファイルを更新すると”アップロードできませんでした この場所の保存内容をアップロードするには、サインインする必要があります。”のエラーになる

QNAPのNASの機能を使ってWevDAVの共有フォルダを作成しました。共有フォルダ上のファイルををOffice 2016で開くとファイル更新時に「アップロードできませんでした この場所の保存内容をアップロードするには、サインインする必要があります。」と言うエラーが発生します。調べたところなかなか根の深い問題で、どうにもMicrosoft Officeアップローダーの仕様上の問題に起因するようです。

ちなみにWevDAV共有フォルダ上のファイルをエクスプローラーで操作したり、Office以外のアプリケーションから読み書きする場合には問題がありません。

Microsoft OfficeアップロードセンターはOffice 2013以降に追加された機能です。通信が不安定な環境において、更新されたWebDAV上のファイルをキャッシュして、非同期的にWebDAVサーバーに送信する機能を提供しています。MicrosoftはOneDrive上のOfficeファイルを開くときに、Microsoftが独自に認証周りを拡張したWebDAVを使用しています。OneDriveのファイルをOfficeで直接扱うためのモジュールとして広く使われています。この独自に拡張しているというところが曲者で、Windows統合認証やMicrosoft Liveアカウント認証に対応していないサーバーの場合に、認証に失敗してしまうようなのです。

Windows 10の場合はタスクトレイに常駐しているMicrosoft OneDrive設定から「ファイルのコラボレーション」を無効にすると、Microsoft Officeアップローダーを止められるようです。Googleから”UPLOAD FAILED: You are required to sign in to upload your changes to this location”で検索すると色々と情報が見つかりますが、OfficeやOSのバージョンによって設定すべき項目が異なったり、公式な対策でもないようなのでなかなか面倒そうです。

この辺りまで調べたところで、WebDAVの使用はあきらめる事にしました。

参考:UPLOAD FAILED: You are required to sign in to upload your changes to this location

Office 2019からOffice 365への移行

2018年10月、Office 2019が発売されました。11月にはプレインストールモデルも順次Office 2019に移行していくでしょう。様々な魅力的な新機能の陰に、ひとつ大きな問題が・・・。Office 2019の延長サポートは、Office 2016の延長サポート終了と同じ2025年10月まで。オンプレミスライセンスは後7年でサポート終了し、サブスクリプションライセンスに移行すると言う、Microsoftからの強いメッセージが込められてます。

Office 2019の発売を喜んで、漫然とオンプレミス版の永続ライセンスを使い続けているわけには行きません。Office 2019からOffice 365への移行を真剣に考えなくてはない状況になっています。

Office 365への移行の壁となるのがライセンス料です。オフィスワーク以外の現場では常時パソコンを使っているわけではありませんから、サービス業や小売業、製造業では1台のパソコンを10人程度で共有している事も珍しくありません。Office 365にはデバイスクライアントライセンスが設定されていないので、使用するユーザー数分のライセンス購入を求められます。10人で共有しているなら1台あたり年間108,000円(Office 365 Business)、Office 2016 Standardの2ライセンス分に相当するコストです。実質20倍程度のコストを負担することになります。従業員が1000人いれば年間1,000万円以上のコスト増加です。単純なOfficeの代替としては受け入れられません。

Office 365ライセンス料を抑えるためには

Officeを使った業務の削減

業務報告など定型入力資料のために使っているなら、これをグループウェアやAdobe Readerを使ったフォーム入力に置き換える。

Officeをレポート出力のためのミドルウェアとして使っている場合がある。この場合にはシステム改修して、別のレポーティングツールに移行するのが良い。

Officeの利用を削減すれば、常時パソコンを使うのでは無い従業員について、Office 365ライセンスを購入しないで済ませる可能性がある。

飾らない資料を標準化

資料を綺麗に飾り付けない文化を推奨する。オンラインで使用するWEB版のOfficeならライセンス料を安く済ませることが出来るが、表現力は大幅に制限される。対外的な資料作成の多い営業職以外はOffice 365 Business Essentialsライセンスで済ませる事を検討する。

フルセット(メール、グループウェア、ファイルサーバ、リモート勤務)でOffice 365に移行

単純にOfficeライセンスの移行として済ますのではなく、複数の社内インフラも含めて移行する。グループウェアやファイルサーバ、メールサーバ、内線電話の運用は年間数百万のコスト負担となっているはずである。これをOffice 365 Business PremiumまたはOffice 365 Business Essentialsに付随するExchange、One Drive、SharePoint、Microsoft Teams、Skype for Businessに移行する。

Office 365 Business Essentialsのライセンス料程度は、オンプレミスで動かしていた各サービスを停止する事でまかなえる。

ただしインターネット上のサービスに移行すれば、インターネットへの通信量が大幅に増える事は避けられない。ネットワーク構成への見直しも合わせて実施しなくてはならない。

Microsoft Officeと決別する選択肢

G Suiteに移行する

コストを問題視しているなら、これは無い。G Suiteはエンドユーザーコンピューティングと、セキュリティ監査関連の機能で勝るが、コスト面ではOffice 365 Business Essentialsの方が優れている。

Libre Officeに移行する

デスクトップアプリケーションについてOpen Sourceを導入した例があったが、長期的に上手くいったという話は聞かない。過去に実施した自治体はMicrosoft Officeに戻している。出力イメージが若干異なる、マクロなどに互換性がない、Libre Officeに不慣れな従業員が多数であり教育コストが増える・・・と言った事を考えると現実的な選択肢とはならない。

 

Outlook上で検索してもメールやメールアドレスが見つからない

Outlookの検索機能はWindows OSの提供するファイル検索機能を使用しています。何らかの理由でWindowsの検索用インデックスが破損していたり、あるいはインデックスの収集が行われていないと、Outlookの検索機能も動作しなくなります。

Windowsの検索機能はコントロールパネルの「インデックスのオプション」から設定出来ます。

「インデックスを作成する対象」のリストから「Microsoft Outlook」を選択して「詳細設定」のボタンを押して下さい。ここで「再構築」ボタンを押すと、既存のインデックスデータを破棄して再作成を開始します。

もしインデックスを作成する対象のリストに「Microsoft Outlook」が表示されていないなら「変更」ボタンをクリックして下さい。「インデックスが作成された場所の変更」のリストにチェックを付けると、インデックスを作成する対象としてリストに表示されます。

インデックスデータの再構築には暫く時間がかかります。半日ほど電源を入れたままにして様子を見て下さい。次第にきちんと検索にひっかかるメールの数が増えていくはずです。

Outlookを起動すると「このフォルダのセットを開けません。」と言うエラーになる

Outlookを起動したときに、下図のように「Microsoft Outlookを起動できません。Outlookウィンドウを開けません。このフォルダーのセットを開けません。予期しないエラーが発生しました。」というメッセージが表示されてOutlookが起動しなくなる場合があります。

これはOutlookの既定のpstファイルが壊れたり、あるいは設定中にエラーが発生したことにより既定のpstファイルが設定されていない事が原因でおこります。

コントロールパネルにあるユーザーアカウント→Mail(Microsoft Outlook ~)を開いてください。

すると次の様な画面が表示されるので、データファイルのボタンをクリックします。

次の様な画面が表示されます。既定に設定されているデータファイルが無い場合には、適当なデータファイルを選択して「既定に設定」して下さい。

既定に設定しようとしてもエラーとなる場合には、データファイル自体が壊れています。この場合には修復ツールを用いて、データファイルのエラーを修復します。修復するには「C:\Program Files\Microsoft Office\root\Office16」のフォルダにある、SCANPST.EXEを起動して、データファイルを選択します。

データファイルの大きさにもよりますが、修復には数時間~半日ほどかかります。急ぎ送受信だけでも可能にしたい場合、既存のデータは後日に修復してImportする物と割り切り、新規にデータファイルを作成して既定に設定する方が良いでしょう。