本記事は BASEアドベントカレンダー2024 の11日目の記事です。 はじめに はじめましての人ははじめまして、こんにちは！BASE BANK Division（以下、BANKチーム）のフロントエンドエンジニアのがっちゃん（  @gatchan0807  ）です。 今回は私が担当しているPAY.JP YELL BANKというサービスについてお話しします！ エンジニアとしてこのプロダクトを担当していて感じるおもしろいところがたくさんあるので、ぜひ一緒に開発しましょ！！というお誘い記事でもあります！！ 全部読んでいただけるととっても嬉しいですが、熱がこもりすぎてとても長い記事になってしまいましたので、記事下部にある、まとめだけを読んでいただく形でもよいです！ よろしくお願いします！ この記事を読む上でのキーワード: エンベデッドファイナンス PoCフェーズ〜グロースフェーズ 分析 / フルサイクルエンジニア 機械学習 FinTech PAY.JP YELL BANKについて まずはPAY.JP YELL BANKについて軽くご紹介させてください。 サービスサイト: https://pay.jp/yellbank 2024年6月に正式公開された際のプレスリリース: https://prtimes.jp/main/html/rd/p/000000224.000030814.html PAY.JP YELL BANK自体は「将来債権ファクタリング」という仕組みの金融サービスになります。もともとネットショップ作成サービスBASE（以下、BASE）向けに同様のサービスとして提供していた「YELL BANK」が元になっており、オンライン決済サービスPAY.JPを利用しているユーザー（以下、PAY.JP加盟店）に将来の売り上げを「ファクタリング」というスキームですぐに使えるお金に代えるサービスになります。 [補足]YELL BANKのサービスサイト: https://yellbank-lp.thebase.com/ 上記YELL BANKのサービスサイトから引用 BANKチーム、PAY.JP YELL BANKの今後について BANKチームは元々、BASEのショップオーナーの金融課題を解決する機能を提供するチームとして立ち上がり、BASE向けYELL BANKを軸に、BASE Card、お急ぎ振り込み機能と、ショップオーナーの金融課題を解決するための機能を拡充する形で展開してきました。 これは今後も変わらずに進めていく予定で、実際に2024年も請求書カード払いの提供開始など引き続きBASEのショップオーナーの金融課題を解決するために新領域にも展開をしていきます。 BASE BANKチームの紹介資料から引用 （引用元: BASE株式会社 BASE BANKチーム紹介資料 - Speaker Deck ） そして、中長期目線では、YELL BANK機能の展開を皮切りにBANKチームで開発・運用している各機能の提供プラットフォームを拡大して、より広いユーザーに価値を提供できるようにしようとしています。 元々、BANKチームが開発・運用しているYELL BANKをはじめとした各機能は、 エンベデッドファイナンス（組み込み型金融）と呼ばれるサービス形態 のものです。 これは「金融以外のサービス提供企業（非金融企業）が、既存サービスに金融サービスを組み込んで金融サービスを提供する」という形のサービス提供方法に名前がついたもので、「ネットショップ作成サービスBASE（非金融サービス）と将来債権ファクタリングのYELL BANK」のような関係のことを言います。 詳しくは こちらの解説ページ や、「 エンベデッド・ファイナンスの衝撃―すべての企業は金融サービス企業になる 」という書籍に譲ります。 これらの金融関連の各機能をBASE以外のプラットフォームに提供を始めることで、BANKチームが関わるプロダクト自体はよりエンベデッドファイナンスっぽい形になりはじめてきています。 その第1弾として、BASEグループのPAY株式会社が提供している「オンライン決済サービスPAY.JP」向けに提供を始めた「PAY.JP YELL BANK」はBANKチームで2018年から開発・運用してきた「YELL BANK」のBASE以外のプラットフォームへの展開というところで、上述の付加価値拡大の方針の試金石にもなるプロダクトになっています。 PAY.JP YELL BANKの技術構成について PoC期間から現在までは、以下ような形の技術構成になっています。 バックエンドはGoで書かれたPAY.JP加盟店ごとの債権管理などのシステム全体の処理の責務を担うAPIと、Pythonで書かれた機械学習を使ったPAY.JP加盟店ごとの売上予測を提供する責務を担うAPIの2つをAWS ECS Fargate上に置き、フロントエンドはNext.jsをAWS Amplifyで動かしてページをiframeでPAY.JPの画面に埋め込むようにしています。 これは、YELL BANKのシステムアーキテクチャを参考に実装しており、再利用できる部分を再利用してアジリティ高くPAY.JP YELL BANKの機能提供を開始できるように実装してきました。 また、フロントエンドはPoC段階の機能の提供速度を早めるためにBANKチーム管轄でNext.jsアプリケーションを作成し、それをPAY.JPの管理画面に埋め込んでもらう形をとりました。 技術構成のこれから その後、PoC期間が終わり、6月に正式提供が開始されてから約5ヶ月が経った今は、スピード重視で作ってきた技術構成を中長期的に運用がしやすく、さらにグロースするために必要な機能を追加しやすいように一部変えようとしているところです。 フロントエンドはiframeで画面丸ごと埋め込む形をやめ、PAY.JPの管理画面に直接機能を実装して、Next.jsのフロントエンド・BFFからではなくPAY.JPのバックエンドからGoのAPIを利用する形に変えていこうとし始めています。 これは、PAY.JP加盟店ユーザーの動線上に適切に表示し、よりシームレスな資金調達体験を作ることと、その先の調達した資金を使った加盟店成長に繋げてもらうためのアップデートです。 ただ、PAY.JPはクレジットカード番号を直接取り扱うプロダクトであるため、開発するメンバーは PCI DSS 準拠のリリースフロー・開発ルールに則って実装を進める必要がありました。 そのためのBANKチームメンバーのPCI DSSを理解度を上げるトレーニングや事前準備を進めたりしてきたので、満を持してPAY.JPへの直接実装をしていくぞ！というタイミングが今だったりします。 他にも、グロースさせていくフェーズに入ったため、新たに必要になった機能を開発する上での各バックエンドAPI改修、分析基盤との連動のためのバッチの追加などを今後も進めていく予定です。 PAY.JP YELL BANKの開発のおもしろいところ さて、そんなPAY.JP YELL BANKを開発する上での特徴であり、個人的に担当していてとてもおもしろいと感じていることを皆さまにも少し知ってもらえればと思います。 大きく分けて、3つあります BASE / YELL BANKのリソースを活用した開発スピードの速さ・手数の多さ エンベデッドファイナンスという少し特殊なプロダクトであること 金融のドメイン知識と機械学習・銀行APIなどのテクノロジーを組み合わせて課題解決していること BASE / YELL BANKのリソースを活用した開発スピードの速さ・手数の多さ 「リソースを活用」と書くと、いささかタダ乗りしているようなニュアンスを含んでしまいますが、どちらかというと 伴走してくれるチームやプロダクトがとても近いところにいて、一緒に開発できている状態で、それがとても価値がある ものだと思っています。 より具体的には、先人の知見をベースに再設計したり検討した上でPAY.JP YELL BANKに取り込んだり、新しい機能を作る際には調査を共に進めて分担したり、そういった知の高速道路に乗りながらBANKチーム・BASEグループ全体で向かうべき未来を目指して開発をしている点です。 また、後述のエンベデッドファイナンスというプロダクトである特徴の話にも重なりますが、BASE・PAY.JPという既存プラットフォームがあり、そこに異なる角度からの新しい機能を追加するという経験はプロダクトを完全にゼロから模索するよりも、ある程度ターゲットが絞れている分、高速に開発を始めることができます。 さらに、既存プラットフォームで得た資金を投資することで、よりダイナミックに機能を作ることが出来るところも魅力です。 他にも、 普段の開発を組織規模やフェーズが先に進んでいるプロダクトと深く関わり、同じ会社内で同じ方向を向いて働くのはとても楽しい です。 BANKチームの紹介資料にも記載がありますが、フルサイクルエンジニアを目指すエンジニアチーム風土であるため、エンジニアはアプリケーションはもちろん、インフラや分析基盤、企画にも携わっていくことが多々あります。 GoやPythonの話をBANKチームのメンバーに聞いたり、AWSの知識が深いBASE内の別のチームに聞いたり、フロントエンドの話を聞かれて答えたりと、それぞれ持っている役割や得意な領域を互いに組み合わせてプロダクト作りを進められているのはエンジニア組織としておもしろいところだなと常日頃から感じています。 エンベデッドファイナンスという少し特殊なプロダクトであること エンベデッドファイナンスの特徴として、BtoBtoC（BASE BANK to BASE to BASEユーザー）という流れでサービスを提供する形になるので、 BASE BANK目線だと提供先によってユーザーのタイプがかなり変わるという特徴 があります。 PAY.JP YELL BANKの初期提供時は、BASE向けに提供しているYELL BANKの知識をベースに作り始めていたのですが、年始あたりからはPAY.JPの加盟店の特性をLookerなどを使って分析し、より適したサービス提供方法を模索しています。 エンジニア目線では、エンべデットファイナンスというサービス形態は「（外部展開も見据えて、）社外の人が使うAPIとしてどう設計するべきか？技術構成はどうするべきか？」を一緒に考える必要があります。 これは他のサービス形態だとなかなか深く考えることがないポイントで、自分の技術力や設計力を伸ばす上で必要な観点であるし、それを磨くことでサービスとしての価値が高まることに繋がるのでとてもやりがいがある開発になります。 PAY.JP YELL BANKにおいては、これまではNext.js製のアプリケーションがBANKチームが提供するAPIのクッションと画面実装を担っていましたが、今後はPAY.JPのバックエンド向けAPIを直接提供する形に差し替えていくので、よりAPIスキーマを重視する方向で動き始めています。 金融のドメインに機械学習・銀行APIなどのテクノロジーを組み合わせて課題解決していること PAY.JP YELL BANKでは「PAY.JP加盟店の将来の売上予測」がサービスのコアにあり、その機能を実現するために機械学習を使っています。 このPAY.JP YELL BANKにおける売上予測の開発には ① PAY.JP加盟店の売上をより精緻に予測し、適切な額を資金提供して回収まで滞りなく実現することで、 BASE BANKとしての事業継続性を高めるための「守りの売上予測精度向上」 ② リスクコントロールが可能な範囲で資金提供可能な金額を上げるためにどのようなデータを追加で提供してもらって機械学習モデルに取り込むべきか考えて、 より多くのPAY.JP加盟店に使ってもらえるようにするための「攻めの売上予測精度向上」 の2種類があり、今後もこの辺りは改善を進めていこうと考えていたりもします。 その他にも、お金に関わるプロダクトであるため、高い責任感が求められる面とそれをテクノロジーを使って解決できることがPAY.JP YELL BANK開発、ひいてはBANKチームで開発を行うことのおもしろさであると思っています。 一例としては、銀行APIなどを使った振込入金におけるユーザー体験の改善などが挙げられます。 また、実際に資金提供を行うことが加盟店の運営・成長につながる一手になりうることもBANKチームで積極的に行なっているユーザーインタビューから様々なユーザーの声を聞いて知ることができ、自分たちのやりがいにつながってもいます。 まとめ ここまで長々と自分が担当しているPAY.JP YELL BANKというプロダクトのおもしろいところ、所属しているチームのいいところをたくさん語らせていただきましたが、ザッとまとめると以下の通りです！ 【プロダクト内容・フェーズ的なおもしろいところ】 これからグロースしていくフェーズなので、新機能や技術構成のアップデートなどダイナミックさがあるところ エンベデッドファイナンスは直接金融サービスを提供するよりはBtoBtoCという形で複雑だが、既存のユーザーの課題により適した形でサービス価値を提供することができるところ 【組織的なおもしろいところ】 BASE / PAY.JPと伴走してプロダクトのグロースや開発を進めていくところ フルサイクルエンジニアを目指す風土なので企画、開発、運用や分析も含めて全てのステップに深く関わるところ 【技術的なおもしろいところ】 プロダクトのコア体験につながる売上予測に機械学習を使っているので、データの集め方やデータ連携の契約の組み方を考える余地がまだまだあるところ 金融（特に資金調達と決済）のドメイン知識を深めることができること 外部向けAPIとしての設計、そのためのワークフロー構築ができる・必要なこと 私自身は、この環境で開発を行なっていくことで自分の技術力やエンジニアとしての成長に繋げられるなと感じているので、今後もPAY.JP YELL BANKの開発に深く携わって、どんどんとサービスの価値を高めていけるように開発をしていく予定です！🙋 おわりに ここまでPAY.JP YELL BANK、BANKチームについての紹介をお読みいただきありがとうございました！ BASE BANKチーム（求人媒体での記載はYELL BANK）ではエンジニアを大募集中ですので、少しでも気になるな👀 と思っていただけたのであれば、ぜひぜひカジュアル面談やX（ @gatchan0807 ）などでお声がけいただけると嬉しいです！ binc.jp 明日は kitamuran さんと pigooosuke さんの記事2本立てです！お楽しみに〜！

この記事は BASE アドベントカレンダー10日目の記事です。 はじめに はじめまして！ BASEのカートチームでバックエンドエンジニアをしている @ykagano です！ カートチームは主にBASEのショッピングカート機能の開発を担当しているチームです。 そんなカートチームでのドキュメント管理術をご紹介したいと思います！ ドキュメント管理の課題 BASEではNotionを社内Wikiとして使用しています！ 社内資料は、Notionのページやデータベースで一元管理しています！ カートチームでもドキュメントはNotionの一つの階層構造で管理していますが、使用している中で以下の課題がありました。 大抵のページは最初に書かれた後、 ページが更新されない ページ作成者以外は更新しづらい心理的な壁がありそう 毎回新しくページを作っているため、 新しい情報と古い情報が混在している 古いページに前提となる情報が書いてあることも 課題を解決するために Notion AIを使用しています！ AIに尋ねれば各ページの情報を元に情報が出てくるのですごく便利です！ でも正しい情報が一発で出てくるとは限りません。 鮮度が古い情報を拾ってくることもあります。 毎回同じことをAIに尋ねていることも……。 そこで、よく使う情報はチームの共有ページにまとめておくことをお勧めします。 これにより、以下の利点があります。 必要な情報にすぐにアクセスできます チームメンバー全員が同じ情報を共有できます チーム全体の開発効率が向上します さらに、まとめたページは、Notion AIと組み合わせることで、 より効率的に情報が検索できる ようになります。 カートチームのドキュメント管理 ではNotionを使った具体的な管理方法を見ていきます！ カートチームでは一つのNotionデータベースにナレッジを集約しています！ ただ更新されないままになっているページも多いです。 時間が経つとページも増えてくるので、全てのページを最新化するのも困難な状況です。 そのため、カートチームでは、ポータルページで 保守するドキュメントと保守しないドキュメントを分ける ことにしました。 カートチームのポータルページ 下図はカートチームのポータルページのトップです！ 最初に保守対象のページを表示してすぐアクセスできるようにまとめています。 保守対象のページは チームメンバー全員で更新していくページ となります。 先ほどのデータベースの中から以下のラベルの付いたページを保守対象としてビューに表示しています。 チーム運営 保守（運用） 保守（技術） 保守（メンテナンス） 次に保守対象外のページです。 左側はデータベースの一覧に新規追加された資料を表示しています。 右側は保守対象外のラベルで資料にアクセスできるようにしています。 最初は工事中のページも資料が育てば、ラベルを付けて保守対象にしています。 資料はチーム全員で育てるもの です！ その時気になったことが一行だけ書かれたページでも、後から気付きを得て、書いた方がいいと思ったことはどんどん追記しています！ カートチームはBASEの決済動線を守るチーム これまでは主に業務視点のドキュメント管理術でした。 カートチームはBASEの決済動線を守るチームです！ そのメインの仕様書はどうやって管理しているのかをお話ししたいと思います！ 仕様書を常にメンテナンスすることは非常に困難です。 案件ごとにNotionやFigJamを使って資料は作っていますが、保守対象としている仕様書は一つに絞っています。 それはシーケンス図です。 決済手段ごとに外部連携先（主に決済会社）も異なれば、非同期処理になっている箇所もあります。 監視ではどこが障害ポイントになるのか確認し、改修時はどこを変更することになるのか検討が必要になります。 そうした時に素早く共通認識が持てるように、 処理全体が俯瞰できるシーケンス図を更新 しています。 シーケンス図をGitHubで管理する シーケンスを以下のようにGItHubで管理しています（表示部分は一部です）。 GitHubはMermaid形式のプレビューに対応していますので、Mermaid形式で書いたmdファイルを格納しています。 カートチームの決済動線のシーケンスは主に以下の階層構造になっています（あくまでイメージのため、一般的な概念図まで簡略化しています）。 import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); sequenceDiagram participant User as ユーザー participant Front as フロントエンド participant Back as バックエンド participant Payment as 決済会社 User->>Front: 商品選択・購入ボタン押下 Front->>Back: 購入リクエスト送信 Back->>Back: 在庫確認 Back->>Payment: 決済実行 Payment->>Back: 決済結果通知 Back->>Back: 注文情報保存 Back-->>Front: 決済完了通知 Front-->>User: 完了画面表示 シーケンス図はバックエンドのGitHubリポジトリに格納しています。 決済動線の処理が変更になるときは必ずバックエンドが更新されるためです。 決済の処理フローに変更が発生した場合、 コード修正と合わせて、シーケンス図も修正 するようにしています。 おわりに 実はカートチームに上記のドキュメント管理ルールを作ったのは最近の話になります。 今後、カートチームに文化として根付いていければと思います！ BASEは決済に興味があるエンジニアを積極採用中です！ ご興味がありましたら採用情報をぜひご覧ください！ binc.jp 明日は、gatchan0807さんの記事です。お楽しみに！

本記事は BASEアドベントカレンダー2024 の9日目の記事です。 はじめに 初めまして、BASEでフロントエンドとバックエンドの開発を担当している kondo と申します。この記事では、私自身が開発エンジニアとしてプロジェクトを成功させるために心掛けていることを紹介します。日々プロジェクトを進める上でどのような取り組みを行なっているのか、参考になる事例紹介となれば幸いです。前提として、私はBASEではスクラム開発・ほぼフルリモートで働いております。 プロジェクトを成功させるための工夫 スクラム開発でベロシティを計測して、ストーリーポイントから逆算してリリース日がいつか可視化する スクラム開発でチームがスプリントでいくらベロシティを消費できるのか計測して、残りのストーリーポイントが何スプリントで終わるのか計測する取り組みをしています。リリース時期を予測しておくことで、自分たちはもちろん、マネージャーやビジネスサイドとも会話しやすくなります。またベロシティが向上し、チームが成長できているかなどの指標も計測することができます。 振り返りで良かったこと、改善したいこと、そのアクションを決める 振り返りの場では、チーム全員でスプリント中に良かったこと、改善すべき点を共有し、それを基に具体的なアクションを決めます。例えば、良かったこととしてペアプロの実施が挙げられた場合はペアプロを継続して、改善すべき点で細かい仕様が不透明であると挙げられたら、仕様書をより詳細に記載していきます。このプロセスを繰り返すことで、改善点は徐々に改善されて、良かったことが継続されていきます。 チームメンバー全員がフロントエンド・バックエンド・インフラの対応をできるようにする チームメンバー全員ができる領域を増やしていくことで、タスクが個人に依存しない強いチームになっていくと考えています。自分たちのチームではバックエンドエンジニアがReact、Typescriptに取り組んだり、フロントエンドも書くしSQLも書くエンジニアがいるなど、各々が領域拡大に取り組んでいます。ペアプロなどを通じてサポートすることで、無理なくできることを増やすことができています。 コードレビューより自分のタスクを優先しない コードレビューは、機能をリリースするためには必須事項です。チームが機能を素早くリリースすることは、顧客への価値提供を早めると考えています。そのため、自分が終わらせたいタスクがあり、コードレビューを先延ばしにしてしまうと、その分チームが機能をリリースできる時間が伸びてしまいます。したがって、コードレビューは優先して見るようにしています。 前提の考えや知識、立ち位置のギャップを埋めるため、同期的コミュニケーションを活用する 私のチームでは、フルリモート環境でSlackやGitHubを使い、非同期で開発を進めています。しかし、非同期のやり取りでは、前提知識や経験則、問題に対する温度感が伝わりにくく、議論が平行線になることもあります。この課題を解消するために、同期的なコミュニケーションを取り入れています。例えば、Aさんは効率性を重視し、Bさんは分かりやすさを優先している場合、意見がすれ違うことがあります。このような時、オンラインミーティングでお互いの思考プロセスや背景を共有することで、認識のギャップが埋まり、新たな解決策を見つけることができます。このプロセスを通じて、相互理解が深まるだけでなく、議論を通じてメンバー同士の新しい視点の獲得にもつながっています。 不確実性の高いタスクから取り組んで、PJの不確定要素を減らしていく プロジェクトの序盤で、不確実性の高い仕様や技術課題から優先的に取り組むことで、リスクを早期に発見し、解消するようにしています。特に外部APIとの連携や、今まで活用したことのない技術などは、実際にそれが必要になるより前に調査して、不確実性を取り除くようにしています。後半になるほど不測の事態の対応は大きくなってしまうので、早めの対応が肝心と考えています。 ストーリー・タスクの優先度を明確化する 全てのタスクに明確な優先度を設定することで、チームが今どのタスクを最優先で取り組むべきか明確にしています。こうすることで重要なタスクの抜け漏れを防いだり、優先度の高いタスクからリリースをすることができます。 仕様書を明確に記載する 仕様書を詳細に記載することで、プロジェクト全体の透明性を高め、チームメンバーや将来の関係者が迷うことなく作業を進められるようにします。また、テストケースが仕様書から明確に導き出せるようになるため、テストの効率化やバグの早期発見にもつながります。これを怠ってしまうと、Slackのどこかで会話した記憶があるとか、どこかのミーティングでこうなった気がする、といった情報が流れてしまう事象が発生してしまいます。仕様書を書く手間より情報を掘り起こしていく手間の方が高い場合も多いため、なるべく書くようにしています。 おわりに 本記事では、プロジェクトを成功させるために工夫していることを紹介いたしました。プロジェクト運営の参考になれば幸いです。明日はykaganoさんの記事が公開予定です、お楽しみに！ binc.jp

本記事は BASEアドベントカレンダー2024 の8日目の記事です。 はじめに BASE Feature Dev1 Group アプリケーションエンジニアの @yuna_miyaa です。 実は、私がBASEに転職してもうすぐ3年ですが、前職はなんとパティシエでした！ (受託会社を経て現在入社しております) 少し変わった経歴なのでなんでエンジニアに？はもう100回以上は聞かれています。 現在も副業でパティシエを続けられているので、いつか「パティシエとエンジニアの共通点」というテーマで記事を書いてみたいと思っています。 さて、今回はエンジニアとしての話題。 私は現在、 スクエア連携App 開発のリーダーを務めています。 この半年間でチームは2度も大きな変化を経験しました。その中で、私がリーダーとして心がけていることや、チーム開発を円滑に進めるための工夫についてお話ししたいと思います。 チーム開発を進めるために意識していること 大きな目標をみんなで共有する エンジニアリングはタスクの連続。 しかし、それだけに追われると視野が狭くなりがちです。「なぜこの仕事をするのか」「それがどんな価値を生むのか」という全体像を共有することが、モチベーションアップとチームの一体感に直結すると考えています。 たとえば、プロジェクト初期の段階では、タスクの完了条件や進め方を細かく記載して、時間をかけて認識合わせを行いました。 当時は「ここまでやる必要ある？」と思うほど大変でしたが、結果としてメンバーがタスクを進める中で全体像をつかむようになり、プロジェクトへの理解が深まっていきました。 困っていることを素直に共有する 「リーダーだから全部解決しなきゃ！」と思っていたら、いくら時間があっても足りません。 むしろ、「実はここがわからなくて…」と自分の弱みをオープンにすることで、自分の弱みや困っていることをオープンにすることで、「助け合えるチーム」という安心感が生まれるんです。 実際に、締切直前にトラブルが起きたとき、早めに「これが解決できない…助けてほしい」と声を上げたことで、メンバーが積極的に協力してくれて無事に乗り越えることができました。 一人で抱え込むのではなく、チームを信じることの大切さを痛感した瞬間でしたね。 メンバーの困りごとをいち早く察知する リーダーの役割の一つは、メンバーが成果を出せる環境を整えること。だからこそ、メンバーが困っていないかを素早く察知するように心がけています。 特に新人メンバーが入ったときは注意深く観察します。 初めての環境に慣れるまで時間がかかりますよね。 たとえば、雑談中に「最近どう？困ったことない？」と何気なく聞いてみたり、ミーティング後に個別で声をかけたり、チームの信頼関係を作る大きな一歩になると信じています。 ユーモアを忘れない 仕事に真剣さは必要。でも、真剣さばかりだと空気が重くなることもありますよね。そんなとき、ユーモアが場を和ませてくれます。 たとえば、毎週1回の雑談デイリーと称してデイリーの後に、雑談タイムを設けています。「最近ハマってるランチの話」や「ちょっとした趣味の話」など、話題は何でもOK。 仕事は真剣に取り組むべきですが、楽しい雰囲気も大事です！チームの空気を和らげるために、時々ユーモアを交えた雑談を心がけています。 笑顔が増えると、不思議とアイデアも出やすくなりますし、チーム全体の雰囲気が明るくなります。 おわりに チームは生き物のように常に変化しています。変化の中で何を大事にするか、どんなアプローチで進めるかを考えることはとてもやりがいがあります。 今回の記事が少しでも誰かの参考になれば嬉しいです。そしていつか、エンジニア×パティシエという異色のキャリアについてもお話しできる機会があればと思っています！ 明日はPayIDチームのkitagawaさんです！お楽しみに！ 採用情報 | BASE, Inc. - BASE, Inc.

この記事はBASE アドベントカレンダー7日目の記事です。 6日目の昨日はasakoyaさん！妊娠から復帰までの体験記がとても参考になるので興味ある方は是非ご覧ください。 はじめに こんにちはBASEのProduct Dev / Feature Dev1 GroupでアプリケーションエンジニアをしているTorataです。 突然ですが、みなさんそろそろ年末で大掃除の時期ですが整理整頓やってますか？ ブラックフライデーで買いすぎて無理やり収納してるもの、なかなか捨てる踏ん切りがつかず家に残ってしまっているものはありませんか？ そんな大掃除でもやるであろう整理整頓ですが、これには王道のステップがあります。 全部出す 不要なものを取り除く グルーピングする 優先順序をつけて並び替える 定位置を決めて収納する これは私の所属するチームのマネージャーのtakashimaさんから教えてもらったものです。 takashimaさんは家の中だけでなく、日々の業務における課題の整理にもこのメソッドを応用していると聞いたので自分も真似してみようと思いました。 今回はこの整理整頓のメソッドを用いて、お問い合わせの対応時間を短縮しようとした話を書いていこうと思います BASEにおけるお問い合わせ対応 ネットショップの作成サービスであるBASEには日々ショップのオーナー様やそのショップを利用するユーザー様から機能の仕様に関する質問や不具合のお問い合わせをいただきます。 技術的な調査が必要なものに関してはエンジニアに調査依頼が来るのですが、エンジニアも担当プロジェクトと並行しなければなりません。 かといってお問い合わせ対応の優先度を下げることはできないので、問い合わせに使う時間が増えることはそれだけ担当プロジェクトに割ける時間が短くなることを意味します。 改善前の課題 現在BASEでは機能をいくつかにカテゴリ分けして、チームごとに担当が割り振られています。 さらにその担当を一定期間でローテーションをすることで属人化を排除しようという方針で運用がされています。 今年の9月にも担当カテゴリのローテーションがあり、 Instagram販売App と Instagram広告App を私のチームが担当することになりました。 これらのAppはInstagramとBASEを連携するという機能で問い合わせ対応の際に以下の課題がありました 連携するのに複数ステップが必要な機能で理解が難しい 開発に携わったメンバーがすでに社内にいなく、仕様を完全に把握している人間がいない 担当カテゴリのローテーションをしたばかりでチーム内に知見がない 上記の要因と外部連携の機能という特性上、原因がBASEにあるのか、Instagram側にあるのかの切り分けが難しい これらの理由で9月10月はお問い合わせ対応に時間を取られてしまい、担当プロジェクトに影響が出てしまいました。 やったこと 実際に改善に向けて整理整頓のメソッドに則って以下のように進めました。 全部出す 今までチームで対応した問い合わせを全てFigJamに出しました。 この時、「グルーピングする」の時の指標に使えるように「問い合わせ内容」「問い合わせの回答」「かかった時間」をFigJamに並べました。 不要なものを取り除く グルーピングの時にノイズになってしまいそうな問い合わせをこの時にFigJamから削除しました。 （具体的にはInstagram関連の問い合わせではあるが、関連する別の機能に関する問い合わせ） グルーピングする 「1.全部出す」 でFigJamに出した内容をもとに以下の4グループに分けました。 社内管理画面から解決できるグループ BASE / Instagram の仕様を詳しく知らないと回答できないグループ BASE側での調査が難しく、Instagram側に再度問い合わせをお願いしたグループ その他グループ 優先順位をつけて並び替える 問い合わせ対応の時間を短縮することを目的に改善をしているので改善活動自体に時間がかかっていては意味がありません。 今回の改善はコスパよく時間短縮を目標にしていたので、件数自体が一番多く、対応自体もシンプルにできそうな「社内管理画面から解決できるグループ」を一番優先度高く、このグループの問い合わせ対応時間を減らす施策を考えることにしました。 定位置を決めて収納する 課題解決における収納はタスク化になります。 今回フォーカスすると決めたグループの対応時間を減らすために、 問い合わせ対応で最初に見るべきフロー図を作ること をタスクとしました。 また、このフロー図を問い合わせを一時受けしているCSの方にも共有することでエンジニアに来る件数を減らす、来たとしてもテンプレ的に解決できるようにすることを狙いとしました。 おわりに 片付けも仕事も何をやるか決まっていない時に腰が重くなりがちです。 これがテンプレになって次やることが明確だと最初の一歩を踏み出しやすくなるんじゃないかなと感じました。 今後、お問い合わせに限らずチームや組織で見つけた課題があれば積極的に改善活動やっていきたいですね。 他にもお問い合わせでこんなことやっているよという事例があれば是非教えてください。 BASEでは現在アプリケーションエンジニアを積極採用中です。 興味ある方は是非ご応募ください！ 採用情報 | BASE, Inc. - BASE, Inc. 明日は同じチームのyunamiyaaさん！お楽しみに！

本記事は BASEアドベントカレンダー2024 の6日目の記事です。 はじめまして、BASEでエンジニアをしているasakoyaです。 2022年10月にBASEに入社し、Merchant Management Devというチームで、不正決済対策や法改正対応など、決済に関する開発に取り組んでいます。 2024年1月に第1子の男の子を出産し、10月に職場復帰したばかりです。 初めての妊娠・出産・育児に挑戦する中で、BASEのサポート体制に助けられたことがたくさんありました。この経験が誰かの参考になればと思い、筆を取りました。 なお、BASEは男性でも育休を取得される方がとても多く、関連したブログ記事もあります。 devblog.thebase.in devblog.thebase.in 今回は女性目線での体験をお届けします！ 妊娠期 妊娠が分かったのは2023年の6月。 安定期に入るまでは周囲への報告を控える方も多いと思いますが、私はすぐに上司と会社へ伝えました。当初は体調が不安定だったため「迷惑をかける前に言っておこう」というのと、BASE独自の制度である「妊娠特別休暇」を付与してもらうためです。 これは定期健診や両親学級への参加、体調不良時に使える特別な休暇で、有給です。「無理せず休める環境」というのは、体の面でもありがたいですが、個人的にはそれ以上に「会社が気遣ってくれている」と感じられることが大きかったです。 また、BASEではハイブリッドワークを取り入れており、在宅でも働くことが可能なため、体調が優れない日でも無理のない働き方ができました。 12:00〜16:00がコアタイムのフレックス勤務のため、妊婦健診も、比較的空いている平日の午前中に、仕事を休むことなく行くことができました。（健診が長引いた時などは妊娠特別休暇を使いました） 仕事の引き継ぎ 体調が比較的すぐに安定したこともあり、妊娠を理由に仕事の内容や働き方を変えたり、セーブしたりする必要はほぼありませんでした。 ただ当然、出産後は長期間お休みすることになるので、引き継ぎについてはマネージャーと相談して調整していきました。私の担当していた仕事は、新しく業務委託の方を採用して引き継ぐことになったので、チームへの負担が増えることにそこまで罪悪感を覚える必要がなかったのはありがたかったです。 おかげさまで、出産予定日の3週間前まで元気に働き、1年間のお休みをいただく予定で、産前休暇に入りました。 いざ出産 「産休ってヒマだな〜」などと余裕ぶっていたら、予定日より10日も早く、いきなり破水してあっという間の出産になりました。3,300gの元気な男の子でした。 あまり準備ができていなかったので「なんか色々書類出さなきゃいけないんだよね！？」と大慌てでしたが、BASEには「産休・育休HAND BOOK」という詳しい資料があり、そこに妊娠・出産関連の手続きの情報がまとめられているので、これがとても参考になりました。 また、妊娠を報告した段階で、労務担当の方がSlack上で専用の育休対応チャンネルを作ってくれました。手続き関連で分からないことがあればすぐに聞けるので、心強かったです。私は手当金の細かい額まで色々と口うるさく質問したのですが、丁寧に答えてくださり感謝です。 手当金といえば、これは会社独自の制度ではありませんが、BASEは関東ITソフトウェア健康保険組合に加入しているため、出産育児一時金として、法定給付50万円に加えて付加給付9万円が受け取れます。ありがたいですね。 復帰まで 子育てが始まって最初の1〜2ヶ月は、体調も安定せず、慣れないことも多くてヘトヘトでした。 ただ、その期間を過ぎると（こんなことを言うと怒られてしまうかもしれませんが）結構ヒマでした。夫が5ヶ月間の育休を取ってくれたのと、子どもがとても優秀で、昼も夜もまとまって寝てくれるという、大変に親孝行な子だったからです。 というわけで、ぼんやりと桃鉄に励む日々の中でふと「早めに復帰できるのでは…？」と思い至りました。 また同じ頃に実家近くへ引っ越し、その地域で入園できる保育園が見つかったため、当初1年の予定だったのを短縮し、8ヶ月で復帰することになりました。 復帰前にはマネージャーや労務担当の方との面談があり、復帰後の働き方についてしっかり相談できたので、安心して仕事を再開できました。 時短勤務や、時間外勤務の制限など、色々な選択肢がありますが、私は休業前と同じくフルタイムで働くことを選択しました。フルタイムで復帰しようと思えたのは、自分の妊娠期の経験も含めて、BASEには柔軟に働ける環境が整っていると感じていたからです。 いざ復帰 「BASEには柔軟に働ける環境が整っている」は本当にその通りだと感じています。 たとえば、夕方以降はカレンダーをブロックして子どものお世話に専念したり、お迎えのために業務を途中抜けしたりする働き方が、マネージャー陣も含めて当たり前のように浸透しています。 子どもの送り迎えを夫と分担して、私自身は基本的に8:00〜17:00で働いていますが、Slackを活用した非同期的な業務が多いため、チームメンバーとの勤務時間のズレも問題になったことはありません。 携わるプロジェクトの内容も、私が休業前に携わっていたものと領域が近く、比較的容易にキャッチアップができるものだったので、スムーズに業務に戻ることができました。 0歳児（10ヶ月）とのリアルな生活 参考までに、今現在の私の1日のスケジュールを載せてみます。 7:00 子どもと一緒に起床 7:15 子どもと自分の朝食、自分の支度 8:00 子どもを夫に任せ、業務開始 時間がないときはパジャマのまま仕事を始めます 8:30 玄関で夫と子どもを見送り 12:00 昼休み、夫と一緒に昼食 まだパジャマのときはこのタイミングで着替えたりメイクしたり 13:00 業務再開 17:00 業務終了 17:20 保育園お迎え→子どもと遊ぶ 18:00 子どもの夕食 18:30 子どもと一緒にお風呂→ミルク→歯磨きなど 19:00 寝かしつけを夫に任せ、夕食準備 20:00 夫と夕食→片付け 21:00 フリータイム お風呂に入ったり、家事したり たまに仕事に戻ることも 時間があれば読書やゲーム 0:00 就寝 見ての通り、朝と夜はバタバタですが、この寝顔のために頑張っています。 夫婦共に在宅勤務・フレックス勤務でこれなのだから、毎日出勤しているお父さんお母さんは本当にすごい。頭が下がります。 今後のこと ここまで書いてきて、なんだか本当に順風満帆にやってきたなあと思い返しています。妊娠の経過がとても順調だったこと、生まれた後も手のかからない性格で健康な子どもだということ、それから夫の全面的な協力があるという、非常に恵まれた環境のおかげです。 みんながみんなこうはいかないだろうし、私自身の家庭環境も、これからどう変化していくか分かりません。 でも、もしこの先、家庭環境が大きく変わっても「働き方や目指す方向を相談すれば、柔軟に対応してもらえる環境がBASEにはある」と感じています。 おわりに もちろん「子育て中でもみんなフルタイムで働くべきだ！」と言うつもりは全くありません。 大事なのは、幅広い選択肢と、柔軟な環境があること。少子化が叫ばれて久しい現代、子育てとキャリアの両立ということが言われますが、なによりも、変化に対応できるという安心感が必要だなと思います。 ここに書いた私の経験が「こんな働き方・生き方もあるんだ〜」と誰かの参考になったり、希望になったりしたらとても嬉しいです。 もしBASEという会社に魅力を感じていただけた方がいれば、是非一緒に働きましょう！ binc.jp 最後になりましたが、産休・育休に快く送り出してくださり、復帰後も温かく迎えてくださったチームメンバー、支えてくださったマネージャーや労務担当の皆さま、本当にありがとうございました。 これからもよろしくお願いします！ ※当記事でご紹介した制度等は2024年の執筆時のものです。法律や会社の制度は変わる可能性がありますのでご了承ください。 明日はTorataさんが整理整頓の極意を教えてくださるそうです。お楽しみに！

devblog.thebase.in 本記事はBASEアドベントカレンダー2024の5日目の記事です。 はじめに BASE Feature Dev2 Groupでバックエンドエンジニアをしている大塚( @ohiro88 )です。 10月1日に入社し、2ヶ月が経過したので入社してから現在までを振り返ってみようと思います。 これまでの経歴 インターネット広告代理店（ASP） → 求人広告メディア → BASE という感じです。 新卒でエンジニアとして入社してからずっとPHPをメインで使用しています。 BASEに入社するきっかけ 前職では求人メディアのバックエンドエンジニアをしていました。 エンジニアとしてのキャリアを通じて、ユーザーに価値を提供することにやりがいを感じてきました。もちろん前職でもやりがいはありましたが、プロダクトの成長がユーザーへの価値提供により直接的につながる開発に携わりたいと考え、転職活動を始めました。 転職活動をする中で、転職サービスを通じてBASEにお声がけいただきました。 サービスはもちろん知ってましたし、カンファレンスなどのスポンサーをされていることも知っていたので、技術に対して積極的に取り組んでいるという印象でした。 お話を伺う中で、ユーザーへの価値提供がプロダクトの成長にダイレクトにつながっていくような、サービスにもっとコミットできる開発ができる環境があると感じ、入社を決めました。 入社して感じたこと スピード感 まず感じたことは開発や意思決定などの速さです。 開発チームやプロジェクト単位で意思決定をする場面が多く、開発メンバー一人一人の自分たちの開発しているプロダクトに対しての解像度が非常に高いと感じました。 それと同時に、技術力やコミュニケーション力も非常に高く、実装の方向性の議論をしてから実装までが非常に速いと感じました。 デプロイのフローもある程度整っておりオンデマンドで実行されるため、総じて開発組織としてのパフォーマンスが非常に高いと感じています。 プロダクトやユーザーへの熱量 次に感じたのはプロダクトファーストやユーザーファーストな考え方です。 BASEはプロダクトの成長がユーザーの成長に直結するので、常にユーザーのことを考えながら開発を進めています。 この後にも記載していますが、ユーザーの声から発足するプロジェクトなども多くあります。 こういった開発は私自身もやりたかったことなので、かなりやりがいを感じています。 入社直後のお仕事 入社後は配属予定のチームから1名メンターを付けていただき、社内の手続きや開発サポートなどを行なっていただきました。 入社して初めの2週間ほどはメンターの方とオンボーディングタスクを中心に実施しました。 あらかじめオンボーディングタスクとして社内の制度や簡単な開発などを用意していただいているので、それを消化することで自然とBASEのことや開発方法などを知ることができました。 BASEは会社としての規模が前職よりも小さかったので、会社の制度として行き届いていない部分もあると思っていましたが、人事の方やメンターの方含め手厚くサポートして頂き、スムーズにチームに合流することができました。 各部署の責任者の方々や社長から直々に説明会や質疑応答の場を用意していただいているので、疑問や不安などもなく入社できたと思います。 現在のお仕事 現在はショップオーナー様が利用する管理画面の検索機能のパフォーマンスを改善するプロジェクトを進めています。 BASEはスモールビジネスをされている方々向けにスタートしたサービスですが、リリースから10年を超えありがたいことに規模の大きなショップも増えてきております。 サービスが順調にスケールしているので良いことではありますが、データ基盤などがそれに追いついておらず、検索機能のパフォーマンス問題が顕著に現れるようになってきました。 実際に規模の大きなショップオーナー様からも課題としてお声をいただいていました。 そういった課題を解決するため、今までの検索で利用していた技術を全く新しいものに一新するプロジェクトになってます。 検索に関わる技術というのは多くのwebサービスのコアの技術になってくると思っており、それを改善することでプロダクトの価値は向上すると考えています。 それが直接ユーザーであるショップのオーナー様のショップ運営の効率改善にも貢献でき、ショップの売上向上などにも貢献できると思うので、とてもやりがいを感じています。 私の入社する前から動いていたプロジェクトで、終盤に差し掛かっているタイミングでのアサインとなりましたが、質問などにも丁寧に答えてくださったり、ペアプロなどを通じて私のコードの理解のサポートをして頂いたりと手厚くサポートいただいているので、なんとか皆さんに付いていけているような状況です。 そういった大変さはありますが、プロジェクトを通じて私自身の成長にも繋がっているという実感もあるので、いち早くチームの力になれるように成長していこうと思います。 その他にやっていること 検索機能のパフォーマンスを改善するプロジェクト以外にも並行して様々なことをやらせていただいています。 その1つとして、New Relicの活用推進のお手伝いをさせていただいています。 New Relicについての説明は割愛させていただきますが、BASEではアプリケーションのメトリクス監視やログ監視、サービスレベル運用などで活用しています。 直近ではサービスレベルの活用を進めていこうということで、社員主導のワークショップでメンバーのサービスレベル運用の理解促進をしようとしています。 前職でもNew Relicの活用を推進させていただいていたので、入社2ヶ月程度の新参者ですがその経験を活かしてワークショップの進行をさせていただいたりしています。 サービスレベルの運用についてはまだまだ始めたばかりなので、しっかりと活用できるように尽力して行きたいと思います。 おわりに まだまだ慣れていない部分もありますが、社員の皆さんはとても良い方ばかりでサポートや制度は充実しておりいつも助けれらています。 常にユーザーのことを第一に考え、日々ユーザーのためにプロダクトを成長させています。 そんなBASEに興味を持っていただけたら嬉しいです。 BASEではエンジニアを絶賛募集中ですので、興味のある方はぜひ採用情報などもご覧ください！ 明日は、Asakoyaさんの記事です。お楽しみに！ binc.jp

はじめに BASE BANKの出金Dev Group でエンジニアをしている 池田聖示 です。 2024/07に入社し、今月で6ヶ月目になりました。 今までどのような取り組みをしてきたのか、何を感じたのかなどを書きたいと思います。 自己紹介 妻と4歳の息子がいます。 エンジニア経験としては、大学時代の長期インターン1年と新卒で入社した企業で2年ほどの計3年、主にバックエンドエンジニア（タスクに応じてフロントエンドの開発なども行っていた）として働いていた状態で入社しました。 なので本ブログは、主にエンジニア経験年数の短いand子育てしている私にとってBASEがどのような環境かという視点で書いています。 ※本記事の情報は2024/12/04時点でのものです。特に組織に関することや福利厚生に関することは変更されることもあるためご了承ください。 入社した理由 大規模なシステムに携わりつつ、さまざまな領域に知見のあるエンジニアの方々と研鑽してエンジニアとして成長したいという気持ちと、BASE BANKのエンジニアの指針であるフルサイクルエンジニアとして開発に閉じずプロダクトにインパクトを出せるエンジニアになりたい、という思いで選考を受けご縁があり入社しました。 選考を通してエンジニアリングのレベルの高さを感じ、成長できそうと強く思ったことと、この先自分が開発だけではなく、施策の企画〜リリース後の検証や評価という一連のサイクルに携わりながらサービスにインパクトを残せるエンジニアになりたい、という目標が明確になり入社を決意しました。 ※BASE BANKについては下記の資料をご覧ください speakerdeck.com ※フルサイクルエンジニアに関しては詳細に下記のブログで説明されているのでぜひご覧ください devblog.thebase.in 入社してからのこれまで 7月1日の入社から2週間〜1ヶ月くらいまではオンボーディング期間として、会社の説明、各部署の説明、所属部署の各サービス説明などを受けつつ、オンボーディングタスクとして担当サービスの開発業務を行いました。 感想としては、オンボーディングがとても手厚かったので率直に驚きました。ドキュメントが整っていたので開発環境構築や担当サービスのキャッチアップなどで特段困り事などがなかったです。 不明点があればメンターの方が丁寧にサポートしてくださったのでスムーズに開発に入れました。 また、基本的にBASE BANKは週に一度出社ですが、入社した週は出社してメンターとマネージャーがオフィスでオンボーディングをしてくれたので、不明点がある際にすぐ聞ける環境だったのでとてもありがたかったです。入社した人の希望を聞きつつオンボーディング期間の出社日などを柔軟に対応してくれたのでとても助かりました。 入社後行ってきたタスクで大きなものだと、特定エンドポイントのパフォーマンス改善タスクや月初業務の自動化などを行ってきました。 どちらも経験のないタスクだったのですが、毎日のデイリースクラム後に同期作業会という相談や壁打ちなどチームで自由に使える時間でサポートして貰いつつなんとか開発を行ってきました。 仕事の環境 私が所属しているBASE BANKという部署は、5つほどのサービスを提供しておりエンジニアは3つのチームに分かれています。 ただ、チームを超えて定期的なミーティングや輪読会なども行っています。チームを超えて技術的な相談なども気軽にできる環境です。 私が所属しているチームでは主に、振込申請という機能とBASEカードというサービスの開発をしており、各メンバーは軸足を置いて開発している機能・サービスもありつつ複数のサービスの開発を担っています。 そして、各サービスで技術スタックは異なるので様々な技術に触れることができて刺激的です。 後述する成長した点で詳しく書きますが、バックエンド、フロントエンド、インフラなど問わず開発をしているので経験技術の幅がとても広がっています。 入社して感じたBASEの良いところ 経験のあるエンジニアが沢山いる フロントエンドやバックエンドの領域で技術力があるエンジニアが多いのはもちろんのこと、SREやデータ分析などの専門チームがあるので、インフラに関する実装を行った際にはレビューしてもらったりできるので技術力を研鑽できる環境だと感じています。 チームを越境して助け合う文化がある Slackで誰かが質問や相談のコメントをしたら誰かしらがすぐ回答する様子をよく目にします。チーム問わず困っている誰かを助けようと動く文化がとても素晴らしいと感じています。 情報がオープン 肌感ですが上場している関係で出せない情報や個人情報以外は全て観れるのではないかと思っています。特に月に一度の全社の会議では各部署の数字や行っていることなどをキャッチアップできるとともに、ドキュメントとして後から閲覧できるのでとてもオープンだなと感じています。 ドキュメントが充実している 技術的なドキュメントで言うと特定ツールの使い方や設定や「〇〇しました」系のTipsドキュメント（例えば、「デッドロック対策しました」とか）を書いて社内で公開してくれるので、何かで詰まった際や同じような実装をするときなどに先人の知恵が豊富にあります 働きやすい 私は子供がいるため、フレックスタイムを利用して幼稚園の迎えやご飯、寝かしつけなどが終わってから夜再度働くなどのスタイルで働く日が多いです。コアタイムが12時から16時という比較的短い時間なので突発的に何かあっても柔軟に動けます。 嬉しかった福利厚生 子の看護休暇 「子の看護休暇」という通常とは別の有給休暇が付与されており（1年あたり5日）子供が熱を出した時などに使用できるため、有給の残りの日数を気にすることが少なくなりました。 メンターランチ オンボーディング期間に会社の人と行くランチ代を会社が支給してくれます。他のチームの方と交流できるのでとてもありがたかったです。 「BASE」加盟店での購入補助 BASEを利用しているショップで、月1万円までの購入金額を会社が支給してくれます。この福利厚生があるおかげで、BASEを利用してくれているショップを実際に購入して関われる機会が増えたので素晴らしい福利厚生だと感じています。 ※福利厚生についての記事は下記をご覧ください basebook.binc.jp 入社してからどのような成長があったか 技術の幅が広がった 主に下記の3つにおいて技術の幅が広がったと感じています。 設計 月初対応の自動化タスクでバッチ処理を設計から行い非同期でのETLや、使用するAWSサービスの選定などを行ったことで今まで行ったことのなかった設計タスクを行い技術の幅が広がりました インフラ 今まで経験のなかったAWSサービスを使用したり、Terraformを使いリソースの管理を行ったりしてインフラ領域での経験を積むことができました 未経験の言語など 前職ではGoとReactで開発していましたが、振込申請は主にPHPとVue、BASEカードはGoとVueという技術スタックなのでPHPとVueに関しては未経験だったのでキャッチアップしつつ経験をすることができました（チームに今年のPHPカンファレンス実行委員長( @cocoeyes02 )がいるのでPHPキャッチアップにおける最高の環境がある） また、Vue Fes Japan 2024にも会社の補助で参加させてもらい、技術的な挑戦を後押ししてくれる会社だと強く感じています。 より精度の高い仕事をする上での考慮することが増えた 例えば、DBのテーブルのレコード数増加によるパフォーマンスへの影響や、非同期処理も考慮した運用手順などの設計、複数のリポジトリやサービスが絡んだ機能のリリースフローなど、規模が大きいからこそ特に考慮しなければならないことがあり、今まではあまり考えたことがなかったことも考慮するようになりました。そしていかにリリース時の懸念を無くし不確実性を減らすかという視点で考えるようになりました。 ただこれらのことも入社当初は何も考えることができていませんでした。前述した同期作業会で日々壁打ちしつつフィードバックをもらい短いサイクルで開発→フィードバック→修正を繰り返して早く成長することができたと思っています。 まとめ 最後に働きやすさや成長の観点で弊社がどのような環境か私が思っていることを書きます。 総じて言えることは、少なくとも今私が所属しているチームは若手のエンジニアの成長にとても素晴らしい環境であると思っています。 チームの成長のためにアドバイスやフィードバックを惜しまない環境があるおかげで多くの挑戦ができていると感じています。未経験のこともサポートしてもらいつつリリースすることで貴重な経験を積むことができています。 今回は量の関係もあり、入社の目的の1つであったフルサイクルエンジニアとしての働き方や取り組んでいることなどについては触れることができませんでした。機を見てブログなどで振り返りたいと思っています。 おわりに BASE、BASE BANKでは一緒に働く仲間を募集しています！ ぜひ採用情報をご覧ください！ binc.jp 明日は @ohiro88 さんです！お楽しみに！

<この記事は Hatena-Blog-Workflows-Boilerplate によって作成されました> こんにちは！ BASE 株式会社 Pay ID 兼 BASE PRODUCT TEAM BLOG 編集局メンバー の @ zan_sakurai です。 今回は、BASE PRODUCT TEAM BLOG のブログメンバーを Terraform Provider for HatenaBlog Members で管理をはじめたので、その紹介をいたします。 前回は、 Hatena-Blog-Workflows-Boilerplate を使ってとある SaaS のリンクを一括置換した話 について書きました。 今回も企業ではてなブログで技術ブログ等を運営されている方の一助になればと幸いです。 Terraform Provider for HatenaBlog Members Terraform Provider for HatenaBlog Members とは、株式会社はてなさん が公式で公開されている、はてなブログのブログメンバーを Terraform で管理できる Terraform Provider です。 以下のドキュメントに詳細を記載いただいており、今回はそちらを参考にし構築を行いました。 はてなブログのブログメンバーを Terraform で管理できる Terraform Provider for HatenaBlog Members を公開しました hatena/hatenablog-members | Terraform Registry https://github.com/hatena/terraform-provider-hatenablog-members Terraform Provider for HatenaBlog Members でのブログメンバーの管理 これまで、BASE PRODUCT TEAM BLOG でのブログメンバーの管理は、BASE PRODUCT TEAM BLOG 編集局に依頼を行って、手動でブログメンバーの追加・削除を行っていました。 有り難いことに、ブログを執筆したいと言ってくれる方々も増えてきておりまして、それと同時に編集局のブログメンバーの管理の負担が徐々に大きくなってしまうことが予想できました。 そこでブログメンバーの管理を簡略化するために、Terraform Provider for HatenaBlog Members を導入に至りました。 基本的には前述のドキュメントを参考にしながら構築すれば特にハマるところはなく、スムーズに導入することができるかと思います。 弊社の場合、ブログメンバーもそこそこ多く? resource... を都度記述して追加するのも面倒に思えましたので、 以下のように、メンバーのリストを変数として管理し、そのリストを使って、メンバーを追加・削除するようにしています。 variable "members" { description = "List of members to manage" type = list ( object ( { username = string role = string } )) } members = [ # This is an example of the structure of the members variable. # You can add or remove members as needed. # { # username = "your_hatena_id" # The Hatena ID of the blog member. # role = "editor" # Role of the blog member. Role must be one of 'admin'（管理者）, 'editor'（編集者）, or 'contributor'（寄稿者）. Basically, Please set the 'editor'（編集者）. # }, { username = "your_hatena_id" role = "editor" } , また、Github 上での管理を行っていますので、 申請(Pull Request) -> 承認(Approve) -> 反映(terraform plan/apply) といった流れでメンバーの追加・削除を行うことができますので、変更履歴も残り、誰がどのような変更を行ったかも把握しやすくなりました。 承認(Approve) に関しては、CODEOWNERS を設定して、マージ前に必ずレビューを強制するようにして、承認プロセスを表現しています。(CODEOWNERS のメンバーは、編集局のメンバーを設定しています。) さいごに(と余談) 今回は弊社での Terraform Provider for HatenaBlog Members の利用例を取り上げてみました。 企業ではてなブログで技術ブログ等を運営されている方にはぜひ一度お試しいただきたいです!!! 余談ですが、今回の Terraform Provider for HatenaBlog Members のようにコードでのメンバー管理をするよく目にすることが増えてきたように思います。 このようなパターンは Teams as Code などと呼ばれるそうですね。 GitHub Provider など他にもあるので、いつか検証してみた記事を書くかもしれません。 明日は、 @ikechen さんの記事です。お楽しみに!!! また、弊社では仲間大募集中です！ open.talentio.com

この記事は BASE アドベントカレンダー2日目の記事です。 勉強会の隠れた課題「読書会のジレンマ」に立ち向かう BASEでシニアエンジニアをしている プログラミングをするパンダ です。 この記事では普通の社内読書会をレベルアップする方法を紹介します。自分の所属するチームでは2ヶ月に渡る勉強会でこの方法を実践した結果、参加者の全員が書籍の内容をしっかり学べたという手応えを感じています。実際に、チームメンバー全員から今までよりも効果的な読書会だったと感想を貰えました。 結論を先に書くと、その方法は自分たちが触っているレポジトリから書籍の内容に当てはまるところと、書籍の内容を実現できていないところを探して発表するというものです。つまり、本で得た知識をすぐに使うというアクティブラーニング志向の読書会です。 そもそも読書会というものは、課題の書籍を読んできてその感想を共有するやり方が一般的です。ただし、この方法はパッシブな読書体験であり、読み手のスキルによって知識の定着量に差が出てしまいます。なぜなら、技術本の読書会の目的はみんなの知識レベルを揃えることなのに、本を読みこなすためにはそれなりに事前知識やスキルが必要だからです。このことを私は 「読書会のジレンマ」 と呼んでいます。 読書会のジレンマは読書会に必ずついて回る課題なのに、読書会での学習効果は学習者自身の責めに帰せられるが故に大っぴらに語られることのない隠れた課題でもあります。この読書会のジレンマについて、以前 ある勉強会の発表 で触れたところ「うちの会社でもあります」と共感を得られました。そこでこの課題は普遍的なことだと思ったこと、勉強会の工夫によってこの課題の解決に一定の成果が出ていることから記事にして公開することにしました。 読書会の隠れた課題を紹介するスライド 勉強会の隠れた課題が露見した瞬間 BASE 社内では読書会が盛んに行われています。あるプロジェクトが組成された後、プロジェクトの完遂までに1,2回ほどは各チームで読書会が開催されるように思います。もちろん業務時間内にです。 私が読書会のジレンマに気づいたのは、かつて自分が所属していたチームで読書会を開催した時でした。技術雑誌のある特集を教材として2回の短期的な勉強会を実施しました。 その方法は以下です。対象範囲を事前に読んで感想をドキュメンテーションツールに記述し、勉強会当日にそれを共有する。疑問が共有されれば、その場でその疑問をみんなで一緒に考えるというごくごく一般的なスタイルです。 読書会の開催後、短い教材の中から「実務に活かせる」とそのエッセンスを読み解いて翌週のプルリクエストに学んだ内容を反映したメンバーもいれば、「書かれている内容は理解したが、実務に活かせるイメージが湧かない」という感想を共有したメンバーもいました。 自分にとってこの言葉はショックでした。読書会の教材は実務に活かすためのものであり、「ここに書かれていることは今の自分たちのコードのここに活かせるな」と考えながら読むもので、それこそが実用書の価値というものです。 「内容はわかったけど、実務にどう活せばいいかわからない。」この言葉は自分に勉強会のあり方を再考させるきっかけとなりました。そして、次はこのフィードバックを活かした勉強会を開催しようと心に決めました。 チームのスキルレベルを揃えるための勉強会を開くために そのチームは無事にプロジェクトを完遂して解散した後、全く異なるメンバーで新しいチームが組成されました。 チームメンバーには転職してきたばかりの方もいました。どのチームでも最初はそうなのですが、全員のスキルレベルが揃っていないが故に、開発初期のコードレビューでは「本当に届けたい機能、実現したい仕様」といった本質的な議論よりも「このときはこう書くのが一般的です」という表面的なレビューのコメントが増えていました。 開発の現場で学習のコストは見過ごされているように思います。実のところ勉強会というものは、事前の見積もりに含まれない隠れた教育・学習のコストです。つまり、「開発の期限は、開発者が不足しているスキルを補う時間を考慮していない」のです。これはアジャイル開発かどうかは無関係です。 少ない時間でチーム全員をある程度同じスキルレベルにまで手っ取り早く引き上げる手段を採用したいと思うのはごく自然なことです。この課題を解決するために、 オブジェクト指向設計スタイルガイド の勉強会を開催することに決めました（この本の選定理由はスライド 「軽量DDDはもういらない！ スタイルガイド本で OOPの実装パターンを学ぼう」 をご覧ください）。 しかし、事前に読んで感想を共有するベーシックな勉強会のやり方では以前の二の舞になる可能性があります。前回の勉強会を反省した結果、そもそも勉強会には「読書会は参加者のスキルアップのために実施するのに、そもそも読み手のスキルレベルによって吸収量に差がある。その結果、学習効果は一様ではない」という勉強会のジレンマがあることに気づきました。 そこで、このジレンマを解消するためにアクティブラーニングな勉強会を実施する方法を考えました。 アクティブラーニング志向の勉強会で知識をすぐに活用する アクティブラーニング志向の勉強会では各自の感想の共有を実施しません。代わりに以下の2点を勉強会で議論することにしました。 書籍の内容で理解できなかったこと、疑問に思ったことをメンバーに共有する。その内容が理解できるまで、疑問が解消するまで徹底的に議論する 書籍の内容と自分たちが開発しているレポジトリのコードを照らし合わせて、書籍の内容を実践出来ているところと出来ていないところを pick up して紹介する 勉強会の開催にあたり、まずチームメンバーに対して勉強会のコンセプトを共有しました。コンセプトはアクティブラーニング形式であることを表現したものです。 コンセプト 議論中心。知識をそのまま覚える暗記に加えて、なぜそれが有用なのか、あるいは不要なものがあるかを語り合う コードで実践！とにかく実践！新規実装でもリファクタでもすぐに実践する！ 次に各回の進め方と事前に準備してもらうことを共有しました。 各回の進め方 各設計スタイルで理解できなかった点を共有してもらい、それについて議論する 「このスタイルを採用するメリットがわからない」とか 自分が気に入ったスタイルを反映しているプロダクションコードを最低1つ紹介してもらう 「スタイルを反映していないので、これからリファクタか改修したい」というコードでもOK 準備してもらうことは負担が大きくなりすぎないように設計しました。 準備してもらうこと 1章ごとに 疑問を持った設計スタイルを書いておいてもらう いくつでも 気に入ったスタイルが反映されている、もしくは反映されていない backend のコードを pick up してもらう 最低1つ 本を読む、コードを探す、本の知識でコードを批評する。この3ステップがアクティブラーニング志向の勉強会の構成要素です。 実際に参加メンバーが共有した内容はこちらです。「本番コードでの assert の使いどころ」や「getter でプロパティを検証していることは Allways Valid なドメインモデルではない」などかなり踏み込んだ疑問や指摘がされているのがわかります。実際にこのときの議論は盛り上がり、また建設的な内容になりました。 疑問を持った設計スタイルの例 スタイルを反映していないコードの例 アクティブラーニング志向の勉強会の効果を振り返る 勉強会の開催以降、コードレビューでは「このときはこう書こう」という一般的な指摘がほとんどゼロになったため、実際に効果があったと言って良いでしょう。「ここは本に書いてましたよ」ということもほとんどありませんでした。 さらに、 オブジェクト指向設計スタイルガイド は良書であるため、チーム全体の設計力も向上しました。 これらの結果は勉強会の目的通りだったので一安心しました。しかも、当初想定していた以上の成果を出すことが出来たのは自分にとって驚きでした。それは、参加メンバーからの勉強会に対するフィードバックの内容に表れています。 本文の質問をきっかけに心理的安全性を醸成 フィードバック1「書籍を読んで感じた疑問についてみんなに聞いて考えることで、書籍の内容をきちんと理解できた」 疑問に対しては誰か知ってる人が教えるというのではなく、みんなで一緒に考える雰囲気を作ることを意識していました。思わぬ効果として、何でも質問ウェルカムな雰囲気の中で自分が持つ疑問についてきちんと議論することで「自分はここで何を聞いてもいいんだ。わかってないやつだとバカにされないんだ」という心理的安全性が醸成されました。 チームでは勉強会が終わった後もこの雰囲気は継続しています。後日あるメンバーと1on1をしたところ「何を聞いてもみんな優しく答えてくれるので安心して働ける」と言って貰えたのでチームビルディングにも役立つことを体感しました。 スタイルの適応例探しから業務外のコードリーディングへ フィードバック2「事前準備をする中で、今触っているレポジトリから本に関係するコードを探してくるので、書籍の内容の使用イメージがすぐに湧いた」 この点に関しては狙い通りです。さらなるフィードバックとして「普段開発している箇所以外から垣根をこえてコードのサンプルを探しに行くので、システムの中心的な部分など他のところでどんなクラスがあってどんな処理をしているのかを学ぶきっかけになった」と言って貰えました。 こちらも思わぬ効果です。実際、ある人はAというモジュールに対象のコードを探しにいき、ある人はBというモジュールに探しに行くとします。すると、それぞれの人はAモジュールとBモジュールのコードリーディングをして「こうだった」と発表をします。その知識は勉強会のメンバー全員に共有されるため、「ここは触ったことがないけどこういう作りになってるんだね」とみんなの視野が広がりました。 スタイルに従ってコーディングしたら、コードの良し悪しの言語化が上達した フィードバック3「スタイルに従うことで自分の考えていることをうまく表現できるため、コーディング中に迷うことが減った」 このフィードバックには続きがあります。「それに加えて、スタイルの原理原則に従っていないコードの違和感に気づける上に、それがなぜ、どのように違和感があるのか説明ができるようになったのは大きな恩恵です。」 良いエンジニアはコードを書いている間も「本当にこの書き方がベストだろうか」と自分に問い続けています。スタイルガイド本を学ぶことでこのセルフレビューの質が上がりました。他の人が書いたコードに対する違和感を言語化してうまく説明することができるようになったため、コードレビューのスキルもアップしています。 まとめ 読書会の準備と内容を見直すことにより、冒頭の「本の内容はわかったけど、実務にどう活せばいいかわからない」という課題に対処できました。もちろん書籍が扱っている内容によるものの、この勉強会の方法自体は社内勉強会でも社外の人たちと集まって輪読する会でもそのまま適用できると思われます。 普通の勉強会をぜひ学習効果の高い勉強会にバージョンアップしていきましょう。 BASEではWebアプリケーションエンジニアを積極採用しています。興味のある方はぜひご応募ください。 採用情報 | BASE, Inc. - BASE, Inc. 明日のアドベントカレンダーは zan_gi さんの「Terraform Provider for HatenaBlog Members を使ってみました。」です！お楽しみに！

はじめに こんにちは！BASE株式会社で開発担当役員をしているえふしんです。 今年もBASEグループ 2024年のアドベントカレンダーのトップバッターを務めさせてもらっています。 今回の記事では、2024年では、Xのタイムラインなどでよく聞いた「開発生産性」について考えてみたいと思います。 開発生産性を高めるとは 開発生産性という言葉を今年よく聞きましたが、その定義は、なかなか難解です。 生産性を定義する難しさについては、廣木さんの下記ドキュメントが参考になります。 qiita.com 経営レベルのマクロな意味であれば、GDPなどと同様に単純に 「売上総利益 ÷ 開発に携わる人数」 などでいいはずです。単純に、そのプロダクトの成果としての売上総利益や営業利益に対して、人数で割って見ておけば、過剰人員になった場合はこの値が落ちるわけですから、コスト的に効率の良い製品開発かは測ることがしやすいです。 一方で、開発チームで考えたいと思うのは、開発という行為に対して、我々の開発活動のあり方が今のままでいいのかそうでないのかを推し量る指標のことで、いろんなものが提案されていますが、何かを妥協して決めつけていかないと万能な指標はでないというのが定説です。また、開発という投資に対する遅行指標である売上総利益を待ってたらもう遅いです。 世間ではFour Keysが定番化しているようですが、ちょっとDevOps寄りすぎるというか、自分がイメージしている改善のアクションへの接続がちょっと難しそうだなと思って、活用自体はポジティブですが、もう少し納得できるように考えたいと思いました。 そもそも自動車の生産ラインのように一つの生産ラインで同じ類の製品をひたすら量産して、一定のものさしを前提としている仕事とは違って、一品一様で二度も同じコードを作らないWebサービスのソフトウエアの開発活動をなんらかしらの指標で平準化して求めようなんてのは難しい話です。 個人的には目標値として一切、置かない形で、デプロイ頻度を見ておくことがチームの活気を示すという意味ではありかなと思うぐらいで、間違っても、LL言語やオープンソースライブラリ、コード補完エディタに依存してるプロダクトがソースコード量を生産性指標にするのは違うと思いますし、案件難易度がプロジェクトごとに違うのにスプリントやバックログの数を複数チーム間での比較指標にするのも違うかなと思います。むしろ目的達成に対して変更するソースコード量の少なさを測りたいくらいです（いや、それも違うと思うが、更新するWebサービスにおける理想はむしろそっちかと思いますし、知識労働者がコード量だけで測られるのはおかしい話）。 指標化というのはカジュアルにやってしまいがちですが、不適切な指標化は人間の行動をミスリードすることがあります。そんな簡単なものではないと思えばこそ、慎重に考えたいものです。それこそ、馬のおしりをムチで叩くようなマネジメントなどになってしまったら、知識労働者であるソフトウエアエンジニアがその状況に我慢できるハズはありません。脳内がポジティブでなければ、適切にソースコードが生み出せないので、生産性云々以前の話です。 そもそも何のために継続的に開発をやっているのか？といえば、ユーザーに価値を届け、ユーザがなんらかしらのメリットを獲得し、その成果としてのビジネス指標が改善され、我々のビジネスの成長につながることを実現するということです。 つまり重要なのは「何回、ユーザさんに「いい変更だね！」という評価を受けたか？」という回数にあると思います。そのためには告知を含めた機能リリースや改善リリースの数を増やすということがプロダクト開発がやりたいことで、その中から成功確率を上げていくというのは、ビジネス全体視点での提供品質の話になります。 なので、プロダクト開発視点では「ユーザさんが知るリリース数を増やす」「トライの数を増やす」ということを「アウトプット量の増加」＝　「結果としての生産性の向上をもたらす取り組み」に着目できたらと思っています。測定ツールとしては、品質指標や集計のことを考えて、まるっとFour Keysの利用でいい気がしてますが、重要なのはユーザインパクトをもたらすことを目指したトライの数を意識することです。 たとえソースコード１行でも迅速に素晴らしい改善をしてユーザの感動を得れば、それは「有益だった１トライ」だと思いますし、大きい機能開発で大きなインパクトを得ることも重要なことです。 トライの数を増やすために必要なこと 個人的に継続開発するWebサービスの開発生産性に対する考え方として個人的に好みなのは、牛尾 剛さんという米国マイクロソフトで働かれている方の著書「 世界一流エンジニアの思考法 」に書かれている、 生産性とはいかに「レベル１（ = 何もググらずに実装できる）」を増やすかどうかではないか？ という文章にジワジワ来ました。 つまり人間のアウトプットを計測した数字の多寡を重視するアプローチではなく、能力に着目した考え方です。なお、牛尾さんの本では、このことが生産性の高さの指標だと書いてるわけではなくて、そのような能力を獲得することが重要なのではないか？という形で書かれています。 めちゃめちゃわかりやすく、いい感じに煽られてると思いませんか？ そう言われてみれば、社内で一番望ましい開発能力というのは、いわゆる汎用的な地頭の良さである仕様理解力に加えて、 大まかにソースコードを把握していて、どこをいじれば望み通りの結果が出るかを如何に素早く見積もりできて、見積もり通りに実現できること ではないかと思いました。正確には案件仕様と現場の仕様をかけあわせて、何をどこまでやるべきかについて正しい見積もりと脳内設計をして、適切にアウトプットできる人が一番確実な仕事ができるはずです。CTOへの仕様レビューも、さくっと口頭でやれてしまうのが望ましい（それだけの信頼と実績があることも含め）。 開発言語や開発ライブラリの知識はもちろんですが、自分たちのソースコードを掌握している人が一番、仕事の対応速度は早いと考えられます。同じだけの設計能力があるなら知識量が多い方が仕事が早い可能性が高いです。 そもそも、開発生産性に対する社内議論が出てきたのは、自分たちのプロダクトが、新入社員では簡単には把握できないほど大きくなってしまったと言われ始めた頃と符号します。もっと会社が小さかった頃の創業当初のメンバーは、今よりも少ないソースコードを把握していて、おそらく生産性という面では、一番そのころが早かったのでしょう。新しい機能の話が出てきても、話を聞きながら大まかの設計は完了していて、あの辺とこの辺を直せばいいと思っていて、即座に開発作業に取り組んでいました。 しかし、昨今の中途採用や業務委託の方による一定の人の出入りを前提とした組織において、ソースコードやサービスの仕様を知るというオーバーヘッドと、コード量やプロジェクト量の増加に伴う把握のしにくさが、開発者の作業性のオーバーヘッドにつながっていったと考えると、極論すると、全部のソースコードを把握していて、頭の中で整理してくれるような脳内のLLMを保有しているエンジニアが、結果として、一番、速やかに実装できると考えることが可能です。 ちゃんと改善を前提とした時に、エンジニア個々人のスキル評価にあわせることができれば、エンジニアの評価を上げる ＝ エンジニアのグレード（給料）が上がる ＝ 生産性が上がるはずです。機能リリースが増えて、ユーザー評価を受けるためのトライの数が増えたのに「売上総利益 ÷ 開発に携わる人数」が改善しなければ、それ以外の何かが間違ってるって話になり、根本から見直す必要があるでしょう。 トライを増やすための「オーナーシップ」と「脳内LLMへのインプット」 内製開発におけるエンジニアの能力を 「何もググらずに実装できるレベルのこと」 に置いたと仮定します。もちろん何もググらずというのは、かなりの理想の話で、Google検索したって、社内ドキュメントを調べても良いのですが、それらの行動と理解速度が最速で作業を進められるようになることを意識することが大事です。 これをもう少し抽象化し、このような状態を「ソースコードのオーナーシップ」を持っている状態と表現してもいいかもしれません。そして、同時に複数人が同じリポジトリのソースコードをいじってるわけですから、毎日、どこかしらの新しいソースコードが生成されると考えると、これはstaticな記憶力のことではなく、コードリーディングを通じて人間の動的に脳に備わっているLLM（人間の知力）が再構築できる能力ということになります。 また、エンジニアの能力をあげていくことを前提として、それを阻害する要素を取り除くことも重要な取り組みです。この場合は、アウトプットに着目するよりも、エンジニアへのインプットの最適化を考えるアプローチになると思います。こちらの方が、ふわっとアウトプットの量を高めようとするよりは、具体的な施策に落ちてきそうな気がしてきませんか？ 例えば、議論や会議の質を高めるであるとか、オンボーディングの改善、ドキュメントの整理の最速化、リファクタリング、更新情報の共有の仕方などが挙げられます。BASEのリアーキテクチャで取り組んでいるclean architecture化（バックエンドリポジトリ）への貢献もオーナーシップ化を促す活動とも言えます。コードを大きく書き換えるタイミングは、オーナーシップ獲得のチャンスです。また、如何に、最少人数、最小構成でリスクを伴った意思決定を最速にできるかというのも重要になってきます。 当社のCTOは、チームメンバーが増えた今もリリースされているプルリクを把握してると聞いてますが、脳内LLMのインデックスを更新する作業を自然にやっているのは素直にすごいと思います。普段、プロジェクトに関わってなくてもコードリーディングを通じて、プロダクトに何が起きてるかを把握し続けているわけです。 なお、ChatGPTなどの生成AIなどの取り組みについても触れておきますと、人間の記憶力は揮発性ですし、年齢や体調によっても脳の力の活用度は変わってきます。ただ単に人間の記憶力だけに頼るのは芸がありません。人間としてのスキルだけでなく、検索や生成AIの活用などで外部記憶を効率よく人間の脳内LLMと連結することができれば、とても生産的なAIに対する向き合い方もできると思います。プロンプトに仕様を書いてコード生成されるだけのAIの利用はイマイチだと思っていますが、人間の理解や意思決定を支援するAIというのであれば歓迎です。開発エディタへのAI支援機能の搭載やNotion AIの活用など開発環境も進化していきますから、AIに対する老害にならず、しっかり取り入れていきましょう。 マネージャが意識しないといけないこと マネジメントラインにおいても、現実的に中途採用、転職、社員、業務委託などの属性を考えて、かつ、エンジニアの成長曲線とグレード評価に必要な時間などを勘案すると、現状の我々が構成しうる、チームメンバーのグレード構成の布陣というのは、一定の範囲を取るはずです。 要は退職が増えて、代わりに入っていただいた新人が増えれば、コードの知識、ドメイン知識がないのは当然だから、学びのリードタイムが必要になり、その時点のチームの人材ポートフォリオは弱くなるでしょうし、経験者が長く働いてスキルが向上していけば、給与もあがって、チームメンバーのグレード構成も高いからこそ、高い生産性で開発プロジェクトをこなしていけるというのは、自分で書いても実感のあるところもあります。 つまり開発生産性の高みを目指すというのは、チームマネージャが望む人材ポートフォリオを、状況にあわせて構成することで、高い生産性を発揮できるチームを作ることに邁進することそのものではないかと思いました。新規事業やM&Aなどでも組織が拡張されていくので動的な概念です。常にチームはアメーバのように分裂したりして増加減可能なことが大前提です。BASEグループのカルチャーが組織の増加スピードと人員移動に対して適切に平準化したりお互いに相乗効果を生み出し続けることも大事です。 マネージャは自分を城を作るという考え方ではなく、会社全体の開発力を上げて、よいアウトプットを生み出す状況を作り続けるのが仕事です。その際にチャンスを得て適切にソフトウエアエンジニアとしての信頼を評価に結びつけていくためにも、メンバーと日常のコミュニケーションを取ってほしいと思います。 人間は機械じゃないので、安定したアウトプット量を出すことでさえ大変だと思いますが、生成AIがどれだけ進化したとしても最後の決断は人間が下し続けると思いますので、最適、最速な意思決定をして、適切なリスクにチャレンジするためにメンバーのスキルを上げ続けることになると思います。ちなみに、適切なリスクとは「基本は無茶をする」です。意思決定の際に無難な方と無茶な方の２つの選択肢があったとしたら、無茶をした側の意思決定じゃないと、プロダクトは成功しないです。でも、できないことを部下にやらせるわけにはいかないと思いますので、ちゃんと実現できるように頑張ってください。 おわりに なお、開発だけの話を書いているように見えるかもしれませんが、当然、開発プロジェクトは開発チーム、ビジネスチーム、プロダクトマネージャやデザイナーが渾然一体となってスケジュールタイムラインを成すので、すべてのチームにおける考慮は不可欠です。オーナーシップという視点でも、それぞれが、ビジネスのオーナーシップ、プロダクトのオーナーシップ、プロジェクトのオーナーシップ、UXのオーナーシップなどを適切に発揮できているかは最重要な確認事項とも言えます。 特に、各々がリスクを伴った意思決定を増やし、失敗を恐れず、朝令暮改も上等という考え方で、チーム間のトライも増やしてく。そのための心理的安全性の構築などが重要です。 改善においても適切なリスクの取り方、意思決定のあり方、リモートワークとリアルmtgの使い方、会議の質の向上など要素は多岐に渡りますが、トータルで言うサービス開発の生産性を阻害するものを効率化しつつ、それぞれの役割のスキルを向上させていくことで、トライを増やし、アウトプットの総量は増えていくのではないでしょうか。来年はこのことについて、一つ一つ考えていけたらいいなと思っています。 現在、2025年に向けた人員計画を立てている真っ最中ですが、引き続き採用活動をすると思いますので、以下の採用情報ページからマッチする求人があるかを見ていただけると幸いです。 binc.jp 明日のアドベントカレンダーは @Panda_Program さんの「「読書会のジレンマ」を克服する: 成果を生むアクティブラーニング勉強会の実践法」です！お楽しみに！

こんにちは！BASE PRODUCT TEAM BLOG 編集部です。みなさまそろそろ年の瀬ですが、いかがお過ごしでしょうか。 今年も恒例のBASEメンバーによるアドベントカレンダーを開催します！ 毎年公開しているアドベントカレンダーも今年で7回目を迎えます。 過去の様子 2023年のアドベントカレンダー 2022年のアドベントカレンダー 2021年のアドベントカレンダー 2020年のアドベントカレンダー 2019年のアドベントカレンダー 2018年のアドベントカレンダー 今年も1日1記事に限定せずたくさんのバラエティ豊かな記事を公開する予定です。 公開され次第以下のカレンダーも随時更新していきますので、ぜひお楽しみに！ 日付 執筆者 タイトル 12/1 @fshin2000 プロダクトの開発生産性について考える 12/2 ＠Panda_Program 「読書会のジレンマ」を克服する: 成果を生むアクティブラーニング勉強会の実践法 12/3 @zan_sakurai Terraform Provider for HatenaBlog Members を使ってみました。 12/4 @ikechen 若手エンジニアが BASE 入社 6 ヶ月目で感じていること 12/5 @ohiro88 【入社エントリー】BASE に入社して 2 ヶ月を振り返る 12/6 asakoya 妊娠・出産・育休を経て Hopeful に働いている話 12/7 Torata 整理整頓のメソッドでお問い合わせ業務の改善をした話 12/8 @yuna_miyaa チーム開発を進めるために意識していること 12/9 @kondo プロジェクトを成功させるための工夫 12/10 @ykagano カート開発を加速させる！効率的なドキュメント管理術 12/11 @gatchan0807 技術目線でみた、PAY.JP YELL BANKのおもしろいところをご紹介！ 12/12 @kitamuran Pay IDメンバーの個性がひかる お仕事環境紹介 12/12 @yusuke.saito 私のキャリアチェンジ：データ分析者からプロダクトマネージャーへ 12/13 @roothybrid7 Pay IDシステム移管プロジェクトの技術スタックの紹介 12/14 tac_tanden SLI/SLOの設定を進めるその前に、アラート品質の改善に取り組んだ話 12/14 @toshi-oliver 輪読会「ドメイン駆動設計をはじめよう」をプロジェクトチームで開催した話 12/15 @miyachin_87 Notion FormとAutomationを使って定型タスクの自動生成ツールを作ってみた 12/16 uenoka レポートシステムの安定稼働に向けた取り組み 12/16 @ysssssss98 ペアプログラミングの体験がすごく良かったので布教したい 12/17 @eijenson Jetpack Compose上でのconstraintLayoutの利用事例紹介 12/18 @meihei PhpStorm で PHPUnit をずっと実行している話 12/18 gonzaresu108 INFORMATION_SCHEMAを用いたBigQueryデータ監視 12/19 @ichi アジャイル組織のデザイナーがやってきたチームビルディングの話 12/19 kaneko20 Pay ID 3回あと払いの開発をきっかけに知る住所の味わい深さ 12/20 @gimupop 登壇やアウトプットを後押しするnote 12/20 noji_ma Next.jsのServer Actionとreact-hook-formでフォームを実装した 12/21 basems (仮)エンジニアと非エンジニアで足並み揃える PJ 進行 12/21 kuma プロダクトマネージャーは 「面白がり力」があると良い 12/22 bun タイトル未定 12/22 @zan_sakurai 今年の記事をふりかえってみた 12/23 @endu PHP Conference Japan 2024 に参加しました! 12/23 shotakeuchi 不均衡データにおけるROC曲線とPR曲線について 12/24 @simezi9 今、リモートワークについて思うこと 12/24 @u_hayato13 統括マネージャー(EM of EM)の仕事7選 12/25 dmnlk タイトル未定

はじめに こんにちは、Pay IDのフロントエンドエンジニアのnojiです。 普段はPay ID あと払いやPay IDのアカウント周りのフロントエンド開発を担当しています。 10月に Pay IDのアカウント編集画面 （ こちら ）をリニューアルしました。この記事では、そのリニューアルプロジェクトでNext.jsのApp Router / Server Actionを活用し、便利だと感じた点をご紹介します。 使用技術 Next.js 14（リリース当時のもの。現在は15になっています） React 18（リリース当時のもの。現在は19になっています） リニューアルの背景 今回のリニューアルは、PAY社が保有する「Pay ID」のデータおよびシステムをBASE社へ移管・再構築するプロジェクトの一環でした。 単なる移管に留まらず、デザインリニューアルを伴うため、PAY社で使用されていたVue.jsのコードは再利用せず、Next.jsでゼロから構築しました。 Next.jsを選定した理由： BASE社内での採用実績があり、安心して使用できること。 BASE以外でも採用事例が多かったり、近年のfrontendのトレンドをリードしていること また、新規アプリケーションの構築であることから、Next.jsのApp Routerを採用しました。（開発着手当初はNext.jsバージョン13でした） App Routerの活用 App Routerはディレクトリ構造がそのままURLパスとして反映されるほか、ファイル名によって役割が明確になる点が特徴です。 /app/〇〇 └ layout.tsx // pageをラップした共通画面(画面遷移で再レンダリングされない) └ template.tsx // pageをラップした共通画面(画面遷移で再レンダリングされる) └ error.tsx // エラー時の画面 └ loading.tsx // ローディング中の画面 └ not-found.tsx // notFound()がthrowされたときの画面 └ page.tsx // 実際のURLに対応するページ これをもとに以下のようなツリー構造で描画が行われます <Layout> < Template > < ErrorBoundary fallback = { < Error /> } > < Suspense fallback = { < Loading /> } > < ErrorBoundary fallback = { < NotFound /> } > < Page /> </ ErrorBoundary > </ Suspense > </ ErrorBoundary > </ Template > </Layout> 親ディレクトリのLayoutを子ページが自動的に引き継ぐため、レイアウト部分を共通化しやすいのが便利でした。 https://nextjs.org/docs/app/building-your-application/routing Route Groups 一方で、「URL階層は親子関係があるがレイアウトを切り替えたい」というケースでは、 Route Groups を活用しました。 Route Groupsはディレクトリ名を () で括ることで利用できます。 (a) └ hoge └ layout.tsx ← レイアウトA └ page.tsx (b) └ hoge └ layout.tsx ← レイアウトB └ fuga └ page.tsx /hoge ではレイアウトAを利用 /hoge/fuga ではレイアウトBを利用 このように適切にレイアウトを切り替えられるのが便利でした。 https://nextjs.org/docs/app/building-your-application/routing/route-groups Parallel Route 管理画面では、ダッシュボードのように 複数の情報を1ページに集約して表示 することが多く、特定のページで Parallel Routes を利用しました。 app └ @parallel └ hoge └ page.tsx // A情報 └ default.tsx └ default.tsx └ hoge └ page.tsx // B情報 @ で始まるディレクトリがslotとなり、同じ階層にある layout.tsx でpropsとして受け取ります。 default.tsxは初期読み込み時やページ全体の再読込中に一致しないスロットのフォールバックとしてレンダリングするファイルを定義しています。 何も表示させない場合はnullを返却するように定義しておきます。 // layout.tsx export default async function Layout ( { children , parallel , } : { children : React.ReactNode ; parallel : React.ReactNode ; } ) { return ( <> { parallel } // A情報 { children } // B情報 </> ); } この仕組みを利用し、A情報とB情報をそれぞれ別のページとして描画し、以下のように表示しました： /app/@parallel/hoge/page.tsx → A情報を表示 /app/hoge/page.tsx → B情報を表示 Parallel Routesの利用により、slotに分割されていることで各ページでの処理が少なくなったり、コードの可読性が上がるように感じました。 Parallel routeでもloading.tsxやerror.tsxを配置しておくだけでローディング処理やErrorBoundaryを利用できるので便利に感じました。片方エラーだったときのハンドリング等しやすい印象を受けました。 しかし、soft navigation時に前のParallelRouteのページが表示されたままの状態になることがあり、Client Componentでラップして、pathを見て出し分けするようにし、意図せず表示が残ってしまうことを防いでいます。 // MatchPathRenderer.tsx 'use client' ; export default function MatchPathnameRenderer ( { matches , children } : Props ) { const pathname = usePathname(); if (!matches || !matches. includes (pathname)) { return null ; } return <> { children } </> ; } // layout.tsx ... < MatchPathnameRenderer matches = { [ '/hoge' ] } > { parallel } </ MatchPathnameRenderer > { children } ... https://nextjs.org/docs/app/building-your-application/routing/parallel-routes Server Component / Server Actionの活用 Server側でのデータ処理周り 各Server Componentからサーバー側で非同期にデータフェッチが可能となり、データ管理が効率的に行えるようになりました。また、同じデータのフェッチ処理は自動的にキャッシュされるため、パフォーマンスへの影響も最小限に抑えられます。 さらに、App Routerの Suspense 処理(loading.tsx)を活用することで、サーバーから先にHTMLを返却し、高いユーザー体験を簡単に実現できるようになりました。 サーバー側で動作するため、機密情報やセキュリティに関わるデータも安全に取り扱うことが可能です。 クライアントからサーバーへのリクエスト周り 従来、クライアントからNext.jsのサーバーへリクエストを送る際には、 API Route を定義し、それを通じてAPIを実行する必要がありましたが、 Server Action を使用することで、クライアント側から直接サーバー側の関数を呼び出せるようになり、非常に便利に感じました。 // server action処理 'use server' ; export const action = async ( prevState : any , formData : FormData ) => { // server側処理 } // フォームコンポーネント 'use client' ; export default function Form () { const [ state , formAction ] = useFormState(action); return ( < form action = { formAction } > ... </ form > ) } https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations リダイレクト周り アカウント管理画面では、認証が必須のため、各URLで適切なリダイレクト処理が必要だったのですが、 Server Component や Server Action 内で redirect を利用することができます。 Server Component内でのリダイレクトはPage RouterでのgetServerSidePropsと似たような処理が実現できます。Server Component内にリダイレクト処理が書けるようになった部分は少し可読性が上がったように感じました。 // Server Component内 export default async function Page () { const session = await getSession(); // セッション取得処理 if (!session) { return redirect( '/login' ); } const { response , error } = getData(session); // データ取得処理 if (error. status === 401 ) { return redirect( '/login' ); } ... } Server Action内のリダイレクト処理については以前だとAPI Routeでクライアントにレスポンスを返してからその結果を見てページ遷移を行っていましたが、サーバー側で処理を完結させることができるため、リダイレクト先のページ表示が高速化されました。 // Server Action内 'use server' ; export const action = ( formData : FormData ) => { const session = await getSession(); // セッション取得処理 if (!session) { return redirect( '/login' ); } // API callなどサーバー処理 return { message : '成功しました' } ; } ; https://nextjs.org/docs/app/building-your-application/routing/redirecting キャッシュ周り Server Action でサーバーサイドの処理を実行した後、クライアントの情報（キャッシュ含む）を更新する際に revalidatePath を利用しました。クライアント側でレスポンスを受け取り、値に基づいてUIを更新したり、 router.push や router.refresh で明示的にページを遷移させる必要がなくなりました。 'use server' ; export const action = ( formData : FormData ) => { // API callなどサーバー処理 revalidatePath( '/hoge' ); return { message : '成功しました' } ; } ; https://nextjs.org/docs/app/building-your-application/caching#revalidatepath おわりに システムリニューアル時にNext.jsのapp router / server actionsを触ってみて便利だった部分を紹介させていただきました。 これからNext.jsを利用するプロジェクトの参考になれば幸いです 現在Pay IDではエンジニアを募集しているので、興味のある方は気軽にご応募ください。

はじめに こんにちは。BASE株式会社 Pay IDでiOSアプリエンジニアをしている kakkki です。 iOS版のPay ID ショッピングアプリ の開発を担当しています。 iOS版Pay IDアプリ(以下Pay IDアプリ)はリリースされてから9年以上、新機能開発を行いながら継続的に運用されています。普段の業務では機能開発を進める一方で、マルチモジュール化やStrict Concurrency対応、SwiftUIへの移行など継続的に技術的な改善に取り組んでいます。 Pay IDアプリ内に古くから存在する画面の多くはUIKitベースで実装されていますが、最近はSwiftUIで実装された画面が増えていくようになりました。そこで本記事では、 SwiftUIを導入する過程で直面した課題や取り組みについて 、約2年前から今日に至るまでの画面実装方針の変遷を3つのフェーズに分けながら紹介していきます。 特に長期間運用されているUIKitベースのアプリにSwiftUIを導入したいと考えているiOSエンジニアの皆様にとって、少しでも参考になれば幸いです。 フェーズ1 (2022年10月頃): Compositional Layouts × Diffable Data Source この時点では、複雑なレイアウトやデータ管理を効率化するためにiOS13から導入されたCompositional LayoutsとDiffable Data Sourceを採用していました。Compositional Layoutsにより、複雑なレイアウトでもセクションごとに設定できるようになりレイアウト実装の柔軟性が高まりました。また、Diffable Data Sourceによりデータの変更を即座にUIに反映できるようになり、データとUIの統一的な管理が可能となりました。 しかし、この時点ではSwiftUIは全く導入しておらずUIKitのみでの開発でした。UIKitは今でもバリバリ現役ですが、SwiftUIと比べてUI実装の速度が劣るケースもあり、後々開発効率などの観点からSwiftUIを導入していきたいという気持ちが強くなっていきました。 フェーズ2 (2023年10月頃): Compositional Layouts × Diffable Data Source × SwiftUI（UIHostingConfiguration） 次のステップとして、SwiftUIを小さくコンポーネント実装に留める形で導入していくことを試みました。 この時点では以下の図のようなイメージです。 具体的には、 UICollectionViewCell 内でSwiftUIを利用する方法です。以下のような UICollectionViewCell の共通実装を用意して、iOS16以上では UIHostingConfiguration 、iOS15では UIHostingController 経由でセル内のUIをSwiftUIで実装していくようになりました。 /// HostingCellの中身となるViewが準拠するプロトコル public protocol HostingCellContent : View { associatedtype Dependency init (_ dependency : Dependency ) } open class HostingCell < Content : HostingCellContent >: UICollectionViewCell { // TODO : iOS15サポートを切ったら削除する private let hostingController = UIHostingController < Content? > (rootView : nil ) override public init (frame : CGRect ) { super . init (frame : frame ) // TODO : iOS15サポートを切ったら削除する hostingController.view.backgroundColor = .clear hostingController.view.translatesAutoresizingMaskIntoConstraints = false } @available ( * , unavailable ) public required init ?(coder : NSCoder ) { fatalError( "init(coder:) has not been implemented" ) } public func configure (_ dependency : Content.Dependency , parent : UIViewController? = nil ) { if #available(iOS 16.0 , * ) { configureWithHostingConfiguration(dependency) } else { configureWithHostingVC(dependency, parent : parent ) } } /// iOS16以上ではUIHostingConfigurationを使う func configureWithHostingConfiguration (_ dependency : Content.Dependency ) { if #available(iOS 16.0 , * ) { contentConfiguration = UIHostingConfiguration { Content(dependency) } // デフォルトでマージンが設定されているので0にする .margins(.all, 0 ) } } // TODO : iOS15サポートを切ったら削除する /// iOS15以下ではUIHostingControllerを使う func configureWithHostingVC (_ dependency : Content.Dependency , parent : UIViewController? ) { guard let parent else { return } hostingController.rootView = Content(dependency) hostingController.view.invalidateIntrinsicContentSize() guard hostingController.parent == nil else { return } parent.addChild(hostingController) contentView.addSubview(hostingController.view) NSLayoutConstraint.activate([ hostingController.view.leadingAnchor.constraint(equalTo : contentView.leadingAnchor ), hostingController.view.topAnchor.constraint(equalTo : contentView.topAnchor ), hostingController.view.trailingAnchor.constraint(equalTo : contentView.trailingAnchor ), hostingController.view.bottomAnchor.constraint(equalTo : contentView.bottomAnchor ), ]) hostingController.didMove(toParent : parent ) } } セルの呼び出し側はセルの中身がどのように実装されてるかを知る必要はなく、従来の UICollectionViewCell を用いた開発と同様に実装することができました。この取り組みにより、セル内のUIをSwiftUIで宣言的に記述できるようになり、UI構築の開発速度が向上しました。 フェーズ2のSwiftUI導入時に直面した課題 しかし、フェーズ2の UICollectionViewCell 内にSwiftUIを埋め込む実装の方法だと、いくつかの課題に直面しました。 特に以下の要件を満たすために、実装が複雑化しやすいことが分かりました。 お気に入り状態を更新する際に、APIの結果を待たずに一時的にUIに反映したい ユーザーによるデータ更新操作およびUIへの反映処理が頻繁にある これらの要件を実現する過程で、次のような問題が浮かび上がりました。 @State による状態管理が可能なケースが限定される UIHostingConfiguration 内でSwiftUIビューを使用する際、 @State プロパティを外部から初期化すると問題が発生していました。具体的には、外部から渡された値で @State を初期化すると、セルの再利用時に状態がリセットされず、データの不整合が発生することがありました。 以下は簡略化したコード例です。 struct ItemView : View { @State private var isFavorite : Bool init (_ isFavorite : Bool ) { // 外部から渡された値で@Stateを初期化 _isFavorite = State(initialValue : isFavorite ) } var body : some View { // ... } } UICollectionViewCell 内でこの ItemView を使用すると、セルの再利用時に ItemView の init が再度呼ばれますが、 @State の値は初期化されず以前の状態を保持します。そのため、表示とデータの不整合が生じ、意図しないUIの挙動になります。 また、以下のようにSwiftUI内部で isFavorite を更新した際も、同様にUIに正しいデータが反映されないことがありました。 struct ItemView : View { @State private var isFavorite : Bool init (_ isFavorite : Bool ) { // 外部から渡された値で@Stateを初期化 _isFavorite = State(initialValue : isFavorite ) } var body : some View { Button(action : { // お気に入り更新APIを呼ぶ前に、スムーズにUIが更新できるように一時的に更新する isFavorite.toggle() // お気に入り更新APIをコール }) { // ... } } } これらの問題の原因は、 @State がSwiftUIのビューのライフサイクルに基づいて状態を管理するため、外部からの初期化と相性が悪いことにあります 。WWDC22にある Use SwiftUI with UIKit のセッションでは、以下のようにSwiftUIの外で保持されるデータを使用する際は @State , @StateObject といったプロパティラッパーは使うべきでないという言及がされています。 To store data that is created and owned by a SwiftUI view, SwiftUI provides the @State and @StateObject property wrappers. Since we're focused on data owned outside of SwiftUI, these property wrappers aren't the right choice. 引用: Use SwiftUI with UIKit (値を利用する箇所がSwiftUIの中に閉じているケースでは、 UIHostingConfiguration の中のSwiftUIで @State を利用しても期待通り動きます。) 当時、Pay IDアプリ内の多くの画面はMVPアーキテクチャで構成されていました。Presenterを知っているのは UIViewController のみです。つまりSwiftUIの外でデータを保持する構成にしていた以上、大半のケースでは @State を使用することはできませんでした。 SwiftUIビュー内で発生したイベント伝搬とデータ更新伝達の複雑化 セル内のSwiftUIビューでユーザーアクションが発生すると、それをPresenterに伝える必要があります。するとコールバックやデリゲートなど、なんらかの形でUIViewControllerを経由しないといけません。 // イメージ図(諸々簡略化して書いています) アプリユーザー ↓ ユーザーアクション(お気に入りボタンをタップなど) SwiftUI.View ( in UICollectionViewCell) ↓ ユーザーアクションの伝達 UIViewController ↓ ユーザーアクションの伝達 Presenter ↓ APIリクエストなどのハンドリング さらに、Presenterの処理の結果何かしらSwiftUI.Viewの中の表示を変える場合、Presenterの結果をまたSwiftUIビューに伝えないといけません。当然Presenterは直接SwiftUIビューを知ることはありません。そこで以下のようなフローでデータ更新を伝搬することになります。 // イメージ図 Presenter ↓ データ更新の伝達 UIViewController ↓ データ更新の伝達 SwiftUI.View ( in UICollectionViewCell) ↓ UIを更新 つなげるとこのようなフローになります。 // イメージ図 アプリユーザー ↓ ユーザーアクション(お気に入りボタンをタップなど) SwiftUI.View ( in UICollectionViewCell) ↓ ユーザーアクションの伝達 UIViewController ↓ ユーザーアクションの伝達 Presenter ↓ APIリクエストなどのハンドリング ↓ データ更新の伝達 UIViewController ↓ データ更新の伝達 SwiftUI.View ( in UICollectionViewCell) ↓ UIを更新 もちろんこのフローでもアプリを要件通り実装することは可能です。ですが、SwiftUIでUIを書いているとSwiftUIで実現しやすいデータバインディングの機構を取り入れて、上記のようなフローをよりシンプルにしたいと思うようになっていきました。 フェーズ3 (2024年7月頃): SwiftUI × Observationフレームワーク フェーズ2の UICollectionViewCell 内に埋め込む形でSwiftUIを導入した際に出てきた課題を解決するため、よりSwiftUIベースな実装方針を目指すことを決めました。ここでの構成が、現在新しい画面を実装する時に積極的に取り入れている形です。 SwiftUIとUIKit間の責務分離と整理 まず、状態管理とビジネスロジックをSwiftUI内部で完結させる実装方針に転換しました。また、レイアウトも今まではUIKit(Compositional Layouts)で実装していましたが、この部分もSwiftUIで実装するように変更しました。 UIKitは主に画面遷移を担当します。ナビゲーションバーなど一部UIを担当することもありますが、API通信などのデータ取得もSwiftUI内部(ViewもしくはViewが保持するViewModel)からRepositoryを参照するようになり、SwiftUIとUIKit間のデリゲート処理もかなり減りました。それによりビュー内で発生したイベント伝搬・データ更新の複雑だったフローの見通しも改善されました。 View+コンポーネントは、言わずもがなSwiftUIです。View+画面遷移の部分は、引き続きUIKit(UINavigationController)で行います。View+レイアウトについては、UIHostingControllerを利用してUIViewControllerにSwiftUIで書いたレイアウト実装を埋め込んでいます。 そしてView+ロジック・状態管理については、Swift5.9, iOS17以上で利用できるObservationフレームワークを導入することにしました。 PerceptionによるObservationフレームワークの導入 しかし、Pay IDアプリはまだiOS16.2以上をサポートしています。そこで Point-Free が公開してくれている、Observation相当のバックポート実装を提供してくれる swift-perception を利用します。swift-perception(以下Perception)ライブラリはiOS17以上であればObservationフレームワークのAPI(withObservationTracking)を呼び出し、iOS17未満ならObservationフレームワークの挙動を模倣した実装が呼ばれます。 SwiftUI上の状態管理において、Perception経由でObservationを導入するか、Combine製のObservableObjectプロトコルを利用するか悩みましたが、ObservableObjectよりもObservationの方が以下の点から使い勝手が良いと判断しました。 子ビューの差分更新において不要に親ビューの差分更新が走らない 値(クラス)を入れ子にした場合、ネストしたクラスの値の変更を検知できる Perceptionを利用する場合、追跡したい値を保持するオブジェクトを @Perceptible クラスとして宣言します。そして @Perceptible クラスへのアクセスを持つViewを WithPerceptionTracking Viewでラップします。 import Perception struct HogeScreen : View { let viewModel = HogeViewModel() var body : some View { // WithPerceptionTrackingで囲む必要がある // TODO : iOS16切ったらWithPerceptionTrackingラップを外すだけでいい WithPerceptionTracking { VStack { Text(viewModel.count) Button( "Increment" ) { viewModel.increment() } // ... } } } } @Perceptible // TODO : iOS16切ったら@Observableに変更する @MainActor final class HogeViewModel { var count = 0 func increment () { count += 1 } // ... } // UIHostingControllerでSwiftUI.ViewをUIViewControllerの中身として埋め込む final class HogeViewController : UIViewController { override func viewDidLoad () { super .viewDidLoad() let vc = UIHostingController(rootView : HogeScreen ()) self .addChild(vc) self .view.addSubview(vc.view) vc.didMove(toParent : self ) vc.view.translatesAutoresizingMaskIntoConstraints = false vc.view.topAnchor.constraint(equalTo : view.topAnchor , constant : 0 ).isActive = true vc.view.leftAnchor.constraint(equalTo : view.leftAnchor , constant : 0 ).isActive = true vc.view.rightAnchor.constraint(equalTo : view.rightAnchor , constant : 0 ).isActive = true vc.view.bottomAnchor.constraint(equalTo : view.bottomAnchor , constant : 0 ).isActive = true // ... } } このようにSwiftUI上のデータバインディングが可能になったおかげで、データの変更が発生した際に @Perceptible クラスの値を更新するだけで済み、UIへの反映がとても楽になりました。 Perception利用時の注意点 Perceptionを使う上で特に重要な注意点の一つとして、 ForEach などViewを返すクロージャーの中で @Perceptible な値を参照する場合は、クロージャーの中でも別途 WithPerceptionTracking で囲む必要があります。囲っていないと、値の更新があってもクロージャー内のViewには反映されません。 struct HogeScreen : View { let viewModel = HogeViewModel() var body : some View { WithPerceptionTracking { ForEach(Array(hogeViewModel.items.enumerated()), id : \\.offset) { index, item in // WithPerceptionTracking { // ❌ hogeViewModel.itemsの一部のnameが更新されても変更を追跡できていない Text(item.name) // } } } } } @Perceptible final class HogeViewModel { /* ... */ } その理由は、 ForEach のクロージャーがViewのbody本体と同じタイミングで呼び出されるわけでなく、Viewのbody本体が呼び出された後に ForEach クロージャーが呼ばれることにあります。そのため ForEach 自体を囲った WithPerceptionTracking の中には ForEach クロージャーの中身のViewは含まれていないので、 @Perceptible のプロパティを追跡するためのViewの登録処理が動いていないのです。 以下のように、ForEachクロージャーの中もWithPerceptionTracking囲っていれば追跡可能です。 struct HogeScreen : View { let viewModel = HogeViewModel() var body : some View { WithPerceptionTracking { ForEach(Array(hogeViewModel.items.enumerated()), id : \\.offset) { index, item in // ForEachのクロージャーの中もWithPerceptionTrackingで囲ってるので、 // 値の変更を追跡できてる // ⭕️ WithPerceptionTracking { Text(item.name) } } } } } @Perceptible final class HogeViewModel { /* ... */ } また、自作のViewにViewBuilderを渡す際も注意が必要です。 以下のコードだと、CustomContainerに渡すViewBuilderの中身が WithPerceptionTracking で囲まれていません。body本体が呼び出されるタイミングではViewBuilderの中はまだ呼び出されてないので、 Text(hogeViewModel.count) の箇所はbody直下の WithPerceptionTracking の範囲外になってしまいます。 // ViewBuilderを渡す側 struct ContentView : View { let hogeViewModel = HogeViewModel() var body : some View { WithPerceptionTracking { CustomContainer(title : "Custom Container" ) { // ViewBuilderの中身 Text(hogeViewModel.count) } } } } // ViewBuilderを受け取る側 struct CustomContainer < Content : View >: View { let title : String let content : () -> Content init (title : String , @ViewBuilder content : @escaping () -> Content ) { self .title = title self .content = content } var body : some View { VStack() { Text(title) content() .padding() } } } @Perceptible final class HogeViewModel { /* ... */ } なので先ほどと同様に、ViewBuilderの中身もWithPerceptionTrackingで囲む必要があります。 // ViewBuilderを渡す親View struct ContentView : View { let hogeViewModel : HogeViewModel var body : some View { WithPerceptionTracking { CustomContainer(title : "Custom Container" ) { // ViewBuilderの中身をWithPerceptionTrackingで囲む WithPerceptionTracking { Text(hogeVieModel.count) } } } } } おわりに 本記事では、古くからあるUIKitベースのiOSアプリにおいてSwiftUIを導入する過程で直面した課題や取り組みについて紹介させていただきました。 前述した通り現在のPay IDアプリのサポートバージョンはiOS 16.2以上であり、次回のサポートバージョン整理のタイミングでiOS17以上のサポートとする可能性があります。その時はPerceptionから純粋なObservationへの移行もあるので、その取り組みの中で新たな気づきがあればまたどこかで紹介させていただければと思います。 また、新規実装はもちろんのこと、古いUIKitベースの画面に対してSwiftUIベースな実装方針に基づいてリアーキテクチャなどもチームで進めていきたいと思います。 最後になりますが、Pay IDでは随時メンバーを募集しています。ご興味のある方は気軽にご応募ください！ open.talentio.com

はじめに はじめましての人ははじめまして、こんにちは！ 先週木曜日ぶり です！BASE BANK Division（以下、BANKチーム）のフロントエンドエンジニアのがっちゃん（  @gatchan0807  ）です。 今回は 11/23（土） に開催された 「Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima」にスポンサリング・スポンサートークをしました！というご報告記事になります！ スポンサリングしたイベントについて 今回スポンサリングしたイベントは「Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima」というイベントで、スナック・ドリンクスポンサーの枠でスポンサリング・参加しました🙋 また、合わせてスポンサートークもさせていただきました！（詳細は後述） devx.jp DevX / Raycast Community Japan さんと 一般社団法人シンギュラリティ・ソサエティ さんの共催のイベントで、Fullstack AI Devの名前も冠している通り、AIを使った生産性向上、価値のあるプロダクトの提供に関心が強い方々の発表をたくさん聞くことができました！ また、Raycast Summitの名前も冠している通り、Raycastを使った便利な機能をはじめ、Raycast Proで使えるAI機能の紹介などなど「えっ、明日からRaycastもっと使いこなしたい！」となる発表や知見をたくさんお聞きすることができました！ スタッフの皆さん、登壇者の皆さんをはじめ、たくさんの方のご尽力のおかげでこのイベントが実施できたのだと感じています。このような素敵なイベントにスポンサーという形で関わらせていただきまして、本当にありがとうございました！ この場を借りて感謝をお伝えできればと思います！ スポンサートークでお話しした内容について 今回のスポンサートークでは、SLM（Small Language Model）の一つ、Gemini NanoがChromeブラウザに搭載されるようになり、どんなことに使えるのかについて、お話をさせていただきました！ 久しぶりのオフライン登壇で緊張しながら発表していた時の図 オンラインでも配信されており、100数十名に見ていただいていた時の図 登壇資料に関してはDocswellにて公開していますので、ぜひ合わせてご覧いただけますと幸いです！ www.docswell.com おわりに 以上、BASE BANKチームとして、「Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima」に協賛させていただきました！というご報告でした！ 今回のイベントはBASE BANKチームとして「エンジニアイベントに協賛させてください！」という発信を見てお声がけいただいたものでして、引き続きBASE BANKチームとしては規模に関わらずエンジニアイベント・コミュニティイベントにスポンサーとしてご協力させていただきたいと思っております！ 詳細は以下の記事にまとまっていますので、もしご興味あればぜひご覧ください！ devblog.thebase.in （私個人としてはスポンサートークの他、どんどん登壇もやっていきたいので、もし この辺りに書かれている発表内容 にピンとくるものがあればぜひご連絡ください！という宣伝もこっそりと…） また、BASE BANKチームはエンジニアをはじめ、各職種を大募集中ですので、もしご興味あればお気軽にカジュアル面談やXなどでお声がけください！ binc.jp

はじめに はじめましての人ははじめまして、こんにちは！BASE BANK Division（以下、BANKチーム）のフロントエンドエンジニアのがっちゃん（  @gatchan0807  ）です。 今回はBANKチームの中で職種横断で行っている「月次会」というLT会について紹介させてください！ この月次会（LT会）を毎月実施していることで、チームにとってどんなメリットがあるのか？や、実施における工夫を知っていただき、皆さんのチームでもスモールスタートで実施してみていただけるととっても嬉しいなと思っています！ また、今回は記事のタイトルの通り、その月次会で半年間（実際には2月~10月の計8回）、毎月様々なお題でLTをしたので、ついでにその内容とそこから得た知見もすこし紹介させてください！ もし、開催予定の技術イベントのテーマで合致しそうなタイトルがあれば X などで気軽にお声がけいただけると嬉しいです！ そもそも月次会とは？ 2022年11月からBANKチームで開始され、開始当時から以下のような想いと目的で実施されきたものです。 （この時期は僕はまだBANKチームにはおらず、BASE側のCRM機能の改善をしていたりしました） 社内のNotionには以下のように月次会についてまとまったポータルが誰でも見られる場所に設置されており、事業責任者の柳川（ @gimupop ）さんが目的を言語化して書いてくれていたり、ここに資料へのリンクがまとまったNotion DBが設置されていたりします。 この会に関しての情報がまとまったNotionページのキャプチャの一部 （BANKチームでのこの取り組みの前進になった「Product BEER BASH」という社内イベントとそれに対する柳川さんのアツい思いは以下のnoteにまとまって公開されているので、ぜひこちらもご覧ください。 👉 https://note.com/gimupop/n/nb950488d8de8 ） 月次会自体は上記Notionにも書かれているように 「自己開示」と「アウトプットをすることによるPDCAの体現」 を目的として実施されています。 そのため、発表する内容は仕事に関係していなくてもよく、フォーマットも自由（スライドを作ってもいいし、Lookerダッシュボードを見せながらでもいいし、Notionを上から説明していく形でも良い）なので、それぞれ5~10分間でかなり自由に発表しています。 今年からは会の運用を 「ローテーションのメイン枠（発表10分+感想・質問5分）× 4~6人」 「任意発表者枠（発表5分のみ）× 1~3人」 という2部構成に変えたので、発表の頻度としてはだいたい3ヶ月に1回、自分の番が来るぐらいのスパンで回っています。 実際に過去にあった発表だと以下のようなものがあります タイトル: 古着の話 古着の分類方法などの基礎知識や、古着屋さんがECに対してどんな課題感を持っているか？という知見の共有など タイトル: 今、恐竜が熱い お子さんがハマり、そこから参加したイベントや恐竜博物館の紹介、直近恐竜のこれまでの常識が変わってきている！という話、さらにはECでこんな商品を出そうかなと考えているアイデアの紹介など タイトル: もっとチームの皆さんとBANKプロダクトユーザーをみていきたい ユーザーインタビューの概要 & ユーザーインタビューとは？の共有など 発表は基本オフラインでみんな聞きながら、Figjamボードに付箋や絵文字、リアクションを貼ってワイワイしています。 発表者側としてはここに感想がたくさん集まっているのを後で見て嬉しい気持ちになれるし、ファシリテーターは非同期に質問や感想が集まっていくので発表後のタイミングで拾ったりしやすいというメリットがあります 🙌 gatchan0807がこの会を見てきて感じたこと BANKチームではこんな感じの会を毎月実施しており、2023年11月（ちょうど1年前）に異動して毎月参加してきて感じたことをざっくり書いておきます。 今の組織フェーズには月次会をやることでコミュニケーションが円滑になるなどメリットがたくさんあるなと感じています 🙋 発表起点で「こんなことやりたい」などを 異なる職種（アナリスト）の人に相談するきっかけになってよかった チームメンバーのパーソナリティを知る機会としてとても活用できる 入社時の自己紹介をしっかりできる場所 があるのはとても良い。どうしても仕事の中、ランチ・飲み会などで自己紹介できる量には限界があるし、話の流れが合致しないこともあるので… 後から入った人も、 長くいる人のパーソナリティを知る 機会になっている Lookerダッシュボードの場所を知れたり、Slackのどこでやり取りされているのか？のような「そんな情報がそこに眠っていたのか！」という気づきや「そうやってみればいいのね！」という 知識のインデックスが貼れる 発表方式にもPDCAが回っていて、最近はCanvaを使っていい感じのスライドをさくさく作って発表する人も出てきてとても良い 大体発表が3ヶ月に1回ぐらいなので、（任意発表で毎回やるとかしなければ）意外と話すネタは見つけやすい 逆に毎月発表はネタ探しとスライド作り大変だった（自業自得） こんなLTをしました ここからは記事タイトルの回収で、月次会で私がどんなLTをしていたかを紹介させてください。 もし、読者の皆さまのなかで何か琴線に触れるものがあれば、ぜひお話ししましょう！お気軽に X （ @gatchan0807 ）までお声がけください〜！🙌 2024年2月: Chrome DevToolsのススメ 実際に使った「Chrome DevToolsのススメ」のスライドの抜粋 フロントエンドエンジニア必携のChrome DevToolsの便利機能をベースに紹介 プロダクトマネージャー、デザイナーの確認作業を楽にする機能や、ネットワークが遅い場合、色覚特性の場合もかんたんに確認できる機能などを紹介 エンジニア以外の職種の方に「実は悪い人たちはこうやって使ってたりする」というのをイメージしてもらい、セキュリティ意識を高める事例も紹介 例えば、Chrome DevToolsを使うことで画面には出ていないこんなデータが見られる 例えば、Chrome DevToolsを使うことで画面を簡単に書き換えてキャプチャが撮れる 2024年3月: 戦略的自己学習のススメ 実際に使った「戦略的自己学習のススメ」のスライドの抜粋 前月にチームメンバーが「戦略的他者交流のススメ」というタイトルで発表をされていたので、それに関連させて話した内容 自分がどんな目的・考え方で調べ物（自己学習）をしているのかを話す自己開示の発表 コミュニケーションを円滑にするために事前に調べ物をしていること 考え事や調べ物のショートカットや、説明をうまくするために調べ物をしていること 2024年4月: （チーム全体でストレングスファインダーを実施する会になったのでおやすみ） ストレングスファインダーの会について、詳しくはこちらの記事をご覧ください basebook.binc.jp 2024年5月: ぼくのかんがえた さいきょうの じょうほうほぞんじゅつ 実際に使った「ぼくのかんがえた さいきょうの じょうほうほぞんじゅつ」のスライドの抜粋 4月のストレングスファインダーの結果に「収集心」という性格特性がTOP5に入っていることから話すことにしたもの 3月の発表で自己学習の話をしていたので、そこで得た知識をどう蓄えているか？というところにフォーカスした内容 Notion、Google Keepなどを使った知識集積プラットフォーム構築を行った後、最終的にSlackに落ち着いている状態 2024年6月: ここがスゴいよ！JavaScript！ 実際に使った「ここがスゴいよ！JavaScript！」のスライドの抜粋 Arcadeというプロダクトを知り、そのプロダクトがChrome拡張 + Webアプリケーションで完結してプロダクトの価値を作っているのを見て、これを実現するためにはJavaScriptの力をふんだんに使う必要があるんだよ！という話 合わせて、JavaScriptを使ってできることを伝え、エンジニア以外のメンバーにもプログラミングや業務効率改善に興味を持ってもらえるように話した発表 2024年7月: もうすぐ来るオンデバイスLLM（SLM）の未来 実際に使った「もうすぐ来るオンデバイスLLM（SLM）の未来」のスライドの抜粋 2024年11月23日に開催されるイベント（ Fullstack AI Dev & Raycast Summit ）のスポンサーLTの内容の元になった発表 個人的にPWAの頃からChromeブラウザに興味が強いので、Google I/OでGemini nano in Chromeを知ったことから実際に触ってみて、得た知識を話したもの 合わせてGemini nanoがAndroidスマホに、Apple IntelligenceがiPhoneに入ることが話題になっていたので、それらも合わせて言及 これもエンジニア以外にもわかってもらえるようにイメージしやすい言葉を最大限使って発表 2024年8月: あなたの知らない.new ドメインの.世界 実際に使った「あなたの知らない.new ドメインの.世界」のスライドの抜粋 Googleが管理するgTLDの 「.new ドメイン」についての知見共有のための発表 https://docs.new でGoogle Docsの新規ページが作成できることなどを業務Tipsとして話したり 自分たちのサービスで作るならこういうドメインがいいかな？という候補を出したり おまけでNew gTLDで語呂合わせドメインが取れることを話したり、BrandTLDについても共有 2024年9月: Webの未来 / Web「ポータル」の未来 実際に使った「Webの未来 / Web「ポータル」の未来」のスライドの抜粋 expand.aiというプロダクトがY Combinatorから調達し、話題になっているのを社内で見つけ、それについて調べた知識を共有した発表 このプロダクトを調べている時にWeb上の情報ポータルサイトの未来を案じたので「こんな変化が必要な世界になりそう」という私見から話したもの expand.aiがどのように使えるのか？という知識に、前職の経験も組み合わせてポータルのポジションが危うくなりそう…という危機感がメイン サービスを継続提供するためにどんな解決策があるか、どんな価値提供が必要かを（ほぼ妄想ベースで）語ったりしました 2024年10月: 今日から始める生成AI 実際に使った「今日から始める生成AI」の未来」のスライドの抜粋 チームの生成AIの活用度合いをもっと上げたいと思い、生成AIに対してのスタンスを共有し、「ハードルをできる限り下げて使い始めてみよう。」というメッセージの発表 イメージしてもらいやすいように「ドラえもんだと思って使おう」というメッセージを伝えている のび太くんがドラえもんに泣きつくように、どんなことだって一旦相談してみてもいい ドラえもんのように失敗することもあるので、温かい目で失敗を教えてあげよう（完璧を求めすぎない） そこから派生して、ロールプレイプロンプトを使った利用時のテンションの上げ方や、JSONでやりとりする形での精度の改善などのちょっとしたテクニックも紹介 gatchan0807がこれだけ発表してきて思ったこと 月並みな表現にはなってしまうのですが、何より アウトプットを起点にした学習は定着が早いし、モチベーションの維持がとてもしやすいので良い なと思いました…！ また、生成AIに対して個人的な興味は強かったものの、プロダクトとして関わったり仕事として関わる見込みはほぼありませんでした。 ですが、積極的に発信していたことで生成AI関連のイベント（後述）へのスポンサリング + スポンサーLT担当をさせてもらう話が進んだり、実際に生成AIをプロダクトに組み込む方法を考え始めたりと（まだまだ構想・妄想段階）、もともとやりたいと思っていた仕事をやらせてもらえていたのですが、そこに追加して新たに生成AI関連のお仕事が増え、仕事をさらに楽しむ要因にもなりました 👏 チームに対しての知見共有も「わかりやすい！」や「学びがあった！」といったフィードバックや感謝を受け取れてとてもテンションが上がりますし、非常に勝手ながらBANKチームでこの会を一番うまく活用している人間なんじゃないかなと思っていたりします 😎 おわりに 今回はBANKチームの「月次会」という月に1回社内で行っているLT発表会の取り組みを紹介させていただきました。 もし、このような取り組みを行っているBASE / BASE BANKチームにご興味を持っていただけたのであれば、ぜひお気軽にカジュアル面談や X でのお声がけなどをしていただけますととても嬉しいです！ まだまだBASE BANKチームとしては作りたいもの、提供したい価値がたくさんあって、それらを一緒に実現していける仲間を募集しています。ぜひBANKチームにお力をお貸しください 🙇‍♂️🙇‍♂️🙇‍♂️ binc.jp また、合わせて gatchan0807 が半年間、毎月発表した内容も紹介させていただきました。 BANKチームとして、中小規模のエンジニアイベントへの会場提供・飲食スポンサーをやっていく動きもあるので、エンジニアイベントの主催、スタッフの皆さまの中で、もしこういった話にご興味ある方がいらっしゃればお気軽に X などでお声がけいただけますと幸いです！ もしくは、こちらの記事を X などでシェアしていただくのもとってもとっても嬉しいです！ devblog.thebase.in 最後に、記事内でも少し触れましたが 2024年11月23日（土）に実施される以下のイベントにBASE BANKチームがスポンサーをさせていただき、LTもさせていただきますのでぜひオフラインでご参加 or オンラインでご覧いただけると幸いです！ devx.jp

<この記事はHatena-Blog-Workflows-Boilerplateによって作成されました> こんにちは！ BASE株式会社 Pay ID の @zan_sakurai と申します。 BASE PRODUCT TEAM BLOG 編集局メンバーも務めています。(実は今年の編集長です。) 今回は、Hatena-Blog-Workflows-Boilerplateを使ってとあるSaaSのリンクを一括置換した話をします。 Hatena-Blog-Workflows-Boilerplate Hatena-Blog-Workflows-Boilerplateとは、 株式会社はてなさんが公式で公開している、はてなブログの記事を書くためのワークフローのボイラープレートでして、GitHub 上で下書きや記事の公開等を行うことができるものです。 github.com 弊社では昨年 @applepine1125 さんが書いた Hatena-Blog-Workflows-Boilerplateつかって BASEのブログ書いてみた も見ていただけると幸いです。 Hatena-Blog-Workflows-Boilerplate を使って 一括置換してみた 先に結論です。一括置換するまでは3ステップで完了しました! 総記事数約450件のうち、置換対象のリンクが含まれている記事は約100件、差分は約130行ほどでした。(目視で確認&置換していたらゾッとしますね...!) 良い感じに取り込んで(pull from hatenablog) 良い感じに置換して！ 良い感じにpush! 以上です! リンク置換作業の経緯 さすがに少し味気ないので、もう少し詳しく経緯もお伝えしようと思います。 ことのきっかけは、これまで利用していたとあるSaaSを別のSaaSに切り替えることになり、社内ではそのリンクの置換作業が行われている最中でした。 BASE PRODUCT TEAM BLOG に掲載している記事にも多くのそのSaaSのリンクが含まれており、置換作業が必要でした。 (ブログというコンテンツの特性上、過去の記事は更新しない、という判断もありえましたが、読者の皆様の体験を損なわないことを優先し、全て切り替えることとしました。) 最初は「全部記事目視で地道にやってみるか...。」と思っていましたが、量も量でしたし、「なんとかならないかな...。」とぼんやり考えていました。 ぼんやり考えているときと、ふとしたときに前述の @applepine1125 さんが書いた記事を思い出しました。 Hatena-Blog-Workflows-Boilerplate はブログの記事を書くためのワークフローを提供するものですが、 hatena blog上に掲載している記事をpullすることができるので、 それを使って、記事の取り込み(pull) -> 置換 -> push という流れで、リンクの置換作業を行うことができるのではないかと思いました。 ちょっと実験がてらやってみたところ、前述のとおり簡単にリンクの置き換えができました。 使ってみた感想 特定の文字列を一括置換という慣れ親しんだ(?)作業をおこなうだけでしたので、本当に簡単でした。 ブログの執筆の一連のフローを Hatena-Blog-Workflows-Boilerplate のワークフローに移行したいな、と社内でもぼやいていたのですが、 執筆のフローだけでなく、ブログのメンテナンスにも使えることがわかり、ますます今後活用したいと思っています。 また、今回触ってみて感じましたが、執筆だけでなく、メンテナンスや記事を一気に見る、といったことにも活用できるので、企業ではてなブログで技術ブログ等を運営されている方にはぜひ一度お試しいただきたいです。 おわりに Hatena-Blog-Workflows-Boilerplate めちゃくちゃ便利です...!!! open.talentio.com

BASE も Aurora MySQL v3 となりました SRE Groupの ngsw です。 2024/10/14〜10/15の深夜メンテナンスにて、BASEで利用しているAmazon Aurora MySQLのバージョンは、v2系からv3系となりました。 アップグレードの前提条件で大きなつまずきがありましたが、 gh-ost を利用することで、乗り越えることができました。 この記事では当該アップグレードの中で gh-ost をどのように利用し、どういう恩恵を受けたかについて述べていきます。 おさらい : v3 対応しないとどうなるの？ Aurora MySQL v2は標準サポート終了が発表されており、v3への移行を終えていないDBクラスターには自動的に有償の延長サポートが適用される流れです。 Amazon RDS 延長サポートの使用 - Amazon Aurora 2024/10/31 に自動で延長サポート入り 2024/12/01 より延長サポート料金の自動請求が適用される 費用はこちらをご確認ください。そこまで安くありません。 料金 - Amazon Aurora | AWS 有償サポート提供によりある程度の時間猶予が与えられたとはいえ、アップグレードを先延ばしにするメリットはほとんどありません。 たとえば、このアップグレードよりも企業にとって利益のある施策やサービスの開発/改修があればまた別の意思決定が働くでしょうが、そんな施策はそうそうないでしょう。 簡単にアップグレードできない問題 Aurora MySQL v2→v3アップグレード検証段階で問題が見つかりました。 BASEでは本番環境のデータにマスキングをほどこしたものを、開発環境で利用できるようにしています。 このマスキングしたDB Clusterで、以下にあるようなインプレースアップグレードの検証を行いましたが、エラーのためアップグレード処理は停止してしまいました。 Amazon Aurora MySQL バージョン 3（MySQL 8.0 互換）へのアップグレード | Amazon Web Services ブログ 停止理由は upgrade-prechecks.log をみることで確認ができます。 原因となる問題は大きく二つありました。 mysql . event に関するアップグレード時の不整合エラー 多数のテーブルに古いディスクフォーマットで datetime 型カラムが作成されていたためのエラー mysql . event に関するアップグレード時の不整合エラー AWS サポートにより対応いただけました。 こちらは数日程度で解決でき、検証作業をブロックするほどの問題ではありませんでした。 多数のテーブルに古いディスクフォーマットで datetime 型カラムが作成されていたためのエラー 問題はこちらのエラーです。 MySQL :: MySQL 8.0: Removing support for old temporal datatypes 解決方法が「当該カラムを持つテーブルを新しく再作成する」ということになり、 Dump & Restoreする ALTER TABLE {table_name} FORCE; というような、つまりv2上で CREATE TABLE 相当のことを行う必要がありました。 おそらくはMySQL5.6以前のAWSのRDSで稼働し、そのままAuroraに引き継がれてきたテーブルで、かつ datetime 型カラムを含むものがこの対象となるのでしょう。 Aurora からサービスを開始したプロダクトなどでは見ることがないエラーなのかもしれません。 どのような困難が伴うか このあとに控える困難を想像し頭を抱えてしまった理由、今回の datetime 型カラム再作成対象となった2つのDB Cluster、XとYについて説明します。 X はショップの情報や商品の情報などを持ちます。 Y は各種履歴などが蓄積されています。 以下に規模感を記載します。 対象テーブル数とその合計サイズ テーブル数 容量 X全体 976tables 約7.5TB 対象テーブル 268tables 600GiB 対象テーブルはDB Clusterのデータサイズにして全体の約8% 4テーブルあれば、うち1つが対象という形。 テーブル数 容量 Y全体 236tables 約5.3TB 対象テーブル 37tables 615GiB 対象テーブルはDB Cluster のデータサイズにして全体の約11% 10テーブルあれば、うち1つか2つが対象という形。 結論としてこれだけのテーブルに対して、 なるべくサービス無停止でALTER文を発行しきる必要があります。 前提として、 当該アップグレードのメンテナンスは1回の深夜メンテナンスで行う 全断して行う予定であるが、メンテナンス時間は5〜6時間程度しかとれない というのがありました。 当初はメンテナンス時間の中で当該テーブルに対してdump&restoreするなども考えましたが、 実行時間的に無理だということがわかりました。 1 オンラインスキーマチェンジ/オンラインスキーママイグレーションツール メンテ当日にALTER TABLE or Dump/Restore + upgrade すべてを行うことは(当然に)無理、ということがわかりました。 それならばメンテ当日までに事前に下準備として行う方法を考えました。 下準備として、ということから暗黙的に無停止でなければなりません。 サービス無停止でALTER TABLE発行というところから、オンラインスキーマチェンジ/オンラインスキーママイグレーションツールに行き着くでしょう。 わたしはこの手のツールの利用経験がなかったため、ひとまず以下を候補にあげました。 2 pt-online-schema-change — Percona Toolkit Documentation github/gh-ost: GitHub's Online Schema-migration Tool for MySQL 結果として、われわれは gh-ost をはじめに検証し、目的に際し十分であると考え、そのまま今回の作業遂行ツールとして採用しました。 以下の理由から gh-ost の検証を優先し、結果的にわれわれの要件的には gh-ost で十分ということがわかったため、pt-osc の検証自体をスキップしました。 pt-oscよりgh-ostを優先して検証候補にした理由は以下になります。 pt-oscを選ばなかった : pt-osc では元テーブルと新テーブルの同期にトリガーが採用されており、トリガー利用による負荷が、サービス提供にどのように影響を与えるのか懸念し、検証優先度を下げた gh-ostを選んだ : 処理時間は長くなりそうではあるが、DB負荷自体は軽そうに思えたため gh-ostを選んだ : 一番の懸念であったDB Cluster Xでbinlog replicationをすでに運用していたため、gh-ost利用適正が高いだろうと思えたため そもそも pt-osc は完了までの処理速度を、gh-ost は小さな負荷での実行(つまりサービス影響の最小化)を重視しているよう思え、今回は後者の哲学を支持したため gh-ost 簡単にgh-ostの特徴および利用しての実感を書きます。 特徴については gh-ost/README.md at master · github/gh-ost を読むとわかりやすいです。 複数方式があるが、replication側からbinlogを取得するパターンが推奨されている 別名テーブルに元テーブルからデータを抽出して挿入する、更新分はbinlogで対応する 負荷が高くなると自動でthrottlingする 指定ファイルをtouchすれば、手動でthrottlingさせることもできる なにかしらのエラーが発生して処理途中で落ちた場合、また作業途中であった別名テーブルを削除して、最初から実行する必要がある 1テーブルにあたり、とてもゆっくり動くので対象テーブルデータ量によっては業務時間内に1テーブル終わるかわからないくらい 別名テーブルと元テーブルを切り替える処理をcut-overというが、この時間を指定することもできる(夜中に切り替えたい、昼間に切り替えたくない場合などに有効) cut-over という単語が出てきましたが gh-ostでは「ALTER TABLE用の別名テーブルを対象テーブルに変名し本番運用へと切り替える」ことをいいます。 gh-ost/doc/cut-over.md at master · github/gh-ost 利用していた実感では cut-over に至るまではまったく問題が起きませんでした。 明示的な問題として1回だけ発生したのは cut-over タイミングと更新タイミングが噛み合ったときに、 cut-over が止まってしまうという現象でした。 一度gh-ostの処理をとめ、新たにやり直すだけで解消するので、 cut-over 間近のタイミングだけ気にしておけばよい、という形で以後の作業もすすめることができました。 gh-ost の好きなところ 個人的に gh-ost で気に入ったところも書いておきましょう。 sock fileを経由することで対話式にコマンド実行が可能 gh-ost/doc/interactive-commands.md at master · github/gh-ost 進捗ステータスが確認できる コマンド実行中にパラメータを動的に変更できる 特定ファイルの設置で処理を暫定停止することができる 処理が遅いのだけが欠点、実運用への副作用がまったくといっていいほどない という感じです。 最終的にはほとんど放置して、一日の終わりに進捗状況を確認する程度になりました。 運用作業者(ひいてはサービス)に優しいツールだなと感じました。 参考 : 実際の作業スケジュール 当初は本番作業時にどのような影響がでるかわからなかったため、開発陣に対象テーブルのリストとALTER TABLE実行スケジュールを共有するようしました。 うまくいっても08月上旬から09月末くらいかかるのではないかと不安でしたが、gh-ostのおかげで08/08〜08/26という想定よりも短い期間で終えることができました。 データ総量が作業時間を左右する傾向がみられたため、見積もりのため以下のようなクエリでテーブルごとのデータの一覧を出しています。 total_size を主に見て実行時間の見積もりを行っていました。 SELECT table_schema, table_name, data_length AS `data_size`, index_length AS `index_size`, (data_length + index_length) AS `total_size`, table_comment AS ` comment ` FROM information_schema.TABLES WHERE table_schema != ' sys ' AND table_schema != ' information_schema ' AND table_schema != ' performance_schema ' GROUP BY table_schema, TABLE_NAME ORDER BY total_size DESC ; 注意点1 今回Aurora v2 -> v3 へのアップグレードだったため、gh-ost のバージョンは v1.1.5 を採用しています。 注意点2 第140回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その3］ | gihyo.jp には以下のような記述があります。 ユニークキーの追加 gh-ostを使用して、ユニークキーを追加することは可能です。 しかし、ユニークキーを追加するカラムの値が事前にユニークな値になっていることを確認してから実行しないと、 データがなくなってしまう恐れがあります。 われわれの今回の作業においては関係がなかったものですが、この記事より興味をもって利用される方においては、用途によっては気にしていただきたい内容であるため、ここに引用しました 参考URL 今回のタスクでは以下のDocumentを参考にしました MySQL 全般について MySQL :: MySQL 8.0: Removing support for old temporal datatypes gh-ost について gh-ost/README.md at master · github/gh-ost 第138回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その1］ | gihyo.jp 第139回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その2］ | gihyo.jp 第140回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その3］ | gihyo.jp 【MySQL】gh-ostを調べる - 地方エンジニアの学習日記 【MySQL】gh-ostでオンラインマイグレーション #Docker - Qiita Runtime error when trying to ALTER a table without PRIMARY KEY / UNIQUE KEY · Issue #332 · github/gh-ost pt-osc について pt-online-schema-change — Percona Toolkit Documentation pt-online-schema-changeの導入時に検討したこと、およびRailsアプリとの併用について - freee Developers Hub Percona社のgh-ostベンチマークなど Using gh-ost with Amazon Aurora for MySQL Gh-ost benchmark against pt-online-schema-change performance spirit というツールもあったが、v2(5.7系)だと利用が難しそうだった MySQL オンラインスキーマ変更ツールの spirit と gh-ost - Please Sleep BASEでは随時メンバーを募集しています。 2024.10現在、私の所属するSRE Groupの募集はないようですが、興味を持たれた読者諸氏におかれましては、以下リンク先をご覧いただければ幸いです。 採用情報 | BASE, Inc. - BASE, Inc. 検証ではdumpだけで想定メンテナンス時間をすべて消費してしまうことがわかりました ↩ チーム内にこれらツールの検証目的の過去Issuesが立っていたため ↩

新しい方を受け入れる側のマインドセットです。 はじめに BASE の Product Dev Division でシニアエンジニアをしているプログラミングをするパンダ（ @Panda_Program ）です。 入社されて3ヶ月目で同じチームで働いている Torata さんが「 入社して感じたBASEのいいなと思うところ 」という入社エントリを書いてくれたので、新入社員を受け入れる側からのアンサー記事です。 以下はBASE社内の人なら誰でも読むことができる文書で、特にこれからメンターになる人には読んで貰っているものです。自分が受け入れ側として数ヶ月間特に意識しており、手応えがあったことを書き残しています。 ここ数ヶ月の間、マネージャーと共にオンボーディングの体験や資料の全面的な見直しを行い、新入社員とメンターのオンボーディング体験を改善しました。この文章自体も前からあるものではなく、これからメンターはこういうことを心がけていこうねと新しく作ったものです。 以下の内容はBASE社での受け入れを想定していますが、他の会社でも（エンジニアという職種以外でも）活かせる内容だと思います。これから新しい方を受け入れるにあたってどう接したらいいのかわからないという方が、この文章を通して何かを掴めたら幸いです。 相手を知ろう これは一番重要です。現在、BASEで採用しているエンジニアは実務経験者の方がメインだからです。 よくある間違いは、相手が何も知らないと勘違いして一から全部教えようとすることです。相手も経験者なので一から教えてもらう必要はありません。では何を教えればいいのでしょうか。それは新入社員の人が持っている知識のうち、メンターから見て不足している部分だけです。 メンターがまずやるべきことは、新しく入社される方のこれまでの経験を深く知ることです。メンターはチームメンバーの誰よりも新しく入社される方のバックグラウンドを理解しましょう。 前職ではどのような業務を担当していたのか、前職の会社の雰囲気はどのようなものであったのか、どのようなことに興味を持っていて、どのようなことが苦手なのか。これらのことを知っていると自然と相手への向き合い方も変わります。相手の良いところや自分にない部分を知ることは相手へのリスペクトにつながります。 BASEではこうだと押し付けるのではいけません。相手の過去の経験を知り、BASEとの共通点や相違点を提示しましょう。すると相手は一から全部知るコストを払う必要はなく、共通点や差分を学ぶだけで済みます。メンターが「ウチではこうだ」と押し付けるのではなく、転職者が自分の過去の経験に基づいて、新しい会社と今までの会社との共通点や相違点にフォーカスする方がスムーズです。結果的に組織やカルチャーへの適応も早くなるでしょう。 自分を開示しよう 新しく入社される方はたくさんの質問を受けることでしょう。しかし、相手のことを聞くばかりではいけません。自分はどういう人間か、会社やチームで働いている人はどういう人たちなのかを伝えることも重要です。 自分の経験を相手に伝えましょう。自分は何が得意で、なぜこの会社で働いているのか。オンボーディング期間は、普段会社ではあまり話すことのない、自分が大切にしている価値観について話すいいタイミングです。ここを逃すとなかなかそれを話すタイミングはありません。 メンターとメンティーの一対一に限らず、新入社員の方が所属するチームのみんなで自分たちの大事にしている価値観について改めて話す機会を設けることにより、メンバーの知らなかった一面も見れるかもしれません。そうすれば、チームの結束はさらに強まるでしょう。 オンボーディングという機会を活用して既存のチームを再ビルディングすると、メンバー同士が今よりもっと互いにリスペクトを送り合えるより強いチームになります。 ドキュメントは渡すだけではなく、相手の理解度に合わせて適宜一緒に読もう。口頭で解説・補足をしよう オンボーディングで最初にやることの一つは、自分たちが開発しているプロダクトを実際に触ってみることです。その際、メンターは新入社員を一人きりにしないであげてください。 一般的に、何かウェブサイトやソフトウェアを触るときにこの裏側はどうなっているんだろうと気になるというのがエンジニアの性（さが）です。新しく入った方は、これから自分が開発していくことになるプロダクトに自然と興味と疑問を持ちます。 興味から出た感想や疑問に対してメンターがシステムの裏側を解説したり、ここはちょっといけてないところなんだよねと共感したりとタイムリーに答えることで、メンティーの知識の定着度は俄然アップします。人は疑問を持った時が一番知識を吸収できるからです。また、このように相手に寄り添った行動の積み重ねがお互いの信頼関係を構築することに繋がります。 ソフトウェアに限らずドキュメントも同様です。一人でただ読むだけでは理解できないことも、メンターと一緒に読みながら適宜口頭で補足や解説を交えてもらうとメンティーは深く理解することができます。 この時、自分で解説を始めたりBASEの事情を一方的に伝えるだけではなく、「この中でどの部分がわからないですか」「あなたの前の会社ではどうでしたか」とまず質問をして話を聞いてあげましょう。そこからうちの会社ではここは違いますね、ここは同じですねという会話を広げていきましょう。 「相手を知る」チャンスはどこにでも転がっています。 おわりに 少し大袈裟ですが、メンターとなるあなたの印象がBASEの社員全体の印象を決めると言っても過言ではありません。もし相手が年下だったり自分より経験が浅くても、相手へのリスペクトを忘れず真摯に向き合いましょう。 なお、手前味噌ですが私の配信しているラジオコンテンツもお聞きいただけると、オンボーディングに対してさらにイメージが湧くかなと思います。 こちらは、オンボーディングしてもらう側特有の焦りからくる失敗などについて話しています。オンボーディングされる側の気持ちを少しでも思い出すきっかけになるかと思います。 BASEではソフトウェアエンジニアを募集しています。ぜひ採用情報ページをご覧ください。 採用情報 | BASE, Inc. - BASE, Inc.

はじめに BASE BANK Division で エンジニア をしている岩本と申します！ YELL BANK の開発を担当しています。 2024年5月にBASEへjoinして早いもので5ヶ月ほどが経ちました。 joinしてからいくつかのプロジェクトを担当してきました。 改めて考えるとオンボーディングがとても充実していたおかげで円滑にプロジェクトに入っていけたのだなぁと感じます。 そこで、オンボーディングを中心にこれまでの5ヶ月を振り返りつつ、チームが新規メンバーのキャッチアップに向けて、どのような取り組みを行っているかを紹介させて頂こうと思います！！ 前置き 本題に入る前に前置きです。 私の普段の業務をイメージしやすいように体制や役割、各種環境についてお伝えします！ 体制 まずは体制です。 私の担当する YELL BANK ですが、joinした5月時点では以下のような3名体制で開発していました。 EPM（Engineering Program Managerのことです。 こちら をご参考ください。） エンジニア2名（内1人が私） 7月以降は以下の体制に移行しています。 EPM エンジニア1名（私） 役割 次に役割です。 私はエンジニアですが、BASE BANKでは「フルサイクルエンジニア」という役割が求められます。 フルサイクルエンジニアについての記事は過去にGroup Managerの松雪さん( @applepine1125 )が書いた こちら をご参考ください。 そのため、企画・要件定義〜保守運用・データ分析支援等まで幅広く対応することが必要になります。 それにより、開発チームだけでなく、PdM、デザイナー、PMMといった職能のメンバーとも頻繁にコミュニケーションが発生します。 体感的には開発チーム：7、PdM・PMM・デザイナー：3くらいの割合でコミュニケーションしています。 出社頻度 コミュニケーションに関連した話ですが、現状、BASE BANKの開発チームでは週1（毎週木曜）に出社日を設け、その他はリモートワークです。 開発環境 最後にアーキテクチャ周りのお話です。 私の担当する YELL BANK の開発業務においては以下の図の上側にあるBASEのサービスと下側にあるBASE BANKのサービス群を実装しております。 ご覧の通り、フロントエンドはTypescript（Vue.js）、バックエンドはPHP、Go、Pythonという形で複数の言語で開発しています。 また、インフラは主にAWSを使用しており、IaCではterraformを使用しています。 本題 前置きが少々長くなりましたが、ここから本題です。 私が効果を感じた取り組みなどを5つ紹介させて頂きます！！ その1　オンボーディングクエスト BASE BANKチームではオンボーディングクエストを用意しています。 以下はNotionで作成したオンボーディングクエストのTOPページになります！ 新規メンバーはまずクエストに沿って開発環境構築等の各種セットアップをしていきます。 さらに開発環境構築だけでなく、プロダクトの説明を受けたり、実際に触ったりといった研修も行います。 オンボーディング中はメンターが1人付きますが、クエストの中でPdMやデザイナーといった他の職能のメンバーとも接します。 フルサイクルエンジニアとしてはコードが書けるというだけでは不十分です。 そのため、プロダクトの研修があったり、他の職能のメンバーとコミュニケーションできる機会があったのは業務を進めるのに大変助かりました！ また、クエストではオンボーディングタスクというものを用意しています。 簡単かつ業務を1サイクル回せるといった最初のキャッチアップにちょうどよいタスクのことです。 私の場合、if文を少し修正すればOKな簡単なコード修正と、それをデプロイするというタスクでした。 これにより一通りの開発の流れを把握できました。 クエストはオンボーディングが終了するたびに振り返りをして改善を重ねています。 その2　オンボーディング期間中は毎日出社 オンボーディング期間は1〜2週間です。 その間、基本的には新規メンバーもメンターも毎日出社します。 そのため、すぐにメンターや他のメンバーに質問することができます。 対面なので、解決も早いです。 それ以上にメンバーとの信頼関係をかなり早く構築できるというメリットを感じます。 リモートの場合、コミュニケーション量が少なくなる傾向があるため、出社による対面のコミュニケーションでレクチャーを受けられたことでシステム、プロダクトのインプット量・質も上がりました。 今振り返ってみても最初に出社していたことでオンボーディング後の業務を円滑に進めることができました。 また、入社前・直後にコミュニケーションに不安を感じる方は多いとは思いますが、BASEでは早期にそのような不安を解消することができました！ デメリットとして通勤の負荷はありましたが、それを超えるメリットを享受できたと感じています！ 前置きでも記載した通り、オンボーディング終了後は週1（毎週木曜）で出社しています。 その3　ドキュメント文化 オンボーディング終了後、いざ本格的な業務に入るわけですが、まだまだ分からないことはたくさんあります。 BASE BANKにはドキュメントを残す文化があります。 分からないことがあればNotionやREADMEを見れば答えに辿り着くことも多いですし、あるいはなにかしらのヒントがあることが多いです。 業務していると大抵、どのメンバーも同じことで困るパターンも多いので、そんなときのためにトラブルシューティングをまとめたドキュメントも存在します。 個人的にはオンボーディング直後はこのドキュメントに大変助けられました。 以下はそのトラブルシューティングのドキュメントを一部抜粋したものです。 その4　メンターランチ BASEにはメンターランチという制度があります。 入社後、主に業務で関わるメンバーとランチするというものです。 費用は会社負担です。 この制度により、自分で機会を設けずとも仕組みでコミュニケーションの機会を設けることができます。 プロジェクト開始前にエンジニア以外の職能のメンバーともお話できたことで、いざプロジェクトを進めるというときにやりやすかったのを覚えています。 その5　振り返り文化 BASE BANKではスプリントごとにも振り返りしますが、それぞれのプロジェクト後にも振り返りをする文化があります。 プロジェクトの振り返りは職能横断的にそのプロジェクトに関わったメンバー全員が参加します。 私個人としては振り返りの場はプロダクトを知る機会でもあり、人を知る機会でもあります。 その人の職能、経験によって色々な意見が出ます。 そして自分も意見を出します。 意見を出すということはプロジェクトやプロダクトについて、常に能動的に考えている必要があります。 振り返り文化のおかげで自然とそのような考えになっているように感じます。 つまり、自然と「早くキャッチアップしなきゃ」という気持ちになります。 まとめ 改めてこれまでの4ヶ月を振り返ってみました。 振り返ってみると円滑なコミュニケーションというところにBASE BANKの強みがあるのだと感じます。 そして、それによるチームプレイに強みがあるのだと感じます。 私自身はまだまだ全般的に知識が不足しているので、チーム力向上に寄与できるように邁進します。 おわりに BASE BANKではいっしょに働く仲間を大募集しております！ フルサイクルエンジニアという役割に興味があるという方はまずはカジュアル面談からでもご応募頂けるとうれしいです！ ↓の採用ページの募集職種一覧から、BASE BANKチームで6.金融サービス（BASE BANKチーム）を選択頂いてカジュアル面談にご応募できます！ binc.jp