ＩＴを学ぶツールとしてのスプレッドシート

NewsPicksの取材をきっかけに、エクセルとGoogleスプレッドシートの主な違いをまとめてみました。

「国語・算数・プログラミング」の時代

非プログラマの方でも「プログラミングを学びたい」とか「子供にはプログラミングを学ばせたい」という方は年々増加しているようです。
元プログラマの人間として、この風潮は大歓迎です。
プログラミングは純粋に楽しいし、学校教育における既存の科目を学ぶだけでは得られない視点が必要だからです。
「国語・算数・プログラミング」の時代はすぐそこまで来ています。

しかし会計士・実務家としての立場からみると、プログラミングを職業とする予定のない社会人が、プログラミング教室に通って「Hello World」から勉強することが、本当に仕事やキャリア形成に役立つことかというと疑問を感じざるを得ません。
私は大学で「トルストイを原文で読んでやろう」と志してロシア語を選択したにもかかわらず、現実の授業は「エータストール（これは椅子です）」から始まることに愕然としてやる気を失った経験があります。

その点、エクセルは学べば学んだだけ実務に直結して役立てることができます。
どんな仕事に転職したとしても、エクセルはポータビリティの高いスキルです。
人材募集でも「VLOOKUP関数ができる方」という募集をみたことがある方も多いはずです。

さらにエクセルは陳腐化しにくいスキルです。
この日進月歩の時代において特筆すべきことです。
30年前のスキルは今でも通用しますし、30年後も陳腐化していないはずです。
理由のひとつは、マス目（セル）のインターフェースが会計報告に適しているからだと考えています。

「会計」というと「経理」を連想される方が多くいらっしゃいますが、会計専門家の立場からいうと、「会計とは、信じて任せてくれた人に『自発的』に報告すること」というのが本質的な意味になります。
会社で仕事をしていれば、どのポジションにおいても数字を使って、仕事を任せてくれた人に報告することになります。
数字を伴った自発的で自由な報告をするときに、白紙から資料を作成するより、縦横に罫線が引かれたエクセルを使った方が整理・作成しやすいのです。
このため私は「会計が続く限りエクセルはなくならない」と言っています。
ここでは「エクセル」と言っていますが、私がなくならないと言っているのはエクセルという特定のアプリケーションではなく、スプレッドシートのインターフェースを持ったアプリケーション全体を指しています。

ちなみに会計を根本で支えている「複式簿記」は、中世イタリアにおいて、数学者であるルカ・パチョーリによって体系化されてからほとんど変わることなく、現代の複雑な会計も処理することのできる、貴重なスキルのひとつだと思います。

エクセル vs Googleスプレッドシート

現時点において実務で使われているスプレッドシートには大きく2つあります。
ひとつはもちろんエクセル。
もうひとつはGoogleスプレッドシートです。
Googleスプレッドシートは後発で知名度もあまりなく、無料でも使えるため、エクセルの代替品とか廉価版のようにとらえられることも多いですが、さすがにGoogleが開発しているだけあってエクセルを超える機能も持っており、スプレッドシートの未来を感じさせてくれるアプリケーションに育ってきています。
もちろん上場企業の実務でも利用され、誰もが知っている有名企業での採用も増えています。
エクセルは確かにすばらしいアプリケーションなのですが、エクセルだけ見ていてもスプレッドシートが今後どのような使われ方をするようになるのかを予測することはできません。

以下、私の独断と偏見で「エクセル」と「Googleスプレッドシート」の違いをまとめ、スプレッドシートの未来を考えてみました。
スプレッドシートを勉強する際の参考にしていただければ幸いです。

クラウド対応の違い

エクセルはローカルのＰＣで動くことを前提に進化してきました。
もちろんエクセルができた当時は「クラウド」なんて言葉はなかったので当たり前です。
これに対してGoogleスプレッドシートは最初からクラウドを前提とした「クラウドネイティブ」なアプリケーションです。
確かに最新のエクセルもクラウドに対応していますが、それだけで「クラウドネイティブ」とはいえません。クラウドの特性を最大限に生かそうとする「クラウドネイティブ」というためには、どこかでローカルを前提としたエクセルとの決別が必要です。
一方のGoogleスプレッドシートは「ただのネット上のエクセル」ではなく、クラウドの特性を最大限生かそう、という設計思想が随所に感じられます。
ローカルを前提としたエクセルとは似て非なるものといえます。

クラウドネイティブなスプレッドシートを活用するとどんな未来が描けるのか、部門別予算実績管理を例に予想してみましょう。

＜前提＞
予算担当者から前期実績を反映させた予算入力シートを各部門に配布し、各部門で予算を入力後、予算担当者が回収、集計して取締役会に報告する。

＜エクセルを前提とした作業＞
・基幹システムから前期実績CSVをダウンロードする
・CSVを集計して部門別予算入力シートに貼り付ける
・予算入力シートを添付して、各担当者にメールする
・各担当者は添付ファイルをダウンロードして入力する
・予算入力シートを添付して予算担当者にメールする
・予算担当者は予算入力シートをダウンロードし全社分集計する
・取締役会用資料に集計結果を貼り付けて報告
・修正がはいると最初からやり直し

＜クラウドネイティブなスプレッドシートの作業＞
・クラウド上の基幹システムにリクエストを出すと、自動でクラウド上の各部門別予算入力シートに実績が反映される
・各担当者に入力シートの編集権限を付与し、入力期限を通知する
・各担当者の入力がリアルタイムで予算担当者の全社集計シートに反映され、取締役会資料にも自動で反映される
・入力担当者の修正があっても追加作業なし

現状ではこのとおりうまくいくとは限りませんが、クラウドネイティブなスプレッドシートを前提にすれば、確実に見える未来です。

エクセルを前提とした現状の作業をロボットにやらせて得意になっている会社もありますが、進化するテクノロジーの活用を真剣に考えないと何も解決しません。
PPAPに対応するRPAなんて、まるで冗談のようです。

今から10年以上前、脱炭素や交通事故の減少等、様々な社会的課題を解決するために電気自動車を選択したテスラを、多くの自動車メーカーがそんなものはいつでも作れると笑いました。
テスラがした電気自動車という選択を、単にエンジンをモーターに変えただけ、という風にしかとらえることができなかったのです。
スプレッドシートにも同じことが起きようとしています。
私はマイクロソフトがレガシーをある程度犠牲にしてでも、クラウドネイティブなスプレッドシートに舵を切らない限り、エクセルはガソリン車と同様、近い将来速やかにその地位を失うことになると考えています。

究極的にはあらゆる業務用アプリケーションとスプレッドシートがクラウドで繋がり、スプレッドシートで自由に表現した報告が、リアルタイムで必要な人とセキュアに共有できる、というのが私の描く未来です。

スピルとARRAYFORMULA関数の違い

私がエクセルの「配列数式」に出会ったのは、かれこれ10年近く前のことです。
当時、株式会社ＴＫＣが開発した、エクセルの関数でクラウド会計システムのデータベースを読み込む「マネジメントレポート設計ツール（ＭＲＴ）」という機能が大好きで、すべてのクライアントにこの機能を活用するよう薦めていました。
ただ、データが大量になると処理が遅くなることがあるのが玉に瑕でした。
クラウド上の会計データベースから情報を取ってくるんだから、セキュリティも含めて時間がかかるのは仕方ない、解決するにはマーフィーの法則に頼るしかないと諦めていました。

ところがある日、ＭＲＴを開発しているエンジニアとランチをしていた時、「エクセルの配列数式を使うと、ＭＲＴのスピードが劇的に改善できるんです！」という話を聞きました。
実際に使ってみるとすばらしいスピードでした。
通常、エクセルで１００ｘ１００の表を作ろうとすると、10,000の数式が必要になります。
ところが配列数式を使うとたったひとつの数式で済ませることができるのです。
エクセルとクラウドとのやり取りも、10,000回から1回に減少するイメージです。
スピードが速くなるのも納得ですね。
これはすばらしいと思って半年くらいかけて配列数式を学び、実務で活用しようと試みました。
しかし、配列数式を活用したＭＲＴは実務で役立つにもかかわらず、配列数式そのものは実務ではうまく活用できません。
エクセルの配列数式を使ったことのある方ならわかると思うのですが、とても使い辛いのです。
私ひとりが使うならまだしも、クライアントに引き継がなければならないようなシートにはとても使えない印象でした。
一番の原因は、配列数式を使う範囲をあらかじめ設定しておかなければならないという仕様でした。

そんなある日、Googleスプレッドシートでも配列数式を使えるということを知りました。
実際に使ってみるとこれが使いやすい！
理由は配列数式を使う範囲をあらかじめ設定する必要のない「動的配列」にあります。
クラウドネイティブなスプレッドシートの特性とあいまって、おもしろいように業務が効率化できました。
この時期は動的配列に対応できないエクセルの悪口ばかり言っていました（笑）
私のGoogleスプレッドシート講座でもエクセルの悪口を言っていたら、マイクロソフト勤務の方が受講していたなんてこともありました。

こんなに便利な動的配列に対応しないなんて、もうマイクロソフトはエクセルを見限ったのかな、それとも技術力がないのかな、なんて思っていたところ、2020年にMicrosoft365で「スピル」がリリースされました。
「スピル」というのは動的配列のマイクロソフト内の名称です。
早速スピルを使ってみるとこれが使いやすい。
Googleスプレッドシートでは動的配列を使うときにARRAYFORMULA関数を使う必要があり、数式が長く若干みにくくなるのですが、スピルは関数を使わなくても勝手に動的配列を認識してくれます。
さらに「スピル範囲演算子」という機能も実装されました。
スピルで動的に展開する範囲を参照することができるという超絶便利な機能です。
私の中で今現在、Googleスプレッドシートに欲しい機能ナンバー１です。
さらにちょっとマニアックな話で恐縮ですが、GoogleスプレッドシートではINDEX関数やSUMIFS関数という比較的よく使う関数で動的配列が使えないのですが、スピルでは使えるのです。
配列に関してはGoogleスプレッドシートのあらが目立つようになってきています。
さすがマイクロソフト！
悪口を言っていたことを、この場を借りて謝罪します。

マイクロソフトとGoogleはぜひ切磋琢磨して、スプレッドシート業務の課題解決を続けていただきたいと思います。

マクロの違い

マクロを学びたい、実務で活用したいという方はたくさんいます。
講座のアンケートでもよくいただきます。
お会いした方に「エクセルスキルはどのくらいですか？」と聞くと、「マクロもできます」と答える方もいらっしゃいます。

どうもみなさん、エクセルのゴール＝マクロ、と考えている方が多いようです。
誤解をしていただきたくないのが、マクロの勉強とエクセルの勉強は全く別物だ、ということです。
マクロが使えるからといってエクセルが使えることにはなりません。
ここは絶対に間違えないでください。
実際、ピボットテーブルで簡単にできることを知らずにマクロでやって、膨大な時間を無駄にするということもあります。
講座のアンケートで、「私はマクロも使えますが、関数でここまでできることを知り、目から鱗でした」というコメントをいただくと、この仕事をして本当に良かったと思います。
実務におけるエクセルが上達したいのであれば、まずマクロのことは忘れてしっかりエクセルの関数を学び、どうしてもエクセルでできない作業が見極められるようになった上でマクロを取り入れるようにするとよいと思います。

マクロはプログラミングですから、素人が見よう見まねで手を出すとちょっとしたことで誤動作する可能性のある危険なものだということも認識しておいてください。
私は元々プログラマでマクロも大好きです。
プログラミングを覚えたての若い頃は、エディタのマクロでオセロゲームを作り、先輩と対戦させたこともあります。
それでもマクロに関してはプロとは言えません。
業務でどうしてもマクロが必要な場合は、できる限り本物のプロに依頼すべきだと思います。
もちろん本物のプロを見極めるためには、ある程度の勉強が必要です。
このあたりのジャッジができない人材は、これから必要とされないと思います。

エクセルのマクロはＶＢＡ(Visual Basic for Applications)という言語を使っています。
一方、GoogleスプレッドシートのマクロはJavaScriptをベースとしたＧＡＳ(Google Apps Script)という言語を使っています。
どちらもスプレッドシート周辺業務を効率化するために手軽に使える便利な機能です。
私がよく使うマクロは、フォルダ内のたくさんのファイルから必要なところを抜き出してひとつのファイルにまとめる、といった作業です。
正直言って実務におけるマクロはこの程度ができれば十分だと思います。
同一ファイル内の処理はほとんど関数でできますし、それ以上のことをやりたいのであれば、マクロに頼らずシステム化を検討すべきです。

両社のマクロの違いについて、実際に使った感想を述べさせていただきます。
エクセルのマクロであるＶＢＡを独断と偏見で人間の言語に例えるとスペイン語かなと思います。
スペイン語を使う人は世界中にたくさんいますが、日本人が最初の外国語として学ぶかというと、よほど必要性がある人に限られるのではないかと思います。
これに対してGoogleスプレッドシートのマクロであるＧＡＳのベースとなっているJavaScriptは非常に人気の高い言語です。
人間の言語に例えると英語といってもよいかと思います。
プログラミングを職業にしたいと思っている方にもおすすめできます。
実際に私が使ってみてもＶＢＡに比べて洗練されている感じで、学んでいて楽しいです。

これも完全に私見ですが、エクセルが将来クラウドネイティブなスプレッドシートに転換を果たしたとして、マクロにＶＢＡが採用されることはないのではないかと思います。
どうしてもすぐに仕事で必要な方はＶＢＡ、そうでなければＧＡＳを学ぶのが良いのではないでしょうか。

プログラミング言語としてのエクセル

ここまでもマニアックな話をしましたが、もう少しマニアックな話にお付き合いください。
先日エクセルがLambda（ラムダ）関数を発表しました。
エクセルはこの関数によってチューリング完全、すなわちプログラミング言語としての仲間入りを果たしたのです。
Lambda関数により、今までエクセルでは実現できなかった真のループ（繰り返し処理）も可能になります。
これによりエクセルは世界で一番利用者の多いプログラミング言語になります。
これまで世界中の猛者たちがＶＢＡを使わずに、エクセルのテクニックを駆使してドラクエを再現したりして、本当にすごいなと思っていましたが、今後はエクセルの関数だけで普通にできるはず（？）です。
この動きにGoogleスプレッドシートも追随するはず、いや、必ずして欲しいと思っています。

でも待ってください。
たった一つの関数の出現で、ゼロから一気にプログラミング言語に昇格するわけではありませんよね。
ということは今までのエクセルも「準プログラミング言語」と呼べる存在だったのです。
しかし、エクセルはプログラミング言語、という感覚が今まで希薄だったのです。

すべての業務がＩＴを通じて提供される現代社会において、あらゆる産業でＩＴがコア業務となります。
「本屋さん × ＩＴ ＝ Amazon」を持ち出すまでもないでしょう。
こんな時代にＩＴスキルやリテラシーが重要といわれますが、これはすべての人にプログラマを目指せといっているわけではありません。

多くの企業が提唱しているように、今後は「テクノロジーの民主化」すなわち会社に所属するひとりひとりがテクノロジーを手足のように使いこなし、現場のその人にしかない視点を経営に活かす、ことが重要となります。
冒頭でも申し上げたとおり、プログラマを目指さない社会人が、仕事で使わないプログラミング言語をゼロから学ぶ意義は乏しいと考えています。
しかしエクセルという世界で最も利用者が多いプログラミング言語を、プログラミング言語らしく、体系的に学ぶことは「テクノロジーの民主化」への王道であり近道です。

今までなんとなく仕事に必要なエクセルだけを学んで満足していた方も、ぜひプログラミング言語としてのエクセルやGoogleスプレッドシートを学んでみてください。
エクセル教育を個人任せにしていた会社や組織は、ぜひ体系的なプログラムを用意してください。
エクセルを正しく勉強した人のＩＴリテラシーは確実に向上し、業務に役立てることができ、「テクノロジーの民主化」を実現できるはずです。

ＩＴに関して、日本は周回遅れとか、後進国とかいった論調が目立ち、悔しい思いもありますが、特効薬があるわけではありません。

まずはエクセルから始めましょう。

まとめ

これからの時代プログラミングスキルは必須
プログラミング　≠　コーディング
非プログラマにコーディングスキルが必要なわけではない
実はエクセル関数はプログラミング言語
マクロもプログラミング言語だが、コーディングが必要
クラウドネイティブなスプレッドシートでは、マクロを使わなくても実務で必要なことは何でもできるようになる
プログラミング言語としてのエクセルと、クラウドネイティブなスプレッドシートの特性を今から勉強しましょう。