読者です 読者をやめる 読者になる 読者になる

suzan2号の戯れ

SIerでインフラSE⇛WEB系でエンジニアのおっさん

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になるということで、気づいたら中堅になってた…そりゃ「どういう方向性に進んでいきます?」ということをよく聞かれるわけやw

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

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

2016年を振り返って

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

今年の抱負

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

社外の人に会う

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

機械学習でなにか作る

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