かしブログ

技術ブログ的なものです

株式会社タイミーを退職してフリーランス向け案件探しサービスを作ります

どうも、かしまです。
8月末にてタイミーを退職することにしました。
業務委託として1年、正社員として半年という長いようで短い間でしたがお世話になりました!

なんでやめるの?

数ヶ月前から自分でサービスを作っており、事業化を狙って本腰を入れたいなと思ったためです! そのためには正社員で働くよりフリーランスで週3~4で働きつつサービスを作るような働き方に魅力を感じました。

どんなサービス作るの?

企業とエンジニアを繋ぐマッチングプラットフォーム

現在フリーランスエンジニアが案件を取得するにはエージェントを利用している人が多いと思っています。 ただエージェント経由だと企業が払う月単価の10~20%を毎月エージェントに抜かれてしまいます。

月々20%抜かれるとなるとエンジニアとしては収入は上がりにくいですし、企業としても直契約の人と比べ割高な金額を払い続けることになります。 自分もエージェント利用してた時がありましたが、最初の案件探しで使うだけでその後ずっと十数万抜かれ続けるのはなんだかなあと思ってました。 これを解決するため、企業とエンジニアを直接繋ぐようなサービスを作りたいなと思ってます。

正直事業としてうまくいくかはわかってませんが、とりあえずリリースしてみようとは思ってます。 ボランティア的に手伝ってやってもいいよ!という方がもしいらっしゃったら是非お声掛け下さい!

初めてコミュニティの司会進行をしてみて

先日開催した 平成.rb #2 @MedPeer で司会進行を担当しました!

初めて運営として仕事した感があり、エモい気分なのでブログを書いてみようと思いました。

運営として参加してみた気付いたこと、良かった事を挙げていこうと思います。

LTを集中して聴けた

今回はLT終了後、自分が一言感想を言ってから次の人に繋げるという形をとったため、いつもより集中して聴くことが出来ました。 普段集中してない訳ではないのですが、twitterで呟くことに気を取られすぎたりしてしまうことが多々ありました。 しかし今回はそのような事が起きないように気をつけながら聴くことが出来ました。

懇親会にて多くの方と話すことが出来た

普段の懇親会だと見知った顔と話して終わることが多いのですが、今回は運営という看板があったため、たくさんの方とお話しできました。 やはり知り合いが増えるのは嬉しいですね。 ただ反面広く浅い交流だったため、昔から面識があった人とゆっくり話せなかったなと思います。 その人達とは別の機会で改めてゆっくり話したいです。

感想ブログを書いてもらうとめっちゃ嬉しいことがわかった

コミュニティに初めて参加されたという方がブログを書いてくれました。

これをみたとき、運営やって本当に良かったなと、とてもエモい気分になりました。 微力ながらも好きなRuby界に貢献できたかなあと思うとこみ上げてくるものがありました。

最後に

コミュニティに初めて参加した一年前には、まさか自分が運営側にまわるとは思ってもいなかったです。 一年前、表参道.rbに連れて出してくれた @yuki3738 には感謝しております。 またゲストLTを快く引き受けてくださった @cesare さん、 @yaboojpさん、会場/ドリンク/フードスポンサーのMedPeerさん、本当にありがとうございました!

これからも平成.rbをよろしくお願いします!

銀座Rails#1 に参加してきました!

第一回銀座Railsに参加してきたので感想を書きたいと思います!

松谷さんの発表「Railsスタートアップがやってよかったこと」

題名の通り、スタートアップ企業が取り入れてよかったgemやツール、開発スタイルについての発表でした。

初めて知ったgemの中で、xray-rails というgemが便利そうだなぁと思いました。

viewファイル見に行ったらpartialだったてことはよくありますし、地味にストレスなので、このgemで解消できそうだと思いました。

また定期的なbundle update、rubycop,Siderによるレビューの自動化を取り入れており、負債を残さないように意識されているんだなと思いました!

 

一條さんの発表「RailsからProtobufを使いたくなった話」

Protocol BuffersとCloud Pub/Subを使ってマイクロサービス化を行なっているというお話でした。

自分はどちらの知見もないので終始「はえー」という感じでしたが、マイクロサービス化を行う上での課題をどのように解決して行ったかというstory仕立てになっており、聞いていて面白かったです。

 

松田さんの発表

松田さんの思い出深いRailsのコミットを振り返る内容でした。

松田さんがRailsに初コミットしたのは約10年前で、コミット数的に平均5日で1コミットされていることになるそうです!すごい!

以下に内容をざっとまとめました。ただ酔っ払いながらメモした内容で、間違いもあるかもしれないのでご了承ください :pray:

思い出深いcommit
  • rails cでppをrequireするcommit
    • 2011年時点でruby2.5の機能を先取りしてた
  • for ... in をeachにreplace
    • DHHはfor ... in で書いてた!!
  • blank?メソッドの修正
    • 全角スペースとその他見えない文字列も対象にするようにした
    • 日本人には必須の対応!!
    • しかし遅くなった笑
  • whereの4種類のシンタックスをコミット
    • where.likeとwhere.not_likeは後ほどDHHによりrevert
  • tabenai(typo)
  • Space Oddity
失敗したコミット
  • sexier migration
    • migrationファイル内でt.xxxという記述でtいらなくね?
    • いつのまにかrevertされた
  • html5 validations
    • まだ早いと言われた
    • gemでならある
    • プラグイン開発/コードリーディングの教材に良い
  • アクションメソッドに引数を
    • DHHは気に入ったものの、細かい仕様の折り合いがつかずお流れ

最後に

松谷さん、一條さんの発表では自社で行なっているTechなお話、松田さんの発表ではRailsコミッターならではのお話が聞けました。 面白かったので第二回も参加しようと思います!

大江戸Ruby会議07 に参加してきました

Asakusa.rb10周年記念に開催された、大江戸Ruby会議に参加してきました!

大江戸Ruby会議は、Rubyist達の「生活発表」をする場で、色々なエモい話を聞くことができました。

ここでは自分が特に印象に残った発表を紹介したいと思います。

 

デカ外人ことJonanさんの発表

Jonanさんの発表は彼のライフマニュアルの発表でした。

5つのセクションがありましたが、その中で 泳ぎ続ける の内容が最も響きました。

簡単に要約すると、以下の通りです。

  • 自分の周りを見るとすごい人が多く、悲しい気持ちになるかもしれないが、やり続ける
  • 止まってはいけない

この発表を聞いてJonanさんレベルのエンジニアでもそう思うことがあるのかと驚きと共に、救われた気がしました。

社会人になってからプログラミングに携わった自分は、同じ年代でも自分より数段レベルが上のエンジニアを見て焦る気持ちがありましたが、自分なりにやり続けるしかないんだなと改めて思うことができました。 

 

うなすけさんの発表

うなすけさんの発表はスライド作成ツールについてでした。

彼はPower PointやKeynoteなどを経て現在はRabbitを使っているそうです。

Rabbitとは
  • Rubyで作られたスライド作成ツール
  • plan textで書けるのでgitで管理ができる
  • 環境(Windows,Mac,Linux)を選ばない
  • スライド内のリンクをクリックできるようになった!
  • アニメーションなどの凝ったスライドは作れない

自分は無難にKeynote派でしたが、これを機にRabbitに乗り換えようと思いました!

また彼はとても喋りが上手く、聞いててかなり気持ちの良い発表でした。

 

しなもんさんの発表

彼女の発表は、彼女がこれまで携わってきたサービス開発でハマったことや、それをどのように解決してきたかという内容でした。

この発表を聞いてまず思ったことは、すごい胆力の持ち主だなと思いました。

あらゆるトラブルに遭遇しながらもトライアンドエラーを繰り返す精神がとてもすごく、見習いたいと思いました!

 

松田さんの発表

松田さんの発表ではAsakusa.rbをなぜ作ろうと思ったのか、そしてできるまでのお話を聞くことができました。

最近Twitterで話題になってる エンジニアは業務時間外にも勉強すべきか というネタにも絡ませており、とても面白かったです。

松田さんの発表で特に心に残った言葉を以下にまとめます。

  • Asakusa.rbは人とRubyの話がしたいから作った
  • 勉強会はインプットの場
  • コミュニティはアウトプットの場
  • なのでAsakusa.rbは勉強会ではない
  • 自分達はRubyで遊んでいるだけ

Asakusa.rbは勉強会ではないよということを強調されていました。

自分たちはRubyが楽しいから遊んでいるだけ、勉強しているわけではないとおっしゃっていて、とてもかっこいい!と思いました !!

 

懇親会、そして川へ

Rubyistは川に集まるということで、懇親会後は終電まで隅田川で飲んでました笑

初めましての方ばかりでしたが、とても楽しい時間でした!

 

実は今回の大江戸Ruby会議、少し前まで同じ職場で働いていた菅井さんに「自分フリーランスなんすけど業界の知り合い少ないんです。。。」と相談したら、「なら今度の大江戸Ruby会議いきましょう」と誘って頂いたことがきっかけでした。

菅井さんはRuby界隈のお知り合いが多く、懇親会では色々な方を紹介して頂き、感謝しかないです!ありがとうございました!

 

MedBeer -Rails開発での技術的負債との付き合い方- に参加してきました

MedPeerさん主催のイベント、「 MedBeer」に参加し「技術的負債」をテーマにRails開発のリードエンジニアの方々のお話を聞いてきました。
自分的にすごく刺さるテーマで、参加できてよかったです。

各発表のまとめ・感想

前島 真一(メドピア株式会社技術顧問) さんの「Rails Good Parts, Bad Parts」

前島さんの発表は、新たな負債を作らないためにはどうすれば良いかという内容でした。
負債を作らないためにはRailsのレールに乗る取り扱い注意な機能・ライブラリについての向き合い方が大事ということでした。

Railsのレールに乗るとは
  • Railsには便利な機能がたくさんある
  • レールに乗るとはRailsが提供している機能を活用することである
  • 便利機能の存在を知らず、スクラッチ開発をして微妙な感じになってしまうのはもったいない
  • 便利機能の存在を知るには
    • 公式ドキュメントやRailsガイドを読む
    • 強い人にレビューやペアプロをしてもらう
取り扱い注意な機能・ライブラリについての向き合い方
  • 安易に採用すべきでない機能やライブラリ例: defalut_scope,devise,webpacker,etc...
  • この手ものの扱い方
    • チーム内でよく吟味する
    • 吟味する時間がないなら禁止する
    • 周りがdisってるからといって、吟味せずに使わないっていうのは良くない
  • チームメンバー全員が負債になりそうな要素に対して対応法を知ってることが大事
    • 社内教育を頑張りましょう
clean-rails.orgについて
  • 可読性の高いRailsコードの議論をするコミュニティ
  • どのように実装するか迷った時に相談できる

MedPeerさんでは社内教育の一環で、ペア(モブ)プロやプルリク振り返り会をやっているそうです。
この2つ、今の現場でも最近積極的に行っておりドメイン知識の共有にもかなり役立っています。
発表を聞いて、チーム開発ではメンバーの知識の標準化が大切なんだなと思いました。

佐々木 達也(Classi株式会社) さんの「Classiでの負債返却への取り組み」

佐々木さんの発表では、いかにして負債の返却を行ってるかの発表でした。
自分の最近の業務内容と照らし合わせ共感できる部分が多く、「あーわかるわー」とつぶやきつつ聞いてました。

ペアプロ/モブプロの導入
  • 一人だと辛いコードもみんなで読むと読める
  • チーム内で知見とやれた感が共有できる
  • みんなでやった感がある
聖地部
  • 負債返却のための活動
  • モブプロで行う
  • 2h/週で開催
  • ボーイスカウトルールの精神
  • 今までやれなかったことができる
  • 小さな成功体験が積み重なる
一人の方が早くね?
  • 大切なのはPRマージ(=リリース)までの時間
  • レビューはベテランがやりがち(=結局時間かかる)
  • モブプロならベテランがコード書ける

発表を聞いて、やはりモブプロのメリットは多いなと思いました。 また聖地部という活動で、定期的に負債返却を行える環境がとてもいいなと思いました!

村上 大和(メドピア株式会社) さんの「メドピアにおけるライブラリアップデート」

タイトル通り、どのようにライブラリをアップデートしているかという内容でした。
自分はこのような作業はやったことはないのですが、なるほどなーと思いつつ聞いてました。
1年数ヶ月ぶりのbundle updateの苦労話から改善の流れが聞けて面白かったです!

bundle update flow
  1. CIにて毎月1日にbundle updateのPR作成
  2. 担当者3人で差分チェック
  3. 必要であれば修正
  4. テスト環境にて1週間漬ける
  5. リリース

発表を聞いて、やはり小まめなupdateは大事なんだなと思いました。 また仕組み化することで運用しやすくなるとのことでした。 npmのupdateも同様に、yarn update flowとして行っているそうです。

小室 直(クックパッド株式会社) さんの「クックパッドの巨大 Rails アプリケーションの改善」

「お台場プロジェクト」というプロジェクトを立ち上げ、cookpad_allという巨大なRailsアプリをどのように改善していったかというお話でした。

お台場プロジェクトでやったこと
  • 開発メトリクスの定点観測
    • コード量、起動時間などを可視化、計測
    • 改善結果を見える化
  • シムテム削除
    • 不要なAPIやworkerを削除
  • システムの分割
    • システムを正しく分割
    • 機能のマイクロサービス化
  • コード削除
    • 頑張って不要コード削除
    • 頑張って不要Gem削除
    • Code Cleaning Contest
      • コード削除コンテスト
      • 豪華景品も

発表を聞いて、ただただすげーと思ってました笑
お台場プロジェクトがうまくいっている要因にプロジェクト名をつけたことを挙げられてましたが、自分も数ヶ月前の業務で似たような経験がありとても共感できました。
プロジェクト名をつけることでチーム全体が同じ問題にフォーカスでき、良い結果につながったと認識してます。

最後に

今回は現場で実践している様々な負債返却方法が聞け、とても参考になりました。
得られた知見を今後の業務でも活かしていけたら良いなと思いました!