scouty ✕ Goodpatch Engineer MeetUp 〜プロダクト開発との関わり方〜
scouty ✕ Goodpatch Engineer MeetUp 〜プロダクト開発との関わり方〜 で聞いたことメモです。
@g = GoodPatch
@s = Scouty
TL;DR
GoodPatch
- スクラム
- ストーリーポイントはTシャツのサイズ(S,M,L,XL)
- カンバンで運用
- 目標設定はOKR
- 代表が会社OKRを作る→会社KRが部門Oになる→そこから個人にも
- 週次、月次で1on1して目標に対して足りてるのかフィードバック
- 最終的な評価にはOKR、社内外での行動(登壇、誰かの役に立つとか)、エンジニア評価
- エンジニアにどう評価されたいかヒアリングして評価軸を決めた
- サービス、プロダクトへの貢献
- 技術貢献(専門性
Scouty
- 教科書通りのスクラムを実施
- ZenHub利用
- 3ヶ月に1回給与には繋がらないフィードバックのための360°評価している
開発の進め方
ZenHub使って管理@s スプリントMTGでプランニングポーカー@s ベロシティと残業時間も計測している@s 逆算して開発以外の時間を割いてしまったのか見てる@s
カンバンでアナログにやっている@g 開発のカンバン、デザインのカンバン等分けてる@g ストーリーポイントはフィボナッチ数じゃなくS,M,L,XL@g 週に何回か改善タイムを設けている@g
デジタルで不便感じてるところは? KPTはホワイトボードに張ってる。KeepはTrelloに移してる@s
KPTでカンバンの改善してる@g マスキングテープで線引とか 剥がし方取り方のレクチャーとか 下に引っ張るか横からか
組織図、開発体制
ホロクラシー(階級のないフラットな組織)、フロント、バック、インフラなど専門職がいる@s
属人性高いと個人が決めた技術選定正しいのかとか、退職のリスクは? メインで持ってるロール以外にバックアップのロールがある@s 複数にまたがる場合は? 複数のロールで話し合ってもらってる@s
ペアプロ、モブプロ試してる@g
スクラムは基本的に多能工が理想だけどホロクラシーだとやりづらいのでは? 基本スキルは全員持っていることが前提なので大丈夫@s 飛び抜けた技術等についての属人化は許容している@s 多能工についてはあまり意識していない、諦めてる@g T字型がいいって言うけど突き抜けてるものもありだと思う@g 多能工ばかりになるとダイバーシティにもならない@g エンジニアチーム全体でいいポートフォリオが出来たら良い@g
採用手法
幹部候補にはリファレンスチェック@g 面接に出るメンバーには面接官トレーニングしてる@g
スキルテストしてる@s
コーディングテストはやってないけど良いサービス出てきてるので試したい@g 口頭でスキルチェックしてる@g
- Jsの言語仕様について
- Reactの実装聞いたり
- ネイティブはこういう時どう実装するか?
- アプリ見せてあなたならどうするか?
リストビューで実装する→データ多かったらどうチューニングする?
評価制度
3ヶ月に1回給与にはつながらないフィードバックのための360°評価している@s まだアイディアだけど1人が5万分持ってて人に送れるとかいいな@s
OKR(半期に1回、3ヶ月で見直し)@g 代表が会社のOKRを作る 会社KRが部門Oになる みたいに掘り下げている@g 週次、月次で1on1して目標にたいして足りてるのかフィードバック@g 最終的な評価にはOKR、社内外での行動(登壇、誰かの役に立つとか)、エンジニア評価@g
GoodPatchのエンジニア評価
ボヤージュのやつを参考にした 1. 評価して欲しい人を選ぶ 2. 評価ドキュメント作成 3. レビュー (ここらへんかな…? GoodPatchのブログ
評価制度だけじゃなく等級グレード、給与の3つを作らないといけない
どう評価されたいかをヒアリングして評価軸を決めた
- サービス、プロダクトへの貢献
- デザインに対する理解と実践
- 提案して採用されたもの
- アニメーションをどう実装していったか
- プロトのデザインを再現できているか
- QCD
- チームへのエンジニアとしての貢献
- プロジェクトの要件や制約条件に対してエンジニアとしてどう対応したか
- デザインに対する理解と実践
- 技術貢献(専門性
- 性能への取り組み
- レスポンス、TAT、FPS、バッテリー、メモリ
- セキュリティ
- リファクタ
- プラットフォーム理解
- 可用性への取り組み
- 保守性への取り組み
- 性能への取り組み
omoiyari.fm #30-1 モブプログラミング、モブライフ を聞いて
omoiyari.fm #30-1 モブプログラミング、モブライフ を聞いてモブプロについて勉強になった箇所をまとめました。
ざっくりいうとモブプロは全員で同じ作業をする。
生産性が下がるのでは?
ペアプロだと2人分の作業が1/2になるのでは…?
モブプロならそれ以上に…?
という声が上がる
そもそも生産性って?
生み出した価値 / コスト
生み出した価値 とは要するにお金
開発チームとしてはリリースできる状態の動くプロダクトのこと
量 / 時間 ではない
並列作業をしたらドキュメントやコードの生産量は増えるが最終的にリリースができる状態(価値を生む)とは限らない。
モブプロでは
モブでやることで作業の同期コストがなくなり、
レビューをする必要がなく、
常にリリース出来る状態になる。
→生産性が高くなる!
モブプロに向く作業 / 向かない作業
課題解決、知識共有、後進育成のためにやっているとのこと。
向く作業
後でチーム全員が知っていると価値があるもの。
問題解決などが向いている。
例えば環境構築
手順書があってもだいたい役に立たない。
手順書はその人の環境でうまくいったパターンの羅列なので意味がないが、
環境を構築するまでの作業・試行錯誤には価値がある。
また、レビューする時に仕様を聞かないとわからないような作業はモブに向いている。
同期コストが大きい作業のことですね。
向かない作業
誰がやっても同じになる作業
同期コストがかからない作業
どれくらいモブプロをやっているの?
その作業に貢献できる人が参加している
別の作業やMTGが会って外れる人は外れていい
最後に
めちゃくちゃモブプロやってみたくなりました👀
Step-to-Rails-Expert.rb#19 に参加しました
Railsの勉強会、Step-to-Rails-Expert.rb#19 に参加してきました!
Step-to-Rails-Expert.rb って?
公式の説明をそのまま…
本勉強会はStep-to-Rails-Expert.rbというRails関連中級者向けの勉強会です。 コンセプトとしては、初心者を抜けたレベルの人が中級者・上級者になる上で、一歩進んだ技術やハマリどころなどを議論形式で共有し、場合によってはともに解決策を考えていけるような勉強会を目指しております。 なお、2017年9月よりExpert-TodoというTodoアプリを各々作って来て参加者同士でレビューし合う企画を実施しております。アプリを作ってきた人だけでなく、そうでない人もレビューの仕方や実装方法などの知見を貯められる企画となっていますので、ぜひご参加ください。
step-to-rails-expert-rb.connpass.com
中級者向けの勉強会!
なんとか初心者からステップアップしたく参加しました👀
感想
今回はTodoアプリのもくもく会でした☁️
環境を作って実装していくはずでしたが、brewの環境がおかしくなってるのかbundle installでコケて環境直してるだけで終わってしまいました…💧
自分の成果としてはほぼゼロでしたが、途中の雑談や懇親会で、できる人達の話を聞いてるだけで勉強になることがいっぱいありました。
トピックス
話していたことをリスト形式でざっと
- データ変更したユーザーを保存しておく方法
- created_by updated_byってカラムを持つのはいいかも
- rails5.2から入ったCurrentAttributesヤバイ
- e2eとか振る舞いさえできれば単体テストいらないんじゃ?
- Custom Copはいいぞ
- RuboCop の実装見るといい
- current_user.posts.create したら異常系でコケる可能性がある
- invalidなレコードが残ってしまう
- 関数型言語勉強するといい
- 破壊するメソッドよくない
- pop shift使わないほうがいい
- after_create はコミットの前なのでメール送信処理とか挟むとsidekiqでnot found になる可能性
- after_commit にしたらupdateでも飛ぶので
on: :create
付けるのをお忘れなく - そもそもフィルターで書かないほうが良い。コントローラのsave後に書いたほうが圧倒的楽
- after_commit にしたらupdateでも飛ぶので
- 「気に入らないコードはapproveしない。こんなコードにapproveした歴史を残したくない」
- 「既存のコードだいたいだめなので」
- ActiveRecord eachで回すならsize、回さないならcountがよい
- bullet 誤検知ある?
- select * のクエリ重いのなんとかしたい
- 5.2から入ったbootsnap 起動が早くなるので良い
- Railsのビュー探索が重い
- SQLの実行待ちが遅いの
- 並列実行できたら早くなる
最後に
できる人達の会話、2,3割くらいしか理解できていなかったと思いますがとても勉強になりました。 つまり、
_人人人人人人人人人人人人人人人人人人_ > Step-to-Rails-Expert.rb はいいぞ <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄
ぜひ参加してください
Sidekiqのジョブを削除する [Rails]
ローカル環境で溜まってしまった無駄なジョブにサヨナラする方法です。
- 処理待ちジョブ確認
- 処理待ちジョブ1件削除
- 処理待ちジョブ全件削除
- リトライ待ちジョブ確認
- リトライ待ちジョブ1件削除
- リトライ待ちジョブ全件削除
- とりあえず全部削除
の7本立て
処理待ちジョブの確認
require 'sidekiq/api' Sidekiq::Queue.new.each { |job| puts [job.jid, job.klass, job.args].join("\t") }
処理待ちジョブ1件削除
require 'sidekiq/api' Sidekiq::Queue.new.find_job(<job id>).delete
処理待ちジョブ全件削除
require 'sidekiq/api' Sidekiq::Queue.new.clear
リトライ待ちジョブ確認
require 'sidekiq/api' Sidekiq::RetrySet.new.each { |job| puts [job.jid, job.klass, job.args].join("\t") }
リトライ待ちジョブ1件削除
require 'sidekiq/api' Sidekiq::RetrySet.new.find_job('job_id /JID').delete
リトライ待ちジョブ全件削除
require 'sidekiq/api' Sidekiq::RetrySet.new.clear
とりあえず全部削除
require 'sidekiq/api' # 処理待ちジョブ削除 Sidekiq::Queue.new.clear # リトライ待ちジョブ削除 Sidekiq::RetrySet.new.clear
GoogleAppScriptでSleepする
GoogleAppScriptで sleep(1000)
は使えなかったので調べた所、Utilitiesクラスで定義されているらしい
Utilities.sleep(1000); // ms