会社員で「コミュニティの人」でもある場合の落とし穴

本記事はIT技術を専門とする会社員で、社外にある程度「あのコミュニティ(例えばプログラミング言語、フレームワーク)のあの人」として名が通っていて、業務の一環としてそのようなこと(以後「コミュニティ活動」と記載)をしている人が注意するとよさそうなことについて書きました。そのような人になりたい人も読むと役立つかもしれません。なお、本記事は特定個人の話ではなく、自分もそうなりかけた経験を含めた一般論です。

誰かが「あのコミュニティのあの人」であることは、それが当人とそのコミュニティにとって良いことであれば、個人としてやっていれば何も問題はありません。しかし、会社員としてそのようなことをしているときにはまりがちな落とし穴があります。

コミュニティ活動をして名が通ってくると、社外に様々な知り合いが増えます。何らかのイベントに呼ばれたり、取材されたりすることもあるかもしれません。なんだか凄そうです。成果が出た気がします。しかし、本当にそうでしょうか。

会社員としてコミュニティ活動をしていると、そのために時間を使うことが増えてきます。チームメンバーと一緒に仕事をする機会も減るでしょう。そんな中で、コミュニティ活動をすることが雇用主やチームの期待する役割と合っているかは定期的に確認しながら日々やることを決めていくとよいと考えます。

定期的な確認をしないと、どういうことが起こりうるかを書きます。まず、社内で浮きます。最悪の場合、「なんだか有名らしいが、何をやっているかわからなくて、会社に貢献してるかどうかも不明で、遊んでいる人」に見られる恐れがあります。周りもフォローせず「会社の業務に貢献していないので評価はできない。しかし下手に発信力があるので強く言いにくい」と放置されるケースもあるようです。

こうなると本人は精力的に活動していて外向きには評価されているのに、内部では評価されないというギャップが生まれます。それに耐えられなくなって会社を辞めてしまう人、あるいは不満を社外に吐き出して信用も毀損してしまっている人は珍しくないです。

このような悲劇を防ぐために、コミュニティ活動をやっている理由と効果を関係者に、少なくともキーマンに納得してもらう必要があると考えます。それによって初めてコミュニティでの活動が業務としての成果となります。コミュニティ活動は成果が測りにくいのですが、適当に挙げると、たとえば会社のプレゼンス向上に繋がる、採用につながる、他社技術者との交流によって新たな知見が得られる、などがあります。これらを上司との1on1やチームのミーティングで主張して、実際にやり遂げて信頼を積み重ねることが大事です。

要は「必要性を周りに納得してもらったことをやると成果になる」というだけの話なのですが、これが難しい。コミュニティ活動を頑張ると社外評価が高まるので、それが社内評価に直結すると錯覚しやすいのです。そこに気をつけてほしいと思います。

色々書きましたが、基本的に私は誰かが何らかのコミュニティで重要な役割を果たしてくれるのは素晴らしいことだと思います。ただしそれを会社の給与を受け取りながらやる場合は、関係者が納得した上でやるとよいのではないか、本人の信用を毀損してまでやることではない…という話でした。

Linuxとの出会い

私が2002年頃にLinuxを使い始めた当時のことを書きます。ずいぶん前の話なので、これからLinuxをインストールして使ってみたいという人には十中八九役に立たないでしょう。どちらかというと青臭い学生の一人が2002年という時代にどういう思いで、どのようにLinuxを導入したのか、それが今にどうつながっているのか、という話を紹介して「そんなこともあったなあ」「昔はこんなかんじだったのか」「なんだこいつ」と気楽に読んでもらうことを想定しています。

当時の私はWindows上で趣味でプログラミングをしていたのですが、調べものをしているときにしょっちゅう目にしたのがLinuxです。Windowsのプログラミング環境といえば当時は有料で、しかも高価なものが主流だったのですが、Linuxというのを使えば無料で本格的なプログラミング環境が得られるということを知り、ぜひ使いたいと思いました。LinuxがUNIXクローンであるということは知っていたので「これはいい」と思ったものの、UNIXを使ったことがなかったので何が「これはいい」だったのか、今となってはよくわかりません。

無料のプログラミング環境が欲しいという事情とは別に、「Linux」という単語を当時の私は流行りものの1つとして認識していました。Linuxの生みの親であるLinus Torvaldsさんが書いた「それがぼくには楽しかったから」は当時大きな話題になっていました。

それがぼくには楽しかったから 全世界を巻き込んだリナックス革命の真実 (小プロ・ブックス)

私はこの本を読んでいなくて聞きかじりの知識しかなかったのですが、とにかく「なんだかわからないけど凄そう、名前もクールだし」と思ったことは強く記憶しています。2026年現在ではLinuxというのは空気のような「あって当たり前」の存在ですが、少なくとも当時の私にはそう見えていませんでした。私は大学でコンピュータとは全然違うことを学んでいて、プログラミングをするような知り合いもいなかったので、いわゆる情報系の学科にいた人々の感覚はまた違っていたと思います。

さてインストールするぞとなったときに、Linuxにはたくさんの「ディストリビューション」とかいうやつがあるらしいことを知りました。色々あった中で「ぐるぐるしているロゴがかっこいい」「aptとやらが便利らしい」「名称にGNUを含めることでGNUに敬意を払っている」という理由でDebian GNU/Linux(以下「Debian」と記載)を使うことにしました。GNUが何なのかはよく知りませんでした。

インストールするときには武藤さんが書かれた「Debian GNU/Linux徹底入門」(以下「Debian本」と記載)を買いました。

Debian GNU/Linux徹底入門: Potato対応

「Debianといえばこれだ」という評判を様々なところで目にしていたためです。また、インストールメディアが同梱されているということも大きかったです。それはBlu-rayやDVDではなく、3枚のCD-ROMでした。

Debian本には特別な思い入れがあります。私はLinuxを使い始めた頃に多くの知識をこの本から得ました。この本がなければ現在の自分はなかったというくらい私の人生において大きな役割を果たしました。数年前に武藤さんに初めてお会いしたときは、はしゃぎまくって握手をしてもらいました。「ついにここまできた」というよく分からない感想を持ったことを覚えています。

話を元に戻します。DebianをPCにインストールするにしても、私はマシンを1台しか持っていませんでしたし、Debianのために2台目を用意することは現実的ではありませんでした。クラウドベンダが提供する無料インスタンスといった便利なものも存在しませんでした。というわけで1つのPCの中で既存のWindowsとDebianを共存させるデュアルブート環境を作ることにしました。ここはDebian本に丁寧にやりかたが書かれていたので全く問題ありませんでした。Windows環境をブッ飛ばすと研究に支障を来すため、物凄い緊張感をもって設定をしていたことを記憶しています。その後、Debianのインストールは無事完了しました。しかし、インターネット接続ができず、GUIが使えない状態でした。

ついにプログラミングをするときがやってきました。「プログラミング用の環境といえばviかEmacsか」という話を聞いていたうえに、「Emacsは環境」「EmacsはOS」「Emacs Lispを使えば無限にカスタマイズできる」という評判に流されてEmacsを使うことにしました。キーバインドが指になじむまではとにかく辛かったです。最初期はEmacsを終了させる方法がわからず、Emacs以外のものを使いたいときはマシンをリセットしていました。

プログラミングなりLinuxの一般的な使い方なりを調べる際には書籍だけでは十分な情報が得られませんでした。インターネットがそのようなときに強い味方になってくれました。しかし上述したように私のDebian環境はインターネットにつながっていませんでした。スマホなどという便利なものも当時はありませんでした。ではどうするかというと、インターネットで調べものをするたびにマシンを再起動してWindowsを起動していました。「自分は何をやっているんだ」と思うことが多かったですが、次第にコツをつかんできて、しばらく後にようやくDebianをインターネットにつなげることができるようになりました。GUIもそのうち使えるようになりました。感動です。

そんなこんなでLinuxを知ってから数年かけてそれなりに使いこなせるようになり、Linuxそのものの開発をする職を得たりと色々ありました。迷走を繰り返しましたが、あの頃があったからこそ今の自分があるのだなと思います。おしまい。

リモートワーカーとしての振る舞い

私は新型コロナ禍よりさらに前から10年近くフルリモートワーカーです。自宅からオフィスまでは電車で4時間ほどかかります。出社は滅多にしません。そんな私が試行錯誤の上に考えた、リモートワーカーはどのように振る舞うとよさそうなのかという知見を共有します。本記事は「企業はリモートワークを推進すべきか否か」というホットトピックには言及しません。あくまで自分自身リモートワーカーであることを前提として、自分がチームの一員として仕事するにあたって、どうすればやりやすくなったかについて書きます。

まずは共有が必要な情報の把握について。とにかく「何やってるかわからないブラックホールみたいな人」にならず、「やるべきことをやっているかどうか確認できる人」「そうでないときは回りが指摘できる人」「困っていたら助言ができる人」になることが大事です。それを心にとどめていると、なんとなく程よいやり方が分かってきます。定期的にチームメンバーに「このような共有のしかたでよいか」とみんなに尋ねるのも良いと思います。どのみち最初から完璧な情報共有はできませんし、何が重要かは日々変わっていくので、実際にコミュニケーションをしながら、やりかたを改善し続けると良いと思います。

伝えるべき情報がわかったとして、伝えかたについてはどうすればいいでしょうか。大前提として、リモートワーカーはオフィスワーカーに比べてコミュニケーション方法が限定されます。よく例に挙げられるように、みんながオフィスで仕事しているときの「今ちょっといい？」と声をかけて短時間で情報を把握する、物理的にホワイトボードで図を描いて議論する、ということができません。できないものはしかたがないので、そういうことができない人として、どういう方法でチームメンバーとコミュニケーションをすればよいかを考える必要があります。よく「リモートワークだとコミュニケーションをとらなくていいので楽」と思っている人がいますが、それは違っていると私は思っています。そうではなく、コミュニケーションに制限があるがゆえに、オフィスワーカーよりも色々な試行錯誤をしてはじめて同等の成果を出せる、リモートワークの難易度はオフィス勤務よりも高いと思っています。

ではどうすればいいかという知見は、幸か不幸かCOVID-19禍に世の中に大量に溜まっているので、そのうちいくつかを紹介します。

• いわゆる分報やtimesで現在何をしているのか、何に疑問を持っているか、何に困っているかをフロー情報として書き連ねる。
• とくに重要なものはストック情報として、どこかで集中管理する。分報のようなフロー情報はリアルタイムで細かい情報を得るには適しているが、「で、今どうなってるんだっけ？」や「過去にいつどんな意思決定をしたんだっけ」と振り返るのが極めて辛いので、このようなものが必要。
• とくに集中したいとき以外はみんなが相談できる場としてのZoomやTeamsのビデオ会議に集まるようにしておく。
• 定期的に物理的に集まる日を作る。
• 普段はテキストで非同期にやりとりするが、それでは効率が悪いと思ったら同期コミュニケーションに切り替える。

これらのうちのどれがチームにマッチするかはチームによって全く違います。チームメンバーの個性、仕事の性質、リモートワーカーとオフィスワーカーの比率、いろいろな要素が適した方法がどれかにかかわってくるでしょう。一人だけで考えるのではなくチームとして試行錯誤し続けるとよいでしょう。

色々書きましたが、三行まとめをすると次のようになります。

• リモートワーカーはコミュニケーション手段が限られるのでオフィスワーカーよりも工夫する必要がある。
• コミュニケーションが限られた中で、お互いに何をやっているか、正しい進め方をしているか、何に困っているかがわかるようにしておく必要がある。
• 自分1人ではなく、チーム全体として最適なコミュニケーションを模索し続ける必要がある。

これを見てもらえればわかるように、半分くらいはリモートワーカー、オフィスワーカー共通の課題があります。それぞれが協力しながら、みなさんが「この人にはリモートワークをさせていても大丈夫」とまわりに思ってもらえるようになればよいなと願って本記事を終わりにしたいと思います。

間違えると死ぬ思考からの脱却

昔書いた以下の記事の姉妹編です。

https://satoru-takeuchi.hatenablog.com/entry/2023/08/18/201343

何をするにも試行錯誤が大事です。試行の後に続く錯誤とは、誤り、間違いといった意味を持ちます。試行と錯誤は両輪の関係にあるのですが、試行はいいが錯誤、失敗は怖いという人は多いのではないでしょうか。過去の私もそうで、失敗したら死ぬくらいの勢いで恐れていました。理由はわかりませんが、いつのまにかそうなっていました。

この思考の癖は実に厄介です。失敗を恐れていると、失敗しないような試行しかしないから、しょぼくれたことしかやらなくなります。物事が先に進まないし、成長しません。これは厳しいな、どうにかしたいなと考えた結果、「失敗がうまくいってないんだから、失敗の練習をしよう」という考えに至り、やってみたらうまくいきました。何かの本で読んだのか、自分で思いついたのかは覚えていません。したがって医学的な根拠があるとかではないです。話半分に読んでください。

失敗の練習とは、わざと失敗することです。うまくいかなさそうということを、あえてやります。まずは小さな失敗から始めて、慣れていきます。だし、他人を巻き込む失敗をわざとやると、その他人はたまったものではないので、自己完結する失敗をします。具体的には、プログラミングでいうと、gotoを使いまくりのトイコードを書いて混乱するとか、めちゃくちゃ大量の配列をバブルソートして遅くて耐えきれずに処理を途中で止めるとか、そういうことです。わざとアンチパターンを踏み抜くといってもいいかもしれません。

「狙って失敗させたら、それは成功なのでは」と思われるかもしれません。その通りです。失敗は成功であるという自己暗示をかけているのです。こういうことを繰り返し行くと、だんだん失敗に抵抗感がなくなってきました。そのうちハードルを上げて、本当に結果が読めないが、失敗しても他人に影響がない試行をしてうまくいったりいかなかったりすることを繰り返して、次第に失敗に慣れていきました。最終的に現在では大小さまざま、多種多様な失敗をたくさんしますが「まあいい、次がある」「うまくいかないことがわかったので前進」と考えられるようになりました。

最後になりますが、失敗を肯定すればいいというものではないということは言っておきます。他人を巻き込む失敗、とくに大きな失敗をしてヘラヘラしててはいけません。任意の失敗をするたびに落ち込んでパフォーマンスを落としてしまうようなことなく、次に繋がる改善を考えるのが良いでしょう。よく言われることですが、なるべく早期に小さな失敗をしまくるのが吉です。

あるプログラマの若かりし頃の奇行集

昔は自分がプログラマとして成長するためには何が必要なのかを悩み、悩みはするが深く考えずに思いつきで奇行に走るということをよくしていました。今になって振り返る微笑ましくて面白かったので、いくつかを紹介します。十中八九読者の今後の人生に役立たないですが、失笑しながら読んでもらえれば幸いです。

gzipコマンドの全オプションを丸暗記しようとする

最初からプログラミングとあんまり関係ない話です。

Linuxを触り始めた頃にgzipコマンドの存在を知り、「全てのオプションを暗記して完全理解したい」と思いました。今覚えば、やるとしても他にもっと別のコマンドがあるだろうとは思いますが、たまたま目の前にあったgzipに飛びついてしまいました。

gzipのオプションは見たことがある人なら知っていると思いますが、めちゃくちゃ多いです。しかも圧縮アルゴリズムの名前は、少なくとも当時の私には理解できない謎の文字列でした。man gzipを研究室のレーザープリンタで印刷したのを覚えています。

その後どうなかったかというと、数日後に飽きて、あっさり止めました。

GNU Helloを熟読する

GNU Helloは、いわゆるHello WorldプログラムをGNUのお作法に則って書いたものです。そのようなお作法で他のソフトウェアを作る際に参考にできるようになっています。多言語化されていたり、たくさんのオプションをサポートしていたりと、かなり凝っています。コードのフォーマットはもちろんGNUです。

このソフトウェアを知ったとき、「なんかしらんがオープンソースの人はみんなこういうスタイルで開発しているらしいからマスターせねば」と固く信じて写経しました。「これ読みにくいし書きにくいし辛いなあ」と思いながら完遂したものの、全然しっくりこなくて面白くなくて、全てを忘れました。そしてオープンソースというかこれフリーソフトウェアですね。当時は違いがよくわかってなかったです。また、「みんなこういうスタイルで」も単なる思い込みですね。

オブジェクト指向こそ至高

オブジェクト指向というものがあります。今となってはわざわざ語るまでもない当たり前の概念ですが、当時は流行りものの一つという扱いを受けることが多々ありました。現在は「場面に応じて使いたい人が使いたいところで勝手に使えばいい」という思いを持っていますが、当時はプログラミングを始めて間もない頃だったので、私は最初に見たオブジェクト指向を親だと思うヒヨコでした。

当時はプログラムがオブジェクト指向かどうかを異様に気にしたり、全てをオブジェクト指向で書こうとしたりとか、手段と目的が見事に逆転したことをしていました。スカスカのにわか知識はたくさんつきましたが、プログラミングの腕は一切上がらなかったです。

なお、別にオブジェクト指向に恨みがあるわけでなく、わたしが勝手に意味を誤解して狂信者になって自滅しただけです。

マイクロソフトを強く憎む

マイクロソフトは今でこそWSLを出したりLinuxカーネルにコミットしたりAzureでLinuxを動かせたりと、Linuxをビジネスに最大限に活用しています。しかし、昔はそういうことは無かったです。私は聞きかじったにわか知識をもとにマイクロソフトは悪の帝国、オープンソースの敵、金の亡者、Micro$oft，M$、と、心のなかで罵っていました。Linuxのドライバが無いハードウェアのベンダやLinuxをサポートしないソフトウェアのベンダも巻き添えでけしからんと思っていました。

インターネット上の当時流行っていた2chのような場所で暴れる趣味はなかったので、幸いにも電子の海に爪痕は残っていません。しかし、思っていたことをそのまま公の場で発言していたら社会から消えていたかもしれません。よかったですね。

あとこれもプログラミング関係ないですね。

Design by Contractに囚われる

オブジェクト指向の話の続きです。この世界では有名なオブジェクト指向入門という本があります。契約による設計という面白い概念がありまして、それについて詳しく書いています。この本に出てくるプログラミング言語Eiffelはメソッドに事前条件、事後条件、普遍条件をコードとして書けるのですが、私はそれを痛く愛してしまいました。

愛が深まった結果、ガチガチに契約で縛った使いづらいクラスを量産しました。クイックソート用のメソッドの不変条件でバブルソートして結果を照合という、なんだかよくわからないことをしていました。

プログラミングの腕はとくに上がらず、変な考え方がしばらく定着して抜けなかったです。契約による設計に恨みがあって変な設計と言ってるわけではなく、私が脳内でよくわからない概念に囚われていただけです。

文芸的プログラミングに熱狂する

Knuth先生の文芸的プログラミングを知り、これしかないと悟り、すべてのプログラムを文芸的に書くことにしました。ところがまるでうまくいきません。半ば負け惜しみで言うと、文芸的プログラミングはそもそも常人には実践が困難です。

何度か試したあと、「これができるのはKnuth先生だけなのでは？」と悟り、飽きてやめました。

1バイトでも削らないと死ぬ

メモリ、ストレージリソースは貴重、1バイトでも削らなければならないという思いが強かった時期があります。なぜかはあまり覚えていませんが、恐らくは大昔の、本当に1バイトでも削るためにカリカリチューニングしていた時代の話に感銘を受けたのだと思います。

このような思いが強かった頃は、for文の添字となるi変数も「ここは高々数千回しかループしないので2バイトにする」「iは高々10なので1バイトにする」などと、どうでもいいところにこだわっていました。構造体をなるべく小さくするためのパッキングにも精を出していました。

悲しいかな、バイナリレベルの話に明るい人ならわかると思いますが、この自称チューニングはほぼ意味ないですし、大体の場合は害悪ですらあります。他にやることないのかと今なら思えますが、当時はこれが大事だったらしいです。

プログラミングの腕は上がりませんでした。しばらく変な癖が抜けませんでした。

おわりに

手段に囚われて意味のある実践ができてなくて迷走してることがありありと見て取れますね。こんな人でもなんやかんやで就職後にプロたちにしばき回されて一人前になれました。

まだまだネタは死ぬほどあるのですが、疲れたのでこれくらいにしておきます。

コーディングエージェントの登場後に読む本が変わった

Claude Code、Codex，Devinのようなコーディングエージェントが出てきてしばらく経ちます。その進化は著しいです。そんななかで私には、よく読むIT技術書の種類が変わるという大きな変化がありました。この変化について、および、その変化について思ったことを書きます。

前述したようにコーディングエージェントの進化は凄まじく、現在は次のようなコードであれば、振れ幅は大きいものの、並のプログラマーと同程度あるいはそれ以上のコードを書けます。

• よく使われている言語で書かれている
• この場合はこう書く、といったセオリーがある
• セオリーを外さないといけない特殊事情が無い
• 規模はそれほど大きくない

品質とは別の観点でいうと、生産速度は人間では到底太刀打ちできないほど高いです。そのままプロダクション環境に持ち込めるかというとそれはまた別の話ですが、ここではその話は置いておきます。

私はプログラマーとしては残念ながら並なので、一部例外を除くほとんどの場面では自分の出番はないし、今後その例外はさらに減っていくと思っています。一部のスーパープログラマーはさておき、このような思いを持っている人はそれなりにいるのではないでしょうか。

ここから本題の、本の話をします。私は仕事でも趣味でも寝ても覚めてもプログラミングをするようなタイプではないですが、コードを読むこと、プログラミングに関する本を読むのが好きでした。ところがコーディングエージェントを使うようになってからは、とくにここ最近は、IT技術に関する本の中で、プログラミングについての本を読むことがずいぶんと減りました。

なぜだろう、と考えたところ、興味の対象が気づかない間に大きく変わっていたことに気づきました。「もうコードのことは考えない。考えなくていい。全部AIにお任せ」なんてことは全然考えていませんが、何か知りたいときは初手で本を読むのではなく、生成AIに質問するようになりました。回答を得るとソースも聞いて公式サイトやソースコードにあたって裏取りをするだけです。ソースを読むときもエージェントのお世話になります(もちろん最後の裏取りはします)。これで終わりです。本を読むこともありますが、登場機会はずいぶん減りました。今後私がプログラミング言語、特定のフレームワークやライブラリの入門書を買うことはほぼ無いでしょう。

最近プログラミングについての本のかわりに読んでいるのは、組織、プロダクト、開発手法、要求定義や設計といったことについての本です。昔はどちらかというとこの手の本は敬遠していましたが、今はとても楽しく読めています。前述のように、立場上必要になっていることもありますが、このようなことを学ぶとコーディングエージェントにいいものを作ってもらえる可能性が上がり、今よりさらに楽ができるという理由も大きいです。私は楽をするのが大好きなので、それを助けてくれるものには、いつだって興味津々です。

このような現状をどう思うかというと、「悲しくはないが少し寂しい」といったところでしょうか。もともとコーディングはモノづくりの手段という考え方だったので、モノづくりについては苦手なところを楽できてラッキーといった気分です。しかし、過去のある時期までは情熱を燃やしていたコーディングが、これほど短期間に、ここまで私のなかに占める割合が下がるとは思ってもみなかったです。大量に積読状態になっているプログラミングについての本も、ますます積む時間が長くなりそうです。寂しい。

最後に、今でもこれから読みたいIT技術書は何かについて、思ったことを書きます。生成AIはどれだけ賢くてもあくまで特定個体ではなく集合知なので、筆者以外に誰に聞いてもわからない、個人が生で体験したことや思ったことが書いてある本をもっと読みたいと考えます。有り体に言えば顔が見える本がいいなと思います。自分も本を書くならそんな本を書きたいものですね。

小学生向けキャリア教育資料の学生向け再構成版

今年の2月に息子の小学校でキャリア教育の一環として講義をしてきました。本記事はこれを中高生以降で社会に出ていない人向けに再構成したものです。対象読者は学校での勉強が将来の自分のキャリアにどうつながるのか気になっている人です。

speakerdeck.com

はじめに

わたしはソフトウェアを使ったサービスを提供している会社で働いています。提供しているサービスを直接作っているわけではなく、そのようなサービスを動かすためのインフラ基盤と呼ばれるものを作ったりしています。他にも本(例)や記事を書いたり、英語の書籍を日本語に訳したり(例)しています。専門分野についての知見を共有するYouTubeもやったりしています。

この記事は、わたしのこれまでの経験を通して、みなさんが将来歩んでいく自分自身の道を見つける手がかりの一つになってもらうことをねらっています。話の構成は次のようになっています。

1. どんな仕事をしているのか
2. わたしが歩いてきた道
3. 学校で学んだこととの関係
4. アドバイス
5. まとめ

わたしは上述した通りIT技術者ですが、細かい技術の話はしないので、私の専門分野であるITに明るくない人も読めるようにつとめて書きました。

どんな仕事をしているのか

わたしはソフトウェアを作るプログラマーです。他にも色々なことをしているんですが、本記事の主題からは外れるので省略します。コンピュータに関する仕事というおかげもあって、会社に出勤することはほとんどなく、自分の家で働いています。といっても一人で仕事をしているわけではなく、日本中の色々なところにいる同僚たちとインターネットでコミュニケーションをしながら物を作ったり、作ったものを動かしたりしています。

会社の仕事では自分の会社の人とだけ話しているわけではありません。といっても、会社のサービスを使われているお客様と話すわけでもありません。GitHubというインターネット上のサービスを使って世界中のソフトウェア開発者と共同でものを作ったりしています。以下は開発のやりとりの例です。

github.com

社内の人とコミュニケーションをとるときはほとんど日本語を使いますが、社外の人とコミュニケーションをとる場合は英語を使います。

本や記事を書く仕事も、ほとんどはインターネットを介して関係者とコミュニケーションをとります。関係者は出版社や、そこに所属している編集者などです。洋書を和訳する仕事も、同じく出版社や編集者とやりとりすることになります。

ここで強調したいのは、これまで述べたすべての仕事においてチームワークがとても大事なことです。なぜなら、多くの場合、わたし1人では仕事が完結しないからです。「仕事が完結」という言葉の意味は、ここでは私が仕事の対価としてお金をもらえることだとしましょう。会社の仕事の場合は次のようになります。

1. 私が同僚と一緒にソフトウェアを作る
2. 会社の他の人がソフトウェアを使ったサービスを売ってくれる
3. サービスを使ったお客様が会社にお金を支払ってくれる
4. 会社がお金の一部を私に給料として支払う

本当はもっともっと複雑ですが、簡略化するとこんなものです。わたしは1人だけでソフトウェアを作れませんし、作っただけでは誰にも使ってもらえなくて、そこで終わりです。

本や記事を書く場合も、わたしが作文しただけでは何も生まれません。わたしが書いた文書を読みやすい文書として編集者が磨き上げ、印刷し、書店に配本し、誰かが買ってくれて初めてお金に変換されます。それが出版社に戻ってきて、はじめて私にお金が入ってきます。

稀にほとんど自分だけでなんでもやってしまう人がいるのは否定しませんが、ほとんどの人はこのように自分以外の多くの人と協力しながら仕事をし、対価を得ています。

私が歩いてきた道

前節では、わたしが今どんなことをしているかについて紹介しました。ここからは、子供のころから何を考えてどういうことをして今に至ったのかを紹介します。ときどき、「ここでこういうことをしたから次につながった」というような事も書いています。

小中学生の頃はゲームが大好きで、そればっかりやっていました。あるときから自分でも作ってみたいと考えるようになりましたが、思ってるだけで、どうすればそんなことができるかはわかっていませんでした。親はさぞかし心配していたことでしょう。

高校生のころ、家でパソコンを買ったことが転機となりました。しばらくはパソコンでゲームをするのに勤しんでいたのですが、あるときからゲームを作るようになりました。たくさん勉強して、だんだんうまくできるようになってきたのに気を良くして、このままゲームプログラマーになろうと固く決意しました。

ゲームプログラマーになるために大学の情報工学科に行けばいいんだろうと固く信じて*1受験したものの、残念ながら受験は失敗しました。バイオハザードとゼルダの伝説 時のオカリナで遊ぶだけで手いっぱいで受験勉強をしている暇がなかったのが敗因でした。

ここで奇跡が起きて同じ大学の材料工学科という学科に受かり、そのまま大学院まで材料工学を学んでいました。学部生のころはゲームを作っていたのですが、大学院のときに転機が訪れました。ゲームよりも、ゲームを、そしてコンピュータそのものを動かすためのオペレーティングシステム(OS)というソフトウェアに興味が移ったのです。このころは大学院の勉強をするかたわら、ひたすらOSの勉強をし続けていました。あまりにも面白かったので、あるとき「OS開発者として食っていく」と決意しました。良く決意する人ですね。単純なんです。

大学院1年になり、そろそろ就職について考えなくてはならなくなりました。わたしは向こう見ずな性格ですが、材料工学を学んでいる人がいきなり「OS作りたいです」と言っても多分相手してもらえないだろうなとは思っていたので、OSの開発をしていた会社のインターンに参加して、そのままその会社に入りました。これは大学で希望している学科に落ちてもプログラミングを続けて、大学で真面目にOSの勉強をしていたからこそ実現できたと思っています。

その後10年くらいは世界一のOSのプログラマになろうと日々勤しんでいました。OSについての本を書いてみたいなと思うようになったのもこのころです。この後に人生を大きく変える3つの出来事がありました。

• 世界一のOSプログラマになるのはさっさとあきらめました。自分が足元にも及ばないような凄い人たちが世界にはゴロゴロいるのを見て、とても敵わないと判断したためです。
• 結婚して子供が生まれて、一番大切なものがIT技術から妻や子供に変わりました。自分以外のことが最優先になるのは人生初の出来事でした。
• 世界一のOSプログラマになるのをあきらめたこととも関係しているのですが、会社を辞めました。

会社を辞めた後は、前々から持っていた「本を書きたい」という思いを実現すべく、知り合いの編集者を介して出版社にお願いして、本を書いてもよいということになりました。無職だと書ける時間が多いので、幸いにも数か月で書けました。自分の成果物が書店に並んでいるのを見た時は強い達成感がありました。ここで重要なのは、自分でお願いするというアクションを起こしたことです。思いがあるだけでは実現はしないし、実績も知名度も無いわたしに先方から声がかかるなんてことはありません。

その後なんやかんやあって今の会社に入社しました。過去にわたしがやっていたことがたまたま今の会社の人の目に留まっていたこと、そして何より無職でフラフラしていたことがきっかけです。人生何があるかわかりませんね。

学校で学んだこととの関係

ここからは小学校から大学院まで、学校で学んだことが今の仕事にどのように関係しているかについて書きます。

プログラミングの仕事については、作りたいものを考えて、動くしくみを考えて、それを実現するコードを書いていくという過程で数学の考え方が役立っていると思います。これらについて勉強するときには国語能力が必要です。また、プログラミングについては英語の情報が多いので、英語能力も必要です。

本を書く仕事でいうと、作文するときにはIT技術に関する知識だけではなく、国語能力が必要です。頭の中では完璧にわかっていたとしても、それを人に分かる形で文書として出力できなければ書籍にはなりません。また、洋書を和訳するときは国語力、英語力、両方が必要です。

既に述べたように、プログラミングをしようと本を書く仕事をしようとチームプレーが大事です。このような時には自分の思いを相手に伝えたり、相手の思いを理解したりするために国語能力が必要です。相手が日本語話者でなければ多くの場合英語能力があるとよい*2。勉強だけではなく、授業の時間以外にクラスのみんなやバイト先の人々と過ごして、好きな人とも嫌いな人とも一緒になって何かする経験というのも将来のチームプレイの予行演習になるでしょう。

今はやっていませんが、昔ゲームプログラミングをしていたときはキャラクターに自然な動きをさせるために物理の知識が役立ちました。また、3D描画エンジンを作っていたころは数学行列演算の知識が大きく役立ちました。

人生は仕事ばかりではありません。わたしは息抜きのために歴史の本を読むのが好きなのですが、そうなったきっかけの一つは社会の歴史の授業です。また、日本という国を動かす仕組み、自分がその仕組みの一部として参加できること、その参加方法の一つが選挙であることを社会の授業で学んだため、世の中をよくするために選挙に行くようになりました。有権者は1億人くらいいて、わたしの力はそのうちの1人分にしかすぎませんが、それでも意義があると考えています。

ではみなさんは、今後わたしのようにプログラマーや本を書く人になるために「国語」「英語」「数学」「物理」「社会」を学べばいいのでしょうか。それは違います。みなさんとわたしは、やりたいこともできることも、置かれた環境も全く違います。何をするかは、これからみなさんが自分で決めるのです。

アドバイス

みなさんには、とにかく色々なことをやってみて、まずは自分自身のことを知ってもらえればいいかと思います。以下に例をいくつか挙げましたが、他にもパターンはいくらでもあります。

気を付けてほしいことについても書いておきます。「自分」というのは時間が経つと、どんどん変わっていきます。「今」できないとわかってあきらめたことも、後でできるようになっているかもしれません。「今」楽しくないことがわかったことも、あとで楽しくなるかもしれません。逆もまた然りです。また、やりたいこと、できることが今は無くても全く構いません。ほしくなったらすぐできるようなことは稀なので、焦る必要はありません。できることは最終的に何かしら一つはあるといいですが、やりたいことについては何もないまま不便なく暮らしている人なんていくらでもいます。

ここからは「学校の勉強は将来の役に立つのか」という話をします。これは一概には言えないんですが、わたしは「やりたいことをするために学力が必要になることがあるならやっておくとよい」「他にやりたいことがないならやっておくとよい」という考えを持っています。まず、学力があれば色々なチャンスを掴みやすくなります。受験や就職といった人生の様々な場面で学力を基準とした審査があります。良かれ悪しかれ世の中の多くの場面では学力があれば道が拓けやすいようになっています。また、とりあえずやっておくと、興味のあることが見つかるかもしれません。何もしていなければ見つけようがありません。

まとめ

本記事ではわたしの小学生のころから社会人になって今に至るまでの道のりについて話しました。皆さんはこれからわたしとは違う道を歩んでいきます。みなさんのクラスメイトとも違う道を歩んでいきます。色々な経験をして、どのような人生にするかを自分で決めてください。よくわからなければ、とりあえず「良く学び、よく遊ぶ(経験する)」で良いと思います。

以上。

*1:のちに、大学の情報工学科は別にゲームプログラミングを学ぶ場所ではなく、もっというとプログラミングを学ぶことが主目的でも無いことを知りました

*2:場面によっては中国語などの別の言語が必要になるかもしれません