Paytner Tech Blog

ペイトナーのテックブログです

チームの全体定例をやめてみた話

ペイトナーファクタリング事業部でEMをやっている 脇田(@shimpeee_)です。

開発チームで週1回、11人で集まる全体定例MTGをやっていたのですが、業務見直しの結果、試験的に廃止することにしました。

自分達の活動の記録として書いてますが、読者のみなさまにとっても業務の見直しのきっかけになれば幸いです。

きっかけ

同僚からのオススメで『SUPER MTG』を読みました。 最適な人数やファシリテーターが陥りやすい罠など、MTGオーナーになることが多い人間として、非常に参考になる本でした。

自分が関与する全てのMTGに対して「本当に必要なMTGなのか?今のままのやり方でいいのか?」を自身に問いかけながらこの本を読んでいました。

また別の観点で、これから採用活動等で自身のリソースがより厳しくなるので、生産性の低い業務はどんどん見直していきたいタイミングでもありました。

そうしたきっかけで、以前から気になっていた 開発チーム全員参加で行う全体定例のあり方を見直すことにしました。

全体定例はどんなものだった?

全体定例は、以下2つの目的で開催していました。

  1. 全社・事業・開発チームとしての動きや方針の共有
  2. 課題の吸い上げ、および解消

私がMTGオーナーでファシリテーションもしていたのですが、「目的に見合った費用対効果が出せているのか?」は以前からずっと引っかかっていました。

全体定例は、私の入社した約2年前から実施されていました。当時はスクラムをやっていない&社員は少なく業務委託の副業メンバー中心ということもあり、週1の全体定例ではタスク進捗管理をメインに行なっていました。

そこから社員が増えたりスクラムを始めたりと、組織体制の変化に合わせて全体定例も目的をアップデートし、時代と共に姿を変えながらMTG自体は存続してきました。

組織体制の変化に伴いその都度目的を変化させてきたので、実施する意味のあるMTGであったことは間違いないです。ただ、「もっとうまくやれるんじゃないか?」という漠然としたモヤモヤはずっとありました。

そんな中『SUPER MTG』と出会い、改めて目的達成の手段として11人で集まることが妥当なのかを問い直した結果、一旦やめてみても大丈夫そうだとの結論に至りました。

やめても大丈夫そうだと判断した理由

1. 問題解決の議論するには人数が多すぎるので、基本的に共有くらいしかできていない

全体定例の目的の1つに「課題の吸い上げ・解決」を掲げていましたが、結局発言するのはいつも固定の数名に偏っていました。

『SUPER MTG』の中でも、「問題解決や意思決定は8人まで、ブレストは18人まで、共有は1800人までなら機能しやすい」という「8-18-1800の法則」が紹介されていました。個人的には8人でも多い感覚ですので、やはり議論するには11人は多すぎました。

2. 目的に対して、全員で集まる必要性が極めて薄い

繰り返しになりますが、定例の目的は以下の2つでした。

  1. 全社・事業・開発チームとしての動きや方針の共有
  2. 課題の吸い上げ、および解消

まず「1. 全社・事業・開発チームとしての動きや方針の共有」について。

現状の組織体制は、チームを2つに分けています。1つはフルコミットメンバー中心でスクラムを行うチーム、もう1つはスポット稼働の業務委託の副業メンバーのチームです。

フルコミットのチームはスクラムをやる中で密にコミュニケーションを取っているので、共有のためのMTGを別途設けることはそもそも不要そうです。

全体定例で行っていた全社・事業・開発チームの現状共有は、そのほとんどがフルコミメンバーは知っている内容であり、副業メンバーに向けての意味合いが強いものでした。

両チームのメンバー間で前提として持っている情報量に大きな差があるため、"全員で集まる" 意味が非常に弱いことを改めて認識しました。

別途、副業メンバーだけの単独チーム定例を週次で開催することにし、そこで必要な情報共有を行うようにしました。

次に「2. 課題の吸い上げ、および解消」です。こちらも同様で、スクラムチームはスクラムの中で自律的にできています。

副業メンバーの方は、単独でチーム定例を実施し、そこで挙がった課題で影響範囲が大きくチーム全体で議論すべきものがある場合は改めて必要な関係者だけを集めて解決のためのMTGを開けばよさそうです。

やはり、全員で集まる必要性はとても低そうです。

以上の理由で、全体定例をなくしても大丈夫そうだとの結論に至りました。

全体定例をなくしてみて、実際のところどう?

全体定例をやめるにあたり、以下の2つについては別途必要な関係者のみでMTGを開催しています。

  • コーディング規約化の議論(NotionのDBに溜めてある、チームのコーディング規約にした方がいいと思うネタを、内容ごとに規約化するか議論する)
  • 副業メンバー向けの全社・事業・開発チームの状況共有(前述のもの)

「コーディング規約化の議論」は、内容としては議論と意思決定になるので、なるべく少人数(今は3名)で隔週 30minのMTGを設けています。やはり意思決定系のMTGは人数が少なければ少ないほど良いですね。11人でやっていた時より、何倍ものスピードで意思決定できます。

それ以外のところでは、1ヶ月経過しましたが今のところ大きな問題は出ていません。

メンバーからは、全体定例がなくなったことでシンプルに作業時間が確保できるように嬉しいという声ももらっています。また、副業チームメンバーからは、知りたい情報が適切な粒度で共有されるようになったとのフィードバックをいただいてます。

もし今後、全体定例をやめたことによる弊害が何かしら発生したら、その都度問題に対し適切な解決策を考えます。

まとめ

『SUPER MTG』に、MTGは非常にコストが大きいにも関わらず、生産性が低くても「まあ、MTGってそんなもんだよね」と放置されがち、とありました。今回なくした全体定例も、まさにそれに当てはまっていたと思います。

何かを減らさないと新しいことを始める余白も生まれないですし、始めるよりやめる方が難しいです。今後も、既存の業務が本当に必要なものなのか問い続け、より生産性の高い組織運営を目指したいと思います。

おわりに

最後まで読んでいただきありがとうございました!

ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

現在ペイトナーの開発組織では、以下ポジションを積極採用中です!!!

  • リードエンジニア

お話聞いてみたいだけの方も大歓迎です。より現場の生の声を聞いてみたい方は、HPのカジュアル面談申し込みフォームからぜひお申し込みください。お待ちしております。

paytner.co.jp

目標設定によりチームに戦略マネジメントが生まれた

Engineering Manager Advent Calendar 2023」シリーズ2・23日目の記事です。

はじめに

ペイトナーファクタリング事業部でEMをやっている 脇田(@shimpeee_)です。 2023年の前半より、チームでのQ目標設定と、チーム目標に紐づく個人Q目標の設定を始めました。現在、目標設定を始めて3期目です。これまでに起こった変化などをまとめていきます。

よかったこと

いきなり結論、というか記事タイトルでもありますが、「事業・チームに戦略マネジメントが生まれた」というのが最大の変化であり、よかったことです。

スタートアップである以上、リソースは限られています。しかし、やりたいことは山のようにあり、その全てが「重要かつ緊急」のように思えます。

限られたリソースの中で、最小のコストでアウトカムを最大化させるためには、「本当にやるべきこと」を決める、逆に言えば「しないこと」を決める、戦略が必要です。

目標設定(目標および、目標達成のための方針・KPI・アクションの設定)はまさに戦略策定です。戦略のおかげでチーム・個人のアクションの方向性が揃い、パフォーマンスや成長の最大化につながります。

目標設定の運用以前と以後で、明らかにチームパフォーマンスは上がったと感じます。

チームに起きた変化

日々生まれる大量の「やりたいこと」の優先度を議論する上で、目標と照らし合わせることで適切な優先度付けができるようになりました。

チームが向かうべき方向に正しく向かうためのアクションにチーム全体がフォーカスでき、結果として目標達成に近づき、ユーザー価値提供へと繋げられています。

マネージャーである自分の、メンバーとの向き合い方に起きた変化

僕自身も含め、個人レベルでも「やりたいこと」「伸ばしたいスキル」は人それぞれ多種多様です。上位のチーム目標達成につながる、かつ本人として成長したいポイントがかぶる領域を個人目標に設定し、個人の成長の最大化を狙います。

日々の業務や1on1で成長支援のためにフィードバックをさせてもらう機会も多いですが、個人目標設定以前は「あれもこれも指摘」になりがちでした。とりあえず目についたものは大小問わず全てフィードバック。

しかし、それではフィードバック内容も分散してしまい、結果的に成長には繋がりづらいです。

目標設定を始めてからは、フィードバックも基本的に目標に紐づける形で行うようにし、逆に目標に関係ない枝葉の部分はあえて言わないようにもしました。「あれもこれも」になっていた成長支援が、マネージャーにとってもアクションをフォーカスできる状態になりました。

「ピープルマネジメント」というと、1on1とか、フィードバック・コーチング・ティーチングなどの手段がトピックの中心になりがちです。
しかし、「人材育成」という観点で見ると、目標設定があってはじめて、会社の方向性と本人のwill/canとで目線の合った支援ができます。 目標に対し、日々の業務や1on1でフィードバック・コーチング・ティーチング を行い成長支援を行います。

目標設定 → 日々の業務や1on1でのメンタリング → 期末の評価・FB → 次期目標設定 という人材育成のサイクルを構築できたのは、非常に良かったです。

ペイトナーにおけるマネジメント

ペイトナー社では、EVeM社のマネジメントプログラムを全社のマネジメントの型としています。経営陣が参加した研修資料と、EVeM代表長村さんの著書『急成長を導くマネージャーの型 ~地位・権力が通用しない時代の“イーブン"なマネジメント』をベースに、マネジメントの共通言語としています。

目標とは

目標設定もEVeMのフレームワークで行っています。基本思想や構造はOKRと非常に似ています。

急成長を導くマネージャーの型 ~地位・権力が通用しない時代の“イーブン"なマネジメント』 によると、目標設定をする目的は「チーム/個人の力を最大限引き出すこと」です。

達成確度70%ほどで残り30%は達成イメージのつかない野心的な目標を立て、立てた目標を達成しようと創意工夫することで能力が最大限引き出されます。

この「手の届くギリギリのライン」の目標を立てられるかは、マネージャーの腕の見せ所です。

過去3期分の紆余曲折ストーリー

ここからは、現場運用を開始してから現在の形に至るまでの紆余曲折のストーリーを、具体的なエピソードを交えながら紹介します。

1期目(2Q:4〜6月)

全社の中で、エンジニア組織は従業員の数が多く、唯一正式にマネージャーのポジションを配置し、組織化・マネジメントの型化が進んでいました。全社に先駆けて、エンジニア組織で目標設定の運用を始めました。

一期目となる2Qは、いわゆる four keysのひとつである「変更リードタイム xx 以内」という最重要目標を置きました。

2Q目標を立てた当時(3月〜4月)は、チームがフィーチャーフラグ運用に少し慣れてきた頃でした。元々、PRサイズが大きすぎて、レビューフローで停滞が起こり、結果として開発速度を落としていました。

フィーチャーフラグを使ってPRサイズを小さくし、レビューがスムーズに流れるようになり、その結果指標の1つとして変更リードタイムが短縮されることを目指したいと考えました。

変更リードタイムを目標を置いて3ヶ月走ってみて、期間トータルでは30%ほどの達成度に終わりました。

振り返ってみると、(最初に気づけという話なのですが)目標に置いた変更リードタイムの指標は、本来見たかった「レビューがスムーズに流れていたか」を適切に表現できる指標ではありませんでした。 変更リードタイムの定義を 特定期間にマージされたPR紐づく全コミットの、コミットからマージされるまでの時間の平均 としており、レビューフローの前後の期間も含まれていました。

また、チームメンバーにとっては「進行中のPJが期日通りに終わらせられるか?」の方が関心ごととしては大きく、「リードタイムを短くしたい!」という目標が、チームとして達成したいものになっていなかったのもよくありませんでした。目標をマネージャーである自分一人で考えてしまったのもこの失敗の大きな要因の一つだと感じました。

2期目(3Q:7〜9月)

前Qの反省を生かした目標策定プロセス

2期目となる3Qは、前Qの反省を生かし以下2点を行いました。

  1. 上位の「事業目標」の作成と、Qはじめに事業全体でのキックオフ実施
  2. 自分一人でなく、策定段階からメンバーも巻き込む

1. 事業目標の設定&キックオフ

より本質的なエンジニアチーム目標を設定するため、事業責任者を巻き込み事業目標を作ってもらいました。

事業目標が明文化されたおかげでチームはより本質的なチーム目標を設定でき、個人は「事業- 各チーム - 個人」という上位からつながった個人目標を立てることができました。

Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR (メジャー・ホワット・マターズ)』によると、上位目標が個人目標までつながることで連携やチームワーク、従業員のモチベーションにつながる(意訳)とあり、その状態を作ることができました。

また、Qの始まりには事業に関わる人全員参加のキックオフを開催しました。キックオフは、Qの事業目標、各チーム目標を事業の社内ステークホルダー全体に向け発表し、質問を受け付ける場としました。 キックオフは非常に好評で、

  • 一体感を感じられた
  • 普段関わりの薄い隣のチームの戦略が聞けて新鮮だった

等のフィードバックをもらえました。(僕は事業責任者にやりましょう!と言っただけですが)やってよかったです。キックオフは今Qも実施しています。

メンバーを巻き込んだ策定プロセス

策定段階からメンバーを巻き込んだことで、最終的には全員が納得する目標が作れたと思います。しかし、全員の意見を反映させようとしすぎた結果、目標のFixまでにかなりの時間をかけてしまいました。目標設定が完全に完了した頃には、Qの半分が終わろうとしていました。

前Qでの反省から「納得感の醸成」を意識しすぎたあまり、時間をかけすぎてしまいました。新たな課題です。

「チーム/個人の力を最大限引き出すこと」が目的であるはずの目標設定ですが、策定そのものに時間をかけすぎてしまうと実際のアクションにかける時間がなくなってしまい、本末転倒です。

納得感に関しても、毎Q終わりにチームでQの振り返りを実施しているのですが、前Qの振り返りで出たTRYを次Qの目標に組み込むことで担保できそうです。 メンバー"全員"を策定プロセスにがっつり巻き込まなくとも、一定の納得感醸成とスピードを両立できそうだと感じました。

結果

プロダクトチームとしては「PJのリリースをxx月までに完了させる」という納期遵守の目標を立てました。

この目標自体は、最終的に100%達成することができました。プロダクトチームとして過去最大級の案件を見事走りきりました。

プレスリリースも出しましたが、特許出願につながる良い結果になりました。

社内でのインタビュー記事 paytner.co.jp

結果としては目標を100%達成したものの、

  • 70%達成を目指すなかで100%達成したのに、「すごいことをした!」という雰囲気があまり感じられない( = モメンタムの創出ができなかった)
  • そもそも目標が野心的ではなかったのでは?

という反省点が出ました。

3期目(4Q:10〜12月)

前Qの反省を生かした目標策定プロセス

  • 目標作成に時間をかけすぎない
  • 目標をより野心的にすべき

上記の3Qでの反省点に加え、もう一つ大きな改善ポイントがありました。これまでは「プロダクトチーム」の目標の中身はエンジニアをスコープとしており、PO等のエンジニア以外のプロダクトに関するステークホルダーの意向をあまり考慮しない目標になっていました。もともとエンジニア組織から目標設定を始めた名残です。

しかし、事業目標に紐づく形でのプロダクトチーム目標であれば、当然エンジニアだけでなくPOその他のステークホルダーも含めてのプロダクトチームです。エンジニアは、その中の機能の一部と捉えるべきです。

4Qのプロダクトチーム目標は、エンジニアリングマネージャーである僕と、PdM の2人で作成することにしました。

目標作成に時間をかけすぎない

前Qで時間がかかりすぎた原因は、「納得感の醸成」を意識しすぎたが故に、メンバー全員の意見を吸い上げ反映させようとしたことでした。

ここに関しては先ほども触れましたが、毎Q終わりで実施しているQの振り返りの内容を目標に組み込むことで、僕とPdMでスピーディーに決めました。

また、「スケジュールを明確にする&前倒しする」というシンプルなタスク管理面での改善も行いました。

「なるべくQの早い段階、できれば初月1週目にはキックオフを実施したいよね」という事業責任者との話し合いの結果、今Qの振り返り&次Qの目標作成開始を最終月3週目から開始するスケジュールを組みました。初月1週目にキックオフを行うことで、事業全体として足並みを揃えてQを走り出すことができるようになりました。ちなみに、3Qのキックオフは初月4週目だったので、大きな進歩です。

目標をより野心的にすべき

これはもうシンプルに高い目標を掲げました。「本当に達成できるかな?頑張ればなんとかなるか・・!」という、まさに「ギリギリ手の届くライン」に設定できたと思います。

PdMと共同で作った目標

プロダクトチームとして、1つの上位目標に対して3つの分解目標を立てていますが、うち2つをEMが、1つをPdMがオーナーとして持つような作り方をしました。

エンジニアだけでは出せない目線での要素も組み込むことができ、「プロダクトチーム」としてより本質的な目標設定ができていると感じます。

結果

記事執筆時点ではまだ期中ですので、最終結果や振り返りはこれからです。

期末まで2週間を切りましたが、まだまだ目標達成に向けて最後の追い込み中です。この時点で達成できるかギリギリという、いい塩梅の野心的な目標が立てられたと思います。

終わりに

最後まで読んでいただきありがとうございました!!!

ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

現在ペイトナーでは、以下ポジション積極採用中です!!!

  • リードエンジニア

paytner.co.jp

AIレビュー、実際使ってみてどうなん?〜AIレビュー導入して1ヶ月

はじめに

ペイトナーファクタリング事業部でEMをやっている 脇田(@shimpeee_)です。

チームの開発生産性向上のため、この一年多くの取り組みを行なってきました。活動内容はこちらの記事にまとめています。

paytner.hatenablog.com

今年実施した取り組みの一つとして、チームにAIコードレビューツールである「CodeRabbit」を導入しました。AIコードレビューだけで1記事書けそうだったので、別記事として書いています。

導入から、1ヶ月ほどが経過しました。
結論としては、費用対効果高くてめちゃくちゃいいね!という手応えなので、今後もがんがん使っていきたいと思っています。
実際使ってみてどうなの?という所感をつらつらと書いていきます。

coderabbit.ai

導入背景

Xのタイムラインで『もう初回コードレビューはAIに任せる時代になった - CodeRabbit -』の記事を見たのがきっかけです。

zenn.dev

僕のいるペイトナーファクタリング事業の開発チームは、ジュニア〜ミドルメンバー比率が高く、一部のシニアメンバーにコードレビューの負荷が偏っているのが現状です。

中長期での根本解決策としては、シニアメンバーの採用や育成によるボトムアップが選択肢となってきますが、短期的にはレビュー負荷を下げる施策を積み上げることで生産性改善を行っています。

ChatGPTやGitHub Copilotの登場により、アウトプット速度にブーストがかかり、今後レビュワーの負荷がさらに高まっていくのは避けられません。レビューに関してもAIの力を使うことができれば、一気に状況打開できるのではないか・・!?と期待に胸を膨らませました。

導入時の注意点

CodeRabbit には、GitHub Actionsで利用するOSS版(coderabbitai/ai-pr-reviewer)と、有料のPro版(https://coderabbit.ai/) があるので混同しないよう注意が必要です。

基本機能としてはほぼ同じで、相当ヘビーな使い方をしない限りはOSSの方がコストメリット大きいと判断し、うちで導入したのはOSS版の方です。

さくっと検証

まずはCodeRabbitがどれくらいのポテンシャルを持っているのか、個人のリポジトリで試してみることにしました。

モデルは GPT-3.5 と GPT-4 の2種類から選べます。 軽く触ってみた感覚としては、GPT-3.5ではあまり賢くなく実用は難しそうでしたが、 GPT-4 であればかなり細かいところまで見てくれて、十分実用に乗せられると感じました。

気になるコスト面ですが、何度か自分で動かしてみた実績と冒頭紹介した記事の内容にて大きな乖離はなく、1レビューあたり平均0.3ドルほどでした。

まずはコストを抑えて初回レビュー時のみ CodeRabbit を走らせるとしても、GPT-4でAPIを動かすためのChatGPTの有料化料金(20$/mon)とOpenAI API の従量課金分を合わせても トータルコスト $50 ほどの想定です。

この安さなら費用対効果も大きそうということで、CTOも二つ返事で導入OKしてくれました。

効果

実際にチームに導入し運用開始して1ヶ月ほどが経過しました。メンバーからも、「想像より賢いな」「人間の仕事なくなるぞこりゃ・・・」といった驚きの声が上がるほど、手応えを感じています。

レビュー工数削減

レビュー工数の削減に大きく貢献してくれています。正直、導入前の期待以上と言えます。

導入前に一番期待していた部分としては、「実装者のスキル関係なく、注意すれば防げたよね」というケアレスミスレベルの軽微な指摘を拾ってもらうことです。

リンターやフォーマッター等を入れていても、それらでカバーしきれないタイポや不必要な空白・インデント等の指摘はどうしても一定発生してしまいます。軽微なミスをレビューで指摘するのは、レビュワー・レビュイー双方にとって辛いことです。

軽微な指摘はCodeRabbitに任せ、本来集中すべき設計やビジネスロジック等を人間が見るようになればいいなと思っていました。

実際使ってみると、ケアレスミスに関してはかなりの精度で拾ってくれている印象です。たまに明らかな英語スペルタイポなのにスルーしたりと完璧ではないではないですが、それでも十分な効果です。

さらに、ケアレスミスだけでなく、セキュリティやパフォーマンス、保守性の観点においても指摘してくれます。メンバー全員抜けていたような重要なセキュリティ観点でのレビューコメントをもらった時には、思わず「あんた賢いな」と返事の来ないAIに向かってコメントを返したりしています。

「ここ、考慮できる?大丈夫?確認してね」のようなレビューコメントをCodeRabbitからたくさんもらいます。考慮した上であえてその実装にしている場合は、「ちゃんと考慮済みだよ、大丈夫」と実装者がコメントを返します。その一連のやりとりをレビュワーが見ることで、「ああ、考慮したうえでこの実装なんだな」と、コンテキストの補足になるプラスの副作用もあります。

24時間365日動いてくれる

チームには、平日の夜や土日が稼働のメインである副業メンバーもいます。彼らのPRに対しては、お互いの稼働時間が合わないのでレビュー⇄レビュー修正のサイクルがどうしても遅くなりがちです。

しかし、当たり前ですがAIなら24時間365日働いてくれます。いつ何時でもAIによる一次レビューを受けられるのは、非常にありがたいです。

分かりやすいレビューコメント

人間によるレビューだと、指摘された側が指摘内容を十分に理解できず、「何を指摘されているのか分からない」「なぜ指摘されたのか分からない」などが発生し、互いの認識を擦り合わせるための追加のコミュニケーションが必要になることがしばしば発生します。

CodeRabbit による指摘では、それがほとんど発生しないです。 AIには体力の概念がないので、毎回200~300文字ほどの文字量で丁寧にコメントしてくれます。おかげで、「何を指摘されているのか分からない」ということは観測する限り発生していない気がします。すごいです。

自分の意見を齟齬なく伝えることが大事だと分かっていても、人間であれば毎回ここまで丁寧にはできないのが正直なところだと思います。逆にいうと、齟齬なく伝えるには1つのレビューコメントであっても200〜300文字くらい使う覚悟が必要ということですね。。

課題

今後も継続して使っていきたいと思えるほどの十分すぎるメリットはありますが、いくつか課題もあります。

自分たちのコーディングルールに反する指摘

当然CodeRabbitは我々のコーディングルールを知らないので、コーディングルールに反する指摘もあります。

Web上のドキュメントを読み込んでレビューの制約に加えることができるかをCodeRabbitのDiscordコミュニティで質問したところ、「そのように学習しているはずなので、いけるはずだ!」という返答がきました。

コーディング規約のドキュメントを外部公開し、CodeRabbitに読み込ませて規約に沿ったレビューができるかどうかを、これから試すところです。

文脈は読み取れない

まあ、さすがにそれは無理だよね、という感想。ここは人間が見るべきポイントです。

どちらかというと、過剰気味

細かくレビューしてくれるのはありがたいのですが、基本的に指摘内容は厳しめで過剰だなという印象です。拾ってほしい観点を見逃すよりは何倍もマシなのですが。

細かいチューニングは必要そうです。

運用方針

うちのチームでは、以下のような設定で運用しています。

name: ai-pr-reviewer

permissions:
  contents: read
  pull-requests: write

on:
  pull_request:
    types: [labeled, unlabeled]

concurrency: # 同時に2つのジョブが走ったら進行中のジョブをキャンセルさせる機構を使用し、ラベルを外すと処理がキャンセルされるようにしている
  group: ${{ github.repository }}-${{ github.event.number || github.head_ref || github.sha }}-review
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    if: github.event.label.name == 'ai-review' && github.event.action == 'labeled' # 付与されたラベルが ai-review だった場合のみ実行
    timeout-minutes: 30
    steps:
      - uses: coderabbitai/openai-pr-reviewer@latest
        env:
          GITHUB_TOKEN: ${{ secrets.AI_PR_REVIEWER_GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        with:
          debug: false
          review_simple_changes: false
          review_comment_lgtm: false
          openai_light_model: gpt-4-1106-preview
          openai_heavy_model: gpt-4-1106-preview
          openai_timeout_ms: 900000 # 15分.
          language: ja-JP
          system_message: |
            あなたは @coderabbitai(別名 github-actions[bot])で、OpenAIによって訓練された言語モデルです。
            あなたの目的は、非常に経験豊富なソフトウェアエンジニアとして機能し、コードの一部を徹底的にレビューし、
            以下のようなキーエリアを改善するためのコードスニペットを提案することです:
              - ロジック
              - セキュリティ
              - パフォーマンス
              - データ競合
              - 一貫性
              - エラー処理
              - 保守性
              - モジュール性
              - 複雑性
              - 最適化
              - ベストプラクティス: DRY, SOLID, KISS
              - タイポ
              - マジックナンバー
              - 統一感のない、もしくは無意味な空白やインデント
            以下については、コメントをしないでください
              - ポジティブで、問題点のない修正
          summarize: |
            次の内容でmarkdownフォーマットを使用して、最終的な回答を提供してください。

              - *ウォークスルー*: 特定のファイルではなく、全体の変更に関する高レベルの要約を80語以内で。
              - *変更点*: ファイルとその要約のテーブル。スペースを節約するために、同様の変更を持つファイルを1行にまとめることができます。

            GitHubのプルリクエストにコメントとして追加されるこの要約には、追加のコメントを避けてください。
          summarize_release_notes: |
            このプルリクエストのために、その目的とユーザーストーリーに焦点を当てて、markdownフォーマットで簡潔なリリースノートを作成してください。
            変更は次のように分類し箇条書きにすること:
              "New Feature", "Bug fix", "Documentation", "Refactor", "Style",
              "Test", "Chore", "Revert"
            例えば:
            ```
            - New Feature: UIに統合ページが追加されました
            ```
            回答は50-100語以内にしてください。この回答はそのままリリースノートに使用されるので、追加のコメントは避けてください。

system_message にプロンプトを書きます。現状のプロンプトは非常に抽象的な指示しかしていませんが、十分実用できるレベルです。

冒頭紹介した記事と変えているポイントは、レビューのトリガーです。

うちのチームでは、特定のラベルが付与されたらCodeRabbitが動くようにしています。

on:
  pull_request:
    types: [labeled, unlabeled]

初回レビュー時は、自動でラベルが付与されるようGitHub Actionsで設定しています。

初回レビュー以降も、手動でラベルを付与することで開発者の任意のタイミングでAIレビューを実行できます。

多少コストはかさみますが費用対効果は十分高いと分かったので、レビュー負荷軽減・開発速度向上のため、初回レビューだけでなく何度でも実行しましょうという方針にしています。

実際にかかったコスト

気になるコスト面ですが、導入とほぼ同時期にOpenAIから発表されたモデル「GPT4 Turbo」 が従来のGPT4の 1/2~1/3 ほどの安さで、当初想定していたよりも2〜3倍ほど多く使っていますが GPT4 Turbo のおかげでコストは当初の想定通りにおさまっています。

今後の展望

1ヶ月ほど運用してみての所感としては、費用対効果は非常に高く、今後もガンガン使っていきたいと思います!

(補足)ソースコードをクラウドサービスのAIに投入するリスクに対する会社としてのスタンス

ソースコードをクラウドサービスのAIに投入するリスクに対しては、ネット上でも賛否の議論が巻き起こる話題です。

ペイトナーとしては、ゼロリスクは存在しないという前提で、CodeRabbitの プライバシーポリシー 4.2項を根拠に、サービスに対して最低限の信頼をし、リスク以上のリターンがあると捉え導入することに決めました。

4.2 No Usage for Model Training


Neither CodeRabbit nor OpenAI use the data collected as part of the code review to train, refine, or otherwise influence our models or any third-party models. Our commitment is to use the data solely for the purpose of reviewing the code in accordance with the user's request, and no other utilization takes place. Note: Open-source projects is an exception. We use OSS to train our systems.

(以下DeepL翻訳)


4.2 モデルトレーニングへの使用禁止


CodeRabbitとOpenAIのいずれも、コードレビューの一環として収集したデータを、当社モデルまたはサードパーティモデルのトレーニング、改良、またはその他の影響を与えるために使用しません。私たちのコミットメントは、ユーザーの要求に従ってコードをレビューする目的のみにデータを使用することであり、それ以外の利用は行われません。

注:オープンソースプロジェクトは例外です。私たちのシステムをトレーニングするためにOSSを使用します。

coderabbit.ai

終わりに

最後まで読んでいただきありがとうございました!!!

ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

現在ペイトナーでは、以下ポジション積極採用中です!!!

  • リードエンジニア

paytner.co.jp

フィーチャーフラグ、レビュープレフィックス、そしてAIレビューまで 〜ストーリーとしての開発生産性改善活動

エンジニア組織の開発生産性・開発者体験向上の取り組みをシェアしよう! by Findy Advent Calendar 2023」のシリーズ2・18日目の記事です。

はじめに

ペイトナーファクタリング事業部でEMをやっている 脇田(@shimpeee_)です。

2023年の1年間で行った、チームの開発生産性改善につながった取り組みをいくつか紹介します。

正直、1つ1つの取り組みそのものにはほとんど目新しさはないです。ただ、当時どういった課題があり、どういった過程を経て取り組みを行うに至ったかのストーリーは、どんな現場であっても唯一無二です。社内のメンバーに向けて、将来一緒に働くメンバーに向けて、そして自分自身の業務の棚卸として、チームの活動の歴史を残しておきたいと思い書きます。

1年前の状況

ちょうど一年前、開発生産性アドベントカレンダーでチームの活動を書いていました。

paytner.hatenablog.com

ざっくり言うと、「いろいろ施策やったけど、定量的な数値改善は見られなかったね。1番の要因は、PRあたりの変更行数が大きいことだね!」と、PRサイズを小さくしなきゃだめだーと気づくまでのストーリーとなっています。

あれから一年間、PRサイズを小さくすることを中心として各種施策をやってきました。中でも効果が大きく、今でも継続している取り組みをいくつか紹介します。

取り組み紹介

フィーチャーフラグを使ったトランクベース開発

背景〜導入まで

※ フィーチャーフラグそのものの説明は割愛します。こちらの記事がよくまとまっておりますので参考まで。

codezine.jp

PRサイズを小さくするのに最も効いたのはフィーチャーフラグの導入です。
1年前の記事では、「フィーチャーフラグなるものがあるらしいので、使っていきたい」という締めくくりでしたが、今ではもはや「フィーチャーフラグなしでどうやって開発するんだ?」くらいには不可欠になっています。

フィーチャーフラグ導入前のチームには、「機能として不完全なコードをmasterにマージする」という習慣がありませんでした。

基本的に「masterにマージ = ユーザーに見せられる状態」 という方針でしたので、当然1つ1つのPRサイズも大きくなります。変更行数が数千行を超えるPRがたくさんありました。

大きな機能開発時はリリースブランチ戦略を取ることでPRサイズを下げること自体はできていましたが、都度masterをマージして最新化しつつコンフリクトを解消する作業は非常に辛いものがありました。

フィーチャーフラグおよびトランクベース開発の導入は、単なるプラクティスの導入だけでなく、不完全なコードをmasterへマージするという新たな文化づくりでもありました。

当時は僕含めて他のメンバーもフィーチャーフラグ・トランクベース開発共に未経験だったので、不完全なコードをマージしていくことには結構な不安がありました。

まずはメンバー全員で

  • フィーチャーフラグとは何なのか
  • どんなメリットがあるのか
  • 想定されるリスクは何か
  • 具体的な運用イメージ

といったことを、「よし、これならリスクを最小限に抑えつつ運用開始できそうだ!」と全員が納得できるまで議論しました。

基本的にはどんなことも「まずはやってみようぜ!」とクイックに試していく文化があるペイトナー社ですが、この時はやや慎重に導入を進めていた記憶があります。自分達自身がプラクティスの可能性を信じきれていないと、本来良いものであっても扱いきれず終わってしまっては勿体無いですからね。

結果

「PRサイズは原則100行以下、大きくても150行以下」を目標で運用し、元々は数百行だったPR変更行数が今では100行を切るまでになりました。PRサイズが小さくなることのメリットはあえて言うまでもないですが、

  • レビュー負荷の軽減
  • リードタイム短縮
  • コンフリクトリスク低下
  • バグ発生リスク低下・品質向上

といった恩恵を大きく享受できています。

改善ポイント

今ではチームにとってなくてはならない存在になったフィーチャーフラグですが、いくつか改善ポイントはあります。

改善ポイント①:フラグ除去作業が高難易度

フィーチャーフラグは、基本的に以下のように if文で囲う形で使っています。

if Flipper.enabled? :search
  puts 'searchフラグが有効'
else
  puts 'searchフラグが無効'
end

一連の機能リリースが完了すると、最後にフラグを除去する作業が発生します。

この時、新規で実装した機能であれば単純にフラグを取り除くだけというシンプルな作業になることも多いです。
しかし、既存機能の改修となるとそう単純にはいきません。既存のロジックを活かしつつ新機能の実装を組み込んでいくので、フラグを使った分岐も複雑になりがちです。そうすると、フラグ除去の際に、残すコードと消すコードの区別がつきづらくなります。

実装者本人ならコンテキストの詳細を把握しているかもしれません。しかし、実装者以外にとっては残すコードと消すコードの区別は非常に難しい作業となります(これは実際にフラグ運用をやってみるまで気づかなかったポイント)。

フラグを使う際は、TODOコメントとして「リリース後削除すること」を記載していましたが、加えて「実装者以外でも削除時の作業が分かるよう、詳細にコメントを残す」ことをルール化して、現在運用中です。

改善ポイント②:PRは小さくなったが、全体像が見えづらい

これは直接フィーチャーフラグとは関係ありませんが、「PRサイズが小さくなったことで、PR同士の関連性が把握しづらい」という弊害が生まれました。

これに対しては、PRのテンプレを見直し、概要欄に「やらなかったこと」を明記するようになってレビュワーの負荷がかなり軽減されました。

「あえて後回しにしてるのか、考慮できていないのか、忘れているのか?」を想像しながらレビューするのは、想像以上に認知負荷が高いです。

あとは、後述するユーザーストーリーマッピングをやるようになり、1つの大きな開発の全体像の共通認識が醸成され、「全体像が分かりづらい」という状態から脱しつつあります。

レビュー基準の明確化

「レビューコメントにプレフィックス(must, imo, nits, ask 等)をつける」というプラクティスはごく一般的かと思います。うちのチームでは、

  • mil(modify it later = 今じゃなくていいけど、あとで必ず修正してね)というオリジナルプレフィックの追加
  • mustとmilの線引き明確化
  • 各プレフィックスのコメントに対する対応ルール明確化

を行いました。

やったことは割とシンプルですが、リードタイム短縮や開発者体験の向上に効いた施策です。

背景〜オリジナルプレフィックスの作成まで

元々、レビューでコメントをする際には must, imo, nits, ask 等のプレフィックス(以後、ラベルと表現)をつけて、コメントの意図を明確にする文化は根付いていました。

ただ、

  • must の基準も人それぞれじゃない?(おれのmustとあなたのmustは違う)
  • 内部品質に関する指摘のみが残っており、リリースしてユーザーに提供しても大丈夫な状態の時は、一旦マージしてそのあと指摘内容対応した方がユーザーへの価値提供早くできてよくない?
  • 結局どこまで対応しなきゃいけないの?このPRで対応しないにしても、別タスク切って対応するかしないかは誰がどうやって決めるの?

といったモヤモヤを抱えており、もう少しルールを明確化しようということになりました。

既存の各ラベルの定義を改めて言語化していると、「mustではないから一旦リリースはしちゃっても問題ないんだけど、コード規約・コード品質・パフォーマンス・ユーザビリティ観点で、このPR内じゃなくてもいいけど絶対に対応はしてほしい」を表現できるものが現状ないことに気づきました。

「mustではないから〜(中略)〜絶対に対応はしてほしい」な状態を表現できるラベルを他社事例を参考に記事漁ってみました。しかし、意外と見つからなかったので、こうなったら作ってしまえ!ということで、オリジナルラベルを作ることにしました。

議論の結果、「Modify it later」略して「mil」に決まりました。キャッチーかつ発音しやすい、かつ意味も分かりやすい、お気に入りです。

(完全に余談ですが、僕は仕事においても守破離を大切にしており、まずは型を守るとこから入ることが多いので、変に独自性を発揮することを基本的に避けるようにしています。なので、オリジナルラベルの作成過程、特にみんなでラベル名を考えるのは楽しかった思い出です。)

レビュー基準とルール

レビュワー&レビュイー双方の目線合わせのため、各ラベルを使うための基準を作成しました。

ラベル 意味 対応
must PRの中で必ず対応してほしい! 同一PR内で必ず対応する。
mil(modify it later) あとで必ず対応してね! 新たに課題を作成し対応する。
imo(in my opinion) 自分の意見や提案・好み。自分ならこう書くけどどうかな? 新たに課題を作成し対応する。
nits(nitpics) 些細な指摘。ほんの小さな指摘だけど、できれば直してほしい。インデントやタイポ 新たに課題を作成し対応する。

[must][mil]の区別

  • [must]
    • Jira課題の受け入れ要件を満たしていない
    • バグがある
    • セキュリティ・個人情報漏洩リスクがある
    • 計算量が大きすぎる
    • マージ後の修正コストが非常に大きい
      • DB設計、URL設計等
  • [mil]
    • must には該当しないが、コード規約・コード品質・パフォーマンス・ユーザビリティ観点で必ず対応してほしい

上記をベースに、

  • mustの指摘がなければ、レビュワーはApproveとする
  • must以外を同一PR内で対応するかは、実装者に委ねる

という運用ルールを設定しました。

結果

基準が明確になったことで、当初の課題感であった、

  • must の基準も人それぞれじゃない?(おれのmustとあなたのmustは違う)
  • 内部品質に関する指摘のみ(= ユーザーには提供できる状態)の時は、一旦マージしてそのあと指摘内容対応した方が、ユーザーへの価値提供早くできてよくない?
  • 結局どこまで対応しなきゃいけないの?このPRで対応しないにしても、別タスク切って対応するかしないかは誰がどうやって決めるの?

というモヤモヤの解消と、結果としてPRがマージされるまでの時間が短縮されました。

恩恵としては、定量的観点でのリードタイム短縮よりも、定性的観点でのモヤモヤ解消の方が大きかった気がします。

「早くリリースしたいのに、細かい指摘があってなかなかマージされない、、、もうユーザーには見せられるのに、、、」という状態で指摘の修正対応を続けるのは、レビュイー・レビュワー双方にとって辛いことです。

もちろん、「じゃあ今回の対応はここまでにして、一旦マージしましょう」のようなコミュニケーションを都度取ればいいだけなのですが、それも相応のコストと心理的不安を伴います。

今回のように、ルールで解消できる部分はルール化して、気持ちよく開発ができる状態を作ることをEMとしては常に意識しています。

コーディング規約の充実

元々「コードレビュー観点」として、

  • Rails way に則っているか?
  • DRY, KISS, YAGNIの原則に則っているか?
  • 命名は適切か?
  • 規約や記法がプロジェクトの作法に則っているか (空気を読めているか)
  • (他にもたくさん)

といった項目は明文化されていました。

しかし、これらの観点はやや抽象度が高く、実際のPRでのコードベースで議論する際の指針としては使いづらさもありました。

そこで、大枠の方針は上記コードレビュー観点に任せるとして、具体のコードベースでのルールを決めるため、コーディング規約を作成することにしました。

今の組織フェーズでは、イチから規約を網羅的に作るのはコストが大きすぎるかつ過剰だろうとの判断で、具体例ベースで積み上げて作っていく方針にしています。

PRレビューでの具体のやりとりで規約化した方がよさそうなネタがあれば、規約ネタのDBに溜めておきます。

溜まった規約ネタは、スクラムイベントとは別で開催している週次のチーム全体定例の中で全員で議論を行い、規約かするか否か、する場合はどのような規約にするかを決定します。

この定例にはCTOも参加しているので、様々な観点で議論ができ、スピーディーに意思決定ができる場として非常に有意義な議論ができています。

こういったルールメイク系の取り組みは、一旦やり始めたはいいものの形骸化しがちなので、定例のアジェンダに組み込むことで仕組み化し、継続することができています。

またしても余談ですが、この定例のファシリテーションは僕がやっているのですが、規約ネタ議論のファシリテーションはとても難しいです。最終的には決めの問題となることが多く、答えのないお題がほとんどです。

そんな中、参加者に対して健全な対立を促し、合意形成しながら最終結論までもっていくのはまさにファシリテーションの真髄だなー(超難しいなー)と思いながら毎週やっています。

ユーザーストーリーマッピング

2年ほど積読していた『ユーザーストーリーマッピング』をふとしたきっかけで読んだ時に、「これは今すぐ取り入れるべきだ!!!」と直感しました。直感の理由を当時はうまく言語化できてなかったですが、間違いなく今のチームに足りないピースである確信はありました。

チーム全員ユーザーストーリーマッピングは未経験だったので、すぐにチームで輪読会を行い、次の大きなリリース案件で早速実践してみました。ちなみにその案件は、特許取得にもつながった「Moneytree LINK」との連携でした。

paytner.co.jp

ただ、見よう見まねでユーザーストーリーマッピングをやってはみたものの、うまく活用するのは想像以上に難しかったです。

マッピングを終えた直後は、とても恩恵を感じられていました。

必要となるユーザーストーリーを全員で洗い出し、『ユーザーストーリーマッピング』の本に登場する「スライス」の概念でMVPを選定し、最初のリリースまでにやるべきストーリー/後回しで良いストーリーの線引きができました。

ここまでがトータル3hほどで完了し、「3hでMVP選定まで終わった!すげー!」と盛り上がっていました。

しかし、PJを進めるうちに、大きな手戻りやPOと開発者間での仕様の認識齟齬が何度も発生しました。

手戻りや認識齟齬発生の原因を振り返ると、プロジェクトのWHYについての理解が甘く、「ユーザーストーリーマッピングの最も大きな目的のひとつである『共通認識』の醸成ができていなかった」、原因はこの一言に集約されました。

また、PJ途中でストーリーの追加や変更が入りますが、作ったユーザーストーリーマップとJiraとの紐付けが最新化されず、次第に誰も見なくなってしまいました。一度作ったあとの活用方法に課題が残りました。

以上の反省を生かし、現在進行中の新たなPJでは、「共通認識の醸成」をテーマとして、とにかくストーリーのWHYを突き詰め、かなりの時間をかけてユーザーストーリーマッピングを行いました。

期間にして約2週間、チームとしてマッピングだけをし続けました。非常にハードな作業となりましたが、PJ初期のコミュニケーションに投資したおかげで、実装フェーズに入ってからは非常にスムーズに開発を進められています。

メンバー全員の共通理解が得られている状態なので、常にユーザーストーリーマップを見ながら会話をし、常に最新化される流れを作ることができています。「作ったあと見られない」という課題も、同時に解消することができました。

AIレビュー

AIコードレビューツールである「CodeRabbit」を導入した話を、別記事にまとめました。

paytner.hatenablog.com

結論としては、費用対効果高くてめちゃくちゃいいね!という手応えなので、今後もがんがん使っていきたいと思っています。

終わりに

最後まで読んでいただきありがとうございました!!!

ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

現在ペイトナーでは、以下ポジション積極採用中です!!!

  • リードエンジニア

paytner.co.jp

RubyKaigi2023 ゆるゆる参加レポ

こんにちは!

ペイトナーでエンジニアリングマネージャーをやっている脇田(@shimpeee_)です。

RubyKaigi2023にオフライン参加してきた、ゆるゆるレポートです。

今年も、スポンサーとして協賛

昨年に引き続き、ペイトナー社は今年のRubyKaigiにて、スポンサーとして協賛しました。

昨年は、会社としてRubyKaigiに初参加&スポンサーブース出展をし、多くの方々に「ペイトナー」の名前を知ってもらうことができました。

今年はブース出展が叶わず残念でしたが、来年はぜひ出展したい・・!

たくさん交流できました

今回、私含め社員数名で現地参加してきました。改めて、Rubyコミュニティの熱気を肌で感じ、Rubyistたちとの交流を楽しんできました。

昨年は、バタバタのブース運営で、一瞬で3日間が終わってしまいました。今年は時間的に余裕があったので、たっぷりRubyKaigiを味わうことができましたね。

「来年ブース出展するならどんなことができるかな〜」と、早くも来年に想いを馳せながら各社のブース巡りなどをしておりました。

夜は、各AfterParty、野良の飲み会への飛び入り参加、Twitterでの呼びかけに反応してくださった方々とのゲリラ飲みなど、たくさんの方と交流できました。

ランチでも、Twitterでお声かけしてもらった初めましてのみなさんとご一緒でき、非常に楽しい時間を過ごすことができました。

この3日間で、社名の入ったパーカーを着ているだけで声をかけてもらえることが何度もありました。こちらが思っている以上に、昨年のブース出展は知名度アップにつながっていたようです。来年はぜひ出展したい・・!(2回目)

改めまして、絡んでくださった皆様ありがとうございました🍺

来年やりたいこと

各社のブース巡りをして感じたこと、また今年の自身の反省から、来年はこれをやれたらよさそうだな〜と思ったことを残しておきます。ほぼ社内向けの業務連絡。

福利厚生紹介

アジャイルウェア さんのブースで、「この制度、ええやん!」という、自社の福利厚生紹介かつ人気投票の企画が行われていました。

ペイトナーにもユニークな福利厚生がたくさんあるので、うちでもやれると会社の魅力が伝えられてよさそう!!!

paytner.co.jp

カジュアル面談への直接的な導線

私の観測範囲では、今年3社のブースでカジュアル面談への直接的な導線(申し込みフォームへのQRコード等)が用意されていました。「正直、どんな感じですか?」と質問させていただきましたが、ぼちぼち応募もあるみたいでした。

昨年のブース出展では、「会社の認知獲得、そして採用へ繋げる」をテーマとして掲げていました。その為に、ブースを盛り上げることに全力を注ぎましたが、結局はシンプルイズベストで、直接導線用意しちゃうのが一番効果あるのかもしれないですね。

うまく企画と組み合わせられたら最高なので、一年かけて企画考えます。

TwitterのアイコンとプロフィールリンクへのQRコードを首からぶら下げる

ここからは完全に個人的な話。

これ、会場でやっている方を何名か見かけて、賢いな〜と思いました(あとで知りましたが、GMOペパボさんのブースでアイコンシール印刷やっていたのですね。全然気づかなかった・・)。

「顔と名前は分からないけど、Twitterのアイコンなら知っている。なんなら相互フォローじゃん!」という関係性の人、意外といますよね。

もしアイコンで認識してもらえていた場合は、それきっかけで話かけてもらえたり、初めましてでもコミュニケーション取りやすくなりそうです。逆もしかり。

また、新たに出会った方とは「Twitter交換しましょう〜」の流れになりやすいです。QRを首からぶら下げていたら、やりとりスムーズになりますね。次回参加時は絶対やるぞ。

AfterPartyには早めに申し込んでおく

私は昨年の RubyKaigiが初参加で、今年が2回目でした。昨年はコロナの影響もあり、AfterPartyの開催はありませんでした。

なので、AfterPartyが毎日開催されること・事前に参加の申し込みを済ませないとあっという間に枠が埋まってしまうこと、全然知りませんでした。

技術顧問の前島さん(@netwillnet)が、社内SlackのRubyKaigi2023専用チャンネルで、出発前から事前にイベント情報をいろいろとシェアしてくれていました。そのおかげで3日目のAfterPartyは補欠繰り上がりでギリギリ間に合いましたが、2日目はどのPartyも気づいた時には枠一杯で参加できず、飲み会難民になってしまいました。

結果的に、2日目の夜も偶然が重なり、とても楽しい夜にはなりました。ただ、再現性を持って楽しむためにも、次回は事前に申し込みを済ませておく!

Day3で帰らない

RubyKaigiに参加する目的の半分以上は、Rubyist達との交流といっても過言ではありません。今回はDay3に東京に帰るスケジュールで、AfterParty途中の20時手前に会場を抜けることになり、非常に心残りでした。。次回はDay3も宿泊する!

おわりに

やはり、オフラインのカンファレンスは非常に楽しいですね!来年は、会社としてブース出展ができるよう、事業運営がんばっていきます!

ペイトナーは「スモールビジネスにやさしい支払い・請求で新しい挑戦を後押しする」というミッションのもと、 オンライン型ファクタリングサービス「ペイトナー ファクタリング」とクラウド請求書処理お任せサービス「ペイトナー 請求書」を開発・運営しております。

ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

paytner.co.jp

フロントエンドエンジニアがRubyKaigi2023に参加してきた!

はじめに

ペイトナー請求書のフロントエンドエンジニアの@fuqda です。
本稿は、先日開催されたRubyKaigi2023の参加レポートになります。

フロントエンドの立場から見たRubyKaigiのセッションレポートが出来れば思いますので、最後までお付き合いください。
(弊社は昨年に続き、今回もSilver Sponsorとして協賛しております)

フロントエンドなのにRubyKaigiに何で?

フロントエンドなのに何でRubyKaigi?と思われる方もいるかもしれませんので、簡単に私の経歴を申し上げますと、元々前職では4年ほどRailsエンジニアをしておりました。 また、社外ではTama.rbという地域Rubyコミュニティのオーガナイザーとしても活動していた時期があります。

Rubyコミュニティのおかげでエンジニアを続けて来れた実感があるので、チャンスがあればまた参加したいなぁと思っていたところ、業務として参加するチャンスを頂けたので、参加する運びとなりました! (ほんとに会社やチームのみんなに感謝です。)

参加したセッション

今回は数年ぶりに再会したRubyFriendsとお話することがメインになってしまったので、参加セッションは気持ち少なめです。

  • 1日目
    • Matz Keynote
    • Develop chrome extension with ruby.wasm
    • Lightning Talks
  • 2日目
    • How resolve Gem dependencies in your code?
    • Yet Another Ruby Parser
    • Revisiting TypeProf - IDE support as a primary feature
    • Multiverse Ruby
    • Keynote:Optimizing YJIT’s Performance, from Inception to Production
  • 3日目
    • Ruby Committers and The World
    • Ruby + ADBC - A single API between Ruby and DBs
    • Code indexing: How language servers understand our code
    • Ruby JIT Hacking Guide
    • Keynote:Parsing RBS

印象に残ったセッション

Develop chrome extension with ruby.wasm

WebAssembly上でRubyを動かせるようになったので、RubyでChrome拡張を実装した!という話でした。 個人的にRubyがフロントエンド技術にどう食い込んでくるのか気になったので見に行きました。

Rubyだけで全てコードを書くハックが聞けるのかな?と思ったものの、蓋を開けてみると、メインの言語はRubyだったのですが、JSをimportして書かなければならないようだったので、だったらJSでええやん…ってなったのを覚えていますw

上記の形式で書くとRubyの心地良い書き味が損なわれてしまうことから、Rubyのスクリプトを読み込むだけでChrome拡張機能を作成できるようなフレームワークである「unloosen」を開発することに至ったとのことでした。 unloosenを使うことで書き味は快適になっていそうなものの、実際のブラウザでは、ページアクセスの度に重めの通信が走ってしまうようなので、minifyする処理などが必要そう?でした。
実戦投入するなら、結局webpackで行なっていることを再実装することになりそうなので、なかなか険しい道かもなぁとしみじみ。

Revisiting TypeProf - IDE support as a primary feature

Ruby 3.0から標準搭載されている静的型解析器「TypeProf」のお話でした。 TypeProf v1では、解析速度がIDEなどで求められるスピードに達しておらず実戦で使うのは難しかったようです。

そこで、v1では変更があった際にコード全てに対して型推論を行っていたのに対し、 v2ではコードの変更部分のみ検査することでコード変更時の型推論のパフォーマンスが向上する見込みとのこと。 個人的にVSCodeでTypeScript同様の補完やコードジャンプが効いてはじめて実戦投入レベルかなと思うのでどんな着地点になるんだか気になります。

Ruby3.3でIDEの利用に耐えるパフォーマンスを目指して開発中らしいので気長に待ちたいですね。

フロントエンドエンジニア目線でRubyの型の話を聞いた所感

やっぱりRubyも型アノテーションや補完、コードジャンプは標準的にサポートして欲しいなと改めて思いました。 MatzのKeynoteでは、動的型付けを志向する人を「flat earth believer」、静的型付けを志向する人を「static type believer」と表現していました。

(余談ですが、飲み会に参加して、型が嫌いなRubyist数人と話した結果、型が嫌いと言っている人は、TypeScriptのジェネリクスのようなものを書きたくないっていう感じの人がいたり、「string | null」で定義しないといけないやつを「string」で定義するやつがいるから嫌だ!など様々でした。型が嫌な人の理由を聞くのが楽しかった)

私は普段フロントエンドを書いていて、型が無いと安全なコードが書けない実感があるので、Matzが言うところの「static type believer」だと思います。 Matzは型推論を頑張ることでプログラマーが型を定義しなくても済むようにしたいという例年通りの立場でしたが、エディタ上でエラーが出ないが故にRSpecをたくさん書かないといけないのもなんか違うし、型をいい感じに吐き出す機構があれば、OpenAPI嚙まさなくてもいいのになぁとしみじみ思ってしまいましたね。

おそらくRubyでコードベースを完結するモノリスのイメージなのか、自分のようにフロントエンドとバックエンドが分かれているイメージなのかで型を必要とする緊急度が違うんだろうなとも思ったり。 Ruby3.3で実装される予定のTypeProf v2でどこまで型の恩恵が受けれるのか?そして、その後でRubyコミュニティは型に対してどういったスタンスになるのか?来年のRubyKaigiが楽しみです。

おわりに

結論、参加して良かったです。 Rubyコミュニティの皆さんと再会出来たことがとても嬉しくて、次は沖縄で!なんて約束もしてしまったので、来年は会社としてもブースを出して皆さんと笑顔で再会出来ればなんて思いました。

新規参画でも安心!RSpecで仕様をサクッと把握する方法

はじめに

こんにちは!ペイトナーでRailsエンジニアをやってる坂東です。 最近はRSpecでテストをたくさん書いています!

ペイトナーではテスト仕様書を書く代わりに、RSpecのテスト自体をテスト仕様書としています。 具体的には、ステークホルダー要求からRSpecのテストを記載しています。

ただ、テスト仕様以外の情報も含まれるため、テスト仕様書としては読みづらい問題があります。 しかし最近、RSpecを--dry-runオプションを付けて実行すると、テスト仕様以外の情報が含まれずに出力されることを知りました。 余計な情報がなくテスト仕様だけ確認できるため、新規参画時のキャッチアップが効率的になるなーと思いました。

そこで今回、私がオススメしたい使い方の一例をご紹介します。 この記事を読んで、皆さんもローカル環境でRSpecを--dry-runオプションを付けて実行したくなると嬉しいです!

--dry-run オプションって何?

RSpec実行時に --dry-run オプションをつけると、テストは実行されず、テストケースの一覧を出力してくれます。

--dry-run option - Command line - RSpec Core - Relish

出力例

$ bundle exec rspec --dry-run
require 'rails_helper'

RSpec.describe User, type: :model do

  # ageが20以上の場合はtrue, 19以下の場合はfalseを返すようなインスタンスメソッド
  describe '#adult?' do
    context 'ageが20以上の場合' do
      it 'trueが返ってくること' do
        expect(User.adult?).to be_truthy
      end
    end
    
    context 'ageが19以下の場合' do
      it 'falseが返ってくること' do
        expect(User.adult?).to be_falsy
      end
    end
  end
end

出力結果は以下のようになります

#adult?
    when ageが20以上の場合
        trueが返ってくること
    when ageが19以下の場合
        falseが返ってくること

どう便利なの?

--dry-runオプションをつけて実行すると上述のように出力されることは分かりました。では、何がありがたいのでしょうか?

一言でいうと、「手軽にテスト仕様を把握できる」ことが最大のメリットだと思います。

describe, context, itが1つの文章となり、出力結果がテスト仕様書になります。テスト仕様書として出力されると、たとえば新規でPJに参画したときなど、--dry-runオプションをつけてRSpecを実行すればさくっとプロジェクト全体のテスト仕様を把握できます。

今回このオプションの使い方を教えてくださったエンジニアの方は実際そういった使い方をしているそうです。

逆にいうと、describe, context, itの説明が自然な文章になるように書きます。 そうすればdry-run 出力する場合も、普通にテストコードを読む場合も、読み手にとって理解しやすいコードになります。

まとめ

--dry-runの便利なポイントがイメージできましたか?新規参画時にはドメイン知識やテスト仕様のキャッチアップに苦労します。 --dry-runを活用すればテスト仕様のキャッチアップ効率化に繋がります。(もちろん、RSpecでテストが書かれていることが前提ですが!)

この記事を読んでくださった皆さんも、積極的にテストを書いて、スムーズなプロジェクト参画ができる環境を整えましょう!

終わりに

最後まで読んでいただきありがとうございました!!!

ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

現在ペイトナーでは、以下ポジション積極採用中です!!!

  • リードエンジニア

paytner.co.jp

参考