プログラミングを始めたころとは考え方が全然変わっていることに気づいてびっくりした話

家にパソコンがはじめて来てから30年くらい、プログラミングを始めてから20年以上が経ちました。その間、IT技術に対する愛は変わらずに、ずっと走り続けてきました。では当時の自分と今の自分で何が違うのだろうと考えてみたところ、めちゃくちゃ変わっていたのでびっくりました。本記事では何がどう変わったのか、それを見てなにを思ったかなどを書きます。

昔は次のようなこだわりがありました。

  • 大きなものは一つの仕事をする単純で小さなツールを組み合わせて作るべし
  • ソフトウェアは可能な限り設定可能になっていてほしいし、それを自分の好みになるまでカリカリチューニングしたい
  • 可能な限りすべてキーボードだけで操作できるようになっていてほしい

いわゆるUNIX哲学をはじめとして、いろんな本やWebサイトなどに強い影響を受けていることがよくわかります。

ところが今は次のように全然違うことを考えています。

  • トラブルハマったときに情報が得やすくなるように、なるべく普及しているものを使いたい。デカかろうと小さかろうがどっちでもいい
  • 設定なしに最初からいいかんじで動いてくれるやつがいい
  • キーボードだけの操作にとくにこだわりはない。楽ならなんでもいい

ここまで変わったものだなあと驚くばかりです。昔は自分の使っているものすべてに対する愛が強かったのですが、仕事などで期限内に要件を満たすものを作るということを繰り返すうちに、その時その時でやりたいことを最小コストで成し遂げられるものが良いものである、と思うようになった気がします。「趣味の世界にも業務的な考え方が侵入してきたのかあ」とちょっと寂しい気もしましたが、今も考え方こそ違えど楽しくやれているので、まあいいかと割り切ることにしました。

なお、ここに書いたようなことは20年くらい前に2ちゃんねる掲示板のプログラマー板かなんかで古参エンジニアらしき人々によるまったく同じような書き込みを何度も見たことがあって、「ついに彼らのところにたどり着いたのか」と感慨に浸っております。

おわり

共訳した本、「入門eBPF」の宣伝

12/9に「Learning eBPF」という本の和訳版、「入門eBPF」という本をudzuraさんと2人で翻訳しましたので宣伝しておきます。

原著はこちら

和訳版はこちら

どういう本か

Linuxカーネルの機能の一つであるeBPFについての入門書です。ユーザはC言語Pythonなどでプログラムを書いて、それをカーネル内に読み込んで実行させるという機能です。カーネルコードに手を入れたりカーネルモジュールを作ったりせずにカーネルの情報を取得したり、ネットワーク周りの一部カーネル機能についてはカーネルの挙動を変更したりできます。著者はeBPFを使い倒していることで有名なCiliumプロジェクトのメンバーであるLiz Riceさんです。

本書を読むのに必要な知識

上述の通りeBPFを使うにはプログラミングをする必要があるので、なんらかの言語でのプログラミング経験があると思います。とくにC言語の知識があるとよいでしょう。文中でC言語についての簡単な解説があるので、C言語の経験がなくてもなんとなく理解できるようにはなっています。

カーネルの中身とはいかないまでもシステムコールが何であるかといったカーネルとユーザ空間のインタフェースについての知識はある程度必要だと思います。そこがまったくわかっていないとeBPFの意義がそもそも理解できないと思います。

推しポイント

本書のタイトルには「入門」が入っています。ここでいう入門には2つの意味があります。

  1. 「eBPFとはどういう機能なのか、どうやって使うのか」という意味での入門
  2. 「どういうしくみで動いているのか」についての入門です。

1については序盤の章でハンズオン形式で丁寧に説明してありますので、eBPFについて全く知らないかたでも「なるほどなあ」とコードを打ち込みつつ進められるかと思います。「こんなことができるのか…」ということを感じていただければいいかと思います。本書はあくまで基本的な使い方を説明しているだけで実用的なeBPFプログラムを書く方法を説明をしているわけではありませんが、そのようなプログラムを書きたいかたに向けて豊富にリンクが張られているので、参考にするとよいでしょう。日々ものすごい速度で開発が進んでいる、かつ、マニアックな機能だけに、リンク先は書籍ではなくWebサイトが中心です。

2については、実行ファイルの構造などの低レイヤあたりの知識がないと読みこなすのがなかなか大変ですが、eBPFの実行環境がいかに凝ったことをしているかがわかるので、楽しく読めるかと思います。「ユーザが書いたプログラムをカーネルの中で実行させるなんて危ないのでは…」という疑問を持っているかたは、ぜひ検証器(verifier)やしくみを見てください。余談ですが、eBPFのしくみについて書かれている章はLizさんの筆が乗っているのがわかり、筆者のeBPFについての愛が伝わってきて、見てるこっちまで楽しくなってきます。

補足

発売日当日にイベントを開催して本記事と似たようなことをしゃべっているので、そちらもどうぞ。

www.youtube.com

おわりに

技術的にアツくて高度な本なので、eBPFを使い倒したいかたもそうでないかたも、ぜひごらんください。

おわり

2023年のインプット、アウトプットの振り返り

今年もいろいろありました。インプットとアウトプットの振り返りをしておきます。いつもながら落ち着きがないというかたくさんやりましたね。

アウトプット

登壇(会社の仕事)

2つやりました。今年は思うところあって意図的に絞ってました。社ブログも一本も書いていません。

Cephaloconに4年ぶりの参加をして喋ってきました。前回2019年のときには「さあ、これからCeph使うぞ!」と何もわかっていない時期で聴くだけだったのですが、今回はCephをじっくり使い込んできた戦士として自分たちの成果をアピールできたので良かったと思います。

https://sched.co/1JKZf

speakerdeck.com

SODA Con というイベントでOSS(RookとCeph)をベースとした自社のストレージシステムの説明と、その過程でやってきたOSSへの貢献について話してきました。けっこうウケたようでなにより。

speakerdeck.com

登壇(副業)

去年と今年に出した本についてForkwellのイベントで喋ってきました。このような機会を与えてくださったForkwellの皆様に感謝いたします。

speakerdeck.com

speakerdeck.com

forkwell.connpass.com

登壇(趣味)

数年ぶりに開催されたKernel/VM 探検隊北陸においてメインセッションとLTをやってきました。仕事ではまじめなことばかりやっているので、ここぞとばかりにふざけまくりました。ふざけつつも、ちゃんと役に立つ情報も提供できたかと思います。

speakerdeck.com

speakerdeck.com

商業出版

英語の書籍の翻訳を2冊やりました。自分で1から本を書き起こすのとはまた別の難しさを感じました。とくに1冊目は大変でした。

あと翻訳とはいえオライリーから本を出したという実績ができたのはうれしかったです。

同人誌

数年前に出した「失敗プログラマー」という本を改版して技術書典で売りました。この本は同人誌にもかかわらず1200部越えでずいぶん売れました。ありがたい。また本書の対象読者と考えていた悩みをかかえる若手技術者たちからの反響もたくさんいただきました。

techbookfest.org

本書は改版するたびにページ数が倍に増えていくのですが、来年も倍…とはいかないまでも改版できればしたいなと思います。できればついででいうと、いずれまとまった量になれば商業出版したいなあとかも考えています。

YouTube動画

14本の動画を公開しました。まずまず。有償の会員になってくださったかたが2桁になって、うれしい限りです。明に「とくに会員のメリットは無い。しいて言うなら動画公開のペースが早まるかも」と宣言しているのに、ありがたい限りです。引き続き募集中ですのでよろしくお願いします。

www.youtube.com

zenn記事

4本公開しました。ずいぶんと控えめでした。

zenn.dev

はてなブログエントリ

この記事を含め16本公開しました。まあまあ。いつも通り、気合い入れたものがまったく反応がなかったり、適当に書いたものにたくさん反響があったり、おもしろいです。

satoru-takeuchi.hatenablog.com

インプット

英語学習

PROGRITのビジネス英会話コースを受講。一日平均2.1時間の学習をしていました。VERSANTのスコアが43から51にアップしました。かなり上がったほうらしいです。めでたい。おかげで上記のCephaloconの発表や休憩中などの議論などにずいぶんと役立ちました。

3か月間講師のかたにケツを叩かれ、励まされ、指導していただき、非常に充実していました。英語力を短期間で爆上げしたい、かつ、覚悟が決まっているかたにはお勧めできます。ただしかなり高価ですし時間の捻出が大変なので業務の一貫でやるのがいいかなと思います。

読書

おそらく50冊くらい。100冊くらい読みたいと思っていたが、そうもいかなかった。息抜き不足だろうか。来年はもうちょっと増やしたいです。

来年

インプット多めにしたいと思います。まず、プログラミングが苦手なので、もうちょっと鍛えたいなと思います。設計スキルも磨きたいです。あとはネットワークやRDBの知識など、自分が専門とするところ以外の知識が非常に弱いので何とかしたいと思います。

あと共著の書籍が1冊出ます。売れるといいですね。今一冊書いているので、そちらも出せるといいな。

おわり。よいお年を

外部発信のはじめの一歩

わたしはよくIT技術系の外部発信をします。手段は記事や書籍の執筆やYouTube動画公開、登壇など、いろいろあります。その立場から、実例をもとに外部発信をするコツを紹介したいとおもいます。外部発信にもいろいろありますが、査読付き論文を書くとかいうすごいことではなく、さくっとブログ記事を書いたり、どこかの勉強会で発表するなどのことを軽いノリでやることを想定しています。

おもな対象読者は「なんらかの外部発信をしたいけど全然できない」「どうやればできるんだ」などと日々モヤモヤしているかたです。既に外部発信の実績がたくさんあるかたにとっては、人のスタイルを知るといいことがあるかもしれません。外部発信にとくに興味がないかたには役に立たないかもしれません。

三行まとめ

  • まずは「やる」と決める
  • 普段からちょっとしたことに疑問を持って、調べて、ネタを集めておく
  • 今できること+αくらいで、できる範囲でやる

きっかけ

今回紹介するのはKernel/VM探検隊北陸part6というイベントでの「device mapperによるディスクI/O障害のエミュレーション」という発表に至るまでの流れです。

www.youtube.com

speakerdeck.com

このイベントが開催されるのはXで知りました。開催場所が自分の住んでいる場所から2時間もかからず行けるところだったのと、旧知の人々と会えること*1、なんかアウトプットしたいと思ったことなどから申し込みました。

ネタは全然考えてなかったですけど、申し込んだら思いつくだろうと思って申し込みました。このあたりは性格によってかなり変わるのですが、締め切りを設定しないと何もやらない人、締め切りが近づくほど謎のパワーが出てくる人には有効な技です。追い込まれると潰れてしまうタイプの人はさすがにネタを考えてから申し込むほうがいいと思います。

とにかく大事なのは「やる」と決めることです。「いつかやろう」「そのうちやろう」で止まっていると何もできません。「やる」と決めて、それを表明する、実際に動き出すのが大事です。

ネタ出し

私の発表ネタは前々から頭の中にぼんやり浮かんでいた、以下のような思いがきっかけで浮かびました。

  • Linuxカーネルのdevice mapperという機能は、世の中でかなり使われているがいまいち地味で目立たない
  • とくにディスクI/O障害のエミュレーション機能については世の中に公式ドキュメント以外の情報があまりない
  • 難しいことをしなくても、これらについて紹介するだけでも価値を出せそう

上記のネタそのものは私がストレージ技術者であることや元Linuxカーネル開発者であるといったバックグラウンドに依存しています。したがって、みなさんの発信ネタになるものはみなさんのバックグラウンドにもとづく全然別のものになるでしょう。

ここで一番大事なのは、「世の中にどういう情報があるのか、ないのか」「こういう情報を出せば誰かが喜ぶのではないか」「自分はその情報を持っているだろうか」「持っていないが、ちょっと頑張れば得られるだろうか」などなどを日々もやっと考えておくことです。ずっと考えていると多分病んでくるので、うっすら、もやっと、でOKです。

こういうものは浮かぶときは浮かびますし、浮かばないときはまったく浮かびません。あるときいろいろなものがリンクして、「これは外に出せる!」となります。多分。なんにせよ、普段何も考えていないのに、「発表したい!するぞ!ネタひらめいた!」とは、なかなかなりません。

発信する内容を具体的に決める

さて話すネタは決めたとして、いよいよ中身を作っていきます。私の場合はネタを決めた後に、話す内容として次のようなものがが浮かびました

    1. device mapperでディスクI/O障害をエミュレーションをする方法の説明
    1. カーネルモジュールを書いてディスクI/O障害をエミュレーションする新機能を追加
    1. aをらくらく使うためのツールを作って紹介する

この中で実際に話したのはaとbの一部(新機能を追加する方法を紹介した)だけです。何かをやるぞとなったら欲が出てきて風呂敷を広げてしまいがちなのですが、今自分ができること+α程度に留めるのがよいでしょう。とくに発信にかけられる時間が少なかったり、発表までの期間が短ければなおさらです。

私の場合は発表の2週間くらい前まで何もしていなかったのと、その頃多忙で大して時間がとれなかったので、a-cをそれぞれ以下の理由で話す/話さないことにしました。

    1. 既に全部知っていることであるしタイトル通りのことなので全て話すことにした
    1. どういう風に書けばいいのかは知っているが実用的なものは書いたことがなかったし、話していると時間が足りなくなりそうだったので方法の紹介くらいに留めることにした
  • c.. 発表用スライドを書いていくうちに、これを書くと時間内におさまりそうにないことがわかった。また、今後メンテされない自作ツールを紹介しても見る人は困るだろうなと気づいた。このため、話さないことにした

大ネタは魅力的ですが、それを達成するために心身の健康を損ねたり仕事や私生活に支障を来してもしょうがないので、やれる範囲でやるとよいかと思います。

また、外部発信経験の無いかたは、最初はなるべく小さなものにすると良いでしょう。慣れていないことをしようとするときに最初からデカいことをすると勘所がわからないこともあって、うまくやるのが大変です。たとえば勉強会での発表であれば、5分くらいのLTからはじめて、だんだん時間の長いものにチャレンジすればいいかと思います。とにかく一回やり切る経験を積むのが大事かなと思います。

おわりに

ここで書いたことをきっかけに、だれかが一歩踏み出して外部発信ができることを願います。また、それをきっかけに何かの別の道が開けたりすることがあるとよいですね。情報や機会は誰かの目に留まった人のところに入ってきがちなのです。

*1:わたしはこのイベントの常連です

自分がやってる副業やそれぞれの比較: 儲け話ではなく儲からない話

私は会社員なのですが、いろいろ副業してます(副業OKの会社)。それぞれについて当たり障りのない範囲で現状を書いた上で、受け取れる額(具体的な金額は一部除き出てきません)や効率のよさなどを比較します。あくまで一般的なものではなく、わたし個人の話なのでご注意ください。

現在の定期収入は以下の通りです。

上から順番に、それぞれどういうものか書きます。

物書きはIT技術、とくにLinuxカーネルやそれに近いレイヤについての書籍や記事の執筆です。それらの原稿料やら印税として対価を得ています。がまあまあ売れているらしいこともあって金額としてはけっこう大きいですが、かなり手間やストレスがかかります。いったん書いてしまうと、あとは何もしないのに定期的にお金が振り込まれるのでうれしいです。ただIT技術書の市場規模が大きくないこともあって、「けっこうな額をもらえるが会社員として働いていたほうが儲かる」というくらいです。商業出版だけではなく技術同人誌も販売しています((ここここ)で売ってます)。こちらは一冊当たりの単価は商業出版に比べて安い、部数は少ない、ページ数も少ない、しかし一冊の売り上げに対する取り分(パーセンテージ)は多い…などいろいろな要素が絡み合った結果、「商業出版よりも作業量は少ないが全体的な利益も小さい」くらいです。

YouTubeの動画配信は、広告収入とメンバーシップによる収入があります。扱う分野は書籍と同じです。現在チャンネル登録者数は8700人強で、公開した動画は平均10分程度のものが70~80本です。けっこう莫大な工数を突っ込んでいるのですが、収入は雀の涙です。これも書籍と同様パイが小さいという話もあります。また、ほとんど思いつきでスライド作って一発撮りなことや機材がしょぼくて音質の悪さを指摘されているなどいろいろあるので、そこは改善していきたいところです。ただもともとパイが小さいという問題はいかんともしがたいし、ものすごく頑張るほどの気力もないので、趣味で動画を公開したらお小銭がもらえるくらいの感覚でやるしかないかなと思っています。真面目に利益を得る方法としてはUdemyで気合を入れた有料動画を公開するのがいいのかなとか最近色々と調べています。

Amazonアソシエイトプログラムについては、読んだ本についての短い読書感想文をソーシャルメディアにアフィリンク付きで流して、それ経由でアガりの一部をもらっています。これは趣味の読書のついでにやってるのでコストはほとんどかからないといってよいでしょう。Xのフォロワーがそこそこ多い(2万人ちょっと)こともあってか、いわゆる「お小遣い程度」の金額にはなります。ただこれで儲けるために本を読んでいるわけでもないし、これからそうするつもりもないので、今の金額から大幅アップというのは難しいでしょう。Xのフォロワーが100倍くらいになれば話は違うかもしれませんが、別に有名人になりたいわけではないので、そうはならないでしょう。

Xの収益分配金は、これだけは金額が軽く言える程度の額だし公開してはいけないとも言われていないので書くと、月に2000円ほどです。好きなことを適当につぶやいているだけなのでコストはかかりません。収益分配金はstripe経由で海外送金されるのですが、ほとんどの銀行は額にかかわらず数千円の振込手数料をとるので、ちょっと前までは「受け取ると赤字だから無視する」というような状態でした。今は海外送金手数料無料の銀行口座を開いたので状況はマシになっていますが、まあ、やっぱり無いよりマシ程度です。この手段でたくさんお金を得るというのはなかなか大変でしょう。

GitHub,Sponsorsは副業と言っていいのかはわかりませんがオープンソース関連の記事などを書くやる気を出すためのものということでスポンサー収入を得ています。少額ですが、とてもうれしいです。

最後に上記すべての手段を「金額」と「大変さ」という2つの尺度で比較しておきます。

スケーラビリティ大事ですね。

終わり。

Xの広告収益分配金をしばらく受け取ったあとの感想

Xには広告収益分配金を得られるという機能があります。X Premium(旧twitter blue)に登録して、かつ、機能を使う申請すれば、インプレッションの数とか色々なものを加味して毎月いくらかのお金をXから貰えるようになります。

本記事は、わたしがこの機能を使い始めてから3ヶ月くらい経った今の現状と、それに伴って得た色々な知見を共有するものです。「あなたもインプレッションを稼いでお小遣い稼ぎ!」とかいうキラキラした話ではないです。

10/31 更新。海外送金されてくる金額を手数料が上回った場合にどうなるかわかったので追記。

3行まとめ

  • かなりフォロワー数やインプレッションがないと全く儲からなさそう
  • 受取金額がしょぼいと海外送金手数料でほとんど消える
  • 手数料を安くしたいならWiseなどの仮想銀行口座は現在使えないので、日本の銀行口座を開設するのがよさそう

自分の直近3回の分配金

わたしのXはジャンルとしてはIT系で、フォロワー数が二万人くらい、直近一ヶ月のインプレッション200万くらいです。別に世間の耳目を集めようとはしてなくて好きなことをブツブツ言ってるだけです。それくらいのひとの直近3回の分配金は次のとおりでした。

なかなか厳しいものがありますね。万単位ならちょっとうれしいけど数千円ということです。しかも右肩下がり。

海外送金手数料

上記の金額がそのまま貰えるかと言うとそうではありません。Xからの収益分配金の受け取りにはStripeというサービスを使うのですが、そのStripeから日本円の銀行に振り込む際に海外送金手数料がかかります。わたしが使っている銀行の手数料は2500円です。初回は手数料を引いた上で2400円ほど、二回目は41円を受け取りました3回目は分配金額が2500円を下回っているので、この場合どうなるか、楽しみにしています。

(10/31追記) …とか言っていたら銀行から次の送金を受け取るかどうかの確認連絡が来て、受取をすると手数料から振込金額を引いた差額を徴収されそうなことがわかりました。これは流石に嫌なので、一旦この送金はキャンセルして、のちほど、後述する海外送金手数料が無料の銀行を振込先に設定することにしました。

手数料を安くするためにWiseを使おうとした

X上で手数料が高いし新しい銀行口座作るのめんどくさいと言ってたらWiseというサービスを教えてもらって、「これは使えないだろうか」という提案をされました。これは次のようなサービスです。

  • いろいろな通貨のお金をチャージできる
  • チャージしたお金はデビッドカードを介して店で使える
  • チャージしたお金を別通貨に両替できる。手数料が安い
  • 海外送金もできる。こちらも手数料が安い
  • 通貨によっては仮想銀行口座を持てる
  • サービスの利用が全てオンラインで完結する

Wiseを使えば楽に、かつ、手数料少なく収益分配金を受け取れないかと模索しましたが、駄目でした。まず日本在住者はStripeからのお金を円でしか受け取れません。また、よく見ると「wiseなどの仮想銀行口座は使えません」ということも書いていました。

https://stripe.com/docs/payouts?locale=ja-JP#supported-bank-account-types

日本では、お客様の名義ではない仮想銀行口座 (Wise や Payoneer) はご利用になれません。

ついでにいうとwiseはまだ日本の仮想銀行口座は提供していないこともわかりました。二重にだめですね。

そんなこんなで日本で手数料安く収益分配金を受けたければ海外送金手数料無料な日本の銀行口座を使うしかないのではと思っています(例えばソニー銀行)。ただ口座作成はわりと面倒くさいので、月々数千円もらうためにそのまで頑張るのはバカバカしいという思いもあります。

手数料が無視できる程度に最低振込金額を設定したい

サポートページを見ると、最初の振り込みは$50貯まるまで保留されると書いています。

https://help.twitter.com/ja/using-x/subscriptions-creator

あなたのコンテンツに起因する収益として最低支払額の50ドルを満たす金額が初めて記録されるまで、収益の支払いは発生しません。50ドルに満たない場合は、未支払額が50ドル以上になるまで翌月に繰り越されます。

しかし私の場合は初回の$38を含め、毎回stripeに振り込まれてきました。ここはなぜかよくわかりません。

Xのサポートに「わたしの収益分配金程度ではほとんど手数料に消えるので最低保証金額をユーザー設定によって上げられるようにしてほしい」と依頼したところ、インプレッションを稼いで分配金額を上げる方法のヒントを教えてくれて話が打ち切りになりました。悲しい。

この機能への思い

Xでブツブツ言ってたらそれなりにお金が入るとかいううまい話はわたしくらいであれば無いんだなとわかりました。一般的知名度抜群のインフルエンサーの人がいくら受け取ったかというpostをいくつか見たのですが、彼らでも受取金額は月々たかだか数万円、数十万円のようでした。おそらくこの金額は彼らにとってはとるに足らない額なのではないかと推測しています。

それに加えてこの機能を提供しだしてからバズったpostにどうでもいい返信をぶら下げたり刺激的なコンテンツを投下したりする人やbotが増えたというような話を合わせると、「これ、誰も対して得してないような…」という思いを持ちました。

おわりに

色々やってみて一番の収穫は、Wiseの存在を知れたことや、その他海外送金に関する色々な知見が得られたことでした。

低レイヤ技術を間接的に仕事で生かしてきた経験の共有。元Linuxカーネル開発技術者の場合

はじめに

ITの世界で「低レイヤ技術」と呼ばれるものがあります。明確に定義されているわけではありませんが、アプリケーションのような直接エンドユーザに触れる部分ではなく、しかもなるべく生のコンピュータに近い部分、たとえばOSカーネルコンパイラ、CPUを開発する技術などがあります。これらの技術に明るい人はそうそういないのですが、「やってみたい」という根強い人気があります。

学生のかたでもセキュリティキャンプなどで実際にある程度身につけてしまうような人もいます。そしてますますこの手の技術に趣味としてのめり込んでいって楽しくなる…というところまではいいのですが、「ではこの技術を会得した先に何があるのか」と不安になる人も多いようです。とくに学生さんの場合は「低レイヤ技術を使って今後なんらかの仕事をして生きていけるのか?」といったことが気になるようです。今日もそのような話を少し耳にしたので、自分の経験を共有する記事を書くことにしました。

わたしはかつて低レイヤ技術のうち、OSカーネル、もっと具体的にいうとLinuxカーネルの開発に15年ほど従事してきました。Webサービスを提供する会社のインフラ技術者として働いています。Linuxカーネル開発をしていたころの話は以下の記事ですでに書いたので*1、本記事では「低レイヤ技術(Linuxカーネル開発技術)を他の仕事でどうやって生かしてきたか」ということを書きます。

satoru-takeuchi.hatenablog.com

対象読者はこの手の技術を身に着けたいと思っている、すでにある程度身に着けている人です。社会人のかたでも役立つとは思いますが、とくに学生さん向けに書いています。

前提

昔の仕事で得たスキルセットをもう少し具体化すると次のようになります。

  1. Linuxカーネルの全体構造の概要がわかる。 一部サブシステムについてはソースコードレベルで理解して、必要に応じて変更もできる: 主にはプロセススケジューラ、CPU online/offline、ブロック層、一部ファイルシステムなど
  2. 上記サブシステムへの変更をupstreamのLinuxカーネルにマージするためのLinuxカーネルコミュニティでの活動ができる。上記サブシステムについてのGitHub issue対応のようなことができる*2

今の仕事をインフラ技術者と表現しましたが、インフラ技術者といっても幅が広いので、こちらももう少し詳しく書いておきます。わたしは自社Webサービスを動かす基盤となるべく開発中のオンプレK8sクラスタのストレージシステムの開発に従事しています。以前もLinuxカーネルのブロック層やファイルシステムなどの開発にかかわってきたので、少しレイヤが上がりましたが依然としてストレージという分野で仕事をしているといえます。

bについては上述の記事で触れているので割愛して、このような仕事にaのスキルがどのように役立っているのかを具体例を紹介しながら書きます。

具体例

コンピュータシステムを開発、運用していると、「アプリやミドルウェアの世界では説明がつかない挙動をしている」「システムコールの発行先で何かが起きているがよくわからない」ということはザラです。そういうときに迷宮入りさせずに根本原因を追究して対策を打てるのは大きなアドバンテージとなります*3Linux上で動くソフトウェアは結局のところLinuxカーネルの上で動くので、アプリケーションの開発者になろうとミドルウェアの開発者になろうと、前述のような「なんだかよくわからない挙動をしているときに「これはカーネルやハードウェアのレイヤの話かもしれない」「カーネルがこういう挙動をしているのであれば説明がつく」「こうやれば直せる/回避できる」といえる機会はいくらでもあるのです。以下に、世の中に公開されている2つの例を上げます。

1つめは「インフラシステムを開発していたらあるプロセスが特定の設定をすると起動しなくなった。原因はカーネルのビルド設定」という話でした。

blog.cybozu.io

この件はそれほど難しい話ではないので、専門外でも熟練の技術者であれば専門外のことでも時間をかければ、いずれは解決していたでしょう。しかし既にやったことがあって慣れていると、何をすればいいかという型を知っているので作業が早いのです。上述の通りわたしはLinuxカーネルのスケジューラはソースコードレベルで把握しているので、上記のことは事象が発生してすぐにだいたい原因のあたりがつけられて、ソースのどこを見ればその仮説があっているかどうかわかるという状態だったので1~2時間ほど解決しました。

この例はとくに緊急というわけではなかったのですが、一刻を争うというような場合にこういうことがプラスアルファとしてできる技術者がいるというのは組織にとってプラスでしょう。「プラスアルファ」と書いたのは、「Linuxカーネルにだけは詳しいけど与えられた職務で主に使う技術が全然ダメなら辛い」ということです。

2つめは「分散ストレージシステムから切り出したブロックボリュームのI/Oが止まることがあった。原因はボリューム上のファイルシステムがXFSだったらカーネルがハングすることがあった」という話でした。

blog.cybozu.io

この話は社内で発生したわけではなくRookというOSSのslackを眺めていたら偶然見つけたものでした。深刻な問題だったもののRookコミュニティでは原因がわからずお手上げ状態でしたが、Linuxカーネルに明るければログを見ただけで「おそらく原因はカーネルであろう」とわかるので、Linuxカーネルコミュニティにはたらきかけて原因究明までこぎつけられました。本件にかかわっていなければ将来的に自社サービス運用中にこのバグを踏んで悲惨なことになっていたかもしれません。こちらもLinuxカーネル開発技術者時代の経験が大きく生きたと言えるでしょう。今後も本件とは別ながら似たようなことが起きた場合もおそらく役に立てるでしょう。

おわりに

わたしは低レイヤ技術の中でLinuxカーネル開発しかやったことがないので他の技術を使って働くにはどうすればというのは正直言ってわかりません。しかしながら「その技術がまわりまわってどのように世の中につながっているのか。事業会社であるならば、どのようにお金になっているのか」「その技術の隣には別のどんな技術があるのか」「募集が多い技術と自分の好きな技術がどうつながっているのか」などと普段から考えておくとよいとは言えるかと思います。

本記事で書いたような低レイヤ技術を「間接的に」生かすというときは、自分が持っている低レイヤ技術はあくまでプラスアルファであり、雇用主に求められている主たる技術の習得を第一とするという認識を持っておくのもよいでしょう。低レイヤ技術はレアなので持っているとチヤホヤされがちなのですが、「俺は低レイヤの人だから」などという考えでいると、たまには役に立つけど普段はいなくていい使いどころに困る人になってしまいます。

なんやかんやと書きましたが、一番いいのは経験者に聞くことです。もし他の技術について「この技術で食っていくにはどうすればいいんだ」と気になっているかたがいれば、それぞれ実践している人を見つけて聞いてみてください。また、もし実践しているかたがこの記事を見た場合は、この記事のようなものを書いてくださると誰かに役立つかもしれません。し、わたしもそういう記事を見たいです。実は「あの人とかあの人とか書いてくれないかな~」という思いもあります。というわけで他の人に話をぶん投げて終わりにします。

*1:今の仕事の話も少し出ていますが

*2:LinuxカーネルGitHubで開発していませんので、あくまで「のようなこと」です

*3:もちろんそういうときに、あえて根本原因を深掘りしないという手段もあります