「フロントエンドエンジニアですか？ サーバーサイドエンジニアですか？」と聞かれても困る

転職活動をしているとよく聞かれます。
果たしてこの質問にどの程度の意味があるのでしょうか。

前置き

もちろん、本人が好きでそう名乗っている場合は否定しません。
あるいは、特定のことがあまりにも得意すぎてしまう人が周りからそう呼ばれてしまうのはしょうがないと思います。

また、雇用の透明性の問題として、事前に求人する役割を明確にしておくべきだという流れはあり、
それに準じようとした結果そうなったのかもしれません。

とある求職者の気持ち

知らんがなって思います。

今までいくつかの会社で働きましたが、そんな役割分担はありませんでした。
また、『どちらをやりたいか』といった願望も特にありません。

確かに、その時によって主にサーバーを触っていた時期やフロントエンドを触っていた時期というのはあります。
しかし、それというのはその場にいる人や状況で決まったことであって、
特に僕のアイデンティティとは関係がありません。

そして、御社ではどのような人が働いていて、どんな技術的課題があるのかわからないので、僕が入った場合僕がどちらをやるべきなのか、こちらでは判断がつかないです。

正直言って、そういうのは出たとこ勝負で何とかなると思っています。
どうしても分類する必要があるということなら、そちらで好きに決めていただければいいのではないかと思います。

求人側の意見

実は、先日転職活動をしていた時にいろんな会社に聞きました。
ほとんどの会社が、「実はそんなに○○エンジニアをはっきり分けているわけではない」と言っていました。

いらないんじゃん。

先方が言うには、「求人サイトのフォームの都合でそうなっちゃう」ということでした。

他には「そこを明示しておかないと人が集まらない」という声もありました。
なるほど。
ということはそこを重要視するソフトウェアエンジニアも一定数いるということでしょう。

技術的な意見

まず、だいたい色んなことで共用できるスキルと、
特定のジャンルの技術というのはあります。

例えば、応用情報技術者試験の勉強をしましたとかは共用のスキルだと思います。
Reactが得意とかは特定の技術だと思います。

そして、そのどちらに投資しているか個人差はあると思います。

なので、

「ゼネラリストタイプですか？　スペシャリストタイプですか？」
　スペシャリストです→「一番得意なのはなんですか？」

みたいな話の流れならいいかなと思います。

ただ傾向として、基礎を重視している人は特定の技術にも素早く対応できるし、
逆に特定のことに尖った経験がなければ基礎が積み上がっていかないということもあるでしょう。
だから、必ずしも対立軸でもないと思います。

また、例えば僕は競技プログラミングをしています。
僕はこれを基礎力の訓練だと思っています。
しかし、競プロを一芸だと思って練習している人もいます。
このように、何を持って基礎とするかが曖昧なので明快な話ではないかな〜という気がします。

組織論として

その組織が成し遂げられることの最大値は、最もそれが得意な人の得意さに依存すると思います。
なので、その分野のスペシャリストがほしい時は必ずあると思います。
そういう人を募集して厚遇するのは悪いことではないと思います。
エースです。一番手です。旗手。マタドール。

逆に色んなことができないとできない判断というのもあったりします。

総合的に言えば、『スペシャリストが数人でその他がゼネラリスト』みたいな組織が一番いいのではないでしょうか。

特定の分野のスペシャリストばかり揃えたり、『全員が何かしらのスペシャリストであれ』みたいな考え方はあんまり好ましいとは思っていません。
まあ、その辺りは各社の経営戦略なので口出してもあれなのですが……

個人的には、

• 言語不問でちょっと複雑な問題を出してコードを書く速さと正確さを見る
• 散らかってるコードを渡してリファクタリングしてもらう
• こういう障害が起きたらどういう順番で対応しますかって聞く

などのほうがいい人を採れるのではないかと思っています。

類例：就活における個人的体験の話

ちょっと横道にそれまして、自分が転職活動で体験したことの話をします。

フロントエンドフレームワークを例に出します。
僕の実務経験量としてはReact>Angular>Vueです。

さて、内定をもらえる割合ははっきりとその会社が主に使っているフレームワークに相関していました。
同じくReact>Angular>Vueの順です。
多分20%ずつぐらい違っていたと思います。

もちろん、各社がどういう理由で合否を出したのかはわかりません。
なので、フロントエンドフレームワークの実務経験だけが理由ではないでしょう。

ただ、現にこれだけはっきり相関しているので、
「React経験多いから内定を出そう」「Vueは実務経験なさそうだから落とそう」という判断をした会社は必ず一定数いたはずです。

僕はちょっと微妙なお気持ちになりました。

Vueってそんなに難しいフレームワークなのでしょうか……
ReactやAngularをいっぱい触っている人でもキャッチアップできないようなものということでしょうか。
もし本当にそうなら、多分いまVueを使っているということ自体が巨大な経営リスクだと思うのですが……

正直『僕ならさらっとドキュメント読めばすぐ使えるようになるでしょ』と思っています。
やったことないけど。

同じように、似たような技術で片方しかやったことないとか両方やったことあるけど業務経験としては片方のみとかのケースで合格率が大きく変わることはが結構ありました。

気にし過ぎでは……

主張

始めに戻ると、僕の主張は

• 特定のスペシャリストが必要な時はある
• スペシャリティ以外の尺度もいっぱいあるはず
• 本人が特定のスペシャリストを名乗るのは別にいい
• 実質「〇〇の専門家」と思われても仕方ない人もいる
• 自分のスペシャリティとか気にしてない人も結構いるはず

ということです。

それに対して

• ソフトウェアエンジニアは、その人の持ち技術で分類できる
• より細かくソフトウェアエンジニアを分類することで上手にマッチングできる可能性が高まる
• その人の最も強い点の強さがその人の技術の総合力

というような考え方の人が多いなと思ったという話です。

残念だった点

事情をよくしらない人事の方がそういう勘違いで落としてしまったならまだわかります。
でも、落ちたタイミング的に、どちらかといえばソフトウェアエンジニアの人たち方が強くそういう価値観に染まっているような気がします。

残念だなーとおもいます。

疑問

ちょっと同業者に聞いてみたいな〜と思いました。
Twitterにリプでもしてください。

• 自分は何かの分野のスペシャリストだと思うか？
• スペシャリストだと思う場合、他の技術の仕事をすることにどの程度ポジティブか
• 特定の分野に強くなれるなら似たような別の分野も上手にできるはずという考えをどう思うか
• 逆に基礎がしっかりしていればだいたいのことには対応できるはずという考えをどう思うか
• それ以外にこの記事を見て思ったこと

自分は何かの分野のスペシャリストだと思うかというのは、
「自分なんて○○さんと比べてorz」という話ではなく、
あくまでアイデンティティとして「自分は○○方面の人だ」みたいな意識があるかということです。

他の技術の仕事をすることにどの程度ポジティブかというのは、
もちろん合意の上という話です。
また、「本人がその分野に取り組んでみたいと思っていた」みたいな話でもないとします。

「技術寄りのエンジニアですか？ ビジネス寄りのエンジニアですか？」という愚問

転職活動しているとよく聞かれるのですが、なんなのでしょうね。この質問。
この二つって対立軸なのでしょうか？

面接で聞かないでほしい

技術寄りと答えると、頭でっかちで会社のことを考えない人だと思われそうです。
かといってビジネス寄りと答えると技術力の低さの言い訳をしている人感が出てしまいます。

どう答えても都合が悪いので、そもそもこの質問をしないでほしいです。

そもそも対立軸でもない

普通に考えて、技術者として雇われているのだから、ビジネスに貢献しようと思ったら技術力はたくさん必要ですよね。

でも技術で貢献しようと思ったら会社のみんなの事とかお客さんの事とか考えますよね。

むしろ逆をこたえるパラドックス

仮にある種の軸があるとして、それを本人に聞くと逆のことを答える気がします。

例えば、とても技術力がある人なら、ビジネススキルを課題に感じることが多いと思います。なので、主観的には「自分はビジネス面を頑張っている」とか「大事なのはビジネス面だ」と感じるかもしれません。
反対に、ビジネススキルが高い人は技術力が大事だと感じることが多いので「自分は技術面を頑張っている」と答える気がします。

謙虚な人ほどこの傾向が強くなると思います。
このように、本人に聞く意味がない気がします。

僕の場合はどうか

僕はとても会社のみんなのことを考えて仕事をしています。
ところで、今のところ会社では僕が一番プログラミング力が高いようです。
なので、なるべく僕がプログラミングの仕事を増やし、それ以外のことを他の人にやってもらった方が全体最適です。
だからそうしています。
それはチームのみんなで話し合った結果そうなったのであって、特に誰も不満に思ってはないと思います。

この場合僕は技術寄りのエンジニアでしょうか。ビジネス寄りのエンジニアでしょうか。

嬉々として答える人は何なのか

このように、どう考えても答え辛い質問だと思います。
なのに、喜んでこの質問に答える人は何なのでしょうか。

もしかしたら今働いている会社の中での役割を答えているのかもしれません。

ただ単に、今の会社では技術力が高い方だから技術重視で働いているとか、このメンバーの中ではビジネススキルが自分のストロングポイントだからビジネス寄りの仕事を頑張っているとか、そういう意味かもしれません。

でも、それはあくまでとある会社の中での役回りであって、本人の性質には全く紐づかない話です。
転職の面接で話す意味はないですね。

もし仮に、本当に技術寄りのエンジニアというのがいるとしたら、語義的に僕が納得行くのはこういう人です。
それはつまり、『社内に自分より技術力が高い人がたくさんおり、逆にこの中ではビジネススキルが自分の長所だ、という状況でも技術重視の役割をやりたがる人』です。
これは本当に技術寄りのエンジニアといえるのではないでしょうか。

逆もしかりです。『社内では一番技術力が高く、逆にビジネススキルはあまり得意ではないのに、ビジネス寄りの仕事をやりたがる人』はビジネス寄りのエンジニアといえそうです。

どっちもあんまり一緒に働きたい気はしないですが……

提案

コンサルタントの就職試験みたいなケーススタディ問題と技術試験を別々に課して、
そのスコアをもとに選考フローを進めたほうがいいと思います。

まとめ

あんまり意味のある質問じゃないよねこれ。

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

動機

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

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

主張

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

理由

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

なぜそう思うかというと、僕は基本的に『常識は間違っていることもある』と思っているからです。
「一般的には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系の人がちゃんとデザインに興味を持つことが大事だと思いました。

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

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