特集　無いものは作れTukubai 流コマンド自作文化（前半・本誌vol.7掲載)

第二章 sm2 コマンドという道具の発明

道具になることを目指して作られたOpen usp Tukubai を構成している49 のコマンド群。実際これらはどのようにして生まれたのだろうか。そのうちの一つで、表の合計値を求めるsm2 コマンドの生い立ちを取材した。

sm2 コマンドとは
Open usp Tukubai のsm で始まるコマンドはsum-up という表計算の世界で頻出の操作を行うシリーズだ。sm2 の場合、例えば下記のように生徒の各教科のテスト成績表があると、これに基づいて生徒毎の合計を求めるなどという用途に用いられる。

それではこのsm2 コマンドの進化の過程を見ていくことにしよう。

１．未来の開発者を想像してみる

頻出の操作であるなら迷うことなく作ればいいじゃないかと思うだろう。いやいや、そこで冷静にならなくてはならない。「道具として本当に必要なものなのだろうか」と、考えるのだ。「既存コマンドをちょっと工夫して使えば無くてもいいかも」、そう思えるかもしれないから。
あれば便利だろうと言ってコマンドを乱立させても、数が多いと覚えきれない。そういう宿命がある。すると、存在意義の薄いもの、使用頻度の低いものからどんどん忘れ去られていく。*1
USP 研究所にも、忘れ去られて今やハードディスクの肥やしとなっているコマンドが何百とあるという。*2 そうなってしまう未来が思い浮かぶなら、作るだけ無駄だ。無駄なだけ
でなく、そのコマンドの含まれるコードを読む未来の開発者が苦労することになる。「あれ、このコマンド……。どういう仕様なんだ？知ってるコマンドで事足りるならそれで済ませといてくれればいいのに」と。
そう、コマンドを作る時には未来の開発者の姿を思い浮かべることが重要なのだ。

§こんなのがあったらきっと便利だろうなー。
§でも、いっぱい作っちゃったら不便だろうなー。

と。そんな葛藤の末、それでも「未来の開発者達も、これがあればきっと便利になるはず！」と思えたらなら作ればいい。

§末永く使われますように。

そう心で祈りながら……。

*1 どの言語も予約語が数十～百数十個程度に落ち着いている理由は、そういうところにあるのだろう。
*2 次章でいくつか紹介しよう。

「そんなコマンド本当に必要なの？」USP 社内では毎週、エンジニアたちが寄ってたかって未来に求められるコマンドについて語り合う「コマンド研究会」と呼ばれる会議が開かれている。

２．作業指示の言葉をよく観察してみる

作るからには末永く使われるものになれなければ迷惑だ。
だから使いやすい仕様を心掛ける。コマンドの場合、書式が作業指示の写像になっていることが重要だという。ではsm2 はそうなっているのか？
sm2 を作り始める前、表計算を行っていた作業現場では次のようなセリフが飛び交っていたという。

§その表の1 列目から2 列目をキーにして3 列目から6 列目の合計を出して！

だからsm2 は、この文章をほぼ過不足無く表現できるような書式にした。結果、決められたsm2 の書式がこうだ。

 

先のセリフをこの書式に当てはめればこうなる。

オプションの“+count” を除けば、「合計を出す」という動詞がコマンド名に、他の名詞が書式にピタリと当てはまっている。このように現場で頻繁に飛び交っている指示の写像に
なっていれば、覚え易いし、また頻繁ゆえ忘れ去られる可能性も少なく、道具として認知される存在に成り得る。

単純でも頻繁に飛び交う動詞なら作る

今、「動詞がコマンド名になっている」と述べたことに注目してもらいたい。
sm2 の話から少し外れるが、例え既存のコマンドのごく簡単な応用で実現できることであっても、敢えてコマンド化した方がよい場合がある。それは、作業指示として頻繁に耳にする動詞があった場合だ。

例えばTukubai コマンドにgyo というものがある。これは単にテキストの行数を求めるだけであり、“wc -l | awk'{print $1}’” とか“awk ‘END{print NR}’” などとやれば簡単に求められる。それでもコマンド、つまり道具として成立したのは、「行数求めて」という指示（動詞）が現場で頻繁に飛び交っていたこと、そしてgyo コマンドの仕様がピタリとその指示の写像になれていたからである。
このケースからも、言葉の観察がいかに大切かということがわかる。

オプションの扱い

sm2 には一つだけオプションがある。これは各々の合計を出すのに使った元の行が何行あったのかを併記するものだ。最初の成績表の場合、各生徒の受けた科目は三つだったので3 という数字を返す。後続のコマンドで平均点を求めたいという場合に有効だ。
しかしTukubai的には、どうしようもない場合でもなければオプションなど殆ど付けないという。オプションもコマンド同様、乱立させても覚えきれずに忘れ去られるからだ。
例えば有名なls コマンドの-r オプションの働きを知っているだろうか？ファイルの表示順が通常なら文字コード昇順であるところを降順にするものだ。しかし、文字コード順ではなくて大文字小文字を区別しない（辞書的な）降順にしたければ……、結局sort コマンドを併用するしかない。ならばそんなマイナーなオプションなど用意せず始めからsortコマンド併用でいいじゃないか、という意見が出てくるのと同じことだ。
オプションもまた、付けるべきか付けざるべきか。或いは増やすぐらいなら別コマンドにすべきか。よく検討したい。
最後に、sm2 の書式に対して抱くであろう疑問について答えておこう。例えば「3 番目から5 番目、それから7 番目の合計を出して」というように、k1 ～ k2 やs1 ～ s2 が不連続な指示が与えられたらどうするのかというものだ。確かにsm2 の書式では表現できない。では改良を検討しているのかというとsm2 にその予定は無いらしい。この判断も現場で飛び交うセリフに基づいている。そのような指示は稀だったのだ。そんなレアケースのために書式を複雑にしたら途端に使い辛くなる。もしそんな指示が来るならself コマンド等と組み合わせ、列が連続するように予め入れ替えるべきだ。
こういったコマンドに持たせる機能のさじ加減を見極める上でも作業指示の観察は重要なのだ。

新機能が求められた時、新規コマンドで対応するか、追加オプションで対応するか。これも重要な議題だ。

３．始めは軽量言語（LL）で実装してみる

Open usp Tukubai のビジネス版の殆どはC 言語で実装されているが、最初はどれもAWK やシェルスクリプトで作られたという。まだ定番の道具になるかわからず、廃れたり、試行錯誤によって仕様が変わる可能性も考えれば、未来の開発者にとってもコマンドの動作が追いやすい言語を使うべきだ。
こうして、sm2 も当初はAWK で実装された。残念ながらAWK で書かれていた頃のバージョンは発掘できなかったが、+count オプションをサポートしないごく簡易的なものならリスト１のように直ぐに書き起こせてしまう。

sum-up という操作は表計算では頻出なので、実際sm2は多用され、重宝される道具になっているのだが、こうして50 行程で書けてしまう。

全てがそうとは限らないが、優れた道具とは概してこのように単純な構造をしているのだろう。もし何百行にも及ぶようなものができてしまったら、それは単機能なものになっておらず、道具として洗練されていないのかもしれない。

４．C言語への移植は、本当に必要とされてから

その後、sm2 コマンドはC 言語へと移植されていった。*1次第に道具としの必要性が認知され、不可欠な存在となって、そこで初めてこのコマンドに対してスピードを求められるようになったからだ。C 言語に移植後は、C 言語の鬼によって更なる高速化のための改良が続けられているという。高速化の作業に専念する為にも、LL 版で仕様をきっちり固めておくべきであろう。

ソースファイルは大抵一つ

sm2 のC 言語ソースファイルは、ライセンスの都合により残念ながら掲載できないが、ソースファイルはsm2.c の1つだけだ。*2 これはTukubai コマンドの殆どに言えることである。もっとも、AWK 版ソースの規模を見れば自明だろうし、同規模のUnix 標準コマンドの多くも一つだ。
一つなのでMakefileは不要。“cc -o sm2 sm2.c”などと書き、コンパイルが通るまで数秒待てば完成だ。
こんなあきれるほど簡単なコマンドやシェルスクリプトによって、一部の大手企業の業務データが管理されている*3と聞かされたら唖然するに違いない。しかし、優れた「道具」とは、そんなことをも可能にしてしまうのだ。

*1 これが、ビジネス版のusp Tukubai として現在に至る。
*2 もちろん標準ライブラリー等をインクルードしてはいるが。
*3 通信やWebUI 周りが必要な箇所では、Apache 等のHTTP サーバーアプリケーションのお世話になるのだが。

本記事の後半部分はこちらから！！