2021年の振り返り

今年も何をやったか振り返っておきます。

会社員としての仕事

ストレージチームのメンバーとして、ひたすら社内新インフラのストレージ開発をしていました。成果は以下の場所にK8sマニフェストとしてまとまっています。

github.com

github.com

成果は以下のような形で外部発表しました。

speakerdeck.com

speakerdeck.com

speakerdeck.com

Rookのメンテナという立場では去年に続き自分でコードをコミットしたのはもちろんレビュー回数がその倍以上になったので、メンテナの仕事をちゃんとやってるなあと年末に実感できました。それに加えて今年のKubeCon+CloudNativeCon 3回すべてで登壇して、デモを担当しました。

kccnceu2021.sched.com

kccncna2021.sched.com

kccncosschn21.sched.com

このうちヨーロッパ開催(といってもVirtualですが)のものについてはKubernetes Meetup Tokyoにおいてrecapもしました。

speakerdeck.com

わたしが仕事でかかわっている主な社外OSSはRookとCephで、去年まではコミットのほとんどがRookだったのですが、今年からはちょくちょくCephにも顔を出すようになってきました。Cephもコア開発者になれるくらいの実力を身に着けて前述のインフラの安定稼働に向けてこれからも頑張っていきます。

あとは会社員として前職を含め初めて雑誌記事を書きました。Software Design 12月号の「OSSとの上手な付き合い方活用」という特殊の1,2章を担当しました。

gihyo.jp

個人事業

Software Designの4月号の「新人教育に役立つLinux総復習」という特集のプロセス管理の章を担当しました。昔はこの手の情報は骨の髄に叩き込んでいるはずでしたが、実は叩き込まれていなかったようで、ジョブ管理のあたりとか、わりと忘れていることが多くて思ったよりも多くて書くのに難儀したと記憶しています。

gihyo.jp

以前出した、ブログや後述のzennに書いたIT系のエッセイをまとめた同人誌の第二版を出しました。第一版に続き好評だったようで何よりです。次の次の技術書典で三版も出す予定です。

techbookfest.org

あと二冊目の単著の原稿の完成が見えてきたので、来年の春ごろに出るとうれしいなあとか思っています。といっても今泣きながら仕上げをしている段階なので、まだまだわかりませんが…

IT系の無償情報発信系

たくさんあるので全部書ききれないんですが、ざっと書くとzennの記事21本、youtube動画7本、などなどです。

zenn.dev

www.youtube.com

これらのやる気の源泉となるgithub sponsorsにもone time、monthly両方についてたくさんの寄付をいただきました。みなさん本当にありがとうございました。

github.com

今後もこの活動については「活動に賛同してくださるかたがたから寄付を募って、それを気合いに変換してコンテンツを作って無償提供」というやりかたを続けようと思います。

趣味

コロナ禍のおかげで外出が減ったこと、および外出しても行くところが非常に限られているという事情によってカメラの出現回数が去年に続き少なかったです。飽きたわけでは全然ないので普段見慣れているものを撮るであるとか家の中の小物を撮るとか、新しい試みをしようかと思っています。

去年までは作業中にコーヒーばっかり飲んでいましたが、飲みすぎで不調を来すことがよくあったので、中国茶や紅茶を飲み始めました。中国茶工夫茶器がかっこいいので買いました(リンク先の店でではないですが)。おいしいし見た目も美しいので非常によいです。

コーディング系でいうといままでPython嫌いだったんですが新しい本のサンプルコードを書いているうちになかなかいいなと思えるようになってきました。

まとめ

あいかわらずインプットに比べてアウトプット過多で生き急いでいるふうですが、何もしないよりはいいのかなとか思ってます。

「Linuxのしくみ」のサンプルコードの改善

拙著「Linuxのしくみ」の一部のサンプルコードを改善したものを公式githubリポジトリに置きました。一部についてはグラフ描画もしてくれるように変更しました。

amzn.to

Ubuntu20.04において動作する、本書において書かれたCプログラムをGoやPythonに移植して、かつ、コメントを日本語にしたものを各章のmiscディレクトリに入れています。必要なパッケージは以下の通りです。

binutils, build-essential, golang, python3-matplotlib, python3-pil, fonts-takao

2章

3章

4章

  • sched: sched.cに対応するPythonプログラム。結果をグラフ化にして"sched-<並列度>.jpg"に保存。

以下、1CPU上でschedプログラムを動かした結果を示すグラフです。上から順番に1並列、2並列、3並列のものです。

5章

6章

  • cache.go: cache.cに対応するGoプログラム。go build cache.goでビルドできる。

以下、cacheプログラムを1CPUコアあたりのL1d,L2,L3キャッシュ容量がそれぞれ32KB,512KB,4MBのCPU上で動かした結果を示すグラフです。

書籍を使った勉強のしかた

わたしがこれまでに書籍でなにか新しいことを学ぼうと思ったときにどういう手段で目的を達成してきたかについて書きます。生業にしているIT系のこともそうですが、それ以外も同じ方法を使っています。

はじめに書いておくと、これまでの自分自身の体験や優秀な人の観察などから、学習の原則コツコツと反復練習を続けることであり、近道は無いと思っています。原則を守るための典型的な方法の一つが「網羅的に書かれた決定版と呼ばれる本を何度も精読する」です。これができる人はこうしたほうがいいと思いますし、ここから先を読む必要はないです。しかしながら、わたしはこの方法がうまくいったためしがないので、自分なりに工夫して、金銭的コストがやや高いながらそこそこうまくいく方法にたどり着きました。本記事ではこの方法を紹介します。

わたしは何かを理解しようとするときには、まずは初心者向きのページ数が少なくて読みやすそうな本をたくさん買います。そのジャンル名、および「参考書」などというワードで検索するとまとめサイトの一つや2つはひっかかります。そこにあがっているもののからフィーリングで5~10冊くらい買って、読みふけります。ページ数が少なくて読みやすいがゆえにサクッと読み終えられて達成感が得られます。そのまま勢いに乗って全部読み終えるまで続けます。

これらの本を読んでいるときは一字づつ噛みしめるように読むのではなく、ほぼ流し読みです。200ページくらいの本なら30分から1時間位で読み終えます。読んでいるうちになるほどと思ったようなキーワードがあれば覚えておきます。「この本なんかおかしなこと言ってるな?」となれば最後まで読まずにその本は即座に切り捨てます。

何冊か読んでくると重複する内容が増えてきます。これによって、本を書くほど詳しい人の多くが言及するほどの「その分野のとても大事なところ」が浮かび上がってくる、かつ、そのようなところを自然と復習できるという利点があります。

乱読が終わった後は気になる本を再読するなり定番本に移行するなりします。ここまで来たら同じ分野の本を読む勘がつかめているので決定版的な本を読む苦労は最初から読む場合よりは全然少なく済みます。また、ここまで来て全く興味がわかない場合はどうしても学ばなければならない場合を除き、今の自分には必要ない知識だと割り切って学習をやめます。

この方法はたくさん本を買うので金銭的コストは高くつくのですが、すくなくともここ十年ほどはうまく機能しています。なかなか学習がうまく行かないという人は一度試してみてはいかがでしょうか。

おわり

一時的に無職だったころを思い出す

前職を辞めてから今の会社で仕事をはじめるまでの数か月間、まったく収入の無い無職でした。ふとそのときのこと振り返ってみたくなったので書きます。とくに悲壮感に満ち溢れていたり、面白おかしかったりはしない話です、これから無職になりたい人とかなりそうな人にはもしかすると参考になるかもです。

無職になってから数か月は本当に何も収入が無かったです。びっくりしたのは何も悪いことをしていないのに毎月お金が減ることでした。これはふざけて言っているんではなくて当時の偽らざる思いです。長期間食っていくだけの貯金はあって金銭的には余裕があったはずなんですが、これまで毎月増えていた持ち金が突然減りだしたので「このままでは減っていく一方」「これが尽きたら死ぬかもしれない」という感覚が出て、なかなかスリリングでした。定期収入大事。

お金が減るスピードもなかなかのもので、前年の収入を基準に支払額決まる住民税や国保はえらく高く感じてびっくりしたものです。給与からの天引きではなく自分で払い込むのでさらにダメージが大きかったです。どっちにしても払ってるのは変わらないんですが不思議なものです。

次は「何をしていたか」の話。しばらくは何もせずにごろごろしてようとか思ってたんですが、当時は何か頭を使っていないと落ち着かなかったので、新しいことをしようとハイスペックなBTOパソコンを買いました。そしたら運悪くハードウェアのバグっぽいものを引いてしまい、数か月にわたってひたすら原因究明するはめになりました。これまでに培ったスキルを活用できて、かつ、少なからぬ人の役には立ったはずだったのですが、別に誰と何を契約していたわけではないので当然一銭も入らなかったです。このときに「お金が欲しければちゃんと技術をお金に変換する努力をしないとなあ」と、しみじみ思いました。

この考え方は、のちに個人事業主(今は会社員との複業)になったときや再就職したときに大いに役に立ちました。あと今になって振り返ると、もっとダラダラしておけばよかったです。数年経って成長した今ならきっちりダラダラできそうな気がします。次に無職になったときは頑張ります。

続いて、前職在籍中に会社員として出会ってきた人たちとのその後の関係について。よく「会社員の看板が外れた瞬間に人は去っていく」という話がありますが、私はそういうことは全くなかったです。これには仕事を通じて知り合った人々はほとんど全員OSS開発者だったことも関係しているとは思いますが、彼らは会社員としての私ではなく、私自身になんらかの価値を認めていてくれていたということなので、とても嬉しかったです。

最後に「その後」の話。もともとは共働きだったこともあって「これからは一生無職で食っていく」と決意していたのですが、幸運にも自分を気にかけてくれる人や必要としてくれる人がいたりで、その後はなんやかんやと今勤めている会社に縁ができて、その後社員になって今に至ります。これについては「技術を磨いておいてよかった」「少なからず自分や自分が持っているものについて情報発信しておいてよかった」「必要以上に敵を作るような振る舞いをしていなくてよかった」などと思いました。

おわり。

ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい 2

↓の続きです。

satoru-takeuchi.hatenablog.com

何をするにも知名度の有無によって注目度は変わります。極端な話をすると、誰かがものすごいことを成し遂げたとしても、誰とも接点が無い人がやれば誰にも知られず、すでに名のある人がやれば注目されます。なので知名度があればそれだけでいいか…というとそうではないです。

知名度の高まりかたにはいろいろと種類があります。そのうち一つは名声を博することです。名声を博するには技術者としてのスキルや地道な実績の積み重ね、場合によっては自己プロデュース能力が必要です。とてつもなく凄いが目立つのを嫌う人もいるので一概に知名度があればいいというものではないですが、その話はここでは置いておきます。

その一方で、人から眉をひそめられるようなことをすると悪名がとどろきます。これには別に技術者としてのスキルは必要ないので名声を博するよりも簡単です。たとえば煽りタイトル/釣りタイトルの記事を書いたり、その手のプレゼンをしたり、何か*1を貶めたり…という方法が定番です。

こういうことをしながら利益を上げていく特殊能力を持つ人たちがいることは否定しませんが、本当にその人たちのようになりたいのか考えてみてほしいです。少なくとも技術者として生きていきたいのであれば、こんなことをしてもいい方向に転がることはほぼ無いといっていいです。たとえば自分が企業の人事だったとしてこういう人を雇いたいか、イベント主催者だとしてこういう人を登壇させたいかを想像してみてください。

「まずはとにかく知名度を上げて、それからイメージを変えていく」というような作戦の人もいるでしょうが、それは考えが甘いです。一度ついてしまった悪評はなかなか消せるものではありません。とくにインターネットが普及した現在ではなおさらです。

とにかく目立てれば、自己顕示欲だけ満たせれば何でもいいというのであれば最早なにも言うまいです。しかし、まっとうなソフトウェア技術者として認知されたいなら、地道に自分を鍛えてまともな実績を積み重ねていくのをお勧めします。

大学でもっとまじめに学んでおくべきだった

大学ではB4の一年間、人によってはさらにMとかDとかで研究をします。そこで学べることについて、および、それを学ばなかったがために私が苦労したことを書きます。ここでは大学に行く人を主な読者層にしていますが、そうでなくても就職した後に後述の問題に遭遇することでは同じです。

わたしは高校時代は「プログラミング一本で生きていく」という決意をしていました。そこで近くの大学に情報工学科という学科があったので、そこを受験しましたが見事落選、第二希望だった別の学科に受かりました。このあとわたしの大学生活のポリシーは「可能な限り楽をして大学を出る、その間にプログラミングについての知識を独学する」でした。B4およびMでの研究においてもそのポリシーを愚直に守り通し、手抜きに手抜きを重ねてギリギリで卒業、修了しました。不良学生というやつです。最終的にはプログラミングやその他低レイヤといわれる領域の知識は平均的なCSの学生より優れていたと思います。しかし、それだけでした。

さて、大学でまじめに学ばないというのは何を意味するのでしょうか。大学卒業後は、Dをとってその後もさらに研究を続けるような一部の人以外は、おおむね就職します。場合によっては私のように大学で研究分野とは一切違うことをする人もいるでしょう。ただしそれに意味がないかというと全然違います。大学でちゃんと学んで研究していれば、個々の業務内容によらない問題設定、仮説、検証を含めた、分野によらない問題解決のための知識、および議論する能力などが得られます。それに加えて論文執筆を通じて、それを人に余すところなく伝えるための作文能力、プレゼンテーション能力などが鍛えられます。もっといろいろありますが、ここでは比較的わかりやすいものを挙げました。端的にいうとわたしはさぼりまくったがゆえにこれらについて何も学ばなかったのです。

その結果は悲惨なものでした。自分ではいっぱしの能力を持っているはずなのに、プログラミング能力などは場合によっては入社後数年経った人よりもすぐれていたのに、まったく仕事ができないのです。「こういうことをしてほしい」と伝えられてもうまく問題設定ができない、進め方がいきあたりばったりで効率が悪い、出てきた成果物の根拠があやふや、などです。結果を人に伝えるときも口頭では「支離滅裂で何を言っているかわからない」という旨をオブラートに包みながら指摘されました。仕様書などを書いても「何をしたいか見えてこない」とよく言われて、いつも跡形もないほど直されました。書いていて辛くなってきたのでここまでにしておきますが、それはもうひどいものでした*1

それもそのはず、わたしは大学に入ってから修士課程を修了するまでの6年間、自分で思いつきでやりたいことをやって、途中で脱線してもOK、楽しければOK、人と議論することもない、ということしかやっていなかったからです。これではうまくいくはずがありません。その後問題の本質に気づいて、なんとか訓練してそれなりのことができるようになるまで2,3年はかかったように思います。正直言ってこの間はかなりキツかったです。そして表題の通り、「大学でもっとまじめに学んでおくべきだった」と激しく後悔しました。

と、つらつらと、本当に大学で何も学ばなかった私の極端な書き連ねてきたことをもとに、現在大学生の人には大なり小なり「俺はこいつのようにはなりたくない」と思ってもらって、しっかり研究活動に邁進していただければなによりです。おわり。

*1:当時の自分の生産物を今振り返ると、自分でいうのもなんですがゴミのようなものしかなくて、根気よく指導していただいた諸先輩方には頭が下がるばかりです

ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい

ソフトウェア技術者として名を上げたい人向けの記事です。

まずは前置き。ソフトウェア技術者の世界にはスーパースターといえるような凄まじい能力を持つ人達がいます。彼らのうちの一部は生活能力がゼロだったり、口や態度が悪かったり、好きなこと以外は一切できなかったりといった様々な欠点があります。すごい人の中でもこういう人は親近感を生むのか、なんとなく目立つ傾向にあるように思います。SNSなどでも粛々と技術の話だけしたりする人よりも、こういう破天荒な人たちがウケて人気を集める傾向にあります。かくいうわたしも、この手の人たちは人間臭くて好きです。

ここからが本題。スーパースターにあこがれる人が彼らのスキルを真似するのではなく、立ち振る舞いを真似してしまって、とくにSNSなどでそうしてしまって、自分の価値を貶めているのを頻繁に目にします。典型的には凄くなりたいけどまだまだ経験が足りない学生さんや経験の浅い社会人などです。技術はすぐには真似できないけど立ち振る舞いは真似しやすいのでそうなるのかもしれませんが、これは本質を外していることはもちろん、大きなリスクになりえます。

欠点が大量にあるスーパースターたちは、得難いスキルがあるからこそ少々の欠点は許容されます。ところがまだ何も持っていない人が破天荒な振る舞いをしても、ただの厄介な人になるだけです。欠点の無い人なんていないので無理して立ち振る舞いを矯正する必要はないと思いますが、少なくとも意図的に奇矯な振る舞いをすることは、わざわざ評判を下げるリスクをおかすだけなので、避けるのが賢明かと思います。その振る舞いに可愛げがあればコンテンツとして面白いので知名度は上がるかもしれませんが、それだけです。それでスキルが身に付くわけではありません。

技術者として名を上げたいのなら技術で目立つのがよいかと思います。