日々Derailment

技術的なことの備忘録。脱線事故が起きまくってるので、なるべくrails wayを守れるよう頑張ります。

Railsdm、個人的備忘録

Railsdmに参加する上でのテーマ

①現状の課題に対するヒントを得る
②外部とのコネクション形成
この2点。
会社の業務時間で参加する以上、やっぱり確実に得るものがなくてはならないなと。


①はもっぱらチーム作りとか、他社さんで新人さんの受け入れとかどうやっているのか、っていうのが気になっている。
技術的なことを学ぶのはもちろんなのだけれど、いまはとにかくチームをスケールさせていくヒントが欲しい。僕の今の行動が会社のエンジニアリング文化に繋がっていく状況だから、よりよいEX(Employee Experience)を生み出すにはどうすべきか、見つけたい。

②に関しては、仰々しく言ってるけど、単純に友達が欲しいだけです。はい。

Railsdm Day1

◯keynote1 "Ask Me Anything" by DHH

@dhh ・仕事で聞けず!

◯A-1 アプリケーションを作るときに考える25のこと

twitter.com

www.slideshare.net

これは僕の中で、通常の会社にあるであろう当たり前、railsにおけるデファクトスタンダードとかそういう知見が欠けているのでそのヒントを得るべく聞いた。
当たり前の品質、と言う部分、これ目の前の作業に必死になりすぎると見落としちゃうんだけど、常にこれを考えなきゃダメだよなぁと。
あと、githubのdependentsで追う、っていうのはなるほどと思った次第。アンテナ貼ってかないとね。

◯C-2 少人数でサービスをすばやく開発するためのRails活用事例

twitter.com

speakerdeck.com

「ヒューマンエラーを仕組みで解決する」
これは現状、うちに人が少ないからこそそういう取り組みをしていかなくてはいけないと思っている。

◯LUNCH SESSION B 現場Railsの執筆現場

twitter.com

ランチチケット取れなかったけど、社内の人材育成で現場railsめっちゃお世話になってるので聞いてみたかった。 どうやって初心者にわかりやすく伝えるか、すごく課題だと思っていた。 ここでの質疑はDay2の懇親会での質問に繋がる。

◯A-3 What's new in RubyGems 3.0

twitter.com

www.slideshare.net

これは基礎的な部分をもっと知らねばなるまい、という課題から選んだ。
B,Cトラックも気になったものの、うちは現状vue.jsを採用しているものがあるのでcssはscopedでなんとかなるだろうというのと、あれこれ手を出している余裕はないかなというところもあった。
とりあえず、GMOペバポさんのマネージメント手法(年俸一律200万アップ)ずるい笑

◯A-4 Talentio をなんとかしようと頑張ってきた18ヶ月の旅路

twitter.com

speakerdeck.com ・~するのは当たり前だよね、ということはやる
・無理をしないことを重視した
・一気にやらない
当たり前がそもそもなんなのかっていうのを知るのに結構苦労してる。
けど、まずはその当たり前の土台を整える動きを優先してるのは間違ってなさそうで良かった。
あと、うちはエンジニアが僕一人なんで、無理してはいけないってのは本当に大事。
無理して潰れるのはただの独りよがり。
あと、大概一気にやろうとしがちなので、気をつけたい。

◯B-5 サービスを成長させる「仮説検証文化」のつくり方

twitter.com

speakerdeck.com

人数が少ない以上、リソースの無駄撃ちをしている余裕はなく。
そんな中、どういう優先順位で施策を行っていくか参考にしたかった。
施策が機能しているか=点、ユーザー体験が向上しているか=線
という概念は非常にわかりやすかった。

直接目で見る定性情報を増やしていく行動が大事 直接目で見る。これほんと大事。

◯B-6 Rails な受託の会社でぼくがやっていること

twitter.com

speakerdeck.com

会社のエンジニアリング文化を醸成していく上で非常に参考になる。
特に「永和村に新しい仲間がやってきた」あたりからのくだり、めっちゃ意識したい。

◯C-7 ユビレジのチーム開発

twitter.com

speakerdeck.com

こちらもチーム作りの参考に。
育休からの復帰の話(Welcome Back! id:katorieって写真飾っちゃったり、業務面でのフォロー)とか、17時に帰らなきゃいけないなら16時から飲みにいけばいいとか、こういうチームめっちゃ素敵。

◯C-8 7年目を迎えたRailsアプリケーションの傾向と対策

twitter.com

speakerdeck.com

rails wayから外れそうな時、どうするべきかというヒントになる話。
ServiceObjectとか、実装にクッソ悩んでた(今も悩んでる)のですごく勉強になった。
ただ、これはtweetもしたけど、rails wayから極力外れないためにどういう選択をするかだし、service objectの責務とかの設計をミスらないように気をつけたい。

◯A-9 Red-Black Tree for Ruby

twitter.com

speakerdeck.com

データの構成も悩みのタネで、何か参考になればと。
が、俺にはまだ早すぎた。

A-10 毎日の開発に役立つRailsプラグインづくりの秘訣

twitter.com

speakerdeck.com

Why Don't You Create Your Own Gems?→僕の場合は、ほぼ100%「現場の問題を解決するため」
問題を解決するGem、って結構ミクロな視点で考えてたけど松田さんが問題と捉えている事象は抽象度が高くて(E2E描くのめんどい、誰でもテストサクッとかけるといいな)、物事の捉え方を考え直さなきゃいけないなー、と思った。
あと松田さんがジョジョ好きなことは心で理解した。

f:id:ys3128:20190324011010p:plain

◯Keynote2 まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

twitter.com

t.co

この先のキャリアをどう見据えていくかを考えさせられた。
できれば「圧倒的な実力で倒す」部類にいたいと思う。

懇親会

rejectされました。

こんなことtweetしてたら、なんかまさかの拾ってくれる人が現れた。

あえてrejectされる必要もないでしょう!笑
今年は「迷ったらより面白そうな方向へいく」というのがテーマなので、普通に話しましょーと攻めてみたら快諾された笑。

Railsdm Day2

2日目は↑の懇親会の約束を果たすべく、気合い入れて9:00に会場ついた。
けど、誰も並んでいなかったので、ちょっと拍子抜けした。(1日目より人少なかったっぽい?)

◯C-11 サービス開発初期の「時間を金で買う」技術

twitter.com

speakerdeck.com

・何が会社の成長にとって一番効率がいいのかを常に考えなさい。
・金額ではなく費用対効果
というのを常日頃社長に言われる状況において、この話を聞くのはmustだった。
具体的なりん議の通し方のヒントとかすごく参考になった。
やっぱり経営者と話をするのに必要なのは基本数字。
環境がエンジニアの採用コスト、って話はどうにもならんときに活用してみたい。

◯A-12 Clean Test Code, Revised

twitter.com

speakerdeck.com

絶賛テスト整備中なので、わかりやすいテストを書く上での参考に。 describeとかはとにかく書きすぎぐらいでやっていこう。 テストをみただけで、誰もが何やってるかわかるように書く。

◯A-13 エンジニアリングマネジメントの孤独と向き合う

twitter.com

マネージャーの役割と課題について。
いままさに、全部やらざるを得ない状況でマネジメントの仕事はなんなのかを参考にしようと。

◯C-14 SmartHRでの最初の1年

[https://twitter.com/risacan:embed:cite]

これ、最初のRails OJTをどう進めたのかもう少し具体的に聞いてみたかったな。
学習方法等々は完全にその人にお任せな感じなのかな?
体験入社してみるべきか・・・?

余談ながら、willnetさん登壇→willnetさんが入った効果とか話してくるコンボずるいです。
羨ましすぎる。

◯LUNCH SESSION A モチベーションクラウド、マイクロサービス化計画

いつも銀座railsでお世話になってるリンモチさん! マイクロサービス化の具体的なお話。 共通DBの状態で専用APIサーバー立てる→DBを切り離してAPIサーバーに寄せるっていう順序とかリニューアルでリファクタリングとかも同時に進めないとか、マイクロサービス化する際には参考になりそう。
そして、かつ重おいしかった。

◯B-15 操作履歴/時点指定アクセスの実現 - BiTemporal Data Model の実践

twitter.com

t.co

データの扱いの参考に。
論理削除、履歴テーブル、いろいろな手法がある中で、BiTemporalという2つの軸を用いたデータ管理方法について。
最後にリポジトリpublicにしたのいいね。

◯B-16 ログを解析し続けてわかった、会社で眠っているアクセスログを活用する5つのプラクティス

twitter.com

speakerdeck.com

ログを効果的に扱うためにどうすべきか。というお話。 Slackに投げてくスタイル、いいすね。

B-17 ガチスタートアップ1人目のバックエンドエンジニアのリアルな戦略と奮闘

twitter.com

speakerdeck.com

もうね、ひたすら全面同意。 ほんとうに、スタートアップはいいぞ。 色々と整っている環境下では経験できないことだらけで。 これがカオスエンジニアリングってやつですよ。(誤用)

C-18 Railsフロントエンドボイラープレート「medpacker」の紹介

twitter.com

speakerdeck.com

より、高速に開発環境を整えるための取り組み。
Application Template便利だな。

C-19 自分たちを信じられるチームが作りたくて私はこうした

twitter.com

t.co

スクラム開発のお話。
ここまでキレイに稼働していると日々の開発が楽しいだろうな。
うちの会社は人数少ないんで、個々の責任にしてしまうことが多々ある。
問題 vs チームって考え方は常に念頭において仕事をしていきたい。

B-20 Charty on Rails

twitter.com

speakerdeck.com

Chartyというグラフ描画ライブラリのお話。
仕事でちょっとグラフ使いそうかなと思って聞いて見たかった。
どっちかというと話を聞かせていただいて響いたのは、red-data-toolsというプロジェクトの存在だった。

red-data-tools.github.io

ポリシー、すごくいい。

当たり前だけど、いま当たり前のように使っているgemとかも全て誰かが作ってくれてるんだよね。
僕も何かしら、コミュニティに返せるものや、未来に残せるようなものが作れるといいな。

Keynote Rails 6, Progress and Maturity

twitter.com

Rails 6と今後の展望について。
僕からお伝えできることはcoffee scriptとようやくおさらばできる、ということぐらいです。
とりあえず、英語もっと勉強しよう。

懇親会

懇親会、1日目に参加できなかったからめちゃくちゃ楽しみだった。 とにかく恐れず、話したいspeakerさんと話すことを決めていた。
AMAとか聞く&メモに必死&質問の書き方悩んでるうちに終わっちゃったんで笑

備忘録も兼ねて、聞いたことを端的にまとめる。

◯Speee株式会社 VPoE 大場さん ・本日のLTの中で「マネージャーとして必要な十分な技術」という部分があったが、その技術の基準とはなんなのか?どこまで身につけたらいいのか?→ベンチャーなら、自分で技術の度合いをコントロールするのは難しいかもしれない。会社にとって必要なことをとにかく全部やる。その過程で身につくものが、必ずマネージャーとして役に立つ。
・会社の成長に対する自分の成長の遅れが気になっているがどうすべきか?→開発支援の会社とか入れて整えた方がいいかも。willnetさんとか、絶対いい。
・外部とのコネクションを創る上でLT等で発信していく戦略はどうか?→中長期で効果が出る。短期で効果が出ることをあまり期待しない方がいい。
・雇いたいけどコストとのバランスが難しい→会社の成長の軸は3つ。サービス、ファイナンス、人。だいたいいずれかの軸が伸びて、それに追従する(サービスがうまくいく→VCから資金流入とか)。綺麗に全部伸びることはない。
工数の見積もりを誤って会社のフェーズを遅らせるなら、外部から人を入れて見積もり立ててもらった方がいいのでは?→見積もりを任せるな。それ意味ない。自分で経験して身につけろ。
・下手な人を入れることになりそうで、人員を増やすのが怖い→どんな会社であれ、自分の望んだ通りの人材をピンポイントで入れることはそもそも難しい。参考としてはクラウドワークスの時は、役員全員の合意が取れた人材だけ入れた。代表がこの人良い、といっても全員の合意が取れない場合は入れないという形をとっていた。

↪︎失敗を恐れずに。大概失敗しても会社が潰れる事態にはならない。ただ、必ずそこから得た経験を会社に対してアウトプットすること。

◯櫻井さん
・「初心者の頃の自分が見て、理解できるように書くことを心がける」とあった(前日のランチセッションでのお話)が、「初心者の頃の自分」というのは何かとバイアスがかからないか?初心者の視点というものを定義するならなんなのか?→初心者の自分が詰まらなかったところは、レビューとかしてもらうと突っ込みが入ったりする。トライアンドエラー、フィードバックを通じて最適化していくしかない。

◯前島さん ・いまは仕事を募集していないという話(札束で殴る会社は考えます)だったが、技術顧問として入る会社を選ぶ基準はあるのでしょうか?→いまはたまたま仕事が立て込んでるので受けられない。タイミングが合えば受けることもある。
・技術顧問のコストっていくらぐらいなんですか・・・?→それはさすがに表立って言えない。
思い返すとめちゃくちゃ不躾なこと聞きました!前島さん、すいませんでした、、、。

あと、speakerの方々の中では特にrisacanさんは話を聞いてみたかったな。
どこかでお会いする機会があればぜひお話をさせていただきたいものだ。

◯@ngmt83さん Day1での約束を果たすことができた。
どんな人だろ、と思ってたけどまさかの同い年だとは思わなかったなー!
エンジニア歴も僕より長いし、ご家族もいらっしゃるとのことで、尊敬するばかり。
すごく良い刺激になって、前向きに行動した方が良いことあるなと改めて思った。
ぜひ今後とも仲良くしていただきたいものだ。

最後のrailsdm

すごく、すごく良い時間だった。
僕のエンジニア人生における一つのポイントだと思っている。

こんな場所を用意してくれたカルパスちゃんさん本当にありがとうございます。
twitter.com

ただ、最後の発表はびっくりしたね。
悲しいかな、railsdmは今回で最後なんだとさ。
記念の回に参加できて本当に良かったけど、もっと同僚とかと来たかったな。








次からはrails kaigiとしてパワーアップ

というわけで次はrails kaigi 2020として、パワーアップとのこと。
この頃には、会社の同僚とかチームで参加とかできるようになってるといいな。
もちろん、自分で技術的なことでアウトプットできると一番いいなと思ってるけど!

もっともっと腕磨いて頑張っていこ!

銀座Railsで話しますー。

明日は銀座rails。 railsdm聞いたあとってのもあるし、初登壇だし、
Rails Tutorialで独学で覚えた勢なので@Yasslabさんくるのもあってさらに緊張している。
一言で表すととにかく緊張している。
資料とか見直すとああでもないこうでもないって、直して直してを延々と繰り返してる。
が、失敗しても死ぬわけじゃないんだ。気楽にいこう。
たぶん、「あ、こんなレベルでも喋って良いんだな」っていう踏み台として僕は後世に残ると思う。
みんなもっとLTしよう。