なんとなく日記

Mediumに移転してみる

Thu, 01 Jun 2017 19:31:35 +0000

Hugo便利ではあるんですが、いろいろ運用面倒になってきたので、しばらくはMediumに移ってにみようと思います。

運用の何が面倒って、記事を作成するには、

Markdownで記事を書く (esa.io)
プレビューして確認
リポジトリにコミット
Hugoのビルド (CI)
S3にアップする (CI)

という手順を踏まないといけないんですが、一番面倒なのはプレビューのところ。まあ仕方ないとはいえ、どうせなら何らかのサービス使ってみたいなと思っていたので、いま話題（遅い）の Medium にしました。

会社のHPも Mediumにしたんで、記事も共有できれば良いなという思惑もあります。

技術力は才能？努力？〜「超一流になるのは才能か努力か?」

Mon, 08 May 2017 16:12:35 +0000

優秀な若者にオススメされて読んでみたんですが、常々思っていたことがちゃんと学問として検証されていたようで、ものすごく腑に落ちたので紹介してみます。

超一流になるのは才能か努力か?

著者: アンダースエリクソン, ロバートプール
出版日: 2016-07-29
出版社/メーカー: 文藝春秋
カテゴリ: Book

昔から「いわゆる生まれ持った才能はない」と思っていたんですが、それを研究や実験を通じて解説されていて、しかもどうすれば能力を伸ばせるのかが書かれていて非常に興味深かったです。

特に新卒エンジニアの採用をしていると、いまの能力で評価するのか将来の伸び率で評価するのか難しい部分があるんですが、個人的には「技術力を伸ばすことはできる」と考えているので、どちらかと言うとカルチャーマッチのほうを重視したりしてました。

とは言え、じゃあどうやって伸ばすのかと言われると答えられないんですよね。自分がどうやって成長してきたのかはある程度わかっているけど、それを他人に適用できるのかと言われれば無理だと断言できる。なぜなら趣味嗜好も違うだろうし、家庭や生育してきた環境も違う。前提条件が違うのに方法論だけ適用してもうまくいかないので、そういう相談をされたときにはあまり自分のことを話さないようにしてました。

上記の本にはその方法として例えば、

具体的な目標を立ててそれ目指して練習する
できる人に適切なフィードバックを得られるような環境でやる
コンフォートゾーン（居心地ところ）から外に出て練習する

と書かれています。3番目なんて僕の好きな情熱プログラマーの「一番の下手くそでいよう」というのに近いかなと、自分の中にスッと入ってきました。

先日のポエムにも書いたんですが、「限界的練習で技術力は伸ばせる」という前提なら、いろいろ採用の仕方も変わってくるなと改めて考えさせられました。もちろん今度は教育が大変になるんですが。

キャリア形成の重要性〜『その「エンジニア採用」が不幸を生む』を読んだ

Mon, 01 May 2017 16:12:35 +0000

ちょっと前に発売されたエンジニア採用に関する本を読んだのでその感想。

その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か?

著者: 正道寺雅信
出版日: 2016-12-07
出版社/メーカー: 技術評論社
カテゴリ: Book

内容的にはこれからエンジニアの採用を始めよう・強化しようと考えている経営者に読んでほしい書籍です。どういった人を採用すべきかがわからないと言う話はよく聞くんですが、その最初の一歩としてはまとまって書かれています。

エンジニア採用でなにが不幸を招くのか

いろいろ問題があると思うんですが、例えばこれから採用しようと考えている会社側の問題としては、経営者の理解が挙げられます。何のために採用するのか、何をやってもらいたいのかなどは整理されているか。また会社制度・文化とのマッチングは大丈夫か。これは前にも書いたんですが、会社と合うかどうかって非常に重要です。さらに日本は制度上簡単に解雇できないので、もし事業がなくなってしまったら別の仕事にアサインすることになりますが、そこまで考えて採用しているケースはほぼないんじゃないでしょうか。

一方で既にエンジニアがいる組織では、待遇の問題というのが発生しがちです。新しくエンジニアを採用しようとすると、既存エンジニアとの給与バランスが悪くなってしまう可能性があります。かと言って現状の合わせて採用しようとすると期待するような技術力がある人が採用できないかもしれません。ここも難しい問題です。

またエンジニア採用には戦略が重要で、ここをしっかり考えないと採用はうまく行きません。メディア露出もそうですが、どんな人が欲しいのか、技術力だけではなく人柄などはどうか。逆に技術力だけで採用するか、その場合は既存組織との住み分けなり融合はどうするのかなど、採用する前に考えて決めておくべき事項は多いです。このあたりを考えずに採用してしまうと、すぐに退職してしまったり、会社側は期待した結果を出してくれないと言う不満を覚えてしまうことになります。

採用にうまくいってもそれで安心はできません。エンジニアのキャリアプランに王道がないからです。一昔前は、エンジニア(PG/SE)からマネージャー(PM)になるという話をよく聞きましたが、いまはエンジニアと言う職種も細分化されているので、そう簡単にはいきません。

またよくある話なのが、「マネージャーになったけど現場で仕事したいから転職した」パターンです。どの会社で話聞いてもそういう人が一定数いて、現場でガリガリ開発してるようです。そしてそんな会社の悩みが「マネージャーがいない」というのもある意味納得です。そりゃ「マネージャーじゃなく現場で仕事したい人」を採用してればマネージャーいなくなるよね、と言うのはある意味当たり前の話ですよね。

そうなるとマネージメントできそうな人にマネージャーの役割を担ってもらうことになるんですが、そうすると現場に戻りたくなって転職するという悪循環が発生してしまいます。このあたりもエンジニアのキャリアプランを会社として考えておかないと、エンジニア採用の長期的な解決になりません。

と言うような話がざっとまとまってたので、これからエンジニア採用を始める方や、担当者がいなくて困ってるという方は一度読んでみてはいかがでしょうか。

優秀なエンジニアとは？採用の難しさ

Fri, 24 Mar 2017 14:12:35 +0000

そもそも優秀なエンジニアってどういう人なんでしょうね。採用やってると、いろんな優秀さが見れるんですが、かと言ってそれを測る尺度をたくさん用意するのは運用上不可能です。特に技術やビジネスなど状況が毎週のように変わるので、下手すると尺度もそれと同じ頻度で変更する必要があります。このあたりで失敗してしまうと、いろいろ不都合が生じてしまうこともあるので、ちゃんとした尺度を持っておかないと後で辛いことになります。

一方で「ある意味、優秀なエンジニアならなんでもできる」という話も聞きます。これも間違ってるわけではないんですが、「なんでもできる」ということと「やってもらおうと思っていることをやりたいと思っている」という話は別です。ここも間違いやすいんですが、確かに「一般的な尺度で言うところの優秀な人間」であれば、なんでもできるかもしれないんですが、そのことを見極める方がもっと大変じゃないかなと思ってます。

たとえ見極められたとしても、優秀さというのが決まっているパラメータで、それ以上成長しないのであればいいんですが、まあ普通考えると仕事をしているうちに伸びていく可能性が高い。そうなると今度は伸び率とか到達地点みたいなのも考える必要があって、さらに難しくなります。「この人はいま技術力高いけど、このまま高いままでいられるのか？」などという見極めは、いくら面接で頑張っても無理があるので、銀の弾丸はやはりありません。

また技術力がある人を採用したとしても、会社の文化と合わないと居心地が悪くなってしまい長続きしません。例えばエンジニアは一般的に朝に弱いと言われてますが、朝9時から始まる会社でフレックスはNGみたいな文化だと入ってから苦労するだろうし、やたらと社内イベントがあるのも辛いという話もあるでしょう。これらは良し悪しではなく好き嫌いなので、社内文化との合うかどうかということも重要な要素です。

そんなこんなで優秀なエンジニアの採用は非常に難しいんですが、じゃあどうするかというと、一つはそもそもエンジニアの採用で技術力をそこまで重視しないという方法を取ることです。全く考慮しないのはさすがにナンセンスですが、技術力だけを見ないで成長力や適応力、また社内文化のとのカルチャーマッチを重視する方法です。個人的には技術力よりもカルチャーマッチのほうがなんともならないという気がしているので、ここをミスるとお互いが不幸になります。

もう一つは優秀なエンジニアが入ってくれるように社内文化を変えることです。フレックスを導入したりリモート作業できるようにしたり、社内イベントなどは任意性にしたりと、変えられるところを変えていって受け入れられるようにする方法があります。

ただこちらは既存文化からの反発が大きくなってしまうので、普通はやらないほうが良いでしょう。エンジニアだけがいれば会社が成り立つのであればいいんですが、普通はそうではなりません。総務・人事・経理など、いくらIT化しても面倒なことには変わりません。そんなことを自らすすんでやってくれるエンジニアなんてほとんどいないだろうし、いたとしても「俺が考える最強の社内システム」を作り出して自滅するのがオチです。

個人的にはこの2つの方法を軸に、いろいろ試行錯誤しながら社内体制を徐々に変更しつつ、成長力やカルチャーマッチを考慮した人材を採用するのが良いのではないかと思っています。

ShiftとAuthyが便利

Thu, 02 Mar 2017 10:20:35 +0000

いろんな会社さんと仕事をしていると、複数のG Suiteを使わないといけなくなるんですが、まあ普通にGoogle Chromeのタブで使い分けていました。ただこれだとタブを開かないと見れないし、そのアカウントに対応するカレンダーとかGoogle Driveとかを開くのも一苦労でしたんですが、そこで見つけたのがShiftという、複数のG SuiteやGoogle Accountを管理できるアプリ。

なにが便利って、ElectronなんですがWindows版があることですね。某MMORPGしないといけないので、Windowsは必須なんですが、そこで利用できるというのが大きなポイントです。Rebuild.fmでも紹介されてたんですが、複数アカウント持ちには便利ですね。

あと最近Google AuthenticatorからAuthyに変えました。

いまは業務用と個人用にスマホを2台持ってるんですが、2FAをどちらでもできたらなと思っていたところにAuthyを見つけました。Authyの便利なところはChrome Extensionがあるところで、いちいちスマホ起動しなくてもいいという点。ただこのように複数端末で使えるのでセキュリティ的に弱くなる可能性はありますね。ご利用は計画的にしないといけません :smile:

jpmobileにCircleCIとonkcopを入れた

Thu, 09 Feb 2017 13:20:35 +0000

最初に jpmobile の開発を始めてからもう7年も経つのかと感慨深い今日このごろ。ここしばらくは Rails と Ruby のバージョンアップのたびにいろいろ diff 見て回ったりテスト回したりする日々ですが、手元ではテスト回せるけどまあ割りと準備が必要なんですよね。

と言う訳ではないですが、CircleCIで動くようにいろいろ頑張ってみました。

苦労したことは特に無いんですが、

rakeタスクの中で rails new して `bundle exec rake test` なんてやってるので環境変数リセットする
SMTPサーバ必須だったので、mailtrap.io使うように変更

などが試行錯誤ポイントでしょうか。特にSMTPサーバはCircleCI上でなんとかしようとしたんですが、頑張ってできたとしてもなんか違う感があったので、Webサービスでなんとかしました。

あとはonkさん謹製のonkcopをベースにrubocopも適用しました。jpmobileが GitHub に来たのが2006年、その前は rubyforge で、開発開始から10年以上も経っているので、やはり古い記法とかが多い。CircleCI化するときにいっその事入れてしまうかと導入してみました。

その他、READMEをmarkdown化してみたりなど、jpmobileも自動化、近代化できたかな？というところで、引き続きよろしくお願いします🙇

Cookpad TechConf 2017に参加してきた

Mon, 23 Jan 2017 14:25:35 +0000

応募したら当選したのでCookpad TechConf 2017に行ってきました。

いやー、一般参加者は気楽でいいですねー。みなさんの発表を聞きながら作業とかもできて、いろいろ捗りました。

それにしてもクックパッドってタレントが豊富だなと改めて感心しました。16年入社の新卒が3名も発表していたり、基盤的なところだけではなく、サービス開発やデザインの話があったりと、幅広いトークがあって非常に楽しめました。（という枠組みを一昨年から去年にかけて頑張って作ったかいがあったというものです :)）

また来年も開催してほしいので、アンケート出してない方はバシバシ出しておきましょう。

アンケートはこちら！ https://t.co/TtZcxvuTFX #CookpadTechconf
— Cookpad Tech Life (@cookpad_tech) January 21, 2017

待遇よりも重要なことはあるか - マネジメントの基礎理論を読んだ

Fri, 20 Jan 2017 14:52:02 +0000

ずっと昔に買って読んでなかったマネジメントの基礎理論という本を読んだんですが、部下を成長させるにはどうするべきかなど、いわゆるマネジメントの方法論などが、マネジメント理論に基づいて解説されていて、いろいろ腹落ちして良い本でした。

無理・無意味から職場を救うマネジメントの基礎理論 18人の巨匠に学ぶ組織がイキイキする上下関係のつくり方

著者: 海老原嗣生, 守島基博(解説)
出版日: 2015-03-31
出版社/メーカー: プレジデント社
カテゴリ: Book

例えばハーズバーグの動機づけ・衛生理論は、いままで自分が感じてきたことが理論としてまとまってました。特に、

衛生要因というのは、それがないと不満が高まるが、それがいくらたくさんあったとしても満足や納得にはつながらない要素です。

たとえば、給与が高い、残業が少ない、休日が多い、会社のネームバリューがある、快適なオフィスなどです。いずれも仕事の中身とは関係ありません。

と言うのは、採用をする際にいろいろ考えさせられたことだったので、ここをしっかり分けて理論化されているのは納得感がありました。

もちろん衛生要因が不要というわけではないので、十分な待遇がなければいけませんが、ただ待遇が良いからと言って仕事はなんでもいいのかというとそうではない。高待遇に引っ張られて転職に失敗してた人の話はたまに聞きますが、やはり「動機づけ要因」があるかどうかを見極めることが一番重要だし、採用する側もこの点を用意できるかどうかが重要だなと、改めて感じました。

また、

モチベーションサイクルをつくることで、最終的には会社が儲かるという当たり前のことをマネジャーに理解徹底させていない

仕組みはあってもマネジメントの現場でそれをどうやって実践するかが教えられていない

など、マネージャーの育成についても書かれていて、「あのとき言いたかったことはこれだ！」という気持ちになったりなど、もっと早く読んでおけばよかったと後悔しています。

ホピーパソコン興亡史を読んだ

Thu, 12 Jan 2017 01:20:02 +0000

頂いた本を少しずつ読み進めてますが、とは言えなかなか消化完了は遠い未来な予感がします。

ホビーパソコン興亡史国産パソコンシェア争奪30年の歴史

著者: 前田尋之
出版日: 2014-09-26
出版社/メーカー: オークラ出版
カテゴリ: Book

というわけでホビーパソコン興亡史を読みましたが、いやー懐かしいですね。僕が初めてパソコンに出会ったのは、近所の西友にあったパソコン売り場。そこで見たYsのデモは衝撃的でした。ただパソコンとか買えるほど裕福ではなかったので、本屋でBASICの本を買って方眼紙に書き込み、店のデモ機でプログラム入力してたのを思い出します。店員さんとも仲良くなって、むしろ面白がられてましたね。

そんな中、初めて買ったパソコン雑誌がOh!Xで、思えばここから王道から外れていくことになるんですが、最初はMSX→MSX2+と割と平凡に進みます。その後やっとX68000 EXPERT II→X68030と流れて、いまがある感じですかね。

というところで思い立ってこういうところを見てノスタルジックな気持ちになってきました。

惜しむらくはEPSONの98互換機の話がなかったことですかね。このあたりは版権とかいろいろ問題ありそうだけど、できれば書いてほしかったところ。

とは言え、昔パソコン少年だったおっさんであればものすごくノスタルジック気持ちになれるので、是非読んでみてください。

ハッカーと画家を読んで

Wed, 04 Jan 2017 19:00:00 +0000

読みたいと思いつつ手が出なかったのがこれ。実はなんか周りのエモい人はみんな読んでいるので、逆に敬遠していたやつです。

ハッカーと画家コンピュータ時代の創造者たち

著者: ポールグレアム
出版日: 2005-01
出版社/メーカー: オーム社
カテゴリ: Book

誕生日とかのあれでいただいたので実際に読んでみると、内容はやはりエモい人が好きそうなネタが満載で、非常に楽しく読めました。やっぱり全てはLispですよね。

周りと同じじゃダメで、その上を行くにはどうすればいいのか。エンジニアとしてさらに成長して飛躍するのにはどうすればいいのか。そもそもエンジニアと言う職種がいままでと同じままでいられるのだろうかなど、いろんなことを考えながら読み進められました。

いまはエンジニアと言う職種がある一定層しかなれなかった時代から変わって、むしろ一般的な職業の一つになりつつある気がしています。まあ、どこまでをエンジニアだと言うかという問題はあるかもしれませんが、それでもエンジニアの需要は今後も増え続けるだろうし、そうすると供給が止まることもないでしょう。

そういう時代でも、じゃあ全員に「ハッカーであれ」みたいなことを言って良いのかとは思わず、かと言ってそういう意識を持っていないと将来辛くなるので持ってて欲しいとも思う。特にこれからの時代、職業の一つとしてエンジニア職が選択されるようになったとき、どうすればみんなが悲しい思いをしなくてもすむんだろうかなどと考えることが多くなってきました。かと言って答えがあるわけではないので、これからいろいろ探りつつ仕事ができればなと思っているところです。

他にもいろいろ示唆に富んでいる内容だったんですが、若干時代を感じることがありました。某所でも言われていたけど、まあ時代の流れが早すぎりので致し方ないのかなと言う気がしてます。

というわけで、若い人に読めとは言いませんが、一度は読んでみてもいい本ではないでしょうか（ちょっと雑なまとめ）。

2016の振り返り

Sat, 31 Dec 2016 16:00:00 +0000

いままであまり振り返りは書いてこなかったんですが、さすがに今年はいろいろあったので軽く書いてみようと思う。

仕事の役割が変わった

これは2016年というわけではないけど、仕事の役割が大きく変わり続けた年でした。もともと前職にはサービス開発をやりたくて入社したんだけど、気がついたら人事部にいたという自分でもどうなってしまったのかという感じがする。

しかし人事部での仕事はいろいろ新鮮で、特に採用や評価というのか自分の持っているものを総動員しないとできない仕事だったので、いろいろ大変ではあったが非常にやりがいがありました。

TechConf1回目ができた

やろうやろうという話だけは出ているが実行できなかったのを開催できたのは達成感がありました。特に某Kaigiの用に毎年開催できるようになるべく省力運用できたのは、その某所での経験が生きましたね。

来年は2回目が開催されるので、

退職した

そんな最中、ほんとにいろいろあったので前職を退職することにしました。退職しようと決意したので4月頭ぐらいだったので、辞めるまでに半年ぐらいかけたことになります。まあ役割とか影響範囲を考えてのことでしたが、その間にもいろいろできたので、結果的にはよかったのかなという感じです。

起業した

特に「このサービスをやるぜ！」というわけではないですが、会社作りました。退職する話をするとよく「受け皿としての会社を作っといたほうが良い」的なことを言われ続けた結果、作らないとダメなような気がしたんですよ。と言うのはさておき、会社を作る経験は社会を知る上でもいい勉強になっています。面倒だけど。

業務委託をはじめた

退職して起業したとは言え、やることは業務委託エンジニアなので、まあ要するにフリーランスですね。最初はコード書く仕事を某所でさせてもらっていたんですが、やっぱりコード書くのは楽しいですね。それ以外は採用のお手伝いや組織全体のことなど、幅広くお手伝いさせていただいています。

ただ時間を切り売りするようになって、スケジューリングの重要性を身にしみています。来年はこのあたりをもっとしっかりやって、ゆとりある感じで仕事していきたいと思っています。

来年に向けて

ひとまずは仕事のペースをしっかり作っていきたいですね。いまは若干流され気味なので。それ以外はなんでも良いので一つ大きなことに挑戦してみたいです。とは言え何とは決まってないので、それも考えながらですかね。

というわけで、いろいろありましたが今年はありがとうございました。

感情労働シンドローム

Fri, 16 Dec 2016 23:08:52 +0000

頂いた本を読み進められていないことに申し訳なさを改めて思ったので、聖典ためたりサブキャラ育てるのそこそこにしてもうちょい頑張ってみようと思った年末。みなさんいかがお過ごしですか。

そしてそんななか、若者から最近読んで良かったと聞いた本を先に読んでしまいました。

感情労働シンドローム (PHP新書)

著者: 岸本裕紀子
出版日: 2012-10-16
出版社/メーカー: PHP研究所
カテゴリ: Book

今の世の中、特にいわゆるITとかWeb系とか言われている業界では、定年までいるなんていうのは幻想でしかない状況。そんな状況で「下積みも大事」とか言われても、それがどう活かされるのかがわからないから「もっと実践的なことを」と主張する。「10年働いて一人前」と言われても、「10年もいる予定はない」など、ひと昔前の状況とはかなり変わってしまっています。

またその若手を部下に持つ上司も、対応方法が変わったことについていけなかったりなど、社会構造の変化が早すぎて追いついていない人が多い。

じゃあどうすればいいかというと特に答えはないんですが、これからの社会を考える上ではこの「感情労働」という観点を持って挑まないと、若い人も年配の人もどちらも辛い目に合うのではと感じました。これらを「感情労働」という観点でうまくまとめてあって、いろいろ理解が進んだ書籍でした。

合同会社を作ってみました

Tue, 11 Oct 2016 00:00:00 +0000

10月からフリーランスで仕事をしているわけですが、いろいろあって合同会社を設立することにしました。

レジャリーワークス合同会社

理由としては、まあ前から会社作っといた方がいいよ的なお話を聞くことが多かったというのもあります。また個人事業主としてやっていくとしても経理的なことはいろいろとやらないといけないですし、いまならクラウド会計ソフトとかあるから会社としてやっていくのでもいいのかもしれないと思ったのが一つ。あと一度は会社を設立する経験をしてみようと思ってはいたので、いろいろあった今がいい機会かも？と思ったのがもう一つ。あと設立費用もそんなにかからないことがわかったのも大きな理由でもあります。

そんなわけで、「レジャリーワークス」という名前の合同会社を設立しました。名前は、悠々と仕事ができる世に中になるといいなと思い、ゆったりとした（leisurely）仕事（work）を語源としています。worksと複数形なのはゴロが良いからです :)

とは言え作ったばっかりでまだまだこれからやること多いのですが、あまり焦ることなく少しづつ整えていきたいと思っていますので、暖かく見守っていただければ幸いです。まずは会社HPの整備からやらないとな…

と言う訳で、これからもひとつよろしくお願いします。

クックパッドを退職しました

Sat, 01 Oct 2016 00:00:00 +0000

2016年9月30日付でクックパッド株式会社を退職しました。2013年3月入社なので、かれこれ3年7ヶ月在籍していたことになります。最初の2年ぐらいはサービス開発エンジニアとして普通にコード書く仕事してたはずなんですが、気がついたらマネージメントや採用中心の仕事をしていました。まあいい仲間がいたからか、非常に充実した仕事ができていたと思っています。

みなさん気になる退職理由とかは、飲み会とかで個別に聞いていただければお答えしますが、たぶん聞きたいような答えじゃない気もするので、あまりwktkしないようにしていただけるとありがたいです。

と言う訳で例のやつおいておきます。

https://www.amazon.co.jp/registry/wishlist/2U0WK80HNEJWN

来月からは心機一転、フリーランスエンジニア？としてお仕事をする予定でいます。経験としてはエンジニアの中途採用や新卒採用のビルドアップとか、エンジニア評価など、組織に関することが一番役に立てそうな気もしてますが、コード書きたい気持ちも強いのでそっちもやりたいと思っているところです。仕事頼みたいという方は、ひと声かけていただけると。

Microsoft Sculpt Ergonomic Keyboardを買ってみた

Tue, 30 Aug 2016 00:00:00 +0000

ちょっと腱鞘炎ぽい症状が出てきたのでエルゴノミクスキーボードを物色してたんですが、大体3万以上と割と高い。分割式だとちゃんとしたタッチタイピングできていないと思うので、最初辛そう。費用対効果考えると躊躇してしたんですが、Microsoftが出してる

Sculpt Ergnmc KB for Bsnss Blk

著者:
出版日:
出版社/メーカー: Microsoft
カテゴリ: CE

というのを買ってみました。実際にヨドバシとかで触ってみてキーの感触は問題なかったんですが、意外なほどちゃんとタッチタイプできていなかったようで、いろいろ辛いです。特にC-bのbを右手で押しててようで、日常的に不都合が起こっています。

まあこれに慣れたらErgodoxとかに挑戦してみたいので、訓練だと思って頑張ってみようと思ってます。