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

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

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

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

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

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

新しい環境で大失敗した話

以下記事の文字起こし+αです。他の記事で書いたことがあるようなものは省略しました。

speakerdeck.com

前置き

わたしは前職を退職してからしばらく無職だったのですが、一年くらい後に今の会社に拾われました。そのときは多分うまくやれるだろうと軽く考えていたのですが、実際にはしばらく何もかもがうまくいかなかったです。

正直言ってこれを公にするのはかなり恥ずかしかったのですが、だれかがわたしと似たような境遇、新しい環境へのチャレンジする状態になった場合に他山の石とできそうなので書くことにしました。

話の都合上リモートワークや時短勤務について言及しますが、これらの制度を否定するつもりはまったくないです。また、会社としてはずっと気にかけてサポートしてくれていましたので、非はすべて私にあると先に書いておきます。

今いる会社に入ったときは私的な制約や好みにより次のような条件で働くことにしました。

• 週20時間勤務(いわゆるフルタイムの半分)
• 働く時間も不定
• フルリモート勤務

では本題に入ります。

コミュニケーションの失敗

入社した当時は他の人とは全然違う、開発は当分先のストレージまわりの調査をしていました。そのときは「まずは他の人と一緒に仕事するわけでもないし」と自分から望んで定例会などには出ませんでした。私は知らない人と話すのがあまり得意ではないので、当時は何となくこうしたんだと思います。

このあと少ししてから非常に仕事がやりにくいことに気づきました。失敗に至るまでの流れは次のようなものでした。

1. フルリモート勤務なので雑談する機会が無い
2. メンバの人となり、誰がどんな役割なのかがわからない
3. 寂しいし、蚊帳の外にいるような気になる(自分でそう思ってるだけだが)
4. 何かあったときに誰に何を頼めばいいか、いちいち迷う。コミュニケーション効率が悪い

これについては、プロジェクトメンバやマネージャなどが見かねて助け舟を出してくれて、しばらくしてから定例会やモブプロにも入れてもらうことになりました。「こいつ使えない、クビ*1」でも不思議ではなかったのですが、見捨てず支えてくださったかたがたには感謝しかありません。

この後だんだんプロジェクトになじんできましたが、最終的にこの問題が解決したのは1年後くらいに海外のイベントにみんなで一緒に行って苦楽を共にしてからでした。それまでは全く意識していませんでしたが、私にとって同僚はある程度腹の内がわかる相手でないといけないということを思い知らされました。やってみないとわからないものです。

畑違いの分野へのキャッチアップの失敗

わたしは前職ではLinuxカーネルの開発、サポート業務をしていました。上述のように新しい環境では未経験だったKubernetesクラスタの構築という仕事をすることになりました。前職ではそれなりの実績があったため、「ちょっと上のレイヤに移動するだけだからすぐキャッチアップできるだろう」と高を括っていたら大間違いでした。実際には全然そんなことはなく、当時の私のスキルセットにはまったくない、非常に広い範囲の技術について知らなければいけませんでした。

この問題を解決するためには近道などなく、慣れるまで必死に食らいつくしかなかったです。最初に週20時間しか捻出できなかった頃は、何か一つ覚えているうちにKubernetesの世界や社内の開発は2つ先に進んでいくという具合で、ひたすら呆然としていました。事情が変わって仕事にかけられる時間が増えたことにより徐々にキャッチアップが進み、「これならなんとか」というレベルになるまでに結局2年くらいかかりました。

当時の技術力および時間の不足もそうですが、一番の問題は全く別分野の実績に胡坐をかいて舐めてかかっていたことだと思います。ある分野で実績があっても、他の分野では素人に過ぎないと思い知らされました。

まとめ

読者のみなさんがもし新しい環境に挑む場合は、あるいは今まさに挑戦しているという場合は、わたしと同じ轍を踏まないでほしいなと思います。そのためにこの文書がなんらかの役に立つことを願います。

*1:日本の法律上クビは難しいので実際は戦力外通告でしょうが

ヘタクソなコードを書いてもいい

プログラミング言語のお作法から外れたコードやメンテ性が悪いコードを書くのはダメとよくいわれます。わたしは学生の頃、そういう意見を過剰に気にしていました。コードを書くことそのものに慣れていないのに綺麗に書こうとして手が動かず、動かないがゆえにコーディングの練習が進まない、という悪循環になっていました。そうすると何もアウトプットしないまま知識だけが増えていって、自分がこれくらいできそうというイメージと実際のプログラミング能力とのギャップで苦しみました。

この意識が薄れたのは、あるときものすごく手が早い人のコードを偶然見たときでした。たしかにちゃんと動くものができているんですが、そのコードの中身は当時の私の基準からいって*1おぞましいほど汚いものでした。そこで「これはわたしが書けば100倍くらい綺麗なコードを書けるんでは…」と一瞬思ったんですが、その後すぐに「あ、自分は知識はあるけど練習してないから手が動かなくて全然書けないや」ということに気付きました。当たり前といえば当たり前のことなんですが、当時は衝撃を受けました。わたしは耳学問でいろいろ知っているのに何もできず、彼はお作法は知らないけど馬力で動くものをちゃんと作っていました。その差は明白です。

このことがあってからはコーディング時に綺麗さをさほど重視しなくなりました。ヘタクソなコードをたくさん書いて、ヘタクソであるがゆえに痛い目を見ることによって、お作法の意味やメンテ性を上げることの重要性が腑に落ちました。

「若いころはそうだったなあ」というような書き方になりましたが、今でも新しい言語を学ぶようなときは最初はその言語の使い手から見るとヘタクソで目も当てられないようなコードを書きます。なぜならその言語については初心者だからです。でも練習中なので気にしません。

当時のわたしと似たような悩みをかかえているかたは、まずはぐちゃぐちゃでもいいから、欲望のままに、とにかく動くものを書いてみるのがいいんじゃないでしょうか。おぞましいコードでもいいんです。そうしたらけっこう道はひらけるかもしれません。

さて、趣味なら徹頭徹尾汚いコードでいいんですが、仕事ではそういうわけにもいきません。では仕事ではヘタクソなコードを一切書いてはいけないかというと、そうではないと私は思います。私はある程度キャリアを積んだ今でも最初から綺麗なコードを書くことにはこだわっていません。まずはダサくてもとにかく目的を達成する動くものを書いて、その後に世に出せるものに修正してPRを出すというやりかたをしています。作文するときに最初はドラフトを書いて、その後に推敲して清書するのと似たようなものかと思います。

まあこんなかんじで、下手なコードを書くのを怖がっているかたが、それを恐れずに、堂々とできるようになればいいかなと思います。おわり。

*1:今の基準でもですが

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

はじめに

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

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言語」の筆者のかたがたに、良書を書いてくださってありがとうございましたと感謝申し上げます。

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

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

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

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