2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
#11 「失敗の科学」 (全1記事)
リンクをコピー
記事をブックマーク
まつもとゆきひろ氏:まつもとゆきひろです。月曜日に放送して以来、ちょっと間が空いてしまいました。今日これを録音しているのは、(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デザインケーススタディ』という本があります。これは、Rubyコミッターの1人である田中哲さんという人が書いた本です。
言語のデザインではないんだけど、例えばAPIのデザイン、どんなAPI、メソッドを用意するかとか、どういう概念をどういうふうに扱うかということについて、課題とか、それをどう直したかみたいなことを紹介している本です。
Rubyのメソッドだけではなくて、例えばWebアプリケーションのバックエンドを作る時、「Web APIを作ります。そのAPIは、どんな機能が必要ですか?」みたいな時にも、応用可能な内容になっていると思います。
プログラミング入門した時には簡単そうに見えた問題が、実は、コーナーケースがすごく難しいから、APIとして実現する時にはこんなことを考えなくちゃいけないみたいなことを勉強できる本になっています。
明日役立つとまでは言えないんだけど、少なくとも、この本を読んだ人はプログラマーとして中級から上級に近づくところぐらいまで行けるんじゃないかなと思います。逆に初心者にはちょっと難しすぎるかな、という本です。
これもKindleあるみたいなので、もしよかったら眺めてみていただけるといいんじゃないかなと思います。うちの本棚には、1冊置いてありますけれども(笑)。
ということで、今日は『失敗の科学』という本と『APIデザインケーススタディ』という2冊の本を紹介しました。
デザインはチャレンジングではあるんですけど、それと同時に非常に難しいものだと思います。難しいからおもしろいというのもあるんですけどね。ぜひみなさんも、ソフトウェア開発や、そうでないところでもなんらかのデザインをする時に参考にしていただければと思います。
今日は、以上です。ありがとうございました。
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには