買ったものに積極的にフィードバックするようにした

これまでは自分が買ったものに問題があってもなんとなくtwitterとかブログに書いて終わりだったんですが、最近は積極的にフィードバックをするようにしました。

その理由は、報告して修正されたらめっけもんだし、OSSのバグはしつこく調べてissue登録/PR投稿するのに、それより遥かに簡単なフィードバックするのはそんなに面倒くさくないなあと気づいたことです。もし直って他の誰かに役立てばそれも良いなというのもありましたが、これはあくまでついでです。

ここ最近で大小5件フィードバックしたと記憶しています。前向きなアクションをして気分がいいので今後も続けていこうかと思います。

コロナ禍の序盤を振り返って素人考えは危険と思った話

はじめに

この文書は自省のための文書です。

コロナ禍が当たり前になってしまったこの世の中、初めてこの件についてニュースになってから現在まで、私の印象に残った出来事を振り返ってみました。なお、ここまでの政府の施策などについては何か正しかったのかなんてのはわからないので評価はしません。

見出しに書いているニュースの元ネタはほとんどは以下NHKのサイトです。

https://www3.nhk.or.jp/news/special/coronavirus/chronology/

改めて振り返ってみると、とくに序盤戦、いかに自分がデタラメなことを考えていたかがよくわかってゾッとしました。

では始めます。

時系列順のまとめ

1月6日 中国 武漢で原因不明の肺炎 厚労省が注意喚起

ニュースで見たとは思うが「へぇ…」くらいのもの。まったくの他人事で関心なし。

1月30日 WHO「国際的な緊急事態」を宣言+more

引き続き他人事。「中国大変ですね」くらい。

2月3日 乗客の感染が確認されたクルーズ船 横浜港に入港

「あらまあ大変ですね。全部おさまるまで外に出られないとノイローゼになりそうだな。出てきたときに差別的扱いを受けそうだな」という思い。依然他人事。

2月中盤あたり 脳天気な判断をしていた

6月にオランダで開催が予定されていたイベントに登壇する予定だった。日に日に「開催日の2週間以内に○○国に滞在していた人は参加できません」に該当する国が増えてきた。欧州は当時大した被害はなかった。

そのあと日本も対象になりそうか、あるいはなったかという段階で、「イベント開催2週間前に海外に出国すればいいのでは?わたしはぜひ喋りたい」というようなことを会社で話していた。その後の欧州の惨状を考えれば狂気としか思えないことを言っていた。

それ以外にも「インフルエンザのほうがよほど危険」くらいの意識でいた。

イベントは当然ながら結局オンラインになった。

2月27日 安倍首相 全国すべての小中高校に臨時休校要請の考え公表

「これは大変なことになった」とようやく危機感を持ち始めた。とくに息子を保育園に預けるのが困難になって日中の仕事に影響が出て我が事になったのが大きかった。

英国ジョンソン首相 PCR検査陽性

これから世界はどうなるのだろうと底知れぬ不安を覚える。

3月29日 志村けんさん死去 新型コロナウイルスによる肺炎で死去

直接の知り合いではないものの、子供の頃からよく知っている人が亡くなったことより絶句。このあたりから「自分が既に感染していても不思議ではない」と思うようになり、さらに気持ちが引き締まる。

4月7日 7都府県に緊急事態宣言 「人の接触 最低7割極力8割削減を」

ついに来たか、という印象。とくに驚かず。この時点では何が起きても異常とは思わなくなり、正常化バイアスが働いていたのだと思う。この感覚はいままで続く

おわりに

いちいち危機感を持つのが遅かったです。それに加えて何も知らないことについて知ったような顔をして、斜に構えていました。こういうのが要職についていると非常に邪魔なタイプですね。

素人考え危険、とにかく反省、今後に活かします。

ゼロほど怖いものはない

わたしのゼロに対する考え方を書きます。たくさんの人が似たような話をしている手垢のついたネタですが、自分の言葉で一度考えを整理したくて書きました。

世の中にはゼロという言葉が踊り狂っています。私の業界でいうとバグゼロ、工場で言えば事故ゼロなどです。こういうのは「そうあれたらいいな」くらいの理想としてはいいのですけど、必達目標にしてしまうと非常に危険なものに化けます。

なぜかというとゼロにするのが多くの場合非常に難しいからです。たとえばバグの話でいうと、かなり単純化して言うと、「バグゼロ必須!」という人はバグの数を20から10に減らすコストが100万円だとして10から0にするコストも同程度と考えているフシがあります*1

実際には、こちらも単純化するとバグの数を10%減らそうとするごとに100万円かかるので0にするのは至難の業、といったところです。

では事実上無理なことを必ずやれと言われた人はどうするかというと、嘘をつきます。バグが出た事実を完全に握りつぶしたり、バグではない別の言葉で置き換えたり、などなどです。仮にバグが出たとしても上司には実際の理由よりも耳障りの良いもっともらしい理由を述べるでしょう。そうしないと吊るし上げがより苛烈になるからです。

ということを踏まえてわたしはゼロという言葉を振りかざす人も、かなりの長期間それを達成できているという情報を見ても、凄いというよりは、むしろあまり信用できないと判断します。似たような意味で100%をやたら強調するのも同じく危ないと感じます。

*1:そうでなく後述の認識を持つ人が立場的にこういうことを言う場合もありますが

今年の振り返り

はじめに

今年はコロナ禍のおかげで世界的に見れば疑いようもなくひどい年でした。しかしながら、わたし個人について振り返って見るとけっこう頑張ったではないかと思い、まとめてみたのがこのエントリです。半分くらいはただの自慢なのですが、ベテランといわれる年代のソフトウェア技術者は一年でどれくらいのことをするのかという目安の一つとして見てもらってもいいかもしれません。

仕事

会社員として

KubeConで発表

なんといってもKubeCon Europeにproposalが通って発表できたのが大きいです。このイベントは数十人に一人しか採択されない狭き門なのです。

kccnceu20.sched.com

これは「私と共同発表者の松田さんが2人でやったった!」というものではなく、プロジェクトみんなで頑張って作ったCSIドライバが世間の興味をひいたおかげです。KubeConについては先月のKubeCon North Americaでもプロジェクトメンバのproposalが通ったりして非常によい感じです。ぜひ次回も通して三連勝といきたいところです。

kccncna20.sched.com

Rookのメンテナに就任

つづいてCNCFの公式プロジェクトであるRookへの継続的な貢献が認められてメンテナになりました。メンテナとは何か、何をすればなれるのか、なると何が嬉しいのか、なって何をする気なのか、などなどについて興味のあるかたは以下のブログエントリやスライドをごらんください。

blog.cybozu.io

speakerdeck.com

来年もバリバリ貢献していこうと思います。なおRookのメンテナ就任にあたっても、私一人ではなく、プロジェクトメンバ一丸となっての貢献が評価されました。チームプレイ大事。

余談ですが、新卒3年目、いまから10年以上前に立てた人生の大目標が「多くの人に使われている有名どころのOSSのメンテナになる」だったので、それがかなって非常に感慨深いです。ソフトウェア技術者としての次の大目標は何にしようかな。

Japan Rook Meetup

Rookについては去年に続き今年もJapan Rook Meetupを主催者の一人として3回開催して、いずれも好評を得ました。RookやCephを多くの人に知ってもらうと共に、自分の所属プロジェクトや会社がRookにコミットしていること、およびそれができるだけの能力があることをしっかりアピールできたのではないかと思います。このイベントについてはKubernetes用のCephのオーケストレーションという人によってはドはまりするもののクラウド全盛の時代にあんまりユーザがいなさそうなソフトウェアのイベントに毎回100人以上参加してくださるのが不思議でしょうがないですが、とにかく嬉しい限りです。

その他対外発表をいくつかやって、かつ、会社のブログにも少なからない数寄稿しました。この手の活動は短期的にどれが何に効いたというのは言えないのですが、価値のある情報を継続的に発信するのは大事なことだと思っていますので、今後も続けていきます。

個人事業主として

雑誌連載が完結

Software Designで2年半ほど連載していた「Linuxのしくみ」が完結しました。頭の整理にはなるのは非常によかった一方で会社の仕事が忙し過労と毎月締め切りが襲ってくるのはなかなか辛いものでした。いろいろな人から毎月読んでいるよと言ってもらったりと、けっこう人気があったらしいということが執筆を続ける原動力となりました。ありがたいことです。この連載の内容はいずれなんらかの形でみなさまに提供したいなとは思っていますが、まだ確かなことは言えません。

大学で講演

ちょっと毛色が違うところでは、普通の人とはかなり異なった働き方をしていることが注目されて、大学で講演をする機会がありました。この激動の時代に社会に出なければならない学生さん向けにうまく意図が伝わっていればと願うばかりです。この講演については普段頭の中でモヤモヤしていた仕事観を整理できたので非常によい経験となりました。

speakerdeck.com

技術書典

これまで毎回参加していた技術書典は今年は一回だけ参加しました。そのときに書いた本は編集者の風穴さんがエモいタイトルをつけてくれたこともあってこれまでで一番売れました。これは一般の技術書とは異なり、私がこれまでにプログラマとして散々やってきた失敗を他の人にはしてほしくないという思いで書いたエッセイ集です。興味のあるかたはお買い求めください。

techbookfest.org

趣味

自分が得意とするソフトウェア技術の普及活動

youtuberになる

思いつきでyoutubeになってLinuxカーネルやそれに近いところの情報を配信するようになりました。

www.youtube.com

けっこうウケているようで、今確認したところ、登録人数が2900人もいるそうです。すごい。

5/30に開始してから動画はこれまでに23本作りました。今後も増える予定です。ご期待ください。23本…よくやりますね。我ながら呆れます。

github sponsorsでスポンサーを募る

youtubeはもとより、その他のソフトウェア技術に関する記事や書籍を書くときに有志に支援いただくためにgithub sponsorsの仕組みを利用することにしました。

github.com

なぜ私が提供するコンテンツの受益者から直接お金をいただかないかというところに興味のあるかたは以下のエントリをごらんください。

satoru-takeuchi.hatenablog.com

その他

コロナ禍において自分が何をできるか考えたところ残念ながら直接役立つ能力が無かったので、せめて経済を回そうと精一杯散財しました。これについては以下スライドにまとめています。

speakerdeck.com

その他にもコーヒー器具やキャンプ用品をいくつか買ったり、フルサイズカメラを買ったり、レンズを買ったりと、世界平和…もとい自分の欲望を満足させるために色々買いました。何一つ無駄なものはなく、どれも愛用しています。

おわりに

よくやった、自分!

VSCodeのterminal上でemacsっぽいキーバインドをまともに動くようにする

自分用メモ。タイトルのまんま。

わたしは普段shellはbash、プログラミングするときのエディタはVSCodeを使っています。端末上でbashを使うときのキーバインドemacsっぽいやつです。より正しい表現をするとbashが内部的に使っているreadlineのediting-modeがemacsになっています。

VSCodeはterminal機能を持っていますが、一部のキー入力をVSCodeが食べてしまうので、使用感が普通の端末とは異なってストレスフルです。このため、端末を使いたければVSCodeのterminalは使わずに別途端末ソフトウェアを立ち上げていました。これが嫌だったのでちょっと調べてterminalのキーバインドを変えました。

やりかたは簡単です。

  1. Ctrl+Shift+pPreferences: Open Keyboard ShortCuts (JSON)を選択して"keybindings.json"を開く
  2. ファイルに以下の内容を追加。
[
    {
        "key": "ctrl+p",
        "command": "cursorUp",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+n",
        "command": "cursorDown",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+f",
        "command": "cursorRight",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+b",
        "command": "cursorLeft",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+a",
        "command": "cursorHome",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+e",
        "command": "cursorEnd",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+d",
        "command": "deleteRight",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+h",
        "command": "deleteLeft",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+k",
        "command": "deleteAllRight",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+m",
        "command": "type",
        "args": { "text": "\n"},
        "when": "terminalFocus",
    }
]

わたしが普段つかうキーバインドしか気にしてないので、人によってはこれでも足りないと思います。そのときは適当に設定を追加してください。

英語を学んできた履歴と現状

自分が何のためにどういうふうに英語を学んできて、現在どうなっているか、ということをなんとなく書きたくなったので書きます。とくに推敲をせずにメモ書きくらいのつもりで書いてます。ご了承ください。

まずは私の職業、英語学習の動機や性格などについて書きます。似たような人には役立つ可能性があります。全然当てはまらない人は読んでもまったく役に立たないかもしれません。

  • ソフトウェア技術者
  • 英語はソフトウェア技術者、とくに技術オタクとやりとりするために身に着けたい。それ以外はどうでもいい
  • 好きなこと、得意なこと、必要に迫られたことはできる。それ以外はまったくできないしやる気もない

では私の約40年の人生でどうやって英語を学んできたか、何がうまくいってを書いておきます。

  1. ~小学校6年生: 英語学習の機会なし。現在は授業でやるそうだが、私のころは英語の教科が無かった。
  2. 中学1年生~高校3年生: 授業で習ったことをやっていた。他はとくになし。6年間ずっと苦手意識を持ったまま過ごす。センター試験は200点中76点だったはず。
  3. 大学B1~M2: コンピュータについての情報を英語で読むことが多くなり、readingについては上達する。興味のある内容だったことと文法が平易だったことが役立った。B4からは研究用に英語論文を読む機会があったので、それも役立った。writing,speaking,listeningは使う機会がなかったのでほぼ成長しなかった。
  4. 社会人になってから今まで(15年くらい): 必要に迫られて仕事を通じてreading,writing,listening,speaking,全てが成長した。それ以外は色々やってみたが、どれも長続きしなかった
    • reading,writing: バグ報告や機能追加のpatch descriptionやその後のやりとりが中心。日によって濃淡あれど、だいたい毎日使っていた。TOEIC向けの勉強や英語学習教材による勉強はどれも長続きしなかった。
    • listening,speaking: 仕事の会議、およびカンファレンスでの発表、その時の質疑応答などを通じて鍛えた。どちらも使う機会はそれほど多くはなく、数か月に一度ほど。listeningについてはカンファレンスのセッション動画を通じても学習した。その他英語の映画やドラマを見て学習しようとしたことがあったが、長続きしなかった。

上記のような学習を通じて得た現在の英語力は次のようなものです。

  • ソフトウェア技術に関するもの
    • reading: マニュアルのようなしっかり書かれた文書ならそこそこ。8割くらいはすらっと読める。文法で苦しむことはそれほどないが、単語がわからないことは多々ある。githubやslackでよくある文法が適当な英語は読むのが辛い。スラングやSFネタとか入ってるとさらに厳しい。
    • writing: 日本語で書くのに比べて半分かそれ以下の速度。それなりに通じる文書が書けているはずだが、たまに「なんて書いてあるのかわからなかった」といわれることが依然ある。三単現のsとか冠詞とかは適当になりがち。
    • speaking: かなり文法がハチャメチャなものは喋れる、が、けっこう途中で言い直したりと苦労する。また、「こういうことを言いたいの?」と聞き返されて何度か問答をしてやっと通じるということがよくある
    • listening: 結構辛い。何度も聞き返すことや、「それはこういう意味ですか」と何度か聞き返してようやく理解ということがよくある。
  • それ以外のもの
    • 興味がないのでそもそも使う機会が少ないが、ソフトウェア技術に関するものより苦手なのは確か。readingとwritingはソフトウェア技術についてのものより3~5倍ほど大変。リアルタイム性が求められるspeakingとlistening、とくに後者がかなり辛い。日常会話はかなり困難だし、TVや映画は全然ダメ。
    • 10年くらい前にTOEICが800点くらいだった。たしかreadingのほうがlisteningよりもだいぶ点が高かったはず。いまはどうかわからないが、readingは昔より高く、listeningは同じかやや低いという数値が出るかなと推測している

いままでの学習履歴を振り返って思ったことは次の通りです。

  • 「英語を覚えたい」という目標の設定考え方がそもそも間違っていて、最初から「英語話者の技術オタクとうまくやりとりしたい」にしていればもう少し効率的だったかもしれない。そうすると必要なことがかなり絞られてくる
  • 興味がないものを題材に学ぼうとしてもつまらないし効率が悪いしでいいことがない。「映画とかドラマを見るといいよ、必要なら字幕つけたり低速再生したり」と言われたりして何度かやってみたが、そもそも日本語でも映画やドラマを見なくて大して興味がないので辛くてしょうがなかった。で、もうやらないことにした
  • 自分の性格に合ったことをやるのが一番

というところでおしまい。これが誰かの何かに役立てば嬉しいです。

人を真似るときに気を付けていること

凄い人、尊敬する人などの真似をしたくなることがあります。IT技術に関係ないところでいうと、ちょっとした仕草や服装、髪型、などなどです。本記事では仕事のやりかたを改善するために私が現在やっていることを書いておきます。

現在わたしの身近には要領がよくて作業効率が高い、かつ、強烈に頭が切れるという人がいます。わたしはこの人に学ぶことが多いので真似をしているのですが、真似ようとしていることは前者だけです。なぜなら要領の良さというのは「全体を俯瞰する」、それをもとに「ゴールにつながるものだけをやる、それ以外はやらない」「優先順位をつける」など、ある程度は訓練によってなんとかなりそうなものという思いがあるからです。これに対してキレッキレの頭脳というのは生まれ持ったものであって、かつ、訓練に変えられるようなものではないと思っているので真似しません。

この考え方については別記事にも書きました。

satoru-takeuchi.hatenablog.com

第二に、身心の作りが違う他人と同じ土俵で勝負しようとするのをやめました。たとえば一日4時間睡眠で平気といったようなショートスリーパー、業務でのプログラミングに疲れたら趣味プログラミングで疲労を回復させるアンデッドモンスターのような人がいるのも否定しませんが、自分ではどうなるかを試してみたところ、残念ながら自分はそうはいかないという認識をしました。その結果、無理なものは無理、自分のハードスペックに合ったことをするのが一番、と思えるようになりました。

こういうことが思えるようにならないと「自分はどうしてできないんだ」「一向に改善しない」と疲弊することになります。かくいう私も過去には疲弊していました。

ここまで述べたことは本記事の読者からするとソフトウェア、あるいはアルゴリズムの改善はできるけれどもハードスペックは変えようがない、という例えをするとしっくりくるかもしれません。いずれにしても、できる人のことを闇雲に全部真似ようとするのではなく、まずは「この人はどこがすごいのか」というのを洗い出した後にわが身を振り返って、これなら真似できそうというものを見つけて楽そうなものから真似すればいいのではないかと思います。