企業が誰を雇うかなんて企業の勝手だよなと思う

動機

先日転職活動をしました。
転職活動中で相手先企業からの質問や選考基準について疑問を抱くことがありました。

なので、これから個人的に納得いかない求人側企業の採用方針について書いていこうと思います。

主張

ですがその前に、大前提として『企業が誰を雇うかなんて企業の勝手だよな』という意見を言いたいと思います。

理由

突き詰めれば、採用活動というのは株主のためにするものだと思います。
だから、どんなに不合理・非常識・不道徳な採用活動をしようと、求職者や一緒に働く従業員に対して何の責任もないという事です。
あくまで本質的には『経営者は株主に対して、良い採用活動をする責任がある』だけです。

なぜそう思うかというと、僕は基本的に『常識は間違っていることもある』と思っているからです。
「一般的にはAをしたほうがうまく行くと思われているが、Bのほうがうまく行くのではないだろうか」と思わしい事ってたくさんあります。
それがただの勘違いで本当にAが正しかったこともあれば、時にはBでうまく行くこともあります。

だからこそ、特にルールに反しない限りは、自分のお金で挑戦する限り周囲は口を出さないべきだと思っています。
お金も出さないのに口だけ出す人は最悪ですからね。

例えば、想像ですが誰かが最初に自動車を作り始めた時、絶対みんなは「馬車のほうがよくね？」って思ったとはずです。
自動車を作っている人は「いや、馬車作れよｗ」って煽られながら作っていたんだと思います。

こういうのを愚行権というのでしょうか。
周りに反対されても自己責任で挑戦する権利があると思います。

だから、僕はいろんな企業の採用を見て「不合理だな～」と思いましたが、
不合理な採用戦略をとるのも企業の勝手だと思っています。

僕はプログラマーなので、「そんなんでは優秀なプログラマーをとれないぞ……」と思うことが多かったのですが、
彼らには彼らなりの価値基準があり、それを信じて挑戦する権利があるのだから、
周りが否定するすることではないと思います。

自動車を作りたい会社に馬車職人が応募して落ちて、周りが「あんなに腕のいい馬車職人を落とすとは何事だ！」とか言っても、自動車会社の人がかわいそうなのです。

結論

多くの企業の採用方針はかなり不合理に感じるが、
それは彼らなりの理由があってそうしているのだから、
他人が口出すべきではないという話です。

もちろん、僕も多くのIT企業の面接や採用試験で不合理だと感じましたが、
それは僕が文句を言う事ではないです。

そのうえで、『でも不合理だとは思うよ』と思った話をこれからしていこうと思います。

僕を雇うにはどうすればいいのか

最近Clubhouseでいろんな会社さんが採用イベントしてますね。

それ以外にも、色んな機会に各社の人事さんやソフトウェアエンジニアさんから、求職者の気持ちを聞かれます。
せっかくなので、自分はどのような観点で会社を選んでいるかについて書いてみようと思います。

ただし、同業者さんたちに話を聞く限り、僕は結構少数派だと思います。
あまり鵜呑みにしない方がいいかもしれません。

あ、あとあんまり触れないですが給料は重要です。

重視すること

• 困っているのはだれか
• その問題に本気で向き合っているか？

あまり重視しないこと

• 使っている技術
• そこで自分が何を担当するのか
• 福利厚生
• オフィスの綺麗さ

誰が何に困っているのか

誰が何に困っているのかという問題意識が一番大事だと思います。

これにはいくつかのとらえ方があると思います。

例えば、『社会のこういう属性の人は○○という問題で困っている。だから××という事業をする』というのは良いです。
また、『この会社は○○に困っている。だから技術部門で××をしてほしい』というのもよいです。
もう少し小さく、『この会社の技術部門は○○という問題を抱えている。だから君に××してほしい』などもよいです。

その問題に本気で向き合っているか？

困っているといっても、それが口先だけで本当は大した問題だと思っていないケースもあります。
だから、僕はどの程度本気で向き合っているかを見ます。

例えば、「うちのチームは人手不足で困っています」という人がいたとします。
さて、困っているなら困っているなりにやることがあると思います。

採用を強化したいなら、ブログを書くとか誰かが登壇するとかイベントのスポンサーブースを出すとか、何かできることがあると思います。

また、少ない人数でも仕事ができるようにするため、それぞれが技能向上に努めているとかでもいいです。

僕はNASAの掃除係のエピソードが好きです。
知らない人のためにざっくり説明すると、『NASAの掃除係が、通りがかった大統領に「あなたは何をしているのですか？」と聞かれて、「人類を月に届けるお手伝いをしています」と答えた』という話です。

それぞれの人にはそれぞれの能力があります。
誰であれ自分たちのゴールをよくわかっていれば、自分のやるべきことを一生懸命にやるはずだと思います。

僕は自分自身がそうありたいと思うし、周りの人に対してもそれを求めます。

その人が何を担当しているかは関係ありません。
どれだけ自分の持ち場に責任感を持っているかの問題です。

結論

僕は誰のために自分の能力を使うべきかという軸で仕事を選びます。
そして、一緒に働く人に対しても同じ熱意でその問題に向き合ってほしいと思います。

採用イベントなどをする際はそのあたりを話すと興味を持ってくれる人が増えるのではないかなと思います。

とある天才プログラマーの自己紹介

目的

最近ずっと転職活動をしていました。
もう終わりました。
だんだん自己紹介に慣れてきたので、ブログにも書いてみました。

概要

プログラマー（ソフトウェアエンジニア）28歳。
現在株式会社CURUCURUというレディースゴルフウェアのECサイトの会社で働いています。
７月から次の会社で働くはずです。

職務経歴

1. 子供の頃からプログラミングが得意でした
2. 最初はプログラミング以外の仕事に就きました
3. プログラマーになりました

特技

• SPAづくり
• ドキュメントづくり
• プログラミングの速さと正確さ

モチベーション

• 誰かの役に立ちたい

職務経歴

幼少期

子供の頃からプログラミングができました。
ひらがなを書けるようになる前にキーボードを打てるようになったそうです。
プログラミングを覚えたという記憶がありません。
多分生まれつきできたんだと思います。

きっと誰の脳にもプログラミング野みたいなものがあるんだと思っています。そこにBASICとかC言語とかを学習させるとコードを書くようになるんだと思います。
だから『プログラミングを覚える』というのはいささか表現が違うと思っています。プログラミング言語は覚えなければいけないけど、プログラミングは誰しも元々できるものだと思っています。

高校生の頃の思い出 クラス内情報共有ツール作り

高校生の頃はクラス内の掲示板みたいなものを作っていました。
その頃、高校生たちが使えたWebブラウザはガラケーとPSPしかありませんでした。だから、それに合わせてCSSを書きました。JSはほぼ使えませんでした。
時間割表や宿題の締め切り情報などをクラスのみんなで共有する目的で始めました。
その掲示板にはカレンダー機能や画像うｐろだ機能もありました。
今で言えばGoogle Driveやサイボウズのようなコラボレートツールに仕上がって生きました。
割とみんな入り浸ってましたね。
この頃から僕は一貫して、ITを使ってチームの生産性を高めるということをやっています。
ちなみにシステム構成は大体『さくらのレンタルサーバー+PHP』または『さくらのVPS+サーブレット』でしたね。

高校を卒業して郵便局で働く

ということで、高校を卒業してひとまず郵便局で働き始めました。
ちなみに僕は簿記三級を持っています。えらい。

なぜこの時プログラマーとして就職しなかったのかが最大のミステリですね。
そもそも、僕にとってプログラミングは趣味でした。
なのでそれを仕事にするという発想もありませんでした。
本格的なシステム開発なんて言うのはどこかの大きな企業がするものだと思っていました。

でも、ここで働くことで逆にプログラマーとして働く意欲が高まりました。
なぜならば、この会社の業務がどれだけ非効率か知ってしまったからです。
僕が働いていた間だけでも大掛かりなシステム刷新が数度あったのですが、問題が根本的に解決することはなく、むしろ悪化していました。

毎日面倒な作業をしながら自分ならどうやってこの会社の業務を合理化するか考えていました。
想像しているだけで楽しかったです。
そして次第にそれを実践したくなりました。

輸送会社のソフトウェアエンジニアになる

20歳の時僕は始めてプログラマーとして働き始めました。
システム開発会社に就職するつもりはありませんでした。
その辺のシステム開発会社より僕一人のほうが強いと思ったからです。
僕が中から業務を全部まるごと合理化してしまうのが一番早いんだと。

名古屋の小さな運送会社に就職しました。
そこは何もかも電話と手書きで回っていた世界でした。
（一応お付き合いのあるシステム会社がありましたが関係は良好ではありませんでした）

勝算はありました。
2010年前後はHTML5やクラウド、スマートフォンなどプログラミングスキルを生かしやすい環境が整いはじめていました。
それまで一人のプログラマーが成し遂げられることが10だとしたら、同じ能力で100のことを成し遂げられる時代になっていました。

だから僕はやりました。
その会社には数千万かけたという業務システムがありました。
ざっくり言って、オペレーターさんがお客から受注して入力すると、運転手さんにやるべき事が通知されるというシステムです。
僕は入社から数ヶ月でそれより高性能で高品質な業務システムを作って置き換えました。
技術的にもよくできていました。
動作がとても速いと評判でした。
実際の仕事を見ながら作ったので、現場にしっかりフィットしました。
業務の流れをちゃんと把握して全体を最適化する方針を押し通したので、会社の業務全体が合理化されました。
経営陣も、業務の状態がリアルタイムに見られると喜んでくれました。

ヘルプデスク

満足したので転職しました。
愛知県の大手自動車部品メーカーのヘルプデスクの業務をしました。
そもそも、僕はヘルプデスクをやるとは聞いていませんでした。

僕が入社したのはいわゆる業務委託と派遣の会社でした。
入社時に聞いていたのは開発の業務だったのですが、最初の配属先がそのヘルプデスクでした。

まあ、仕事はなんであれ一生懸命やるタイプなのですが、残念ながら腹立たしい思いをしました。
その配属先の自動車部品メーカーでは、半人前の人がまずヘルプデスクなどの運用業務に入り、経験を積みながら開発業務や管理業務に配属されていくという流れがあるようです（厳密なことは知りません）。

そんなことは知らず、なんとなく「開発がやりたいんですよね～」と口にしたところ、それを聞いていた先方の社員が何かにつけ「そんなんじゃ開発に行けないよ^^」などといびってくるようになりました。
向こうは僕のことを能力が半人前で丁稚奉公させられてる人だと思ったようです。

うっせえわ。あなたが思うより天才です。

レディースゴルフウェアのECサイト

という事で転職しました。

新しい職場はレディースゴルフウェアのECサイトです。

僕はすぐにこの会社が好きになりました。
一緒に働くみんなが真面目で、挑戦的で、お客さんに誠実で、会社のみんなに親切で、謙虚で、勇敢な人たちだったからです。
僕は自分の恵まれた能力をこの人たちと、そしてそのお客さんのために使ってほしいと思いました。

僕はゴルフをしたことはなかったのですが、要するにこういう事だそうです。

ゴルフというのは男性人口が多いスポーツでした。
なので女性にとってはゴルフウェアなどの市場が発展せず好みのゴルフウェアが少ないという問題がありました。
そこで、ゴルフが好きな女性の一人がレディースゴルフウェア事業を始めました。それが弊社社長です。という事だそうです。

まあ、正直毎日ユニクロで生活している僕にはそれの何が問題なのかよくわからないのですが。

とりあえず本人たちが困ってるというのだから困ってるのでしょう。

この会社でいろんなことをしました。
会社の業務管理システムの刷新やECサイトの商品検索機能の開発などです。

中でも大きな成果を上げたのはECサイトの速度改善です。

まず、GoogleのPageSpeed Insightsを毎日チャットに投稿するものを作りました。
そこから、超速本にあるような改善を一個ずつやっていきました。
PageSpeed Insightsの採点は30点台から(Google Analyticsを除いて)95点くらいに上がりました。
すごい。

特技

僕のプログラマーとしてのスキルは主に三つあります。

SPA作り

運送会社のシステムを作ったときからSPAを作っています。
当時はそんな言葉なかった気がします（あったかもしれないけど）。
その当時のWebの表現力を考えてそれが一番合理的だという結論にたどり着きました。

別に流行にあてられてSPAを始めたわけではありません。
JSPやPHPなどサーバーサイドでHTMLを組み立てる系の手法を一通りやった後、自力でSPAという考えにたどり着きました。
それでうまく行っているのである程度僕のいう事には信ぴょう性があると思います。

SPA作りが得意といっても、フロントエンドエンジニアというわけではありません。
SPAを活かすためのサーバーサイドの作り方やログの出し方など、全体に詳しいとお考え下さい。

ドキュメント作り

狭義の技術とは言わないかもしれませんが、ドキュメントを書くのが好きです。
会社では図書委員と呼ばれています。
ちなみに、一時期Zennで流行った『保守性の高いソフトウェア開発のTips集』を書いたのは僕です。
あれはもともと、インターン生向けに僕がどんなことを意識して開発しているのかを纏めたものが土台にあります。

速さ・正確さ

プログラムを書く速さと正確さはよっぽどだと思います。
これは僕と一緒に仕事をしたほぼ全員がそういうので間違いないと思います。
競技プログラミングでも、難問はなかなか解けないものの、簡単な問題を超高速に解くことで高順位に入っています。

モチベーション

基本的に誰かの役に立てるかどうかで動くタイプです。
あの言語が使えるからといったことで仕事を選ぶことはないです。

それゆえ、業務知識を重視するタイプでもあります。
僕は最初に運送会社に入ったときは、運転手さんの車に乗せてもらって業務を勉強したりしました。
ゴルフウェアの会社に入ったときも、もちろん倉庫の仕事を手伝ったりゴルフを始めたりしました。
思えば、高校生の時も自分の高校生活を楽にするために掲示板を作っていました。

今後

とりあえず転職先は決まりました。
少なくとも入社後半年くらいまでは親しい人にだけ伝えることにしようと思います。

なぜ『ネットで政治が良くなる』は幻想だったのか。そして解決策案。

 

昔、政治と民意についてこんな話を聞いたことがある。日本医師会の会員数と妊婦さんの数はだいたい同じらしい*1。日本医師会は国政に絶大な影響力を持っているのに、妊婦さんの意見は通り辛い。それは何故か考えてみましょう。という話。

さて、10年前にはこれからネットで日本が良くなっていくという希望があった。
Twitterなどでみんなが自分の意見を自由に発信できるようになったからだ。

しかし、それは幻想だった。
人々が好きなことを発信できるようになったからといって、急に世の中がガラッと良くなることはなかった。

いくつか、ネットで政治を良くしようみたいな活動をされている人を見掛けるのだが、あまり応援する気にはならない。
『ネットで自由に意見を言えるようになったところで、それだけでは足りない』ということに気づいていなさそうだからだ。

僕は三つの課題があると思う。

1. 正しいことを言うのは難しい
2. 仲間を集めるのは難しい
3. 意見が違う人と話し合うのは難しい

正しいことを言うのは難しい

何かを変えたければ自分の困りごとを『証拠に照らして』『緻密な論理展開で』言葉しなければいけない。それは高等技術だ。殆どの人はそんなことできない。ということは、その気になればどんな意見であっても「お前は間違ってる」で片付けることができてしまう。それはよくないと思う。

よくTwitterで社会に対する不満を見かける。
本人は勇気を出して声を挙げたのだ。意見には誠意を持って耳を傾けるべきだと思う。
にもかかわらず、引用欄を見ると事実誤認や論理の飛躍を指摘して冷やかしている人がたくさんいる。ちょっと冷たいなと思う。

とはいえ、僕は発言者が弁論の素人だからといって事実誤認や論理の飛躍が含まれる主張を無条件に受容するべきだとは思わない。
みんなの事は出来る限り正確な情報と論理的思考に基づいて決めるべきだ。

僕はこの『ちゃんと意見を言うのは難しい』『ちゃんとしてない意見を受け付けるべきではない』『でもみんなの意見を聞きくべきだ』という相反する問題について考えている。

仲間を集めるのは難しい

さっきの医師会と妊婦さんの件はこれらしい。一度医者になった人はずっと医者だが、妊婦さんは１年で妊婦さんではなくなってしまうから、組織力に差が出てしまうという話らしい。

Twitterでも、同じ問題意識を持っている人同士でもっと積極的に連帯していこうという話にはなりづらい。
なったとして、すぐに変なカルトが出来るだけだと思う。

僕も経験がある。
とある『良くないことをしている政治家』をTwitterで批判したことがあった。
すぐに、同じようにその政治家を否定している人たちと対話が始まった。
最初のうちは同じ意見を持っている人同士で話が合うと思った。
ところがそうはいかなかった。
僕はその政治家がしたAという行為は良くないと思ったが、Bという行為は別に問題ないと思った。
その人たちにそう伝えた。
そうしたらその人たちがキレだして、複数人から『なんであんな政治家を擁護するんだ』とか『お金を貰ってるのだろ』とか言われて不愉快な思いをした。
もうこの人たちには関わらないでおこうと思ったし、政治についてTwitterに書くこと自体が不利益だと悟った。

自分の意見を世の中に伝えていくには、どうしたって同じ意見を持つもの同士で寄り添う必要がある。
断っておくが、少人数の意見だから黙殺していいとか、大人数の意見だから採用するべきだとかは思っていない。
しかし、現実問題として同じ意見を持つもの同士でまとまらないと政治力にはならない。と同時に、同じ意見を持つ人同士でまとまるのは面倒事が多い。

よって、ある程度責任ある立場の人がハブになってくれたほうがいいと思う。
少なくとも近しい意見を持っているからと言って一般市民同士が無理対話しなくてもいいようにするべきだ。

意見が違う人と話し合うのは難しい

もし僕が正し意見を持つ側だったとしても、口喧嘩の相手が西村博之さんなら絶対に自分が言い負かされる自身がある。

意見の中身ではなく口の達者さで勝敗が決まってしまうなら最初から話し合う意味がない。

ちゃんと弁論について訓練を受けた人同士が論を戦わせたり、時には譲歩し合ったりして話を決めるべきだと思う。

以上が、僕の問題意識だ。

この先の民主主義はどうあるべきか

僕はこんなシステムだったらいいと思う。

まず、自分の意見を代弁してくれそうな人を見つけ訴え出る。ここは拙い言葉でもいい。
依頼を受けた人は、論理武装して国会で弁舌をふるう。
その人に思いを託した人がどのくらいの人数いるのかがちゃんと可視化される。

こういうシステムだったらいいと思うし、それを支援するITシステムがあったらいいと思う。

*1:いま確かめてみたら数字が合わなかったのでちょっとニュアンスが違ったかもしれない

好きな技術書ランキング

好きな技術書ランキングを発表するのが流行ってるらしいので便乗します。

もともとは初心者の時に役に立った技術書とかいうトピックだった気がしますが、この際どうでもいいや。

ジョー・セルコ『プログラマのためのSQL』

この本に書いてあるのはSQLの事ですが、しかしプログラミング全般に役立ちます。
僕がこの本で学んだのは、プログラムは処理ではなくて宣言だという事です。

まず、どのプログラム言語にもその言語を司っている設計思想があります。
だから、それに合わせたコードを書くべきです。
そして、言語にはセマンティクスが用意されています。
ただ漫然と動くコードを書くのではダメなのです。
その言語のセマンティクスを理解し、それを使って自分の意図をコードで表現することもプログラミングの大事な側面です。

ということをこの本が教えてくれました。

GoF『オブジェクト指向における再利用のためのデザインパターン』

一般的にデザパタ本と呼ばれている本です。

大体の言語にはinterfaceという機能がります。
これほど使い道がよくわからん機能もなかなかない気がします。

extendsはわかりやすいです。処理を共通化できるから。
それに比べてinterface単体では処理を共通化できず、一体お前は何がしたいのだと思います。

しかし、実際にはextendsを多用するとすぐにコードが汚れてしまいます。
反面intarfaceを（上手に）使ったコードの共通化はあまりコードが汚れないです（上手にやれば）。

初心者の方はぜひこのデザパタ本を写経するといいでしょう。

この本に書いてある内容は古く、現代では通用しないという事で多くの人の意見が一致しているようです。
僕もそう思います。
この本の内容は役に立ちません。

しかし、interfaceを何に使うのかを理解するうえで一番いい本だと思います。
どうしたらコードを汚さずに処理を共通化できるのか、ノックだと思ってやってみるといいと思います。

戸根勤『ネットワークはなぜつながるのか』

ネットワークスペシャリストが自信をもってお勧めできる、
最もわかりやすくネットワークの初歩を教えてくれる本です。
ソフトウェア開発をしていて、ネットワークについてほとんど知らないわけにはいかないと思います。
とはいえWeb系の開発者であればネットワークにめちゃくちゃ詳しい必要もないと思います。

その点この本は粒度が最適だと思います。
この本を読んで興味がわいたらもっと専門的な勉強をしてもいいし、
この本の内容だけでも実際に必要なことはばっちり身に付きます。

トム・デマルコ『デッドライン』

お仕事では、組織運営に対する洞察も重要です。

トム・デマルコさんは「ソフトウェア開発で起こる問題は大体人の問題だ」っていうんですね。

みんな自分たちはハイテクなことをしてるって思いあがってる。
でも本当にハイテクなことしてるのは最先端の発明・発見をしているごく一部の人だ。
それ以外のソフトウェア産業の人はみんな突き詰めれば人間関係ビジネスだ。

だそうです。
で、いかに人間の組織を使ってソフトウェアを作るかという事についてこの本が教えてくれます。

坂田アキラ『坂田アキラの 数列が面白いほどわかる本』

世間のイメージに反して、
プログラミングと数学って実はあんまり関係がないですよね。
Web系のプログラマーが数学を使う機会なんて普通はほぼないと思います。
数学力がない人でも全然問題なくやっていけるわけです。
ところが、数列だけはプログラミングとかかわりが深いので簡単にかじっておくといいかと思います。

ジョン・マコーミック『 世界でもっとも強力な9のアルゴリズム』

今までの本の中で、一番知識によっている本です。
この本を読みながら何か練習したりしなくてもいい本です。
圧縮や暗号化についてざっくり知っておくと便利だと思います。

そもそも、この「好きな技術書ランキング」みたいなのが今ネットで流行ってるのって、
この業界には「なぜかみんな知ってるけど、それをどこで教わってるのかわからない」みたいな知識が膨大にあるからだと思います。

という意図を鑑みるとこの本が一番お勧めかもしれません。
「なぜかみんな知ってるけど、教わる機会がない話」集としてはよくできてると思います。

泉水翔吾、 佐藤歩『超速！ Webページ速度改善ガイド 』

Web系の開発者ならば、平場でPageSpeed Insights90点くらいは出せるようになってほしいと思います。

この本を読むとページ速度を上げるうえでどこが大事かがわかります。
それがわかっていると、開発の早い段階から速度を上げやすい設計にできます。

それとは別に、ページ速度はわかりやすい点数が出る点がいいと思います。
プログラミングというものはどうしてもゴールがあいまいになりがちです。
その点、この本を参考に特定のページの速度を上げる経験を繰り返すことによって
プログラミングスキルが全体的に向上するものではないかと思います。

ただ、ちょっと内容が古いところもあります。
最新情報は別途追った方がいいと思います。
変化が速い領域なのです。

徳丸 浩『体系的に学ぶ 安全なWebアプリケーションの作り方』

いわゆる徳丸本です。

あまり「読むべき本」などと強い言葉は使いたくないですが、
これは唯一「読むべき本」だと思います。

XSSやSQLインジェクションやCSRFなどについてわかりやすく書かれています。

リーアンダー ケイニ―『ジョナサン・アイブ　偉大な製品を生み出すアップルの天才デザイナ』

デザインの本も挙げたいなと思いました。

『誰のためのデザイン』『インターフェースデザインの心理学』などの名著と迷いましたが、
最終的にこの本を選びました。

具体的な技術はいろんなところで身に着けるとして、
そもそもIT系の人がちゃんとデザインに興味を持つことが大事だと思いました。

デザイン次第で商品の評価がこれほど変わるのかという事と、
いいデザインにするという事を工程に完全に組み込まなければいけないという事の両方を学べます。

『工程の最後にデザイナーさんに仕上げをお願い』ではないのです。
『いいデザインのものを作るという事がゴールで、プログラミングはそのお手伝い』と考えなければいけないのです。

プログラミング中級者の伸び悩み

流石にもう僕はプログラミング初心者ではないと思う。多分中級者くらいだ。
これまで初心者向けの教材や切磋琢磨の場にたくさんお世話になってきた。ありがとう。

さて、それ以降の人って何をしたら伸びるんだろうね。

Twitterやブログを見ていると、自分より優秀そうな人はたくさん見つかる。
でも、自分とその人の間にどういう差があってどうすれば近づけるのか分からない。
僕はそんなことを５年位悩んでる。

まず、初心者を脱するとどうなるか。

初心者の頃は、とりあえずプログラミングが好きなら勝手に伸びる。
作りたいものを作りたいように作ってるだけでどんどん成長していく。
会社に入らないと身につかないスキルがあるという意見もある。コードを整理整頓する技術などだ。しかし、僕は幸いなことに生まれつき脳のワーキングメモリが極めて乏しかったため、ちょっとでもコードが散らかると頭が爆発するので、その手の技能も趣味開発で身につけることができた。
この段階であれば、自分の足りない知識が何かを自分で検知できる。開発をしていて困ることはたくさんあるからだ。
本屋さんに行けば自分に必要な本が必ず１０冊くらい見つかる。
ところが、そのうちただコードを書いているだけでは全然成長しなくなってくる。
だいたいのものは一通り作れるようになってるからだ。
既に持っている知識と適宜のググりで困ることはほとんど無い。
もちろん本当は知らないことがいっぱいあるんだと思う。でも、苦手なことを無意識に回避する方法を覚えてしまっている。だから、自力で自分の苦手分野に気づくことができなくなってくる。

また、初心者のうちは新しい言語を覚えたりフレームワークを使ってみたりする度に成長していく。新しい世界観に出会えるからだ。
でも、徐々に新しい技術を身につける時の負荷が落ちてくる。

初心者を脱した僕が何をしたのか。
まず、本屋さんでいわゆる名著の類を読み始めた。プログラミング原論とか型システム入門とか。
頑張って読んだけど難しすぎて全然アレだった。
多分僕はまだこの次元には達してないようだ。

次に、資格を取り始めた。TOEICと数学検定とAtCoderとIPA。
ここ数年間は毎月100時間くらい勉強している。
AtCoderと数検は一応それなりに難関と言えるところまで到達した。

他にも、mozaic bootcampに参加させてもらった。
これは大変良かった。
ただ、365日誰かにこうやって教えてもらうわけにも行かなそうである。

何より、会社での仕事を一生懸命やってきた。

そんな僕は、なぜ伸び悩んでいると思うのか。
実は先日いわゆる転職活動というものをした。
その結果、あんまり自分の評価が高くないということを思い知った。
初心者を卒業してから何年間もずっと精進して生きてきた。だから当然それなりの評価があるものだろうと思っていた。ショックだった。

確かに、コーディングテストや知識を問う系のテストは上手く行った。
『○○なアプリを作りたいからどんなインフラにするか考えて』系も大丈夫だった。
でも、その次のステップでほぼ落ちた。

伸び悩みながらも頑張ってやってきたつもりだったが、実は全然伸びていなかったんだろうなと。
自分が技術力だと思っていたものとみんなが技術力だと思っているものは全然違うんだろうなと。
しかも、今僕は何が理由で落ちたのかよくわからないでいる。
これは困った。

今後僕はどうするか。
とにかく自分よりもっとレベルの高い人に色々教えてもらえるようにならないといけない。

二つ目標を決めた。自分よりレベルの高い人がたくさんいる会社で働くこと。もう一つはもっとコミュニティに関わる。

自分よりレベルの高い人がたくさんいる会社で働くというは、かなり難しい目標だ。だって、普通に考えて受からないからね。
これは煽りじゃないんだけど、その会社で一番技術力低い技術者って、どうやって会社に入ったんだろうね。
それってある意味一番難易度が高いハードルを突破した人ってことじゃん。
だれかレベルが高い会社の受かり方教えてください。

もう一つはコミュニティに関わるということ。
そうすれば色んな人が自分にいろんなことを教えてくれるようになると思う。
具体的にはこれをやろうと思っている。QiitaのQ&Aやteratailで質問に答える。みんなの技術ブログにちょっとコメントする（自分も試してみましたとか）。趣味でアプリを作ってる人がいたらちょっと使ってコメントをいう。
なぜそう思ったかというと、昨日中田敦彦のYoutube大学でオンラインサロンについて見たからだ。
オンラインサロンには興味がないが、オンラインサロンの活用術でこんなことを言っていた。『一番興味を持たれるのは一番みんなに興味を持ってる人。一番発信力があるのは一番人の話を聞いている人。一番手助けされるのは一番手助けしてる人』
これは確かにと思った。だから、僕はこのIT界隈にもっと貢献しようと思う。

『あのアーティストの代表曲は』の技術詳解

こういうWebアプリを作った。
https://famous-song.app/

本人は企画として面白いと思っている。
せっかくなので、どういう技術で作られているかについて解説する。

概要

まず、認証とRPCは全てFirebaseを使っている。
サーバーサイドはFirebase HostingとCloud Functions。
フロントエンドはTypeScript/React/Redux/typescript-fsaあたりを使った。
投票ページはSPAで、それ以外の結果表示ページはSSRしている。

意図

SSR

最近はSSR不要論も多い気がする。
ただ、フロントエンドでSPAと合流するようなSSRならともかく、ペライチのHTMLを生成するだけならSSRしたほうがロードが速いし実装も楽だと思う（そこに反対する人はいないと思う）。
SSRにはReactのtsxを使った。
tsxを使うと、引数にTypeScriptの型をそのまま使えるので簡単である。

SSRのCache-Controlにはこれを指定した。
public, max-age=10, stale-while-revalidate=1000
キャッシュが古くてもとりあえずCDNのキャッシュを返し、その間にCDNからCloud Functionsにアクセスしてキャッシュを入れ替える。
こうした理由はコレだ

• Cloud Functionsはそこそこ重い
• リアルタイム性が超重要というわけではない
• ユーザーも、おかしいなと思えばリロードするくらいのリテラシはあると思う

コマンド化

フロントエンドからRealtime Databaseの公開データを直接書き換えるのではなく、
フロントエンドからサーバーサイドにコマンドを送って、サーバーがそのコマンドを元に公開データを書き換える仕組みにした。
こうした理由は、この方がバリデーションやアクセス制御の点で楽だからだ。

この方式には１個欠点がある。
フロントエンドでサーバーの処理待ちがしづらいことだ。
RESTであれば、POSTを投げてからサーバーで処理が終るまでグルグルを出しておくということが簡単にできる。
しかし、Firebaseでコレをやってしまうとグルグルを消すタイミングがわからないという問題だ。
そこで、サーバーで処理が終わったこともRealtime Database経由でフロントエンドに通知することに指定ある。
その部分を抽象化してあるので、フロントエンドはasync/awaitで簡単に処理の待ち合わせができるようになっている。

フロントエンドでの正規化

それなりに大きいフロントエンドであれば、フロントエンドでも状態を正規化して持つべきだ。
正規化というのはRDB用語かもしれないが、要するに

• 値段は三桁ごとのコンマを入れずに数値で持つ
• Dateはタイムゾーンを統一しておく
• 省略可能なものに関しては必ず省略する
• RDBと同じように関係で表せるものは関係で表す

というよううなことだ。
タイムゾーンに関しては、YYYY-MM-DDの文字列で持つというのも結構優秀だ。
省略可能なものというのは、例えば誕生日・現在時刻・年齢や直角三角形の３辺など、二つが確定すれば残り一個も確定するようなものに関してはその１個を省略して持つほうが扱いやすい。
関係で表すとは、例えば、商品一覧とユーザー一覧と購買一覧があるなら、無理にオブジェクトで親子関係を作らずに配列を三つ持つということだ。

重要な点は、そのデータがどのように使われるかをあえて意識せず、データとしての完全性を最優先した型で持つことだ。
一見、そのデータがどのように使われるかに応じて型を決めたほうが後の処理を楽に作れる気がする。小さなアリケーションならこういう考え方もあると思う。
しかし、そういう考え方だと早晩コードが散らかってカオスになる。データの使い回しがしづらくなる。
やはり、データは極力完全な形で持つべきだ。

タブレイアウト

僕は、タブレイアウトって素晴らしいと思っている。
昔rebuild.fmでもそういうことを言っている人がいた。
2ch専ブラのJaneStyleやTabtterなど、人気のツールはだいたいタブレイアウトだ。
だから僕もタブレイアウトにした。
Webというものはクモの巣状にリンクが広がっていくモデルなので、ネイティブアプリと違って階層構造で画面遷移を表現しづらい。
それならば全てはタブであるという一般化をしたほうが認知しやすい。

アイキャッチの自動生成

Twitterなどにリンクを投稿する時のOGPのことだ。
実装の詳細はここに書いた。
https://qiita.com/isyumi_net/items/ee94a5e2d963958eb515
頑張ってレイアウトを計算すれば画像処理の延長で生成自動化は可能だが、
今使っている技術の延長で画像を生成できるということで、puppeteerを使った画像生成をした。特にBootstrapを使えるのでデザインが統一できて良い。