あなたが成功したいならプライドを飲み込み、外に出ていって、自分が馬鹿に見えるのを恐れないようにしなければならない

最近(もう一ヶ月くらい前)、今更ながらソフトスキルズという本を読んだ。

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

この本場が話題になったのは去年の前半くらいだったと思うんだけど、買った後ちょっと読んで、忙しくなって積んでしまっていた。 あらためて読んだんだけど、タイトルにもした一文が自分的にはいい話だったのでブログにしておく。

あなたが成功したいならプライドを飲み込み、外に出ていって、自分が馬鹿に見えるのを恐れないようにしなければならない

結構自分は「自分をよく見せようとしすぎる」ところがあるなーと思っていて、そういう気持ちが何となくイベントにでて発表したりといったところに億劫になっていた気がする(あんまり失敗したくない・・・恥かきたくない的な気持ち)。

自分は影響されやすいので、この本を再度読み始めた直後に会社にお誘いのあったイベントに登壇してみることにした。 (以下が資料) speakerdeck.com

上記の資料はまあ正直フロントエンドガチ勢の人からするとそんなに参考にならないないようだった気がするし、 反省会というタイトルに引っ張られすぎて辛い内容を盛り込み過ぎたなぁと反省するところも多い。 あと結構当日までビビってて行きたくねーと回りに言いまくっていたりしたｗ

でもイベント終わったあと色々情報交換したいということで話に来てくれる人がいたり、 他の勉強会とかでお会いしたときに話掛けてくれる人がいたりして、今は登壇してよかったなーと思っている。 (Wantedly経由のお話しませんか的なやつの数も気持ち増えた)

【再掲】あなたが成功したいならプライドを飲み込み、外に出ていって、自分が馬鹿に見えるのを恐れないようにしなければならない

自分が成功しているとはまだとても言えないけど、外に出ていってみることで、色々分かることとか、広がるチャンス的なものがあることはかなり実感できた。今後もイベントがあったら登壇していきたい。とりあえず来週は、最近はじめたGo言語のイベントに出てみることにする。

最近Golangを触っている話

今更ながら趣味でGolangを触り始めた。家庭内アプリ用のAPIサーバとしてGolangを絶賛書いている。アプリはReact Nativeで書いていて、それはまた別の機会に書くことにしよう。

実は一年前くらいにもちょっと触っていて以下のような本を読みつつ、簡単なアプリケーションを作ろうとしていた。

Go言語によるWebアプリケーション開発

スターティングGo言語 (CodeZine BOOKS)

が、ちょうど仕事が忙しくなる時期と重なってしまったり若干モチベーションが落ちてしまったので、最近まではRailsにずっぷりだった。

Golang楽しい

一年ぶりに触り直してるんだけどとても楽しい。前回多少学習していたという貯金が効いている説、この1年で自分が成長している説などあるけど、明らかに前回触ったときより楽しい。 具体的には以下の辺が。

• gofmt、golint… などで書き方をかなり強制されるので迷わず書ける。
• ので、どうロジックを書くかといった部分に集中できる。
• フルスタックなWAFのようなものはないので、自分で色々設計について考えられる(考えなければいけない)
• (これは完全に自分の個人的な感想)ちょっと書く行を減らすためのハックより、愚直に書くことが好ましい雰囲気があるきがしていて、愚直に書けばいいやーという気持ちになる
• 「それ標準パッケージでできるよ？」といったマッチョな思想があるきがしていて、ベストプラクティスを追い求めなくてよい(と、いいつつ、 echo や gorm を使っているけど…)

ここからは静的言語ならどれでもそうなんですが

• コンパイルが通れば、大体動くという安心感
• エディタ上で型、引き数が補完されるので、一々リファレンス眺めなくてよい

SIでJavaやってたときも同じメリットはあったはずなんだけど、全然思い出せないし楽しいと思ったことあんまりないな。なぜだ。

なぜ一年前はあんまり楽しくなれなかったのか

たぶんGolangでRubyっぽいことやろうとしていた。Golangにはクラスがなくて構造体しかない。で、構造体を利用して、オブジェクト志向っぽく書く方法はいくつかあるにはあるけど、Rubyと同じような作りで書けるわけではない。なのに一年前はRuby(というかRails)のような書き方をしようとして、色々調べた結果うまく書けずそこでやる気が失われてしまった部分はあると思う。

Goに入ればGoに従え

今回はアプリケーションを書き始める前に、GitHubでいくつかrepositoryを見てみたり、いくつかブログを読んだりして、みんなどんな書き方をしているのか見て回っていた。そのおかげで、Golangではどう書くのかーというところをある程度インップットできたと思う。GolangをGolangらしく書くことで、楽しくなったきた気がする。

Golangからの学び

Golangで今更ながら型の有り難みを噛みしめるようになった。エディタの型補完や、コンパイルが通ったときの安心感とか。 型のある言語からRuby/Railsに来た人が「型がないのが怖い」的なことを言う理由がちょっと分かった。自分がJava => Ruby に行った時には型がなくて怖いなんてことは思わなかったんだけど何で今更こんな感覚を持っているんだろうな・・・。Golangで書くようになって、インターフェース的なものを前より意識してプログラミング書くようになった気がする。

React NativeでJS書くときもflowをちゃんと使うようになった(前は使っていたけど面倒になってやめてしまった・・)。ライブラリの選定も「これくらいなら自分で書けばいいかー」という思想になってきた。

まとめ

お気づきの通り、Goに入ればGoに従え を言いたかっただけの記事です

最近アプリケーションの設計するときに気をつけてること

最近、機能の設計をレビューしたり話し合ったりするときに、うん・・・？ってなることがあって、でも駄目な理由をうまく説明できなかったのでちゃんと言語化してみる。ちなみにRailsの話です。

DBには事実だけを記録するようにする

色々開発してきて思ったのは、テーブルに状態を持たせるようにするとあっという間に複雑度が増してしまうということ。 status カラムや hoge_flag みたいなカラムを持つこと自体は全然否定しないけど、本当にそれが最適なのかは慎重に考えた方がよいと思う。

これは例ですけど、会員申し込み => 何か審査 => 会員登録完了 みたいなフローのアプリケーションを作る時に、会員情報のテーブルを１つだけ作りstatus 、approved_at みたいなカラムを突っ込んで、申し込み状態と申込み完了状態を アプリ側で頑張って判定しようとしている例はまれによくある。

こうすると何が辛いかというと、他のレコードから関連を辿って参照しようとしたときに常にレコードのカラムの状態を気にしないといけなくなってしまう。それに申し込み時の情報と、会員登録後に必要になる情報は必ずしも一致しないはずなので、作ったときは同じだとしても後々拡張するときに辛くなってくる。また、会員情報にDB上のユニーク制約をかけたくなっても掛けられないのでアプリケーションでかけるしかなくなる。(そしてアプリケーションで掛けた制約は結構簡単にすり抜ける…)

こういうときは事実が何なのかに着目すると、きれいに設計ができると思う。今回でいうと申込み というテーブルと 会員情報 というテーブル二つに分けてしまう。そうすれば上記にあげたような懸念はスッキリ解決する。 同じようなカラムが二つのテーブルに別れることを懸念するかもしれないけど、本来違うものを同じテーブルに押し込むことのデメリットの方が大きい。

同じような理由で論理削除もよく考えたほうがよいと最近は思っている。削除という状態を追加するよりも、素直にそのテーブルからデータは消してしまい、必要な情報だけ履歴的に別のテーブルにコピーしておいた方がアプリケーションをシンプルに保つ事ができるとおもう。

安易にHashを作らない

「Rubyはダックタイピングなのでそんなに厳密にやってもしょうがない」みたいな話は一定理解するし、そういうゆるさがRubyのいいところだと思いつつも、巨大なHashを作ってそれを色んな所に引き回したりするのは結構最悪だと思うようになった。Hashに何が入っているか、何のkeyを持つべきなのか実装を全部追わないと分からないからだ。

そしてHashが巨大化していくると、そのHashを操作するための実装がそのHashを引き回す側に出てきたりしてあっという間に良くない感じになっていく。

何かを作る場合も、ハッシュではなく、クラスを作ってそこに attr_accessor を定義したほうがよいと思う。そうしておけば、クラスを見ればどんな値を持つべきなのかすぐに分かる。それに、値の中身を書き換えたり、デフォルト値を与えたり、変換したりといった処理をそのクラスに押し込めていくこともできる。

まとめ

最近考えたことをまとめてみた。定期的にこういうの考えて吐き出しておきたい。

メンターになって1on1をやることになったので「ヤフーの1on1」という本を読んだ

ヤフーの1on1という本を読みました。

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

何で買ったのか

新卒の子のメンターになって、1on1を週次ですることになったので。今までもマネージャーの人と1on1は普通にしていたけど、そもそもどうやってやるものなのか自分自身よく知らないなと思って買ってみた。

感想

ヤフーの宣伝的な要素が結構多いのかなーと思ったけど、中身はおもったよりも参考になった。1on1といっても組織によっても位置づけは当然異なるんだろうけど、相手に「自分で考えて学びを得てもらう」ことが大切っぽい。なので上司やメンティーの立場から、安易に相手の考えを否定したり、こちらから答えや意見を出してしまうのは基本的には望ましくない。相手に考えてもらい、自分で課題ややりたいことに気づいてもらうことが大切ということだった。

自分自身のこれまでの1on1を振り返って、「◯◯さんはどう思う？」みたいな質問を何度も返されることがあって、「いや、こっちはあなたの考えを知りたいんだけど・・・」と思うことが結構あったんだけど、それは今思えば自分で考えて答えを出して欲しい、みたいな思いもあったのかもしれない（確認したわけではないので違うかもしれない）。相手の意図はわからないけど、何というか自分で考えずに相手に委ねようとしていた部分があったなーと思ってちょっと反省した。

で、実際にやってみて

予想以上に、「相手に考えてもらう」ように会話を進めるのって難しい。これまで普通に話してるときは意識してなかったけど、結構相手の意見を聞く前に自分で意見を言ってしまったり、自分の思う答えを先に出してしまおうとしていたことに気がついた。

そして実際に相手に考えてもらうように1on1を進めていくと、「A」だと思っていたやりたいことは実は「B」だった、とか「C」が自分の課題と思っていたけど実は「D」の方が課題だった、みたいなことが結構クリアになってくる。コレは自分が「A」と聞いたときに、先輩目線で適当なこと伝えていたら出てこなかったことだと思うので素直に驚いた。

マネージメントみたいなこと、正直全然興味なかったんだけど、これはこれで結構面白いなーと思ったのでした。(1on1がマネジメントと言えるのかは分からないが…)

2016年の振り返り

2016年の振り返りをします。

ちなみに去年はこんなこと書いていた。 suzan2go.hatenablog.com

2016年の振り返り

仕事で一からサービスを立ち上げた

仕事で1からサービスを立ち上げました。一昨年は既存のサービスを別WEBサイトとして立ち上げるということをしたんですが、本当に全く新しいWEBサービスを立ち上げるのは初めての経験でした。立ち上げまで殆どの期間でエンジニアが自分ひとりだったので、全体のモデル設計、決済関連の実装とか中々経験できないことを経験値として積むことができました。

プロダクト開発について色々考えた

仕様を考えるにあたって、それをやるべきかどうか判断するためのデータも少ない状態で作るのは本当にしんどかった。リーンスタートアップ的な考え方って正直あんまり好きじゃない部分もありました(いやいやちゃんと作れよ…的な)。が、正解が何か殆ど判断できない状態で作り込んでも無駄が多いっていうのは本当に実感したです。実際リリースしてから機能が全く使われない or KPIには寄与しないところを議論しまくって作ってたりとかしてました(たらればも少し入ってるかもしれないけど)。

• ただ、「小さくリリースしていく学習する」ことを掲げるだけではだめで、そうすると「これ大変だから仕様削ろう」みたいな話になりがち
• MVP(Minimum Viable Product)が考えられてないと、本当は優先度が高い機能が削られたり、サービスの立ち上げ時にはさして重要じゃないものに時間を掛けてしまったりする。
• そんで、MVPをチームで考えるときには「解決する課題の仮説」をもっていないといけない。これがないとMVPがふわっとして、結局「競合はやってるからやった方がいい」「過去サービスでこれをやって◯◯が向上した」「◯◯さんはこれやった方がいいと言ってる」みたいな、そりゃやったほうがいいとは思うけど…みたいなことでいっぱいになってしまう。

みたいなことを学んだのでした。

以下のスライドははてブかtwitterで見かけたのですが、何かもう心当たりのあることしかなくてｳｯってなりました。 speakerdeck.com

Reactを沢山つかった

なんかもうReactを使うこと自体は特に珍しいことでも何でもないですが、技術的にはReactをかなり積極的に採用しました。以下の記事にも書いたんだけどrailsとの組み合わせでReactを使うとき、かつwebpackなどを使用してSprocketsを使わない場合にはreact-railsじゃなくて、react_on_railsを使った方が色々捗ると思う。というわけでreact_on_railsを使ったです。

github.com

suzan2go.hatenablog.com

Reactを使ったこと自体には後悔していないんだけど、使い方には後悔があったり。react_on_rails (react-railsでもほぼおなじ)では、以下のようにReactのコンポーネントをERBやSlimに埋め込めるので、普通のrailsのテンプレートとReactを共存させることができますが、これをあんまりやらないほうがよかった。

.hoge
  = react_component ‘HogeComponent’, props: { pico: ‘hello' } 
.user
  = @user.username

既存のサービスならともかく新規のプロダクトでReactを使うなら、全部SPAとまではいかないまでも(実際そこまでの工数は掛けられなかったが…)あるネームスペース配下のURLでは全てSPAにするとか、ヘッダー・フッター以外は全てReactでrenderするとかにするべきだったなと。ReactにしてもReduxにしてもやっぱりSPAを前提にして作られているものだと思うし、上記のような使い方はどうしてもエコシステムに乗り切れない感じがした。

設計について色々考えるようになった

サービス立ち上げとも絡む話ではありますが、設計について色々考えるようになりました。この冬色々話題になったサービスクラス、railsのconcernなど、プログラムのテクニック的な捉え方しかしてなくて設計観点でどうかということは正直意識が低かった。ビジネス要件が大きくなって実装が複雑になっていったときに、どうしてもアプリケーション側のテクニックで何とかしがちだったのですが、あるべきデータの形が何かとか、モデルの責務としてどうかとかそういうことを何となくではなく意識して考えるようになったのでした。その辺りの話は以下のアドベントカレンダーをどうぞ。

qiita.com

今年はDDDとかオブジェクト志向とか改めてちゃんと勉強していきたい。

キャリアについて考えるようになった

まだまだ若手枠のつもりでいたのですが来年30になるということで、気づいたら中堅になってた…そりゃ「どういう方向性に進んでいきます？」ということをよく聞かれるわけやｗ

良いプロダクトを生み出すには技術力だけでは駄目なんだということはよくわかったし、チームで良いパフォーマンスを出していくにはジャーマネ的な動きが大切なのだということがよくわかった一年ではあったものの、やっぱりまだ自分はエンジニアとしてコードを書くことを一番していきたいというのが正直なところ。

去年子供が生まれてライフスタイルが大きく変わった。自分に費やせる時間は圧倒的に減っているので今後の生存戦略を本気で考えないといけない。

2016年を振り返って

正直関わっていたプロジェクトは結構ハードで、良いことばかりではなくどちらかというと反省の方が多いのですが、それでもサービスの立ち上げというものを経験できてよかったと思います。 一昨年はSIerから転職してきて何とかWEBエンジニアとして頑張っていこうというところでしたが、去年はWEBエンジニアとして自分の価値をどう出していくか考えていた一年でした。自分の価値が出せたのかというと結構微妙なところな気はしているので、今年は明確に見える成果を出していきたい。

今年の抱負

雑ですがこんなことことを考えています。

社外の人に会う

去年は社外の勉強会にあまり参加できなかったので参加したいというのと、もっと社外のエンジニアの人と色々話してみたい。いろんな会社のRails Wayを知りたい。そして自分がどんな位置にいるのかを把握していきたい。

機械学習でなにか作る

アドベントカレンダーの以下の記事が割と衝撃的だった。WEBだけやっていても自分の市場価値はもう上がっていかない感が凄いので、色々手を出して行きたいと思います。 qiita.com

React + Redux + Railsのサンプルを色々アップデートした

アップデートしたのはこれ。 react-rails と redux を同時に使うためのサンプルです。 github.com

公開する時期が早かった(2015年の8月)せいか、謎にスターが100個以上ついてる。有難い。 (当時はReduxがまだ流行り始めたころで、Railsと組み合わせて使ってるようなサンプルが無かったから…と思う)

使っているgemは以下。

• browserify-rails
• react-rails

こんなサンプル作ったけど、仕事ではこの構成で運用してなくて、JS/CSSのビルドとして Sprockets は使わずに、 webpack を使う構成だったりします*1。

browserify 自体の開発がもうあまり活発には行われていないっぽい(さらにrails 5.1 では webpack のサポートが入る*2… )のと、 個人的には react-rails よりも react_on_rails *3 の方が色々都合が良い( HMRがやりやすいとか、コンポーネントをグローバルに置かなくてよいとか、AuthenticityTokenをポストする方法がサポートされているとか )と思っているので、このサンプルの構成自体ちょっと微妙ではあります。

が、react_on_rails の方にはかなりしっかりした Redux を使ったサンプルコードがあるので*4 、 react-rails でうまくやる方法はまだ一定需要があるかなと思い、色々アップデートしてみました。

Railsを4.2から5.0.0.1に上げた

ほぼ中身のアプリケーションがないということもあるけど、何も困らずに上げられました。特筆することも特に無いｗ

テストを追加した

こんなIssueを貰っていたので、テストを追加してみた。 github.com

E2Eのテスト

対象のコミット

普通にcapybaraとseleniumで。仕事でもハマったのですが、 firefoxの47以下でないとselenium-webdriverが動きません。。以下、 capybara の公式より引用です(2016年12月18日現在)。

Note: Firefox 48+ If you're using Firefox with selenium-webdriver and want full functionality stay on either Firefox 45.0esr or 47.0.1. If using selenium-webdriver 3.0+ this will require configuring your driver with the marionette: false option as shown below

本当は Poltergeist のようなヘッドレスブラウザの方が良さげですが、それそれでハマりそうだったので一旦仕事でも実績のある構成にしました。

JS単体のテスト

対象のコミット

正直、テストのライブラリだけでも色々あって何が良いとか全然わからないのですが、過去ちょっと触ったことがあって今も流行ってるっぽい enzyme で書きました。 github.com JSDOMを使ったテストのセットアップはほぼ以下を参考にしています。 github.com

正直、ESEのテストがあればJS単体のテストってそこまでいらない気もするのですが、どうなんですかね。オートコンプリートとか割と複雑なコンポーネントを自分で書いた場合には確かに欲しい気もしますけど…フルSPAとか書いたりするとコンポーネント毎のテストが欲しくなったりするのだろうか。

---

サンプルとしてはかなりシンプルなので(Redux公式のカウンターアプリそのまま)、もうちょっと色々肉付けしたい感ある。 仕事で使った時便利だったRedux Formとかそういったライブラリも混ぜて、もうちょいリアルなアプリケーションにしていこうかな。

*1:http://engineer.crowdworks.jp/entry/2016/05/24/174511

*2:https://github.com/rails/webpacker

*3:https://github.com/shakacode/react_on_rails

*4:https://github.com/shakacode/react-webpack-rails-tutorial

【その「エンジニア採用」が不幸を生む】を読んだ

その「エンジニア採用」が不幸を呼ぶ という本を読みました。

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

何故読んだのか

ブログやtwitterで見かけたので。 Rubyエンジニアの採用戦略について話した - pblog

自分は会社で採用に関わる立場ではないのですが、今後のキャリアとかちょっと考えるきっかけになったりするかなと思い、買ってみました。 (結論からいうと、そういう観点ではそこまで参考になる部分はなかった)

感想

いくつか印象に残った点をメモ。

経営課題をエンジニア採用で解決しようとする落とし穴/エンジニアの募集要項が書けない人事

えーこんなひどい経営者/人事いるのか・・・という感想です。目的はないけど100人エンジニア採用しようとする、「よくわからんけどクラウドサービス作りたい」でよく分からんままエンジニア雇っちゃう経営者とか、エンジニア募集要項のよくわからないところを勝手に削っちゃう人事…とか。自分のいる環境って結構恵まれてるんだなと思いましたw

現職エンジニア、転職時の希望職種は「特にこだわらない」が50%

えーこれは本当にそうなのかーって思いました。少なくとも自分の観測範囲にはいなかったなぁ。 自分がSEやってたとき「SEやめてー」はよく思ったけど、すくなくともエンジニアではいたかったので。

エンジニアを2つのタイプ、4つのグループで分類する

自由な開発環境(タイプA)と、ガバナンス優先の開発環境(タイプB)という2つのタイプ、技術×志向×経験でレベル分けした1〜４までのグループの組み合わせ8つのセグメントにエンジニアを分類して採用を考えましょう、というお話でした。これ、最近よく聞くようになった SoR/SoE とかも絡んでくる話な気がします。

20代の開発経験がタイプAとタイプBのどちらかになるかに大きく影響するとあって、自分はどっちなんだろうと思いました。 タイプBの開発環境にいた期間は長いですが、それにフラストレーションがたまって転職したところはあるので、現在でいうとかなりタイプAだと思われる。でもタイプB的なところを最近評価されることが多い気もするので、どっちとも言えない。

優秀なエンジニアはSNSつながりで転職する

何となくそうだろうなとは思ってましたがやっぱりそうなんだなという感じ。でも、人材サービス会社経由で見つけるのが難しくなっているレベルだとは思わなかったです。自分もSIerから転職するときにはリクナビやら◯◯ナビ系にはいくつか登録しましたが、いま転職するとしたらきっと登録しないだろうな(自分が優秀かどうかはさておきｗ)。

---

久しぶりにブログ書いた。本を読む熱が上がってきてるので、また読んで書こう。 次はじょーかーさんのqiitaで読めって言われてた以下の本を読もう。

オブジェクト指向設計実践ガイド　?Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方