Paytner Tech Blog

Paytner Tech Blog

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

プロヒス2024ブース出展、奮闘レポと学び

ペイトナーファクタリング事業部でEM(エンジニアリングマネージャー)をやっている片岡です。
Paytner Tech Blogでは初めまして。これからどうぞよろしくお願いいたします。

先日、YOUTRUST様が開催するプロダクトヒストリーカンファレンス2024にスポンサーとして参加しブース出展してきました。
とても良いイベントで、スポンサーとしての意義を感じることができたうえ、ブース出展からも多くの学びを得られたため、ブログに記録しようと思いました。

当日の様子など

始まるまで

開催日は11/30の土曜日。

開催地はTODA BUILDINGでした。とてもきれいな建屋かつ芸術作品が多く展示されている、田舎者としては上を眺めざるを得ない素敵な場所でした(私は岐阜からフルリモートで働かせていただいています)。 今回のプロダクトヒストリーカンファレンス2024が大規模なカンファレンスとしては初めてだったこともあり、YOUTRUSTの方々やビルの関係者の皆さんも気合が入っている様子でした。

私自身にとっても、ペイトナーとしてもカンファレンスでのブース出展は久しぶりだったため、準備の段階からブースに人が来てくれるまで、メンバー全員が緊張していました。 そもそもカンファレンスで『ブースに多くの人が足をとめて話を聞いてくれる』といった成功体験に乏しいため、「それほど人も来てくれないだろう」という気持ちで居たのも事実だったりします。

開場後

しかし始まってみるとそんな心配は無用だったとわかりました。

開始直後はブースが会場の奥に位置していたこともあり、入口に近いブースから賑わい始めたため、ややスロースタートとなりました。しかしながら一度ブースに足を止めていただけたのをきっかけにメンバー全員がそれぞれ参加者のお相手をできるほどお話を聞いていただけ、波はあれどかなり終盤になるまで続くことになりました。

ノベルティとしてお配りしていた社長の阪井の顔入り水。

ノベルティも後半やや強引ではありながらも200本以上をお配りすることが出来ました。

ブースに来ていただいた方々からも、熱心に話を聞いていただけたのが嬉しくメンバー全員最後まで話し続けることが出来ました。

参加者も、会社のCEO・CTOなどの役員レベルからエンジニア、セールスやマーケティングの方など様々な属性の方がいらっしゃいました。そんな中、ほぼ全員の人がプロダクトについて説明を求めてくれたり、質問や深堀りをしてくれたりとプロダクト志向の人たちが集まった良いカンファレンスでした。

私だけでも50名ほどとお話することができ、弊社のプロダクトの説明がどんどんと洗練されていくのを感じました。ほかメンバーもそれに近い人数と話せたと思いますのでこの日だけで、ペイトナー株式会社と『ペイトナーファクタリング』『ペイトナー請求書』の知名度はかなり上昇したと考えても差し支えないでしょう!

特に、「ファクタリングというものはご存じですか?」という質問に対して、「知っています」と答えた方は体感で1%程度だったため、今回のイベントは認知拡大にも大きく寄与できたと感じています。

本来は順番でセッションも聞きに行く予定だったのですが、途中から「もういい!目の前の人たちに応えるぞ!」となっていったのもモメンタム感じられて楽しかったです。

カンファレンス終了から懇親会

最高に白熱し楽しいスポンサーブースでしたが、普段ではあり得ない量の初対面の方々との会話によってメンバー全員ヘロヘロになりながらブースの片付けをしていました。

懇親会では、弊社メンバー数名とともに「もう他社の方と話す気力がない……」と笑い合いながら振り返りをしたり、ビールを飲んだりして余韻を楽しんでいました。

そんなところに、「ちょっと混ざっていいですか?」と声をかけてくださったのが、YOUTRUSTのエンジニアの墨さんと少し遅れて参加した寺井さんでした。

YOUTRUSTの話や色々と雑談を重ねていた中で、今回のカンファレンスがとても良かったことをCloudbase株式会社様協賛のオリジナルビールも頂き、ハイになった私が直接何が良かったのかをずうずうしくもフィードバックさせていただくことになりました。

YOUTRUSTのエンジニアに直接伝えたFB

イベントの建付けが良かった

プロダクトヒストリーカンファレンス2024のABOUTから言葉をお借りすると、以下のようになっています。

プロダクトやサービス開発の軌跡から学びを深める、テックカンファレンスです。

このイベントの建付けがテックな属性とはいえプロダクト志向の人々を呼び込み、結果ブースでの会話量に繋がっていったと思います。「プロダクトについて説明してもらえますか?」と参加者側から言ってもらえるカンファレンスのブースはなかなかないと感じています。プロダクトそのものや、その作り方・成長のさせ方に関心がある方々がこれほど多く集まったのは、YOUTRUST様のOrganizingの賜物だと思いました。

私も今後カンファレンスに出たときはブースの人たちにプロダクトについて聞いてみたいと思います。

スタンプラリーが良かった

正直な話ですが、ブースに人々の足を止めてもらうのはとても大変です。

参加者側の経験としてもブースに足を止める強い需要はないなと感じています。そしてブース側は様々な企画やノベルティを考えるのですが、それも大変な割に効果は薄いように感じています。

今回のスタンプラリーは、主催者側がブースに足を止めてもらうための非常に有効な仕掛けだったと感じました。

まず今カンファレンスでのスタンプラリーを説明します。

参加者にはスタンプラリーカードが配られ、各ブースでスタンプを貰います。一定のポイントが貯まると、懇親会に先行入場できお寿司とビールにアーリーアクセスできるというものです。

まぁ、特別なものではないのですがこれがかなり強い効果を発揮しました。

ブースはとりあえずシールを配ります。シールを台紙から剥がしたり、参加者のカードに貼り付けたりしている時にどうしても間が発生します。その時に弊社が言っていたのは「本日はどのようなモチベーションでカンファレンスに参加されたんですか?」でした。その返答に合わせて技術的な話をしたり、キャリア相談に乗ったり、プロダクトの説明をしたりと柔軟に会話を始められる寸法です。

ノベルティだと自分が興味ないものだとスルーしてしまいがちですが、シールに関しては懇親会に参加する気のある方は強い動機で受け取りに来てくれるように感じました。

ふりかえってみて

カンファレンスへのスポンサー参加としてはかなり成功の部類だったと感じていますが、今考えるだけでも数点の改善点はあったと感じました。

アイテムの用意

参加にあたって「ビジョン、プロダクト概要、組織図、技術スタック」を記述したポスターボードを用意したのですが、好評だったため卓上ボードを取り合って説明するような状態になってしまったので複数無いことが体験としてよくないなと感じたところです。

また想像以上にプロダクトそのものへの興味を持っていただけたので、プロダクト説明のパンフレット的な説明の補助資料がなかったのは悔やまれます。

ただ、メンバーとも話した所パンフレットは配っても読まれないのではないかとブースの中で話し合っていました。 ボートと同じもの、そしてその裏面にプロダクトの1枚説明(いわゆるペライチ)を印刷したものをラミネートしたものを何枚か用意しておくのが良いのではという結論に現在はなっています(もっと良い案が今後出るかもしれない)。

展示していたポスターボード

カジュアル面談ランチ

施策としてカジュアル面談ランチを提案していましたが、想定以上に反応が芳しくありませんでした。

今回のカンファレンスの色と合っていなかっただけな可能性はありますが、見せ方や話の持って行き方などに工夫が足りなかった結果だとは思うので改善したいポイントです。

まだまだお待ちしておりますので、ぜひペイトナー株式会社 カジュアル面談ランチ登録からご登録ください!

カジュアル面談ランチ、お待ちしています

メンバー

今回のカンファレンスの特色としてプロダクト志向の人が集まったというのは前述の通りです。 それを肌で感じたのがイベント開始後だったのですが、ブースのメンバーを全員エンジニア(とEM)で固めたのはもったいなかったかなと今では思います。

弊社のエンジニアはプロダクト志向の方が多く説明などには問題はなかったとは思いますが、プロダクトマネージャーを始めとしたその他職種の方が居ても良かったですね。

多角的な説明が提供できたな、と共に社内モチベーションのためにもなったと思います。

まとめ

総じて、とても素晴らしいカンファレンスで、スポンサーとして参加して本当に良かったと感じています。

個人的にカンファレンスに参加するときは『新しい人と仲良くなる』必ず頑張ることとして設定していて、10人以上とSNSアカウント交換をするをKPIとしています。

スポンサー参加のため単純比較は難しいですが、YOUTRUSTでのつながりが45人、X(旧Twitter)の相互フォロワーが6名増えました。

それだけ多くの人と会話することが出来た活気あるカンファレンスだったということですね!

最後に

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

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

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

  • Webエンジニア
  • エンジニアリングマネージャー
  • プロダクトマネージャー

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

特に急成長プロダクトになっている今プロダクトマネージャーを急募しています。
一緒にプロダクトを作りプロダクトの熱を広げてくれる方をお待ちしています!

LAPRASアカウントが必要ですが、最も詳細なPdMの募集要項になります。
https://lapras.com/jobs/7956

私も今後はPaytner Tech Blogに出稿するようにしたいと思います。

コード書きたくなった Kaigi on Rails2024参加レポ

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

kaigionrails.org

技術カンファレンスへの参加は、RubyKaigiを除くと今回が初めてでした。RubyKaigiのセッションは自分にとってはなかなか理解の難しい次元の話をされることが多いですが、Kaigi on Railsは明日から現場で使える知見がたくさん得られ、実践的な学びの多い二日間でした。

技術カンファレンスに参加し得られるメリットは、対象テーマについての知識獲得につながるのはもちろん、その周辺領域の体系的な知識、歴史や思想まで知れることですね。また、登壇者に感化され「自分もやっていくぞ!!!(何を?)」というエネルギーをもらえるのも良いですね。普段は仕事でもコードを書く機会は減ってきていますが、めちゃめちゃコード書きたい欲高まってます。熱が冷めないうちに、印象的なセッションの感想を書きます。

Rails Way or the highway

Palkanによる基調講演。「適切にRails Wayに乗っかろう。でも、設計上辛いタイミングって結構あるよね」という会話が弊社内でもよく発生します。面接でもこうしたテーマについて質問・議論させていただくこともあり、実践的なテーマとして興味深いセッションでした。

Railsの設計パターンを学び、規約の原則を受け入れるために、フレームワークの思想を理解することはとても重要なのだなと理解しました。

「Rails Wayに乗っかりながら隙間を埋める技術」として紹介されていた『Layered Design for Ruby on Rails Applications: Discover practical design patterns for maintainable web applications』は英語書籍ですが挑戦してみたいです。テック系の書籍は未翻訳の良書が多いので、いつか英語でもスラスラ読書できるようになりたい。。そのきっかけになるか、、、!?

推し活としてのrails new

個人的な今年のNo.1セッションかもしれません。普段は業務以外でコードを書かない人がなぜ業務外でrails newをし、何を作り、その後どうなったかのお話でした。

僕も業務外ではコードを書かないタイプなのですが、技術ドリブンではなくどうしても解決したい課題が目の前にあれば確かに、同じようにコードを書くだろうなあと思いながら聴いていました。仮にそのタイミングが来た時に、コードを書こうと思えば自分で書ける職業であるエンジニアって素敵だなと思いました。この道を選んだ数年前の自分ナイス。

エンジニアとしてのスキルを業務外で発揮する場面を見つけるためにも、人生を豊かにする意味でも、まずは寝食を忘れるほど熱中できるものに出会うことが何より大事だよなと、大袈裟に言うと人生を見つめ直すきっかけになったセッションでした。

Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜

React製の機能を実際にHotwireに置き換える過程で得られた実践的な知見についての共有でした。「Hotwire or React、どちらを採用すべきか?」は、CRUDがあるかないか、リッチなインタラクションがあるかないか、あたりが観点になりそうです。CRUDに処理を寄せられる&少しの動きが必要、くらいであれば十分Hotwireで対応可能とのこと。
ちょうど直近僕らのプロダクトでもフロントエンド技術選定で「Hotwire or (Vue or React)?」といった議論が生まれ始めているので、非常に参考になるセッションでした。

Sidekiq vs Solid Queue

弊社技術顧問、我らが前島さん(@netwillnet)のセッションです。2024年現在、RailsにおけるバックグラウンドワーカーのデファクトスタンダードであるSidekiqと、Rails8.0から標準採用されるSolid Queueを、歴史的な変遷と交えながら機能や特性を分かりやすく紹介してくださいました。

「今後はSolid QueueがRails標準になるので、Sidekiqから移行すべきか?」という論点だと、現状はそこまで移行メリットは薄そうとの結論でした。Solid Queueによって機能が増えるわけではなく、現状困っていることが解決するわけではない、というのが主な理由です。

また、これから新たに入れる場合はどちらがいいかでいうと、めちゃくちゃ大量のジョブを扱う場合を除くと、Sidekiq特有の機能を使いたい明確な理由がない限りSolid Queueでよさそうです。うちのプロダクトだと、Solid Queueでよさそうだなーと思いながら聴いていました。

Data Migration on Rails

本番データ操作、どうしてますか?がテーマ。rails consoleでの操作・rakeタスクでの実行・gem利用など、各手法にはそれぞれメリデメあり現状デファクトスタンダードが存在しない領域です。

セッション内で、おすすめのgemとして Shopify/maintenance_tasksが紹介されていました。UI上でタスクの実行管理ができます。

README内の「Should I Use Maintenance Tasks?」によると、大量のデータ操作を行うようなジョブがあり、UI上でタスクの進捗を見て一時停止・再開等したいような需要がある場合はこのgemが有効であり、そうでない場合は普通にコマンドラインでタスク実行すればいいよとのことでした。

現状のペイトナーファクタリングのアプリでは、このgemの導入までは不要そうだなと思いながら聴いていました。

WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと

島田浩二さんによる基調講演です。これからのエンジニアの人に向けて、島田さん自身が大事だと学んだことを教えてくれました。

「アプリケーションに閉じずシステム全体の視点を持つべし」という話は、最近読んだシステム思考の本でも語られており、僕もエンジニアリングに限らず組織開発等全ての業務において非常に大切にしている価値観なので非常に共感できました。共感はしましたが、プロダクト開発においてはシステム全体の視点を全然持てていないことも同時に分かりました。全体視点を持つための第一歩としては低レイヤー知識を身につけるのがいいみたいです。そうなんだ。

おわりに

みなさん、Railsについて語りたい欲高まってませんか・・?Kaigi on Railsの感想戦しませんか?

ペイトナーではバックエンド技術にRailsを採用しており、Webエンジニア大募集中です。それ以外にも、以下ポジション積極採用中です!!!

  • Webエンジニア
  • エンジニアリングマネージャー
  • プロダクトマネージャー

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

open.talentio.com

RACIで可視化!「これ、誰が決めるんだっけ?」を明らかにしたい

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

プロダクト組織の拡大に伴い、「これって誰がやるんだっけ?誰が決めるんだっけ?」という疑問が生まれる場面が増えました。そこで、事業内のプロダクト開発における意思決定に関わるメンバーを集め、誰が・いつ・どのように意思決定するかをRACIというフレームワークを使って決めるワークショップを行いました。

ワークショップにより、どんな役割があるのか洗い出され責任範囲が明確化されました。非常にいい時間だったと思いますし、参加した他のメンバーからも同様のフィードバックをいただきました。

この記事が、みなさんにとっても日々の業務を見直すきっかけになれば幸いです。

背景

ペイトナーファクタリングは、事業の中期計画として単に売上だけでなく、プロダクトミッション実現のため複数軸で並行してプロダクトを成長させていく必要があります。

事業成長に伴い、プロダクト組織は過去最大規模になっており、今後さらに拡大予定です。また、人の入れ替わりで中心ポジションの専任が不在となり兼務が多い状況でもあります。その結果、各チームと事業責任者との間でどのように意思決定を行うのかが曖昧な状態になりつつありました。

そんな中、直近ジョインされたメンバーから「事業と開発とのアラインメントがちょっと弱そうですね」と言われることがありました。この一言は、僕が直近抱えているモヤモヤをズバり言い表したものでした。

それからしばらく現状の組織的な課題について考えていましたが、「事業と開発とのアラインメントが弱いこと」にほぼ全ての問題が内包されているとの確信に至りました。この抽象度の高い問題を解決しない限り組織として前進できないと思ったので、この機会に役割&責任を明確化したいと思い、関係者を招集しました。

参加者

  • 事業責任者
  • PdM(兼CSマネージャー)
  • PdM(副業)
  • EM(自分)
  • EM
  • CTO

当日のアジェンダ

  • RACIの理解タイム
  • RACIチャートの作成
  • 会議体の整理

RACIの理解タイム

RACIのフレームワークに誰も馴染みがなかったので、まずはRACIを理解するための時間を10分設けました。今回は、RACIと合わせてマネジメント3.0に出てくる「デリゲーションポーカー」を組み合わせて権限委譲レベルを可視化しました。

このあたりの整理は、アカツキさんのテックブログ『エンジニア組織の責任範囲の透明性をRACI図で高めてみた - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)』を大変参考にさせていただきました。ありがとうございます。

hackerslab.aktsk.jp

RACIチャートの作成

ワークショップのメインブロックです。

事前に叩きとなるチャートを作成しておき、それを元に役割の細分化と各役割の責任明確化を1つずつ行いました。

ペイトナーでは、『プロダクトマネジメントのすべて』の思想やエッセンスをプロダクトマネジメントに取り入れています。今回のRACIチャートも、本書に出てくるプロダクトの4階層(仮説のミルフィーユ)をベースに役割を分類しました。

肉厚な「仮説のミルフィーユ」をつくる(https://note.com/ozyozyo/n/n5362f89f283c)より引用

各メンバーに発散的に意見を出してもらい、最終的に誰をR/A/C/Iにするかを合意で決めていきます。

最終的なアウトプット

会議体の整理

RACIチャートの作成が終わったら、それぞれの役割について適切に意思決定・実行・相談・共有がされる会議体が整備されているかを確認します。既存の会議体の目的・頻度・参加メンバーを見直し、必要に応じて変更を行いました。この「RACIで役割を明確化するMTG」自体も定期的に開催すべきだよねという結論になり、Qごとに定期開催することに決めました。

よかったこと

やってみてよかったことを、チームと自分個人の観点で挙げてみます。

チームとして

まず箇条書きにすると、以下がよかったポイントです。

  1. 抽象的な互いへの期待値を初めて伝え合うことができた。
  2. 未来のあるべき姿についてもある程度認識合わせることができた
  3. オフラインで発散的な会話をワイワイできて楽しかった

1. 抽象的な互いへの期待値を初めて伝え合うことができた。

最終アウトプットとしてRACIチャートを作成しそれぞれの責任範囲が明確化されたことで、

  • 意思決定(A)を多く持つメンバーが、他メンバーにどう動いてほしいかの期待値を明らかにできた
  • 実行(R)を多く持つメンバーが、どこまで主体的に動くべきかの期待値を明らかにできた
  • RACIチャートとしてアウトプットしたことで、誰に仕事が集中しているかが可視化された
  • 現状落ちているボールを洗い出し、新たに役割明確化しボールが落ちづらい体制を作ることができた

といった良いことがあったのはある程度想定内でした。

それだけでなく、今回のワークショップを通じて、抽象的な互いへの期待値を伝えることができたのが非常に良かったです。

職能上の直接的な指揮系統(いわゆる上司-部下)の関係性であっても、上司が最終的な責任を持つとしてもデリゲーションポーカーのどのレベルで部下に委譲されているかは、相互の認識合わせをしっかりやらないとかなり曖昧です。ましてや今回のような職能や役職を超えた関係性における仕事の境界線や責任は非常に曖昧です。

なんとなく全員が「この辺りの仕事はxxさんがやるよね」というふわっとした期待値でよしなに動いている状態でした。組織規模が小さいうちはそれでも回せますが、規模が大きくなってきた今まさに必要な議論だったと思います。

ワークショップ後もどんどん新しい仕事は生まれていますが、RACIチャートを使って適切に役割分担できています。

2. 未来のあるべき姿についてもある程度認識合わせることができた

RACIチャートを作成すると、誰に業務が集中しているかがはっきりと可視化されます。具体的には、実行である「R」をたくさん持っている人は忙しくなりがちです。業務を多く抱えている人の負荷軽減や、より専門性を持った人が必要といった観点で、「ここにこんな人がいるといいよね」という話が自然と生まれます。未来の理想像と現状とのギャップが明確になり、今後の採用方針もより磨かれました。

3. オフラインで発散的な会話をワイワイできて楽しかった

弊社の出社スタイルは、基本リモートで都内のオフィスに通える人は週1〜2出社、遠方に住んでいる方は不定期で交通費会社補助で出社、という形です。出社はチーム内コミュニケーション活性化を主な目的としており、チームごとに出社日を分けています。ゆえに、複数チームのマネージャーレイヤーが一同に介して発散的に会話するような機会が意外と日常ではありませんでした。

「リモート VS 出社」には様々な論争がありますが、出社による人間関係構築のしやすさや偶発的な会話が発生することは、リモートでは得づらい非常に大きなメリットだと感じます。

個人として

  • 準備に時間をかけたおかげで、当日は生産性の高いMTGができた
  • 自分のチームへの関与方針もRACIで整理するきっかけになった

準備に時間をかけたおかげで、当日は生産性の高いMTGができた

社内で(自分も含めて)誰もRACIに馴染みがなかったこと、扱うテーマが非常に抽象的かつ発散的な議論が展開されることが予想されたので、事前の準備が非常に大事でした。また、今回のようなワークショップを企画&ファシリテートするのがほぼ初めてだったので、事前準備にはかなりの時間がかかりました。

組織開発アドバイザリーの方と壁打ちしながら、当日のアジェンダや事前準備をどこまでやるか等を詰めました。

当日、RACIチャート作成が終わって小休憩中に「正直、ここまで決まれば僕としてはもう満足です」と言ったところ、参加者の一人から「主催者が満足したなら最高じゃないですか。こういうの、ファシリテーターが一番大変ですからね」と言ってもらえて、準備を含めてやりきって本当によかったと思いました。

自分のチームへの関与方針もRACIで整理するきっかけになった

ワークショップの参加者は事業責任者・各チームのPdM・EM・CTOでした。今は自分が事業全体の開発組織を見ているので、自分と各開発チームとの関わり方についても、RACIで責任範囲を明確化し、参加するMTGも整理しました。

まとめ

RACIフレームワークを使って責任範囲の可視化ができ、仕事がしやすくなってとてもよかった!という話でした。組織スケールに伴う様々な課題が出てきているので、マネージャーとして今後も向き合っていきたいです。

さいごに

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

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

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

  • Webエンジニア
  • エンジニアリングマネージャー
  • プロダクトマネージャー

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

open.talentio.com

新チーム発足でスキルマップを作った話

はじめに

ペイトナーファクタリングのエンジニアの@fuqda です。
直近、チーム異動があり、新体制でチームをスタートするためにキックオフミーティングを行いました。

本稿は、そこで相互理解のためのワークとして、メンバー個人のスキルマップ作成を行なった結果得られたことを綴った活動記録になります。 読者のみなさまにとっても何か改善のきっかけになれば嬉しいです。

きっかけ

自身の異動に伴い、チームのリーダーとして新チームをスタートさせることになり、メンバーそれぞれのやりたいことや強み、伸び代の目線を合わせた上でタスクのアサインや相互にフォローしていく体制作りを行いたいと思ったことがきっかけでした。

やったこと

  • 「得意なこと」、「普通」、「苦手なこと」、「チャレンジしたいこと/伸ばしたいスキル」の4項目について時間を決めてメンバーそれぞれ自由記述
    • ex. Ruby on Rails, DB設計, マークアップetc...
  • 各自が出した項目を受けてチームで取り組むことを決める
    • チームの伸び代に対してTRY出来そうなことをその場で挙げてみる

キャプチャ画像のようなスキルがあらかた出し終わった後にTRYについても話し合いました。 チームメンバーの苦手に対する解決策として、以下の勉強会・チーム内イベントを開催することに!
※執筆時点で未実施ですが、隙をみて開催予定です

  • Sentryエラー調査勉強会
  • DB設計勉強会
  • AWSにアプリつくってしまおう勉強会
  • 発散でもなんでも良いMTG
  • 何でもLT会

やってよかったこと

  • 単純にメンバー間の相互理解が深まったこと✨
  • メンバー個人のスキルの棚卸しの機会になったこと✨
  • 困った時に誰に何を聞けばいいのか可視化出来たこと✨
  • メンバーの嗜好性が分かり、タスクアサインの参考になったこと✨
  • メンバーから「自分のスキルを改めて考えるきっかけになってよかった」と言ってもらえたこと👏
  • 他チームで実施してくれた方からもスキルマップ作成を通して、「いつも〇〇さんの△△に助けられてます」と普段言えなかった感謝を伝えられてよかったとの言葉をもらえたこと 🎉

自分は何気なく行なってることでも誰かにとっては苦手なことだと分かったり、お互いの助け合いポイントも明確になってチームとして一つ強くなれたと思います。 この場でお互いに期待していることをちゃんと言葉にする大切さも合わせて再確認出来た有意義な時間でした。

改善できそうなこと

プログラミング技術や開発手法だけではなく、アプリ内のドメイン知識でスキルマップを作っても面白いかなと思いました。
例えば、〇〇機能、△△機能といった項目を設けて、誰がどの機能に詳しいかが分かれば運用対応や要件定義の際に有用そうです。
ドメイン知識や業務フローの理解を題材にするのであればエンジニアに限らず汎用的にやれそうですね。

まとめ

話し合わないと個人個人が何に課題感を持っているか、何を期待して仕事に臨んでいるかは分からないですよね。
今回のワークはメンバーの相互理解やどうやって各メンバーと関わっていけばいいのか可視化出来た有意義な機会でした。

おわりに

最後まで読んでいただきありがとうございました。
ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください。
現在ペイトナーの開発組織では、以下ポジションを積極採用中です。

  • Webエンジニア
  • エンジニアリングマネージャー

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

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

RubyKaigi2024

はじめに

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

フロントエンドエンジニア目線でRubyKaigiの面白かった部分のレポートが出来ればと思いますので、最後までお付き合いください。

参加したセッション

  • 1日目
    • Writing Weird Code
    • Namespace, What and Why
    • Generating a custom SDK for your web service or Rails API
  • 2日目
    • Leveraging Falcon and Rails for Real-Time Interactivity
    • Reducing Implicit Allocations During Method Calling
    • Breaking the Ruby Performance Barrier
    • Good first issues of TypeProf
    • Squeezing Unicode Names into Ruby Regular Expressions
    • Lightning Talks
      • The Frontend Rubyist
      • The Journey of rubocop-daemon into RuboCop
      • The test code generator using static analysis and LLM
  • 3日目
    • Ruby Committers and the World
    • Make Your Own Regex Engine!
    • Matz Keynote

印象に残ったセッション

📝 Namespace, What and Why

speakerdeck.com

Rubyのプログラムを動かす際に読み込んだ外部のライブラリと手元のプログラムの名前空間の衝突を避ける機能を実装しているというお話でした。

今回の発表で触れているRubyに入れたい機能の名前は Namespace on read

「①ライブラリを読み込む」、「②ライブラリで行われた変更を隔離する」、「③定義されたメソッドを隔離された空間の外側から呼び出せるようにする」という3つのステップでライブラリコードはそのままでネームスペースの利点を生かせるようにするみたいです。

Namespaceの活用方法として特に興味深かったのは、 1つの Rubyプロセス上で、複数アプリケーションサーバーを動かせる & コンテナレスで簡単に開発環境を構築出来るようになるという話でした。

型以外の部分でも着実にRubyによる開発体験向上が感じられて、ワクワクするセッションでしたね。

📝 Good first issues of TypeProf

speakerdeck.com

定義ジャンプ、コード補完をサポートするTypeProfというRuby組み込み機能に関する現状のお話とメンテナが遠藤さん一人なのでコントリビュート待ってますというお話でした。
メンテナの遠藤さん曰く型注釈を書かずにどこまで推論でやれるかを挑戦しているとのこと。

型推論が効くことはコードを書く際に楽である一方で、型注釈を書いた方がコンパイル速度が速いケースがTypeScriptにはあるので一長一短あるなと。

コンパイルの工程がある以上は、TypeScriptと同じようなことが起こりそうな気がするので、型推論に全振りせずに使い分けれた方がシビアにパフォーマンスチューニングしたい時やりやすいんじゃないかなと思いました。

📝 Lightning Talks

speakerdeck.com

ブラウザで動くプログラムがRubyで書けるjsgというライブラリのお話でした。
JSG.d.querySelectorAll("h1") のような書き味でRubyをクライアント側で動かせるとのことでした。

現状は1つのファイルにロジックやテンプレートをベタ書きしているようでしたが、 今後どうロジックを合成関数に切り出したり、コンポーネント分割のソリューションが生まれるのでしょうか。

また、ここ最近ホットな分野であるアクセシビリティ等も含めてフロントエンドの広大な技術領域をカバーするには今しばらく時間が必要な印象でした。
来年のRubyKaigiでもこうしたフロントエンドの動向が聞けるのを楽しみに1年後を待ちたいと思います。

その他:Rubyistとの会話

セッション内容とは関係無いですが、会期中のAfterPartyで某シリアライザーgemのメンテナの方とお話するチャンスがあり、 その方から将来的にシリアライザーの定義からTypeScriptの型を生成出来るようにしたいという話を聞く事が出来ました。
それが実現するとOpenAPIスキーマを書かなくても良くなるので、ワクワクしたのを覚えています。

全体総評

今年もRubyにこれから実装されようとしている実験的な機能についていち早く知ることが出来て学びがありました。
去年に引き続きWebフロントエンドをRubyで書く!という発表は興味深かったです。

とはいえ、現時点ではコンポーネント指向のモダンなフロントエンドではなく、AngularJS以前?の時代のJSを書くような形に見えたので、 この先進化していく中でコンポーネント指向の標準的な道を辿るのか独自の進化を遂げていくのか動向が気になりますね。

型についてもTypeProfやRBSの発表内のコード例はプリミティブな型の例のみでしたが、
より実務寄りの使い方をするためのTypeScriptのユーティリティ型のようなものが今後生まれてくるのかその辺りも含めて来年のRubyKaigiが楽しみです。

RubyKaigi「何もわからん」だった俺、ガチで危機感持った方がいいと思う

ペイトナー株式会社に今年新卒で入社した田崎です! paytner.co.jp

初めてrubykaigiに参加してきました!今回はRubyKaigiでの体験をシェアしたいと思います!

全体を通した感想

実は2年前のRubyKaigi2022にはオンラインで参加していました。オンラインでの参加もとても圧倒されるような体験でしたが、今年の現地での参加は人、情報に圧倒される体験でした。

初日ははじめてということもあり緊張しながら会場入りしましたが、お祭りのような雰囲気に直ぐに緊張はワクワクへと変わりました。ここにいる人が何かしらでRubyに関わっている人であるというのを肌で感じ感動しました。

私が実際に使っているRubyを作った人、gemを開発している人、開発で困った時に助けてもらったQiitaやZenn、はてなブログを書いてくれた人などが実際に同じ会場にいると思うと改めて感謝の気持ちが湧き上がりました。

自分が感じた危機感

オープニングが終わり最初のセッションであるWriting Weird Codeが始まってすぐにこう思いました

「何もわからん」と

RubyKaigi事前勉強会に参加した弊社の社員から

  • Railsプログラマーにとって、明日から使えるTipsは一つもない

  • トークの内容自体は、ほぼ「分からない」。彼らの話を聴いて、自分もできるようになるわけではない

らしいと聞いてはいましたが、改めてショックを覚えました。セッションの内容がわからないことはもちろん、発表者の方の「Rubyistジョーク」で笑えないのが地味に応えました。。。

そこからはわからないワードをメモってググるの連続でした、、、

何もわからんの原因は何か

「何もわからん」に打ちひしがれているとき、これは自分が体系的にRubyやプログラミングについて勉強していないからだと考えました。私はペイトナーで2021年からwebエンジニアとしてインターンをさせていただいていました。そこではたくさんの実務経験を積ませていただきましたが、お恥ずかしながら自分で体系的に学ぶことがあまりなかったのです。インプット量が足りないと感じました。

しかし、沖縄から帰る飛行機の中で「体系的に学んでいないのが問題ではなく、個々の経験を体系化できていないのでは?」と気づきました。ペイトナーでのインターンから現在に至るまでの経験は確かに開発に活かされていると実感しています。しかし「技術的な面で何を学んだか?」と聞かれるとうまく言語化できない状況です。これは具体的な開発内容を反芻し、自分の中で「体系化」できていなかったのではと気づきました。日々の開発を学びに変えることが不足していたなと振り返って感じます。

よかったこと

「何もわからん」によって上記の課題を感じることができたのはまず1つ大きな収穫でした。

「何もわからん」は決してネガティブなものではなく自分の新たなステップの方向性を示してくれました。

また、今回初めてのRubyKaigi参加でしたがたくさんの方とお話しする機会がありました。各企業のブースの方、Official PartyやDrink Up(私はちゅらデータさんの会に参加させていただきました)、After Partyで皆さんが作っているサービスの話、Rubyの話、開発の話などいろいろな話をさせていただきました。社外の方とお話しする機会は滅多になかったので全てのお話が大変面白く、学びのあるものでした。

これから

とても楽しく、そして学びのあるカンファレンスだったので来年もぜひ参加したいと心から感じました。来年はより楽しく、そして学びのある機会にしたいのでこの1年しっかりと勉強と開発をやって「何もわからん」から「ちょっとわかる」「完全に理解した」と言えるような立派なRubyistになって帰ってきます!

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

ペイトナーファクタリング事業部で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