オープニングトーク
まつもとゆきひろ氏：まつもとゆきひろです。月曜日に放送して以来、ちょっと間が空いてしまいました。今日これを録音しているのは、（2022年）6月25日の土曜日なので、月曜日から土曜日まで録音できなかったということになります（笑）。
「Voicy」は、一発録りで流す仕組みで、編集をほとんどかけていないので、そういう意味で言うと、習慣化して毎日10分とか録れば、すぐに毎日できるようになると思うんですけれども、まだ習慣になっていないので、忙しいとこうやってつい後回しになって、じゃあ、次の日、とかなってしまいがちなのが現状です。
例えば、毎日「Wordle」をするとかですね（笑）、日記を書くとかですね、それから、「mruby」に1日1回コミットするとかですね、そういうのは心掛けて毎日の習慣にしているので、Voicyを録音するというのも、毎日の習慣に組み込んでしまえば、きっともっと頻度高く放送できるんじゃないかなと思っています。
『失敗の科学』の紹介
今日は読んだ本をちょっと紹介して、それについて考えたことをご紹介しようと思っています。
今日紹介しようと思っている本は『失敗の科学』という本です。
この本は最近読んだんですけれども、航空業界は、失敗をすることを前提にしているので、ミスがあることを前提にしています。
人間、ミスなくなにもかも行うことは不可能なので、ミスをすることを前提にした状態において、もう二度と同じ問題を起こさないようにフィードバックするという文化があるんですね。
一方、医療業界は、ミスがあることが仕組みに組み込まれていないんですね。医療において失敗があると、医療ミスとか大事（※おおごと）になりますし、場合によっては裁判になったりするわけです。
その結果、失敗があると基本的に隠すような……「これは予想不可能な人体の問題によって起きたもので失敗ではない」というような言い訳をするので、失敗によるフィードバックが利かず、進歩が遅いという話がいろいろな事例として掲載されています。
それから、いろいろな業界のお話とか、いろいろな失敗を認めて成功した業界とか、あるいは、医療業界でも失敗を認めるようにして、業務がすごく改善されて、結果的に医療ミスが減ったみたいなことを紹介している本です。
ほかには、ブルース・リーの有名な言葉「考えるな。感じろ！」、「Don't think. Feel!」をもじって、「Don't think. Fail!」という言葉が引用されています。「考えるな。失敗しろ！」とか「しくじれ」という感じで、日本語にうまく翻訳できないんですけれども。
やはり失敗するというのは、人間の不完全さなんでしょうし、みんな不完全なので、間違ったり失敗したりしちゃうんですよね。本当はしなくてもいいような失敗もたくさんありますけれども。
それを素直に認めて、できるだけ仕組み的に、そういうことがもう起きないようにするという工夫を積み重ねていくことによって全体のクオリティが上がるということに真正面から取り組んだ本だと思います。とてもいい本だと思います。
「Amazon」のリンクを貼っておいたので、ぜひ見ていただければと思います。今だと「Kindle Unlimited」でも読めると書いてあったので、Unlimitedの会員の方はそれで見ていただけるといいんじゃないかなと思います。
新しいメソッドを追加する時、失敗は許されない
私は、Rubyというプログラミング言語のデザイナーなので、失敗をどういうふうに扱うかについて考えたんですが、普通に考えると、ちょっと適用しにくいんですよね。
というのは、例えば医療であれば、いろいろな患者さんに手術をしたり治療したりするわけですし、あるいは航空業界であれば、同じ飛行機をたくさん作ったり、あるいは、設計するのは何年かに1回なんだけど、似たような飛行機をたくさん作るわけです。
例えば、「737（ボーイング737）」とか「747」とか「777」とかいろいろあるので、設計のパターンを流用できるんですけれども。
プログラミング言語の場合、1人の人が複数のプログラミング言語を作ることは滅多にないんですよね。私自身も作りかけた言語はいっぱいありますけど、きちんと世に出たのはRubyだけですし、Rubyを作り続けてもうすぐ30年になるので、私の経験を私自身が活用するのはなかなか難しいんですね。かつ、プログラミング言語デザイナーの人たちが、自分たちの失敗の経験を披露するのは、そんなに頻繁にはないですよね。
一応、例えばC++とかですね、『C++の進化と設計』というタイトルのビャーネ・シュトラウストラップ先生の本はありますが、それは、そういう意味で貴重な例外というか、どういうふうにRubyのデザインに当てはめたらいいのかが、直感的にはわからないですね。
かつ、Rubyみたいにすでに広く使われている言語になると、例えば新しい機能を追加するとか新しいメソッドを追加する場合、失敗が許されないんですね。いや、厳密には失敗しているんですけど。
例えば、「あぁ、このメソッド、ちょっと名前がわかりにくいから違う名前にしようかな」とか、あるいは、「このメソッドの振る舞いがちょっとおかしいから直そうかな」と思っても、Rubyのユーザーはすごくたくさんいるので、その状態で使っている人がどこかにいるんですね。
そこを、「ちょっとごめん、直すわ」といって変えたりすると、その人たちが書いたプログラムが動かなくなるわけですね。
例外はいくつかありますけれども、ほとんどの場合、1回リリースした機能は取り消せないんですよね。そういう意味では、ちょっと失敗が許されないというところがあります。
『APIデザインケーススタディ』の紹介
困ったもんだという感じではありますけれども、ただ、設計のパターンとしては、考えるに足るようなものがいくつかあります。今日は、そのことについて書いた本も紹介しておこうと思います。
技術評論社から出ている、『APIデザインケーススタディ』という本があります。これは、Rubyコミッターの1人である田中哲さんという人が書いた本です。
言語のデザインではないんだけど、例えばAPIのデザイン、どんなAPI、メソッドを用意するかとか、どういう概念をどういうふうに扱うかということについて、課題とか、それをどう直したかみたいなことを紹介している本です。
Rubyのメソッドだけではなくて、例えばWebアプリケーションのバックエンドを作る時、「Web APIを作ります。そのAPIは、どんな機能が必要ですか？」みたいな時にも、応用可能な内容になっていると思います。
プログラミング入門した時には簡単そうに見えた問題が、実は、コーナーケースがすごく難しいから、APIとして実現する時にはこんなことを考えなくちゃいけないみたいなことを勉強できる本になっています。
明日役立つとまでは言えないんだけど、少なくとも、この本を読んだ人はプログラマーとして中級から上級に近づくところぐらいまで行けるんじゃないかなと思います。逆に初心者にはちょっと難しすぎるかな、という本です。
これもKindleあるみたいなので、もしよかったら眺めてみていただけるといいんじゃないかなと思います。うちの本棚には、1冊置いてありますけれども（笑）。
クロージングトーク
ということで、今日は『失敗の科学』という本と『APIデザインケーススタディ』という2冊の本を紹介しました。
デザインはチャレンジングではあるんですけど、それと同時に非常に難しいものだと思います。難しいからおもしろいというのもあるんですけどね。ぜひみなさんも、ソフトウェア開発や、そうでないところでもなんらかのデザインをする時に参考にしていただければと思います。
今日は、以上です。ありがとうございました。
