新型コロナ禍におけるリモートワークの知見共有

はじめに

本記事は以下スライドを文書にしたものです。

speakerdeck.com

本記事は新型コロナ禍による環境の変化にともなって業務に支障を来している社会人に向けて、いくつかの課題と、それについての対策案を書いたものです。想定読者はこれまでオフィスに通勤していたけれどもリモートワークになって困っている人、および、新卒入社でいきなりリモートワークになって困っている人たちです。zoomなどの音声/ビデオによるコミュニケーションツール、slackなどのチャットツールは使える状態であると仮定して書いています。

本記事は新型コロナ禍より前からフルリモートワークをしていて、かつ、本記事で書いた状況、問題のすべてに遭遇してきた筆者の経験をもとに書きました。

同僚とのコミュニケ―ション

新型コロナ禍より前から働いていたかたはコミュニケーションコストが高くなったと感じることが多いのではないでしょうか。たとえば、これまで口頭で済んでいたことをいちいちzoomやslack経由でしなければならなくなった、などです。コミュニケーションコストが高くなると自然とコミュニケーションをとるのが億劫になってきてチームが機能不全に陥ることも珍しくありません。

このようなときに明にコミュニケーションを取りやすくなる施策が有効ではないかと考えています。具体的には定期的に雑談的なミーティングをして個々人の思いを吸い上げておくことです。それだけではなく、zoomで誰でもいつでも入れる雑談部屋を用意して、疲れたらそこに入ってどうでもいい話をするなどです。作っても使われないプラットフォームは無意味なので、なんとなく人と話したくなったときに「雑談zoom部屋に行こう」と誘ったり、それを気軽にできる空気を作るのもよいでしょう。

新卒入社した人や転職した人はもっと大変でしょう。まず、誰がどういう役割なのか、どういう人となりなのかがリモートだと全然つかめません。このため、相談しようにも誰にすればいいのかわからず、かつ、既存の社員からしても困っているかどうかがわかりにくいです。

このような問題を避けるために、新しく入ってきた人とのアイスブレイクのための雑談の機会をなるべく早く設けるのが重要だと考えます。対面で話せていたようなときは入社した後に数日してから懇親会をする…というようなやりかたが一般的だったでしょうが、今は自然に発生する雑談は期待できません。また、このような雑談においては既存の社員同士で盛り上がるのは新しい人に疎外感を植え付けるので避けたほうが無難かと思います。

気持ちの切り替え

オフィス勤務ではないということは出勤という仕事とそれ以外を分けるスイッチの一つがなくなったということです。このため、気持ちの切り替えができずにずっと気持ちが張り詰めたままという例を少なからず耳にしました。また、仕事を終えたとしても家に仕事ができる環境が整ってしまっているので、ついつい会社のメールチェックをしてしまったり、というのも珍しくありません。

このようなときの対策として、仕事とそれ以外のときに使うものは完全に分けてしまうという手があります。たとえばPCや机などです。ただ家の広さは有限なので、これは簡単にはいきません。せめて仕事が終わった瞬間に会社用のPCは電源を抜く、外に出かける、仕事と関係ない趣味を作って没頭する、などのスイッチを作るとよいかと思います。わたしはやったことがないですが仕事前後で着替えをするなども効果がある人がいるようです。

身心の健康

新型コロナ禍はこのウィルスにおかされなくても心身の健康を害していきます。ここでは身体の健康と心の健康に分けて課題と対策案を書きます。

身体の健康

身体の健康に影響をおよぼすのはなによりも外出機会の喪失、および座りっぱなしの機会の増加による筋力低下、体重増加、体の凝りなどが大きいでしょう。この問題についてはたとえば寝具や椅子、机に可能であれば投資をするという方法があります。これらは高ければいいというものではないのですが、ある程度までの金額であればQoLを劇的に上げられるケースが珍しくありません。

お金がないわけではないけれども「もったいない」という理由で最安のものばかり使ってきたというかたは、一度家具屋などで安くないものを試してみて、これは自分に合うとおもったら買ってみるとよいと考えます*1。中古市場もあるので、抵抗がなければ使ってみるのもありかと思います。

他には運動やストレッチが有効です。定期的に長時間の運動が難しくても、気づいたときに一分くらいかけて軽いストレッチをするだけでもだいぶ違います。筆者は一息つくたびに首の凝りをほぐしていますが、やる前と比べてずいぶんと体調がよくなりました。休憩時間や思考時間にはあえて立ってうろうろしてみるというのも一つの手です。とにかく座りっぱなしというか同じ姿勢でずっといるのはよくないです。

心の健康

心の健康については新型コロナ禍以後に多かれ少なかれ問題が出たという人はかなり多いようです。症状の出かたは人によって全然違うのですが、眠れない、気持ちがふさぎ込む、イライラする、集中できない、などなどです。この手のメンタル疾患の兆候については厚労省のサイトなどを見ればいろいろ書いています。

解決策については、やばそうだと思ったら精神科ないし心療内科にかかるのが一番かなと思います。これらの科にかかるのに抵抗があるのは理解できますが、健康のほうが重要です。メンタル疾患をこじらせると二度と社会復帰できなくなることもあるので、少しでも危ないと感じれば行ってみるとよいかと思います。

友人知人に悩み相談をすることもあるかと思いますが、そのとき具体的な対策についてのものは避けたほうがいいかもしれません。彼らはあなたに親身になってくれるかもしれませんが専門家ではないので、見当違いのことをいって治療を遅らせることもあります。下手をするとオカルトにはまったりカルトに走ったりするリスクもあります。世界には正常に判断ができなくなっている弱い人を狙っている人が残念ながらそこかしこにいます。

おわりに

最後になりますが、本記事に書いた施策案は耳ざわりがよいものが多いですが、全員に当てはまるようなものではありません。たとえばそもそもコミュニケーションが苦手な人にとっては定期的な雑談などは苦痛でしかなく、フルリモートワークで誰とも話さないという現状が最高なもかもしれません。このため、あえて「対策"案"」という表記をしました。無理強いはせず、個々人に合わせて対策を打っていた抱くといいかと思います。

読者のみなさまやその関係者のみなさまがこの社会の劇的な変化を乗り切れること、および、本記事がその一助となれることを願います。

*1:なければ買わなくていいです。相性の要素は大きいので

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

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

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

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

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

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

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

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

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

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

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

- 2021/6/20: ioutilについての記述を追加
- 2021/7/11: 軽微な誤りについての記述を追加

[みんなの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

軽微な誤り

Goのバージョンには関係ないですが、本書の中に公式の正誤表に載っていない軽微な誤りが2点ありましたので書いておきます。出版社には連絡したので、いずれ正誤表に載るかもしれません。

P108 4つ目のcode snippet

xv := rv.Field(0)

rvはpへのポインタを指しているので、ここではElem()で実体にアクセスする必要があります。

xv := rv.Elem().Field(0)

P116 1つ目のcode snippet

if f := rv.Field(0); f.CanSet() {

一つ目の指摘と同じ理由により、以下のようにする必要があります。

if f := rv.Elem().Field(0); f.CanSet() {

おわりに

本記事の補足内容は私が本書の中のちゃんと読んだところについて自分の知ってる最新状況について補足しただけであって、すべて最新版の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:辞めても前と変わらず付き合ってくれて嬉しい