企業にとってのプログラミング言語の位置づけ

プログラミング言語の良し悪しについては昔から活発に議論されてきました。このような議論の中で企業がどのようなプログラミング言語を採用するかについて釈然としない思いをしたかたも多々いらっしゃるかと思います。典型的には「なぜ自分の会社では俺の好きな言語を採用しないのか」です。この「なぜ」の一部に回答する、かつ、そこに共感しないまでも理解してもらうのが本記事の目的です。

この手の会話は炎上しがちであり、かつ、私はそのようなことはしたくないので個々の言語の名前は挙げません。そのためやや抽象的な表現が多くなりがちですがご容赦ください。また、筆者はここで書く価値観が絶対というつもりはなく、読者のみなさま個人のプロジェクトは自分の欲望の赴くままに好きなものを使えばいいと思っています。

企業は継続的にプログラムの開発やメンテナンスをする必要があります。これを念頭に置くと、使いこなせる人が多い言語であれば複数人で開発する場合に有利です。後から人員を追加するときには学習コストが低いものが採用しやすいです。このような言語でないと開発組織をスケールさせるのが難しくなります。どれだけ設計が優れた言語であってもそれを使いこなせる人がいなければ、とくに大きな企業では、大規模な採用は辛いでしょう。

その一方で、いくらユーザが多くても年長者にしか使い手がおらず、若手は嫌うような言語は長期的には採用しづらくなっていきます。理由は将来的に技術者の確保が難しくなっていくからです。ある時期にいきなりプログラミング言語の流行りが変わっていく理由の一つがこのような世代交代です。いつだって主流派は強いのです。

何かを開発するときには標準ライブラリだけあればいいというのは稀なので、企業の目的を楽に達成できるライブラリが豊富にあるかどうかも重要です。企業にとっては利益を得るのが重要なので、貴重な人的リソースを使って毎度毎度「なければ作る」で挑むよりも、ありものを使ってやりたいことに集中したいことのほうが多いでしょう。

何か起きたときのデバッグトラブルシューティングが容易なツールが揃っているかどうかも重要です。作ったもののメンテできない、しづらいものは企業は使いにくいです。この意味では昔から業務用に使われ続けてきた言語は多種多様なツール、およびノウハウがあるので有利となります。明らかに昔のものより設計が優れている言語が一向に普及しなくて不満を募らせるというのはよくあるのですが、その大きな理由として絶対的なユーザ数の不足に加えてこの手のツール/ノウハウの不足があります。

ではみなさんが使いたい言語を仕事でも使いたいならどうすればいいかというと、一つは特定言語で開発していることが募集要項において明らかな企業やプロジェクトに入ることです。中には特定言語を使っていること、あるいはその言語のエキスパートが揃っていることを前面に押し出している会社もあります。興味があれば調べてみるとよいでしょう。

あるいは茨の道ですが、いま居る組織の中で自分の好きな言語を使うほうがいいと説得するという方法もあります。ただし、この場合はあなた以外がその言語を使えないということであれば、あなたが作ったプログラムはあなたがメンテし続けることになるでしょう。メンテは開発よりも大変なので、あとになればなるほどやることを変えられないという事実が重くのしかかってきます。「それは嫌だから辞める」というのはもちろんアリなのですが、企業にとってはそれをやられるのは嫌なので、やっぱりユーザが少ない言語の採用には及び腰になります。

読者のみなさまが本記事を読んで個人プログラマの顔と職業プログラマの顔を使い分けて折り合いをつけられるようになること、あるいは馬力で現状を打破できるようになることを願います。

「みんなのGo言語 第二版」補足。Go v1.16の新機能紹介など

- 2021/6/20: ioutilについての記述を追加

[みんなのGo言語 第二版」という本を読んでいます。とてもいい本です。

この本が書かれた当時、2019年のGoの最新バージョンは本書の内容と発売時期から考えるとv1.12でした。それから二年の歳月が過ぎたいま、Goの最新バージョンはv1.16になっています。それにともなって本書のコンテンツのうちのいくつかは現在では違う方法が主流になっていたり、推奨されていたりします。本記事ではそれらについて紹介します。

最初に断っておきますが本書の内容が古いと文句をいいたいわけではなく、この書籍に最新のGoの状況を補足しておくと誰かの役に立つかもしれないと思っただけです。

P15: GO111MODULE環境変数

go v1.16からGO111MODULE環境変数の値はデフォルトでonになっています。Go v1.16のリリースノートからの引用です。

Module-aware mode is enabled by default, regardless of whether a go.mod file is present in the current working directory or a parent directory. More precisely, the GO111MODULE environment variable now defaults to on.

P15: vendoring

Go v1.13からgoのモジュールはデフォルトでGo module mirrorというところからダウンロードするようになったため、ダウンロードの所要時間はgithubなどのサイトからダウンロードするより高速になりました。これによってvendoringの嬉しさの一つは薄れてきています。

以下リリースノートへのリンクと該当する記述の引用です。

golang.org

As of Go 1.13, the go command by default downloads and authenticates modules using the Go module mirror and Go checksum database run by Google. See https://proxy.golang.org/privacy for privacy information about these services and the go command documentation for configuration details including how to disable the use of these servers or use different ones. If you depend on non-public modules, see the documentation for configuring your environment.

go module mirrorをはじめとするGo module proxyとvendoringの比較については以下ドキュメントをごらんください。

arslan.io

P16: 依存の追加

モジュールを有効にした場合(つまりデフォルト)のパッケージのビルド/インストール、および依存関係の更新において推奨されるコマンドが変更になりました。

  • パッケージのインストール: go install
  • 依存関係の更新: go get -d

-d引数なしのgo get、つまりパッケージをビルド/インストールする目的でのgo getの使用は非推奨となりました。以下Go v1.16のリリースノートからの引用です。

go install now accepts arguments with version suffixes (for example, go install example.com/cmd@v1.0.0). This causes go install to build and install packages in module-aware mode, ignoring the go.mod file in the current directory or any parent directory, if there is one. This is useful for installing executables without affecting the dependencies of the main module.

go install, with or without a version suffix (as described above), is now the recommended way to build and install packages in module mode. go get should be used with the -d flag to adjust the current module's dependencies without building packages, and use of go get to build and install packages is deprecated. In a future release, the -d flag will always be enabled.

P41 statikを使う

バイナリにファイルコンテンツを埋め込む方法としてstatikが定番でしたが、Go v1.16からはembedというパッケージを使えば同じことができるようになりました。

以下Go v1.16のリリースノートからの引用です。

The new embed package provides access to files embedded in the program during compilation using the new //go:embed directive.

embedは以下のように使います。

$ echo "hello embed!" >hello.txt
$ cat hello.txt 
hello embed
$ cat emb.go
package main

import (
    _ "embed"
    "fmt"
)

//go:embed hello.txt
var s string

func main() {
    fmt.Print(s)
}
$ go build emb.go
$ ./emb
hello embed!
$ 

詳しい使い方はライブラリのドキュメントをごらんください。

golang.org

P63: ioutilパッケージ

リスト18において使われているioutilパッケージの使用はGo v1.16から非推奨になりました。以下リリースノートからの抜粋です。

The io/ioutil package has turned out to be a poorly defined and hard to understand collection of things. All functionality provided by the package has been moved to other packages. The io/ioutil package remains and will continue to work as before, but we encourage new code to use the new definitions in the io and os packages. Here is a list of the new locations of the names exported by io/ioutil:

Discard => io.Discard
NopCloser => io.NopCloser
ReadAll => io.ReadAll
ReadDir => os.ReadDir (note: returns a slice of os.DirEntry rather than a slice of fs.FileInfo)
ReadFile => os.ReadFile
TempDir => os.MkdirTemp
TempFile => os.CreateTemp
WriteFile => os.WriteFile

おわりに

本記事の補足内容は私が本書の中のちゃんと読んだところについて自分の知ってる最新状況について補足しただけであって、すべて最新版のbest practiceに置き換えたようなものではないです。

最後になりますが「みんなのGo言語」の筆者のかたがたに、良書を書いてくださってありがとうございましたと感謝申し上げます。

仕事と趣味と効率と優先度

仕事では最小の労力で最大の成果を上げるために個々のタスクの効率を上げることが重要です。それに加えて仕事全体を見てみると、数あるタスクの中で優先度の高いもの、たとえば何かのブロッカーになっているものを先にやる、というのも重要です。優先度をうまくつけられて高い効率で仕事をバリバリこなせると快感でもあります。

ところが一旦仕事を離れて趣味になると、あまり高い効率や優先度付けを付けを追求するとよくないのかなとここ数年思い始めました。趣味を「仕事を離れてリラックスするもの」と考えるならば、ゆったりと無計画に、その時々にやりたいことを欲望のままにやるほうがいいのかなと今は考えています。別に効率が低くても誰も困らないですからね。義務で趣味やってもしょうがないです。

この話はわたしのような欲望駆動で感情のままに行動するけど自分に責任があるところでは無理矢理自分を矯正している人にはぴったりくるかも。もともと計画的に行動するのが好きな人には全然当てはまらないかも。

年とってくると注意してくれる人がいなくなる

あらゆる組織の若手は最初は先輩社員の指導を受けて育っていきます。ところが年を経るにつれて注意されなくなってきます。わたしも社会人になってから今まで、注意される回数がどんどん減っていきました。もちろん私が成長して注意すべき点が減ってきたというのもありますが、それだけでは説明がつきません。あとから振り返ってみると「これは相当まずいことをしたな、昔なら相当叱られてただろうな」ということが多々あります。では自分の成長以外にどういう要素があるかというと、それなりに大きなウェイトを占めるのが加齢だと思っています。

「技術の前には年齢は関係ない!」という話もあり、実際それはそうだと私も思いますが、年長者は敬うべきという文化がずっと続いてきた日本で実際に年長者に正面からボロカスに注意する人というのはなかなかいません。それに加えて「この年になるまで変わらなかったんだからもう注意しても無駄だろう」「年食ってきたら人間はもう変われない」という意識も働くと思います。本人のいないところで「あいつ使えない」と言われることはあるでしょうが、それは本人には届きません。

実際自分が40歳に達した今、注意してくれる人がいないのは自分にとっての大きな問題のひとつで、定期的に過去の自分を振り返って内省をしています。そうしないと改善のきっかけがないのです。そうしないとプライドが高くて成長が止まった役に立たない人のできあがりです。

この取り組みがうまくいっているかはよくわからないのですが、しないよりは全然いいと思っています。年はとってきて、不可逆なかたちで衰えが出てきているところは多々あれど、今後もできるところは改善、進歩していきたいと思います。

1からコードを書き起こさないプログラマ

以下の記事が面白くて、かつ、自分も似たような観点でなんか書いてみようという気分になったので書きます。

blog.riywo.com

主な対象読者はプログラマの業務がどんなものかピンと来ていない人たちです。

わたしはソフトウェア開発者で、かつ、現在は10万行程度の規模のRookというOSSのメンテナとしての開発をしています。それより前は2700万行ほどあるLinuxカーネルのうち、10万行ほどの規模のサブシステムを扱っていました。

私がこれらを1から書き起こしたかというとそういうことはなくて、どちらも既にあるものの開発に途中から参加しました。書くコードも大規模な機能追加というよりはバグ修正、ドキュメント修正、既存機能に新しいモードを足すようなものが中心です。バグ報告のときの再現プログラムを書くことも多いです。

それ以外にも、わたしは趣味で大きなプログラムを書くことはあまりないです。これまでに一から書いたソフトウェアがいくつかありますが、それぞれ高々数千行、あるいは一万数千行程度の規模です。やりたいのにやっていないかというとそうでもなくて、自由に無から有を作り出すものより、既存のコードにいかに影響を与えずに必要最小限のコードで目的を達するか、というところに一番興味があります。

プログラマといえば自分で一からプログラムを書くというオリジナル作者というイメージがあるかたが多いと思いますが、こういうケースも多々あります。もちろんどちらか一方だけではなく、どちらもたくさんやるというケースもありますが、わたしはこういう具合です、という参考情報でした。

これまでの人脈の広がりかた

はじめに

先日書いた以下の記事の反響がけっこうあったので、その続きのようなものを。

satoru-takeuchi.hatenablog.com

わたしは今も昔も仕事としてOSS開発者をしていて、twitterなどでそれなりに名前が知られていることもあって、昔から「どうすればそういうこと(業務としてOSS開発)ができるのか」「どういうキャリアを歩んできたのか」「Linuxカーネル開発者になるにはどうすればいいのか」ということをよく聞かれてきました。当時わたしが置かれた環境と現在の環境では違いがありすぎるので公開に積極的にはなれなかったのですが、一つの過去事例として何らかの意味はあるかもと思って公開することにしました。

これと似たような話で、わたしはIT業界の知人友人がけっこうな数いて、かつ、かなりジャンルがバラエティに富んでいます。このため、「どうやったらそうなるのか」という質問をよくされます。本エントリはそれについて書きます。どんな時期に何をしたらどういう人と知り合いになってきたか、という観点で書きます。

IT企業のインターンシップに行くまで(~2003)

2003年のM1のときに上記の記事にも書いたように富士通インターンに参加しました。それまではIT業界の知り合いは皆無でした。学科が材料系だったこと、および他の学科の人との交流もなかったことより、知人友人にもプログラミングに興味のある人は皆無でした*1。当時は自分の一番好きなことを話せる人がおらず、かつ、自分の能力がどれほどのものかもわからず、悶々としていました。

インターンに行くとLinux大好きな人、カーネル大好きな人、プログラミング大好きな人、とたくさん知り合いました。IT企業といえど仕事としてやってるだけで好きではないという人ばかりの職場もあるそうなので、ここは恵まれていたのでしょう。

この時期まではIT業界の知り合いはインターンに参加したチーム、およびその周辺の人たちだけでした。

新卒入社以降数年のカーネル開発者人生の前半(2005~2009年)

就職すると社内の知り合いが徐々に増えてきました。自分のチームからはじまり同じ部署の別チームの人、別部署の人、などなど。ただSEさんと話すことは稀で、お客様を含めた社外のかたと知り合うことは皆無でした。ここまでは大企業の開発者としてはとくに珍しくないでしょう。

その一方で、ベンダと取引先やお客様という関係ではなく、同じOSS(Linuxカーネル)を開発する人たちとつながっていきました。接触の場は主にLinuxカーネルに関するイベントです。古くはOttawa Linux Symposium、OSDLのJapan Linux Symposiumなど。その後はLinuxCon Japan(現在も毎年開催されているOpen Source Summit Japanの前身)などなど。これらのイベントを通して大手ITベンダ(NFH,NTTDなどなど)のLinuxカーネル開発者たちとちょくちょく喋るようになりました。

この時期までは社外のIT業界の知り合いはほぼLinuxカーネル開発者のみでした。

社外イベントの講師(2010年)

たまたま社内でオペレーティングシステムの講義をやっていたこともあって、セキュリティ&プログラミングキャンプというイベント(セキュリティキャンプの前身)で学生にLinux Kernelを学んでもらうコースの講師として呼ばれました。講師は全員現役Linuxカーネル開発者という強烈なメンツで、社外のかたが5,6人いました。当時ほかのかたとは「お互いに顔は知ってる」程度でした。このイベントを通してずいぶん仲良くなりました。講師だけではなく、LinuxLinuxカーネル、プログラミングが大好きな情熱的な学生さんたちともたくさん出会えました。そのうち一部のかたは現役Linuxカーネル開発者になったりなどして今も縁が続いています。

セキュキャンで特筆すべきは、これまで全く縁がなかったセキュリティ技術者、OS自作lover達、プログラミング言語開発者のかたがたという別ジャンルのかたがたと知り合えたことです。あまりにも世界観が違うのでかなりの衝撃を受けたことを記憶しています。セキュリティキャンプは学生同士、学生と講師が繋がるハブとして過去も現在も機能していますが、教える側の講師も別ジャンルの講師/学生とつながって刺激を受けることも珍しくないのです。

現職のサイボウズの社員のかた*2との縁もここでできました。まさかそのときはサイボウズに入社するとは夢にも思っていませんでしたが…

他にもセキュキャンを機に、当時はさして興味がなかったtwitterをはじめました*3。のちにこれは私の人脈の広がりかたに大きく影響するようになりました。

カーネル開発者人生の後半(2010~2017年)

セキュキャンで知り合ったLinuxカーネル開発者たちを経由して、Linuxカーネル界隈の主だった日本人開発者たちはほとんど知り合いのような状況になりました。技術的な話からくだらない話まで、ずいぶんたくさんした気がします。このかたがたとは今でも関係が続いています。

Linuxカーネルに詳しくなっていくとともに、各種イベントにおいても聞く側だけではなくプレゼンする側になったりして、日本国外の開発者とも知り合いになってきました。主に自分が開発にかかわっているコンポーネントの開発者とよく話すようになりました。

無職時代(2017前半)

前職を辞めてから、とくにやることがなくてツイ廃になりました。2010年から2017年あたりまでは大してフォロワーもおらず、知名度もなく、淡々とネタツイをして過ごしていました。

この年に買った新しいPCについていたとあるCPUの不具合を見つけた*4こと、および、それを面白がってtwitterで調査の進捗報告したことにより応援や注目してくださるかたが増えて*5、いろんなジャンルの知り合いが増えていきました。狙ってやったわけではないですが、知名度もそこそこ上がりました。「いつもtwitter見えます」と声をかけてくれる人も増えました。

ツイ廃だけではなく個人事業主として技術書を書きました。これが結構売れて評判もよかったことから、こちらも知名度が上がり、かつ「本を見ました」というのをきっかけに知り合いも増えたと記憶しています。「この人といえばコレ」という持ちネタがあると相手も話のきっかけがあって、知り合いが増えやすいという印象があります。

このあたりでkernel/vmというカーネルとかVMとかが好きな人たちの集団とかかわるようになりました。ハッカーコミュニティというやつですね。ここではのちに幾つかのイベントの主催もするようになったりして、さらに知り合いが増えていきました*6

外注エンジニア時代(2017年後半~2018年前半)

この時期に過去の知り合いがいろいろ取り計らってくれたこともあり、Linuxカーネルに詳しい人としてサイボウズに技術顧問(外注技術者)として雇われることになりました。雇ってくれた人とは間接的にしかつながりはなかったのですが、既存の人脈が大きく生きました。余談ですが、twitterでの巻き込みリプライをきっかけになんやかやあって雇われたのでtwitter就職(このときはまだ外注エンジニアだけど)だったりします。

サイボウズ社員時代(2018年後半~)

この年、技術顧問から社員になりました。仕事はLinuxカーネルからすこしレイヤが上がってKubernetes技術者です。さんざ苦労してきましたが徐々に仕事が軌道に乗ってきました。さまざまなイベントに参加したり、登壇したりすることによってKubernetesの技術者とのかかわりが生まれました。この業界でも幸か不幸か「twitter見てますよ」と声をかけられることが多いです。見られるのはこっぱずかしいですが、話すきっかけになるのはいいことだと思っています。

今は会社の次期インフラで使う予定のRookというソフトウェアのメンテナをしていることもあり、海外在住のRookの他のメンテナや開発者たちとも親しくなりました。Rookの開発を通して「Rookの人」「Kubernetesのストレージの人」としても認知されるようになりました。

おわりに

現在の知人、友人の構成は次の通りです。

  • 前職の先輩、後輩。ほぼ全て同じ部署か1hop先の部署の人たち。十数人*7
  • Linuxカーネル開発者たち(”元”を含む。わたしも今はやってない)。十数人
  • セプキャン&セキュキャンをきっかけに出会った人たち。数十人
  • kernelvmの多彩な能力を持つ人たち。数十人
  • Kubernetes技術者たち。十数人
  • 上記の人たちから紹介された人たち。数十人
  • Rook開発者たち。数人
  • ついった知り合い。数十人。アカウント名しか知らない人多数。お互いIT技術者だが技術的な話を一切しない人もいる

振り返ってみると「人脈を増やしてやるぜ」と息まいたことはあんまりなくて自然と増えていったので、あまり気負わなかったのがよかったのかもしれません。鼻息荒くいくと独特の臭みが出るので避けたほうがいいかもしれません。

その他に読者のみなさまに言えることがあるとしたら、面白そうな人たちがいる場所に飛び込んでみる、発表の場があればやってみる、twitterなどのSNS、qiita、zenn、note、各種ブログなどのサービスから地道に情報発信してみて「この人といえばコレ」というものを作って、ウマが合うひとたちと自然につながっていけばいいのかなと思います。

ではこんなところで、おわり。

*1:正確にはみんな授業でFORTRAN77を学んでましたがとくに熱意をもって何かしていた人はおらず

*2:正確にはサイボウズラボでしたが

*3:アカウント自体はもうちょっと前から持っていた気がする

*4:すでに修正済です

*5:敵も増えて炎上もしました

*6:昔からずっとここにいるように思われていますが、かかわるようになってから高々4年しか経ってません

*7:辞めても前と変わらず付き合ってくれて嬉しい

仕事としてOSS開発者をやってきた話

はじめに

わたしは今も昔も仕事としてOSS開発者をしていて、twitterなどでそれなりに名前が知られていることもあって、昔から「どうすればそういうこと(業務としてOSS開発)ができるのか」「どういうキャリアを歩んできたのか」「Linuxカーネル開発者になるにはどうすればいいのか」ということをよく聞かれてきました。当時わたしが置かれた環境と現在の環境では違いがありすぎるので公開に積極的にはなれなかったのですが、一つの過去事例として何らかの意味はあるかもと思って公開することにしました。

書き方が難しかったのですが、うまくまとまらなかったので、自分が書くのが楽な日記みたいになりました。

きっかけ

2000年初頭に学部4年のころにLinuxを触りはじめてから「UNIXとかLinuxってすげえ」「こんなものが無償で使えるのか」「これらのソースコードが全部見られるのか」と感動して、「自分も成果物を公開していきたい!」「この道で食っていきたい!(やりかたしらんけど)」と思ったのがすべての始まりです。

その後「プログラムってどうやって動いているんだろう」というのを掘り下げて行ったらカーネルにたどり着いて、Linuxを使っていたのでLinuxカーネルに興味を持って色々調べていました。ここでも「この道で食っていきたい!(やりかた知らんけど)」になりました。

ありがちですが以下の本なんかも読みました。

インターン

B4の頃、私がその手のことをやっていると知っていた友人が「こういうのがあるらしいよ」と、とあるサーバベンダでLinux開発をやっている部署がインターンの募集をしているということを聞きました。当時はLinuxカーネルなんて本を適当に読んだだけでいじったことはあんまりなかったのですが、「まあなんとかなるやろ、落ちても別にダメージはないし、受かって何もできなくてもその時だけのこと。もしうまくいってここに入れればめっけもの」と思って応募しました。とくにわたしは情報工学情報科学専攻ではなかったので*1、こういう手段をつかわないとなかなかカーネル開発なんて難しいだろうなあという思いはあったので、「これだ!」と思った記憶があります。

エントリーシートの内容はあんまり覚えてないんですが、「実績はまったくないですがプログラミング経験はあります。意欲はあります!」のような勢いだけのものだったと思います。

幸いにもインターンには受かりました。当時は日本のサーバベンダが「これからはIAサーバ*2メインフレームUNIXの置き換えでやるぞ!」と怪気炎を上げていて、とにかく育ててでも人材が欲しかった頃なのでわたしのような怪しい人が入り込む隙間があったのかもしれません。

インターンでは実際にカーネルを触ってみたらなんとなく成果は出せたらしく、後日、無事その部署に配属になりました。インターンでやったことは詳しくは書けませんが、たとえばファームウェアが提供するハードウェアの情報が書かれたテーブルを書き換えてCPUを一個論理的に消すとかそういうことをしました。事前にいろいろ調べてはいたのでなんとかなりました。

ここで重要だったのは次のようなことだと思います。

  • 友人、知人に「俺はこういうことをしている/したい」と話しておくのは重要。ふとしたことからチャンスは降ってくる。前述の友人もとくにコンピュータやLinuxに詳しいわけではなかった
  • 幸いにもインターンで成果を出せるくらいの素養はあったが、応募しなければ何も始まらなかった。やって損はないことはやるといい
  • 「どうせ俺は〇〇だから(自分の場合は「情報系学科ではないから」)」とあきらめない。あきらめなければ必ずできるわけではないが、あきらめたら試合終了

OSS開発、Linuxカーネル開発の実績を積む

入社してからは優しく厳しい先輩方に囲まれてゴリゴリLinuxカーネルに新機能を追加していきました。ここではとくにドラマ性はなく、日々必死に仕事をして、小さな改善パッチから始めて大きな機能の取り込みに、といったステップアップをしていきました。このときにLinuxカーネルそのものの知識に加えて、issueの発行のしかた、自分のパッチの効果に説得力を持たせるために議論する方法などを学びました。土台を固めながらの成長に近道はないです。

なお、優しく厳しい先輩方はmemory cgroupsの(当時)メンテナとかLinuxRubyのデュアルコミッタとか、えげつないかたがたばかりだったので、学べるところがたくさんありました。今思えば、これほど豪華な環境で成長できることはなかなかないのではと思います。ほかにも表には出ないもののダンプの模様が見える超人のような人とか、いろんなすごい人達がいました。

今やってること、OSS開発経験が役立つこと

今は上記サーバベンダは辞めてグループウェアを作っている会社にいます。といってもWebアプリを作ってjsとかを触っているわけではなく、Go言語を使ってKubernetesやらRook/Cephを使ったオンプレインフラ基盤を作っています。

業務はupstreamのRookの開発がいまのところ中心で、メンテナもやってます。ただし最初からupstream Rookの開発をやるために入社したわけではないです。会社が求めていたスキルにマッチしているから入社して、自社インフラを作るにあたってRookにゴリゴリコミットできればいいねということになって、わたしができそうだからやりはじめただけです。

過去の知識についてはオンプレ基盤という性質上、Linuxカーネルの知識はとても役立っています。Rookの開発についてもLinuxカーネル開発で培ったOSS開発の型のようなものがずいぶんと役立っています。LinuxとRookはまったく性質が異なるコミュニティなのですが、型はできていたのですぐに適応できました。この型はなにもOSS開発だけではなく部署間、会社間の交渉にも役立つと思います。

今から業務としてOSS開発するにはどうすれば?

今から業務としてLinuxカーネル開発者になる方法については正直言ってよくわかりません。わたしは5年近く前にLinuxカーネル開発が仕事でなくなって、この界隈の事情に疎くなったからです。他のソフトウェアについてはもっとわかりません。

一般論になってしまいますが、できるところから自分のたずさわりたいOSSについてissue報告したりPR投げたりして実績を積んでおいて損はないと思います。それに加えてイベントなどに顔を出していると関係者の目に留まって…ということは珍しくはないです。実績がなくても界隈の技術者に声をかけるとなんらかのヒントをもらえるかもしれません。

あともう一つ言えるとしたら「企業はOSS開発をしたい人ではなく会社に貢献してくれる人を求めている」というのは重要です。仮にあなたがナントカというOSSのメンテナですと言っても、その企業でそのようなことが求められていなければ仕事としてはできません。そうではなく、そのナントカを使って仕事にしている会社、ナントカの開発によって利益が得られる会社を探す必要があるでしょう。

あやふやな言い方で申し訳ないですが、いい加減なことは言えないのでこのくらいで。

おわりに

なんか抽象的なことばかり書きましたが、わたしが言えるのはこんなところです。まとめると、ありきたりですが「情熱を持つ」「チャンスをつかむ」「実績を出す」「しっかり関係者にアピールする」といったところでしょうか。全部でなくてもかまわないので、できる範囲でやるとよいかと思います。

ついったでメンションとかDMとかしてくれれば追加でなにかお答えしたり、ここに追記したりできるかもしれません。その時々の負荷に応じてベストエフォートで…

*1:なぜかというと入試で落ちたからです

*2:当時はx86ではなくItanium