「コマンド体系のデザイン」で考慮すべき、ユーザとレイヤー違いの4領域
例えば、Webアプリケーションにおけるユーザインターフェースには、ブラウザから見るHTMLページとWeb APIの大きく2つがある。前者は人をユーザとしたユースケースで、後者は機械をユーザとしたユースケースだ。小山氏は、「コマンドラインインターフェイスもWebアプリケーション同様に2つのユースケースがある。しかしコマンドラインインターフェイスでは、1つのユーザインターフェースで人間と機械のユースケースを同時に満たす必要がある」と言う。
コマンドラインインターフェイスの大きなメリットは、さまざまな操作を単一のユーザインターフェースで実現できることだ。その反面、単一のユーザインターフェースしか提供できないことは、制約にもなる。よって、人と機械の両方のユースケースで使われるCLIツールでは、両方のユーザの特徴を考慮する必要があるというわけだ。
これを実現するため、2つのユースケースと2つのレイヤーを考慮し、下図の4つの領域について、それぞれを意識してCLIツールをデザインすることが大切だ。
2つのユースケースと2つのレイヤー
2つのレイヤー
2つのレイヤーについて深掘りしていこう。
まずは「1つのCLIツール」というレイヤーだ。コマンド入力という単純なインターフェースでは、サブコマンドなどを通じて多くの機能を含めることができる。例えば、AWSのCLIツール「aws-cli」は、単一のユーザインターフェースで多岐にわたるAWSリソースを操作できる。ブラウザの「AWS Management Console」を使う場合は複数のページを行き来する必要があることを考えると、単一のユーザインターフェースで操作できることは大きなメリットと言えるだろう。
しかし、裏を返せば、多くの機能を1つのCLIツールで操作しなくてはいけないということだ。小山氏は「同じインターフェースで操作できるのに、サービスごとに異なる操作感のコマンドだと使いにくいツールになってしまう。そのため大前提として、CLIツールは統一されたコマンド体系であることが求められる」と述べた。
もう1つのレイヤーは「UNIXシェル」だ。これはコマンドラインインタプリタであり、ここでCLIツールを実行する場合、実行方法と入出力が統一される。一方で、パイプと呼ばれるコマンドを組み合わせるための機能もあり、結果として連携や自動化が容易になる。そのため「UNIXシェル上では組み合わせを考慮したコマンド体系であればあるほど使いやすい」と小山氏は言う。
ここで、UNIX哲学のなかからCLIツールデザインに関する部分を2つ抜粋する。「それぞれのプログラムが1つのことをうまくこなすように」すること、「すべてのプログラムの出力が、まだ見ぬ別のプログラムの入力になる」ことだ。小山氏は「これらの哲学は、『CLIツールは組み合わせを前提とすべき』だと明確に示している」と指摘した。
2つのユースケース
続いて、2つのユースケースについて見ていこう。まず、人をユーザとしたユースケースを考えると、「コマンドを覚えていないと実行できない」という問題がある。グラフィカルユーザインタフェースと異なり、何も入力していないUNIXシェルの画面上には、コマンドに関するヒントがない。また、複雑な仕事をする際には複雑なコマンドを記述する必要があり、ユーザである人に大きな負担をかけてしまう。そのため人にとって「入力しやすく」「理解しやすい」コマンド体系が求められる。
「入力しやすい」とは、想像しやすく、単純に入力文字が少ないことを意味する。このようなコマンド体系は人が覚えるのも容易だ。言い換えれば、フラグやサブコマンドが一定のルールで統一化され、他のよく知られたCLIツールと類似性があるコマンド体系といえるだろう。例えば-vといえば、多くの場合バージョン表記か、何らかの詳細出力を想像できる。独特の「オレオレコマンド体系」を作ってしまうと、組み合わせた時に使いにくくなってしまうのだ。また、入力する文字数が少ないことも重要だ。頻繁に実行するコマンドであれば、ショートフラグを提供することで使いやすさが向上する。
「理解しやすい」とは、実行結果と実行する内容が分かりやすいことを意味する。実行結果の出力を読めばその意味を理解できることはもちろん、出力も一目見ただけで理解できる状態が理想だ。例えば、文字の色を成功なら緑、失敗なら赤と分けることで直感的に結果を理解できる。また、入力したコマンドが何を実行するのか、コマンドの文字を見ればすばやく分かることも重要だ。小山氏は「特に本番環境に影響するコマンドだと、より説明的であることが求められるので、ショートフラグではなくロングフラグを提供することで、可読性を向上できる」と述べた。
次に、機械をユーザとしたユースケースを考える。ジョブ管理ツールの「cron」や「Consul health checks」などに一度コマンドを登録すると、人のように記憶力や操作性の制約なくコマンドを利用することができる。後々の保守を意識したら、入力しにくくとも可読性の高いコマンドのほうが良い。また、実行結果は機械にとって分かりやすいことを意識する必要がある。機械はコマンドの影響よりも「成功したか失敗したか」を大切にするので、終了ステータス（Exit code）の整備は必須だ。標準出力と標準エラーについても、一定の方針のもとに使い分けすると良い。
ここで今までの内容をまとめると、コマンド体系のデザインには2つのレイヤーと2つのユースケースがあり、4つの領域を意識して、バランスをとる必要がある。小山氏が実際にCLIツールをデザインする時にも、そのコマンドをメインで使うユーザやレイヤーに合わせて、どんな特徴を重視すべきか考えていくそうだ。
