takuwan's blog

感じたことを書きますよ

2019年以降における、フリーランス・スタートアップの経済的リスク

株式投資を少々やっていることもあり、最近マクロな経済指標が芳しくないことに目がいってしまいます。

自分はいまフリーランス(個人事業主)の立場で、0 → 1の事業を伸ばす仕事(スタートアップの立ち上げ)に複数携わらせて頂いています。私のクライアントにとっても私個人にとっても、こうした経済状況はリスクとしてちゃんと認識して立ち回らないといけないなと考えていて、さらっと頭の中を整理します。

(雑にさらっとまとめるうえ、私はソフトウェアエンジニアであり、経済は専門ではないので、内容の保障はしかねます。というか、自分でもググってほしいです。ただの素人の一解釈なので。)

 

 

いま起きていること

個人的に頭に残っている、マクロな指標やニュースについて。

貿易戦争

まず挙げるべきはトランプ・ショック、また米中の貿易戦争にはじまる保護主義経済政策の流れがありますね。

保護主義政策をとって一番損をしないのは米国になるという試算がトランプ陣営にあるのではないかとか、各媒体で喧々諤々と議論されていますが、とりあえず景気の悪化につながっているのは間違なさそう(ググったら色々記事は出てくるので割愛)。

自分はまだ実感ないのですが、父とLINEで通話するたびに「トランプやばい」みたいな話を聞かされるので、実感がある業界に身を置いている人には只事ではない模様。

 

国内不動産のバブル

SUUMOなどで23区のマンション価格を見ていただきたいのですが、都内2LDKで億超えとかが普通な価格帯になっていて、たとえ年収1000万円あってもそうそう手を出せない状態になってます。

新築マンション市場は、マンションを建てても売れないのが見えているので低迷するという予測が一般的ですが、とはいえ中古マンションですら結構高いという...

マンションの価格は2013年から上昇し続けており、どこかで弾けると思いますが、日銀の金融緩和終了(金利の上昇)がきっかけにもなりそう。さらには、金融緩和の終了するタイミングとしては、黒田総裁退任、安倍政権交代、金融緩和の限界としてソブリンリスク顕在化とか色々ありそう。住宅ローンの金利が上がったりするので、そうするとマンション価格が一気に下がる見立てでいます。(というか、このゼロ金利政策は麻薬みたいなもので非常にやばいものに思えます。)

下記のちきりんさんのブログが一番わかりやすく分析されているので、ご一読をば。

chikirin.hatenablog.com

 

個人的には、中古住宅の売買領域は大手の寡占市場なので、市場が低迷したときに次に何が起きるのか非常に楽しみです(狙っています)。


海外不動産の価格高騰

海外の住宅価格も高騰してます。
Zillowは日本でいうSUUMOみたいな米国大手の不動産メディアで、そこが色んなレポートを出してます。下記リンクではカルフォルニアの物件価格に関する情報がざらっとグラフ化されていますが、2013年以降の各指標の伸びが凄いです。(価格が高騰してます。)リンクはカルフォルニアのものですが、それ以外の主要都市もだいたい似たような感じです。

https://www.zillow.com/home-values/

米国の不動産価格がバブルなのかは、私は現地にいないこともあって確信をもった判断はできないのですが、賃貸契約の比率が上がっていたり、米国の友人は「家高すぎて買うなんて無理だぜ」みたいなこと言ってたのもあり、米金利の上昇は米国の不動産業界にとって痛手になるのは違いなさそう。既に米国は金利あがってますが、パウエルさんがこんなこと言って牽制してたのが印象的です。(金利は上げたいけど、上げたら景気が悪化するのもわかってるから、ほどほどにしますよとアピール。)

jp.reuters.com


景気循環論

近い将来景気が悪くなるんだろうなと自分に妙な納得感を与えてしまったのが景気循環論で、景気は良くなったり悪くなったりを定期的に繰り返しているよねといった理論です。

詳しくはマクロ経済の教科書なりググったりしてもらいたいですが、この論に則れば、そろそろ景気後退してもおかしくなさそうな感じです。(自分が説明しても多分間違った説明になりそう。)

立ち読みした東洋経済やらエコノミクスやら、諸経済誌でも景気循環を論拠の一つとして景気後退が予測されていたので、わりとメジャーな解釈だと認識しています。

 

その他

オリンピック需要、最近原油価格が急落していること、消費税増税などなど

 


不況下での立ち回り方

スタートアップ(起業しろ的なやつ)、フリーランス、さらには副業(複業)とか色々流行っていますが、上記のような景気の悪化リスクが顕在化しつつある中で、どういう動きが取れるだろうかと簡単な考察です。

 

スタートアップ

資金調達環境が悪くなり、現在のような高いバーンレートを維持できなくなります。最近はそこらへんの普通の人でもエンジェル投資家としてベンチャーを探し回っていたりしますが、そういうエンジェル投資家は一気に減りそうです。(所謂スタートアップ村的なところにいそうな人たちは、そういうことを既に言ってます。)

いまはバリュエーションばかり高くて実態がないスタートアップは意外と少なくないですが、そうしたスタートアップは力尽きて無くなるでしょうし、また赤字を掘ってばかりでマネタイズできていない小規模スタートアップも、いまの調達環境なら調達できても、不況下では調達できず無くなるところも増えるでしょう。株価も冴えないので、IPOせずプライベートカンパニーとしてしばらくやっていく企業もありそうです。

スタートアップにとって不況はメリットとなることもあると思っていて、よりユーザーのペインに刺さったプロダクトが生まれやすい環境という捉え方もありそうです。(ちゃんと課題の解決になっていないものは、シビアにお金を払ってもらえない。)MSは石油危機の最中に生まれたらしいですし、結局はアイデアと創業者次第。

ただ、ハイリスク・ハイリターンなアイデアと、ローリスク・ローリターン(そこそこ儲かるよう)なアイデアがあるとき、今だったら間違いなく前者を真っ先にやるけれども、後者から取り組んで死なない体力をつけてから前者に取り組む、という選択肢を取ることで失敗のリスク低減を図るスタートアップとか増えそうですね。マネタイズしながら検証を進められるアイデアが好まれたり、受託しながら進める企業が増えたりとか。

いまはわりとふわっとスタートアップに転職している人が少なくないように感じていますが、今後スタートアップに転職するなら、①ユーザーのペインにちゃんと刺さっているのか、②事業としてグロースできるのか(マネタイズできるのか)をシビアに見定める必要があるように感じます。(実態は微妙なのに無理やりExitさせる例はいまよりずっと減るでしょうから。)

 

フリーランス

リーマンショックの経験者に聞く限り、基本的には仕事は減るし単価は落ちます。一般的なフリーランスは、2018/12現在の単価を維持したままだと仕事を受注できなくなります。

私と縁がある某社ではリーマンショック当時外注コストをかなり切っていて、プロジェクトは幾つも中止されたりと、経験者はみな「ひどかった」と口にしています。

いまはフリーランスエンジニアの結構な割合の人がSESで大企業に入って働いていたりしてますが、いつでも契約を切れることを重視してSES契約を結んでいる大企業もあるので(そういう企業を知っているので)、重要なロールを担っている人以外は契約が終わる可能性が少なくはないです。(過去にそういうことがありました)。リーマンショック時は、腕のある人のみフリーランス(エンジニア)でやっていけたとのことで。

20代だとフリーランスになるほうが手取りが増えるというので、フリーランスになる人が多い(お勧めする・煽る人も少なくない)ですが、歴が浅いジュニアレベルの人は、今のうちにビジネスが確立している大企業・有望企業に正社員として入ることをお勧めしたいと思ってます。強い人は、不況もなんのそのでしょう。

 

副業(複業)

リーマンショックの経験者に聞く限りだと、今後の景気悪化と共に単価は結構下がるだろうと考えられます。が、正規雇用されている分収入が途絶えるリスクは少ないと思われるので、副業は一生懸命続ければ良いのかなと思ってます。

ただし、副業をする際には青色申告を税務署に提出して個人事業主になる人が多いと思いますが、個人事業主は失業保険を受けられなくなるのでそこだけ注意です。

失業保険を受給しながら転職活動をする人は自分の周りにはちらほらといますが、景気の良し悪しとは関係なく、青色申告が提出されているとそういう動きは取れなくなります(退職直前に廃業届だしても受給できるのかもしれませんが、私は知りません)。副業のデメリットとしてもっと語って良い点だと思っています。

 

 

私はどうするのか

こう色々考えはするわけですが、結局のところ自分の想いは変わらないわけで、こうした考えを周囲に伝えつつ、引き続き0→1をつくり続けていきます。

ウェブ・アプリから組み込み系ソフトウェアを扱うTips

ウェブやiOS・Androidのアプリケーションから、プリンタ・POS・体重計などのいわゆる組み込み系と言われるようなハードウェア上のソフトウェアと疎通・連携する機能を開発するときのTipsをまとめます。

開発者が利用するための環境・情報が整っているOSSや各種クラウドサービスとは異なり、組み込み系のソフトウェアは外部の開発者にとっては優しくないことが多く、見積もり通りの開発にはならない傾向が強いためです。

  

 

設計・実装をはじめる前にやること

ハードウェアを選定する

実現したい機能から逆算して、ウェブ・アプリから利用するハードウェアを選定します。外部の開発者に開かれていてSDK等が提供されているハードウェアとそうでないものがあったり、iOS・Android・Windowsアプリはサポートしていてもウェブ(JS)はサポートしていないものがあります。

ハードウェアの機能重視で比較検討すると、外部開発者の利用を想定して設計されていない(けどリバースエンジニアリングはできそうな)製品が候補にあがったりしますが、意図せぬバグの可能性、将来性、法律の問題など色々問題があるので、潔く諦めましょう。妥協できないようであれば、ハードウェアベンダと提携したり、自社ブランドでハードウェアを開発する道を検討しましょう。

 
Windowsの開発機を用意する

ウェブやiOS・Androidアプリを開発する人であれば、MacやLinuxで開発をするエンジニアがほとんどだと思いますが、Windowsの開発機は事前に用意しておくのが無難です。Windowsでの開発しかサポートしていない組み込み系ソフトウェアは結構多くて、なんだかんだ必要になってくるケースがあります。

ドキュメントを一見して、Windows機は使わなくてもなんとかなりそうと感じても、実はWindows機でのみ動く開発用ソフトウェアを使わないと利用できない機能とかあったりします。実際に、SSL周りの設定はWindow機がなくてもできたのに、実はSSL証明書のインポートにはWindows機が必要だったとか、そういう経験があります。実装中にWindows機が必要であることがはじめて発覚し、そこからWindows機の選定と発注をしているようだと、余計なリードタイムが生じてしまいます。選定次第では数万円程度で済むので先行投資しましょう。

 

ハードウェアを販売している営業マンとつながっておく

ハードウェアを販売している営業マン、さらにできれば、その先にいるソフトウェアベンダーと繋がっておけると開発が行き詰まる可能性がぐっと減ります。というのも、組み込み系のソフトウェアは、まともなエラーログを吐いてくれないことが往々にしてあります。組み込み系ソフトウェアは外部開発者にとってはブラックボックスなので(OSSと違ってissueもコードも何も見えないので)、ログもないとなると何か詰まったときにはどうしても内部のつくりを知っているベンダーに問い合わせたくなってきます。問い合わせると意外な答えだったり、隠れた機能を教えてもらえたりするものです。

ただ、組み込み系ソフトウェアを開発しているベンダーの情報はなかなか手に入らないので、ハードウェアベンダや販売会社にまずは問い合わせることになります。コールセンターやメールでの問い合わせは大抵役に立たないので(ソフトウェアに関することを答えるケーパのない人たちに繋がるので仕方ないですね)、そこから頑張って営業マンやソフトウェアベンダに繋いでもらいます。コールセンターや問い合わせフォームの中の人からはマニュアル化された答えしか返ってこない、さらには営業マンと繋いではもらえないと思いますが、そこは頑張るしかありません。(電話での交渉が得意な方に頼りましょう。)

所謂ウェブ系のエンジニアなら大丈夫だとは思いますが、ベンダが外資の場合は当然英語でのやりとりになります。

  

 

実装・保守で意識すること

ドキュメントを過信しない

外部開発者の利用を想定している組み込み系ソフトウェアには大抵ドキュメントがあり、ウェブ上からダウンロードできるようになっています。SDKごとにサンプルコードとか付いてたりします。しかし残念なことに、何故か肝心なことが書かれていなかったり、普通に間違った記載がされていることがあるので、ドキュメントに頼ってばかりではいけません。

大抵SDKの中を読むことになりますし(そしてバグを見つけたりする)、結構雑なつくりだったりするのでびっくりすることもあります。パフォーマンス上の課題とかも、SDKを読み解くことで見つかったりします。組み込み系とウェブ系で言語や慣習が異なる以上、元々SDKの開発や言語に慣れていない人がSDKをつくってたりもするでしょうし、仕方ないのかなと思ったりもします。

 

なるべく早い段階で、リアルな現場で一通りの動作確認をする

なるべく早い段階で、ハードウェアを設置するリアルな現場で一通りの動作確認をします。ハードウェアの配置、電源、ネットワーク(疎通)等で問題が出てくることがあります。(ありました。)

組み込み系ソフトウェアとの疎通には、プライベートなIPに対してHTTPやWebsocketで疎通したり、Bluethoothで疎通することになると思います。(ハードウェアにパブリックIPを当ててドメイン付与とかはしないでしょう。)仮にウェブフロントからSDKを叩いてハードウェアを操作する場合には、プライベートなIPを叩く以上はSSL周りを工夫しないとブラウザからMixed Contentで怒られてblockされたりするケースがあるでしょうし、iOSならATSやその管理をどうするかといった話があります。Bluetoothで疎通するなら、Bluetoothは電力依存で壁を透過しないという性質があるので、常に電源を確保できて配置上疎通に問題がないかを確認します。

 

ファームウェアのアップデートを欠かさない

アップデート内容次第ですが、ファームウェアのアップデートには追従できるようにします。OSSのバージョンアップデートの考え方とほぼ同じ考え方でいますが、例えばセキュリティの脆弱性対策とか、ブラウザの自己証明書に対する扱いの変更に関するアップデートとか重要なものもあり、アップデートに追従できないと機能が死ぬケースもあるかと思います。 

私はまだ開発したことはないですが、他社にハードウェア一式もろともSaaSとして(?)貸し出すPOSシステムなど(Airregiとか)は、どうやってファームウェアアップデートを管理するかとか、ちゃんと設計しないといけなさそうですね。

 

 

まとめ

組み込み系ソフトウェアとの連携機能をそんなすごい数開発したわけではないですが、いままで詰まったこと、こうしたほう良いなと思ってたこと、またよく起きることをまとめてみました。

個人的に、大抵どこかで詰まるのであまり開発に乗り気になれる分野ではないのですが、でも機能が一通りできたときの達成感は並以上のものがあるので、また機会があったら率先してやってみようと思っている所存です。

5年前に自分がつくったRailsアプリをリファクタした話

8月に入り、晴れてフリーランスになりました。
ありがたいことに色々とお仕事のお話を頂きまして、今月から創業間もないスタートアップ2社に微力ながらお力添えさせていただくことにしています。楽しみです。

7月はほとんど有給消化期間で、結構のんびりしていたのですが、いろんな人にお会いしてお話したり積読本を消化したりする傍ら、5年くらい前に自分がぱっとつくってほぼ放置していたRailsアプリのリファクタ、パフォーマンス・チューニングをしていました。

30万pv/monthしかない小規模なウェブサイトですが、一週間くらい頑張ったらだいぶマシになったので、やったことを晒します。(大したことやってないですが、近況報告程度に。笑)

 

Railsアプリの概要

ikstudieという、独学の大学受験生を支えたいというコンセプトのウェブサービスが対象です。私自身、大学受験には独学で臨んだのですが、何かと不安に思うところがあって辛かったので、私のような思いをする受験生の支えになりたいと思ったのが立ち上げのきっかけでした。

以下、このサイトの特徴を挙げます。

  • 私が個人ではじめてつくったウェブサービス(手抜き、超短期開発、糞コード)
  • ここ数年、30-50万 pv/month。数日に一回程度、受験生からの質問がある。
  • リリースしてから5年くらい経つものの、Rails3系から4.2までのバージョンアップと、クリティカルなボトルネック対応以外、ほぼ手付かずで保守できていない
  • 有志で、View部分だけずっと書いてくれている仲間がいるものの、staticなページが多数出来ている
  • 当然のようにユニット・テストはない
  • モデルは30個前後の小規模アプリ
  • 当たり前品質を満たせていない(レイアウト崩れ、機能が壊れている等)
  • インフラに関しては、完全に私の実験場になっていて、これまでEC2 + capistrano2系 ー> Opsworks + Chef ー> Elastic Beanstalk ー> Terraform + Packer + (Itamae or Ansible) on AWS  ー> Google Kubernetes Engine ー> Google App Engineと色々お引越ししてきている(チューニングはしていないが、最低限のインフラ環境は整っている)

ずっとikstudieに関わってきてIT系に勤める有志の仲間たちと、これからちゃんとエンハンスをしようという話になったのが、今回のリファクタのきっかけです。中のコードがひどかったり、当たり前品質と言われるようなところに問題があったので、まずはリファクタしないと先に進めないという認識でした。

 

何はともあれまずは現状把握と解析

ぱっと調べられる範囲でいろんなツールを使って解析したり、主要ページのコードを眺めたり、全画面に遷移して挙動の確認をしてみました。

 

rubocop(linter)を走らせる

f:id:takuwan0405:20180802165103p:plain

rubocopはRubyのlinterです。autocorrectを走らせ、linterのターゲットをコントローラーとモデルだけに絞った結果、これだけoffensesが出てきました。(意外と少なかった。)

Fatなコントローラー・モデルに対して、もっと小さくしろよと怒ってるのがほとんどでした。
自分の目でコード一行一行を読んでいくともっとツッコミどころ満載だったので、あくまでrubocopで補足できる範囲での数値です。

もっとRubyっぽく柔軟に書けば読みやすいしコード量も1/3以下で済むのに、みたいな記述がたくさんあった感じです。

 

Railsアプリとしてのコード品質をrails_best_practicesでチェック

f:id:takuwan0405:20180802174305p:plain

rails_best_practicesは、その名の通り、Railsらしい記述を指南してくれる静的解析ツールです。Warningの数もさることながら、カラムにindexが付いていないだとか、結構重要なところでも怒られました。
Warningのほとんどは、viewの書き方が汚いよ・間違っているよと怒っていて、地道な修正が必要そうでした。

 

Skylightでパフォーマンスモニタリング

f:id:takuwan0405:20180802170321p:plain

Newrelicでも良かったのですが、今回ははじめてSkylightをつかってパフォーマンスモニタリングをしてみました。Newrelicのほうが機能はリッチでしたが、価格もリッチだったうえ、Skylightでも今回は困りそうになかったためです。

Typical Responseで244msは、うーんって感じですね。基本的にマシンリソースには余裕があって負荷もないので、worker、thread、connection poolとかにボトルネックがある様子もありません。Problem Responseでは1.5s以上のものも散見されました。

ActiveRecordのクエリは遅くても20msで返ってきていて、Viewの生成にすごい時間がかかっていました。

 

Lighthouseによるフロントからの評価

f:id:takuwan0405:20180802171838p:plain

SEOの100点が眩しいですね。(一応メディアなので、ここはクリティカルなポイントでした。)
PWAは対応する気がないので問題ないですが、PerformanceとBest Practicesが気になります。

細かい設定は色々指摘されましたが、画像周りが大変そうな印象。

 

Railsアプリのセキュリティ脆弱性をBrakemanでチェック

f:id:takuwan0405:20180802163354p:plain

やたらErrorsが出てますが、全部Parsing Errorでした。
数年前にbrakeman走らせたときはXSSのSecurity Warningが出てたりしたので(パラメーターを直に使ってSQL叩いてたところがあったので)、本当に駄目なやつは昔直してました。

 

Githubのセキュリティアラート

f:id:takuwan0405:20180802165915p:plain

自分は、つくっては放置しているリポジトリがいくつもあるので毎週怒られてます。
ikstudieもいくつかの依存ライブラリでsecurity alertが挙がっていました。(が、内容ちら見したうえでいままで後回しにしてました。)

 

使われている機能・使われていない機能の確認

管理画面を見たり、本番データを複製したDBにクエリ投げてみたりして使われていない機能をぱっと洗い出しました。

記事をマイリストする機能、いいね!する機能などが使われていないことがわかったり、使われていないカラムが沢山あることが判明しました。データ量がそんなないので、slow queryは引っかかりませんでした。

 

愚直に手動でE2Eテスト

テストケースを列挙して丁寧にやったわけではないですが、全画面の挙動を確認しました。ログイン機能が一部壊れてたり、もう色々壊れてました。

全体的にひどかったのがレスポンシブデザインで、例えばトップページでも下記のように崩れていました。

f:id:takuwan0405:20180802173316p:plain

jpmobileという、Railsのview層でUserAgentを判別できるgemが導入されていて、viewで ` request.smart_phone? ` といった感じの分岐がいたるところに入っていました。リリース当時はレスポンシブデザインだったはずなのですが。。(UserAgentで切り分けているので、スマホでikstudieを見たら崩れてはいなかったです。)

CSSに一貫した命名規則がなく(bootstrapっぽいもの、SMACSSっぽいもの、安易な命名とか混在してた)、少し触るとすぐレイアウトが崩れそうなので、それが一因してjpmobileを多用したのかなと伺えます。たぶんそんな考えてないです。

 

目標を決める

現状把握は一日くらいでぱっと済ませたので、その後4日くらいで達成する、リファクタのMUST要件(目標)をゆるく、ざっくり決めました。上から優先度高めです。

  • 壊れているレイアウト・機能の改修(UX目線での当たり前品質を満たす)
  • SkylightでのTypical Responseを80ms以下にする(UXを向上させ、SEO上のマイナスをなくす)
  • 不要な機能、コード、テーブル、カラムの除却(エンハンスしやすい形にしたい)
  • コード品質向上・維持のために、CIを導入してrubocop、rails_best_practices、brakeman、Github security alertでのwarningとerrorをゼロにする(負債を貯めないようにしたい)

 

リファクタ結果

当たり前品質(壊れたレイアウト・機能の改修)

View層で動的な部分はほぼ全部書き直しました。CSSの設計が破綻してたので、エンハンスする可能性がありそうなページは書き直しておくことで後々うれしい気持ちになりそうだったためです。問題になっていたjpmobileは極力取り除き、書き直したページは一部を除きレスポンシブデザインに戻りました。(UserAgentでのViewの条件分岐はなくしました。)
View層は私以外にも触る人がいるので、Reactjsとかは入れずに、以前から入っていたslimというテンプレートエンジンを採用し続けました。私以外の人はエンジニアとして生活しているわけではないので、学習コストがない状態にしたかったためです。

ただただ、愚直に直しただけです。
静的なページは、後日優先順位をつけて改修する必要があるかもしれません。

 

f:id:takuwan0405:20180802184816p:plain

ちなみに上の画像のフッターに出てるLINEへの送客は、どれくらい送客できるか、ikstudieのユーザー層はどうなっているかを検証・確認するためにやってみたのですが、結構良い・面白い数字が出ています。受験生の集客、つまり広告として成り立ちそうだなーとか考えています。(受験に関連するiOS/Androidアプリつくって送客しても良さそう。)

 

UXとSEO向上(パフォーマンス・チューニング)

f:id:takuwan0405:20180802190947p:plain

Typical Responseは大体40~60msになりました。(1/5くらいになりました。)

ループを回してHTMLを生成している部分が概して遅く、Railsが標準で提供しているフラグメントキャッシュという、生成したHTMLをキャッシュする機構を多く使いました。キャッシュストア、またセッションストアにはRedisを採用しています。

N+1は意外と少なかったのですが、利用しない(検討した結果利用する予定もない)AccessLogやEventLogをinsertするクエリが各リクエストにあったり、他にも不要なクエリがいくつかあったので削ったのも少々効きました。あとはrenderメソッドのチューニングとかも効いてそうです。

キャッシュのヒット率を高めるためにキャッシュの有効期限は長めに取ってますが、記事の検索結果のページとかはヒット率が低いので、ひどいと500msとかかかってしまうケースもまだあります。

Skylightをつかってて嬉しかったこととして、週次でどれくらいパフォーマンスを改善したのかが送られてきます!StaticPageController#homeはトップページなのですが(全然Staticじゃないので命名が意味不明ですね。負債具合が伝わりそう。)、9倍になったらしいです。記事のページは141msとかかかってるので、まだ改善が必要そうですね。

 

f:id:takuwan0405:20180802190949p:plain

 

エンハンスしやすい形に(不要な機能、コード、テーブル、カラムの除却)

前述したAccessLogやEventLogもそうですが、不要なテーブルやカラムが散見されたので、凍結したりdropしました。

また、マイリストの機能は改修がちょっと大変な割には本当に使われてなかったので、一旦凍結しました。また、ログインが必要なために使われていなかった「いいね!」機能は、ログインしなくても利用できるようにしました。

コード量も全体的に削っていて、PRのコード量を単純にみたら3600行削ったようです。

f:id:takuwan0405:20180803005720p:plain

 

コード品質向上・維持 

まず、rubocop、rails_best_practices、brakeman、Github security alertでのwarningやerrorは全てゼロにしました。静的コード解析上では常にクリーンな状態を保つことである程度のコード品質を担保したかったのと、コード品質を表現する尺度を他のコントリビューターにもみえる形で設定したかったという意図です。

CIは、いまのikstudieでは無料で十分使えるCircleCIを採用し、元々あったdockerの開発環境をそのまま利用する形でぱっと構築し静的解析を走らせるようにしました。(コンテナのキャッシュとか設定してないので1回のRunで13分前後かかってて、いつか改善したいです。)

ブランチ戦略も簡単に設けて、masterとdevelopブランチはprotectし、基本的にdevelopからfeatureブランチを切る形にしました。
Staging環境をHerokuで無料で構築し、developブランチにPRがmergeされたらデプロイされるようにしました。また、masterブランチにPRがmergeされたら本番環境にデプロイされるようにもしました。

ユニットテストとかは書いてないですが、コントローラーもモデルもスリムであまり量がないので、これからエンハンスしながら書き加えていこうと思います。

 

余談

リファクタのPRを本番デプロイ後にLighthouseで確認してみたところ、数値がそこそこ改善していました。

Nginxとかの細かい修正が少なくなかったですが、Performanceに関しては、CDNとしてCloudFrontを導入してCache-Controlを長めに設定したこと、S3に置かれている画像オブジェクトを全部圧縮したこと(pngの圧縮は時間がかかりました)、またLayzr.jsをつかって一部の画像を遅延読み込みさせたこととかが、効いていそうです。

f:id:takuwan0405:20180803013031p:plain

あと余った時間でやったこととして、たまたまGoogle Cloud Load Balancerの障害に当たってしまったり、ikstudieにとってGAEは割高だと感じていたこともあって、本番環境をElastic Beanstalk(というかAWS)に移行しています。ついでにPumaのworker、thread、postgres、connection pool、GC周りとかもそれっぽい数値を改めてぱっと設定して様子見しています。

 

これから

優先順位は高くないもののまだリファクタしたいことはいくつもあるので、「心置きなく」というわけにはいきませんが、エンハンスには着手できそうです。

今年いっぱいは既存のウェブサイトの最適化を図る予定ですが、アプリの開発やリアルでのイベント開催などでもできること・やれることは沢山あるので、仮説検証をしつつコードも書いていていきます。

興味がある方はtwitterでDMください。

 

リファクタの感想

あくまで個人開発なので全然しっかりしていない開発・リファクタですが、一応満足。

リクルートを退職します(エンジニアです)

7月末にリクルートを退職することにしました。今日から有給消化です。

(はてぶで「政治経済」カテゴリに自動分類されてしまったので、タイトルに「エンジニア」と追記してみました。「テクノロジー」カテゴリいきたい。。)

 

リクルートでやってたこと

「SUUMOを内製化するぞ!」ということでリクルート住まいカンパニー(以下RSC)に出向となり、インフラエンジニア、スクラムマスター、iOSエンジニアなどのロールで2年半弱SUUMOの開発をしてきました。

入社当初の「内製化」は紆余曲折あってすぐ雲散霧消したのですが、30年以上の歴史があるSUUMOの、特に賃貸領域をいかに伸ばすかというところに力を入れてきました。

(以下はRSCに限った話で、リクルートの他グループ企業では違った事情があると思います。)

 

リクルートはどうだったか

入社当初は戸惑いばかりでしたが、いま振り返ると学べたことがだいぶあったと満足しています。

感謝していること

この2年半、感謝することばかりで挙げればそれこそキリがないのですが、リクルートという会社(場)にフォーカスすると、会社の枠を越えて本音で話してくれる、応援してくれる大人が沢山いることが、私にとって一番ありがたかったなと思います。

自分の拙い文章では、具体的に書くとエモくなったり陳腐化したりしてうまく表現できないのですが、ワーワー言いながらみんなで良い方向を目指して頑張っていた感じだったり、業務外でもいろんな縁があったり、自分が本音で相談したらポジションを抜きに本音で答えてくれた人が沢山いたところが良かったです。

入社して戸惑ったこと

リクルートに入って1年目は、組織に振り回されて色々悩みました。SUUMOという巨大メディアを内製化するにあたって、自分は純粋なエンジニアとして入社したつもりだったのですが、人に依ってはパートナーマネジメントを期待してきたり、要となる人が色んな事情から諦めてしまったり、エンジニアリングマネージャーがいなかったり、(なので仕方ないんですが)上司のマネージャーにエンジニアリング上の課題を伝えるのが大変だったり。。大規模なサービスの内製化界隈は大変でした。

いまは、リクルートの他グループ会社の方々の助けもあって、当時ほど組織について悩むことは一切ありません。ただ、組織が出来上がって落ち着きすぎていて、あの頃はワーワーいって楽しかったなと思ったりもするので、不思議なものです。(自分は、きちっと環境が整っている場所より、ワーワー言ってみんなでどうにかしようと働きかけられる場所のほうが好きだということに気づきました。)

 

学べたこと、成長できたこと

自分の技術力やマインドに限った話をします。

デカいサービスを開発する難しさ

自分がもともとリクルートに入ったのは、大きな企業で大きなサービスをつくるエンジニアとして10→100の知見を得たいという動機からでした(たぶん)。この動機は十分に満たせました。

コード量はもちろんのこと、全体的な設計としてもSUUMOは本当にデカいサービスで、その理由はいくつか思い当たるのですが、そのうちの一つとして複数のドメインを扱っているからデカいというのがありました。

SUUMOは賃貸・新築マンション・中古マンション・注文住宅・リフォーム等々の、不動産産業の複数のドメインを扱っています。ビジネスモデルは基本的に全ドメイン同じでカスタマー(一般ユーザー)とクライアント(企業)をマッチングさせるリボンモデルですが、扱う金額・商習慣・課題としていること等が各ドメインで異なってくるため、SUUMOとしてもKGI・KPI、売りの立て方などが各ドメインごとに異なってきます。ということは、企画する人は各ドメインにいるし、実装する企画の規模・内容は各ドメインで異なってきます。開発体制を例とすると、あるドメインは基本的にウォーターフォールで数ヶ月かけて開発して大きなリリースをするけど、あるドメインは基本的にアジャイルに毎週にでもリリースをしていくみたいなことになったりします。開発者もかなり多いので、チームをまたいで密に連絡を取りつつ、いかにコンフリクトしないかとか、齟齬らないかとかを気をつけて、日々工夫して開発をしていました。

ソフトウェアエンジニアとして、こうした環境のもと、社会に影響力がある大きなサービスを丁寧にしっかりと、でも一方でアジリティをも意識した開発をできたのはとても良い経験だったと感じています。前職やインターン時代にベンチャーで働いていたとき以上に、品質に問題のないもの作ったり、先々のことを見通したりといったことが確度高くできるようになったと感じていて、技術の基礎力の底上げになったことは間違いありません。

また、技術力以外のソフトスキル(対人能力的なもの)が鍛えられたとも感じていて、大きな組織でのチームづくりを経験させてもらえたことで、いまではエンジニアリングマネージャーとしてのキャリアも現実的に考えられるようになってきたと感じています。

やりたいと言ったら任せてもらえたインフラ

いままでインフラだけに集中して業務に取り組んだことがなかったのでスキルセットを広げられそう、負荷はあるだろうしサービスがデカいことを1番実感できるのはインフラだろう(実際はそんなことなかった)、対応の優先度が高いシステム上の課題や改善ポイントがある等々の理由で「インフラやりたい」と当時の上司やチームに打ち明けたところ、SUUMOスマホサイトの環境を任せてもらえました。(働く本人の意志をちゃんと考慮してもらえる文化がリクルートにはあると思ってます。)

EC2 Classic群の環境からVPCに環境一式を移行して、ついでにAnsibleやTerraform等でInfrastructure as Codeを実践し、MackerelやPagerDuty等でモニタリングできるようにし、RedashとAthenaでアクセスログ解析をできるようにしたり、Blue-Green Deploymentの仕組みを構築して云々といったことを通じて、インフラに関するスキルがぐっと上がりました。途中で上司が強いエンジニアを連れてきてくれて、色々教えてもらえたところも貴重な機会でありがたかったです。

エンジニアリング以外のハードスキル

自分が一緒に働いた企画者は優秀な方ばかりで、エンジニアだろうが一朝一夕では身につけられない、エンジニアリング以外のハードスキルってあるんだなーと痛感しました。 KPIツリーの構築、グロースハックの施策、未来への仕込みなど、「なるほどなー」と感じさせられた場面が度々あったり、CACやLTVだとか入社前は全然知らないワードも自然と耳に入ってくる環境だったので、エンジニアリング以外のマーケティング・ファイナンスの領域にも食指が動くようになりました。

  

働く環境

リクルート(RSCの親会社)の人事にも言われたのですが、私が在籍していたこの2年半はRSCの組織体制が大きく変わったタイミングで、それに伴い働く環境や雰囲気も変わりました。

勤務時間・場所

私が入社してすぐにリモートワークが解禁され、全職種でリモートワークが一時的に流行しました。がしかし、昨年下期あたりからRSCのエンジニアはリモートワークが非推奨になり、最近では企画職とかでも、リモートワークは週1日以下の人がほとんどではないかと思います。

SUUMOは業務委託のパートナーさんやベンダーさんが多く、パートナーさんのマネジメントが疎かになりがちだったこと(社員はリモートで開発していて、パートナーさんが常時オフィスで開発するといった、なんか変なことが起きていた)。また、過去の経緯上SUUMOはなにかと仕様が複雑で、リモートでの開発がパフォーマンスの向上に結びつきにくかったことなどが主な理由です。SUUMOの場合はオフィスにみんなで集まって開発をするほうが作業が捗るのは確かなので仕方ないことだと納得していますし、昨今のリモートワーク推進の流れに反する面白い経験をできたなと思います。

勤務時間については、入社時との大きなギャップでもありますが、夜まで残ってがっつり働くみたいなことが制度上難しいような、わりとまったりとした環境でした。

また些事ではありますが、オフィスが移転して勤務地が東京駅から田町駅に移りました。リクルートは東京駅だという思い込みがあったので、田町に移転になったときはざわざわしました。

知見が落ちている

リクルートにはいま、株式会社リクルートテクノロジーズ(RTC)という機能組織を軸にして、ソフトウェア・エンジニアリング各界の著名人が集まっています。この分野ならあの人だな、という人達が雇用形態を問わずいろんな形で在籍しています。

例えばですが、SUUMOのアプリ開発でアジャイルに動けるチームを立ち上げるといったミッションを私が担ったとき、@i2keyのアウトプットには大変お世話になりました。アジャイル・リーンといった考え方はもちろん、フロー効率・リワークチャートといったリクルートにいなければキャッチアップできなかったであろう概念をいちはやく知れたことや、それらの概念を考え出す場面をslack上でちら見できたところとか良い学びでした。

様々な属性の仕事がある

SUUMOは1000億近い売上がある、リクルートの中でも頭一つ抜けた巨大販促メディア(10 → 100)で私はこれにずっと従事をしてきましたが、リクルート社内を見渡すと0 → 1のフェーズ、 1 → 10のフェーズの仕事も沢山ありますし、海外での仕事やR&Dといった仕事もあります。

株式会社リクルートテクノロジーズ(RTC)を通じて、いまではRSCのエンジニアも他領域の全く違ったフェーズの仕事にトライすることができるチャンスがあるかもしれないので(制度化されているわけではないと思う)、まだ自分がどこで勝負する人間なのかが見えていないエンジニアとかにも良い環境なのかなと思ったりします。(社内転職みたいなものなので、転々とするのはそれはそれで苦労があるかもしれません。)

待遇

世間が狭い私はあまり実感できていないのですが(個人事業主としても活動してるからかも)、待遇に関しては「下駄を履かされる」と言う人が少なくないように思います。私が良かったなと感じているのは、ちゃんと仕事をすれば評価してもらえて、それが待遇に反映されている納得感がありました。給与はちゃんと上がります。

 

なぜ辞めるのか

基本的には満足していた私ですが、なぜ辞めるのかというと、自分が解決したいと思える課題に対して、もっと自分の意志が介在できる形でアプローチをしたいと考えているためです。端的にいうなら、スタートアップをやりたいと思っているのですが、リクルートの新規事業制度を通すよりも自分の意思を反映でき、かつハイリスク、ハイリターンな形を取りたかったという経緯です。

直近はフリーランスになってお金を貯めつつ、何にどうコミットしていくのかを考えていこうと思います。

 

最後に

本当お世話になりました!お疲れ様でした!

またどこかで一緒に仕事できるとうれしいです。

あと、twitterを数年ぶりにやりはじめたので、フォローしてもらえるとうれしいです。@takuwan0405です!

 

長文にも拘らず、最後まで読んで下さりありがとうございました。