誤りを認める練習
明らかに誤ったことをしたのにそれを認められずに醜態をさらしている、場合によっては傷口を広げて自分を窮地に追い込んでいる人を大量に見てきた結果、「こうはなりたくないな」と思う気持ちがずっとありました。にもかかわらず、数年前に見事に過ちを認められずに、謝罪できずに無様な姿をさらしたことがありました。公の場でやったことではないし、もしかすると謝罪されるべきだった相手は気にしていなかったかもしれませんが、自分から見れば間違いなく無様でした。
こういうことがあって以来、誤りを認める練習をするようになりました。練習といっても、壁に向かって謝罪し続けるというような話ではなく、自分の言ったこと、書いたことが間違っていたとわかったら、何もしなくてもその場はやりすごせそうな小さなことでも即座に「これは誤っていた」と表明するということをやっています。小さな誤りを認められなければ、大きな過ちを犯したときにも認められないだろうというという仮説に基づいて、こういうことをしています。なお、専門家に相談したりしたわけではないのでこの方法にはとくに医学的な根拠などはないです。
練習の機会は本ブログや書籍、などを介したIT技術に関する情報発信に対するコメントへの対応という形で、いくらでもありました。ここで注意が必要なのは、「誤りを認める = 謝罪をする」ではないことです。これは、あまりに些細なことで謝ってばかりいると自分が疲弊してしまいますし、相手からしても対応に困るからです。極端な例でいうと、誰かに「ここの文書にtypoがあるよ」と指摘したときに「申し訳ありません」と謝罪されても、きっと困惑することでしょう。
このような取り組みをしてきた結果どうなったかというと、ここしばらくは大小様々な誤りを認められなくても困ったということなく過ごせています。たまたま自分の認識に大きな誤りが明らかになって一歩間違えれば人生を棒に振っていたかもしれない事態に陥ったときも、ためらいなくすぐに謝りを認めて謝罪できたので首の皮一枚つながった…という経験もしました。少なくとも主観的には「これは練習の成果が出ているな、以前の自分ならできなかったな」と体感できました。もちろんこの方法は、そもそも誤っていることを自分が認識できていない場合にはまったく効果がなくて、傍から見ると「あなた全然誤りを認めてないじゃない」と思う方もいるかもしれませんが、これについてはまた別の話として、ここでは触れないことにします。
上記の方法がどれ位の人に適用できるのかはわかりませんが、「自分は誤りを認められない人間だ」という自覚があって、それで困っているかたにはもしかすると効果があるかもしれません。
ソフトウェア開発者のわたしが好きなコンピュータ以外の本
2023/8/13 18:20 タイトル変更。「ソフトウェア開発者が好きなコンピュータ以外の本」→「ソフトウェア開発者のわたしが好きなコンピュータ以外の本」 2023/8/15 16;20 「敗者のゲーム」から「星を継ぐもの」までを追加
私はソフトウェア開発者です。このブログなり別の場所なりでコンピュータについての参考書を何度なく紹介してみました。本記事はそれとはちょっと違って、私がこれまで出会ってきて感銘を受けたコンピュータに関係ない本たちを紹介します。紹介順とお気に入り度は連動していません。思いついた順番に書いただけです。
ルワンダ中央銀行総裁日記
銀行家である筆者がルワンダという国の中央銀行総裁を務めていた時期のことについて述べた本です。事あるごとに色々なところで紹介される有名な本なので、名前は聞いたことがあるとか読んだことがあるとかいう人は多いかと思います。本書の凄いところは2つあります。
1つ目は、やっていることのスケールの大きさです。著者の任務は前述の通り中央銀行総裁なのですが、実際にやっていることを見ると国王の信頼を背景に実質的に国家を運営しています。このようなことの体験記などそうそう読めるものではありません。
の2つ目は、文書の美しさです。といっても文学的表現がされているというわけではなく、表現方法は簡潔明快なものです。しかしながらその簡潔明快具合がずば抜けていて、息を呑んでしまうほどの凄まじさでした。わたしもいつかはこのような見事な文を書いてみたいと願っていますが、いまだゴールは遠いです。
ロジカルシンキング
文書を筋道立てて構築するための考え方について書かれています。あるものを文書として表現したい場合に、書きたいものをどのように論理的な木構造にまとめればいいのか、それをどのように文書として書き下せばいいのかなどが述べられています。文書を書くのが苦手という人が本書を読んで、書かれていることを実践すれば、かなり問題は改善するのではないでしょうか。かくいう筆者も自分の文書のあまりのヘタクソさに頭をかかえてこの本に出合って、そこから作文技術を改善してきました。
人を動かす、道はひらける
自己啓発本のはしりのような本です。内容について詳しく書くとネタバレになってしまうので書きませんが、人生なんかうまくいかないなあと悩んでいる人は一度読んでみるといいかもしれません。わたしはかなり気楽になりました。また、わたしは人生に悩んでいたころに100冊以上はこの手の本を読んできましたが、この2冊を上回る本にはついに出合わなかったです。また、ほとんどの自己啓発本は100年近く前に書かれたこの本と似たようなことを書いているので*1、何も読んだことがない状態からなら、この2冊だけ読めば事足りるかなと個人的には思います。
余談ですが、わたしは本書の存在を昔から知っていましたが、表紙が独特なのでカルトの教本かなにかだと思って敬遠していました。読んでみるとそんなことはなかったです。どこかのセミナーに行けとかお布施をせよとかは書いてないです。
はじめてのGTD
自分のあまりの計画性のなさに絶望して色々TODO管理方法について模索していたころに読んだ本です。端的に言うと「やるべきことを人間の脳に記憶せずに紙でもなんでもいいからどこかに書き出して管理せよ」「あるときには一つのことだけに集中せよ」です。やるべきことをどこかに書き出すというのは実に効果があって、スケジュール管理が(うまくはないが)かなりマシになりました。本書については別記事でも触れています。
敗者のゲーム
素人はアクティブファンドを買わずにインデックスファンド買っとけという話です。ごもっともだなあと思いました。現在のわたしの投資スタイルを決めるのに一番影響を受けた本だとおもいます。
証券分析、賢明なる投資家
ウォーレン・バフェットが好きだったので、そこから彼の師匠であるところのベンジャミン・グレアムのこれらの本にたどり着きました。現在のわたしの投資のうち、個別株投資はこれらの本に基づいた怪しい式を使って割安かどうか判断した上で決めています。
イノベーションのジレンマ
成功者が新しいことをするのの難しさ、難しさを克服して実現するために何をすればよいかについて書かれた本です。「なるほどなあ」と思うことばかりでとても楽しかったです。たぶん主な読者は経営者だと思うんですが、経営者ではない技術者の私にも「この技術はまだまだオモチャで既存のあれには遠く及ばないね」とか思っちゃいがちなことを思い出して、よい戒めになりました。
放浪の天才数学者エルデシュ
世間がイメージするステレオタイプの数学者の典型例のような、色々な意味でブッ飛んでいるエルデシュの伝記です。今まで読んだ伝記の中で一番印象に残ったかもしれません。ただ、その中で一番心を打たれたのは天才数学者としてのエルデシュではなく、彼の母が亡くなってからかなりの時間が経った後に母がいないことに悲しむ姿でした。どんなフィクションよりも感動したのを覚えています。
大学、中庸
儒教の経書のうち、とくに重要とされる四書の中の2冊です。「いいこと言ってるなあ」と痛く気に入って、今でも自分の行動規範の一つになっている気がします。ただ、骨の髄までしみわたっている…というわけではなく気に入ったところだけを覚えて都合のいいように解釈しているだけです。
残りの「論語」と「孟子」は読んだには読んだのですが気に入らなかったです。とくに論語は説教臭くて嫌でした。大学も中庸も同様に説教臭いのですが、なぜかはわかりませんが平気でした。
銀河英雄伝説
読んだのはずいぶん前なのでうろ覚えですが、小説の中では一番考え方に影響を受けたかも。登場人物もかっこいいです。アニメ(古いほう)も何周も見ました。
モモ
時間の大事さを思い知らされました。とてもいい本です。効率を追求しすぎる人や自分をインターネット中毒、SNS中毒などと考えている人が読むと、とくに嬉しいかもしれません。
星を継ぐもの
SFの金字塔と呼ばれるやつですね。SFは数えるほどしか読んだことはないんですが、本書はとてもよかったです。「SFはちょっとなあ」…と思って食わず嫌いをしている人(私もそうでした)もぜひ。
おわりに
それではこの辺で終わりにします。本記事は書こうと思い立ったときに思いついたものだけ書いているので、他にもたぶん感銘を受けた本はたくさんあると思います。それらについては思い出したらまた追記するかもしれません。
*1:参考資料として挙げられていることも多いです
人の好みは千差万別。完璧なものは作れない
なんらかのコンテンツを作って発信したい、あるいはしている人向けの記事です。筆者が過去に書いた本(コンピュータ技術についての解説本)に対する様々な評価を実例として、万人が100点満点と評価するコンテンツを作るのがいかに難しいかということを述べます。
本記事は、以下記事の「答えが無いものについての反対意見」について少し掘り下げたものです。
satoru-takeuchi.hatenablog.com
では早速、上述した拙著の読者から寄せられたご意見から、本記事に関係が深いものを列挙します。すべて同じ本に対する実際の感想です。
- 書いていることの詳細度について
- 細かく書きすぎていてわからなかった
- ちょうどよかった
- もう少し詳しく突っ込んだところを書いて欲しかった
- 扱う範囲について
- 機能Aについて書いていないのが残念だった。網羅性が足りない
- 他の本にはよく書かれている機能Aを思い切って省いていたのがよかった
- 機能Bと機能Cの比較をしているのがよかった
- 機能Bと機能Cはどちらかだけ書けば十分でもう片方は不要
- 難易度
- 簡単すぎて全部知っていた。買う意味がなかった
- ちょうどよかった
- 難しすぎて理解できなかった
見ての通り、上記のコメントをしたかたがたの意見を反映しようとすると、全員を満足させるのが不可能なことがわかります。なので、何かを作ろうとしたときは、誰からも不満が出ない完璧なものを作ろうと気合を入れるのではなく、作ろうとしているものを見せたいターゲットを明確化して、その人々に自分の伝えたいことを伝えられたかを基準に評価を眺めると良いかなと筆者は思います。
完璧を目指せば目指すほど、不満の声にがっかりしてしまって、次のものを作る意欲が失せてしまいます。多くの目に触れれば触れるほど不満の声が多くなるのは避けられないものと考えると、このような不幸な事態は避けやすくなるでしょう。多分。
最後になりますが、このような話は遥か昔から「あるある」だったようで、ろばを売りに行く親子が有名です。ご興味のある方はリンク先をご覧ください。
めんどくさがり屋にハイスペックな体組成計が使いこなせなかった話
私は何年も減量に取り組んできました。減量には定期的な体重測定と、測定結果の振り返りが大事だそうです。本記事はこの定期的な体重測定が何年も全然続かなかったのが、ちょっとした変更によってできるようになったという話を共有します。それによって体重が減ったかどうかは定かではありませんが*1、それについては本記事のスコープ外です。
最初に「毎日体重測定するぞ！」と思った数年前に、やる気一杯で健康器具メーカーの一番いい体組成計を買いました。「体重、体脂肪、筋肉の量などなどなんでもとれるぜ、しかも結果はBluetoothでスマホアプリに送れるぜ！」とはしゃいでいたと記憶しています。
ところがこれが続かない。測定できない日がたまにあるとかそういう問題ではなく、データをとってない日のほうが多いというありさまでした。そんなある日、「ちょっとこれはなんとかせんといかんな」「なにがまずいんだろう」と振り返りをしたところ、いくつかのことに気づきました。
- 全データをとろうとすると両手に測定用の棒みたいなのを持って体組成計の上で一分くらいじっとしていないといけないのか苦痛
- アプリへのデータ転送が全自動ではなく、アプリを立ち上げて「体組成計からデータを受信する」というボタンを押さなければならなかった。これが苦痛
- 体組成計がデカくて重くて邪魔と思っていた
- せっかくデータをがんばってとっても後から見返すのは体重だけだった
その後、上記のことを踏まえて、体重しか測れないけれども軽量小型の体重計を買ったところ、何の問題もなく毎日体重を測れるようになりました。
この経験より、次のようなことを思いました。
- 自分のめんどくさがり具合が思ったよりすごかった。自分を知るのは大事
- これくらいの人には多機能さより「とにかく簡単に手早く使えること」を優先させる方がいい
- たくさんデータをとっても使わなければ無駄。無いのと同じ
とくに最後のところは本業であるはずのコンピュータシステムの運用における「メトリクスはとればいいというものではない」という話に通じるものがあって、考えさせられました。
おわり。
*1:変更後に3kg減ってるのですが、同時期に食事を変える、食事の記録を取るようにした、運動量を増やした、などの変化もあったので、どれがどれだけ効いたかわかりません
著作の英訳版を出すための取り組みを始めた
去年、Linux、とくにLinuxカーネルの役割を図解と実験によって説明する本を出しました。
この本は幸いにもけっこうな好評をいただきまして、現在も売れ続けています。本書は私の知る限り日本には類書が存在しなくて、かつ、英語の本でも同じことがいえるため、本書の英語版を出したいなという野望を持っています。本記事はこの本の英語版を出すぞという意気込みを示しつつ、現在は目的の達成に向けてどういう活動をしているのかについて書きます。
本書は「増補改訂版」とあるように第一版があります。こちらもけっこう売れて、かつ、中国語版(簡体字&繁体字)、韓国語版も出ました。増補改訂版も今後もしかすると、これらの言語に翻訳されるかもしれません。というような事情もあって「英語版もいずれ声がかかるんでは」くらいに軽く構えていたのですが、色々と調べたり、詳しそうな人に聞いたりしているうちに、ちょっと無理筋っぽいということに気づきました。具体的にいうと日本語のIT技術書を出して、まあまあ売れたり好評だったりする程度では、英語圏の出版社には本書の存在に気づいてすら貰えないということを知りました。
たとえば日本の出版社の中には英語の技術書が出ると、翻訳したら売れそうかなどをチェックしているところがあります(だからこそ我々は英日翻訳された本を読める)。これと同様に中国や韓国、台湾の出版社には日本の技術書をチェックしているところがあるそうです(わたしの本の翻訳が出たのはこのパターンのはず)。で、米国の出版社が日本語の技術書をチェックしているかというと、どうもそんなことは全然無いそうです。
最近ではどんな本が英訳されたんだろうと軽く調べてみると、「ゼロから作るDeep Learning」の英訳版だけ見つかりました。この本がどういう経緯で英訳されたのかは知りませんが、この本は20万部以上売れた化け物コンテンツなので、もし仮にここまで売れないと英訳の話が来ないというのであれば、かなりつらそうです*1。
このことを知ってからは、「ならば自分で英訳して売り込めばいいのでは」と思うようになりました。ただし、以下の理由によっていきなり全部を英訳して持ち込みというのはちょっと無理筋かなと考えました。
- 英語力が大したことない。GitHubとかで「なんとか通じる」程度のブロークン英語はいけるけど、それだけ
- 日本語の英訳にはものすごい手間と時間がかかるので、その間いろいろなものを犠牲にしなくてはいけない
- 翻訳を人に依頼するとしても、なんだかんだで直しなどの時間がかかるし、お金もすごくかかる*2
- 全部完成させて持ち込んで断られると悲しい
ではどうすれば…と、悶々としていたある日、ChatGPTでGPT4を使うと、かなりの品質で日本語文の英訳ができそうという話をtwitterで見ました。
僕のコンパイラ本を英語に翻訳しないといけないなーと思いながら5年くらい放置していた結果、自分でやらなくてもChatGPTでできるようになってしまった。翻訳のクオリティが高すぎて、えー、すごすぎ・・となってる。 https://t.co/xaiIIacVtI
— Rui Ueyama (@rui314) 2023年3月20日
ものは試しと本書の一部をChatGPTで翻訳してみると、よく見ると若干おかしなところがあるものの、少なくとも私の英語よりははるかにマシなものが出力されました。というわけで今は最新テクノロジーであるところのChatGPTを使って本書をちょっとづつ訳して無償公開して、いずれ英語圏の出版社の目に留まるといいなあ…という活動をしています。具体的にはdev.toというサイトで連載記事のような形で公開しています(例: 一本目の記事)。
ChatGPTは応答が遅かったり単位時間あたりのAPI発行数制限があったりしてこれはこれで面倒なんですが、全部自力で翻訳するのに比べたらはるかにマシなので、種まきのつもりでちょっとづつやっていきます。英語がたまにおかしいのは百も承知なのですが、別に完璧な英語を書くのが目的ではなくて、多少英語がヘタクソでも許容してくれる人に、自分のコンテンツに価値があるかどうか判断してもらえればそれでいいのです。
この活動の現状がどうなっているかというと、「本出したら読むよ！」とコメントしてくださるかたが少なからずいて、dev.toのアカウントのフォロワーも200人近くまで増えるなど(アカウント名からするとだいたいは日本人の名前ではない)、出だしは順調です。今後どうなるかはまったくわかりませんが、これからもやっていきます。
最後になりますが、この活動に賛同してくださり、かつ、英語圏の出版社に知り合いがいるかたは上記の連載をそのかたに紹介していただけると助かります(わたしのメールアドレスは記事の末尾に書いています)。
タスクの終了条件を理解していなかったことによる失敗
仕事してるとさまざまなタスクをこなすことになります。タスクの粒度、期限、難易度などは物によって異なりますが、共通しているのはタスクの終了条件を満たして初めてタスクは終えられるということです。本記事では、この当たり前過ぎて何をわざわざ…というところをわかってなかった社会人になりたての頃くらいの失敗を共有します。なお、当時を知っている人が「ああ、あの件ね」と特定できない程度に、適当に話を脚色してます。
ことの発端はザクっと書くと次のようなものでした。
- あるシステムでトラブルが起きて、考えられるのはソフトウェアfooかbarか、いずれかの問題だった
- fooとbarは別のプロジェクトの管轄下にあった
- 一週間以内に問題を解決するか、あるいは回避策を出すというタスクができた
- このタスクのfoo側の担当がわたし、bar側の担当がAさんになった
このトラブルについて私が初期調査をすると、fooに問題があるように見えないことがわかりました。更に色々調べた上で「この現象はfooの問題では説明つきません。たとえばbarがこうなっていたら起こり得ます。barの挙動について確認してくれませんか」という連絡をトラブル発生当日にしました。ところがbar側の担当のAさんは「やってない」「忙しい」と何もしてくれず、催促をしてもそれは変わらないまま数日が経ちました。
そんなある日、同じプロジェクトの先輩に「あのタスクはどうなったのか」と話を振られました。わたしは「自分の初期調査は終わってAさんに依頼した。でもAさんが動かないから先に進まない」と回答して、「Aさんはとんでもねえやつだな」と同意されるのを待っていました。しかし、返ってきたのは同意ではなく、「え、じゃあなんで上にエスカレーションしてbarのプロマネに動いてもらわないの？」という困惑混じりの再質問でした。そう言われて実際にそうすると話はさっさと動いて、期限内にタスクは無事解決しました。具体的にはbarのリーダーはこちらへの謝罪とともに担当者をすぐに替えて、代理の方は当日中に私の仮説が合っていたことを確認してくれて、かつ、回避策も見つけてくれました。
ここで言いたいのは「Aさんがいなくなってスッキリ爽快＆俺の言ったことは正しかった」…ではもちろんなく、私はやること全然やってなかったねということです。
このタスクにおいて私は2つの大きなミスをしました。
- 「問題の解決あるいは回避」というタスクの終了条件を忘れて「犯人はfoo以外」とわかったところで半ば終わったつもりになっていた
- Aさんに正面から依頼し続けても無意味だとわかったところで別の手段(上へのエスカレーションや別の人への相談など)を考えなかった
これはシステムのユーザ目線で見ると、わかりやすいです。目の前でトラブルが起きて早期解決をしたいシステムのユーザから見ると、fooとbarのどっちが悪かろうとAさんが何もしてなかろうと、そんなのは知ったことではないのです。自分がユーザだとして「fooじゃなくてbarにバグがあるっぽいんですがbarの担当者から反応がないんですよ」とか言い訳されるとめちゃくちゃ怒るでしょう。そこのところを当時の私は何もわかっちゃいなかったのです。
我ながら、今書いているだけで背筋が凍るような意識の低さなんですが、社会人になりたてだとこんなやつもいるよねということで、ご容赦下さい。記事の中の「…同意されるのを待っていました。」のあたりまでを「そうだよね」とひっかかりを覚えずに読んでしまった方が将来私と同じ過ちを繰り返さないようにすることを願いまして終わりにします。
外部イベントの楽しみ方
みなさんが所属している会社や学校などの組織から見た外部のイベントを楽しむ方法をいくつか書きます。ここでいうイベントとは、いくつかセッションがあって、最後に懇親会があって…という形式のものを想定しています。本記事の前半ではここ最近再開されつつあるオフラインイベントについて書きます。後半ではオンラインイベントやハイブリッドイベントについて述べます。筆者はIT技術者で、かつ、オープンソース関連のイベントに出ることが多かったので、これに近いところにいるみなさまにはとくに役立ちやすいかもしれません。
イベント参加でうれしいこととして、まずはセッションの聴講によって業界技術の最新状況や他社事例などを見られて知識が増えることが挙げられます。これは多くの方々が既に経験されているのではないでしょうか。
イベント参加にはそれ以外の楽しみ方もあります。具体的には外部の人たちとの双方向コミュニケーションです。これによって自分が所属している組織内の、ある種自分と似たような人々とは違う立場から新鮮な意見を聞いたりできます。さらに「この人は信用に足る」と思ってもらえれば、イベント後に別の誘いを受けたり、ほかの人を紹介してもらったり…といったこともあります。このような双方向コミュニケーションこそイベントの本番であると考える人は筆者を含めて、少なくありません。
「でもどうやって気になる参加者に話しかければ…」という人もいらっしゃるでしょう。そのような場合は、興味深かったセッションで質問してみたり、あるいはみなさん自信がセッションで喋る側になって話題を提供するという方法もあります。いずれにせよ、もともと知り合いではない人と新規にコミュニケーションをとるには、いきなり「○○と申します」などと話しかけるより、話の種があると非常にやりやすいです。
ここからは、オンラインイベント、あるいはオンラインとオフラインのハイブリッドイベントなら上述の楽しみ方はどう変化するかということについて書きます。まずはオンラインイベントについていうと、セッションを聴くという目的は達成できるものの、双方向コミュニケーションがなかなか大変です。オンラインイベント向けにはさまざまなプラットフォームがありますが、どれもオフラインイベントよりコミュニケーションコストが高くなりがちです。まず、セッション動画をリアルタイムでYouTubeなどから配信する場合、セッション後の質疑が通信の遅延の問題でリアルタイム性が低くなるため、質問者と講演者の間で複数回やりとりするのはなかなか大変です。遅延を回避するために配信システムに聴衆も入れると、誰がいつしゃべるかという調定が難しく、収集がつかなくなりがちてす。廊下や懇親会での会話に相当するものを実現するのも大変です。
もちろんそれっぽいことができるプラットフォームもありますが、わたしはオフラインの場合よりも気になる人に声をかけるのがやりにくいと感じています。ただ、このへんの感覚は慣れや性格にかなり依存するので、人によっては何ら苦労していないかもしれません。あくまで個人の意見です、
ハイブリッドイベントの場合はオフライン会場のほうが情報量が多いこともあってオフライン参加者とオンライン参加者との間で熱量に差が生じがちです。オフラインでは大盛り上がりなのにオンラインの人たちは置き去りになって…というのをよく見てきました。もちろん私がかつて参加したハイブリッドイベントではあの手この手でこの問題を解決しようと開催側の方々が奮闘していましたが、現代のテクノロジーが両者のコミュニケーションコストの差を埋められていないとな感じました。
オンラインでなにかをするのに消極的な人は「F2Fで会わなければ分かり合えないことってあるよね」などと言いがちですが、筆者は「オンラインでもオフラインと同等のことがやろうと思えばできるが、コストが高い」と感じています。
最後にまとめ。本記事では外部イベントに参加するとセッション聴講によって新知識が得られるだけてはなく色々な人と繋がって刺激が得られたり、また、なんらかの新しい道がひらける事があるという話をしました。また、現状ではイベントにオンラインで参加するほど、このようなことがやりやすいという筆者の私見を述べました。本記事が誰かのなにかに役立つことを祈って終わりとします。
