バックグラウンドジョブをcronで実行する。(NextCloud+Docker)

ある日を境に、NextCloudにログインすると「ストレージ容量がいっぱいです~」と言うエラーメッセージが表示されるようになった。どうも原因はバックグラウンドジョブが正常に起動されていなかった為のようで、この機会にcronから起動するようにシステム構成を変更することにした。

NextCloudは公式のDockerイメージを使用しているので単純にcronから実行する事はできない。dockerコマンドを使ってcron.phpを実行する命令をcronに登録することにする。

以下のコマンドを実行して編集画面を表示。

sudo crontab -e

以下のコマンドを登録して5分おきに実行。

*/5 * * * * sudo docker exec --user www-data [docker container name] php /var/www/html/cron.php

TP-Link Deco X50 + ひかりTV

結論から言うと動作しない。Deco X50をブリッジモードにするか、Deco X50でIPv6をパススルーに設定すれば動作するような気がするが、実際には動作しないません。

ひかりTVはTV放送データを効率よく配信するためにIPv6 multicastを使用しています。つまり「ひかりTVに対応出来る」=「IPv6 multicastを適切に扱える」に限りなく近いわけです。

TP-LinkのDeco X50は、ルーターモードでもブリッジモードでも、IPv6のファイアウォールがデフォルトで有効になっており、このファイアウォールを無効にする事ができないようです。このファイアウォールによってIPv6 multicastの通信がドロップされているように推測されます。ファイアウォールのルールを設定する画面もあるのですが、設定の制約が厳しく、マルチキャスト通信を許可するような設定を入力する事ができません。マルチキャスト通信は宛先IPv6アドレスがFF00::/8となりますが、このようなIPアドレスの入力を受け付けないのです。

設定に使用するスマホを英語モードにすれば入力できる可能性はあります。ただTP-Linkの英語版掲示板を見る限り、IPv6 multicastが通らないといった相談は度々あがっており、公式アカウントからのログ提出依頼もついていますが解決には至っていません。本質的にIPv6 multicastはMesh WiFiと相性が悪いのかもしれません。

・・・というわけで、あえてメッシュWiFiは使わずに、WiFiルーター+WiFiエクステンダーで構成するのが良さそうです。

寒波でEVの充電できずに立ち往生した話とか

米国の寒波でTESLAの急速充電器が動作しなくなり、充電待ちのEVが電欠で動作できなくなり行列を作っているとニュースになっていました。そういえば日本でも夏に充電できなくなった急速充電器とかありましたね。この手の話し、たまたまEVがニュースソースとして注目されやすいからニュースになっているだけで、-30℃なんていう寒波の中では、EVの急速充電器に限らず色々な機械が止まっているはずなのです。

というのも、世の中の機械は-30℃~40℃でしか動作保証をしていないことが多いのです。例えば「やはりハイブリッドカーが最適」という発言をちらほら見かけるけど、プリウスのマニュアルには-30℃以下だとハイブリッドシステムが起動出来ない場合があると明記されています。なんならガソリンエンジンも通常で-15℃、寒冷地仕様で-30℃を下回ると起動できない場合があるそうです。そもそも内燃機関は急速充電器が止まってしまうような低温下では、ヒーターで温めてからで無いと始動できないのです。

ガソリンスタンドの給油機もやっぱり-30℃~40℃だったりします。ディーゼルだともっと深刻で、-10℃~-30℃ぐらいで軽油に含まれる高分子量の成分が分離して固形化してしまうそうな。灯油の凝固点も-20℃~-46℃なので、燃料が固まっているから石油ストーブも動きません。じゃ北極圏に近いような場所ではどうやって暮らしているのかと言えば、24時間暖房を耐えさせないようにしているわけです。

同様の事は高温時にも起こります。日本でも夏の気温が上がり35℃を超える猛暑日が度々おこるようになりました。直射日光が当たるような場所なら40℃を超えても不思議ではありません。気象条件が変わって寒波が襲来したり、猛暑が到来したり、度々おこるようになっている以上、インフラ関係の機器だけでも-40℃~50℃ぐらいまで動作するように考えなければならないのかもしれません。

某高校の入試申請で話題になってたメールサーバーのこととか

神奈川県の高校入試出願システムで障害、志願者のGmailにメール届かず – 現在は解消

神奈川県下の中学三年生は約7万3千人。予備のメールアカウントも登録しているから、全員に一度にメールを送信しようとすると、約15万通のメールを一度に送信しうるメールサーバーという話になる。

件のメールサーバーではMXテーブルにIPアドレスを指定していたことが原因で、SPFやDKIMが機能していない。その状態で大量のメールを送信したためレピュテーション(評価)が低下、不正中継サーバーと判断されて、メールを拒否されるようになった。Googleが制限しているためメールを受信出来ないという表現は確かにその通りだが、不正メール対策として正しく設定していないメールサーバーからのメールを受信しないのはGoogleに限らず多くのベンダーで行っている基本的な対策だ。正しく設定出来ていなかったメールサーバー側が全面的に悪い。

では正しく設定出来ていたら問題無くメールを送れたかというと、実は送信出来なくなった可能性が高い。新規にドメインを取得して間もなかったり、普段より極端に多くのメールを送信した場合にも、レピュテーション(評価)が低下する。これはSPFやDKIMによる認証が行われるようになる以前から行われていた不正中継対策だ。

もし独自にメールサーバーを立てるなら、ユーザーの利用が集中しないように利用開始時期を分散させつつ、レピュテーション(評価)の状態を確認しながらメールの送信数を調整、時間当たりに送信するメールを少しづつ増やしていく必要がある。運用に常に人を張り付けて微調整が必要になる。そもそも1~2月だけ大量のメールを配信するというのはレピュテーション(評価)を下げやすいので、年間通してメールを送り続けるような仕組みまで考えておく事を求められる。

実際には上記のような運用は手間がかかるし、バッドノウハウの塊なので経験がないものが実施するのは難しい。そこで通常は大量のメール送信を代行する、メール配信事業者に頼むことになる。

1月~3月だけ数十万通のメールを送信するシステムで、自前のメールサーバーから配信しようとしている時点で、発注者側にも受注者側にも適切に設計を出来るIT知識が無かったことがうかがわれる話だったりする。

参考:Google メール送信者のガイドライン

Nintendo SwitchのSDカードを容量の大きなものに交換する

Nintendo Switchに使っているSDカードの空き容量が不足してきたので、サイズの大きなSDカードに交換したいと思う。Nintendo SwitchのSDカードはFAT32フォーマットを採用していて、2TBのSDカードまで対応している。パソコンで単純にコピーできれば早いのだが、Windowsでは32GBを越えるFAT32パーティションを作成することが出来ない。そこで使用するのは以下の二種類のツール。作業を始める前にダウンロードしてインストールしておく。
HDD Raw Copy Tool
MiniTool Partition Wizard 無料版

SDカードリーダーが2台有ればMiniTool Partition Wizardで元となる容量の小さなSDカード、新しい容量の大きいSDカードに直接コピーできる。だがその為だけにSDカードリーダーを追加で用意するのも勿体ない。ここではHDD Raw Copy Toolを使ってSDカードを複製した後に、MiniTool Partition Wizardでパーティションサイズを変更する手順で作っていく。

コピー元SDカード⇒ディスクイメージファイル

最初にHDD Raw Copy Toolを使用してSDカードからディスクイメージフィルを作成する。HDD Raw Copy Toolは日本語化されていないので日本語のフォルダ名やファイル名は文字化けする。保存先などには日本語名が混じらないようにする。

SDカードをリーダーに挿した後にHDD Raw Copy Toolを起動すると認識しているディスクの一覧が表示されるので、コピー元となるSDカードを選択して、Continueをクリックする。

次にコピー先となるディスクイメージファイルを選択する。認識されているディスクの一覧の最後にFILEと言う項目があるので、それをダブルクリックする。保存先の選択ダイアログが表示されるので、保存先のファイル名を入力する。

コピー先となるディスクイメージファイルを指定したら、Continueをクリックする。

以下のような確認画面が表示されるので、Startをクリックして、ディスクイメージファイルの作成が終わるのを待つ。コピーが終わったら100% completeと表示されるので、HDD Raw Copy Toolを終了する。

ディスクイメージファイル⇒コピー先SDカード

コピー先SDカードに差し替えて、再びHDD Raw Copy Toolを起動する。最初にコピー元を選択するが、今度はディスク一覧の最後にあるFILEを選択する。FILEをダブルクリックして、先ほど作成したディスクイメージファイルを指定して、Continueをクリックする。

次にコピー先を選択するので、ディスクの一覧からコピー先となるSDカードを選択して、Continueをクリックする。

コピー確認画面でStartをクリックする。コピー先のパーティションを上書きして良いか警告が表示される。ここでは警告を無視して「はい」をクリックして先に進める。

パーティションサイズの変更

この時点では、コピー先SDカードのパーティションサイズは、コピー元SDカードと同じになっています。この後に、MiniTool Partition Wizardを使用して、コピー先SDカードのパーティション拡張を行います。

MiniTool Partition Wizardを起動してドライブの一覧から対象のSSDにあるFAT32パーティションを選択したあと、右側のパーティション変更からパーティション拡張をクリックします。

パーティション拡張のバーを一番右側までスライドさせ、パーティションサイズを最大まで拡張します。

最後に右下の「適用」をクリックしてパーティションの拡張を実行します。

この手順で、キャプチャした画像はコピー元のSDカードが32GB、コピー先のSDカードが64GBになっていますが、最大2TBまで制限無く拡張できるはずです。

緊急地震速報の誤報報道の滑稽さ

緊急地震速報(警報)で震度7の警報が出たにもかかわらず、有感地震が無かったことが誤報として問題視されている。同様の誤報は数年おきに発生しており、今回が初めてと言う訳でもありません。

緊急地震速報の仕組み自体は気象上の緊急地震速報(予報)発表状況にかなり詳しく記載してあり、なぜ誤報が起こるのかまで記載されています。

緊急地震速報は次の様な仕組みになっています。

2箇所以上の地震計で、地震のP波と思われる振動を捉えると、震源地や最大震度を予測して、その結果を緊急地震速報(予報)として関係諸施設に送信します。一回計算して終わりでは無く、新たな地震計のデータを加えて何度も予測計算を繰り返し、そのたびにより正確な緊急地震速報(予報)を送信します。予測される最大震度が4.5超える場合には緊急地震速報(警報)を送り、スマホからおなじみの警報音が鳴り響くことになります。

ここでお気づきと思いますが、2箇所の地震計の観測データから震源を計算したとしても、その震源は帯状の範囲としてしか予測できません。正確に震源を特定するなら最低でも3箇所、出来れば4箇所以上の地震計のデータが必要になります。それにも関わらず2箇所の地震計のデータで震源を計算しているのだから、誤報が発生して当たり前のシステムなんです。

緊急地震速報は全国に約1700箇所ある地震計を使用しています。日本の陸地面積は378000平方Km。仮に地震計が一様に設置されているとしたら、約222平方Kmに1箇所、およそ15Km間隔で地震計が設置されています。 P波が地中を伝わる速度は約7Km/sだから、3箇所目の地震計からのデータを待つなら最大で2秒程度遅れることになります。現状でも緊急地震速報警報が伝わってから、S波到達までの時間的余裕は数秒~数十秒でしかありません。3箇所目のデータをまつために2秒遅らせたら、緊急地震速報は本震に間に合わず、存在意義を失います。そのため不正確なのを承知の上で、2箇所に地震計のデータで処理を行っているわけです。

緊急地震速報の予測震度が大きくずれる原因はある程度わかっています。
・震源が陸から(地震計から)大きく離れている場合
・地震発生と同時に、周辺の地震計が地震以外の震動や電気的雑音を拾った場合。
・たまたま複数の地震が同時に発生した場合。
・地震計の故障などにより、使える地震計が少ない場合。

今回は大きな地震発生から間もないため頻繁に地震が起きており、また地震計も被害を受けているため使える地震計が少なく、誤報が発生しやすい条件下にあります。

緊急地震速報は、ある程度の誤報を許容する事で、より早く警報を出せるようにしたシステムです。誤報の発生を許容する警報システムそのものを問題視する議論ならわかります。そこを無視して、緊急地震速報に誤報の再発防止だの、誤報を出したことの管理責任を求めたりというのは、エンジニア目線だとわりと滑稽な話です。

2024年1月1日16時移行、13回の緊急地震速報の警報を発表している。震度5を越えても警報が出なかったのが3回になっている。人命や減災を意識するなら、実際の震度が低いにもかかわらず発報してしまった場合よりも、実際には震度5を越えているのに発報できなかった事を問題視するべきはずだ。だが、逆の事をしているあたりが、リテラシーの低さを物語っています。

NextCloudで”一部のファイルは整合性チェックに合格していません。~”

dockerでNextCloudを動作させて居るのですが、バージョン28.0.1への更新移行、以下のエラーが発生する状態になってしまった。監理者設定の画面を開くと、以下の通りに表示されている。

“無効なファイルのリスト”のリンクを開くと、整合性チェックでエラーとなったファイルのリストを確認出来る。

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- core
	- INVALID_HASH
		- core/js/mimetypelist.js
	- EXTRA_FILE
		- core/img/filetypes/dwb.svg
		- core/img/filetypes/drawio.svg
Raw output
==========
Array
(
    [core] => Array
        (
            [INVALID_HASH] => Array
                (
                    [core/js/mimetypelist.js] => Array
                        (
                            [expected] => 550ab566d30693bfa24ec4b15d9df87731ae8a3be8f79dabf94757e5b8b20eec6e4b678f17af1718297f2872f6b04519eeb024d1dff11947f29da431c7f11201
                            [current] => 301654cbbe168b8723530db88fd2e40ad688f4e6b0bdaeade5b4fe34bd94d9d3cfe760821e97dc792e585d4b6ccff838597bfd46466bb07d30ff84df4cb79518
                        )
                )
            [EXTRA_FILE] => Array
                (
                    [core/img/filetypes/dwb.svg] => Array
                        (
                            [expected] => 
                            [current] => 43731dd5f17a048112ea5109b40b02ec019b3ee2324385a0f448e3bd2264cb13dc160ab018d893f92f8e2f168fd09009b51578c8c6b97a02a1617c67ac087701
                        )
                    [core/img/filetypes/drawio.svg] => Array
                        (
                            [expected] => 
                            [current] => 92e0974cf869bf8ab969c3442dc2b80d55fde36441d22924db74916a06b407520aa2a9dc39336f9157195ebede697ffac0e639360879255ab91932d406e1897d
                        )
                )
        )
)

core/js/mimetypelist.jsがバージョン不整合を起こしていることが分かるので、NextCloud(https://nextcloud.com/changelog/)から28.0.1のbzip2ファイルをダウンロードし、nextcloud-28.0.1\nextcloud\core\js\mimetypelist.jsをhtml\core/js/mimetypelist.jsに上書きする。

html\core/img/filetypes/dwb.svg、html\core/img/filetypes/drawio.svgはexpected(必要なファイル)のハッシュ値が空欄である事から、そのまま削除する。

監理者設定の画面を開き”再スキャン”をクリックすると、再度整合性チェックが行われる。これで”一部のファイルは整合性チェックに合格していません。~”の表示が消えた。

“468 error in the logs issu”の方も気になるのでログを確認すると、”Temporary directory /var/www/html/temp is not present or writable”との表示が並んでいた。

以下のコマンドを実行してtempフォルダを作成する。

sudo mkdir .\html\temp
sudo chown www-data:www-data .\html\temp

糞コードのリリースは許されるのか?

糞コードをリリースすることの是非みたいな発言をXで見かけたので私見を纏めておく。

糞コードの問題は、理解するのに時間が掛かるとか、改修が困難とか、バグを出しやすいとか色々と言われるけど、纏めるとランニングコストが高いと言うことになる。単純にコードの保守性だけの問題では無くて、処理が最適化されていないために多くのコンピューターリソースが必要となるといった事も含まれます。

ランニングコストが高いと何が不味いのかを、簡易的にグラフにしてみた。

時間経過とともに機能が追加されたりデータが増えたりするため、システム規模は日に日に大きくなり、累積コストは指数的に増加していきます。糞コードは初期コストが安くても運用コストが高くなります。対してクールコードは初期コストが高くても運用コストが低く抑えられています。初期は糞コードの方が運用コストが低く済んでいますが、いずれクールコードと逆転するわけです。

糞コードの収益性が悪いだけなら良いのですが、場合によっては採算ラインを超えてしまう事が起こります。独占企業なら問題にならないかもしれません。ですが競合他社が居る場合、運用コストの高さは長期的にビジネスの継続を危うくするわけです。

糞コードは後で書き換えれば良いという主張もあります。ビジネスとして継続する為に、システムを再構築してクールコードに書き換えるわけです。ですがこれは開発コストを二重に負担しているので、コストが大幅に増えて収益を圧迫します。

特に新規のビジネスの場合には資金的にも人員的にも余裕がないため、実際には糞コードの再構築は後回しになりがちです。再構築が遅延すると、その間にコードもデータも増えていくため、再構築にかかるコストがより大きくなります。最悪の場合、再構築を行うと採算ラインを越えるため出来ないが、このままだと運用コストが採算ラインを越えるため放置も出来ないという、詰んだ状態に陥るわけです。

以上のことから、糞コードのリリースについて三行に纏めておく。

  • 時間的な制約から糞コードをリリースする場合はあり得る。
  • だが糞コードは最小限にし、速やかに改修しておく必要がある。
  • 糞コードの放置はビジネスを終わらせる時限爆弾となり得る。

画像ファイルを開こうとすると「ファイルシステムエラー ファイルを読み込めません」となる。

MicrosoftフォトなどのMicrosoft Store アプリが動作しなくなると中々に厄介です。昔同様の状況になったときには修復できずに終わったのですが、今回はなんとか修復できたので実行した作業を纏めて起きます。

DISMコマンドおよびsfcコマンドでコンポーネントストアの修復を試みます。管理者権限でコマンドプロンプトを開いて、以下のコマンドを順番に実行します。

DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /SCANNOW

次に設定→更新とセキュリティ→トラブルシューティング→追加のトラブルシューティングからWindowsストアアプリを選んでトラブルシューティングツールの実行を行います。

設定→アプリ→アプリと機能からMicrosoftフォトを選択して詳細オプションを開く。終了、修復、リセットを純に実行する。

Microsoftフォトが起動するようにはなりましたが、アプリと機能に表示されないなどどこか動作が不自然なのでPowershellからMicrosoftフォトをアンインストールします。

管理者権限でPowershellを開いて以下のコマンドを実行します。

Get-AppxPackage Microsoft.Windows.Photos | Remove-AppxPackage

Microsoftストアを開いてMicorosftフォトを再度インストールします。

参考:ファイルシステム エラー-2147219196の対処法7つ

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の場合には生産性の低さや将来性のなさから、より少ない量に抑える必要があるはずです。

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