書籍を使った勉強のしかた
わたしがこれまでに書籍でなにか新しいことを学ぼうと思ったときにどういう手段で目的を達成してきたかについて書きます。生業にしているIT系のこともそうですが、それ以外も同じ方法を使っています。
はじめに書いておくと、これまでの自分自身の体験や優秀な人の観察などから、学習の原則コツコツと反復練習を続けることであり、近道は無いと思っています。原則を守るための典型的な方法の一つが「網羅的に書かれた決定版と呼ばれる本を何度も精読する」です。これができる人はこうしたほうがいいと思いますし、ここから先を読む必要はないです。しかしながら、わたしはこの方法がうまくいったためしがないので、自分なりに工夫して、金銭的コストがやや高いながらそこそこうまくいく方法にたどり着きました。本記事ではこの方法を紹介します。
わたしは何かを理解しようとするときには、まずは初心者向きのページ数が少なくて読みやすそうな本をたくさん買います。そのジャンル名、および「参考書」などというワードで検索するとまとめサイトの一つや2つはひっかかります。そこにあがっているもののからフィーリングで5~10冊くらい買って、読みふけります。ページ数が少なくて読みやすいがゆえにサクッと読み終えられて達成感が得られます。そのまま勢いに乗って全部読み終えるまで続けます。
これらの本を読んでいるときは一字づつ噛みしめるように読むのではなく、ほぼ流し読みです。200ページくらいの本なら30分から1時間位で読み終えます。読んでいるうちになるほどと思ったようなキーワードがあれば覚えておきます。「この本なんかおかしなこと言ってるな？」となれば最後まで読まずにその本は即座に切り捨てます。
何冊か読んでくると重複する内容が増えてきます。これによって、本を書くほど詳しい人の多くが言及するほどの「その分野のとても大事なところ」が浮かび上がってくる、かつ、そのようなところを自然と復習できるという利点があります。
乱読が終わった後は気になる本を再読するなり定番本に移行するなりします。ここまで来たら同じ分野の本を読む勘がつかめているので決定版的な本を読む苦労は最初から読む場合よりは全然少なく済みます。また、ここまで来て全く興味がわかない場合はどうしても学ばなければならない場合を除き、今の自分には必要ない知識だと割り切って学習をやめます。
この方法はたくさん本を買うので金銭的コストは高くつくのですが、すくなくともここ十年ほどはうまく機能しています。なかなか学習がうまく行かないという人は一度試してみてはいかがでしょうか。
おわり
一時的に無職だったころを思い出す
前職を辞めてから今の会社で仕事をはじめるまでの数か月間、まったく収入の無い無職でした。ふとそのときのこと振り返ってみたくなったので書きます。とくに悲壮感に満ち溢れていたり、面白おかしかったりはしない話です、これから無職になりたい人とかなりそうな人にはもしかすると参考になるかもです。
無職になってから数か月は本当に何も収入が無かったです。びっくりしたのは何も悪いことをしていないのに毎月お金が減ることでした。これはふざけて言っているんではなくて当時の偽らざる思いです。長期間食っていくだけの貯金はあって金銭的には余裕があったはずなんですが、これまで毎月増えていた持ち金が突然減りだしたので「このままでは減っていく一方」「これが尽きたら死ぬかもしれない」という感覚が出て、なかなかスリリングでした。定期収入大事。
お金が減るスピードもなかなかのもので、前年の収入を基準に支払額決まる住民税や国保はえらく高く感じてびっくりしたものです。給与からの天引きではなく自分で払い込むのでさらにダメージが大きかったです。どっちにしても払ってるのは変わらないんですが不思議なものです。
次は「何をしていたか」の話。しばらくは何もせずにごろごろしてようとか思ってたんですが、当時は何か頭を使っていないと落ち着かなかったので、新しいことをしようとハイスペックなBTOパソコンを買いました。そしたら運悪くハードウェアのバグっぽいものを引いてしまい、数か月にわたってひたすら原因究明するはめになりました。これまでに培ったスキルを活用できて、かつ、少なからぬ人の役には立ったはずだったのですが、別に誰と何を契約していたわけではないので当然一銭も入らなかったです。このときに「お金が欲しければちゃんと技術をお金に変換する努力をしないとなあ」と、しみじみ思いました。
この考え方は、のちに個人事業主(今は会社員との複業)になったときや再就職したときに大いに役に立ちました。あと今になって振り返ると、もっとダラダラしておけばよかったです。数年経って成長した今ならきっちりダラダラできそうな気がします。次に無職になったときは頑張ります。
続いて、前職在籍中に会社員として出会ってきた人たちとのその後の関係について。よく「会社員の看板が外れた瞬間に人は去っていく」という話がありますが、私はそういうことは全くなかったです。これには仕事を通じて知り合った人々はほとんど全員OSS開発者だったことも関係しているとは思いますが、彼らは会社員としての私ではなく、私自身になんらかの価値を認めていてくれていたということなので、とても嬉しかったです。
最後に「その後」の話。もともとは共働きだったこともあって「これからは一生無職で食っていく」と決意していたのですが、幸運にも自分を気にかけてくれる人や必要としてくれる人がいたりで、その後はなんやかんやと今勤めている会社に縁ができて、その後社員になって今に至ります。これについては「技術を磨いておいてよかった」「少なからず自分や自分が持っているものについて情報発信しておいてよかった」「必要以上に敵を作るような振る舞いをしていなくてよかった」などと思いました。
おわり。
ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい 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:今の基準でもですが
