isyumi_netブログ

isyumi_netがプログラミングのこととかを書くブログ

2010年くらいの世界が技術的に楽しかった頃

要約

今現在プログラマーがかっこいい職業ということになったのは、
2010年頃に必要な技術が出揃ったからだと思います。

それまでは、例えプログラミングができたとしても、
それを使って社会に貢献するのは難しいことでした。
ソフトウェアで何かをするには、
プログラミングスキルだけでなく、それなりの予算と大きな組織が必要でした。

それに対し、2010年以降はプログラミングさえできれば社会に貢献しやすくなりました。

その頃に何があったのかについて話したいです。

きっかけ

自己紹介記事を書いていた時に思い出したのですが、
2010年頃って本当に技術的に楽しかったよなーって思いました。

主にAndroidとかが出てきた時期です。

一般的には1990年代の後半がITの転換期とされていると思いますが、
僕はこの2010年前後が一番のターニングポイントだったと思っています。

プログラミングというものの持つ意味が大きく変わったなと総括できると思います。

この文章の狙い

僕と同世代の方には、そんな時代もあったな〜と当時を懐かしく思っていただければと思います。

僕よりちょっと年下だったりプログラミングを後から始めた方におかれましては、
今現在のプログラミング界隈の当たり前というのは、
比較的最近形成されたものなのだと知っていただければと思います。

それまでのプログラミング

僕は昔からプログラミングができたのですが、
自分が作ったものを他の人に使ってもらう手段はほぼなかったです*1

だから、基本的にはプログラミングは個人の趣味でした。
プログラミングができるということとそれが社会との関わりになるということは全然別の問題でした。

今プログラミング能力が100の人が社会に与えられる影響が100だとしたら、
当時その能力値でできることは5くらいだったと思います。

そこからどのように個人のプログラマーにできることが広がっていったのか話します。 

この頃に登場・普及した技術

HTML5/CSS3とGoogle Chrome登場

Chromeが登場したのは、ウィキペディアによると2008年だそうです。
僕が使い始めたのは2009年頃だと記憶しています。

ここで初めて自分が作ったものを気軽に人に使ってもらえるようになりました。

それまで、Windows向けのデスクトップアプリとWebアプリでは表現力と性能に雲泥の差がありました。
しかしながら、デスクトップアプリを他人にインストールしてもらうのはハードルが高かったです。
だから、複雑なものはデスクトップアプリで作り、チープなものをWebアプリとして作っていました。

そこから、Ajaxやブラウザ戦争やHTML5/CSS3などの流れがあり、徐々にWebで本格的なアプリを作れるようになりました。
そして、Chromeの性能と普及率により、ついに何でもWebアプリで作ればいいということになりました。

僕はAudio APIを使ってみたときのことを覚えています。
iTunes的なものをWeb技術で作ろうと思ったのです。
出来たものを高校のクラスのみんなに使ってもらいました。
こんなに簡単におしゃれで便利なものを作ってみんなに使ってもらえるのかと興奮しました。

公平に言えば、それ以前にOperaFirefoxといったデキのいいブラウザは存在しました。
しかし、あまり普及していなかったので、それを前提にWebアプリを作るわけにはいきませんでした。
また、別の要素として、当時はPCの他にガラケーPSPのブラウザの利用率が高かったので、
Webアプリを作る時はそれらでも動くようにするべきということもありました。

Chromeの性能と普及率で初めてWebで本格的なアプリを作るという世界の扉が開いたと思います。

iPhone/Android

いくらプログラミングができても使ってもらう方法がないという問題のもう一個の決定的な解決がスマートフォンでした。

みんなが持ち歩く端末向けに自由にアプリを作って公開できるなんて革命でした。
しかも、カメラやマイクなど様々な機能にアクセスできました。

 

加速度がホントにJavaのコードから取れてびっくりしたのを覚えている。

この感覚、凄くわかります。

fushiroyama.hatenablog.com

 

なかでもAndroid

  • 開発にMacがいらない
  • マーケットの審査がゆるい
  • 野良アプリも配れる
  • 端末が安い

という点でiPhoneよりも大きな役割を果たしたと言える気がします。

Google App Engine

それまで、サーバーを借りることに大きな制約がありました。

サーバーホスティングサービスなどもありましたがお値段が高かったです。

なので基本的には共有サーバーを使っていました。
多くの共有サーバーでは、CGIは許可されていました。
プロセス常駐型のサーバーサイドアプリは使えませんでした。
そのため、言語の選択やアーキテクチャなどでとても不自由しました。

VPSという選択肢もありました。
しかし、アプリやOSやApacheなどのミドルウェアが落ちることもあり、
監視・復帰メカニズムを作ろうと思うとまた大変でした。

その点、GAEは安くてJavaが使えてサーバー運用が不要だったので、
簡単にアプリを公開しやすくなったと思います。

Wi-Fi/4G*2

ユーザーの端末が当たり前に高速ネット回線に繋がっていることが期待できるようになり、
ソフトウェア開発の幅がグッと広がりました。

PIC/Arduino/Raspberry Pi

PICなんて結構昔からあったらしいですね。
だから普及とは言わないと思います。

まあそれはさておき、この時期にちょっとしたハードウェアなら自力で作れるようになりました。

身の回りにタッチパネル製品が増えだした頃だったので、
逆にロータリーエンコーダーやトグルスイッチのような手触りがある入力デバイスのほうが親切な局面がありました。

例えば、僕が昔作った業務管理システムでは、

  • 画面上の特定の箇所をスクロールするためだけのロターリー
  • ある事件が起こると光って点滅するボタン(押すとそのページが開く)
  • あるボタンを押しながら喋ると、別室のスピーカーで音が出る

のような左手デバイスを作ったら喜ばれました。

NFC/Bluetooth

上と同じような話ですが、NFCBluetoothを積んだスマホが安価に手に入るようになったり、
NFCタグがどんどん安くなったことで、
物質世界と絡めたようなシステムを作りやすくなりました。

Dart/TypeScript/Kotlin/Swift/Go...

プログラム言語周りの発展も重要でした。

昔はWeb系ではサーバーでもフロントエンドでも動的型付け言語が主流でした。
それで困らなかったのかなって思うでしょ?
困ってました。

他にも、

  • まともなimport機構
  • 公式フォーマッター
  • 公式ライブラリリポジトリ
  • 依存管理機構

こういったものがちゃんと用意され始めたのもこの頃からでした。

更に、CI/CDサービスやSwaggerなどの開発効率系ツールも充実してきました。

単純にプログラミングの生産性も10倍くらいになった気がします。

何ができるようになったのか

これまでは、大きな業者に高いお金を払わなければ実現できなかったようなことが、
一人のプログラマーの力で実現できるようになりました。

例えば、飲食店のホールさんが持っているような端末についてです。
あるいは、倉庫や配達の現場で使うようなハンディターミナルでもいいです。

あのようなものを導入するにはすごくコストがかかります。
もちろん業者さんも意地悪をしているわけではありません。
ハードウェアが高いしSDKも高いのでどうしてもリース価格が高くなるのです。

しかし、Androidなら安くて簡単です。
端末は、Nexus 4なら5万弱、Nexus 7なら2万円弱で市販品を買うことができました。
アプリも自由に作れます。
その気になれば情シスさんが一人で必要な装備一式を作ることができました。
僕もよくそういうことをしていました。

このように、それまでは例えプログラミングができたとしても、それを使って会社の業務を良くしようと思えば大きな予算を獲得しなければいけなかった時代から、担当者一人でどんどん会社を改善していける時代になりました。

結論

あの時の、自分がだんだん強くなっていく感覚が楽しかったなーと思い出しました。

*1:ふりーむにゲームを投稿していました

*2:正確な普及時期とはちょっと違うようです

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

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

前置き

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

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

とある求職者の気持ち

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

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

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

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

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

求人側の意見

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

いらないんじゃん。

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

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

技術的な意見

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

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

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

なので、


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

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

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

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

組織論として

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

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

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

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

個人的には、

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

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

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

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

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

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

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

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

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

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

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

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

気にし過ぎでは……

主張

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

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

ということです。

それに対して

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

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

残念だった点

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

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

疑問

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

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

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

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

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

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

面接で聞かないでほしい

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

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

そもそも対立軸でもない

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

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

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

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

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

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

僕の場合はどうか

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

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

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

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

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

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

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

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

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

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

提案

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

まとめ

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

 

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

動機

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

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

主張

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

理由

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

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

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

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

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

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

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

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

結論

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

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

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

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

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

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

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

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

重視すること

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

あまり重視しないこと

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

誰が何に困っているのか

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

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

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

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

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

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

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

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

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

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

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

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

結論

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

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

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

目的

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

概要

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

職務経歴

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

特技

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

モチベーション

  • 誰かの役に立ちたい

職務経歴

幼少期

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

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

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

高校生の頃はクラス内の掲示板みたいなものを作っていました。
その頃、高校生たちが使えたWebブラウザガラケーPSPしかありませんでした。だから、それに合わせてCSSを書きました。JSはほぼ使えませんでした。
時間割表や宿題の締め切り情報などをクラスのみんなで共有する目的で始めました。
その掲示板にはカレンダー機能や画像うpろだ機能もありました。
今で言えば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を始めたわけではありません。
JSPPHPなどサーバーサイドでHTMLを組み立てる系の手法を一通りやった後、自力でSPAという考えにたどり着きました。
それでうまく行っているのである程度僕のいう事には信ぴょう性があると思います。

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

ドキュメント作り

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

速さ・正確さ

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

モチベーション

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

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

今後

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

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

 

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

 

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

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

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

 

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

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

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

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

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

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

仲間を集めるのは難しい

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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