『APIデザインケーススタディ―Rubyの実例から学ぶ。問題に即したデザインと普遍の考え方』
（2015年12月，技術評論社）より転載

本書は，プログラミング言語Rubyの開発において，さまざまな機能がどのような考えに基づいてデザインされたのかを豊富な具体例によって説明するものです。多くの例はライブラリのAPI（Application Programming Interface）についてのものですが，言語自体の機能についての例も含まれます。

Rubyはmatz（まつもと ゆきひろ氏）によって開発されましたが，フリーソフトウェアとして多くの人の貢献を受け入れています。筆者はRubyに機能拡張を含む多くの貢献を行っており，その結果として現在はRubyコミッタという，Rubyのソースコードを直接変更できる立場にあります。

Rubyがどのような機能を持つべきかという点に関しては，現在でも広い範囲でmatzが最終責任者であり，Rubyコミッタと言えども新しい機能を勝手に加えることはできません。機能を加えるには，matzの了解をとる必要があります。

そして，Rubyは，プログラマにとって使いやすい言語であることを目指して開発されています。そのため，ある機能を採用するかどうかについては，その機能が使いやすいかどうかという点が強く意識されます。そのため筆者は，多くの機能について，それがプログラマにとって使いやすいということを考え，（⁠matzを説得するために）言葉で説明してきました。本書はその経験をまとめ直したものです。

ここで「使いやすい」というのはどういうことか，それをいかに言葉で説明するかという点が問題になります。短く記述できる方が良い，思考を節約できる方が良い，よくある問題を解決する機能の方が良い，といった指針はありますが，結局は個々の具体的な状況に応じて使いやすさを検討した上で説明する必要があります。本書は，そのような「個々の具体的な状況に応じて使いやすさを検討した」結果について述べています。多くは筆者自身が提案したものですが，そうでないものも含まれています。

2015年にmatzは「20年目のRubyの真実」（⁠※）において，言語デザインについては「驚き最小の法則」を利用することを止め，ユースケースなどを元に議論して判断するようになったと述べています。本書が述べている具体例の検討は，そのような議論をまとめ直したものとも言えます。

プログラミング言語は大抵の場合，何らかの問題を解決するために使われるので，使いやすくするためには問題を簡単に解決できるようにするというのが基本です。そのためには，まず問題そのものを十分に理解する必要があります。そして，本質的な問題を解決する機能を多くの人に使いやすいようにデザインする必要があります。

とは言え，問題をどのくらい理解すれば良いのか，どうやったら使いやすくできるのか，というのは自明ではありません。Ruby程度に使いやすくしたいと思っても，Rubyそのものを調べるだけではどうやってデザインされたのか理解するのは難しいでしょう。本書は，そのようなデザインを行った当事者あるいはそれに近い立場から具体例を解説することにより，読者がデザインの経過をたどれるようになっています。

問題をどのくらい理解すれば良いのかというのは，もちろん問題に依存しますが，本書を読むことにより，Rubyではどの程度の考察が行われているのか実感できるようになるでしょう。

使いやすさを具体的に実現する手法はいろいろあって，個々の状況に適した手法を適用する必要がありますが，それなりによく使われる手法をいくつか以下に例として挙げます。

• 良い名前を使う（プログラマが連想するとおりの内容とする）
• 簡潔な表現（やりたいことを簡単に記述できる）
• モードをなくす（機能を利用する前提条件を減らす）
• 引数を減らす（引数を準備する手間を減らす）
• 一貫性を保つ（プログラマの推測が成り立つようにする）
• 低レベルAPIと高レベルAPIを分ける
• 互換性を保つ（過去の知識とプログラムをそのまま利用できる）

複数の指針が矛盾することもあるので，常にすべての指針を満たすことはできません。そのため，最終的には，個々の状況に応じて検討してデザインする必要があります。本書では，個々の具体例について，どのような手法で使いやすさを実現しようとしたのか，ということも述べています。

本書で述べた具体例が，使いやすさについて意識的に考える材料になり，さまざまな言語やライブラリが使いやすさを意識してデザインされるようになってほしい，と期待しています。

※「20年目のRubyの真実」（⁠松本 行広／笹田 耕一，情報処理Vol.56 No.12，2015年11月，情報処理学会）