この記事は、お子さん、どんな本読んでる？ Advent Calendar 2015 の 18 日目の記事です

今年のヒット絵本

とりあえず、今年のヒット絵本について、紹介しておこうと思います

『うどんのうーやん』やはりこれですね。chezou さんのどんな子供も好きになる、「うーやん」を広めるたった1つの方法でも紹介されていましたが、本当に頭おかしくて最高の絵本です。

他にも、おなじ岡田よしたか先生の『ちくわのわーさん』と『こんぶのぶーさん』というシリーズ作品も大変頭がおかしくて最高です

結局、『うどんのうーやん』が家で大ヒットしてから、本屋に行く度に「あっ、この絵は！」とか「うーやんっぽい！」という事で『わーさん』『ぶーさん』も購入することになったわけです

さらに、別の出版社の岡田よしたか先生作品『はずかしがりやの バナナくん』という本も、購入しました

読書家のみなさんなら「作者買い」というのは日常茶飯事かと思いますが、絵本の世界にもそれがあって、それどころか子供は作者名がわからなくても表紙の絵柄で「あれっぽい！」「それっぽい！」という感じで指摘しますので、特に顕著なのではないでしょうか。現に、我が家には現在岡田よしたか先生作品と、せなけいこ先生（『ねないこだれだ』の）作品で溢れています

そんなこんなで、絵本の頃から「作者買い」をする癖を付けて、この先の豊かな読書ライフに繋げて欲しいなと願うばかりです。以上！

12 月 18 日

今日はわしの誕生日なんですが、毎年「ウィッシュリストに入れてるからには読めよ」などと言いながら難しい本を送りつけて下さる方が続出しております。ほんと勘弁して欲しいですね

疲れが抜けてきたので、大江戸 Ruby 会議 05 に行ってきた記録を blog に書いておく

基調講演

Windows 環境の Ruby のガーディアン、usa さん

「あいおーのはなし」グレートトークだった。

あくまでサブシステムだったということが良く分かった -> "Microsoft Windows NT系はPOSIX 1.0に準拠しているPOSIXサブシステムを搭載しており" / “POSIX – Wikipedia” https://t.co/JH2htkVZmV

— yancya (@yancya) November 8, 2015

「WIndows NT 以降は POSIX」って言葉だけ頭にあったので、つぶやいてみたら、拾って言及してくださった。

ああ、そういえば、質問をカットしたので、会場では誰からも「POSIXサブシステムあるじゃん！」ってツッコまれずに済んだんだけど、それに対しては「あれはWindowsだけど、ぼくの今日の話でいうWindowsやないんや……」という答えが用意してありました。

— usa (@unak) November 8, 2015

ちなみに、ぼくはRubyをinterixに対応させるコードをcommitしたことがある程度には奴のことも知ってはいます。(今も動くとは言ってない)

— usa (@unak) November 8, 2015

WindowsのPOSIXサブシステム小ネタ。
実はNTFSはファイル名の大文字小文字を区別できる。Win32サブシステムのAPIセットでは同一視してるというだけなので、POSIX側で大文字小文字だけ違うファイルを作って、Win32ではアクセス不能！という遊びができる。

— usa (@unak) November 8, 2015

POSIXサブシステムはサブシステムだったけど、Win32サブシステムもサブシステムだから対等なんやで(という体裁だけど、もちろんWin32サブシステムを取り除くと動かない)。
他にはOS/2サブシステムとかも始めの頃にはあった(そもそもNTは次世代OS/2として開発が始まった)

— usa (@unak) November 8, 2015

この辺の話は全部『闘うプログラマー』https://t.co/2QA8metWu5 に書いてあるので、興味のある人はどうぞ。面白いよ！

— usa (@unak) November 8, 2015

「闘うプログラマー」読みかけのまま積んでるので、この機会に読み切りたいと思った。

LT

Ruby コミッターが５分ずつ原液みたいな濃さのトークを連ねていくというアタマノオカシイ企画

大江戸 Ruby 会議（Asakusa.rb）でしかできない、特殊な企画だと思う…

なかださん

(My) Best Commits of the year 2015 がすごくて、こういうのが聞きたかった。

mame さん

超絶技巧プログラミングと Ruby 3.0 （大江戸 Ruby 会議 05 コミッタ LT）も、期待してた以上の内容で、とても良かった。予め持ち込んでおいた超絶技巧本にサインもしていただいた。

こっそりサイン頂いてたんだった。ありがとうございます。#oedo05 pic.twitter.com/YQEliLlb4s

— yancya (@yancya) November 8, 2015

nagachika さん

Functional Music Compositionは意表を突かれた。『アンダスタンディングコンピュテーション』を読むと、この境地に至れるらしい。今、会社で読書会をしているので、わしもSKIコンビネータ計算厨の極みへ到達したい。

Ninja Talks

かねこさん

励まし合いながら当日に臨んだ発表者仲間のかねこさん。Rails on Two DBs という発表だった。

いろんな RDBMS における database, schema の扱いの違いを Rails で吸収するのが厳しいみたいな話で、みんなで辛さを共有して心を楽にしようという感じだった。

という感じだったが「複数 DB やめればいいじゃん」という鋭い質問が出て緊張した。

発表やった

SQL 脳から見た Ruby というタイトルで２０分しゃべることができた。

発表時のタイムラインの様子を見るに、一部の人には好評だったようでよかった。

発表が終わった後は、しばらく気絶してた。

発表の準備をするのに力を貸してくれた家族や周りのみなさんに、圧倒的感謝

地獄シリーズ

意識が戻った頃から、地獄っぽい Ninja talks が連続して行われていた。スライドの公開も無い、つまり本当の地獄の話達だ。

私の発表ですが微妙にセンシティブな内容なので資料のpublicな公開はかんべんください。何卒空気を読んでいただければw #oedo05

— 最速配信研究会山崎大輔 制約理論及び待ち行列理論による技術経営コンサルとエンジニア起業相談やってます (@yamaz) November 9, 2015

Special Talk

江渡さん「共創コミュニティのデザイン」

Ruby コミュニティについて、にわかなわしにとって、昔からの流れをキャッチアップする、大変ためになる話だった。この場に居合わせて、本当に良かった。

懇親会

Shapeshifter について質問してくれる人が多くて、ものを食べる暇も無く（ビールは飲んでた）しゃべりまくってたら３時間近く経ってて、すぐ終わってしまった。

発表者になると懇親会が充実するという話は本当だった。

帰り

懇親会二次会に行きたかったけど、一次会で全く食事をしていなかったため、空腹に耐えられずに東京ラーメンストリートへ。

きたきた pic.twitter.com/PLDXo9mbBj

— yancya (@yancya) November 8, 2015

食べたらお腹いっぱいになって眠くなったので帰宅しました

我々にできるOSSとそのコミュニティの育てかた

tagomoris さん

間口が最大になる英語以外、選択肢はないという話はもっともだと思った

version 1.0 の意味についての話について「あー」と思ったので、Rebuildfm #68 のtagomorisさん回を再度聴いた

質疑応答、異常に良い質問が出てきて「うおっ」と思ってたらt_wada さんだったらしくて納得。講演後に演壇の前で、この世の終わりみたいな顔をした t_wada さんが tagomoris さんと話をしていたのが印象的でした。

OSS 開発、あれやこれやしているうちに身動きがとれなくなって別の OSS が席巻し始めるような流れについて「新しい OSS が席巻し始めるタイミングは新規のコントリビューターが参入する絶好のチャンスだし、それはそれで OSS エコシステム全体から見れば好ましい事であるという視点で OSS の盛衰を見ているので」という返答は流石だと思いました。

woothee みたいな状態を意図的に作り出したり維持出来るケースはレア。みたいな話を昨日聞いてた

— yancya (@yancya) August 21, 2015

「成功例が１つだけあって厄介」と言っていたのは woothee の事らしいです。なるほど感

前夜祭の懇親会

MyNA の方々の飲み会に潜り込ませて頂いて、PostgreSQL ユーザーとして情報交換してました

LT はじまったw pic.twitter.com/Z9SqUQtncg

— yancya (@yancya) August 20, 2015

とみたさん「Sequel って Gem が最高なんですよ」

メリークリスマス！

Larry Wall

Kindle で指輪物語を全巻買って読みたくなった人が多そう

洋ゲーの冒頭で、こういう語りをするおじさんいるの、よく見る

— yancya (@yancya) August 21, 2015

TBD

Matz

Streem、本当に動く言語になってきててヤバい

日経LinuxバックナンバーDVDに Matz の Streem 記事が連載開始から１２回分くらい収録されているのでオススメです

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術

大事なことは最高な本から学んだ

PietでLISP処理系を書くのは難しい

GitHub でも画像の diff 見られるようになってるし、実用的な言語だなと思いました。

esa.io – 趣味から育てたWebサービスで生きていく

「かわいいは正義」と高らかに宣言した時のふかやつ氏のかわいさたるや

１日目の懇親会

Ruby の人達で固まってたので、ご挨拶をしつつ、他の島もグルグル回って聞き耳を立てたり、様子を見てました

何人かの方と「あー、インターネットで見たことある、あの」という挨拶をさせて頂き、有意義でした

１日目の懇親会の２次会

調子に乗って飲み過ぎて、03:40 くらいの帰宅となってしまい、本当に申し訳ありませんでした

ここで話した内容も一切公開できない内容でしたので、一体なんだったんだという感じです

Google Cloud Platformの謎テクノロジーを掘り下げる

朝から頑張って出席しました

謎テクノロジーが掘り下げられることはなく、いつもの「BigQuery はフルスキャンでこの速度！」って話から GCP 全体像への話へ

総合すると、データセンターのハードから自前で作っていく事により、現代、考え得る最高のインフラを構築、その上で最高のアプリケーションが絶えず走ってますという話であって「先駆者」というにふさわしいなという印象です

このあと「我々はどのように冗長化を失敗したのか」「3分でサービスのOSを入れ替える技術」という発表もありましたが、Google の背中を見て走っているのだよなぁと思いました。実際どうかは知りませんけども

BigQuery の UDF 、２〜３週間後くらいにリリースされるってよ！ #yapcasiaD

— yancya (@yancya) August 22, 2015

質問したら、大変嬉しい回答が貰えたのはよかった。半分くらい期待して待ってます

我々はどのように冗長化を失敗したのか

式年遷宮インフラストラクチャ3部作の第2部

「遷宮キメればいいかなと」 #yapcasiaD

— yancya (@yancya) August 22, 2015

MySQLで2億件のシリアルデータと格闘したチューニングの話

質疑応答で「ハードウェア増強の提案などはされないのですか」という質問に対して「お金がかかるので…」と回答されていたのが涙なしでは見られない感じでした。これだけの苦労をされたエンジニアの時間に対して「お金がかからない」と思われているんだなと感じたので…

3分でサービスのOSを入れ替える技術

あんちぽさんから信頼された高度な技術者達による英雄憚。

透過的な構築処理を１まとまりとして層を成し、よけいな構築時間がかからないようにまとめ上げるというのは DRY の原則っぽくてクールでした。

質疑応答にもありましたが、DB 等の永続化層で同じ事をやるのは厳しそうだなと思いました

Profiling & Optimizing in Go

この辺で体力が尽きかけてました

「Go に daemon の仕組みが無いのはどうすんの」という質問に「daemon はオワコンというか、daemon の仕組みを言語環境側が持つべきではないと考えている。init とか supervisord とか systemd とか色々あるんだし、今ならアプリケーションをコンテナ化するのがいいのでは」って言ってたのが印象に残りました

[LT] MySQL 5.7の罠があなたを狙っている

MySQL ユーザーのたくましさ、ここに見たり

[LT] 本物の “ロック” ってやつを魅せてあげますよ – 分散排他ロック篇

本物のロック、ここに見たり

[LT] コミュ力あげてこ

YAPC 、静まり返った満員のホールに、ただモールス信号が響き渡っていたシーンが頭から離れない

— yancya (@yancya) August 24, 2015

素晴らしすぎた

[LT] CONBUの道具箱

こういうのが脳内に浮かんでましたね

本当にありがとうございました。会期中、とても快適でした

２日目の懇親会

ないです。ラーメン食べて、帰宅して即就寝でした

#yapcramen pic.twitter.com/gLm3J4oooV

— yancya (@yancya) August 22, 2015

まとめ

新橋に宿を取ればよかった…

退職しましたというエントリを書いてから早くも２年、そして、１年前に転職しましたというエントリを書いてから１年が経過しました。せっかくなので、またまた１年を振り返ってみることにします。

いままであらすじ

２年前、ごく小規模の WEB 受託開発会社から、中規模の広告代理店へ転職。

転職先では、エンジニアの社員はわしだけ。

「エンジニアの居ない場所に行ってポストを作れさえすれば、割と無双できます」は、やはり正しかったと自負。

よかったこと

２年目は内製体制への慣れが出てきて、チームの雰囲気が変わってきました。最初の１年では、外注のクセが抜けておらず、何かをやりたいときにチーム内のエンジニア（わし）に「発注」するようなコミュニケーションになっていました。そのため、何をするにも「発注者」が「要件」「仕様」を決めてから「発注」という流れになり「発注」まで長い時間がかかった上に「発注」後に「仕様」が変わっていくというお決まりのパターンに陥る事が多々ありました。また、チーム内でそういった「お客様感覚」の振る舞いをされると、まぁ、気分はよくないですよね（言いませんけど）。その辺りについて、この１年は何かやりたいことがある場合、とにかく、まず issue を立てるようにしてもらい、そこで「要件」がなんなのか、どんな「仕様」がいいかを議論していくスタイルに変わっていき、いまでは定着しているように思います。これにより、やって欲しい方は、やりたいことが整理できますし、作る方はなにがやりたいのか明確になりますので、前よりスッキリと開発ができるようになりました。この体制になるまで（今でも少し）、口頭で聞き慣れない話題について話してるのを聞いたら「タイトルオンリーでもいいので、issue を立ててからやって貰えますかー。あとですぐ閉じることになってもかまわないのでー」と言うのを２年間、延々と繰り返してきました。長い目で見て取り組むのが大事だなって思います。

Java から Ruby に移植した WEB アプリケーション、運用が２年目に入りました。現在 Ruby 2.2.2, Rails 4.2.2 環境で元気に動いてるので、サーバーサイドは比較的健全な状態を保ててると思います。（サーバーサイドは）

BigQuery の導入は大当たりでした。今までは PostgreSQL を使った OLAP をたくさんやっていましたが、処理する DB の件数も増え、各種 BigData 処理環境の発展による相対的な性能劣化も目立っていましたので、安くて美味しそうな BigQuery に手を出してみました。最低限の Window 関数は揃っていましたし、PostgreSQL で培った OLAP ノウハウがだいたい生かせる環境でしたので、ボトルネックになっていた処理から順に移植している状況です。

昨年のエントリで ISMS 事務局の一員となった件についても書きましたが、昨年末にあった大型の審査（社屋移転、３年更新、新規事業追加に伴う適用範囲の拡大、ISO27001:2014 へのアップグレードの４本立て）を乗り切りました。ただ、ISMS 体制の維持については、無駄な労力がかかっている部分が多々あるので、年々効率化を進めて、全体の負担を減らしていきたいところです。

昨年のエントリで「ここらでもう一人くらい増やせるように色々立ち回っていきたいなと思っています」と書きましたが、うまいことやりまして、５月からエンジニアが１人入ってきてくれました。僥倖。

うまくいかなかった事

片手間 Javascript 業が、かなり大変でした。サーバーサイドはイイカンジで動いているんですが、いわゆるフロントエンドは勉強不足が災いして安定するまで結構時間が掛かってしまいました。AngularJS 1.2 を導入して、最初はよかったんですが、途中から IE8 への対応が必要になって 1.3 以降へのアップデートを封じられてしまい、UA 毎にコードを変える決心も付かず、その場しのぎの対応で問題を先送りしていました。そうして先送りしていたところ、IE8 終了のお知らせが舞い込んできて、時間稼ぎさえすれば近いうちに解放されるという状況になってくれて、ホッとしています。

今回は、たまたまなんとかなったからいいものの、この反省が生かせるかというと微妙なところなので、どうしようかなという感じです。「もっともっとちゃんと勉強してから始めればよかった」ってのも、それはそうなんですが、それでは始まらないというのもあり…

「jQuery で頑張って書く」というようなことをしなかっただけ比較的マシなルートを通ったんじゃ無いかとも思うので、非常に難しい感想になります。

今後やりたいこと

現在、データセンターにサーバーを置く、いわゆるオンプレ環境での運用を続けていますが、ハードウェアのリプレース時期が近づいてきているので、クラウド環境での運用に移せればいいなと思って動いてます。インフラは片手間 JS の時みたいなヘマをすると取り返すのが比較的難しい領域ですから、慎重にやっていきたいところです。幸い、新しく入ったエンジニア氏が、わしよりもインフラに明るいので、協力して新環境を樹立したいと思います。

新しく入ったエンジニア氏が元々 Perl 畑の人で、現在 Ruby について熱心に勉強中なので、Rubyist として育成していきたいという感じです。

欲を言えば、さらに１人くらいエンジニアを増やせると言うことがないんですが、売上が劇的に躍進したりしない限り、少し厳しそうです。

言いたいこと

普通の会社には、普通のエンジニアが潜り込んで出来る事がたくさん転がってます。

要するに、繰り返しになりますが「エンジニアの居ない場所に行ってポストを作れさえすれば、割と無双できます」という事につきます。

あえて、エンジニアの薄い環境へエンジニアが転職していくようになれば、ますますエンジニアが不足して価値が高騰するかもしれませんので、みなさまよろしくお願いいたします。

注

このエントリ中での「エンジニア」という言葉は、SE とかアーキテクトとかプログラマーとかインフラエンジニアとか、そういった感じのものを混ぜた感じの言葉として使っています。「エンジニア」という言葉の定義に敏感な方にはご不快かもしれませんが、何卒ご容赦いただければと思います。

このエントリは、誕生日 Advent Calendar 2014 の 12 月 18 日分です。

誕生日

そういえば、@onk さんと同じ誕生日なんですよね。前々から bio に書いてあるのを見て「あっ同じだー」とは思ってました。

@onk 一緒に祝っておきますね

— yancya (@yancya) November 4, 2014

一緒に祝っておきます。はっぴばーすでー！わし＆おなかさん！

カーチャン

誕生日について考えるにあたっては、やはりカーチャンへの圧倒的感謝を忘れるわけにはいきません。

わしが産まれる前、わしがこの世に発生したときに「覚悟を決めて産む」「キャンセル」というダイアログが出たと聞きます。結局、カーチャンは１人で産んで、色々あったけど１人で育てました。ロックだ。

今、わしは３人の子供を育成していますが、かみさんと協力してギリギリの状態で、やっと回っています。毎日の大変さが増せば増すほど、あの日「キャンセル」を押さないでくれたカーチャンへの感謝も比例して増していくようです。

33.0 歳ともなれば、仮に 99 歳まで生きるにしたって今まで生きてきた 3 倍の時間でしかないし、誤差っぽいです。それが 0.0 歳だとどうでしょう、何歳まで生きるかに関わらず Infinity 倍ですからね。救急戦隊ゴーゴーファイブの主題歌の中に「ひとつの命を救うのは 無限の未来を救うこと」という歌詞があるんですが、うおー。

この先生きのこることができるか

「生存戦略」みたいなものについて、わしは「この世に産まれてしまいさえすれば、あとはゴールまで生きるだけ」という人生観なので、いまいちピンときません。日本に生まれたのなら、どうあれ生存できちゃうと思います。なお、サバンナでは同じ事は言えません。

「いかに他人を出し抜いて、自分と家族だけは良い思いをするかという戦略」なら、なるほどって思います。ただ、まぁ、あまり他人をシバき過ぎると、殺されるかもしれなくなるので、程々にしないとダメだよなって思ってます。余力はシェアして、治安を高めよう。

「好きなことで生きていく」という事が「生存」であり、「望まぬ事を強いられて生きていく」という事を「死」と同等に捉える前提での「生存戦略」なのであれば、うおー、贅沢な悩みだなと思いますが、豊かであるということは素晴らしいですね。

Advent Calendar

一昨年くらいから Advent Calendar をボチボチ書き始めて、読むのも書くのも楽しいので毎年やることにしました。せっかく 12 月に誕生日があるので、空きがあれば誕生日の枠を確保してます。今年の投稿は下記の通りです。

• Refinements のスコープについて
• Rails でシングルじゃないテーブル継承
• PostgreSQL のパーティションテーブル自動生成

誕生日ですが「ウィッシュリストに入れてるからには読めよ」などと言いながら難しい本を送りつけるなどの行為は何卒

四日間フル参加、広場では生活発表と LT やった。
とりあえず、今日はもう寝ないと死ぬ

後で追記する

— 追記（ 2014/11/28 ）
このあと２ヶ月くらい、燃え尽き症候群めいていた

はじめに

早いもので、rubyhiroba で、すとうさんから学んだ事（前編）というエントリを書いてから１年以上が経ったようです。そろそろ記憶も薄れてきたし、明日から RubyKaigi 2014 だし、続きを書いて〆ておこうかと思います。
ここからは、わしのノートにメモしてあった内容を曖昧な記憶で補完しながら書いていきます。

※ 注意
※ このエントリはほぼ実話ですが、細部については記憶の欠落や脚色があります。
※ 予めご了承の程、よろしくお願い致します。

あらすじ

ひょんな事から Rabbit のソースコードリーディングをする事になったわし達は…

ソースコードリーディングの様子

Rabbit は、言わずと知れた Ruby 製プレゼンテーションツールで、すとうさんが強力にメンテされている偉大なソフトウェアです。この時のソースコードリーディングで対象としたのは Rabbit::Canvas というクラスのソースコードでした。

require は、いつすべき？

参加者１「Ruby って、各ファイルで require するけど、それって DRY 的にどうなんスか？自分は PHPer なんスけど、PHP には __autoload() とか spl_autoload_register() ってのがあってオートロード出来るのに、なんで Ruby には無いのかなって思うんスよね」
わし（うおー。そこからかー）
参加者２「まぁ、Rails では const_missing をオーバーライドして、しかるべきファイルをオートロードする仕組みがあったりするよ」
参加者１「へー。なんで Ruby 本体に無いんスかねー。なんでスかねー」
すとうさん「あ、ちょうどなかださんがいるので聞いてみましょう。なかださーん」
わし（なかださん、なんで床に座ってパッチ書いてるの…）
なかださん「Rails でやってることなんだから、Gem にしちゃえば使えるじゃん。本体に入れる意味あんの？」
みんな「あざーす」

def_delegate 多すぎ

参加者１「なんか、よく分からないんスけど、def_delegate してる行が多すぎません？」
すとうさん「なぜ、多いと悪いと思いますか？」
参加者１「いや、なんとなくなんスけど、クラスの切り方がうまくいってないときにそうなりがちな気がするのでー」
みんな「ふーむ」

class comment について

参加者１「クラスの冒頭に、そのクラスを説明するコメントを入れたりしないんスか？」
すとうさん「特に必要無ければ入れませんね」
参加者２「ボクは入れる派ですねー。１クラスのソースが１画面に収まるくらいだったら書かないですけど」
わし（あ、これリーダブルコードで見たやつだ）
みんな「ふーむ」

Utils

参加者１「あっ！utils.rb なんてのがあるぞ！」
参加者２「utils っ！ utils っ！」
すとうさん「見てしまいましたね」
参加者１「Rabbit::Utils 以外の module も書いてあるぞ」
参加者２「1 file 1 module じゃないんですかー。かー」
わし（怖ー！怖ー！コードリーディング怖ー！）

感想

こういった流れの中でも、すとうさんは楽しそうに場を進めていっていたように記憶しています。慣れているからなのか、人柄なのか、凄いなと思います。
とは言え、このソースコードリーディングは、恐らく場の趣旨とは違ったものになってしまったんじゃないかなと思っています。見ている分には勉強になりましたが、若干、心に闇が生まれました。
今後、これと全く同じ場はもう無いと思いますが、似たような場面に立ち会った際に、少しでも会話の場をハッピーな方向に変えられるような発言が出来るよう心がけながら、明日からの RubyKaigi 2014, RubyHiroba 2014 に臨んでいきたいと思います。

退職しましたというエントリを書いてから、早くも１年が経過しました。せっかくなのでゆるーく１年を振り返ってみたいと思います。

いままであらすじ

１年前、ごく小規模の WEB 受託開発会社から、中規模の広告代理店へ転職しました。

転職先では、エンジニアの社員はわしだけです。

転職して変わったこと

複数のプロジェクトを掛け持ちしなくて済むようになったので、比較的、目の前の仕事に集中しやすくなりました。

電話を取らなくて良くなったので、比較的、目の前の仕事に集中しやすくなりました。

職場が広くて清潔になりました。しかも６月に新築ビルに引っ越してさらに快適になったので、比較的、目の前の仕事に集中しやすくなりました。

システム開発に関するしがらみが０なので、唯一のエンジニアであるわしの裁量で大体のことは決められます。比較的、目の前の仕事に集中しやすくなりました。

何か新しい機能を作るときに、(打算的な)見積もりを作って価格交渉したりする必要がないので、比較的、目の前の仕事に集中しやすくなりました。

目の前の仕事に集中しやすくなったので、比較的、目の前の仕事に集中しやすくなりました。

集中力に乏しいので、本当に助かります。

試してうまくいった事

入社して一番最初に目に付いたのは根性駆動の Excel 業務でした。毎月の定型作業を数日がかりで仕上げているのを見て、これはイカンと思い、VBA は未経験でしたが、少し勉強してマクロを書きまくりました。よくある「２日かかる作業を５分にするような改善」というやつです。同じような箇所は今でもまだまだありますので、今後もゴリゴリ倒していきたいと思います。「人間がコンピューターの仕事を奪うな」がスローガンです。

６年くらい前に Java で構築された WEB アプリが、テストも無くてメンテ可能限界を超えそうになっていたので、Rails で書き直してみました。テストもないし、新機能の需要もありましたので、移植ではなく、要件定義からやりなおしました。１回リスケジュールが入りましたが、先日なんとかリリース出来ました。

部署内の情報共有に HipChat と GitHub Organization を導入しました。それまではメールと口頭のみのコミュニケーションでしたが、今ではメールは社外とのやり取りにしか使っていません。「何か話すべき事があったら、井戸端会議をやる前に issue を立てて下さい」という事を口を酸っぱくして言い続けたところ、今ではすっかり徹底されています。ポケット１つの原則に従うと、本当に捗ります。

うまくいかなかった事

前職では毎日コーヒーメーカーで美味しいコーヒーを入れて楽しんでいましたが、現職では不許可となりました。仕方なくウォーターサーバーのお湯とティーバッグで紅茶を飲んでいます。

前職より年収を倍にしようと思って交渉しましたが、世の中そこまで甘くはなかったです。

Rails アプリの書き直しの仕事をやるとき「この日までには終わりそうかな」と言われて、うっかり「いくらなんでも終わるでしょう」と言ってしまい、割り込みの仕事などをホイホイ受けているうちに「あっ」ってなってしまったのは痛恨事でした。状況の変化を共有していくことの大事さよ。

今後やりたいこと

弊社では ISMS を導入しているので、社内で異質な開発環境についてあれはダメこれはダメと言われない為に、誰もやりたがらない ISMS 事務局のメンバーを買って出て ISMS 活動をしています。色んな会社で聞くような糞セキュリティにならないよう、今後も目を光らせていきたいです。

社内のエンジニアが開発を進めていく事の速さ、安さ、美味さを分かってもらえてきた頃だと思いますので、ここらでもう一人くらい増やせるように色々立ち回っていきたいなと思っています。

言いたいこと

１年前「エンジニアの居ない場所に行ってポストを作れさえすれば、割と無双できます」と書きましたが、１年経った今、やはり正しかったと思っています。エンジニア本人のためにもなるし、情報処理未開の地に住む人達にとっても福音となるのがいいですね。

世のチョットデキル系エンジニア達と比べたら到底パっとしない、わしのようなエンジニアでも、素人の中に居ればスーパーハッカーなのです。パソコンの大先生なのです。わしの場合、運も味方してポストが作れましたが、他にも潜在的な需要が沢山あるはずだと思っています。エンジニアを求めてるのはモヒカンの巣みたいな会社だけじゃないし、転職先を求めてるのはモヒカンばかりではない。そういう需要を掘り起こして、パッとしない系エンジニアとマッチングするようなサービスがあったら良いんじゃないかなと思います。

後日談

２年前に転職しました