スプレッドシート使用に関する私のルール

そして今、すべては私が言ったこと、そしてそれが間違っていた、あるいは誤解されたということです。 次の投稿 前の投稿 スプレッドシート使用に関する私のルール 2026年8月1日 午前10時29分 Dr. Drang 著 私の基本的なルールは「使うな」ですが、一言ではブログ記事になりません。以下では、私がどのようにしてそのルールに至り、どのような例外を設けているかを説明したいと思います。 最近、スプレッドシートをどのように使用し、使用しないかについてかなり考えてきました。この内省は、Allison Sheridan氏のMacstockでのプレゼンテーション（彼女のサイトで他の最近のスプレッドシートに関する投稿とともに見ることができます）と、差分テーブルの作成やデータテーブルの整理のためにNumbersを使用した最近の経験に触発されました。 まず、スプレッドシートがなぜそれほど魅力的であるかを考えてみましょう。すぐに、データコンテナとして機能するセルのグリッドが表示されます。これらのコンテナを定義する必要はなく、名前を付ける必要もなく、初期化する必要もありません。ただそこにあり、必要に応じて記入するのを待っています。このデータに対する操作を開始する際にも、セルの名前を付ける必要はありません。クリック（またはドラッグ）するだけで、関数引数を入力できます。スプレッドシートアプリは、適切な行/列参照を入力します。セルの目的のリマインダーが必要な場合は、隣接するセルに名前や説明を入力できます。同様に、操作の適切な順序を理解する必要はありません。アプリはセルの依存関係チェーンを処理し、すべてをどこでも一度に再計算します。そして、各セルのサイズ、色、境界線、フォントスタイルを設定できるため、スプレッドシートはレポート、メモ、スライドショーに挿入するための見栄えの良いテーブルを生成できます。つまり、スプレッドシートはデータストア、ロジックマシン、プレゼンテーションツールなのです。理解できましたか？ しかし、スプレッドシートがそれらすべてであるなら、なぜ私の「使うな」ルールがあるのでしょうか？多くの源がありますが、過去10〜15年間の私の仕事人生に強く影響されたと言わざるを得ません。その間、私はExcelスプレッドシートとして送られてきた数十、数百ものデータセットを分析しなければなりませんでした。私にスプレッドシートを送ってきたエンジニアリング会社は、それらを単なるデータストアとして作成したわけではありませんでした。彼らは独自の分析を含め（通常は私の分析とわずかに重複していました）、スプレッドシートをレポートに挿入するためのテーブルとしてフォーマットしていました。これはいくつかの理由で私の仕事を困難にしました。 1. 彼らの分析を理解し、同意する必要があったため、すべての数式を確認する必要がありました。これらの数式の中には複雑なものもありました。ネストされたIF文は、従来のプログラミング言語では理解しやすいですが、スプレッドシートでは混乱します。一部は一貫性がありませんでした。同じテーブルの異なる行が異なる数式を持っていたり、まるで異なる人々が異なる時期に作成したか、または以前のプロジェクトのスプレッドシートから適応されたかのようでした。一部は遠く離れたセルを参照しており、追跡するには多くのスクロールが必要でした。10年以上経っても、数式を理解しやすくするためにセル名を使用したものは一つもありませんでした。 2. 上記の複雑な数式には、時々（頻繁ではありませんが、時々）間違いが含まれていました。そして、数式が正しい場合でも、ヘッダーセルの説明が間違っていることがありました。これは、不一致を解決するために電話が必要になり、分析をさらに遅らせました。 3. データが2つ以上のシートに分割されていることがよくありました。これは主に、テーブルが他のエンジニアのレポートにうまく収まるようにするためだったと思いますが、それは彼らの目的には合っていましたが、私の目的には合いませんでした。分析のためにデータを再結合する必要がありました。また、シートにはしばしば複雑で複数行のヘッダーがあり、CSVファイルとしてエクスポートするだけでは済まなくなりました。 4. 私が一緒に仕事をしたすべてのエンジニアは、それぞれ異なる方法でスプレッドシートを構築していました。同じ会社で働いていた人々でさえ、「ABCエンジニアリング」のようなハウススタイルに従っていませんでした。個々のエンジニアでさえ、プロジェクトごとにスプレッドシートのスタイルを変更していました。基本的に、受け取ったすべてのスプレッドシートは唯一無二であり、すべてのデータクリーニングを手作業で行う必要がありました。これは、このステップで自動化に頼ることができなかっただけでなく、コピー＆ペーストの間違いを避けるために作業を二重、三重に確認する必要があったため、私の作業を遅らせました。 根本的に、この経験、特に項目1は、大規模または複雑なものに対するスプレッドシートの使用を私に嫌悪させました。私が一緒に仕事をしたエンジニアは賢かったのですが、彼らのスプレッドシートは賢くありませんでした。私の結論は、典型的なクリック＆ドラッグ方式でスプレッドシートを構築する容易さが、スプレッドシートが成長したり新しいデータに適応されたりするにつれて、悪い組織化とエラーを助長するということです。簡単に「ああ、私はそんなことはしないだろう」と言うことができますが、私は自分がそうするだろうと知るほど年をとっています。今日のアプリでスプレッドシートを簡単に構築できることは、私を岩礁に導くセイレーンの歌のように感じます。（もしあなたがReinhart/Rogoff論文について私に書き込もうとしているなら、安心してください。それは初歩的なスプレッドシートエラーの典型的な例です。2人のハーバード大学教授が決してしないであろうエラーであり、不必要な緊縮財政政策の多くの苦しみにつながりました。そして、もしあなたがReinhartとRogoffのエラーが彼らの結論の基本的な真実を無効にしないと私に書き込もうとしているなら、黙っていてください。） データと分析ロジックが同じドキュメントにあるという利便性は、特にそれらがサイズで異なる複数のデータセットにそのロジックを適用する必要がある場合に問題となります。スプレッドシートテンプレートは、データが同じレイアウトの複数のスプレッドシートを作成できる場合に役立ちますが、私が扱うデータはそのような厳格なパターンには適合しません。例えば、複数の時系列の分析とプロットを行っている場合、それらの系列が同じ期間や同じデータポイント数に及ぶことはめったにありません。ロジックがプログラム内にあり、データから分離されている場合、これらのサイズの違いを処理する方がはるかに簡単です。 スプレッドシートのもう1つの問題は、保持できるデータ量が他のデータ分析ワークフローを使用する場合よりも制限されることです。スプレッドシートのサイズ制限は確かに非常に大きいですが、ビッグデータの時代には「非常に大きい」では十分ではないかもしれません。Allison氏がMacstockでの講演で、米国の赤ちゃん名前データセットを処理する際にその問題に遭遇した方法を示しました。 そのデータセットを処理する方法の1つは、ZIP圧縮されたCSVファイルのコレクションとしてダウンロードすることです。コレクション内の各ファイルは1年に関連付けられており、yob1960.txtのような名前が付いています。内容は次のようになります。 Mary,F,51472 Susan,F,39208 Linda,F,37316 Karen,F,36378 Donna,F,34138 [以下略] ここで、最初の項目は名前、2番目は性別、3番目はその年にその名前が付けられた赤ちゃんの数です。行はまず性別、次に数で並べられています。すべてのファイルを連結すると、2,181,032件のエントリがあることがわかります。Allison氏が発見したように、これはExcelスプレッドシートには収まりません。Excelは1,048,576行に制限されています。これは非常にコンピューター的な数値である2^20または1024^2です。Numbersの制限は、よりコンピューター的ではありませんが、より人間的な1,000,000行です。 Allison氏は…ええと…ずるをしてサイズの問題を回避しました。彼女は人気のない名前を削除してリストをExcelに収まるようにし、その後ピボットテーブルの操作を実演しました。ビデオの1:13:50あたりから見ることができます。 私は彼女の作業と同様のことを、ずるをせずにやろうと決めました。まず、個々のファイルを1つの大きなCSVファイルに連結し、年フィールドも含めました。これは以下のシェルコマンドで行われました。 ```bash echo 'Year,Name,Sex,Count' > all-years.csv for f in yob*.txt; do y=${f:3:4} sed -e "s/ $//;s/^/$y,/'" $f >> all-years.csv done ``` 年はファイル名から部分文字列展開によって抽出され、sedコマンドによって各行の先頭に追加されます。元のファイルはWindows形式でCRLF改行コードを使用しているため、sedコマンドはCRも削除します。