人々が今なおVBAを使う理由
(sancarn.github.io)- 多くの組織で Excel が業務プロセスの基盤になっているため、小さな自動化が必要なとき VBA が事実上の第一選択肢 になる
- 事例の組織は 13 個のデータプラットフォームと複数の自動化ツールを持っているが、必要なデータソースに幅広くアクセスできるツールは VBA と PowerShell くらいに絞られる
- CyberSecurity は
Python,Ruby,Node,Rustのような高水準言語のインストールを拒否し、代替の Power Platform はデータアクセス性と複雑なアルゴリズム保守の面で限界を見せた - Lotus Notes と IBM BPM の過去事例は、IT 主導のシステムがサポート終了、未完了の移行、保守の空白に脆弱であり得ることを示している
- VBA は古く弱点もあるが、Office に含まれていて誰でも使え、SME が業務ロジックとデータ移行を自ら検証できる コントロール権 を提供する
VBA が選ばれ続ける直接的な理由
- 2021 年の /r/vba 調査では、VBA ユーザーの多数が ほかに選択肢がないため VBA を使っていると答えた
- 多くの組織は業務プロセス全体を Excel で運用しており、少しの自動化が必要なとき VBA が最初に選ばれることが多い
- 「スプレッドシートでインフラの一部を制御している」という批判の背後には、組織が提供するツール、データアクセス性、保守体制の制約がある
データアクセス性と自動化ツールの制約
- 事例の組織のエンジニアリング部門は複数の自動化プラットフォームを利用できる
- OnPrem:
PowerShell, Excel のVBA/ 制限付きOfficeJS/OfficeScripts/PowerQuery,PowerBI Desktop,SAP Analysis for Office - OnCloud:
PowerApps,Power BI, 非プレミアムのPowerAutomate - サンドボックス環境:
ArcGISのArcPy,MapInfoのMapBasic,InfoWorks ICMのRuby,ArcGIS Online
- OnPrem:
- IT が管理するデータプラットフォームは
D1からD13まであり、地理空間 DB、SAP DB、テレメトリプラットフォーム、SharePoint、Lotus Notes、IBM BPM、ファイルシステム、Hydraulic Model Information などを含む - 必要なデータソースに接続できる自動化プラットフォームは VBA と PowerShell くらいに整理される
Power BI Desktopは組織に導入されているが、VBA がアクセスできるすべてのプラットフォームをカバーできない- 同じ範囲にアクセスできても
Power BIはプロセス自動化には使いにくく、別のデータセットを扱うには CSV を作って SharePoint に保存する方法が使われる - その CSV 作成も VBA が担うことがある
- VBA の一部 OnCloud サービス接続は直接の試行に基づいており、SAP BW4HANA やほかのクラウドサービスも VBA でインターフェースできると見ているが、認証要件とプロトコルはまだ解決していない
高水準言語と Power Platform の限界
- 組織は業務自動化のために
Python,Ruby,Node,Rustのような高水準言語を使いたかったが、チームやビジネス全体へのインストール要求は CyberSecurity によってすべて拒否された - 拒否理由は、エンドユーザーに高水準プログラミング言語へのアクセスを許可することが、会社の技術戦略ビジョンに反するというものだった
- 代替として挙げられる
PowerAutomate,PowerAppsは必要なデータにほとんどアクセスできない - データアクセスが可能でも
Power Platformは大半のプロセスを実行するには不十分- 必要なアルゴリズムが複雑なため、
PowerAutomateソリューションは保守が難しく、IT 人材にとっても理解しにくいことがある - 例として projection algorithms が挙げられている
- 必要なアルゴリズムが複雑なため、
- 結局、実用的に残るツールは
PowerShell v3と VBA になるPowerShell v3はクラス構文をサポートせず、モジュールのインストールもできない- VBA は、現代的な基準で妥当な言語として補強するために何百時間もかけて open source VBA libraries が作られる対象でもある
保守の保証としての VBA
- 2000 年代には多くのシステムが IBM Lotus Notes データベース上に構築された
- Lotus Notes は 2019 年に HCL に買収された後、サポート継続性が揺らぎ、2024 年 6 月に公式サポート終了が予定されていた
- 2019 年から技術チームは複数のシステムを新技術へ移行しようとしており、組織は Lotus Notes DB ひとつを置き換えるために IBM Business Process Manager ベースのシステム開発へ大きなコストを投じた
- 計画は
D11にD10のデータをすべて投入した後D10をアーカイブすることだったが、2023 年時点の状況は異なっていた- 公式サポート終了まで 8 か月しか残っていない
- 技術チームは IBM BPM のサポート契約をなくした
- IBM BPM と Lotus Notes DB のどちらについても代替システムが見当たらない
- IBM BPM ソリューションは保守不足で、必要なとおりに動作しない
- 目的に合わないソリューションを IBM BPM に無理やり押し込んだ状態になっている
- REST API はあるが、技術チームにも SME にもほとんど役に立たない
- 一部の REST 呼び出しは文字列としてエンコードされた JavaScript を使う
- 別の呼び出しでは XML の中の JSON の中に HTML を入れなければならない
- DB テーブルは名前ではなく GUID でクエリされる
- どの GUID がどのテーブルやプロセスに対応するのか文書がない
D10のデータは実際にはD11に移行されておらず、ビジネスは 1 つではなく 2 つのシステムを使っているD11のデータモデルもD10のデータを適切にサポートしていない
- SME はツールを日常的に使い、システム変更の必要事項を決める主体である
- SME が VBA を使えば、必要なだけシステムを自ら制御し保守でき、これは IT システムでは保証されない 保守の保証 として機能する
コントロール権と SME 協業の問題
- 最近のプロジェクトは、ビジネスの中核スプレッドシートを置き換える新しい統合 IT システムを作ることで、成功すれば
D6の重要度は C ランクに下がる予定だった - 初期仕様はシンプルだった
NodeJSサーバーとMySQLデータベースReactUI- 管理者と SME にコードベースと
gitのアクセス権を提供 - IT と SME が協力してシステムを構築
- 技術チームは別の要求を出してきた
- 管理者と SME はコードにアクセスできない
- フロントエンドは “Strategic Vision” に合わせて
Microsoft PowerAppsで構築する - バックエンドは “Strategic Vision” に合わせて
Microsoft Azure Pipelinesで構築する
- SME の立場では、この要求はいくつもの問題を生む
- 技術チームは現場業務を理解していないため、業務ロジックや計算を理解しにくい
- 開発者が業務ロジックを書くと誤りが生じやすい
- 技術チームはカスタム技術プロジェクトをしばしば放置し、保守や改善のリソースが消える
- SME と協業すれば、少なくとも一方のチームはシステム保守リソースを維持できる
- SME は成果物を信頼できなければならないが、コードが見えなければすべてのエッジケースで動くか確認しにくい
- 単体テストがあっても、コードが見えなければテストが存在し頻繁に実行されているか検証しにくい
- SME は既存レガシーシステムの改善・保守や、システム間相互作用に関する知識を多く持っている
- 新システムへすべてのデータが正確に移行され表現されているか確認するには、バックエンドへのアクセスが必要
- コードが VBA に残っていれば、SME とビジネスは コントロール権 を維持できる
- 技術チームはビジネスチームにほとんどコントロール権を渡さず、SME はソフトウェアがモジュール式に適切に開発され、緩くつながった技術の寄せ集めになっていないことを確認できる
慣れた環境の中でのユーザー体験
- ほとんどのエンジニアは日常業務でスプレッドシートを使っている
- VBA はスプレッドシート内に組み込まれているため、慣れた環境 の中で見慣れないツールを提供できる
- 見慣れない環境で見慣れないツールを提供するより、慣れた環境の中に新しい機能を入れるほうが、ユーザーにとってより強力になり得る
結論: VBA の弱点と現実的な選択
- 組織がスプレッドシートと VBA を選ぶ理由はいくつもある
- セキュリティ上の懸念のため、IT が提供する代替手段が乏しい
- 代替ツールがソースシステムに十分接続できず、たいていまだ進行中の状態にある
- 一部のユースケースを反映していない IT 戦略上の問題がある
- セキュリティと保守の懸念から SME と協業しようとしない
- ユーザー、管理者、SME が代替システムの教育を十分に受けていない
- ユーザーと SME はシステムの業務ロジックに対して一定のコントロール権を求めている
- Office に含まれていて、誰でも使える唯一の実行可能な技術である
- VBA に弱点がないわけではない
- mataroa の記事 には一部もっともな点がある
- ときに管理はひどいが、組織の多くの人は与えられた道具の中で正しいことをしようと努力している
1件のコメント
Hacker Newsのコメント
企業には、在庫外ソフトウェアの承認を得るために管理層、上級管理層、プロジェクト登録、予算、プロジェクトマネージャーの割り当てなどを経なくても済む開発環境が、すでに Excel の中にある
ネットワーク上のデータストアとWebインターフェイスまで欲しければ、SharePointをつなげればいい。こうしたエンドユーザー志向から解決策が生まれ、その解決策はVBAで作られる
昔、Word VBAで作られたひどいレポートエンジンが、ファイル共有からレポート定義を読み込み、テンプレート片を切り貼りしてから出力していた。退職者が使っていたPCをIT部門が回収しなかったので、それで一日中
.docを回してエンジニアリングレポートを作っていたが、CAD/CAMソフトウェアのレポートオプションを購入するよりずっと速く安かった。そのオプションには少なくとも18か月、コンサルタント、プロジェクト予算の消費が必要だったはずだ人々がExcel VBAでひどいことをしていると批判するとき、原因はもっと上位のスタックにある可能性が高い。もう一つの原因は「サルにハンマー」で、サルにハンマーを持たせれば何でも叩くように、手元の道具がVBAだけなら、あらゆるものがVBAで解くべき問題に見えてくる。今では少し進化した霊長類にはなった
次の段階ではJimも実行したがるのでスクリプトがコピーされ、Janeは別のVBAバージョンを使っているため修正され、今度は「これも！」となって拡張される。最終的に1500行の継ぎはぎになり、保守を開発チームに押し付けようとする
会社のPCはかなりロックダウンされていて何もインストールできず、ホワイトリストにないサイトにも行けないが、Excelはある
かつての「Emacsオペレーティングシステム」パラダイムを、別の文脈に適用したものとかなり似ている
だからVBAが企業でいまだに非常に価値を持つのは驚きではない。他のツールや言語、成熟したビルド手順がある環境でも、プロダクトマネージャーたちがVBAであきれるほど複雑なビジネス分析をしているのを見たことがあり、手元の問題にはそれが適した道具だった
プロの開発者たちもExcel/VBAを補助ツールとしてかなり使っているのを見て驚いた
数年前、大手ヘッジファンドと仕事をしたとき、データアナリストが自作のExcelモデルを送ってきたが、
.xlsm拡張子を見てVBAコードが入っているのだろうと思った。「マクロ記録カウボーイたちが何をやったのか見てみよう」と思ったが、中には大量のVBAがあり、作者はCaltechのコンピュータサイエンス出身で、Pythonを非常によく使いこなすデータアナリストだったVBAはデータベースからデータを取得してシートに入れ、数式を作り、見栄えよく書式設定する用途で、UserFormもいくつかあった。「VBAですか？ そこでは他に何を使うんです？ 綿繰り機と蒸気ショベルですか？」とからかったのだが、予想に反してExcelとVBAを大いに称賛したので驚いた
彼の言葉が印象に残っている。「Excelは、計算が示唆する依存関係の構造を理解しやすくしてくれます。これをPythonでやっていたら、一日中質問に答えていたでしょう」
VB6にはかなり大きなコミュニティがあり、https://twinbasic.com/ が最近、VBAとVB6のコミュニティを統合するのに大いに役立っている。なので、開発者コミュニティでちょっとした復活があるかもしれない
スウェーデンには38ページのユーザーマニュアル付きの 3GBのExcel/VBA年金予測モデル もある。ただし、Excelを非常にうまく活用した例とは言いにくい: https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
VBAは強力で、プロトタイピングと反復が速い。さらにはVB6が CRUDアプリ の頂点だったとも言える
「驚くほど便利だから」
昔、JP Morgan のネットワーク上に Access データベースが2万個以上あったという話を聞いたことがあります。さまざまな会社のデータアナリストは、ある日、毎日の仕事に嫌気がさして「マクロの記録」ボタンを眺めます。ある人はそれがかなり便利だと感じ、そのまま使い続けます。さらに賢く立ち回って、マクロが吐き出したコードを覗き込み、少し学んで手を加えてみようとする人も出てきます
少数派はデータ構造とアルゴリズムまで学び、Django を真似た認証・権限システムを作り、UserForm UI を一から作り直し、Markdown、SAX パース、カスタムスクロールバー、ロギング、ゲームまで実装します
答えはたぶん、データアナリストが毎日の仕事に退屈したからです
もちろん、誰でも入ってきて学ばなければならない何かをサポートする必要がある、というのは妥当な懸念です。しかしビジネス側が問題解決のためのツールにアクセスできる限り、「退屈した」人たちは方法を見つけます。摩擦が大きすぎるのです
Excel の中である程度複雑なものを作ってネットワーク共有に置くほうが、IT を通して IDE をインストールし、何かを作り、セキュリティ手続きを経てデプロイするより簡単なので、当分終わらないと思います。すべての問題に Jira プロジェクトや過度に複雑な解決策が必要なわけではありません
ただし、大きなものを VBA で作ることには全面的に反対です。いくつかのセルの値の変化に応じて、あるシステムのキューブを照会し、別のシステムのテーブルデータと結合する程度の小さなスクリプトなら構いませんが、ある時点からは別の場所へ移るべきです
ほとんどのプロジェクトでは、サーバーライセンスがあって自動化できるという前提で、Alteryx+Tableau/PowerBI スタックを非常に好みます
アナリスト向けに簡単な CRUD インターフェースを作る必要がありました
最初の問題は、アナリストたちがすべての CRUD 手順を Excel の中で処理したがっていたことです。Excel が実際のインターフェースだったので、Excel の中で実行できる何かが必要でした
IT 部門はコマンドラインアクセスを許可せず、未承認の開発ツールのインストールも拒否しました。承認を得るには数か月かかる可能性がありました。データベース管理者たちは既存の Oracle DB に新しい DB を追加することを快く思わず、IT 部門も自前で DB を運用することを嫌がりました
さらに、Excel に新しいアドインを入れるだけでも IT 担当者に頼み込まなければなりません。運が良ければある日突然アドインが現れますが、1日かかるのか、1週間かかるのか、1か月かかるのかは分かりません
そのため、現実的な唯一の選択肢は VBA であり、結局、アナリストたちが2週間に1回使う暫定的な固定対応策を立ち上げることに成功しました
ある情報機関で働いていたとき、アフガニスタンに派遣された人たち向けのアプリを作る必要がありました。彼らが使えるコンピューターはロックダウンされた Windows XP だけで、新たにインストールする方法はありませんでした
すでに検証済みでインストールされていた Office に縛られていたため、Linux ユーザーである私も Office に縛られました。純粋な VBA だけでかなり多くのフランケンシュタインを作り、好評を得ました
scriptタグに JavaScript コードを入れた HTML ファイルでしのいでいました。マシンがネットワーク分離されていたのに IE の実行がブロックされていたのか、それとも JavaScript より VBA のほうが楽だったのか気になります認めたくはありますが、IT は現代の官僚制部門であり、自分たちで作った問題への対応で 95% 忙しく、サービス志向はせいぜい 5% くらいです。外部の人にとってプロセスは不透明で、たいてい役に立ちません
IBM BPM の説明でこういう箇所を読んで本当に笑ってしまいましたが、問題のかなりの部分をよく要約しています
「IBM BPM には REST API があるにはあるが、この REST API は技術チームや中小企業にはほとんど役に立たない。ある REST 呼び出しは文字列にエンコードされた JavaScript を使い、別の呼び出しは XML の中の JSON の中の HTML を要求する。データベーステーブルは名前ではなく GUID で検索される。どの GUID がどのテーブル／プロセスに紐づいているのかの文書はない」
多くのものがばかげて複雑になりすぎて、IT の外の誰も扱おうとせず、時には IT の中の人間でさえ扱いません。AJAX 以降、開発工数の半分がフロントエンドコードとバックエンドサービスの設計に費やされるようになりましたが、これはエンドユーザーの自動化問題とは実のところほとんど関係がありません。その後さらに悪化し、最近の UI はモダンに見えるものの、それを作るのに使われた技術スタックと同じくらいユーザーに敵対的です
Excel では UI がただ「そこに」あり、マクロ記録というコード生成器もあり、IT 部門が私の権限を詮索したり、私のビジネス上の問題を手伝う時間も予算もないと言ったりもしません。だから VBA は、ユーザーが IT 部門を迂回するための抜け道なのです。完璧ではありませんが、他の選択肢よりはましです
何も変わっていません。前世紀にもこういうことはあり、自動化の島と呼ばれていました。当時、私の周囲では良い戦略だと見なされていて、各部門にまず遊ばせてみて、可能性が見えたら統合していました
分析担当者が数人集まって、自分たち用の小さな VBA ツールをハックすること自体はまったく気になりません。そういう精神は称賛に値しますし、その結果として私の日常業務をよりよく理解できるようになるかもしれません
気に障るのは、その分析担当者たちがある時点で、自分たちの個人プロジェクトに合わせて私のシステムアーキテクチャが何とか受け入れてくれることを期待し始める時です。文書を求めてもなく、アーキテクチャ概要もなく、その怪物のリポジトリへのアクセス権を求めると「リポジトリって何ですか？」となります
なぜ彼らのスプレッドシートが私の処理パイプラインにデータを注入してはいけないのかと尋ね、YouTube 動画を半分見て覚えた REST の断片に合わせて私がコントローラを書くべきだと思っています。会議では「認証が必要とはどういう意味ですか？ なぜ IT はいつも物事を複雑にするんですか？」という質問が出ます
VBA であれローコードであれ何であれ、人々がツールを作るのは良いことです。私も同じことをしています。ただ私はそれをシェルスクリプトと呼び、Git リポジトリに置いているだけです。ですが、自分の CLI ツールを本番サーバーに放り出したりしないのと同じように、コードレビューを一度も経ていないものもそうはしません
私を雇ったのは市場リスク管理責任者で、彼の役割は銀行が一日にあまりにも多くの金を失わないようにすることでした。彼は、正式に承認された IT 部門が自分のアルゴリズム実装コードを正しく書けるとは信じられなかったため、私を雇ったのです。たとえば彼らは、乗算が加算より優先されるという演算子の優先順位を理解しておらず、間違えたことがありました
市場リスク計算にはすべての取引を入力として入れる必要があり、2000 年代初頭だった当時、机の下の PC に Apache と Perl CGI をインストールして、トレーダーが取引を入力しポジションを追跡できる小さなアプリを作りました。トレーダーたちは、公式の IT ソリューションより使いやすく、ポジションを見やすいので、こちらを好むようになりました
多くの企業環境では、IT を迂回する方法を見つけることが重要な機能です。Excel に話を戻すと、トレーダーたちは計算やシミュレーションに Excel を使っており、私たちは Excel に差し込めるツールを提供して、彼らがすでにやっていたことを活用しようとしました
「エンドユーザーに高水準プログラミング言語へのアクセスを許可することは、会社の技術戦略ビジョンに反する」とされています
「エンタープライズ」の驚異です。人々がそれを長所や言い訳のように持ち出すたびに驚かされます
最近まで良い代替手段がなかったため。未来は新しい Office アドインモデルにある: https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
TypeScript について何と言おうと、少なくとも VBA よりはまし。ただし VBA と違って、Excel の中でそのままプログラミングできないのが大きな問題。時には、再利用を前提にした本格的なアドインプロジェクトを始めたいわけではなく、今すぐ何かを直すために、ざっくり一度だけ実行するスクリプトが欲しいだけのこともある。これを使っているうちに Script Lab(https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...) を知ったのだが、役に立つかもしれない
さらに明白な疑問がある。アドインは権限のないユーザーが IT 部門の介入なしにインストールできるのか。スプレッドシートに埋め込めるのか。前者が「いいえ」なら本当に致命的だし、後者が「いいえ」でも採用には悪影響がある。マクロと VBA の利点は、セキュリティ設定を除けば、すべての Excel インスタンスが追加インストールなしで直ちに実行できることにある
別の問題は、エンドユーザーにアドインを共有するのが些細なことではない点。マーケットプレイスや SharePoint に公開する必要があり、サイドロードには SMB サーバーと GPO が必要になる。ただし、どこにもあまり触れられていない選択肢が一つあり、ドキュメントに含めておくと、初回オープン時にユーザー確認のうえインストールされるようにできる
もう一つの大きな問題は、OfficeJS を使うには Web サーバーをホストできる必要があること。通常、エンドユーザーの大半にはそのようなアクセス権がない
VB(A) は Python に似ている。きれいではないが、仕事はこなす。きれいだと思うなら、経験が足りず、より良い代替手段をあまり知らないということ
実際の仕事を終わらせてくれる優れたエコシステム、つまりツール・ライブラリ・統合を備えたツールは有用だ。デスクトップアプリ開発システムとしての Visual Basic は、DB の利点を加えた MS Access とともに、多くの状況で非常に有用だった。それを超える段階になれば、「本物の」解決策へ拡張する資金もあったはずだ
VBA ベースのシステムで莫大な金が稼がれたことに疑いはない。金融開発を主に外部者の立場で経験した身として、最大級の Excel/VBA の書き直しは、2008年前後にクレジット・デフォルト・スワップで大金を稼いだ会社のものだった。書き直し前はワークブックを開くのに5分かかっていたが、VBA が多くの重い処理を担っていた。知識を持つ人たちは、会社と自分のためにボーナスで大金を稼いでいた
ここから学べるのは、ツールが理想的かどうかより、そのツールを使うよう特別に訓練されていない人にとって アクセスしやすい かどうかのほうが重要だということ。Python がクライアント Web ブラウザーの外で1位になった理由もそれと同じ。最高という意味ではないが、仕事をこなし、手が届きやすいという意味だ
しかし、それが人気の唯一の理由ではない。最も堅牢な データサイエンスツール を持っているため圧倒的な効果が生まれ、Django や Flask のようなまともな Web フレームワークもある。多くの大学で Java に代わる「最初に学ぶ言語」になったことも人気上昇の理由だ。VBA はそうではない
経験とは、きれいかどうかには主観的な要素があることも知っているということだ。VBA は「過酷な」条件下で進化したため、奇妙な点もある程度は説明がつく
VBAはオブジェクト指向プログラミングをサポートする、まずまずの言語です。継承はありませんが、合成は可能です。Excelに深くアクセスして制御でき、成熟していて安定しています。Microsoftがもはや大きく変更しないためです。
「本物のプログラマー」たちがVBAを嫌うのは、たいていビジネス担当者が書いた素人っぽいスパゲッティVBAコードが多く、ときどきプログラマーがそれをデバッグしてほしいと頼まれるからです。
コード内の制御文字がローカライズされるなど、奇妙な特性だらけです。[1][2] 英語以外のインストール環境でもコードを動かしたいなら、
Application.International(xlDecimalSeparator)のようなプレースホルダーを使って、その関数に渡す文字列を動的に作る必要があり、コードの可読性は大きく低下します。この理由でコードが壊れると、エラーメッセージは信じられないほど役に立たず、開発者がそれをVBAの潜在的な問題だと知らなければ、再現自体が事実上不可能です。再現するには、知らないかもしれない言語にインターフェース言語を変更しなければなりません。少なくともWordでは、現在の段落の後ろに段落を挿入するなど、最も有用な関数の半分ほどが表セルの最後の段落で使うと壊れるため、スパゲッティ的な回避策が大量に必要になります。
DOM要素の
innerHtmlプロパティを参照するように、複数の書式を含むテキスト文字列を受け渡ししたい場合、ハック的なスクリプトベースの選択とコピー/貼り付けを使わない限り簡単ではありません。別のスレッドでBashと比較していた人がいましたが、実際その通りだと思います。どちらの言語でも複雑なものを書くべきではありません。
[1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
[2] https://stackoverflow.com/questions/29832281/vba-range-funct...
ただし、VBAが受けている嫌悪のかなりの部分がVBAプロジェクトの状態に由来するのも事実です（https://sancarn.github.io/vba-articles/why-is-vba-most-dread...）。
On Error Resume Nextのような誤った機能を含む環境を好意的に見られないのは、公平な見方だと思います。Excelとスプレッドシート全体について考えると、スプレッドシート言語がリアクティブ関数型プログラミングをどれほどよく実装しているかは、外部の人にはあまり理解されていません。React/Angularが10回以上のリリースにわたってきちんと実現しようと苦労している、まさにその部分です。
また多くの人は、エンドユーザーにとってスプレッドシートがなぜそれほど便利なのかを理解しておらず、その結果、実際にはより難しくしてしまう劣ったUIを提供しています。
ときには一歩引いて、グラフィカルUIがなかった時代でも昔の人々は正しくやっていたのだと理解する必要があります。初期の頃でもビジネスは回っていましたし、企業がほとんどの場合必要としているのは、表形式のビューと、その上でリアクティブな関数計算を行える選択肢です。中小企業で働く友人に聞けば、確認してくれるでしょう。