【知見を広めよう】5年目のエンジニアがイベントに初参加してみたイベントレポート
きっかけ
弊社では、評価指標として「積極的な社外研修受講」「社内外コミュニティへの参加」というものがありまして、今まであまり小規模のイベントなどには参加してこなかったのですが、YouTubeを見る形式と、パネルディスカッション形式のイベントを見に行ってきました!!
感想
いきなり感想かよ!となるかもしれないですが、めちゃくちゃ良かったです。
前職でも接点があった人は社内の人だけで、自分の悩みや困りごとの「程度」がわかりませんでしたが、同じ境遇の人がたくさんいたり、上手い切り抜け方(?)を知っていたりと「世界を広げることの大切さ」を改めて実感しました。
結構初めて参加した!という方も多く、今後も時間スケジュールの許す限り参加しようと思いました。
参加したイベントについて
1.麻布台ヒルズ TECH TALK - 開発生産性を高める組織の取り組み -
内容としては、anotherworksという複業を支援する企業が、SmartHR、ケップルのエンジニアリングマネージャー層を招待し、取り組みなどをパネルディスカッション形式で発表する形でした。
2.プルリクエストとコードレビューで開発を加速させるLT会
進行の方がいて、たまにコメントを拾ってくれる感じでかなり気楽に参加できました。
気になったワードについて
このイベントで気になったワードをいくつか紹介します!見たことないワードはお読みいただくとイメージが湧くかもしれないです。
1.麻布台ヒルズ TECH TALK - 開発生産性を高める組織の取り組み -
アジャイル
アジャイルを導入し、メイン製品へパワーを注ぐ、そんなことができたら良いなあという夢を抱くことができた。
弊社では、まずはみんなでアジャイル勉強会を開き、輪読していく感じが必要そう。
一部案件では取り入れているとのこと。
社内で一貫した技術スタック
サーバーサイド:PHP or Ruby
フロントエンド:Nuxt or Next
ローカル環境:Docker or Vagrant
DB:MySQL or PosgreSQL
OS:Ubuntu or Amazon Linux
ミドルウェア:Nginx or Apach
モバイル開発環境:Flutter or ネイティブ(Xcode、AndroidStudio) or ReactNative
といった技術スタックを社内で統一すると社内のメンバーを自由にアサインでき、スイッチングコストを下げることができる。もちろん、技術親和性の高さや、セキュリティ、メンテナンス性、モダンで開発が活発かどうかなども大切ですが、やはりチーム一丸となって取り組む土俵は揃えるべき、と実感しました。
弊社ではフロントエンドはAngularになっているので、Nextを取り入れたい
Vagrantも残っているので、Dockerに乗り換えていくといったことが必要です。
Findy Team +
For KeysというGoogleの提唱する開発生産性を計測する指標を簡単にGithubなどと連携して計測可能にしているそう。
ただ、この数字をハックすることはいくらでもできるので、この数字にこだわるのではなく、あくまでもアクションを起こし、それのフィードバックとして得るという気持ちでやるそう。
なんとなく、APIを駆使すれば、どうにか簡易的に出す方法もありそうなので、調べてみたいと思った。
ただ、弊社は特殊なブランチ運用をしているため、パッと計測することは難しいそう。
スクラムマスター当番制
これも面白い取り組みだと思いました。仕事で大事なのは、「相手の気持ちになって考えること」だと思っています。
ちなみにアドラーによると、、、
「原因ではなく目的を考える」
「人の行動は過去の経験や育った環境ではなく、その未来となる『目的』によって、決定されるとし、適切な目的を見つけることで新たな行動が決められる」
「人間の悩みのすべては対人関係の悩み」
「幸福とは、自己受容・他者信頼・他者貢献」
スクラムマスターを当番制にすることで、他人の粗探しではなく、より良い製品作りに本当の意味で没頭できると思いました。
相手のことを思いやり、円滑に進めることができるハックだと思います。
弊社ではまだアジャイル案件は少ないので、適用できるPJがないか、気にしながら進めたいと思っています。
技術負債解消デー
X週間に1日、技術負債を解消する日に当てるというもの。
リファクタしたいな、自動化したいな、エンジニアは日々そういった悩みに何だかんだリソースを使いがちです。
とりあえずメモしておいて、技術負債解消デーにまとめて片付けると、日々の業務も捗るとのこと。
ただ、話題にもありましたが、新たに文化として作るのはなかなか難しい点があります。
横車を押すくらいの勢いで、説明して、取り入れていくというのも時によっては必要なのかもしれないです。
業務を進めながら、数値化ができる要素についてアンテナを伸ばしておく。
プルリク
詳細をどこまで書くかは悩むところですが、全てのリンクは最低限載せる
特に、「Why」をちゃんとかく(なんかリファクタしたはNG)
ラベルをBotで自動化して使う
- マイグレーション
- フロント
- バックエンド
などをパスなどから分類して見やすくする
生存時間を短くする
PRが残り続けるのは本当に無駄です。理由はともかく、せっかく実装したのに、取り込まれないなんてことがあるのであれば、エンジニアのモチベーションはダダ下がりでしょう。
また、なかなかレビューしてもらえない、実際にテストされるのがリリース直前すぎる
こんなことも精神衛生上良くないです。PRを1時間でも早くクローズする方法を皆で考えるべきです。
KPTの有用性
やっぱり振り返りのフレームワークとしてはKPTが有効
なかなかTできない、Pが怖いみたいなこともありますが、うまく置き換えて議論が活性化するカスタマイズで乗り切れる。
Tryオーナーを立てて、Tryを遂行することも有効。
たまーに別のフレームワークを使うことも良いが、オーソドックスにKPTが一番安定する。
Goodを追加してGKPTとかも有用
スターフィッシュ(ヒトデ)とかおすすめとのこと
1on1
髪切った?元気ない?相手が話したいことはなんだろう?など1on1は相手にどれだけ向き合えるかが大事。
適当にやるくらいならない方が良いかもしれません。
AI系について
Copilot: テストが簡単に書ける
PR Agent:レビューしてくれるが当たってるのは2,3割だが、会話や改善のきっかけになる
2.プルリクエストとコードレビューで開発を加速させるLT会
このイベントで気になったワードをいくつか紹介します!見たことないワードはお読みいただくとイメージが湧くかもしれないです。
コードの作者がいるということはかなり貴重である、今のうちにたくさん聞こう。
相手の時間を奪ってしまう、とか、こんなこと聞いたらどう思われるだろう?とか考えるとキリないので、サクッと聞いちゃいましょう。
ですが、少しでも相手の時間を使わない方法を考えたり、適切にメモしてみんなに知見として残しましょう。
PRは鮮度が大事、PR作成後疑問点はすぐ聞く
PRを出して時間が経ってしまうと、何をやったのか思い出すのにかなり時間がかかったり、Whyがわからなくなったりします。なるべくPRを開けて放置しない、されないように出す時間帯や曜日に気を配りたい。
コードは書かれるより読まれることが多い
コードレビューは多層防御の1要素でしかない
コードレビューはそのコードがどんなコードかがわかる状態を作ることが最大意義
コードレビューは指摘より質問を心がける
コードレビューで指摘が増えた場合はペアプロやガイドライン作成をする
参考:https://zenn.dev/yumemi_inc/articles/safety-project
指摘が増えてしまうのはチームの凹凸を表している
Loomという拡張機能が便利。ブラウザの録画を途中で止めれるがちょっと料金高い
モノリポのPR作成おすすめワークフローについて
- ディレクトリで自動レビュアの設定
- 自動でPRにラベルを付与
- ブランチ名の命名規則チェック
- サブブランチのPR一覧を自動追加
暗黙の前提(OOしなくてもXXなるだろう)を避ける
コードレビューAIはPR-Agent、CodeRabbit、Copilot PRあたりが有名。
分析結果
チームが幸せになるPRの作り方
- 粒度
- AとBを実装した→NGで別PRにするのを推奨
- タイトル
- 探しづらい→【OOAPI】〜〜という感じで探しやすい誰が見ても中身が想像つきやすいタイトルをつける
- 実装理由がだらだらある→上記を参考に修正
- 説明欄
- チケットのリンクは最低限
- 動作確認は動画
- 見た目の確認は画像を添付
- 5w1hが大事だが、特にwhyを書く
- 確認事項を必ず記載する、migrateが必要とか
- 動作と結果をセットにして書く
- 上記の関連:commitを積むとは「物語を書く」ことである
負のスパイラル
イベント後の懇親会
1.麻布台ヒルズ TECH TALK - 開発生産性を高める組織の取り組み -
もっとギラギラしているのかなと心配していましたが、良くも悪くもエンジニアって感じでしたw
有名どころでいうと、⚪︎天、⚪︎イバーエージェントの方などもいらっしゃいました。
そんなに気負わなくて良いということは本当に楽です。
余談
1.麻布台ヒルズ TECH TALK - 開発生産性を高める組織の取り組み -
麻布台ヒルズはめっちゃ迷いました。
都内のビルの場合、侮らない方がいいかもです。。。
2.プルリクエストとコードレビューで開発を加速させるLT会
個人的にもう少し会自体が活発な感じの方が発表の方もやりやすそうだなとは思いました。
Discussion