ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい 2
↓の続きです。
satoru-takeuchi.hatenablog.com
何をするにも知名度の有無によって注目度は変わります。極端な話をすると、誰かがものすごいことを成し遂げたとしても、誰とも接点が無い人がやれば誰にも知られず、すでに名のある人がやれば注目されます。なので知名度があればそれだけでいいか…というとそうではないです。
知名度の高まりかたにはいろいろと種類があります。そのうち一つは名声を博することです。名声を博するには技術者としてのスキルや地道な実績の積み重ね、場合によっては自己プロデュース能力が必要です。とてつもなく凄いが目立つのを嫌う人もいるので一概に知名度があればいいというものではないですが、その話はここでは置いておきます。
その一方で、人から眉をひそめられるようなことをすると悪名がとどろきます。これには別に技術者としてのスキルは必要ないので名声を博するよりも簡単です。たとえば煽りタイトル/釣りタイトルの記事を書いたり、その手のプレゼンをしたり、何か*1を貶めたり…という方法が定番です。
こういうことをしながら利益を上げていく特殊能力を持つ人たちがいることは否定しませんが、本当にその人たちのようになりたいのか考えてみてほしいです。少なくとも技術者として生きていきたいのであれば、こんなことをしてもいい方向に転がることはほぼ無いといっていいです。たとえば自分が企業の人事だったとしてこういう人を雇いたいか、イベント主催者だとしてこういう人を登壇させたいかを想像してみてください。
「まずはとにかく知名度を上げて、それからイメージを変えていく」というような作戦の人もいるでしょうが、それは考えが甘いです。一度ついてしまった悪評はなかなか消せるものではありません。とくにインターネットが普及した現在ではなおさらです。
とにかく目立てれば、自己顕示欲だけ満たせれば何でもいいというのであれば最早なにも言うまいです。しかし、まっとうなソフトウェア技術者として認知されたいなら、地道に自分を鍛えてまともな実績を積み重ねていくのをお勧めします。
大学でもっとまじめに学んでおくべきだった
大学ではB4の一年間、人によってはさらにMとかDとかで研究をします。そこで学べることについて、および、それを学ばなかったがために私が苦労したことを書きます。ここでは大学に行く人を主な読者層にしていますが、そうでなくても就職した後に後述の問題に遭遇することでは同じです。
わたしは高校時代は「プログラミング一本で生きていく」という決意をしていました。そこで近くの大学に情報工学科という学科があったので、そこを受験しましたが見事落選、第二希望だった別の学科に受かりました。このあとわたしの大学生活のポリシーは「可能な限り楽をして大学を出る、その間にプログラミングについての知識を独学する」でした。B4およびMでの研究においてもそのポリシーを愚直に守り通し、手抜きに手抜きを重ねてギリギリで卒業、修了しました。不良学生というやつです。最終的にはプログラミングやその他低レイヤといわれる領域の知識は平均的なCSの学生より優れていたと思います。しかし、それだけでした。
さて、大学でまじめに学ばないというのは何を意味するのでしょうか。大学卒業後は、Dをとってその後もさらに研究を続けるような一部の人以外は、おおむね就職します。場合によっては私のように大学で研究分野とは一切違うことをする人もいるでしょう。ただしそれに意味がないかというと全然違います。大学でちゃんと学んで研究していれば、個々の業務内容によらない問題設定、仮説、検証を含めた、分野によらない問題解決のための知識、および議論する能力などが得られます。それに加えて論文執筆を通じて、それを人に余すところなく伝えるための作文能力、プレゼンテーション能力などが鍛えられます。もっといろいろありますが、ここでは比較的わかりやすいものを挙げました。端的にいうとわたしはさぼりまくったがゆえにこれらについて何も学ばなかったのです。
その結果は悲惨なものでした。自分ではいっぱしの能力を持っているはずなのに、プログラミング能力などは場合によっては入社後数年経った人よりもすぐれていたのに、まったく仕事ができないのです。「こういうことをしてほしい」と伝えられてもうまく問題設定ができない、進め方がいきあたりばったりで効率が悪い、出てきた成果物の根拠があやふや、などです。結果を人に伝えるときも口頭では「支離滅裂で何を言っているかわからない」という旨をオブラートに包みながら指摘されました。仕様書などを書いても「何をしたいか見えてこない」とよく言われて、いつも跡形もないほど直されました。書いていて辛くなってきたのでここまでにしておきますが、それはもうひどいものでした*1。
それもそのはず、わたしは大学に入ってから修士課程を修了するまでの6年間、自分で思いつきでやりたいことをやって、途中で脱線してもOK、楽しければOK、人と議論することもない、ということしかやっていなかったからです。これではうまくいくはずがありません。その後問題の本質に気づいて、なんとか訓練してそれなりのことができるようになるまで2,3年はかかったように思います。正直言ってこの間はかなりキツかったです。そして表題の通り、「大学でもっとまじめに学んでおくべきだった」と激しく後悔しました。
と、つらつらと、本当に大学で何も学ばなかった私の極端な書き連ねてきたことをもとに、現在大学生の人には大なり小なり「俺はこいつのようにはなりたくない」と思ってもらって、しっかり研究活動に邁進していただければなによりです。おわり。
*1:当時の自分の生産物を今振り返ると、自分でいうのもなんですがゴミのようなものしかなくて、根気よく指導していただいた諸先輩方には頭が下がるばかりです
ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい
ソフトウェア技術者として名を上げたい人向けの記事です。
まずは前置き。ソフトウェア技術者の世界にはスーパースターといえるような凄まじい能力を持つ人達がいます。彼らのうちの一部は生活能力がゼロだったり、口や態度が悪かったり、好きなこと以外は一切できなかったりといった様々な欠点があります。すごい人の中でもこういう人は親近感を生むのか、なんとなく目立つ傾向にあるように思います。SNSなどでも粛々と技術の話だけしたりする人よりも、こういう破天荒な人たちがウケて人気を集める傾向にあります。かくいうわたしも、この手の人たちは人間臭くて好きです。
ここからが本題。スーパースターにあこがれる人が彼らのスキルを真似するのではなく、立ち振る舞いを真似してしまって、とくにSNSなどでそうしてしまって、自分の価値を貶めているのを頻繁に目にします。典型的には凄くなりたいけどまだまだ経験が足りない学生さんや経験の浅い社会人などです。技術はすぐには真似できないけど立ち振る舞いは真似しやすいのでそうなるのかもしれませんが、これは本質を外していることはもちろん、大きなリスクになりえます。
欠点が大量にあるスーパースターたちは、得難いスキルがあるからこそ少々の欠点は許容されます。ところがまだ何も持っていない人が破天荒な振る舞いをしても、ただの厄介な人になるだけです。欠点の無い人なんていないので無理して立ち振る舞いを矯正する必要はないと思いますが、少なくとも意図的に奇矯な振る舞いをすることは、わざわざ評判を下げるリスクをおかすだけなので、避けるのが賢明かと思います。その振る舞いに可愛げがあればコンテンツとして面白いので知名度は上がるかもしれませんが、それだけです。それでスキルが身に付くわけではありません。
技術者として名を上げたいのなら技術で目立つのがよいかと思います。
新しい環境で大失敗した話
以下記事の文字起こし+αです。他の記事で書いたことがあるようなものは省略しました。
前置き
わたしは前職を退職してからしばらく無職だったのですが、一年くらい後に今の会社に拾われました。そのときは多分うまくやれるだろうと軽く考えていたのですが、実際にはしばらく何もかもがうまくいかなかったです。
正直言ってこれを公にするのはかなり恥ずかしかったのですが、だれかがわたしと似たような境遇、新しい環境へのチャレンジする状態になった場合に他山の石とできそうなので書くことにしました。
話の都合上リモートワークや時短勤務について言及しますが、これらの制度を否定するつもりはまったくないです。また、会社としてはずっと気にかけてサポートしてくれていましたので、非はすべて私にあると先に書いておきます。
今いる会社に入ったときは私的な制約や好みにより次のような条件で働くことにしました。
- 週20時間勤務(いわゆるフルタイムの半分)
- 働く時間も不定
- フルリモート勤務
では本題に入ります。
コミュニケーションの失敗
入社した当時は他の人とは全然違う、開発は当分先のストレージまわりの調査をしていました。そのときは「まずは他の人と一緒に仕事するわけでもないし」と自分から望んで定例会などには出ませんでした。私は知らない人と話すのがあまり得意ではないので、当時は何となくこうしたんだと思います。
このあと少ししてから非常に仕事がやりにくいことに気づきました。失敗に至るまでの流れは次のようなものでした。
- フルリモート勤務なので雑談する機会が無い
- メンバの人となり、誰がどんな役割なのかがわからない
- 寂しいし、蚊帳の外にいるような気になる(自分でそう思ってるだけだが)
- 何かあったときに誰に何を頼めばいいか、いちいち迷う。コミュニケーション効率が悪い
これについては、プロジェクトメンバやマネージャなどが見かねて助け舟を出してくれて、しばらくしてから定例会やモブプロにも入れてもらうことになりました。「こいつ使えない、クビ*1」でも不思議ではなかったのですが、見捨てず支えてくださったかたがたには感謝しかありません。
この後だんだんプロジェクトになじんできましたが、最終的にこの問題が解決したのは1年後くらいに海外のイベントにみんなで一緒に行って苦楽を共にしてからでした。それまでは全く意識していませんでしたが、私にとって同僚はある程度腹の内がわかる相手でないといけないということを思い知らされました。やってみないとわからないものです。
畑違いの分野へのキャッチアップの失敗
わたしは前職ではLinuxカーネルの開発、サポート業務をしていました。上述のように新しい環境では未経験だったKubernetesクラスタの構築という仕事をすることになりました。前職ではそれなりの実績があったため、「ちょっと上のレイヤに移動するだけだからすぐキャッチアップできるだろう」と高を括っていたら大間違いでした。実際には全然そんなことはなく、当時の私のスキルセットにはまったくない、非常に広い範囲の技術について知らなければいけませんでした。
この問題を解決するためには近道などなく、慣れるまで必死に食らいつくしかなかったです。最初に週20時間しか捻出できなかった頃は、何か一つ覚えているうちにKubernetesの世界や社内の開発は2つ先に進んでいくという具合で、ひたすら呆然としていました。事情が変わって仕事にかけられる時間が増えたことにより徐々にキャッチアップが進み、「これならなんとか」というレベルになるまでに結局2年くらいかかりました。
当時の技術力および時間の不足もそうですが、一番の問題は全く別分野の実績に胡坐をかいて舐めてかかっていたことだと思います。ある分野で実績があっても、他の分野では素人に過ぎないと思い知らされました。
まとめ
読者のみなさんがもし新しい環境に挑む場合は、あるいは今まさに挑戦しているという場合は、わたしと同じ轍を踏まないでほしいなと思います。そのためにこの文書がなんらかの役に立つことを願います。
ヘタクソなコードを書いてもいい
プログラミング言語のお作法から外れたコードやメンテ性が悪いコードを書くのはダメとよくいわれます。わたしは学生の頃、そういう意見を過剰に気にしていました。コードを書くことそのものに慣れていないのに綺麗に書こうとして手が動かず、動かないがゆえにコーディングの練習が進まない、という悪循環になっていました。そうすると何もアウトプットしないまま知識だけが増えていって、自分がこれくらいできそうというイメージと実際のプログラミング能力とのギャップで苦しみました。
この意識が薄れたのは、あるときものすごく手が早い人のコードを偶然見たときでした。たしかにちゃんと動くものができているんですが、そのコードの中身は当時の私の基準からいって*1おぞましいほど汚いものでした。そこで「これはわたしが書けば100倍くらい綺麗なコードを書けるんでは…」と一瞬思ったんですが、その後すぐに「あ、自分は知識はあるけど練習してないから手が動かなくて全然書けないや」ということに気付きました。当たり前といえば当たり前のことなんですが、当時は衝撃を受けました。わたしは耳学問でいろいろ知っているのに何もできず、彼はお作法は知らないけど馬力で動くものをちゃんと作っていました。その差は明白です。
このことがあってからはコーディング時に綺麗さをさほど重視しなくなりました。ヘタクソなコードをたくさん書いて、ヘタクソであるがゆえに痛い目を見ることによって、お作法の意味やメンテ性を上げることの重要性が腑に落ちました。
「若いころはそうだったなあ」というような書き方になりましたが、今でも新しい言語を学ぶようなときは最初はその言語の使い手から見るとヘタクソで目も当てられないようなコードを書きます。なぜならその言語については初心者だからです。でも練習中なので気にしません。
当時のわたしと似たような悩みをかかえているかたは、まずはぐちゃぐちゃでもいいから、欲望のままに、とにかく動くものを書いてみるのがいいんじゃないでしょうか。おぞましいコードでもいいんです。そうしたらけっこう道はひらけるかもしれません。
さて、趣味なら徹頭徹尾汚いコードでいいんですが、仕事ではそういうわけにもいきません。では仕事ではヘタクソなコードを一切書いてはいけないかというと、そうではないと私は思います。私はある程度キャリアを積んだ今でも最初から綺麗なコードを書くことにはこだわっていません。まずはダサくてもとにかく目的を達成する動くものを書いて、その後に世に出せるものに修正してPRを出すというやりかたをしています。作文するときに最初はドラフトを書いて、その後に推敲して清書するのと似たようなものかと思います。
まあこんなかんじで、下手なコードを書くのを怖がっているかたが、それを恐れずに、堂々とできるようになればいいかなと思います。おわり。
*1:今の基準でもですが
新型コロナ禍におけるリモートワークの知見共有
はじめに
本記事は以下スライドを文書にしたものです。
本記事は新型コロナ禍による環境の変化にともなって業務に支障を来している社会人に向けて、いくつかの課題と、それについての対策案を書いたものです。想定読者はこれまでオフィスに通勤していたけれどもリモートワークになって困っている人、および、新卒入社でいきなりリモートワークになって困っている人たちです。zoomなどの音声/ビデオによるコミュニケーションツール、slackなどのチャットツールは使える状態であると仮定して書いています。
本記事は新型コロナ禍より前からフルリモートワークをしていて、かつ、本記事で書いた状況、問題のすべてに遭遇してきた筆者の経験をもとに書きました。
同僚とのコミュニケ―ション
新型コロナ禍より前から働いていたかたはコミュニケーションコストが高くなったと感じることが多いのではないでしょうか。たとえば、これまで口頭で済んでいたことをいちいちzoomやslack経由でしなければならなくなった、などです。コミュニケーションコストが高くなると自然とコミュニケーションをとるのが億劫になってきてチームが機能不全に陥ることも珍しくありません。
このようなときに明にコミュニケーションを取りやすくなる施策が有効ではないかと考えています。具体的には定期的に雑談的なミーティングをして個々人の思いを吸い上げておくことです。それだけではなく、zoomで誰でもいつでも入れる雑談部屋を用意して、疲れたらそこに入ってどうでもいい話をするなどです。作っても使われないプラットフォームは無意味なので、なんとなく人と話したくなったときに「雑談zoom部屋に行こう」と誘ったり、それを気軽にできる空気を作るのもよいでしょう。
新卒入社した人や転職した人はもっと大変でしょう。まず、誰がどういう役割なのか、どういう人となりなのかがリモートだと全然つかめません。このため、相談しようにも誰にすればいいのかわからず、かつ、既存の社員からしても困っているかどうかがわかりにくいです。
このような問題を避けるために、新しく入ってきた人とのアイスブレイクのための雑談の機会をなるべく早く設けるのが重要だと考えます。対面で話せていたようなときは入社した後に数日してから懇親会をする…というようなやりかたが一般的だったでしょうが、今は自然に発生する雑談は期待できません。また、このような雑談においては既存の社員同士で盛り上がるのは新しい人に疎外感を植え付けるので避けたほうが無難かと思います。
気持ちの切り替え
オフィス勤務ではないということは出勤という仕事とそれ以外を分けるスイッチの一つがなくなったということです。このため、気持ちの切り替えができずにずっと気持ちが張り詰めたままという例を少なからず耳にしました。また、仕事を終えたとしても家に仕事ができる環境が整ってしまっているので、ついつい会社のメールチェックをしてしまったり、というのも珍しくありません。
このようなときの対策として、仕事とそれ以外のときに使うものは完全に分けてしまうという手があります。たとえばPCや机などです。ただ家の広さは有限なので、これは簡単にはいきません。せめて仕事が終わった瞬間に会社用のPCは電源を抜く、外に出かける、仕事と関係ない趣味を作って没頭する、などのスイッチを作るとよいかと思います。わたしはやったことがないですが仕事前後で着替えをするなども効果がある人がいるようです。
身心の健康
新型コロナ禍はこのウィルスにおかされなくても心身の健康を害していきます。ここでは身体の健康と心の健康に分けて課題と対策案を書きます。
身体の健康
身体の健康に影響をおよぼすのはなによりも外出機会の喪失、および座りっぱなしの機会の増加による筋力低下、体重増加、体の凝りなどが大きいでしょう。この問題についてはたとえば寝具や椅子、机に可能であれば投資をするという方法があります。これらは高ければいいというものではないのですが、ある程度までの金額であればQoLを劇的に上げられるケースが珍しくありません。
お金がないわけではないけれども「もったいない」という理由で最安のものばかり使ってきたというかたは、一度家具屋などで安くないものを試してみて、これは自分に合うとおもったら買ってみるとよいと考えます*1。中古市場もあるので、抵抗がなければ使ってみるのもありかと思います。
他には運動やストレッチが有効です。定期的に長時間の運動が難しくても、気づいたときに一分くらいかけて軽いストレッチをするだけでもだいぶ違います。筆者は一息つくたびに首の凝りをほぐしていますが、やる前と比べてずいぶんと体調がよくなりました。休憩時間や思考時間にはあえて立ってうろうろしてみるというのも一つの手です。とにかく座りっぱなしというか同じ姿勢でずっといるのはよくないです。
心の健康
心の健康については新型コロナ禍以後に多かれ少なかれ問題が出たという人はかなり多いようです。症状の出かたは人によって全然違うのですが、眠れない、気持ちがふさぎ込む、イライラする、集中できない、などなどです。この手のメンタル疾患の兆候については厚労省のサイトなどを見ればいろいろ書いています。
解決策については、やばそうだと思ったら精神科ないし心療内科にかかるのが一番かなと思います。これらの科にかかるのに抵抗があるのは理解できますが、健康のほうが重要です。メンタル疾患をこじらせると二度と社会復帰できなくなることもあるので、少しでも危ないと感じれば行ってみるとよいかと思います。
友人知人に悩み相談をすることもあるかと思いますが、そのとき具体的な対策についてのものは避けたほうがいいかもしれません。彼らはあなたに親身になってくれるかもしれませんが専門家ではないので、見当違いのことをいって治療を遅らせることもあります。下手をするとオカルトにはまったりカルトに走ったりするリスクもあります。世界には正常に判断ができなくなっている弱い人を狙っている人が残念ながらそこかしこにいます。
おわりに
最後になりますが、本記事に書いた施策案は耳ざわりがよいものが多いですが、全員に当てはまるようなものではありません。たとえばそもそもコミュニケーションが苦手な人にとっては定期的な雑談などは苦痛でしかなく、フルリモートワークで誰とも話さないという現状が最高なもかもしれません。このため、あえて「対策"案"」という表記をしました。無理強いはせず、個々人に合わせて対策を打っていた抱くといいかと思います。
読者のみなさまやその関係者のみなさまがこの社会の劇的な変化を乗り切れること、および、本記事がその一助となれることを願います。
*1:なければ買わなくていいです。相性の要素は大きいので
企業にとってのプログラミング言語の位置づけ
プログラミング言語の良し悪しについては昔から活発に議論されてきました。このような議論の中で企業がどのようなプログラミング言語を採用するかについて釈然としない思いをしたかたも多々いらっしゃるかと思います。典型的には「なぜ自分の会社では俺の好きな言語を採用しないのか」です。この「なぜ」の一部に回答する、かつ、そこに共感しないまでも理解してもらうのが本記事の目的です。
この手の会話は炎上しがちであり、かつ、私はそのようなことはしたくないので個々の言語の名前は挙げません。そのためやや抽象的な表現が多くなりがちですがご容赦ください。また、筆者はここで書く価値観が絶対というつもりはなく、読者のみなさま個人のプロジェクトは自分の欲望の赴くままに好きなものを使えばいいと思っています。
企業は継続的にプログラムの開発やメンテナンスをする必要があります。これを念頭に置くと、使いこなせる人が多い言語であれば複数人で開発する場合に有利です。後から人員を追加するときには学習コストが低いものが採用しやすいです。このような言語でないと開発組織をスケールさせるのが難しくなります。どれだけ設計が優れた言語であってもそれを使いこなせる人がいなければ、とくに大きな企業では、大規模な採用は辛いでしょう。
その一方で、いくらユーザが多くても年長者にしか使い手がおらず、若手は嫌うような言語は長期的には採用しづらくなっていきます。理由は将来的に技術者の確保が難しくなっていくからです。ある時期にいきなりプログラミング言語の流行りが変わっていく理由の一つがこのような世代交代です。いつだって主流派は強いのです。
何かを開発するときには標準ライブラリだけあればいいというのは稀なので、企業の目的を楽に達成できるライブラリが豊富にあるかどうかも重要です。企業にとっては利益を得るのが重要なので、貴重な人的リソースを使って毎度毎度「なければ作る」で挑むよりも、ありものを使ってやりたいことに集中したいことのほうが多いでしょう。
何か起きたときのデバッグ、トラブルシューティングが容易なツールが揃っているかどうかも重要です。作ったもののメンテできない、しづらいものは企業は使いにくいです。この意味では昔から業務用に使われ続けてきた言語は多種多様なツール、およびノウハウがあるので有利となります。明らかに昔のものより設計が優れている言語が一向に普及しなくて不満を募らせるというのはよくあるのですが、その大きな理由として絶対的なユーザ数の不足に加えてこの手のツール/ノウハウの不足があります。
ではみなさんが使いたい言語を仕事でも使いたいならどうすればいいかというと、一つは特定言語で開発していることが募集要項において明らかな企業やプロジェクトに入ることです。中には特定言語を使っていること、あるいはその言語のエキスパートが揃っていることを前面に押し出している会社もあります。興味があれば調べてみるとよいでしょう。
あるいは茨の道ですが、いま居る組織の中で自分の好きな言語を使うほうがいいと説得するという方法もあります。ただし、この場合はあなた以外がその言語を使えないということであれば、あなたが作ったプログラムはあなたがメンテし続けることになるでしょう。メンテは開発よりも大変なので、あとになればなるほどやることを変えられないという事実が重くのしかかってきます。「それは嫌だから辞める」というのはもちろんアリなのですが、企業にとってはそれをやられるのは嫌なので、やっぱりユーザが少ない言語の採用には及び腰になります。
読者のみなさまが本記事を読んで個人プログラマの顔と職業プログラマの顔を使い分けて折り合いをつけられるようになること、あるいは馬力で現状を打破できるようになることを願います。
