エンジニアは推測するな、計測せよ　まつもとゆきひろ氏が説く、非機能要件で数字を重視すべき理由

非機能要件に対しては「数字で話をすること」が重要

まつもとゆきひろ氏：2番目のことわざ、続いていきましょう。「推測するな、計測せよ」。これはちょっと誰が言い出したか調べられなかったんですが、わりと有名な言葉です。

なにかというと、プログラミングの中にはいわゆる非機能要件と言われているやつがあるんですね。

こんな機能があるとか、こういうことができる、というのは機能要件ですよね。そうじゃない要件があって、例えば、このプログラムをバッチプログラムだとすると、「用意ドン」で実行した時に何秒で終わる、とか、あるいは、そのプログラムを実行している間にどのぐらいメモリを消費するかとか、どのぐらいディスク容量を食うかとか。

あるいは、ふだんはいい感じでいくんだけど、時々ものすごく遅いリクエストがあるとか。100人のうち99人まではWebページを表示させるまで0.1秒以内に済むのでハッピーなんだけど、1人だけ5秒ぐらい待たされるというケースがあった場合、そういう最悪ケースの場合のパフォーマンスも非機能要件です。

非機能要件というのは、物を作る前からわかることが滅多にないんですよね。実際にプログラムを動かして、運用を始めたり、テスト運用をする時に初めてわかるんですよ。「あっ、メモリを食いすぎている」とか、「なんか、すごく遅いんだけど」とか「動作がもっさりしているんだけど」みたいなことを言われて、「じゃあ、直さなきゃ」という話になります。

そういう時だいたいの人は、「きっとここを直せば速くなるに違いない」みたいに思うんですね。あるいは、「直す手段としてこんなアイデアがあるんだけど、これをやったらどうだろう」と言って、直してみたりするんですが、残念ながら、だいたい外れるんです。

例えば遅いとかメモリ消費が多いとか、そうなる原因はいろいろな要素が絡み合っていることが多いんですね。

当たればいい、それでめでたしめでたしなんだけど、それで本当に問題を全部解決したかというとよくわからないんですよね。その時に必要なのが計測で、きちんと測ること。

数字を重視することが大事です。例えば、開発に対して「こんな機能を満たす必要があります」というリクエストを出す時があります。「このプログラムがちょっともっさりしているんだけど、何秒以内に終わらせられないでしょうか？」みたいな話をする時に、きちんと数字で話をする。秒、あるいはメモリが何MBとか、何GBとか、数字で話をすることは非常に重要だと思います。

全体的な数字を正しく計測しなければならない

またRubyの機能リクエストの話に戻りますが、Rubyの開発をしている中で、「こんなことをするといいと思うんだけど」みたいな話をした時に、「じゃあ、プロトタイプを作って、ベンチマークを取ってから入れましょうか」という話をすることが多いですね。やはり数字がはっきりしない時にそれを「イエス」と言うことは難しい。

なぜかというと、この場合には速くなるんだけど別の場合には遅くなるというケースがあるからです。あるいは、スピードは速くなったんだけど、メモリ消費量が受け入れられないほど大きくなったというケースもあるわけですよね。

そういう意味でいうと、全体的な数字を見ないと判断ができないんですよね。そのためにどうするかというと、やはり測らないといけない。それも正しく測らないといけません。

よくやっちゃうのが、ボトルネックではないところをいじっちゃうこと。本当に遅くなっている原因はほっといて、些細な、ここのループの数を10回を4回にしましょうみたいなことをやってしまいがちなんですが、10を4にしても差が出ることはあまりありません。その隣で100万回ループしていたりとかするので（笑）。

手をつけなくちゃいけないのは、100万回をなんとかすることであって、10回を4回にすることではないんですね。

プログラム全体は均質に重要ではないので、一番重要なところだけいじることをできればやりたい。そのためには測らないといけないんですね。測るツールはいろいろあります。プロファイラとか、ベンチマークで測るとかいろいろあるので、そういうツールの使い方を学んで正しく測ることが必要です。

正しく測ることが必要なんですけれども、気をつけなくちゃいけないのは、人工的なベンチマークを作ってしまうことです。絶対に駄目とまでは言いません……まぁ、Rubyもやっているし（笑）。

Rubyがバージョン3.0で、「前のバージョンに比べて3倍速くなりました」と言った時には、やはり特定の人工的なベンチマークで3倍速くなっていて、Railsアプリケーションが3倍速くなったわけではないので（笑）。

そういうことをやることはありますが、本当に問題を解決したい時には、リアルワールドのアプリケーションでどのぐらい遅くてどのぐらい改善するかを測らないといけない。だから、人工的なベンチマークはだいぶ危険。リアルワールドに近いもので測ることが理想です。

同じ理由で、マイクロベンチマークみたいなものも、危険があるわけですね。マイクロベンチマークは、小さな規模のプログラムで回します。それが、さっきのリアルワールドアプリケーションの中の性質を反映していればいいのですが、結局ループを100万回、回すだけというベンチマークを作りがちです。そうすると、関数呼び出しだけを測っているという話になっちゃうので、それが本当にリアルワールドアプリケーションについて重要なのかということも含めて、考えないといけない。

気をつけないと、「数字を出しました」と言っても、その数字は嘘だったり、あるいは統計の使い方が間違っていて、アプリケーションの開発全体を違う方向にドライブしていく可能性さえあるということです。

なので、エンジニアのみなさんには、その問題に対して誠実に向き合っていただきたいなと思います。これが、「計測せよ」ですね。これが2つ目。2つ終わりました。

「上司に許可を求めてから始める」は必ずしも良い方法ではない

3つ目はですね、「許可を求めるな、謝罪せよ」という、社内政治っぽいことわざです。

これは、言った人ははっきりわかっていて、グレース・ホッパーさんという人です。アメリカ人女性で、海軍の准将だったかな？　偉い人です。

COBOLっていうプログラミング言語……最近あまり名前を聞かなくなりました。まだ動いているところでは動いている。銀行の中とかではまだ使っているらしいんですが、COBOLというプログラミング言語には設計委員会みたいな、CODASYLという委員会があって、そこの委員長が、このグレース・ホッパーさんだったそうです。数学がメッチャできる女性だったそうです。

正確には、グレース・ホッパーさんの言葉は、「許可を求めるより、謝罪するほうが簡単」なんですが、言う時はもうちょっと強めに、「許可を求めるな、謝罪せよ」という言い方になっていますね、ことわざ的には。

さっき、「誠実であれ」と言ったので、なにか新しいプロジェクトをやりたいとなった時、きちんと正式なルートで、マネージャー、あるいは役員に「こんなことをしてもいいですか？」と許可を求めて始めたほうがいいんじゃないかな、と思うかもしれませんが、実は、これはあまり良い方法ではありません。

なぜかというと、正式に聞かれると、（聞かれたほうは）正式に許可しないといけないんですよね。正式に許可する場合、その許可を出した人に対して、うまくいかなかった時のリスクを考えたり、あるいはうまくいかなかった時に、許可を出した人に責任が発生しちゃうんですよね。そうすると、許可を出した上司……マネージャーかもしれないし役員かもしれませんが、その人の負担になっちゃうんですよね。

だいたいチャレンジングなことというのは、100パーセント成功するとは限らないので、「これがもしうまくいかなかったら、僕は、そのまた上司にどうやって説明しよう」みたいな話になるわけです。

それは良くないのでどうするかというと、こっそりやります（笑）。これを「スカンクワーク」という言い方をするらしいです。

スカンクワークをやっておいて、もしそれが失敗しちゃったら、「ごめんなさい」「こんなことをやっていたんですけど、うまくいきませんでした」と上司に謝る。あるいは、上司がそもそも気づかなければ謝る必要さえないんですよね。

でも、もしそのプロジェクトが成功したら「ありがとうございます」「お目こぼしをいただいたおかげでこんなに大成功しました」と言います。「わしが見逃してやったから」と上司の顔も立つということですね（笑）。「あの時見逃していただいたプロジェクトです」とお礼にいくという感じです。

Rubyは「スカンクワーク」から生まれた

実際、Rubyを作った時もそんな感じでした。Rubyを作り始めたのは1993年と言いましたが、バブル経済が崩壊してすごく不景気だった時なんですよ。

私は、自分の会社の社員が使う社内システムを作るところに配属されて作っていたのですが、景気が悪くなると社内システムって売上が立たないんですよね。外貨を稼いでこないと景気が悪いので、会社が立ち行かないという話になって、プロジェクトがキャンセルになって、メンバーは散り散りになったんです。

私自身は、すでにそのプロジェクトで作ったソフトウェアのメンテナンス要員として残されたんですね。40人ぐらいいたメンバーの中で2人だけメンテナンス要員で残ってそのうちの1人が私でした。どちらかというと窓際ですよね。

新規開発が禁止されているので、新しいソフトウェアを作れないし直せないんですよ。何をするかというと、たまに社内から電話がかかってきて、「おたくの作ったソフトウェアがうまく動かないんだけど」と言われるので「あぁ、そうですか。じゃあ、PCを再起動してください」と言って、終わり。2日か3日に1回ぐらい電話がかかってくるという、それだけ（笑）。

本当にやることがなくて、かつ、上司も見ていないんですね。上司もお金を稼ぐところのマネージャーをしていてこっちはその兼任だったので、何も監視していないんです。パソコンは取り上げられなかったので、目の前にコンピューターはあるんですよ。これはスカンクワークの絶好のチャンスなわけですよね。さっき言った先輩が本を執筆するという話をしていて、それがきっかけでRubyを作り始めたんです。

さっき言うのを忘れていましたが、その本の企画はあっという間にボツになって、本は出なかったんですね。だけど、せっかく作り始めたので「なんか作るか」と言って、ずっと作っていたんですよ。

結局、私自身はプログラミングが好きで、時間があったらプログラミングをするタイプだし、プログラミング言語も大好きだったので、自分でプログラミング言語をデザインして作るというのも、1つ、自分の夢だったので、「それをやるか」と言って継続したんです。

こんなふうになるとは、その当時はぜんぜん思ってはいなかったんですね。その後、会社がいよいよやばくなったのでその会社は辞めたんですけど、辞める前に、「誠実であれ」とは思っていたので、上司に言いにいきました。「すみません、マネージャー。こんなことを陰でこっそりやっていたんですけど」と言ったら上司に、「見なかったことにするから持っていけ」って言われました（笑）。

それで、次の会社にそのソースコードを持っていって、そこにいる時にRubyをリリースしたのですが、もし上司が見逃してくれなかったら、今のRubyはもしかしたらなかったかもしれないと思うと、もうその上司には30年ぐらい会っていませんが、もし会う機会があればですね、「あの時助けていただいたRubyがこんなになりました」とお礼を言わないといけないなと思います（笑）。だいぶ年上だったので、もう退職していらっしゃると思うんですけどね。

世の中、未来のことは予想できないですね。これが3番目のことわざになります。

あれ？　いったいいくつ用意したんだっけ？　まぁいいや（笑）。

（次回へつづく）