Paytner Tech Blog

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

駆け出しエンジニアインターン生が人生初テックカンファレンス"RubyKaigi"に参加した感想

はじめに

ペイトナーでエンジニアインターンをしています田崎です!

私は人生で初めて参加したテックカンファレンスであるRubyKaigi2022についての感想や自分が考えたことについてお話したいと思います! 今回はRubyKaigiのセッションの中でもTrick2022とContribute to Rubyについて取り上げたいと思います。

Trick2022

https://rubykaigi.org/2022/presentations/tric.html#sep08

Trickとは

Trickとは

  • T’ranscendental(霊的領域に関する、世俗を超越した、超絶技巧)
  • R’uby(ルビー)
  • I’mbroglio(極めて混乱した、恥ずかしい事態)
  • C’ontest(コンテスト)
  • for RubyK’aigi

から取った名前であり、Rubyで記述された複雑かつ面白いコードを発表し競い合うプログラミングコンテストです。

私がRubyに初めて触れたのはこのペイトナー社にインターンとして参加したことがきっかけで、初めからプロダクトを作ることを目標に勉強していました。ですので私は常に綺麗なコード、読みやすいコードを書くことを意識していました。 しかし、このコンテストはむしろその逆で、私はとても驚くと共に一気に興味をそそられました。

私が特に感動したものはYusuke EndohさんがMost global 「最もグローバルで賞」を受賞した地球儀が廻るような作品です。https://github.com/tric/trick2022/tree/master/03-mame

地球儀が回って見えるところや、地軸の傾き、地図としてのディティールにもとても感動し、制限のある中でこのような美しい作品を作り上げられた技術力の高さに憧れを抱きました。地球儀をRubyで実装するという点もRubyコミュニティの広さを感じることができたような気がします!

Trick感想

発表されていたコードはどれも私では解読不可能でしたが、実行結果はとてもワクワクするようなものばかりでした。 自分がプログラミングを始めた頃を思い返してみると”Hello World”が出力されることに感動し、少しずつ勉強してジャンケンができるようになったりと、楽しく、色々な可能性を秘めていると感じさせてくれる存在としてプログラミングがあったと感じています。実務や研究でコードを書いていくうちに私はそのような童心を忘れていたのかもしれません。

Contribute to Ruby

こちらはRubyの開発者であるMatz氏(https://twitter.com/yukihiro_matz/) によるセッションでした。

導入

まずはじめに語られたのはRubyという技術に対する数々の意見?についてでした

Rubyスクリプト言語として良すぎる」 「スクリプト言語オブジェクト指向はいらない」 「Rubyは遅い」 「Rubyは死んだ」etc…

これらについてMatz氏はフェアではない意見に対して不満を持っているとおっしゃっていました。 機能やツールの不足などデータに基づいた批判はありだけれど、虎の威を借る狐のようにPythonなどを引き合いに出し批判するのは建設的ではないということです。 (お話の中ではPythonの威を借るユーザーとおっしゃっていました。)

真の価値について

では真の価値とは何なのか?そのことについて”y”で終わる英単語を挙げていました。

  • Productivity

Gemやフレームワークが充実することでRubyの価値がより高まっているとのことでした。

  • Community

これはMatz氏がRubyの価値の中で一番大切であるとおっしゃっていました。 現在Rubyコアチームが中心となって開発を進めるとともに、Gemの創造や使用というところでRubyの価値を実現しているとのことでした。

  • Joy

Matz氏はRuby使用者から感謝の言葉を向けられた時に喜びを感じるそうです。 Matz氏をはじめとする開発者の方だけでなくそのご家族が使っているサービスもまたRubyで作られているということも多くあり、そういった人々の生活の中で価値を創っているということを実感するときにも喜びを感じるそうです。

  • Money

Rubyを発表した当初はアメリカで30数人程度の集まりであり、その人々は面白そうというところから来た人が多かったそうです。しかし現在はビジネス的に必要だからということでコミュニティが拡大し、それによりRubyコミュニティでお金が回るようなったとおっしゃっていました。 現在は有名な企業、サービスでRubyが使われており、経済的な規模で見てもRubyが及ぼす影響も大きいと私も感じています。

このように価値を考えていく中で世界を広くみると 上であげたような数々の批判などのノイズは無視でき、これからも価値を生み出していく中で鍵となるのはコミュニティであり、Rubyに関わる人々のコントリビューションが大切であるとMatz氏はおっしゃっていました。

Matz氏が求めるコントリビューション

  • Publicity

Rubyコミュニティに参加している人にTwitterやブログなどで情報を広めてほしい Rubyの経験やテックブログ、サービスなどの成果物等の報告など

→これらが開発者の精神安定にプラスの影響するとのことです

  • Reporting Bugs/Feature Requests

バグや提案を共有してほしい

  • Fixing/Implementing

バグ修正や機能開発を行ってほしい

  • Documentation Update

プログラマはドキュメントを書くのがあまり好きじゃないため、ドキュメントが疎かになってしまうこともある。そのためドキュメントアップデートのプルリクエストや修正依頼等を出してほしい

  • Gems

Gemを公開してほしい

→Gemを公開しオープンソースに貢献することでリクルーティングにもプラスになる

  • Triage

月1回行われる開発会議において、リクエストを捌くときにイシューが多すぎてmerge時期が前後してしまったり、重要なものの見落としが生じてしまう。ので検討事項の優先順位づけや議事録、検討事項の管理をしてほしい

  • Translation

多言語に翻訳されているが十分ではない。ユーザーの母国語ドキュメントを作りたい

  • Conferences / Meetups

カンファレンスの立ち話などで刺激を受けることがあるのでRubyKaigiをはじめとするイベントに参加してコミュニティ活性化してほしい

  • Hiring Developers

企業が使ってRubyを使っているのならRuby開発のフルコミメンバーを用意してほしい

Contribute to Ruby感想

特定の技術について使用している人や詳しい人は身近にもいますが、その技術を作った人、ましてや、Rubyという世界的に使用されている技術の開発者のお話を聞けたということはとても貴重な経験でした。開発者ならではの悩みや今後の展望などとても濃い内容のお話を聞くことができて私もモチベーションをいただきました。

最後に

3日間開催されたRubyKaigiですが、どのトピックでも共通して言えることは「Rubyという技術が好きである」ということのように思いました。好きだからこそより良くしたい、深く勉強したい、Rubyを使って面白いものを作りたいなど、皆さん情熱を持って取り組まれているのだろうと感じました。私は今まではRubyの一使用者でしたが、このカンファレンスに参加した経験をもとに、コミュニティのメンバーとして活動していけたら良いなと思います。

【RubyKaigi2022】ブースを盛り上げるだけではだめ!?本気の振り返りをやって見えた、1つの大きな反省点。

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

今回は、RubyKaigi2022のプラチナムスポンサー&ブース出展企業としての振り返りを社内で行ったので、その内容について書きたいと思います!

どんなことやってた?

ブースでクイズをやっていました!!

1日目は技術顧問・前島さん(@netwillnet)作のクイズ、2、3日目は弊社エンジニア作のクイズで、3日間毎日違うものを用意し、連日大盛況でありました!!!

強烈(!?)なCMを流しました




RubyKaigiのスクリーンに巨大やっぷんが登場したときは、完全に異空間でした

振り返りやりました

総評

今回のRubyKaigiをスポンサー企業目線で振り返ると、

会社やサービスの紹介、最大の目的であった「採用」につなげるというところへの手応えは残念ながらあまり感じられませんでしたが、このような技術イベントへの出展は初だったのと、クイズでブースを盛り上げることはできたので「ペイトナー」という会社の認知拡大はできた!!

という総評でした。

実際にKPT方式で振り返りを行ったので、それぞれについていくつかピックアップします!

よかった点

ブースを盛り上げることができた!!!

クイズが想像以上に盛り上がり、連日ブースに足を運んでくださる方で大盛況といえる盛り上がりを見せていました!参加してくださった皆様、ありがとうございました!!!

2日目からは、Twitterで回答をツイートすると正解者の中から抽選で技術書やTシャツをプレゼントするキャンペーンを実施!当選者のみなさま、おめでとうございました!!!

noteさんの記事でも取り上げていただきました!ありがとうございます!!! engineerteam.note.jp

Rubyistのみなさんとの交流ができた!!!

各社ブース担当者の方々、弊社ブースに遊びに来てくれたたくさんのRubyistの皆様と交流できたことも、大きな収穫でした! 特に、2日目の夜はふらっと遊びに行った飲み屋さんがRubyistによる熱気でスゴいことになっていました。

たまたまカメラ向けたら皆さんこちらを向いてくださり、とても良い写真が撮れました。

会社としても、筆者個人としてもオフラインの技術カンファレンスには初参加でしたが、オフラインならではの密な交流は、非常に楽しいものでした。

チームの一体感を感じることができた!!!

現地参加した6人のうち5人はブース運営未経験だったので、3日間通じてトラブル続きで(笑)、良くも悪くもその場しのぎで何とか事なきを得るという経験を繰り返し、参加メンバー同士の絆はより深まった気がします!

昼はブースでバタバタして、夜はみんなで津の美味しいご飯食べて、文化祭みたいで楽しかった!!!

こちら、MatzさんとCTOかずまさん(@kazuman519)の記念写真。社名の入った旗を掲示用の土台に使うという即席っぷり(重みに耐えきれず何度も転倒)。現場でのドタバタを物語っています。

コミュニティの熱気を感じることができた!!!

初めてRubyKaigiに参加し、「あ、Rubyを実際に作っている人たちがいるんだ」ということを知りました(当たり前っちゃ当たり前ですが、私にとっては当たり前ではなかった)。 RubyKaigi以降は、普段の開発でRubyを触る際にもコミュニティの方々に想いを馳せるなんてこともあり、これまでとは一味違った感情でRubyという技術と向き合うことができています。

改善すべき点

ブースに集客した後の導線が設計できていなかった

今回の最も大きな改善ポイントです。

RubyKaigi2022 Platinum Sponsors として協賛&ブース出展します! - Paytner Tech Blog でも書いた通り、

スポンサーとしてRubyコミュニティへの還元をしたいという想いも当然ありますが、本音として、採用目的で「Rubyコミュニティに『ペイトナー』という存在を知ってもらいたい!」という想いがあることをここに告白致します。

採用につなげたいという目的がありました。

事前に設定した目標として、「カジュアル面談の約束を取り付ける」があったのですが、一件も約束取り付けまでできず未達となりました。。

クイズを通じてブースを盛り上げることができた一方、そこから先、どうやって会社やサービス・社内の開発環境や技術スタックの紹介、ひいては採用につなげていくかという導線が全く設計できていませんでした。

次があったらこうしたい

最初から全員を巻き込んだプランニングを!!!

最大の反省点として「ブースに集客した後の導線が設計できていなかった」を挙げましたが、ここに対する改善策としては、「最初から、全員でブース設計を考える」に集約されそうです。

今回は、エンジニアチームで「ブースを盛り上げる」という目的のもとアイデア出しをしていました。 しかし、「そもそもなぜブースを盛り上げたいのか?」や、「そもそも我々はなぜRubyKaigiにスポンサー支援し、ブース出展を行うのか」という最上位の目的を忘れてしまう瞬間があったことは否定できません。

また前述の通り、盛り上げて集客したあとどうするのか?の設計はできていなかったので、ここはまさにエンジニアだけでなく、広報・PRチームのメンバーも含めた全員で議論すべきところだったと思います。

CTO面談ブース!?

これはあくまで具体的な案のひとつですが、「今すぐCTOと会話できるコーナー(仮)」みたいな、CTOをブースに常駐させておき、いつでもだれでもCTOとお話しできますよ!という場所を用意しておく。

「今度カジュアル面談しましょう!」なんていうケチな話ではなく、「今やっちゃおう!」ってことですね。

そうすれば、カジュアル面談の日程調整をする必要もないし、参加者も気軽にお話しできてよいのでは!?ということを考えていたりします。本当にやるかどうかは分かりませんが、乞うご期待!?

(おわりに)こんな会社です!!!

RubyKaigiでちゃんとお伝えすることができなかった、ペイトナーについて少しだけ紹介させてください!!!

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

これらのプロダクトを爆速でさらに成長させるために絶賛エンジニア募集中です! やりたいことに対してエンジニアがまだまだ足りない状況です・・!

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

開発組織としては、以下ポジションを積極採用中です!!!

  • Webエンジニア
  • リードエンジニア
  • EM/VPoE

potent-act-ed6.notion.site

Railsのコードレビューを受けてみて勉強になったところ

ペイトナーのエンジニアの井齊です。
プロダクトのコード品質を高め維持していくためには、コードレビューが欠かせないですよね。

ペイトナーでは、バックエンドにRailsを使って開発しています。
今回は、コードレビューでコメントをもらった指摘事項をまとめました。

①配列展開メソッドで、 indexの開始の値を指定したい時にeach.with_indexを使う

eachなどを使って配列展開する時に、indexを取得したい場面がありますよね。その時に、each_with_indexを使って対応しようとしていました。
例としては以下のようなケースです。

before

drinks = ["コーラ", "サイダー", "アップルジュース"] 
drinks.each_with_index do |drink, index|
    p "#{index + 1}番目: #{drink}"
end

出力結果はこんな感じでしょうか

1番目: コーラ
2番目: サイダー
3番目: アップルジュース

もちろん、これでもやりたいことは達成できるのですが、今回のように1番目から始めたい場合はindex + 1で指定する必要があります。
そこで、each.with_indexの出番です。

after

drinks = ["コーラ", "サイダー", "アップルジュース"] 
drinks.each.with_index(1) do |drink, index|
    p "#{index}番目:#{drink}"
end

each.with_index(数値)を使うと、indexの最初の値を指定することができます。

② if文の結果を変数に格納する

コントローラー層でmail_flagのパラメータで条件分岐する実装を例として挙げました。
一方はメール送信の関数を実行して「メール送信しました」のメッセージをリダイレクト先で表示させ、
もう片方はメール送信せずに「完了しました」のメッセージをリダイレクト先で表示させる実装です。

before

    if params[:mail_flag]
      send_mail(@user)
      redirect_to complete_path(@user), notice: 'メール送信しました'
    else
      redirect_to complete_path(@user), notice: '完了しました'
    end

beforeも動きますが、if文の結果を変数に格納するとDRYになります。

after

    notice_message = if params[:mail_flag]
      send_mail(@user)
      'メール送信しました'
    else
      '完了しました'
    end
    redirect_to complete_path(@user), notice: notice_message

リダイレクト先は同じで、返すメッセージだけ異なる形だったため、 if文で条件分岐の結果としてメッセージを変数に格納し、そのメッセージをリダイレクト先に渡すことでDRYにできました。

まとめ

今回挙げたようなコードレビューで指摘をもらって、拡張性・変更容易性・視認性など重要ポイントをきっちり見るということが勉強になりました! ここだけでなく、他の実装箇所にも応用できるように頑張っていきたいと思います!

終わりに

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

これらのプロダクトを爆速でさらに成長させるために絶賛エンジニア募集中です!
ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

potent-act-ed6.notion.site

RubyKaigi2022 Platinum Sponsors として協賛&ブース出展します!

こんにちは!
ペイトナーでエンジニアリングマネージャーをやっている 脇田(@kiwatchi1991)です。

この度ペイトナー社は、RubyKaigi 2022にプラチナスポンサーとして協賛することになりました! スポンサーとしてRubyコミュニティへの還元をしたいという想いも当然ありますが、本音として、採用目的で「Rubyコミュニティに『ペイトナー』という存在を知ってもらいたい!」という想いがあることをここに告白致します。

弊社では、2つある自社プロダクトが共にRails製アプリケーションです。まさにRubyコミュニティど真ん中であるペイトナーのことを皆様に知っていただき、今後一緒にプロダクト開発をやっていく仲間との出会いのきっかけになれるとよいな、と心から願っています!

rubykaigi.org

ブース出します!

ありがたいことにブースの抽選に当選しましたので、当日はオフラインでブース出展&WebではCMも流れます!!!(ペイトナーファクタリング公式キャラクター・やっぷん の動く姿は本邦初公開!?)

ブースでは、ノベルティ配布や、オリジナルクイズの出題をします!!!ぜひブースでお待ちしております!!!

クイズ

1. 技術顧問・前島さんからの挑戦状

ペイトナーでは、技術顧問として『パーフェクトRuby on Rails』の著者である前島真一さん(@willnet)にお世話になっています。週一のミーティングや日々のチャットでの質問、ときにはコードレビューにも入ってもらうなど、会社としての技術力向上に貢献して頂いてます。

今回のRubyKaigiブース出展にあたり、軽い気持ち(!?)で「前島さん!Railsクイズを作ってくれませんか!!!」とお願いしたところ、快諾してくださいました(本当にありがとうございます!!!)。

そんな前島さんからの挑戦状へのチャレンジャー、ブースにてお待ちしています!!!

ちなみに、事前に社内のエンジニアでクイズに挑んだところ、正解率は、、、なんと、、、、、ゼr(これ以上は弊社エンジニアの名誉のためにやめておきます)。

2. ペイトナーエンジニアによるオリジナル問題

前島さんクイズが中〜上級者向けということで、初級者向けに社内メンバーで自作したクイズも用意しています! (余談ですが、私自身もクイズ制作メンバーに入りました。クイズ作るのってめちゃめちゃ難しいんですね・・・)

皆様からの挑戦、お待ちしています!ぜひペイトナーブースまで!!!

ノベルティ

各種ノベルティ用意しています!

  • Paytner Tシャツ
  • Paytnerうちわ
  • やっぷんシール
  • やっぷんラベルの 水(500mLペットボトル)

シールはこんな感じ↓↓↓

おわりに

当日オフラインで参加される皆様、ペイトナーブースでお待ちしております!!!

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

これらのプロダクトを爆速でさらに成長させるために絶賛エンジニア募集中です! ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

本当に"簡単な操作"なのか?E2Eテスト自動化ツール『Autify』を導入してみた。

はじめに

ペイトナーのエンジニアの井齊です。

みなさんはシステムのテストをどのように行っていますか?

バックエンドであれば、PHPunit, RSpec, JUnitなど
フロントエンドであればJestなどで行われているかと思います。

弊社のペイトナーファクタリングのシステムではバックエンドはRailsRSpecを使っており、フロントエンドのテストとして自動E2E(End to End)テストツールである「Autify」を使っています。

paytner.co.jp

今回はその一環として、フロントエンドのテストとして導入した「Autify」についての感想や良かった点、課題などを伝えたいと思います。

結論

直感的でわかりやすい!!

AutifyのHPでも、

ノーコードと簡単な操作でスムーズにテスト作成

と紹介されておりますが、ぽちぽち画面の要素を押すだけという"簡単な操作"で、直感的にE2Eテストケースを作成することができます。

autify.com

さらに、下地を作れば非エンジニアでも問題なくテストの作成・実行ができそうです。今後の展望として、非エンジニアで運用していくことも視野に入れられそうです!

Autifyとは?

Autifyはオーティファイ株式会社が開発した自動E2E(End to End)テストができるローコードツールです。E2Eテストというのは、テスターやQA担当者がブラウザ操作で想定通りの挙動になっているかどうかをみるテストです。

なぜAutifyを導入したのか?

RSpecのRequest SpecやController Specでフロントエンドのテストを一部代用できたり、System Specを使えばRSpecでE2Eテストを行うこともできます。

しかし、最終的に非エンジニアによるQAの一部に使いたいので、直感的なGUIで操作でき、さらにそのQA自体の工数削減を狙える、という理由でAutifyを導入しました。

Autifyの使い方

簡単にAutifyの使い方をご紹介します!

一つのテストを「シナリオ」という単位で行います。新しいテストを「新規シナリオ」で作成します。

シークレットモードが立ち上がるので、そのブラウザで作業します!

AutifyはAutifyブラウザ上で操作したことをそのまま記録し、それをもとにE2Eテストのテストケースをつくってくれます!
画面の右下にバーがあり、その欄の赤丸が点滅していれば記録されている合図です。

Autifyでランダムなメールアドレスが生成でき、メールアドレスに送信したメールに対してもテストができます。

要素が存在していることをテストしたければ、該当の要素をクリックすることで記録することができます。(わかりやすい!)

記録し終わったら、実行の流れが表示されテスト実行することができます。

できること

テスト内容としては、

  • view(画面)に該当の要素が存在しているか
  • 正しいページに遷移しているか

などをテストできます。

他にもテストの定期実行も可能です。
テストが通ったかどうかはslack連携ができるので、結果をすぐに把握できるのはありがたいです。

テスト結果の一覧も見られます。

よかったところ

  • ぽちぽち画面の要素を押していくことで登録できるので直感的にE2Eテストができる
  • 一部JavaScriptでもかける

「ボタンを押す」みたいな処理も一部JavaScriptで対応できます。
今日の日付をクリックしたい!などの特殊な処理をしたいときに便利でした(公式でスニペットも用意されてます)

今後の課題

  • (Autifyに限ったことではないですが)E2Eテストはフロントエンドの実装に修正が入ったときに合わせて修正のメンテナンスが必要
  • ユーザーステータスによって振る舞いが変わる場合は毎回新しいユーザーにしないと厳しいのでデータが溜まっていく場合はたまにデータ初期化しないといけないケースもありそう

どのようにメンテナンスをしていくかは今後の課題です!

まとめ

テストケースが比較的簡単に作れるので、非エンジニアでも画面の検証をするハードルが下がったと思います!
必要なテストを充実させて、さらに保守性の高いシステムを開発していければと思っています。

ペイトナーは生産性の向上のため、様々なツールの検証と積極導入をしています!
他のツールについては、改めて別の記事で紹介します!

終わりに

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

開発組織としては、この2つのプロダクトを爆速でさらに成長させていくことはもちろん、
スモールビジネスの領域にはまだまだ解決したい課題と、その課題を解決するために開発したいプロダクトが非常にたくさんあり、それらも爆速で開発していきたいと考えています。

それを実現するにはまだまだ仲間が足りない状態となっております。
ですので 絶賛エンジニア募集中 です!
ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

potent-act-ed6.notion.site

初心者3人でペアプロ始めたら、想像以上にメリットだらけだった

ペイトナーでエンジニアをやっている脇田慎平(@kiwatchi1991)と申します!

僕が入社した2022年5月からチーム内でペアプロ導入を提案し、実際にこれまで何度か実施して得た経験や気づきを書きます!

結論

めちゃくちゃにイイです!!! これからも続けていきます!!!

以降、始めたきっかけや良かった点、苦労したことなどを書きます。

きっかけ

ペイトナーには、「同期作業」という文化があります(僕がとても素敵だと思う会社文化のひとつです)。 「オンラインで繋いで、仕事の会話するもよし、雑談するもよし、黙って作業するもよし」 というものです。 業務上でのもくもく会みたいなものです。

「biz側(PM) x エンジニア」の同期作業を週2回、各30分ずつやっているのですが、これがもうすごく良くてですね。。。

ペイトナー社では現在、フルコミットメンバーは週2の出社でオフィスの席数の関係で出社日を曜日で分散させています。ですので、だいたいどのメンバーともオフィスで顔を合わせるのは週1回程度です。

リモート下ではどうしても全員が出社している時と比べるとコミュニケーションコストは上がります。PMと仕様の詳細やプロダクトの在り方等までがっつり議論できる場は、エンジニアとしてもすごくありがたい時間です。

他の人が会話しているのを聞いてるだけでもかなり学びがあります。

まだまだチームとしても課題だらけ(そもそも解くべき課題は何なのか?を探るフェーズでもある)なので、密にコミュニケーションを取りながら仕事を進めるのが好きな僕にとって、個人的にも非常に大切な時間です。

、、、で、思いました。

「これ、エンジニア同志のコミュニケーション活性化のために、エンジニアだけの同期作業もやりたいな!」

「てかそれってもう、ペアプロでよくね!?」

これがきっかけです。

チームのコアメンバーである社員3人ともペアプロ初心者。どう始めたらいいのかも全く無知の状態でしたが、「ペアプロやってみたい!」という気持ちだけで、えいやーで始めてみることにしました(向いてなければすぐ辞めればいいだけの話!)。

てかペアプロってどうやるん?

「よし、ペアプロやるぞー!」とSlackで盛り上がっていると、少しずつ周りのメンバーから情報が集まってきました。

過去、毎日8時間ペアプロをする(!?)現場を経験された方がいて、その方からペアプロ始めるにあたって役に立ちそうな記事をいろいろとシェアしていただきました。

これらをざっとインプットして、とりあえずはスクラムスプリント外のリファクタ系タスク(ペアプロがうまくいかなくて進捗出なくても問題ない)から始めてみることに。

実際やってみてどう?

ってことで、ここまで数回実際にやってみて感じたことを以下まとめてみました。

良かった点

学びがえぐい

これはもう一番のメリットです。

普段はスキル感の近い3人でやっています。常にコミュニケーションをとりながら、全員の持っている知識を総動員し、1つのタスクに向き合います。

Railsのお作法・設計・命名のテクニックなどの技術的な知識、ドメイン知識、細かい仕様についてだけでなく、エディタの使い方にいたるまで、補完し合いながら進めます。

やはり3人集まると、自分は知らないけど他の人が知っていること(逆も然り)がめちゃくちゃ出てくるので、時間当たりのインプット量がえぐいです。

また、一度CTOの三浦さん(@kazuman519)をナビゲータに迎えて「ストロングスタイル(つよつよエンジニアがナビゲータとなり、知識を伝授するスタイル)」で実施したこともあります。

このときは、いつもの3人が倒すことができなかった敵に対してどうアプローチしていくのかを、三浦さんがナビゲータとなって我々にデバックの過程を見せてくれました。

具体的には、「ActiveRecordで発生したバリデーションエラーの中身が見れない」という、Railsチュートリアルですら触るような初歩レベルで行き詰まっており、自分達の未熟さを痛感。。

三浦さんのデバッグをリアルタイムで見せてもらい、結局は地道に1つずつ、確実に原因を切り分けていくしかないんだな、、、と再認識する結果となりました。

レベルが近い人同士でやっても、つよつよな方とストロングスタイルでやっても、どちらでも大きな学びを得ることができます。

1人でうんうん悩まなくてよいので、早い

1人で実装していると、行き詰まったときにどうしても長時間考え込むことがあります。

そうならないよう、Google15分ルールを引用しながら、「適切に助けを乞うようにしましょう」という共通認識を持つようにはしています。

しかし、ああでもないこうでもないと試しているうちに、気づくと数時間経っていた、、、なんてことは、エンジニアだと誰しも経験したことがあるのではないでしょうか。

ペアプロではみんなで考えるので、行き詰まってから次の打ち手を見つけるまでの時間が圧倒的に短いです。 仮に全員の知識を以ってしても倒せない敵の場合であっても、「これは自分達には無理だからヘルプを呼ぼう」とスムーズに次のアクションにつなげられます。

一人でやっていると、意外と難しい部分じゃないかと思います。

コミュニケーション量が増える

ペアプロの心得にもあるように、ペアプロ中は「15秒の沈黙ですら長い」と感じてしまいます。そのため、ずっと会話しています(本当に、ずっと会話してる)。

そうしてたくさんコミュニケーションを取ることで、日々の仕事におけるお互いへの質問のハードルもかなり下がったように思います。

いわゆる「心理的安全性の高い」チームビルディングにおいても、ペアプロは非常に有効だと感じます。

単純に、楽しい!

みんなで「あーでもない、こーでもない」とわいわい会話しながらやる開発は、シンプルに楽しいです!!!楽しみながら仕事をすることは、取り組みを長く続ける上でも、生産性の上でも、非常に大事です!楽しい!

苦労した点

疲れる

ずっとコミュニケーションとっているので、すごく疲れます。疲れるので、定期的に休憩をとりましょう!(ペアプロの心得にも、一番最初に書いてあります。それだけ重要なことです!)

でも、たくさん学びがあって楽しい!!!

自分の意見を言語化する難しさ

実装方針等で議論しているとき、「ここはこうした方がいいんじゃないか?」と自分の意見を言う場面が何度もやってきます。これが結構難しい・・!

うまく言語化できない部分は理解が不十分なところなので、それが炙り出されてまた成長しちゃいますね!伸びしろ!!!

キリが悪い状態で終わる難しさ

ある日のペアプロで、予定していた時間がきてしまったけど、会議室空いてるし、キリが悪いからもうちょっとだけ延長しよか・・・!と延長したことがありました。

しかし、あと少しで終わると思ったところで新たな沼にハマり、1時間延長してさらにカオス化して終わる結果となりました。

すぐ解決するとは限りません。時間になったら中途半端でも終わらせる強い心が必要。

具体的には、終わる時間の10分前になったら、今日やったこと、今詰まっているポイント、次回最初に確認することを簡単にまとめることをルールとしました。

開発効率が落ちる!?

ペアプロやると複数人で同じコードを触っているから開発効率が落ちる」という言説があります。これは、リソース効率・フロー効率の観点でいうとリソース効率重視の考え方だと思います。

www.slideshare.net

私たちのチームでは、スクラム開発を行っています。スクラム(およびアジャイル)開発は、まさにフロー効率を高める活動そのものです!

今はペアプロに慣れていないことで短期的に開発効率が落ちることがあっても、仕様・ドメイン理解の向上、メンバースキル向上, チームビルディングの側面を考えると、すぐにペイできるコストだと考えています!

まとめ

ここまで述べてきたように、苦労ポイントもありますが、生産性向上が期待でき、学びの多い楽しい取り組みとなっています!

これからはもっと頻度を増やし、スプリントのタスクに複数人をアサインし、ペアプロベースで開発を進めるということもできたらいいなと考えています!!!

おわりに

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

これらのプロダクトを爆速でさらに成長させるために絶賛エンジニア募集中です! ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

potent-act-ed6.notion.site

ペイトナーTech Blog始めます

はじめまして!! ペイトナーでCTOをしている三浦( @kazuman519)です。

この度、エンジニアによるブログを始めることにしました!

なぜはじめたのか

ブログをはじめた目的は2つあります。

1つは定番な目的である 「採用力の強化」
もう1つは 「組織としての開発力の向上」 で、こちらが1番の目的です!

ペイトナーは創業してから今年で4年目の会社となり、非常に頼りになるハイスキルなエンジニアや、やる気が満ち溢れている開発意欲の高いエンジニアが集まっています。

しかし、エンジニアが組織的に開発ができるようになってきたのはここ半年間の出来事で、それまではメンバーの個の力でプロダクト開発を支えていた印象が強い状態でした。

それ故に 「組織としての開発力」 は伸ばす余地がまだまだある状態です。

なので今回メンバーと話し合い、今後さらに開発力を向上してくための投資はしっかりしていこうということで、リソースの投資先の1つとしてブログを選びました。

ブログで情報をアウトプットすることで、

  • 組織としての知見や技術の貯蓄
  • 知識や技術、考え方などの共通認識化
  • アウトプットすることで自身のそのトピックに対する理解度 & アウトプット能力の向上

といったことを促し、組織としての開発力の向上に繋げられると考えています。

また、そのアウトプットによってペイトナーのエンジニア組織の雰囲気や文化、取り組んでいることなどを外部の人に知っていただき、
結果的に採用力の強化にも繋げられると考えています。

なのでまずは「組織としての開発力の向上」に重きを置き、
カジュアルに開発に関する情報を発信していければと思っておりますので、
今後ともよろしくお願いいたします!

おわりに

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

開発組織としては、この2つのプロダクトを爆速でさらに成長させていくことはもちろん、
スモールビジネスの領域にはまだまだ解決したい課題と、その課題を解決するために開発したいプロダクトが非常にたくさんあり、それらも爆速で開発していきたいと考えています。

それを実現するにはまだまだ仲間が足りない状態となっております。
ですので 絶賛エンジニア募集中 です!
ペイトナーに少しでも興味を持っていただけましたら是非、ペイトナー 採用情報 をご覧ください!!

www.notion.so