改善は後からできるから、とりあえず動くものを作ってみる
まつもとゆきひろ氏（以下、まつもと）：次にいきましょう。「Done is better than perfect」ですね。これは「完璧を目指すよりまず完了させろ」で、Facebook（Meta）ですね。
動かないソフトウェアとか、発表しただけで実際に手に入らないソースコードのことを「ベーパーウェア」、蒸気ウェアといいます。ソフトウェアは、動かないと試せないんですよね。実際に人間は、動かしてみないと、このソフトウェアが自分の求めるものかどうかが判断できません。
私はソフトウェア開発者としてそれを痛感しているはずなんですが、ある時すごく忙しかったので、後輩にソフトウェアを作ってもらったんですよ。「これこれこういうことをするソフトウェアを作って」と言ってお願いしたんですね。
ある程度経ってから、「できました」と言って後輩が持ってきたんですよね。そうしたら僕はなんて言ったと思いますか。「ここ、ちょっと違うんだよな」って言ったんです（笑）。
プログラマーが言われたくない言葉No.1を自分が言っちゃった。仕様書があるはずで、実際に私も「これこれこういうソフトウェアであって、こういうソフトウェアが欲しい」と言ったんですよ。
だけど、人間のイマジネーションには限界があるので、仕様書だけではわからないんですね。だから、とりあえず動くソフトウェアを作ることが非常に大事です。改善は後からできる。特に非機能要件、さっき言ったパフォーマンスやメモリ消費量とかは、作ってみないとぜんぜんわからないんですね。とりあえず動くものを作りなさいという感じです。
つらい経験があったとしても、それを学びにすることが大事
最後のことわざは「塞翁が馬」。有名な中国のことわざですね。
塞翁というのは、塞という村に住んでいるおじいさんという意味らしいですね。塞翁のおじいさんは馬を飼っていたんですが、その馬が逃げちゃったんですね。周りの人は「馬が逃げてかわいそうね」「財産を失って残念ね」と言ったんですが、その馬が何日か後に、いい馬を連れて帰ってきたんですね。馬が増えたんですよ。そうすると周りの人は「あぁ、いい馬が来て良かったね」「すばらしいね、運がいいね」と言ったんですね。
だけど、そのいい馬に乗っていた息子が落馬して骨折しちゃった。働き手が1人減っちゃったんですよ。そうすると周りの人は、「馬から落ちて残念ね」「骨が折れて残念ね」「運が悪かったね」と言うんですね。
でも、それからしばらく経ったら戦争が起きて、息子は骨が折れているので兵隊に取られず生き延びたんですよね。村のほかの人たちは兵隊に取られて死んでしまったのに、息子は生き延びたという話があります。
つまり、短期的には判断できないんですね。仮に目の前に悪いことがあったとしても、それを長期的に見たら違うかもしれない。
むしろ、悪いと思っていたことに対して、長期的にいいことにする努力をするのは自分自身ではないかなと思うんですね。
つらい経験があったとしても、それを学びにする。今日言った格言も、私自身も含めてそれで失敗した人がいるわけです。それをまとめて後輩に伝えると、私は講演料がもらえるし、みなさんは私と同じような失敗をしなくて済むし、みんなハッピーというWin-Winの関係ができるということです。そういうのが人生ではないかなと思います。
今日は、いろいろなことわざについて話しました。だいたいみなさんも失敗するんですが、先輩の失敗談やことわざを聞いて、みなさんの失敗が深刻でないもので済むように心から願っていますし、ぜひ失敗を避けて人生の大成功を勝ち得ていただきたいなと思います。
一番大事なのは、「名前重要」だと思いますが（笑）、それ以外にもいろいろ話をしたので、ぜひ覚えて帰っていただければと思います。ありがとうございます。
1分20秒前に終わりましたね（笑）。
抽象化する時は「本当にこれには例外がないのか？」という視点が重要
司会者：Matzさん、ありがとうございました。まだ5分程度お時間がありますが（笑）。
まつもと：えっ、5分あるの？ じゃあ質問を受けようか。
司会者：はい、ぜひお願いいたします。
まつもと：じゃあ、コメントから。（コメントを見て）おもしろいのでこれにしましょうかね。「抽象化しすぎてほかの人にわかりにくいコードになった場合はどうしますか？」。抽象化はだいたいの場合はうまくいくので、ぜひ活用していただきたいなと思うんですね。
気をつけなくちゃいけないことがあって、ジョエル・スポルスキさんという人が書いた『Joel on Software』という本の中に、「抽象化の漏れ」という表現があります。英語では「Leaky Abstraction」といいます。
抽象化するということは、その概念はそういうものだと決めて処理するということですが、抽象化でカバーしきれないような例外があった時に、それに対する特殊コードみたいなものも書かなくちゃいけません。その特殊コードみたいなものが上のレイヤーに積み重なっていくと、せっかく抽象化で簡単になったものが複雑になっていきます。
具体的に言うと、鳥を抽象化した時に、「鳥は飛ぶ」という処理をしたんだけど、ペンギンとかダチョウとか飛ばない鳥がいるよねという話をすると、上のレイヤーに「飛ばないやつもいる」というのが漏れ出してきて駄目というやつですね。そういうことは、ちょっと気をつけないといけない。
つまり、抽象化する時に、本当にこれには例外がないのか。それは全部のケースをカバーしているのかに気をつけないと、ちょっと痛い目に遭う可能性があります。
チームメンバーとして欲しいのは、自分で学べて人間関係を良好に保てる人
まつもと：次は、「チームメンバーとして欲しい人材の特徴は何ですか？」ということなんですけども、一緒に働きたい時に期待したい特質としては、教えなくても自分で調べられる人と働きたいです。これが1点ね。
つまり、「これはね、こういうことをすることだよ」といちいち教えなくても、自分で学べる人。「教わってないからできません」と断らない人。
調べてもわからないことは当然あると思うので、それは聞いてくれたらいいと思うんだけど、事前にお膳立てをして、「これこれを学びましょう」「こういうふうにしましょう」と全部教えてあげないと働けない人は、ちょっと困るので、そうじゃない人。自分でできることは自分でする人と働きたいですね。これが1点。
もう1つは、ものすごく優秀な人でもチームで働く時に関していうと、人間関係をうまくやれない人がいるんですよね。自分より劣った人を罵倒するとか。
英語では、Brilliant Jerk。「嫌なやつ」という意味で、Brilliant Jerkと言うらしいです。チームで働く時は、そういう人もちょっと嫌だなと思います。
結果だけを使うのであれば、その人がJerkかどうかはぜんぜん関係ないので、結果だけをもらえればいいんですけど、チームとして一緒に働くのであれば、全部お膳立てしないと働けない人と、人間関係で他人を罵倒するようなタイプの人は困るなという感じではあります。あとはできれば優秀であってほしいけど、それぐらいですかね。
実際にコードを書いたからこそわかることはけっこうある
まつもと：あと2分ぐらいあるね。（コメントを見て）「学生のうちからアプリを作ることは大切とよく聞くんですが、ToDoアプリでもなんでもいいからリリースしなさいという意味ですか？」という話ですね。
基本的にはそうですね。さっきの「ちょっと違うんだよな」もそうなんだけど、自分でプログラムを読んで書いた気になるだけではたぶん十分ではなくて、実際に書いたからこそわかることってけっこうあるんですよね。
それを経験するためにも、なにかソフトウェアを書く経験をするのはいいことじゃないかなと思います。
採用する時も、最近だと「GitHubのリポジトリを見せてください」というケースもあるみたいなので、そういうのも含めて、理論だけじゃなくて自分でソフトウェアを書いてみるという経験を持つのは、けっこうアピールポイントになるんじゃないかなとは思います。
見切り発車でどんどんプログラミングしていく
あとは……もうそろそろ時間だね。（コメントを見て）「プログラムを書く際は十を考えてから書くほうがいいのか、それとも最低限機能を考えて処理するほうがいいのか、どちらがいいでしょうか？」ですが、もう見切り発車したほうがいいと思います。
全部わかってから書いても結局、「なんか違うんだよな」と言われるので（笑）、考えてもたぶん無駄なんですよね。なので、ある程度こんなふうなものを作ると決めたら、見切り発車してどんどん書いていったほうがいいと思いますね。
「Streem」と「Spinel」を構想中
まつもと：いっぱい質問してくれてありがとうございます。（コメントを見て）「もう1つ新しい言語を作るとしたらどのような名前を付けますか？」という質問が来ましたけれども（笑）。
Rubyの後に、2つの言語に取りかかったことがあって、1つは「Streem」という名前の言語です。ストリームの英語のスペルは、「eam」なんだけど、そこを「eem」に変えた、ちょっともじった名前を付けました。
ストリームベースのプログラミングというのはどういうものかを自分で実感したかったので、プロトタイプを何年か前に作って、今は放置していますけど（笑）。
最近、名前だけを決めてまだ書いていないベーパーウェアがあって、そいつは「Spinel」といいます。Spinelも宝石です。ある漫画で、ルビー・ムーンとスピネル・サンという対になるキャラクターがいるので、Rubyだったら次はSpinelかなと思って、Spinelというのを考えています。まだ書いていないです（笑）、これから作れるといいなって。
だいたい時間になりましたね。今日は本当にたくさんの質問をありがとうございました。
司会者：Matzさん、貴重なお話をありがとうございました。みなさん、たくさんの拍手をお願いいたします！
まつもと：はい、ありがとうございました。
