「表計算ソフトって」

はじめに

告白する。 私は、どうも人より相当頭が悪いらしく、 まがりなりにもコンピュータのプロというか、 プログラマで飯を食っている身の筈なのであるが、 いわゆる「表計算ソフト」というのが 何がなんだかさっぱりわからないのである。

とはいえ、周りには、Excel大好きな人一杯である(いや、もちろん、 Excelばかりが表計算ではないが、やはり既に代名詞にはなってしまっている)。 不思議なことに、表でもなければ計算もしない文書を作るのにさえ、 Excelを使う人が後を絶たない。 フツーの文書を作るのなら、「表計算」ソフトじゃなくてワープロだろう、 と思うのだが...

# え? Wordは使いにくい?
# ごもっともです。全面的に賛成します(切実)。

Excel使っている人は、口を揃えて「こんな便利なものはない」と言う。

でも、やっぱり、私にとっては、 「何がなんだかわからない」 のである。

以下、私の、「表計算ソフト」についての疑問を、 つらつら書いていこうと思う。

典型的な(?)例

表計算ソフトの典型的な使用例というと、下図のようなものだと思う。

典型的な例

一応、家計簿のつもりである(家計簿って付けたことがないので 実はよく分かってないけど)。

見るからにExcelに最適の表?

確かに、こういう表をExcelに入れれば、差引残高は自動計算してくれるし、 支出の各項目も加算してくれるし、それを円グラフにするのも思いのままである。 確かに便利である。便利なのは百も承知なのだが...

しかし、私には、ここで、大量の疑問符が点灯してしまうのである。

このシートを見ると、まず1行目は、表自体のタイトルである。 そして、2〜3行目は、各列の説明である。 そして、4行目になって、ようやく表の本体が始まる。

何故、これだけ異質な項目に、1, 2, 3, 4, 5... という連番が、無造作に振られているのだろう? 表の本体は、(見掛け上の)4行目から始まるのだから、 当然この行が1行目(FORTRAN流数え方)になると思うのだが。

1行目の「7月分収支」という文字列は、(見掛け上はぶち抜きだが) データとしてはA1に入っていると思うんだけど、それは何故? それどころか、人によっては、D1あたりにさくっと書いてくれたりするんだけど、 「表全体の説明」が、なんでそんな所に?

3行目に書いてあるのは、結局支出の内訳なんだけど、 だとすれば、それは、(多分D2に入っている)「支出」と、 何らかの親子関係を持っていなければならない筈なんだけど、 それはどこにあるんだろう?

A3, B3, C3, H3の空欄は、何?

B1〜H1, E2〜G2は、空欄にゃ見えないが、やっぱり空欄なんだろうか?

おまけに、人によっては、小さい表だと、A1から書き始めずに、 シートのド真ん中にいきなり書いてくれたりするし...

もう、さっぱり、わけがわからん。

「シート」を、データ構造として見る場合

ここまで読んで、

「おお、そうだ、俺もそう思っていた」

という方と、

「そんなことを「わけがわからん」という、お前の方がわけがわからん」

と思う方とがおられると思う。

そして、後者の方が圧倒的に多そうな気がする。

というわけで一応説明しておくと、曲がりなりにもプログラマである私から見ると、 Excelのシートというのは、「2次元配列」に見えるのである。

いったい、理性のあるプログラマなら、この家計簿を表現するのに、 こんなふうに何もかもひとつの2次元配列に突っ込もうとするだろうか? 例えば、Visual Basicなら、Variantの2次元配列にすれば、 そりゃ何でも入るだろう。 JavaならObject、Cなら、void*の2次元配列だろうか。 だからって、(CやJavaの書き方で)a[0][0]に「7月分収支」 という文字列を突っ込んで、その月最初の収入をa[2][3]に突っ込むような プログラムを書いてくるバカがいたら、 私が上司なら、即刻書き直しを命じる。 だいたい、経験を積んだプログラマなら、VariantだのObjectだのvoid*だのは、 出来るだけ使わないようにするものである。

# だから、ObjectでしかCollectionを実現できない最近流行りの某腐れ言語は...
# というのは次回以降のネタに取っておこう。

だいたい、何らかのデータ構造を表現するのに、 「任意のデータ型からなる2次元配列」を複数個持てる(Excelは、「ブック」の中に シートを複数個持てる)だけ、というのは、ひどく貧弱ではないだろうか?

# 世の中には、リレーショナルデータベースなんてものがあるけれど、
# あれは、Cで言えば、構造体の(順不同)配列になると思う。
# 列毎の定義がちゃんとあるので、Excelとはワケが違う。
# ま、あれはあれで、ずいぶん不自由だと思うけど。

表計算ソフトの機能の目玉は、複数のデータ間に「制約」を持たせ、 あるデータが書き換えらえると、その制約にもとづいて、 あらゆる値が整合性を保ったまま再計算される所にあると思うのである。

その場合、データ構造は、2次元配列だけで足りるのだろうか?

いわゆる、「事務計算」の世界には、2次元の表が非常に多いことは認めるが (というか、2次元の表でなければ紙の上に表現できなかったから こうなったと言うべきか)、 例えば、買物毎にポイントが貯まり、いくらか貯まったら割引してくれるような サービスがあったとして、

「お客さまのポイントが a を超えましたので、今回のお買い上げ額 b円から c円値引きさせていただきます」

というごく簡単でありがちな帳票があったとする。 この、a, b, c の間には、式で簡単に表現できる制約がある。 自動で再計算してくれれば便利だと思う。 では、これを、Excelで作ろうと思ったら、どうすれば良いのだろうか?

「シート」を、レイアウトとして見る場合

とまあ色々書いたが、世間の多くの人は、表計算ソフトの「格子」を、 「2次元配列」ではなく、「レイアウト用紙」として見ているのだと思う。

「2次元配列なんて、そんなものは知らん。 Excelのシートは、自動で計算してくれる魔法のレイアウト用紙だ」

という考え方である。

しかし、レイアウト用紙として見るなら、 紙の端から端まで、単一の格子がぶち抜きになっているExcelの構造は、 極めて不自由ではないだろうか?

Excelのシートを「紙」として見るなら、ひとつのシートに複数の 表が入っているのは、ごく自然な話である。 たとえば、こんな、ありふれすぎていて例に出すのもはばかられるような レイアウトを、Excelで表現しようと思ったらどうすれば良いのだろうか?

やっぱり典型的な例

手元に、インプレスの「できる Excel97」という 恥ずかしい本があるので、一応調べてみたが、 載っていないようである(できるの?)。 この本には、複数の表を入れたシートの例もいくつか載っているが、 どれもわざとらしくタテ線がきれいに揃った例ばかりである。

「ここまでやりたかったらさー、Wordに貼ればいいんじゃない?」

多分それが正しいのだろうと思う。(「ここまで」と言われるほど特殊な例か?)

なら初めから、それを前提とした設計になっていればいいのに。 Excelは、純粋に、縦横格子の表を作成するツールに徹して、 レイアウトその他は、Wordなどに任せるような設計になっていれば、 私もこんなに悩まなくて済んだだろうと思う。

ところが、Excelは、バージョンが上がるにつれ、 レイアウトの機能がどんどん進化している。 しかも困ったことに、これがWordなんぞより はるかに高機能であったりするもんだから、 誰も彼も、「何でもかんでもExcel」になってしまうのである。

何ページもあるような仕様書(表なんぞ一個も入っていない)を、 全部Excelで書いて、 1ページをひとつのシートにして、それはそれで便利だったんだろうが、 「気持ち悪くないのか?」 という疑問を持たずにはいられない。 特に相手がプログラマであった場合には。

それでは

結局のところ、私が表計算ソフトに対して違和感を持つのは、 プログラムを起動すると、いきなり「はじめに格子ありき」 で始まるところにあるのである。

格子だから、2次元配列かと思うと、そうでもない。

じゃあレイアウトかと思うと、確かにそんな感じなのだが、 それにしては不便すぎる。 レイアウトなんて書く人の勝手の筈なのに、 なんでそれがはじめから格子に縛られていなければならないのか。

私から見ると、計算したい表の「データ構造」と、 それを紙の上に表現する際の「レイアウト」とは、 全く別のものであるように思えるのである。 ちょうど、LaTeXやHTMLが文書の論理構造とレイアウトを分離しているように。

先の家計簿の例なら、データ構造としては、(Cの言葉で言えば) 「構造体の配列」である。 これが、何らかの「レイアウト規則」に基いて、 紙の上にマッピングされると考える方が自然ではないだろうか?

データ構造は、何も構造体配列や2次元配列に限らない。 先に挙げた、 「お客さまのポイントが a を超えましたので、今回のお買い上げ額 b円から c円値引きさせていただきます」 のような例なら、関係式で制約された3つの変数だろうし、 3次元以上の配列になることもあるだろう。 Excelでは、一応「串刺し機能」で、3次元のデータ構造を扱うことはできるが、 2次元配列であるシートを寄せ集めて3次元のデータ構造を表現するより、 初めから3次元のデータ構造を作っておいて、それを (2次元しか表現できない)紙の上にマッピングする、と考えた方が自然である。 たとえば、x, y, zの3つの次元を持つデータ構造をExcelで表現するとして、 シートでx, yを表現し、串刺しでzを表現... するのはいいが、 ある時急に、yとzでシートを作りたくなったらどうすればいいのだろう? (できるの?)

そして、「レイアウト」の側は、 最初は何も書いてない白い紙から始まるべきである。 人間が紙に書くならともかく、コンピュータ上での編集なら、 位置を揃えたければ必要に応じてグリッドを出せばいいのである。

もちろん、「レイアウト」側の機能は、Wordのそれでは 話にもならない

文書の構造は文書の構造として、章立てや箇条書きなどを その見栄えとは独立して保持する。 計算したい部分は、その計算式にちゃんとマッチする データ構造で保持する。 そして、レイアウタが、それを綺麗に紙の上にマッピングする。 ま、ここは、LaTeXのようにフルオートにしてしまうと、 「思い通りにならない」という不満が出るので、 かなりの所まで人間の手で制御できるべきだと思うが。

せっかく「統合環境」としてOfficeのようなアプリケーションを開発するなら、 ぜひともこういう思想のもと設計して欲しい、と思うのである。

そんなに変なこと言ってるかなあ...


ひとつ上のページに戻る | ひとつ前の話 | ひとつ後の話 | トップページに戻る