表計算アプリは偉大。

最近はAndroid上に構築した簡易開発環境でモバイルに特化した劣化版Excelモドキを暇なときにコツコツとコーディングしている。

事の始まりはモバイル版の表計算アプリを利用する際に多機能過ぎて使いづらいかもと感じたことから、ForMeの簡易開発環境のテストも兼ねてモノは試しと作り始めたのだ。

自分が初めて触ったモバイル用の表計算アプリは懐かしきios5版iPod touchのNumbersだった。当時、現場仕事をしながら不良対策書を作成していたが、パソコンに向き合える時間がどうしても取れないので統計解析ができず、期日が目前に迫っていた。いろいろな機械油で汚れた検査用紙のデータ化が進まないのが大きな問題点だった。

悩んだ結果、上司に許可を取った上で現場のスキマ時間にNumbersでデータ入力を進めた。お陰で週末にそのデータをExcelに取り込んで統計解析を行い、不良対策書を書き上げてナントカ期日を守ったのだった。

この経験は強烈さこそはないがかなり鮮明に記憶に残っていた。当時はまだガラケーが主体でAndroidはその操作性から二度と触らないと宣言する人間も周りに多く居た中で、ハンディターミナルのような専用機では無く、民生の汎用機でも効果的に効率化を進めることができると実体験を得たのだった。

当時、後光が差して見えていたスティーブ・ジョブズの語る未来に機械油まみれに成りながら少し触れた気がしていた。もう少し待てば紙とペンから開放されるかなと期待を寄せた。

だが、中々そのような事にはならなかった。様々な業務システムが開発され、インダストリアルなんたらと持て囃されてもその恩恵に触れられるのはごく一部の現場だけであった。

そんな中、アメリカ出張に鞄持ちとして一緒に行動をした当時の常務から「これからはプログラミングの時代だ。」と事ある毎に呟いていたことを思い出し、個人的にプログラミングを勉強し始めた。

よくあるようにExcelVBAからのスタートだったが、Androidを主体としたJavaからフロントサイド、PHP、C言語などを習熟度はバラバラでありながらも継続的に学習を続けていた。ただし、あくまで改善活動と教養学習の一環として。

十数年勤めた会社を辞め、プログラマに成るための準備をしていた時期に独学ではあるが本格的なモバイル向けのUI・UXの学習を始めた。こんな考え方があるのかと目から鱗状態が長く続いたが、Excelのようなテーブル表示の項目で以下の一文を読んで思考停止に陥ってしまった。

モバイルのような小さな画面ではテーブル表示は表示情報の不完全さとその操作性の悪さから最適解とは言えない。可能な限り別の表示方法を採用すべきである。どうしても必要であればExcelやGoogleSpreadSheetなど大企業が開発したアプリを利用すべきである。

あくまでも昔のことなので正確な言い回しは覚えていないが、このような意味であった。

当時は只、知識を詰め込む段階であったのとテーブル表示は実装が難しいという背景もあり、このルールは頭に厳密に刻まれた。

自身でAndroidアプリやWEBシステムを組むようになっても、テーブル表示は避け続けた。Androidアプリではどうしても必要な場合はには外部の評価の高いライブラリに頼り、必要に応じて外部の表計算アプリを経由するようにしていた。

ただし、この方法では2000レコードを超えた当たりで端末によっては操作に遅延が発生したり、そもそも表示されない場合がでてきていた。また、ライブラリは多機能の為、ファイルサイズが大きい事とライセンスを含む保守性の複雑さに対応する手間などのデメリットが目立ってきていた。

もうお目溢しが出来ないなと思い始めた頃、Android端末上でコーディングをするネット記事を見た。パソコンと違いスマホは常に手元にあるので試行錯誤し易いし、配布しているアプリにユーザーが自由に機能を追加できる方法を模索していた中でこのアイデアは有りだと思った。

インターネット黎明期にホームページ制作を経験したことがあるがそこから進んでいないユーザーをターゲットにした。潜在的なユーザーが多いと思われると同時にせっかくの技術を活かしてほしいと思いから言語をHtml,CSS,JavaScriptに絞り、完全なスタンドアロンにすることで利便性を少し犠牲にするが外部攻撃を意識しなくても良い開発環境を作成した。

そんな簡易開発環境で今までタブーにしてきたテーブル表示ライブラリを自作することにした。あくまでメインではなく、出来たらいいなの感覚でコーディングを始めた。コードネームはGOMOKU。Excelなどの表計算アプリが囲碁のように高度なものに対し、五目並べのような簡単なものをまず形にしようとの考えから付けたネーミングだった。

最初はHtmlのTable要素をベースに試行錯誤していた。テーブル構造が自動で構築されるのは大きなメリットであったが、プレレンダリングや表示領域のみを構築し表示する方法をなどをとっても描写時間の短縮は満足の行くものにはならなかった。

ちょうど、GoogleSpreadSheetがCANVASベースに変更されて、少し時間が経ったくらいだった。全部を計算する必要のあるCANVASベースの方法に自分の実力で対応できるか気後れしたが、思い切って変更してみた。

これがうまくハマった。ましてや小さなスマホ上でコーディングし、成功したのだから、かなり嬉しかった。自身で開発した簡易開発環境も大きく洗練することになった。何よりかつて、テーブル表示は無理なので諦めろと書いてあったUI・UXの教科書に一つ金星を上げた気になった。

今取り組んでいる劣化版ExcelモドキはボツにしたGOMOKUのTable要素バージョンをベースにしている。理由はコーディングが楽になる事とスマホでそんなに難しい表計算は行う気もないし、各データはシートではなく配列形式としてセルに入力・取り込みをすれば良いと割り切った為だ。あくまで計算シートのようなものにする。複雑なことはExcelやGoogleSpreadSheetを使えば良い。範囲も30行×100列の3000セルのみと割り切る。

勿論、セル参照や基本的な関数群とオートフィル・書式と数式を保ったコピペは実装することとした。書式は太字か普通のどちらかだけ、セル幅変更は出来ない(2つまでの結合はあり)と割り切っている。

操作性については表の拡大縮小表示に一切対応していない事が特徴になる。この特徴はGOMOKUも同じ理由で一貫している。それは縮小表示してもそんなに視認できる情報量が多くない点とジェスチャーによる操作性の自由度の高さが誤操作を誘発する事が多いと個人的に感じたためだ。

離れたセル同士を比較したい場合は吹き出しで参照先を表示し、長い文字は入力欄だけでなくダイアログで表示できるようにしている。操作もセルにタッチすると入力欄に関数が反映される。値を変更し確定する場合は確定ボタンかエンターを押さない限り反映されない。

セルを選択してもプレビューモードの場合は編集できない。入力後の移動は関数パレット上で変更する。(ハードウェアキーボードのショートカットキーに後に対応)

セルの書式や同時選択・オートフィル・コピーなどはセルをダブルクリックすることでメニューが表示される。

書式ごとセル範囲にペーストする場合は入力欄に貼り付けて確定ボタンを押すことで自動で判定される。別のアプリからのタブ区切りは値のみが入力される。セルに配列形式で値を入力するとINDEX関数を利用して値を取り出せる。

セルにCSVファイルパスを入力し、INSERT LINKを実行すると配列形式としてセルに入力される。保存は一時保存とJSONに対応し、読み込みもできるようにしている。

自動再計算は不対応で手動操作しなければならない。セルアドレスを入力する際の補助が一切無い。アンドゥ・リドゥが機能の一部にしか適用されないなど問題点は多いが、思考補助の道具として利用しながら開発を続けている。

だからこそ、ExcelやGoogleSpreadSheet、LibreOffice Calcなど表計算アプリの偉大さに驚かされる。開発規模が全然違うのはあるが、あれほどの機能を実装・試験・リリースするまでどれほどの時間と労力が使われたのだろう。今はAIが持て囃されているが、そのAIが相撲を取る土俵の一つである表計算アプリについてもたまには思いを馳せても良いのではないかと劣化版Excelモドキで猫の餌代を勘定しながら思うのだ。