※元々限定公開で社内向けに書いた記事を一般公開にしました。

Excel講座とは書いていますが、技術的な内容はほぼなく、主にExcelに対する考え方の話です。全て私個人の意見です。

はじめに

日本は資料を何でもかんでもExcelで作ろうとする文化が根強いなと思う。（ほかの国がどうなのかは知らないけど。）
確かにExcelはできることが豊富で便利なツールではあるが、Excelに依存しすぎることで組織・事業の成長を妨げたり、仕事をスムーズに進めることを妨げているケースが多々あるなと感じている。そうならないためには、Excel本来の目的や、メリット・デメリットを正しく把握して適材適所でうまく付き合っていくことが大事であると思う。

Excelとは

そもそもExcelが何のツールなのか。
Excelの存在を知らない人はあまりいないと思いますが、Excelが本来何のツールであるかを忘れている人は意外と多いような気もする。

とりあえず調べてみる。

Microsoft Excel（マイクロソフト・エクセル）は、マイクロソフトがWindows、macOS、iOSおよびAndroid向けに開発・販売している表計算ソフト。
（Wikipediaより抜粋）

なるほど。
では、表計算ソフトとは何なのか。

表計算ソフト（ひょうけいさんソフト、英: spreadsheet、スプレッドシート）は、数値データの集計・分析に用いられるアプリケーションソフトウェアである。
（Wikipediaより抜粋）

とのこと。
つまり、Excelは数値データの集計や分析が必要な資料を作成する際に使うツールとなります。

集計や分析が必要ない資料にも関わらず、Excelを使って作られている場合、使い方として適切ではないということ。計算の必要性がない資料の場合、たとえExcelで見やすい資料が作れたとしても、それが最適解ではない可能性が高いということ。

Excelで作ることが向いている資料

先に述べた通り、Excelは表計算ソフトなので、データの集計や分析が必要な資料を作成するのには向いている。ただし、計算が必要な資料だったとしても、条件によってはExcelは不向きとなる。

他人との共有が発生し、更新頻度が高い場合

Excelで作った資料を自分以外の人と共有し、互いに修正する可能性がある場合、Excelで作るのは向いていない。ファイルとして作成してしまうと、他人と共有するにはメールやチャットで添付したりする必要があり、更新頻度が多いと毎回共有するのがとても面倒である。（パスワードがかかっていたりするとなおさら）
共有される側も毎回ダウンロードする必要があり、とても面倒である。
共有フォルダを利用すれば、毎回添付して送る手間は省けるが、ダウンロードする側の手間は変わらないし、複数人で編集する可能性がある場合、中身が上書きされるなどのリスクもある。

他人との共有が必要で、更新頻度がそれなりに高い資料の場合、GoogleスプレッドシートなどのWeb上で共有が簡単にできるツールを使う方が望ましい。

一応ExcelにもWeb版が存在するが、使い勝手はGoogleのスプレッドシートに比べるとかなり悪く、かつMicrosoftのアカウントも必要になって何かと面倒なため、Web上で共有するなら圧倒的にスプレッドシートの方がおすすめ。ExcelファイルもGoogleドライブにアップすればスプレッドシートで開くことが可能だが、どうせスプレッドシートで開くのであれば、最初からスプレッドシートで作成した方が全体的に使い勝手は良い。

ファイルが分割されてデータが管理される場合

Excelはファイルが分割されてしまうと本来の目的（集計や分析）さえも難しくなってしまう。

例えば、社員の勤怠情報をExcelで管理しており、社員ごとにファイルが分かれて保管されているケースを考える。その場合、組織全体の残業時間の平均を出したいと思うとなかなか大変な作業になる。
社員ごとのファイルを参照する形で新しいExcelファイルやシートを作成すれば実現することは可能だが、人が増減した場合でも修正なしに対応できるような柔軟性はないだろうし、ちょっとしたファイルの移動や削除で中身に影響が出て、メンテナンスがしにくい資料になる可能性が高い。

Excelは確かに集計や分析には向いているけれど、ファイル単位でデータが分割される場合、データ管理ツールとして使うのは不向きである。
一定量以上のデータを管理して、後々集計・分析する可能性があるのであれば、システム化を検討してデータベースにデータが蓄積される仕組みを作るのが根本的な解決策になる。

Excelで作るのが最適な資料

ここまでの話をまとめると、以下のようになる。

Excelはデータの集計・分析のためのツールである
Excelは他人と共有して共同編集するには向かない
Excelはファイルが分かれると集計・分析も難しい

つまり、Excelで作るのが向いている資料は以下のようになる。

計算処理（集計や分析）が必要
自分ひとりで完結している(他人に共有しない、共有するとしても編集するのは1人)
必要な情報がファイル単位で閉じている（ファイルを分割するデータ管理が発生しない）

これらの条件に当てはまらない場合は、Excelを使うことは向いていないか、少なくともExcelが最適なツールではないと認識していた方が良いかと思う。

開発ドキュメント

ソフトウェア開発では、開発ドキュメントの作成でExcelが使われている現場も多い。
ここでは開発ドキュメントや、開発工程の中で作成される資料がどの程度Excelと親和性が高いのか整理してみる。

開発ドキュメントとExcelの相性

要件定義書
- 計算の有無：×
- 表形式である必要性：×
設計ドキュメント
- 計算の有無：×
- 表形式である必要性：△（画面の項目定義など、内容によっては表形式の方が見やすい）
テーブル定義書
- 計算の有無：×
- 表形式である必要性：〇
テスト仕様書
- 計算の有無：△（合格した件数、失敗した件数など、簡単な集計はあり得る）
- 表形式である必要性：〇
課題管理表
- 計算の有無：×
- 表形式である必要性：△（テキストベースの一覧でも問題はなさそう）

表形式であることで見やすくなっている資料は確かにあるが、少なくとも複雑な集計や分析が必要な資料はない。
Excelならお手軽に見やすい作成できるという点は納得できるけれど、計算が必要な場面はほとんどない以上、Excelが最適とは言い難い。

少なくとも、開発ドキュメントは開発チーム間で共有されるものであり、複数人が編集する可能性もあるので、最低でもGoogleスプレッドシートなど、Web上で共有できるものにはしておきたい。
表形式である必要すらないドキュメントは、WikiやNotionなど、マークダウンがサポートされていてテキストベースで作成・共有できるツールの方が適していると思う。

他にもスケジュール管理表などをExcel使って行うケースもあるだろうけれど、それらはプロジェクト管理ツール等で既に最適化されたものが存在しているので、ここでは対象外にした。

ドキュメントの在り方を考える

開発系のドキュメントでExcelを使っている場合、そもそものドキュメントの在り方を一度考え直してみても良いかもしれない。ドキュメントの目的や在り方を明確にし、そのうえで対象ドキュメントを作るのに最適なツールを選定すると開発がスムーズに進めやすくなるかと思う。

本音を言えば、テーブル定義書はDDLがあれば不要だと思うし、テスト仕様書はテストを自動化して「テストコード＝テスト仕様書」の形にしてしまうのが理想だと思う。
実際、そのような考えでほとんどドキュメントを作らない開発現場もある。

ただ、受託開発案件の場合は成果物としてドキュメントの納品が求められることもあるし、案件によっては参画しているメンバーの力量などの都合でドキュメントが必要になる場面も少なくない。
とはいえ、設計ドキュメントを詳細まで書きすぎると、仕様変更があった際にコードとドキュメントの両方に修正が必要になって管理コストがかかるので、いい塩梅でその案件に適したドキュメントの在り方を最適化することが重要になる。

コードとドキュメントの2重管理のコストを減らすには

コード → ドキュメントの生成
ドキュメント → コードの生成

のように片方から自動生成できる仕組みがあればよいが、Excelの場合だとなかなか難しい。
（DB設計 → DDLの生成とかなら簡単にできそうだけど）

仕様変更があった場合には必ず先に設計ドキュメントを修正し、確認後にコードを修正するフローを徹底すればドキュメントとコードの差異は極力抑えることが可能ですが、その場合はドキュメントの差分だけが簡単に確認できた方が良いため、テキストにしてGitで管理する方が良いだろう。

いずれにしても、まずはドキュメントの目的を明確にし、そのうえで2重管理が極力発生せずスムーズに開発が進む運用方法を考えていくことが大事かと思う。

Excelで読みやすく保守しやすい資料の作り方

個人的にはExcelで作成することが向いている開発ドキュメントはほぼないと思っているけれど、案件の都合でどうしてもExcelを使用しなければいけないという場合のために、個人的に思っているExcel資料作成のコツにも触れておきます。

Excelとプログラミングの共通点

Excelの資料作成とプログラミングの共通点は？
と聞かれたらあなたはどう答えますか？

私は、Excelの資料作成とプログラミングは実はほとんど同じであると思っている。

セル → データを格納する箇所 → 変数
行および列 → セルの集まり → 変数の集まり → 配列（リスト）
表 → 行 × 列 → 配列 × 配列 → 2次元配列

セルを変数、セルの集まりを配列として考えると、「セルにデータを入力して最終的なアウトプットを作る」ことと「変数に値をセットして結果を出力する」ことは同じことのように思える。

「Excelの資料作成 = プログラミング」と捉えると、コーディングのテクニックはそのままExcelの資料作成にも適用できる。

例えば、コードをきれいに書くコツの代表例と言えば変数名や関数名をわかりやすく命名する、というもの。
このコツはそのままExcelにも適用することができる。
Excelではセルやセルの集合に名前を付けることができる。
式が複雑になる場合はセルに分かりやすい名前を付けたり、計算の途中結果を別のセル（変数）に分けて格納しておくことで読みやすい式を作ることができ、メンテナンスもしやすくなる。

エンジニアにとってはExcelでの資料作成のコツよりもプログラミングスキルの方が重要なので、コードの書き方に関するスキルを身に着け、その知見をExcelにそのまま転用してしまう方が効率よく成長できるように思う。

開発中にExcelが役に立つ場面

Excelを資料作成のためのツールと捉えてしまうと、先に述べた通り「自分だけしか見ない計算が必要な資料」くらいしか本当の意味で役に立つ場面はない。
ただ、データ変換・生成ツールと捉えると、開発現場において使える場面は結構ある。

例えば、Excelを使うと以下のような作業が簡単にできる。

CSVファイルを大量に作成する
CSVファイルをSQL（INSERT文）に変換する
SQL（INSERT文など）を大量に作成する
横並びのデータと縦並びのデータを入れ替える

などなど。

開発の仕事をしていると、大量のテストデータを作らないといけない場面が多々ある。
そんな時、Excelをデータ変換・生成ツールだと考えると、かなり使える優秀なツールになる。

エンジニアとしては、Excelでの資料作成を上達するために学習コストを割く必要はないんじゃないかと個人的には思うけれど、Excelをデータ生成ツールとして使いこなすために学習コストはかけて勉強する分には損はないと思う。

※Googleスプレッドシートでもほぼ同じことができるので、そっちで使い方を学習しても良いかもしれない。

Excelの知識をどこまで学ぶべきか

Excelには膨大な機能があり、関数やマクロ（VBA）まで含めると、使いこなすにはかなりの知識が必要になる。
業種・職種によってはExcelの高度な知識を持っていた方が良い場合もある（事務系の仕事とか、コンサルの仕事とか）が、エンジニアとして開発の仕事をしていくうえで必要になる知識はそれほど多くないと思う。
自分の作業が効率化できる程度の知識を絞って学習するのが良いかと思う。

Excelの機能

機能に関して、先にも述べた通り、データ変換・生成ツールして使いこなせるための最低限の知識は身に着けた方が良いと思う。
Excelでデータを作成したり変換するには、オートフィルやセルのデータを文字として扱う(先頭にシングルクォーテーションを付ける)などの最低限の知識はないとつらいので、そのあたりの知識は最低でも知っておきたい。

資料作成の知識

資料作成に関しては、先にも述べた通りプログラミングのコツを転用できる部分も多いので、無理に学習コストをかける必要はないと思う。
特別にやりたいことがあってもAIやインターネットを駆使すれば簡単に見つけられる。

関数

集計・分析に関しては、SUM、COUNT、COUNTIFなど、テスト仕様書での簡単な集計ができるレベルの関数は知っておきたい。
今は様々なシステムでExcelにデータをエクスポートする機能が付いているが、そのような機能で出力されたExcelに対して関数を使って簡単な集計や分析ができると一つの強みにはなるかもしれない。（コンサルとか目指すなら活きる知識になるかも）
ただ、データベースに直接アクセスできるなら権限があるのであれば、SQLで分析できるスキルの方がエンジニアにとっては有意義なスキルかと思うので、どちらかというとSQLの方に学習コストをかける方が良いだろうと思う。

マクロ（VBA）の問題と使いどころ

Excelにはマクロ（VBA）という機能が存在する。
IT業界以外の人には（いや、IT業界の人でも）普段からExcelを使っているけれど、マクロの存在は知らなかったという人は意外と多い。
マクロは使いこなすと実に色んなことができ、学習したばかりのころは「Excelでこんなこともできるのか！」と感動すら覚える。

ただ、Excelとマクロは、この「何でも出来てしまう事」が大きな問題だと思う。

マクロの問題点

Excelとマクロを使うと、手動で管理していた作業も「なんちゃって自動化」ができてしまう。本来はシステム化してデータベースにデータを蓄積した方が後々活用の幅が広がるようなデータだったとしても、マクロを使ったことですべてのデータがExcelにしか蓄積されない状態が起きてしまう。１つのExcelファイルで全てのデータが閉じている状態であれば問題ないが、ファイルが分割されてしまうと、全体のデータを使った分析・活用は非常に難しいため、結果として業務の改善活動自体が難しくなってしまう。

今の日本はデジタル敗戦国と言われ、この先少子化・高齢化の流れを考えると様々な業種でDXを加速していくことが急務だと言われているが、目に見える範囲だと思ったほどDX化は進んでいない。本当の意味でのDX化を行うには、データを活用していくことが必須になるが、そもそもデータがExcelに蓄積されている状態では活用することすらままならない。

何でもかんでも資料をExcelで作成し、そのうえマクロを使ってExcelでデータ管理している組織が多いことが、日本でDX化が進まない1つの要因になっているのではないかと個人的には思っている。

マクロは短期的には非常に便利な機能だが、安易に使用するのではなく、長期的にはデータをどこに蓄積すべきなのかを考慮したうえで慎重に判断することが必要だろうと思う。

マクロ（VBA）の使いどころ

個人的には、Excelファイルを編集する際に面倒だと感じる場面で使い捨て用のプログラムとしてマクロを使用するのが良いかと思う。
例えば、1つのExcelファイル内にシートが大量に存在するとする。
そのシートを順番良く並べ替えようと思うと、手作業で行うのはかなり時間がかかる。
こういう時、VBAを使ってシート並び替えのプログラムを作成することで、手動で編集する時間を短縮することができる。
実質1度しか使わない使い捨てのプログラムということになるが、VBAの使いどころはそのくらいだと認識しておいた方が良いだろうと思う。

VBAは他のプログラミング言語に比べてメンテナンス性が高い言語とは言えないので、何でもやりすぎると後々の保守が大変になってしまう。
何より、VBAに頼りすぎることで本来システム化すべきものをExcelで管理してしまう方が長期的には損失が大きい。

VBAを使い捨てプログラム用の言語だと捉えると、基本的なプログラミングスキルさえあれば、ChatGPTなどのAIにプログラムを生成してもらうだけで十分対応できるので、無駄に学習コストをかける必要もなくなる。

最後に

計算の必要がないのにExcelが使われていたり、DBで管理した方が良いはずなのにExcelが使われていたりと、適切でない使われ方をしていることに対して特に違和感を持たない人も多いかもしれません。そこに違和感を感じない人が多いこと自体が、多くの日本の組織の課題だと個人的に思っています。

私自身、元々そういう考えだったわけではなく、昔はExcelをすごく便利だと感じていて、使いこなすためにある程度勉強もしてきました。
様々な現場、及び組織でのドキュメントもExcelを多用しており、そこに違和感も感じていませんでした。
しかし、年数がたって講師やエンジニアを続けていく中でExcelの目的や課題を次第に意識するようになり、最近はExcelを使わなければいけない場面は、改善の余地がある危険信号だと認識するようになりました。

地味に影響が大きかったのは講師をしていたころに使っていた成績管理のExcel。
その成績管理のExcelは教室単位でデータが閉じた状態になっているため、過去の研修をさかのぼって検索・分析したり、他の教室の状況を把握することもできませんでした。
そのころから、情報量の多いデータ管理は早めにシステム化するべきだと思うようになりました。

また、仕事で使用していたWindowsのPCが使えなくなってMacに切り替えた時、MacのExcelでマクロが正常に動作せずにとても面倒な思いをしました。
アシスタントとファイルを共有するときもSlackで都度添付して共有していたので（共有フォルダはあったが研修生も使用していたので、ファイルのやり取りにSlackを使っていた）、共同編集もしにくく非常に面倒でした。
このころから業務でExcelを使うことが嫌になり、Web上で簡単に共有できるツールを好むようになりました。

講師をしていたころ、事務員の方たちにExcelを教える仕事をしていたこともありました。
そのころから、Excelの資料作成とプログラミングは共通点が多いなと思うようになりました。

自分の経験の中で多くExcelと触れてきたことで、Excelのメリットやデメリットなどが色々と見えてきて今の考えになりました。
ここに書いてあることはあくまでも私個人の考えですが、現状を良くするためのきっかけとして何かプラスになるものがあれば幸いです。

まとめ

Excelは表計算ソフト
Excelで作るのが向いている資料の特徴
- 計算が必要
- 自分１人しか編集しない
- 必要なデータが1ファイルで閉じている
開発ドキュメント
- 共有の必要がある場合はGoogleスプレッドシートがおすすめ
- 表形式である必要がないならWikiやNotionがおすすめ
- ドキュメントの目的を明確にした上で何で作るか検討したい
Excelをデータ生成・変換ツールと捉えると開発に役立つ
マクロを使っていいのは使い捨て用のプログラムを作りたいときだけ
データ管理が複数ファイルにまたがる場合はシステム化を検討すべし
Excel・マクロの使い過ぎが日本のDXを阻害している（たぶん）

おすすめ書籍

外資系投資銀行のエクセル仕事術

Excelに関する書籍の中で個人的に一番良書だと思った本。
どうしてもExcelを使わないといけない現場で洗練されたExcelの資料が作れるようになりたいという人にはおすすめです。

Software Design 2024年10月

ドキュメントの在り方の部分で参考にしました。
Excelとか関係なく、設計ドキュメントをどんなツールでどの粒度で作るべきか、など設計ドキュメントに対して悩みがある方にはおすすめです。

リーダブルコード

Excelの資料作りのコツよりもコードの書き方を先に学びましょう。
エンジニアなら一度は読んでおきたい。

具体と抽象

似ているものの共通点を抜き出し、個別の法則を別の事象に適用するための思考法を学べます。
Excelとプログラミングが似ているという例は私個人の考えでこの本に書いてあったわけではありませんが、この思考法のおかげでプログラミングとExcelが似ていることに気づき、知識を転用できることに気づけました。