$shibayu36->blog;

株式会社アンドパッドでエンジニアをしています。プログラミングや読書のことなどについて書いています。

RubyKaigi 2022にオフライン参加しました

ANDPADに入社してRubyistになったのでRubyKaigi 2022にオフライン参加してきました。

rubykaigi.org

久しぶりのオフラインカンファレンス参加、本当に楽しかったです。最近オンラインのカンファレンスや勉強会に行っても中々いろんな人と話す機会が持てず、なんとなく行かなくなっていました。今回久々にオフライン開催ということで行ってみたら、久々に会った人と技術的な会話ができたり、ブースでいろんな企業のことを知れたり、ふらっと見てみた発表で異常な技術が発表されていたりと、楽しいことが盛りだくさんでした。オフラインとオンラインのハイブリッド開催は非常に大変だったと思いますが、運営の皆様ありがとうございました。

印象に残っていること

今回視聴者として印象に残っているのはこの辺り。

  • 久々に技術でねじ伏せる人たちを生で見れたのが良かった。自分もまだまだ技術を学ばないとという気持ちにさせられた
  • kateiさんが発表していた、RubyWebブラウザで動くようになるために、Ruby自体に手を入れたり仮想ファイルシステムも作ったりみたいな話はとんでもない話だなと思った。ブラウザでirb動いてgemのインストールができるとか意味わからなすぎる。「Cookpad Code Puzzle for RubyKaigi 2022」もブラウザで動いて回答できるというのも良かった。とにかくすごい
  • ペイトナーさんのRuby/Railsクイズが面白かった。自分がまだまだRubyRails初級って感じなので、普通に勉強になった。
  • hfmさんと久々に会って(というかリアルだと実は今回初なんだっけ...?)、基盤開発むずい〜って話だったり、クックパッドマートだとリアルデバイスの難しさがあってという話だったりを雑談できたのが楽しかった。気づいたら2時間くらい話していた

ブース担当

またANDPADは企業ブースも出店していたので、ブース担当も行った。二進数足し算RTAも結構盛り上がり、いろんな手段で高速に足し算されていて面白かった。

自分がブース担当が初めてなこともあり、ちょっと反省点もいくつかあった。これは次に担当するときは気にしておきたい。

  • 会社Tシャツを着るときは、3日間使えるように、いい感じに下に着れるシャツを持っていく・懇親会をする前に着替えるのを徹底する
  • ノベルティや景品は各社工夫をしている様子だったので、参考にしたい

まとめ

こんな感じ!やっぱり久々にオフラインで参加すると良いですね。次に参加するときは、もっとRuby力を上げて、Rubyistの知り合いも増やして、さらに楽しめるようにしていきたいと思いました。 改めて運営の皆さんありがとうございました。

Findyさんのイベントで「今の生産性向上活動で大切にしている考え方」という発表をしました

開発生産性を高めるヒントを最前線で働くエンジニアによる取り組みから考える会 - connpassのイベントで、「今の生産性向上活動で大切にしている考え方 〜開発チームに属した改善活動から得た気づき〜」というタイトルで、開発生産性に関する発表をしてきました。

speakerdeck.com

自分はこれまで、10年近く開発チームの中からボトムアップでチーム改善・生産性改善をしてきました。例えば、GitHubを使った開発フロー改善、チームごとの開発生産性の定量化・可視化、バリューストリームマップを使った、開発フローのボトルネック発見、CIの高速化などによる生産性改善、Findy Teamsを使った生産性可視化と改善などです。

それらの活動では失敗も成功もありました。その体験から、改善活動をしているときに裏で大切にした方が良い考え方についても明確になってきました。

そこで今回は、「今の生産性向上活動で大切にしている考え方」の言語化を試みて、発表することになりました。具体的には以下の三つのことを大切にしています。

このことについて、発表で深堀りしているので、興味があれば是非資料を見ていただければと思います。ちなみに僕は以下のスライドが気に入ってます。

他の発表の感想

他の方の発表も「わかるわかる」と頷きながら聞いていました。簡単にですが感想です。

開発者の生産性向上の始め方・育て方 〜生産性向上チームの 7 年間から見えてきた知見〜 宮田 淳平さん(サイボウズ株式会社)

  • スケールするにつれて、改善活動を支援先のチームと進めていく、自力で改善活動を継続できるように、というのが良い話だなと思いました。「自分達で改善する」のではなくて、「改善できる能力をインストールする」みたいな感覚
  • 利用は強制しない、もめっっっっっっちゃ大事だなと思いました。基盤チーム・生産性向上チームが、変に標準化してしまって、逆にプロダクトチームの工夫を阻害するというのがあるあるなので、自分自身も気をつけていきたいです

OKRと連動した開発スピード向上のための土台づくり 前島 治樹さん(株式会社hokan)

  • インシデントスコアを付ける、なるほどと思いました
  • 障害の根本対策をするとき、「クリティカルなものは根本対策してもう起こさないようにする」「クリティカルでないものは、あえて根本対策をせず別の施策を優先する」の両方が大切だと思っています
  • インシデントスコアをつけることで、うまく両方を満たせそうだと思いました

開発生産性をハックする話 神谷 健さん(ファインディ株式会社)

  • まずは「生産性高そう」から始めませんかというのが非常に良かったです。エンジニアをやっていると、その特性からか「生産性などのデータを取るならちゃんと定義を決めないと」と思いがちなのですが、最初から定義を決め過ぎようとすると動けなくなってしまうというのがよくあるので、参考になりました
  • 自分もPR数という指標は思ったより良さそうと感じてます。自分もよく「1日1PRくらい作れると良いペースですね」という話をしてます。PRを細かく分けてもらえると、素早いフィードバックが回るんですよね
  • その上で、指標を給与の評価には使いたくないよね、は本当にその通りだなと思いました

参考: これまでの自分の生産性向上活動に関する記事

Re: チームのベロシティを上げる vs. 安定させる

yigarashi.hatenablog.com

これが良い話だなと思ったので感想メモ。

「安定させる」のは良い。安定しないならチームの開発フローに問題が起こっていることが多く、「なんでブレちゃうんだっけ?」という議論からチームの課題が見つかることが多い。安定させるという考えなら変なハックが起こらない傾向にある印象

「上げる」は難しい。これまで、「上げよう」とした時に、ベロシティは基準によって変わる相対的指標なので、上げようと意識するとどれだけ気をつけても無意識にハックしてしまう経験がある。例えば

  • 完了条件には完全に明文化されていないような地味かつ大切なポイントが終わっていない(例えばコードのメンテナンス品質が思ったより低い)時も、上げる意識だと終わりにしてしまいたくなる
  • 考慮もれを見つけた時に、そのタスクで終わらせる意識ではなく、新タスクを作ってそっちで倒す意識になりがち
  • 何となく、悲観方向で見積もりをつけてしまう

そのため自分は、「安定させた上で、その後は価値提供の量および価値提供のスピード(フロー効率)を意識する」ようにしている。

ただし、以下のコメントもめちゃくちゃ分かる。

チームのベロシティを上げる vs. 安定させる - yigarashiのブログ

安定を優先すべきと頭ではわかっているが、数値的に上がっているのを見てモチベーションにつなげたいときがある

2022/04/26 11:28
b.hatena.ne.jp

この観点に関しては、以下のように考えている。

  • 成功体験を積むために、一番気軽な「ベロシティが上がった!」という体験をしたいということがある。つまりチームが理解しやすくするために敢えてベロシティに着目する。
  • その場合も、少なくとも先導する側は、「安定してユーザーに価値提供ができるチームを作る」「最速で価値検証ができるチーム」など、最終的な目標への意識を忘れないようにしたい
  • かつ、ベロシティに着目することを徐々にやめられるように、少しずつアジャイルの知識をチームに浸透させることが必要だと思う
  • なんだけど、「ベロシティあげよう」使ってしまいがちなんだよな〜〜〜〜〜〜〜〜(自戒)