この記事は BASE Advent Calendar 2022 の17日目の記事です はじめに こんにちは！Pay ID 決済 バックエンドエンジニアのzan( @zan__gi ) です。 今回は、BASEに入社して「Speak Openly」っていいよね！と思った経験を綴ります。 BASEでの働き方や開発組織の雰囲気を少しでも伝えることができたら幸いです！ そもそも Speak Openly とは Speak Openly とは BASEのプロダクト作りと3つの行動指針のひとつで、 「 素直に話すこと。より良い結論を得るために、その場で意思を伝えよう。 」です！ BASE株式会社 会社紹介資料 も見ていただくとよりわかりやすいです。 Speak Openly の良いところ3選 現在携わっているプロジェクトでは実はフロントエンドを担当しています。 （現在進行中なので、プロジェクトの詳細は割愛させてください！） BASEに入社してプロダクト開発（しかも入社後初プロジェクト＆フロントエンド！）を通じて 「Speak Openly」っていいよね！と思ったので、今回はその中で3選、紹介します！ #ダサいぞ Speak Openly なSlackチャンネルのひとつとして、#ダサいぞ があります。 #ダサいぞ は「ユーザーとの接点全てにおいて、ダサいところを報告して直していく！Speak Openly！」をトピックとしたチャンネルです。 フロントエンド開発への恩恵として、ダサいパターンが蓄積されているので、センスを磨けた気がします。 また、実際に「ダサいぞ」といっているところを見ると、「私もいいプロダクトを作るために素直に話そう！」と前向きになることができます。 （↓2019年から多くの「ダサいぞ」が報告され、改善されている。） 暗黙知に触れやすい 開発以外にも共通して言えることですが、プロダクト開発を進めていると、暗黙知を知ることができると嬉しい場合があると思います。 BASEではpublicなSlackチャンネルが多く、Speak Openlyにコミュニケーションしているので、過去のプロジェクトのチャンネルを探ることで暗黙知に触れることができ、プロダクト開発にも活かしやすいと感じています。 また、プロジェクト参画者の発言を追うこともできるので、一方的に既視感を得ることができ、初めてコミュニケーションを取る際の心理的なハードルも少し下がります。 （↓privateなコミュニケーションチャネルばかりだと、コードやドキュメント等の成果物以外の情報を辿りにくい） 心理的安全性 現在、PdM、デザイナーやエンジニアと共にフロントエンド開発を一緒に進めていますが、 議論やレビューなどの際、「Speak Openly」という共通の行動指針は、 コミュニケーション相手も「Speak Openly」で行動してくる、という心構えでいれるので、ある種の心理的な安心感があります。（もし議論が白熱してヘコんでも、そこはBe Hopefulな気持ちで！） また、バックエンドを担当してきて、コードの美しさ、みたいなところの議論が多かったですが、 フロントエンドでUI、UXがイケてない、みたいな議論や検討ができているのは新鮮です。 文化的行動様式に近い話ですが、組織文化に裏打ちされたコミュニケーション基盤はやはり強い、と実感しています。 （↓多くの人が Speak Openly な行動をしているので、自分も Speak Openly になりやすい） 最後に 冒頭にも書きましたが「Speak Openly」っていいよね！と思った経験でした！ シンプルな哲学と行動指針なので、組織文化としてしっかり根付いていて、プロダクト作りに活かせていると感じています。 さて、明日は @chihiro さんの記事が公開予定です！お楽しみに！

はじめに この記事は BASE Advent Calendar 2022 の15日目の記事です。 こんにちは！船坂（ @takumi_funasaka ）です。BASEでプロダクトマネージャーをやっています。 先日、所属しているプロジェクトチームで「チームの能力を自己評価し、チームとしての今後の成長方針を決める」ワークショップをやってみました。 これが結構良かったので、ご紹介させてください。 ざっと目を通していただくと、チームの課題を抽出したり、いいチームのどこがいいのかを知るためのヒントになるかもしれません。 チームがいい感じ、な気がする 最近、自分が所属しているプロジェクトチームがとてもいい感じだなぁと思っています。 やるぞ！感もあるし、アウトプットも良い。苦難や衝突もたくさんありますが、それを踏まえても、良いチームになってきていると感じていました。 ただ、 チームの何がいい感じなのか、よく分からない のです。 現在、BASEではプロダクト領域ごとに組織をわけており、僕たちのチームもプロジェクトが終わったらすぐ解散ではなく、しばらく続いていく予定となっています。 そのため、現状の理解のままではなく、チームがいいと感じる要因を明らかにし、同時に課題も認識することで、中長期的なチームの成長方針をたてたいと考えました。 チームについて考える まずは、チームについて疑問があったので、調べながら自分の一旦の考えをまとめてみました。 「チームってなんなんだろうか。人の集まり？」 → チームとは、 ただ人が集まっただけではなく、目的を達成するために密に協働する人の集まり である 「じゃあいいチームってどういうチームだろう？」 → いいチームとは、 チームの存在理由である「成果」を上げることができ、そして評価されるようなチーム である 「いいチームかどうかを知るには、どうしたらいいんだろう？」 → いいチームにはいいチームワークが存在している。チームワーク能力を測ることがチームの機能性を知ることに繋がる。 このあたりの前提に立つために、いくつか研究を参考にさせていただきました。（後述） チームワークを評価するワークショップを実施してみた さて、ようやく本題ですが、自分たちがどういうチームなのかを明らかにするため、チームワークの機能性を評価するワークショップを設計してみました。 ワークショップの流れ ワークショップはチームのメンバー全員で行いました。 僕たちの場合は、 プロダクトマネージャー×1 デザイナー ×1 エンジニア ×5 QA ×1 の計8人で実施しています。 ワークショップの流れは以下になります。 チームワークについてみんなで学ぶ 事前に用意したチームワークの要素※1ごとに、その要素に関連する具体的な行動やコミュニケーション、できていないことなどをPositive / Negativeで振り分けて書き出す 全てのチームワーク要素について書き出し、全員で読む 各要素について、今の自分達のチームは何点になるか、1〜5点で投票する 意見が割れたところに関して、メンバー同士で意見交換をする 議論後、チームとしてのスコアを決定 チームとして不足している能力や今後獲得していきたい能力について、話し合う ※① チームワークの要素として、こちらの論文（ 山口裕幸（2007）、チーム・コンピテンシーと個人のチームワーク能力 ）に記載されていたもの利用させていただきました。 結果：チームの今を知る やってみた結果、僕たちのチームのスコアは下記のようになりました。（各5点満点。各要素の詳細な解説は省きますが、後述する資料を是非ご覧になっていただければと思います。） チーム指向性 職務指向性 4 対人指向性 5 チーム・リーダーシップ 適切な指示 3 対人的配慮 3.5 チームプロセス モニタリングと相互調整 4 職務の分割と明確化 3 フィードバック 4 知識と情報の共有 3 このように スコアを定量化・可視化したことで、チームについて俯瞰することが容易になり、メンバー同士の議論もしやすくなった と感じました。 メンバーの肌感ともほぼ一致した数値感になり、非常に参考になりました。 ディスカッション：チームについて話し合う このスコアを元に、更にチームで感想や今後チームとして獲得していきたい能力について、ディスカッションを行いました。 結果を見ながら、僕たちのチームは今後の方針として チーム・リーダーシップに課題があるので、今後注力して伸ばしていく チーム指向性が高いことを今後も大事にしていく チームプロセスもまだ改善途上であり、継続的に向上させていく ということをメンバーで合意できました。 これはとても大きな意味があったと感じています。 ワークショップの感想 実感としては非常によい機会になったなと思っています。 個人的に感じたことや、メンバーからあがっていた感想・意見を紹介します。 チーム指向性が比較的高いのはとても良いと感じていて、自信になった。普段から目的の意識付けやそこにコミットする姿勢を全員で共有できていることを再実感できた。 リーダーシップを取るということに対して、メンバーが課題に感じていることが明らかになった。現状は満点でなくても、全員で伸ばしていくという意識付けができたことはとても良かったと思っており、これが今回のワークショップの一番の成果だと感じている。 チームワークというチームを主語にした能力をトピックとして取り扱ったので、個人の能力に言及することなく、課題について議論できた。心理的安全性を保ちながら、オープンに今後について話せた実感がある。 「適切な指示」について考える中で、タスクを全部自分で巻きとろうとしてしまう癖に気づいた。これからは適切にメンバーを頼り、チームとしてもっと効率的・持続的にタスクをこなしていけるようにしたいと思った 特定のメンバーがチームワークという点で大きな役割を果たしているということが明示的になったのが良かった。課題ではあるが、認識できたので、他のメンバーも今後意識的に経験を積みながらチームを改善していけると思う。 チーム力は悪くはないことがわかったが、個人でみると偏りがあることも明らかになった。これからは偏りを分散させることを意識しながら、チームのいいところを高めていきたい。 ⁠ワークショップ後のFigjam（雰囲気だけ） 最後に 今回はふわっとした「チームがなんかいい感じ」の要因を明らかにするために、チームワークの機能性を知るワークショップを実施してみました。 チームワークの機能性をスコアとしてプロットしたことは、メンバー全員で今を見つめ、今後進むべき方向性のすり合わせをすることを容易にした感覚があり、重要なキーだったと思っています。 また、実は僕たちのチームは来年から少し構成が変わる予定があったため、状況が変わってもパフォーマンスを出し続けていくために、やるべきことを考えたいという目的もありました。 これは、ワークショップのstep2において具体的なコミュニケーションをベースに書き出す設計にしていたことで、チーム構成の変動後、どのようにチームワークが変わりうるかを予想することもでき、良かったと思っています。 さて、明日は @gimupop の記事が公開予定です！お楽しみに！ Appendix: 参考にした情報と、学んだこと おまけとして、今回このワークショップを設計するにあたって調べた情報と、学んだことを書いておこうと思います。 Google re:Work『効果的なチームとは何か』 学んだこと： "チーム: メンバーは相互に強く依存しながら、特定のプロジェクトを遂行するために、作業内容を計画し、問題を解決し、意思決定を下し、進捗状況を確認します。チームのメンバーは、作業を行うために互いを必要とします。" 効果的なチームに必要な要素は５つ 心理的安全性 相互信頼 構造と明確さ 仕事の意味 インパクト チームの効果性には「誰がチームのメンバーであるか」よりも「チームがどのように協力しているか」のほうが重要である チームワークの教科書 学んだこと： チームの成果を左右するコミュニケーションの要素は コミュニケーションの「熱量」 チーム全体への「関与」 外の世界へと向かう「探索」 チームメンバー同士が長い期間固定されていると、パフォーマンスが向上する しかし、同質化が進み、新たな学習を妨げることがある チームに『異端者』がいると、議論が活発化し、パフォーマンスが向上する 他にも色々学べました 山口裕幸（2007）、チーム・コンピテンシーと個人のチームワーク能力 学んだこと： チームワークの要素とモデル（ワークショップで利用） チームワークの測定項目群（ワークショップで利用） チームワークは個人のチームワーク能力にも影響を受けるが、メンバー同士の相互作用により、個々の能力を超える大きな影響を受けることが少なからずある

はじめに この記事は BASE Advent Calendar 2022 の14日目の記事です こんにちは。BASEの資金調達サービス「YELL BANK」チームでPMM（プロダクト・マーケティング・マネージャー）を担当している神納（＠yuni）です。 9月に入社をして3ヶ月間、中からプロダクトを見てみて、ぜひ皆さんにも知ってもらいたいなと思ったYELL BANKの推しポイントをご紹介させてください。 そもそも、YELL BANKってなに？ YELL BANK（エールバンク）とは、BASE加盟店が利用できる「資金調達サービス」のことです。一言で表してしまうと 「未来の売上を前借りしているようなイメージ」 です。 まとめて仕入れを行う時や、新商品の開発、機材の導入などで資金繰りに不安を感じた際にご利用いただくことを想定して、サービスを提供しています。 現在は、BASE加盟店の一部のショップオーナーさまに限定してご利用いただけるサービスで、 調達できる金額は、BASEの売上実績に紐づいており、ショップによって金額規模も変わってきます。 YELL BANKの知ってほしいところ3選✨ 一般的な金融与信とは切り離された「独自の与信審査」 「すぐに欲しい」に応えた即日性 売れた時だけ支払えるから、売上が安定していなくてもリスクが低い それぞれ順にご説明します。 1. 一般的な金融与信とは切り離された「独自の与信審査」 そもそも与信とは、取引相手のことを信用して、資金などを貸与することです。 一般的な金融与信は、利用者の「返済能力（Capacity)」「返済資質（Character）」「返済担保（Capital）」で評価されています。 投資会社側も、融資先が倒産などの理由で返済が出来ない状態（=貸倒）になってしまうと、企業にとっての損失になるため、 安心安全に取引ができる相手なのかを判断する ために、事前に審査を行います。これが「与信審査」です。 金融機関の融資以外でも、クレジットカードを作成するときなどに、耳にしたことがある言葉かなと思います。 金融機関の与信審査であれば、年収、勤務情報、金融資産、借入、住居などの情報を元に評価がされます。 一般的には、窓口に出向きヒアリングが必要だったり、本人確認書類や決算書、事業計画書などの書類の提出が必要だったりします。 YELL BANKも金融サービスになるので、同様の与信審査は必要です。 ただ、YELL BANKで行われる与信審査はたった一つ 「BASEでの運営実績」のみ です。書類提出などの必要は一切なく、 今までのBASEショップ運営の頑張りを評価 します。 このようにYELL BANKは独自の与信審査をしているため、既に複数の借入をしていて追加での借入が難しい方や、個人事業主であるため金融機関での融資に通らない方でもご利用いただけます。 2. 「すぐに欲しい」に応えた即日性 YELL BANKでは「BASEショップの運営状況」をシステム上で常に評価しているので、「今申し込みたい！」と思ったタイミングですぐに調達ができます。予測不能なアクシデントが起きた場合でも、即日対応できるのは強みの一つです。 また、クレジットカードやQRコード決済だと、現金着金が翌月に持ち越してしまうという、キャッシュレス化が進むことでの弊害もあります。売上は安定しているものの、一時的にキャッシュフローに詰まってしまったなという場合でも、YELL BANKで予備資金を作っておくという対処もできます。 利用したい時にすぐ取り出せる自分のお財布のように、YELL BANKを利用してもらえたらいいな と思っています。 3. 売れた時だけ支払えるから、売上が安定していなくてもリスクが低い 金融機関などでは、毎月固定金額の支払いが必要な場合が多いのですが、YELL BANKはBASEショップで商品が売れたら、その売上からn%支払う、というサービススキームです。売上が落ち込む月でも、収入より支出が大きくなる心配はないので安心設計です。 また、支払い期日がないので、「長期的に挑戦したいことがあるから、まとまった資金が必要。だけど、いつ売れるかわからない...」場合でもご利用いただけるので、新しいことに挑戦したいタイミングで活用しやすいサービスかと思います。 おわりに 今回は、ぜひ知って欲しいYELL BANKのサービスのことをシェアさせていただきました。 YELL BANKチームでは、どうやったらショップ運営を続ける中で感じる資金課題や、不安をいち早く解決できるかを考えて、日々機能改善に関する対応を行っています。 もっといいプロダクト、体験を提供できるように尽力しておりますので、今後のYELL BANKのアップデートを楽しみにしていただけると嬉しいです。 また、YELL BANKでは一緒にプロダクトを盛り上げてくださる方を積極採用中です！カジュアル面談も対応しているので、お気軽にご連絡ください。 採用情報は こちら 明日は ＠funasaka ＠zan の記事が公開予定です、ぜひご覧ください。

はじめに この記事は BASE Advent Calendar 2022 の13日目の記事です。 はじめまして、BASEでエンジニアリングマネージャーをしている渋谷と申します。 今回は、textlintを導入したところレビュー工数が90%削減できたので技術的にどのようなアプローチをしたかについて紹介させていただきます。 背景 弊社にはUXライターが在籍しており、BASEプロダクト全般におけるテキストの品質を向上させる、UXライティングを行っています。 テキスト版デザインシステムとして「運用ガイドライン」「用語リスト」を作成し、あらゆるタッチポイントにおいて、日々テキストコミュニケーションの最適化を図っています。 UXライターが文言を作成するケースもありますが、UXライターでない方が文言を作成するケースが多く、その場合UXライターがレビューすることで品質を担保しています。 そのような取り組みの中で見えてきた2つの課題がありました。 ことばのトンマナ（トーン＆マナー：デザインやスタイルに一貫性を持たせること）をひたすら磨く作業が、現状のテキストデザイン作業の大半を占めていること 運用ガイドラインがあっても、品質の担保は、最終的にはどうしても属人的にならざるを得ないこと つまり、表面的にはトンマナが統一されていることによって、一定のテキスト品質は担保されている一方、UXライティングの本来の役割である「体験をデザインすること」という本質に時間を割けていなかったのです。 そこでtextlintを導入し、トンマナを機械的に統一させようという試みがスタートしました。 （具体的な背景についてはUXライターの藤井が執筆した こちらの記事 に詳しく記載されているので、ぜひ御覧ください） textlintとは textlint は JSer.info などでおなじみの azuさん が開発されているOSSで、テキストファイルやMarkdownのための文章校正ツールです。 .textlintrcにルールを記述するとそのルールに従い校正が実行されます。 アプローチについて 大きく分けて2つのことを行いました。 textlintのためのルール設定 誰でも使える環境の構築 textlintのためのルール設定 ルール設定までの経緯について UXライターはもちろん非エンジニアであり、textlintの使い方に慣れていなかったため、エンジニアである私がサポートしながら進めることになりました。 設定したい校正ルールをUXライターの方にリスト化してもらい、そのリストに対してエンジニアの私がどのtextlintルールを適用できるか一つ一つ検討し、今回導入するパッケージを決定していきました。 設定したルールについて 弊社では下記パッケージを導入しています。 textlint-rule-preset-ja-technical-writing textlint-rule-period-in-list-item textlint-rule-preset-JTF-style textlint-rule-proofdict 特に今回役立ったのはproofdictです。 proofdictは表記揺れやtypoなどを検知するための辞書管理ツールです。 弊社では単語の表記揺れ対策はもちろん、 下記のようなBASE独自ルールについてもproofdictを活用しました。 （）かっこは半角を使用しない ・・・は……（全角三点リーダを2回繰り返す）にする 金額表記は¥（全角）＋半角スペースで表記する 誰でも使える環境の構築 textlintは文章校正がメインの機能になっており、利用する場合にどのエディタを使うかは利用者側に委ねられています。エンジニアの方はローカル環境にtextlintを npm install した上で、VSCodeなどのエディタ経由で利用することが多いと思います。しかし、今回の要件では非エンジニアの方がtextlintを利用するため、ローカル環境の構築はハードルが高く現実的ではありません。 そこで textlint/editor です。 chrome拡張を使ってブラウザ上で文章校正を行うことができます。独自設定をインストールすることで独自の.textlintrcを反映させることもできます。 その結果わずか2ステップで導入することができました。 ステップ1：chrome拡張のインストール ステップ2：BASE独自設定のインストール ただし、このchrome拡張は2022年11月時点でtextareaタグのみに反応する仕様となっており、弊社で利用しているドキュメントツールであるKibelaやGoogleDocsでは利用することができませんでした。 そこで、textareaを有しテキスト内容をローカルストレージに自動保存する簡易なWebエディタを自作しそちらを使ってもらう運用にしました。 （この記事もそのエディタを利用して執筆しています） 導入した結果 UXライターの方いわく、「レビュー前のテキストの品質は、『トンマナ』という文脈においてはとんでもなく担保された！　トンマナレビュー工数、体感で約90％削減！」とのことでした。 本来の役割である「体験をデザインすること」という本質に時間を割けるようになったそうです。 私としてもそのような結果は大変うれしく思いますし、なによりazuさんには感謝の気持ちでいっぱいです。 おわりに 本記事では、弊社でtextlintをどのように運用しているかについて説明しました。読んでいただいた方の助けに少しでもなれば幸いです。 明日はmatzzさん、yuniさんの記事が公開予定です、ぜひご覧ください。

初めに BASEアドベントカレンダーの 13日目です。 こちらの記事では、BASEの開発組織の環境がこれから成長していく若手エンジニアにとってとてもいい環境であることを身をもって体感したため、レポさせていただきます！ 自己紹介 こんにちは。Owners Marketing所属の若菜と申します。 普段は、新規ショップオーナーの方によりよくBASEを使ってもらえるための機能改善や、 もっとたくさんの人にBASEを使ってもらえるようにするための機能提供に取り組んでいます。 対象の読者と伝えたいこと こちらの記事は、以下に当てはまる人に特にご覧いただきたい記事になっています。 エンジニアとしてのキャリアをこれからどう伸ばしていこうか迷っている人 また、この記事においてお伝えしたいことは以下です。 BASEが若手エンジニアにとって非常に良い成長環境であると感じている その理由・背景などを実際の出来事ベースにご紹介 入社して1年が経過する私が、この1年で実際にエンジニアとしてBASEで働きながら感じた点を、 仕事面 と 会社生活面 に分けて、お伝えさせていただきたいと思います。 仕事面 🙋🏻プロジェクトの開発責任者として、業界初の機能をリリースした BASE で使用できる配送方法の一つである、 かんたん発送App にて、匿名配送機能を提供するというプロジェクトの開発主担当を担いました。 （詳細は こちら ） BASEは個人の利用であれば、 住所・電話番号を非公開 にしてネットショップをオープンすることができるため、匿名配送機能が実現されれば業界初の 匿名でネットショップを開き、売ることができる こととなり、社内外問わずインパクトの強いプロジェクトでした。 自身の成長につながった点 このプロジェクトを経て、特に以下の2つのことが成長に繋がったと感じています。 開発のいちメンバーとしてだけで参画していたら得られなかったような経験を積むことができ、大変ありがたく思っています。 1️⃣ 1つ目：「確実なプロジェクトの進め方・不確実性をいかに減らすか」という観点が身についた 本プロジェクトを進めるにあたり、経験豊富なマネージャーに進め方を相談しました。 そこで以下のようなアドバイスをいただき、それらを実践に移すことで安心しながらプロジェクト進行を行うことができました。 「タイムラインを管理するガントチャートを用いてプロジェクトを管理すること」 「リスク管理を先手先手で進めること」 中でも リスク管理 は私がこれまで仕事を進める上であまり意識できていなかった点でした。 プロジェクトの初期段階で、今後リリースまでに発生しうる様々なリスクをブレスト形式で洗い出し、それをシートにして毎週の定例などで定期的にウォッチしていきます。 詳細は、以下の記事をご覧ください。 不確実性に立ち向かう一つのTips〜リスク管理に取り組んだ話〜 決して手元の開発だけ行っていればいいわけではなく、自分の開発タスクをこなしながらもプロジェクト全体のリスク回避、安全進行を意識していく。 以降、私の日々の業務においても影響を大きく与え続けている意識改革だったと実感しています。 2️⃣ 2つ目：機能仕様の隅々まで把握し、成果物すべてに責任を持つ意識が身についた 今回、新たに匿名配送を実装した「かんたん発送Apps」は、 2018年から提供を開始している 機能です。 当時開発を担当していたメンバーはすでに退社してしまったりと、BASE内でも機能仕様に精通している人が少ない状況でした。 そのため、 自らがこの機能の 社内で一番の仕様理解者になる 勢いでソースコードや社内ドキュメントなど使えるもの全てを使って調べ上げていき、既存仕様と追加仕様の把握をリードしました。 本機能リリース後も、別プロジェクトに従事する傍ら、かんたん発送Appsにおける社内の調査を積極的に引き受けるなどして、知見を社内に還元できるようにしています。 会社生活面 🙋🏻チャレンジ大歓迎で、成長を一緒に考えてくれる組織 会社や開発組織全体で「 チャレンジを歓迎する 」雰囲気があると感じています。 BASEの行動指針にも掲げられている「 Be Hopeful 」が手伝う形で、チャレンジ歓迎な文化醸成に作用していると思っています。 Be Hopeful 楽観的でいること。 期待した未来は実現すると信じて、勇気ある選択をしよう。 BASEのSlackワークスペースを見ていると、社内の至る所で上記のBe Hopefulを感じる場面が多く、開発組織に限らず全社的に挑戦が歓迎される雰囲気を感じます。 その中でも、私がBASEで働く上で特に感じる、 成長できる環境 について触れさせていただきます。 🏁 目標を明確に設定し、伴走してくれる BASE社内では、四半期ごとにOKRフレームワークを用いて目標設定を行います。 その際、ストレッチの効いたチャレンジングな目標設定を行うことも可能であったり、担当マネージャーが目標設定の壁打ちをさせてくれたり、定期的な1on1で進捗の相談相手になってくれます。 よく、成長していく上で「コンフォートゾーン・ラーニングゾーン・パニックゾーン」3つのゾーンが重要と言われますが、BASEで働いている中で常に 最も成長しやすいと言われる「ラーニングゾーン」 にいられていると思っています。 エンジニアとしてキャリア形成を考えない日はありません。 私は仕事で自分のできる範囲のことしか行わないコンフォートゾーンで停滞していたことに思い悩み、BASEへ転職した背景もあるため日々の業務をこなしながら ラーニングゾーンに居られること が個人的にとてもありがたいと思っています。 🏔"越境"を推奨し、チャレンジを歓迎してくれる 日々業務に携わっていると、業務ドメインや技術ドメインで担当領域などができていくと思いますが、それらを踏まえてBASEの開発組織では「自分の担当領域の枠を越えて活躍する人」「チャレンジする人」が多いように感じます。 以前私も、日頃はサーバーサイドエンジニアでありながらフロントエンドの開発・リリースに携わり、記事も執筆させていただきました。 サーバーサイドエンジニアがフロントエンドに挑戦して最高の経験になった話 私自身、上記の経験を経てさらに日頃の業務内でのチャレンジングなことへの敷居が下がったこともあり、 チャレンジを行うことで次のチャレンジがしやすくなる好循環 を明確に実感しました。 BASEに入社する前の段階では、上記のようなテックブログや今回のようなアドベントカレンダーの執筆も気が引けてしまい「自分は投稿しない（できない）だろうな...」と思ってしまっていたので、こちらは 明確なマインドの向上ができた と思っています。 ✍️ まとめ 私がBASEに入社して成長しやすい環境と感じた理由をお伝えさせていただきました。 日々の業務をこなすことも大事ですが、それと同じくらい 自身の成長を実感できること も大事だと思っています。 何より、成長を実感しながら毎日の仕事をこなせることがシンプルに仕事の楽しさ・充実度にも直結しています。 エンジニアとして働いて数年が経ちますが、この一年が間違いなく 今までのエンジニア人生で一番充実している と自信を持って言えます。 読者の方の中に、エンジニアキャリアのこれからが不安な方、迷っている方、チャレンジしていきたい方などいらしたら、カジュアル面談なども実施していますのでぜひ一度ご連絡ください！ 明日はmatzzさんとyuniさんの記事です！お楽しみに！

はじめに 本記事は BASE アドベントカレンダー 2022 の11日目の記事です。 はじめまして。CSEグループのエンジニアの泉原と申します。 BASEのCSEグループでは社内業務改善や内部統制の整備など幅広い業務を対応しています。 CSEグループについてはこちらをご覧ください。 devblog.thebase.in 今回は、BASEにおける月初処理の概要とreportシステムの自動化、業務フローの見直しなどの業務改善についてご紹介します。 BASEにおける月初処理・reportシステムとは 月初処理 BASEではJ-SOX対応の一環として、 BASEショップの売上金と決済サービス側の入金データ BASEショップの売上金とBASE側の決済データ BASE側の決済データと決済サービス側の入金データ 決済サービス側の入金データと実際の入金額 これら4点の整合性が取れていることを確認することで財務報告上の信頼性を担保しています。 月初処理は月次でこれらの整合性が取れていることの確認を行うことを指しています。 reportシステム CSEグループでは上記の月初処理を行うにあたりreportシステムと呼ばれるレポーティングシステムを構築しており、決済サービス側の入金データの取得やBASE上の決済データとの突合(差異調査)を行なっています。 reportシステムの詳細についてはこちらをご覧ください。 devblog.thebase.in これまでの月初処理の課題 システムの実行手順が複雑 reportシステムではBASEのデータ集計やレポーティングを行い、経理側へ売上データを連携しています。 ただし、最終的に経理側へ必要なデータを受け渡しするまでに、以下のような工程で手動でコマンド実行したりデータを取り込んだりする必要があり、作業者の慣れが必要となっていました。 また、決済によってはreportシステムのDBに決済データが取り込まれるまでにタイムラグがあるため、売上レポートやデータの突合の際に作業者が手動で日付のオプションを指定してPythonコマンドを実行する必要がありました。 こういった手動でのコマンド実行の際に人的ミスが発生する可能性も否めませんでした。 差異調査が複雑になることがある 差異調査とは 月次処理では決済システム側の決済データとBASEの決済データの整合性を確認するために、それぞれの決済データを突合して差異がないかを確認しています。これを差異調査と呼んでいます。 どのような時に差異が発生するか 差異は以下のような条件で発生することがあります。 BASEや決済システム側の不具合や特殊な処理による差異 不具合の解消などに伴う返金処理で発生する差異 決済システムにトランザクションが渡るまでのタイムラグによる差異 これらの差異は毎月発生する可能性があり、CSE内で事前に把握できていない差異があった場合、差異の原因の調査に時間がかかることがありました。 どのような改善を行ったか システムの実行自動化 各決済システムから決済データを取得する箇所に関しては、puppeteerを使ったブラウザ操作で自動化されていましたが、一部の決済に関しては管理画面にログインしてデータをダウンロードしDBにデータを取り込む方式をとっていたため、まずはこちらを自動化できるよう対応を進めました。 また、売上レポートの取得や決済差異の抽出、共有フォルダへの配置など手動で実行していた一連の処理を1つのStepFunctionsにまとめたことで、手動での作業をなくしワンクリックで処理できるようにしました。 差異調査の改善 調査フローの整備 決済の差異が発生するパターンにはある程度決まったパターンがあったため、差異の調査方法をフローに起こし、CSE内で誰でも調査が進められるように対応しました。 また、発生した差異の内、月を跨いで対応が必要なものに関しては、別途シートを作成して対応状況を追える状態にしたことで差異を見失わない体制を作っています。 月初の確認会 毎月差異の確認用のslackチャンネルを作成し、差異として抽出されそうな決済を事前にCSE内で共有しておくことにしました。月末には確認会を設けてCSE内で再度確認することで、差異調査のヒントが得られ調査時間の短縮に繋がりました。 結果 これまで月初処理の際には売上レポートの受け渡しと差異調査を含めて2営業日程度要していました。また、差異調査が複雑になり、CSE総出で時間をかけて調査することもしばしばありました。 改善後は売上レポートの受け渡しは1時間程度、差異調査を含めても半日程度で完結しており、経理側への連携にかかる時間が大幅に短縮されました。また、データを早く連携できるようになったことで、経理側の月初作業も1営業日程度短縮し、決算スケジュール上余裕をもって取り組むことができるようになっています。 最後に 今回の月初処理の改善に関してはCSEグループ内の業務改善でしたが、実際に業務を通じて課題が見えてくることを改めて実感しました。他の業務改善の際にもまずは一度業務を体験して理解することから始めてみたいと思います。 明日は@naoki.munechikaさんと@yuniさんの記事が公開予定です、ぜひご覧ください。

この記事は BASE アドベントカレンダー 2022 の 10 日目の記事です。 はじめに 初めまして、BASE のバックエンドエンジニアの shiiyan と申します。この記事では、ファットな注文検索モデルをリファクタしたことの経緯と感想について紹介します。 注文検索モデルをリファクタする理由 古典的な MVC モデルでは、スキニーコントローラー・ファットモデル（ Skinny Controller, Fat Model ）の考え方があるゆえに、プロダクトの成長と共に、モデルが肥大化していくことは多々あります。 BASE において、注文モデルと注文検索モデルはこの流れから逃れられませんでした。2022 年初めの時点では、注文検索を担当するモデルクラスは 1 ファイル 3000 行弱の規模に肥大化しています。こういったモデルクラスでは、コード自体が読みづらいだけでなく、機能改修時に影響範囲が読みにくく、メンテコストが高いという課題がありました。 2021 年 12 月から 2022 年 3 月まで、私は注文管理改善プロジェクトに参加していました。このプロジェクトではボトルネックを特定し、注文検索のパフォーマンス改善を目的としていました。ボトルネックを特定するために、まず処理の流れを理解する必要があり、そして、工数の見積りを出すために、注文検索処理を修正した場合の影響範囲を調査する必要がありました。こういった背景で、改修する前に、まず既存コードが分かりづらいという課題を解消することに合理性を感じ、プロジェクト内でリファクタリングの意思決定を行いました。 リファクタリングの意思決定 今年 3 月ごろに、注文検索周りの処理をリファクタすることについて、担当 PM と合意ができました。リファクタを進めるために、以下の前提があります。 進行中プロジェクトの進捗に影響しないこと 優先度が高いプロジェクトができた場合に、いつでもリファクタリングから切り替えられること これらの前提を満たすために、以下のようなリファクタの進め方を計画しました。 ボトムアップ方式 テストファースト 毎朝 1 時間のペアプロ ボトムアップ方式というのは、注文検索の既存処理を俯瞰してリファクタリング方針を決め、その後に順序的に進むことではなく、まずは変数名や関数名など些細なところからリファクタリングをし、少しずつ範囲を拡大していく方式です。この方式をとる理由は、条件が複雑な注文検索処理の全体を俯瞰し短い時間の中でリファクタリング方針を決めることが難しいと判断したためです。 テストファーストというのは、リファクタ対象のクラスやそのクラスの上位クラスに対してまずテストを追加し、リファクタをしても既存処理がデグレていないことを担保することです。これは、デバッグ時の生産性を高めることとリリース時のリグレッションテストのコスト削減を図ろうとしています。 毎朝 1 時間のペアプロをとる理由は、日中のプロジェクトの進捗に影響を出したくない、また、ペアプロすることにより、リファクタが目指す良いコードの基準を合わせたかったためです。 注文検索モデルの課題点 リファクタする前の注文検索モデルには以下の課題点がありました。 コーディングスタイルが決まった前に実装したため、変数名と関数名にスネークケースとキャメルケースが混在していた 同じ変数名で再代入を重ね、変数の値を追うことが難しかった 200 行を超える関数が複数存在し、関数名も自明ではなかった 注文検索用のモデルだが、クラス名は注文モデルと区別ができなかった 複雑な検索条件の分岐を全て 1 箇所で対応したため、検索クエリを構築する処理が複雑化していた リファクタリングのやり方 リファクタリングの手法や基準はおもに Martin Fowler さんの『 リファクタリング 既存のコードを安全に改善する（第 2 版） 』を参考にしました。これらの手法を PhpStorm という IDE の機能やプラグインと一緒に使うと効率よくリファクタリングを進められます。今回の注文検索モデルのリファクタリングで頻繁に利用したリファクタ手法をいくつか紹介します。 変数名や関数名をキャメルケースにする BASE のコーディングスタイルを基準に、変数名と関数名をキャメルケースに統一します。PhpStorm デフォルト機能で Toggle case というものがありますが、変更したいケースに一発で変えられるようにしたいため、 String Manipulation というプラグインをインストールしています。直前に変更したケースを記憶しているので、複数箇所連続でスネークケースからキャメルケースに変換する時に重宝しています。 変数の抽出と変数のインライン化 同じ変数名で再代入を重ね、変数の値を追うことが難しかったの課題を解消するために、変数の抽出と変数のインライン化を適用します。その時に、利用されるのが PhpStorm のリファクタ機能です。リファクタ対象を選択して、右クリックのメニューで Refactor | Introduce Variable を選ぶと変数の抽出ができます。 Refactor | Inline を選ぶとインライン化ができます。 PhpStorm のリファクタ機能では以下の 4 パターンの変数抽出に対応しております。 ローカル変数 コンスタント フィールド変数 パラメーター変数 関数の抽出と関数のインライン化 200 行を超える関数が複数存在し、関数名も自明ではなかった課題を解消するために、処理の意図が伝わるまでに関数の抽出とインライン化を繰り返しました。関数の抽出はを Refactor | Extract Method 利用し、インライン化は Refactor | Inline を利用します。Extract Method は関数の抽出後、いい感じの関数名を提示してくれるだけでなく、複数箇所で同じ処理が書かれている場合に、全て対応してくれるのでとても便利です。 クラス名、関数名、変数名の変更 注文検索用のモデルだが、クラス名は注文モデルと区別ができなかった課題を解消するために、クラス名を OrderSearcher に変更しました。 Refactor | Rename を利用します。クラス名を変更する時に 1 つ注意点があります。クラスを変更した時に、そのテストクラスの名前は変更されないことです。例えば、 OrderSearcher を NewOrderSearcher に名前を変えても、 OrderSearcherTest の名前はそのままです。追加でテストクラスに対して、 Refactor | Rename を使い名前を変更するようにしています。 不要な use の削除 注文検索モデルに CakePHP 2 依存の App::uses がたくさんあったため、それを PHP の use キーワードで名前空間を利用するようにしました。そうすると、PhpStorm の Code | Optimize Imports 機能を利用して、不要な use の削除ができます。さらに、Optimize Imports を Before Commit フック に入れると、PhpStorm 経由でコミットする前に、自動で import をチェックし、修正してくれるようになります。 ポリモーフィズムで注文検索の条件分岐をシンプルにする 複雑な検索条件の分岐を全て 1 箇所で対応したため、検索クエリを構築する処理が複雑化していた課題を解消するためにポリモーフィズムを導入しました。条件分岐の中で最も複雑なのは、検索対象の中にコイン注文（ショップコインという BASE 内かつて流通していた仮想通貨を使って購入した注文）が含まれているかどうかの分岐です。コイン注文ありなしの 2 パターンで検索クエリ構築、DB へ問い合わせ、返り値の整形という一連の流れを 1 つのクラス内で実装していたため、条件の分岐が散らばり、処理の重複も発生するようになりました。 注文検索モデルのコイン注文ありなしの分岐に対して、以下のリファクタリングを行いました。 同じインターフェイスを実装したクエリ生成クラスを別々に作成した。クエリ生成の共通処理は trait に切り出した。 コイン注文ありなしの条件に応じて正しいクエリ作成クラスを生成するファクトリーを作成した。 注文検索モデルでは 2 のファクトリーを利用してクエリ構築の条件分岐を隠蔽した。 今回のリファクタから学んだこと よかったこと まずはリファクタすること自体がよかったです。既存コードに手を加えることにより、実装者の意図が伝わり、ドキュメントに書かれていない仕様の細かい部分への理解も深まりました。リファクタリングの結果、ソースコードの可読性とメンテナンス性が向上し、注文検索改善など後続プロジェクトが軽い身でスタートできるようになりました。今は、リファクタして損はないと考えています。 テストファーストとリファクタリングの相性がよかったです。テストを予め定義することで、このリファクタでデグレっているのかのフィードバックを最短でもらえるため、バグが発生しても早めに気づいて修正することができ、リファクタの生産性向上に貢献が大きかったです。今回のリファクタで 10 回弱のリリースの内、注文検索の全パターンを網羅的に手動テストしたのは最後の 1 回でしかないです。リリースして半年が経っても、バグが出ていませんでした。 ボトムアップ方式でリファクタの意思決定の合意が取りやすかったです。リファクタリングの合意がうまくいかないほとんどの場合は、進行中の開発タスクを優先したいと思います。ボトムアップ方式ならリファクタのための前期設計と計画が不要となり、いつでもリファクタリングを開始や停止にでき、いつでも開発タスクに戻れる状態が作れやすいです。 よくなかったこと ボトムアップ方式に限界がありました。変数名の変更や、関数の抽出など局所的なリファクタでは設計せずにスムーズに進めましたが、ポリモーフィズムなどクラス全体あるいは、クラスを跨ぐ影響が出るリファクタでは予想していなかった理由でリファクタが進めなくなると手戻りコストが高いです。注文検索モデルの例では、元々はクエリ構築、DB へ問い合わせ、返り値の整形という一連の処理に対して、ポリモーフィズムを適応しクラスを分けようとしましたが、DB へ問い合わせは Model を継承したクラスでなければいけないというフレームワークの制限に引っかかり、2 回ほどやり直しが発生しました。手戻りコストが高いリファクタリングを行う前に、一定程度でトップダウン方式で設計しておいたほうが良いと思いました。 おわりに 本記事では、ファットな注文検索モデルをリファクタした実践について記載いたしました。読んでいただいた方の助けに少しでもなれば嬉しいです。 明日は @izuhara さんの記事が公開予定です。ぜひご覧ください！

この記事は、 BASE Advent Calendar 2022 の9日目の記事です。 同日公開の @gatchan0807 さん の「 プロダクトの小さな負を解消する有志活動の振り返り 」もぜひご覧ください！ こんにちは！BASEでPdMのプレイングマネージャーをしている本山と申します。 チームビルディングについて考えることが多いのですが、オンラインだと格段にハードルが上がるなぁと感じています。 この記事では、今までのトライを通して見えてきた「オンラインでのチームビルディングで意識をしていること」をまとめたいと思います。 似たようなお悩みをお持ちの方にとって、少しでもヒントになれば嬉しいです。 目指している満足度 チームビルディングの企画をする際、私は満足度75%くらいを目指しています。 チームビルディングは、チームの状況にあわせて継続的に取り組むことが大切だと考えているからです。 満足度100%を目指そうとすると、企画や準備のハードルが上がりライトにトライをしにくくなってしまいます。 逆に満足度が低ければ、チームのみなさんに協力をしていただけなくなってしまいます。 「次も参加してみたい」と少しでも思っていただける状態と、自分からお誘いをしやすいバランスの目安として満足度75%くらいを目標にしています。 意識しているポイント チームビルディングを考える際に、意識をしているポイントは大きく3つあります。 ※ 毎回全てを満たそうとしているわけではありません 会話を発生させる 変化をつくる ポジティブな印象で終われるようにする 1. 会話を発生させる 特にオンラインMTGでは、発言・会話をするか迷ってしまう場面があると思います。 参加者の方が迷わず発言しやすいような状態作りを意識しています。 取り入れ方 発言順番は、指名制にする 指名方法は「今日の占い順位」のように変化があるものだと、固定の順番にはならないので相性が良いです アイスブレイク・雑談はテーマを指定する 事前にテーマを募集しておき、ストックをしておくと便利です ビジュアルイメージで表現をしてもらう 今週の絵文字 / 気持ちを天気をスタンプで表現 + その理由を話していただく 2. 変化をつくる 特にオンラインのMTGでは、聞いているだけなど特定の状態が長時間継続した場合、集中力の維持が難しいと考えています。 参加者の方の興味が続きやすい状態をつくるため、気持ちや状態の変化を意識的に取り入れるようにしています。 取り入れ方 タイマーをかけて区切りをわかりやすくする 少し短めでかけると、タイマーが鳴ることで間延びしないのでおすすめです グループ分けをシャッフルする zoomのブレイクアウトルームとの併用が便利です ポジティブ・ネガティブ両方の感情の発散をしていただく もやもや・今後やってみたい・不安 などもお互いを知る上でおすすめの切り口です 3. ポジティブな印象で終われるようにする 「終わりよければすべてよし」という言葉もありますが、最後はなるべくポジティブな印象でおわれる構成になっているか注意をしています。 取り入れ方 感想をシェアしていただく ざっくり👍 👎 などの感情アンケートだと視覚的にわかりやすくおすすめです 自分からここが楽しかった・嬉しかったなどポジティブな感情を伝える 流れとして、ポジティブなテーマが最後にくるようにする オンラインでできるチームビルディングのアイディア 1〜3のポイントを意識してオリジナルの企画をすることもありますが、他の方がつくられた取り組みを使わせていただくことも多くあります。 活用をしたことがあるものや、今後トライしてみたい取り組みのキーワードを貼っておきます。 ※ 自分で全て見つけたわけではなく、まわりの方に教えていただいたキーワードも含めさせていただいています キーワード バリューズカード モチベーションポーカー ソーシャルスタイル診断 16 Personalities Belbin Model スキ・キライ・得意・苦手チャート まとめ 改めて、チームビルディングには正解がないからこそ、難しいですし面白いとも思っています。 今後もチームのみなさんと一緒に、色々なトライをしていきたいと思っています。 明日は、 shiiyan さんの記事が公開予定です。お楽しみに・・・！

この記事は BASE Advent Calendar 2022 の9日目の記事です 同日公開の（この活動にも参加してくださっている） @yuripiiiii さんの 「オンラインでのチームビルディングで意識をしていること」 もぜひご覧ください！ ごあいさつ はじめましての人ははじめまして、こんにちは！フロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です 今回の記事では1年近く継続して実施してきた、 プロダクトの細かな不具合や使いづらい部分を有志チームで改善していく「#iikanji-pkb-kaizen」という活動 についてご紹介します！ なかなか利益に繋がっているかが計測しづらく、組織の間にボールが落ちてしまいがちな細かい不具合対応や改善をチームとして対応するために「どのようなことを考えて」「どのように進めて来たのか」を共有することで、読んでいただいた皆さまの組織でも実践するヒントになれば嬉しいなと思っています！ 周辺の環境 まず初めに、この活動を行っていたチームとそれを取り巻く組織について組織について紹介します。 #iikanji-pkb-kaizen の「pkb」とは BASEというプロダクトに対して、様々な経路で受け取った改善要望をまとめている場所の「Product Kaizen Backlog（プロダクト改善バックログ）」の略称です。 現在はAsanaを使っていて、そこに予め用意したテンプレートの内容を埋めて、改善要望を登録してもらう形を取っています。 PKBがなかった頃は、CSへのお問い合わせで届いたフィードバック、BASEとしてショップ運営を有人サポートしているショップからのフィードバック、社内で気づいたちょっと気になる点などの様々な改善アイデア・改善要望が様々なツール上に散らばってしまっていました。 それらをまとめて確認出来るようにする場所を作ることと、正式なお問い合わせとは別に、ショップオーナー向けの管理画面下部から直接要望やフィードバックを送れる以下のようなフォームを作成するプロジェクトを遂行して現在の形になっています。 まだまだ運用方法を模索中ではありますが、一旦ここに蓄える。という場所ができたのは検索性・一覧性の観点からとても運用しやすくなりました。 組織構造の変化 この活動はもともと、 Owners Experience（以降、OXチーム）という「ショップオーナーさんのショップ運営の体験向上」にフォーカスした組織のメンバーが有志で集まって、 月曜朝と金曜夕方という、集中力が高まりにくい業務時間のウォーミングアップ&クールダウンとしてやりだした のが始まりです。 「プロジェクトのように数ヶ月単位でやるレベルじゃないけど、BASEへのお問い合わせなどでちょいちょい届く、BASEの使いにくい部分をガンガン改善していこう！」というモチベーションで始め、いずれ他の組織の人も集まっていければ良いね〜と実施していました。 そこから数ヶ月が経ち、ビジネス優先度と組織の全体最適化のために「目的別組織」への移行が進んで「OXチーム」という組織はなくなり、より具体的な「CRM」「Back Office」などの領域に紐づく目的別組織になりました。 結果として、現在では #iikanji-pkb-kaizen の参加メンバーは様々な部署から有志でPdM、デザイナー、バックエンドエンジニア、フロントエンドエンジニアが集まる形で合計6名で実施しています。 活動名の「iikanji」とは BASEのSlackコミュニケーションにおける文化として、Slackチャンネルをサクッと作って特定のトピックをそこでガッとコミュニケーションを取ろうという文化がありました。 「iikanji」というのは、そのSlackチャンネルを作る時に「プロジェクトでもないし、かといって何かが決まってるわけでもない、モヤッとした課題感を "イイ感じ" に解決していきたい」という感覚値を表したワードで、いつからかこれをSlackチャンネル名にプレフィックスとしてつけることが社内で慣習になっています。（プレフィックスをつけることで、こういった社内の有志活動を見つけやすくするという意図もあります） "#iikanji-pkb-kaizen" というチャンネルは上述の通り「OXチーム」がなくなったタイミングで、今までやってきた細かい改善の有志活動を引き続きやっていきたいという思いで作った形になります。 ちなみに、過去のテックブログには他にも #iikanji-agile や #iikanji-conference-toudan という活動について紹介された記事があるので、もしご興味があればぜひ読んでみてください！👀 運営してみてわかったこと、やったこと ここまでで「#iikanji-pkb-kaizen」という取り組みがどういうものなのかを紹介できたので、ここからは実際にこの活動を運営していて考えたこと、チームで実施したことを紹介していきます！ 9月のタイミングで行った振り返り OXチーム時代から続けてきた活動が #iikanji-pkb-kaizen という名前に変わり、約半年がたった今年9月末にこの活動の振り返りを実施しました。 まずはその振り返りをしている中で改めて見えた、言語化が出来ていなかったけどぼんやりと感じていた課題感について共有します。 1. 活動時間だけで進捗を出せている感じがしない これは週に2日1時間ずつ、それも週の頭と終わりの日に行っているので、ウォーミングアップとクールダウンという目的にはあっていたものの、活動の時間でタスクを進めるという目線だと、 思い出す時間の方が多くて作業が進まない… という声でした。 また、この会にはPdM、デザイナーの方も同じように参加してもらっていて、エンジニアに限らず彼らからも同様の声が上がっていました。 ですが、こういった声を振り返り会の中で深ぼってみると、それぞれ少し異なる原因があることがわかったので、2つの対応方針（後述）を決め運用してみることにしました。 2. 我々がやってることは新入社員向けオンボーディングタスクとなにが違う？ / カニバってない？ 少し話は変わりますが、BASEではありがたいことに2021年から2022年にかけて、月数名のエンジニアが新入社員として入社してくださる時期が続いていました。 そんな中で1つ問題になるのが、 「オンボーディング時にプロダクションコードを触るきっかけになるちょうど良い粒度のタスクが見つからない問題」 です。 「オンボーディングタスクを探すこと自体も大変だけど、そもそもこの活動でそういったちょうどいいタスクを消化してしまっていたらどうしよう…」という思いも頭のどこかにあり、この振り返りで議題に上がりました。 これに関しては、話している中で上記 1. の課題と同時に解決する方法（後述）が見つかったので、それを試してみることにしました。 3. タスクの管理方法がやりにくい これは、歴史的経緯と具体的なツールの話しになるので、あまり読者の皆さんの参考にならないかもしれません。 もともと #iikanji-pkb-kaizen では FigJam というホワイトボードツールに現在対応中のタスクを付箋にして貼る、作業が進んだら移動させる。という形を取っていました。 これは、チームやプロジェクトによってはAsanaを活用しているチームもあったものの、社内的にはまだ普及しきっていない + タスク管理をボードでカジュアルに行いたかった（+ 個人的な好み）ことから、 FigJam を使った運用を選択した形です。 しかし半年も経って、社内の覇権を握っているタスク管理ツールもツールに対しての参加メンバーの認識も変わってきたことから FigJam を使った運用はやりにくい！となったのです。 そのため、その場で FigJam のタスクボードはアーカイブとしてファイルだけ残した上で、Asana上で管理するように切り替えました。 振り返ってわかった課題とその解決策 活動時間だけで進捗を出せている感じがしない この課題感に関する根本原因を深ぼってみたところわかったのは、 「なんらかの機能全体の体験の改善を行うには、活動時間がそもそも足りない（思ったよりも規模が大きくなりがち）」 ということでした。 具体的には、以下のように2つのパターンで問題が起きていました。 ① エンジニア主導で進める場合、 業務フローの理解や調査、他チームへの確認が多くなってしまう ため、結果的に実装だけでないところに手がかかること（回答待ちが発生してなかなか実装に進めないことも） ② PdM・デザイナーが対応していた作業は 「そこやるならついでにここも直したい→規模が大きくなってしまう」パターンと、「近いうちにプロジェクト側で代替の対応が入るから触らなくてOKとなる」パターンが発生する ことでした。 これらの問題は、有志メンバー以外のプロジェクトやチームとのすり合わせが必要なために発生していたので、 #iikanji-pkb-kaizen で取り扱うもののスコープをもう少し絞り、運営体制としてはもくもく会のような形に移行することにしました。 エンジニア側は 「ゴールが明確で、実装対応と進捗把握がしやすい不具合の解消を進める」 。 PdM / デザイナー側は 「ショップオーナーから受け取ったフィードバックを整理し、対応方針・担当領域も含めてPKBのアイテムとして起票をする」 。 という部分にそれぞれフォーカスし、週2回もくもく会に集まったメンバーでそれぞれ上記のような対応をしつつ、別の職能の知識が必要な場合はもくもく会で適宜質問をし合えるという形に切り替えました。 運用方式を変えて得た効用 エンジニア側 エンジニア側で対応する「不具合」には以下のようなものが含まれるのですが、これらの対応は短い時間でも対応しやすく、サクサクとリリースすることが出来ました。 納品書ダウンロード App でダウンロードできるPDFファイルの決済方法の表示部分だけ外国語対応されない 商品詳細登録画面のスマホビューのときにだけ表示されるボタン文言が旧式の呼び方のままだった レビュー App の設定項目が新しいデザインテーマだと不要なのに表示されてしまっていた などなど… これまでに対応したものの中の一部ですが、上記であげたような細かな不具合は短い時間で解消〜リリースまで完了することが出来ました。 PdM・デザイナー側 こちらの運用方式の変更を図解すると、以下の図の紫色の枠で囲った部分をガンガン進めていくぞ！という形です。 この活動を行うことで、今までよりも対応要望の詳細度が上がったバックログアイテムがPKBに積まれることになります。 これによって #iikanji-pkb-kaizen に参加しているエンジニアが対応しやすいバックログアイテムが増えるというメリットはもちろん享受できたのですが、副次的に 我々がやってることは新入社員向けオンボーディングタスクとなにが違う？ / カニバってない？ という課題に対しての解決策にもなりました。 図では以下の紫色の枠で囲った部分が増え、オンボーディングタスクが必要な時はPKBから探す。という運用がしやすくなりました。 まとめ 以上、プロダクトの小さな負の部分を解消する「#iikanji-pkb-kaizen」という活動についての紹介でした！ こういった有志活動は「こうすれば活動がうまくいく！」「これが絶対的な正解だ！」というものを見つけるのはなかなか難しいと思っていて、会社全体の組織状態に合わせて臨機応変に対応していきながら、 なによりも継続し続けること が一番大事だと思っています。 なので、BASEでも1年近く有志活動をしているとこんな状況になって、こういうことを考えて解決していったよ！というケーススタディの材料として皆さんに知ってもらえればよいなと思ってこの記事を書かせていただきました。 今回紹介できた内容は、会社組織の状況に対するかなり対処療法的なものばかりでしたが、少しでも皆さんの参考になれば幸いです。 明日は同じチームの shiiyan さんの記事です！お楽しみに！

この記事は BASE アドベントカレンダー 2022 の8日目の記事です。 はじめに BASE BANK Section Dev Group Manager/ BASEカード Engineering Program Managerの松雪( @applepine1125 )です。 普段は BASEカード のEPMとして開発をリードしながら、BASE BANKがもつプロダクト開発チームそれぞれがガンガンアウトプットを出していけるように様々なサポートを行っています。 最近は、まだ日本であまり馴染みのないEngineering Program Managerについて色々とアウトプットしているので、特にマネジメント視点からアジリティの高いチーム作っていきたいぞ!という方は是非読んでいただけると幸いです。 プロダクトのデリバリー、クオリティに責任を持つEngineering Program Managerという役割 オーナーシップを持ち自己組織化するチームに必要な Engineering Program Managerという役割 今回は、BASE BANKでも掲げているフルサイクルエンジニア(Full Cycle Developer)というスタンスについて、定義だけでなく実際の仕事の中で見出した姿をお伝えします。 フルサイクルエンジニア(Full Cycle Developer)とは 2018年にNetflixが記事で公開し、日本でもCARTA Holdingsさんが訳してくださったことによりさらに広まりつつある概念です。 Full Cycle Developers at Netflix — Operate What You Build Netflixにおけるフルサイクル開発者―開発したものが運用する 上記記事の日本語訳 詳細な内容については上記記事に任せますが、要はこれまでソフトウェアライフサイクルの各段階を分業、専門化していた状態から、よりスピーディにプロダクトアウトプットし続けるために一連の段階を価値提供に関わるエンジニア、チームが責任を持ち、実行できるようにしようというスタンスです。 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 別にNetflixが提唱して初めてそういった働き方、関わり方が生まれたわけではなく、これまでも自律性の高いチームだったり、良くも悪くもカオスなチームに所属するメンバーは似たような働きをしていたのではないでしょうか。 プロダクトや事業を前にすすめるために、創るべきプロダクトについて考え、実装し、インフラや安定したリリースのためのCI/CDフローを構築し、効果測定のための分析基盤まで整備し開発のサイクルを回し続ける。 webアプリケーションエンジニアが担ってきたこの責務にNetflixがFull Cycle Developersという名前付けを行うことで、プロダクトアウトプットのサイクル全体をより能動的に効率よく回そうとする流れができつつあるのは喜ばしいことです。 フルサイクルエンジニアはフルスタックエンジニアなのか? フルサイクルエンジニアを志向する上で、よく話に上がるのがフルスタックエンジニアとの比較ではないでしょうか。 果たしてフルサイクルエンジニアを志向することはフルスタックエンジニアになることなのでしょうか? 個人的な意見ですが、結果的にフルスタックエンジニアになっていくことはあるものの、必須ではないと思っています。 フルサイクルエンジニアは “Operate what you build” (開発したものが運用する)というアプローチで、開発だけでなくテストや運用、様々なものを効率化します。 ここで重要なのは、 個人ではなくチームで 一連のサイクルをスピーディに回すことに取り組んでいることです。 全員が全技術領域において圧倒的なアウトプットができれば理想ですが、現実世界ではメンバーによってスキルや興味関心のある領域が異なるのは当たり前です。 そういった中で、CI/CDやテストなどの技術的なツールだけでなく、各メンバーの得意領域における知見やスキルもチームのツールの一つとして活用することで、チームとしてより良いアウトプットを生むことができます。 とはいえ、チーム内で技術的に完全に分業してしまうとこれまでのような専門化した分業体制をチーム内で再現することになるため、各メンバーが少なくとも各技術領域にチャレンジすることは求めるべきだと思っています。 プロダクトのために、自分の強みを活かしつつもその時々ですべきことを行っていくことで、いわゆるT字型のようなスキルセットをもったエンジニアになっていくことはあるでしょう。 フルサイクルエンジニアは専門性が身につかないのか? 広いプロダクトライフサイクル、技術領域に関わることで、器用貧乏になることを恐れている方を時々見かけます。 チームや会社の状況により、仕方なくいろいろな領域に関わらざるを得なくなった結果、自身の強みとなる領域を見つけられずもがくこともあるでしょう。 フルサイクルエンジニアの場合、より良いプロダクトアウトプットのために自ら様々な領域にチャレンジしていきます。 上でも書いたように、自身の強みをチームのツールの一つとして活かしながら、プロダクトのために実行できる領域を広げていけるように成長戦略を立てていくことで、技術的にも十分専門性を育てることができます。 とはいえ、チームとして分業体制がうまく構築され、いわゆる深いI型のスキルを持ったエンジニアに技術的な専門性で劣ると感じることもあるでしょう。 しかし様々なスキルをプロダクトのためにどう使いこなすか、それによってメンバーと共に成果を出し続けられることも十二分に専門性の高いスキルだと思っています。 個ではなくチームのアウトプットを最大化する 事業やプロダクトは常に成長圧力に晒されます。プロダクトの要求も複雑かつ柔軟に変化していきます。 自らの手だけで全領域実行できるようになったとしても、いつか個人の物理的なアウトプット量の限界にぶつかります。 素早い市場の変化、柔軟な要求の変化に追従し、リードしていくためにはチームで課題に取り組まなければなりません。 Some developers view design+development, and sometimes testing, as the primary way that they create value. This leads to the anti-pattern of viewing operations as a distraction, favoring short term fixes to operational and support issues so that they can get back to their “real job”. But the “real job” of full cycle developers is to use their software development expertise to solve problems across the full life cycle Netflixのブログでもこう言っているように、専門性を発揮しつつもあくまで チームとしてライフサイクル全体の問題を解決することにフォーカスする 必要があります。 そのなかで各個人に求められることは、少なくとも すべてのライフサイクルの段階にオーナーシップを持つこと です。 現実にはインフラ構築はSREの方に実行いただいたり、カスタマーサポートの方にユーザーのサポートをしていただいたりすることもあるでしょう。 そういった場合でもライフサイクル全体をより良くするためにステークホルダーとどうコラボレーションしたり、場合によってはチームの責務として巻き取れるか 主体的に 検討し実行することにより、個人だけではなくチームを強化することができます。 By combining all of these ideas together, we arrived at a model where a development team, equipped with amazing developer productivity tools, is responsible for the full software life cycle: design, development, test, deploy, operate, and support. 個人的にNetflixのブログ内のこの一節が好きです。 個人ではなくチーム なのです。 Netflixのエントリのタイトルも Full Cycle Developer ではなく Full Cycle Developer"s" であることにお気づきでしょうか。 developerが複数形であることに(勝手に)意味を感じ取っています。 プロダクト開発は基本的にチームで行います。チームがよりよい価値提供を目指して一丸となり、そのために個々人がチームに対しどういった貢献をするのか。そこをうまく組み立てることができれば、各々の強みを最大限に生かした、プロダクトへの様々な関わり方を生み出すことができます。 フルサイクルエンジニアとして働く意義、意味を創る ここまで主にメンバーの立場でフルサイクルエンジニアについてお話してきました。 ただプロダクトのためにやるべきことをやれ!では人は動きません。そこでマネジメントの腕の見せ所です。 チームとしてフルサイクルエンジニアとして取り組むことがインセンティブとなるように目標や評価を設計する必要があります。 個人が直接プロダクトに価値を与えていくだけでなく、解決すべき問題を見つけるための視点の時間軸を切り替えられるように、チームが余裕を持てるような投資も行っていく必要があります。 例えば、短期的に目の前のプロジェクトをなんとしてもスケジュール通りに終わらせることだけをひたすら求められた場合を考えてみましょう。 当然目の前のタスクに集中し、プロジェクトを完遂させるために払った技術的負債を返済する余裕もなく、ツールやスキルだけではどうにもならなくなります。 すると、短期的な視点で任された自分の仕事だけをこなすことに躍起になり、保守的な見積もりや越境を回避することによるディスコミュニケーションが多く発生するようになり、PMやビジネスサイドとエンジニアとの間で信頼関係が構築できずチームとして破綻していきます。 チームやメンバーは燃え尽きのリスクに晒され、プロダクトアウトプットのライフサイクルが破壊されてしまうのです。 とはいえ、長期的な視点で技術的な投資ばかりしていては事業は前にすすめることができません。 あくまでプロダクトアウトプットのためにどういった投資ができるか考え、それを実行したことで日々の開発がどのように効率化したか常に振り返り続ける必要があります。 直接事業を進めるための仕事と長期的な投資のバランスを取るためには、マネジメントをする人間が両方の視点を持ってうまく優先順位付けを行い、メンバーの成長をサポートし生き生きと働けるような環境づくりをする責任があります。 BASE BANKでのフルサイクルエンジニア像 色々と偉そうなことを書いてきましたが、我々BASE BANKチームもまだまだ発展途上の段階です。日々改善を積み重ねています。 BASE BANKチームはショップオーナーさんのキャッシュフローの課題解決を行うために2018年に誕生し、そこからYELL BANK、やBASEカードなどのプロダクトを生み出してきました。 新規事業立ち上げ、グロースを担うチームとして、最初から意識していたことはとにかく早くリリースし、素早く改善のサイクルを回し続けることです。 これを大前提として今に至るまで組織設計や技術選定、文化の醸成を行い続けています。 現在BASE BANKは全体で15名ほどのチームです。 そのうちエンジニアは10名で、下記組織図のようにDev Group内でBASE BANK管掌の3プロダクトごとにチームを分けています。(他にもチームはあるがBASE BANKに関係する組織構造だけ抜粋) プロダクトの意思決定に関わるメンバーを組織構造的にも近い位置に置き、よりスピーディにコミュニケーションを取り意思決定を進められるように組織設計をしています。 https://speakerdeck.com/base/basebank?slide=29 なぜやるのか考え、フィードバックループを通じて学び続ける エンジニアとして解くべき本質的な課題を発見し、フォーカスしてもらうために、なぜ今のような組織構造や開発プロセス、文化になっているのかについて深く腹落ちしてもらい、その上でチームの一員として何をすべきかを一緒に考え、アウトプットしています。 そして個人やチームがアウトプットの結果何を得られたか、何を改善すべきかを振り返りつづけられるようにサポートすることで、学びを積み重ね、発見する課題とそのアウトプットの質を高めていけるようにしています。 エンジニアチームのいわゆるレトロスペクティブのようなスプリントごとの振り返りだけでなく、様々なタイミング、粒度での振り返りやそこから生まれたネクストアクションの実行、そしてまた振り返り・・・といった積み重ねが、エンジニアに限らずBASE BANKチーム全体で当たり前のように行われています。 チーム全体でとにかく学び続ける。 これを徹底しています。 背中を任せ合う。コラボレーション BASE BANKのメンバーは、皆がプロダクトのライフサイクルすべてを完璧に回せる超人というわけではありません。 各々の強みを最大限に活かしながら、個ではなくチーム全体で高い生産性を維持、向上させ続け、まさに"個ではなくチームのアウトプットを最大化する"の項で書いたことを体現してくれています。 日々の開発のサイクルは各チームが主体的にまわしつつ、チームを横断しレビューや技術的なサポートと通じて背中を任せ合っています。 背中を任せ合うのはエンジニアに閉じた話ではなく、product group(事業企画やマーケティングを担うチーム)やdesign group(デザイナーが所属するチーム)とも密に連携しあい、よりスピーディに仕事をすすめるにはどうコラボレーションしていけばよいか?を日々の振り返りを通じてアップデートし続けています。 https://applepine1125.hatenablog.jp/entry/20220818/1660750909 個人的に昔書いた"みんなでアジャイル"の書評の中でもふれましたが、アジリティの高いチームであり続けるための原則の一つとして 早期から頻繁にコラボレーションするのがアジャイル というものが掲げられています。 変化に対し、チームとして柔軟に適応し続けるためには互いに密にサポートしあうのは当然の流れなのです。 越境 "フルサイクルエンジニアは専門性が身につかないのか?"の項で、T字型のスキルについて触れました。 フルサイクルエンジニアとして高いアウトプットを行い続けるためにはプロダクトに必要なことのために越境し続ける必要があります。 技術的なスキルに限った話だけではありません。必要なステークホルダーへのコミュニケーションなどチームの越境や、これまで持ったことのなかった範囲の責任を持ちチャレンジする越境など、様々な越境の形があります。 BASE BANKのメンバーは自分が関わるプロダクトにまつわる領域に高い興味関心をもち、積極的に越境しコミュニケーションを取り、主体的に仕事を前に進めてくれています。 その背景にはプロダクトやユーザーへの高い理解や、相互の信頼があるのかなと思っています。 とはいえ闇雲に越境し続けるとコンフォートゾーンを一気に突き抜けパニックゾーンにまで到達してしまい、越境から得た学びを積み重ねることができずに消耗してしまうこともあるでしょう。 そうならないためにも、自分がマネージャとしてOKRや日々のコミュニケーションを通してプロダクトの方向性とメンバーの志向をすり合わせ、チャレンジしてもらう範囲を着実に広げています。 信用、信頼 ここまで書いてきた学びのサイクル、背中を任せ合うこと、越境、すべての根底には互いへの強い信頼関係があります。 より柔軟にコミュニケーションを取り、学びを積み重ねながらスピーディにプロダクトや事業を前にすすめるためには、技術や経験だけではなく 互いの信用、信頼が何より重要 と考えています。 "フルサイクルエンジニアとして働く意義、意味を創る"の項でも書いたように、互いの信頼関係が構築できないと、越境することもなく、保守的になりプロダクトアウトプットのサイクルは鈍化していきます。成長もできません。 互いに信頼関係を構築するには手放しで任せ合うのではなく、日々の仕事を通じて互いに腹を割って議論し、成果を出し続ける必要があります。 腹を割ったコミュニケーションができるようになると、意思疎通がスムーズになるだけでなく、相手の理解も深まり、結果的に深い信頼関係を築く事ができます。 また社会人として至極当たり前の話ですが、約束を守り、成果を出し続けることで、信頼を積み重ねることができます。 これができるようになると、よくあるビジネスサイドとエンジニアサイドでやりたいことが食い違い衝突するようなこともなく、状況に応じて仕事の優先順位を適切にコントロールできるようになります。 チームとして仕事をする上で互いに深く理解し合い、頼り合える関係の構築を何より大事にしています。 おわりに 様々なツールが充実しエンジニア自身で実行できる範囲が広がる中、プロダクトのために越境し実行し続けるとフルサイクルエンジニアになっていくというのは自然な流れなのかなと思っています。 我々自身もまだよりよいチームづくりの途中です。今後事業やチームメンバーが増える中で様々な課題にぶつかることでしょう。 それでも互いに信頼関係を構築しあい、背中を預け合いながら、プロダクトのために何ができるか考え続ける姿勢さえ忘れなければ、どんな課題もこのチームであれば乗り越えていけるのではないかと思っています。 当然さらなる成長のためにより多くのメンバーの力も必要です。BASEやBASE BANKの事業、我々の働き方など少しでもご興味があれば気軽にお話しましょう! open.talentio.com 明日は @gatchan0807 @yuripi の記事が公開予定です、ぜひご覧ください!

はじめに 本記事は BASE アドベントカレンダー 2022 の8日目の記事です。 BASE BANKの @osushi_maguro 🍣です。 「BASEカード」というプロダクトのPMM（プロダクト・マーケティング・マネージャー）を担当しています。 『HUNTER×HUNTER』が大好きです。 今回は、ユーザーリサーチとABテストを通じて、 「BASEカード」 の効果的なメールマーケティングが実現した話をします🙋‍♀️ 　　 その前に……「BASEカード」って何？🤔 BASEカードは、BASEショップの売上を全国のVisa加盟店で「即時決済」できるカードです。 ショップオーナーさんは、 「振込申請をすることなくすぐに」「手数料をかけずに」 売上をご利用いただくことができます。 1分でわかる、「BASEカード」のきほん - BASE U｜ネットショップの開設・運営・集客のノウハウを学ぼう 　　 ユーザーリサーチ内容✏️ ユーザーリサーチは、3ステップでおこないました。 BASEカードのファネル分析： 「離脱が多いファネル」を把握する ヘビーユーザーへのインタビュー： ヘビーユーザーの「BASEカードに対する愛着」が強くなったきっかけやポイントを把握する 未発行ユーザーへのインタビュー： 1の調査により「発行ファネル」における離脱率が最も高いことがわかったため、発行の阻害要因を把握する 　　 ユーザーリサーチ結果💡 上記ユーザーリサーチの結果、わかったことが 3つ ありました。 BASEカードのヘビーユーザーは、主に 「法人化していない個人事業主の方」「BASEを副業として位置付けている方」 に多かった ヘビーユーザーにとって、BASEカードの最大の魅力は 「振込申請のペイン（入金までのリードタイムが長い・手数料がかかる）が解消されること」 未発行者はBASEカードを クレジットカードだと誤解 しており、「クレジットカード = 発行が面倒臭い・年会費がかかる」というイメージから発行に至っていない 以上から、BASEカードのマーケティング戦略として、 「現在のヘビーユーザーのような層をターゲットとし、クレジットカードのイメージを払拭しながら、振込申請のペインが解消されるというメリットを強調する」 という方針で施策を実行していくことにしました。 　　 ABテスト内容✏️：文面検証編 マーケティング施策として、まずはメールから始めることにしました。 発行ファネルの離脱率が高いことから送信対象を「未発行ユーザー」に絞り、 ユーザーリサーチ結果を踏まえて2種類の文面を用意し、テストをおこないました。 A.「 振込申請のペインが解消されること」を強調した内容 件名：振込手数料が無料になる「BASEカード」が発行できます！ BASEカード・振込申請の比較イメージを載せたもの（図の中央） B. 「クレジットカードではないこと」を強調した内容 件名：「BASEカード」（プリペイドカード）が発行できます！ BASEカード・クレジットカードの比較イメージを載せたもの（図の中央） 発行率が高かったのは、果たしてどちらの文面でしょうか？ 結果を見ていきましょう！ 　　 ABテスト結果💡：文面検証編 発行率が高かったのは A「 振込申請のペインが解消されること」を強調した内容 のメール文面でした。 振込申請と関連づけながらアプローチする方法は確実に効果がある 、ということがわかったので、続いてもう1つテストをおこないました。 　　 ABテスト内容✏️：タイミング検証編 前述のABテスト結果を受け、 「振込申請に対するペインが”特に”高まるタイミングにアプローチすると、さらに効果的なのでは……！？🥸」 と考えました。 そこで、 「振込申請に対するペインが”特に”高まるタイミング = 振込申請の直後」 と仮定したうえで、 振込申請をした かつ その当日に「振込申請のペイン解消を強調した内容」のメールを送信したグループ 振込申請をした かつ 上記メールを送信しなかったグループ 振込申請をしていない かつ 上記メールを送信したグループ 振込申請をしていない かつ 上記メールを送信しなかったグループ という4つのグループを作り、発行率を比較しました。 さて、こちらの結果はどうだったでしょうか？ 　　 ABテスト結果💡：タイミング検証編 発行率が高かったのは 「振込申請をした かつ その当日に上記メールを送信した」 グループと、 「振込申請をしていない かつ 上記メールを送信した」 グループでした。 振込申請した・しないにかかわらずメールを送ったグループの発行率が高かったことから、 送信タイミングが効果に及ぼす影響はあまり高くない = メールを送信すること自体が重要 だと思われます。 これは、個人的には結構意外でした😳 　　 おわりに 今回は、ユーザーリサーチ結果をクイックにアウトプットに活かせたこと・ABテストを経て効果的なメールマーケティングが実現したことが非常に良かったと思います。 また、「ユーザーの声からどんな仮説を作るか？」「どんな検証をおこなうか？」「検証の結果、何がわかったのか？」「仮説をどのように修正するか？」という点はまさにPMMの腕の見せ所で、緊張感がありつつも（あるからこそ）日々面白いと感じます。 今後はメールマーケティングにとどまらず、Web画面のUI/UX改善・プロダクトの機能改善にも着手し、BASEカードがユーザーにとって最高のプロダクトになるよう尽力していきたいと思います！ 明日は @gatchan0807 @yuripiiiii の記事が公開予定です、ぜひご覧ください。

カートチームを振り返る この記事はBASEアドベントカレンダーの7日目の記事です。 devblog.thebase.in Payment Dev Group マネージャーを担当している田仲（ @tosh ）です。 Payment Dev Groupは決済領域のプロダクト開発を担当しているグループになります。その中でも主にショッピングカート機能を担当しているカートチームについて、どういう経緯で生まれたのか、チームの役割や今後のことなどご紹介させてください。 カートチームについて BASEというECプラットフォームにおいて決済はサービスのコア領域になります。 BASEの中で決済は2つの方向性があると考えています。 ショップオーナーと購入者の間で行われる決済 BASEとショップオーナーの間で行われる決済 カートチームは前者のショップオーナーと購入者の間で行われる決済、システムの機能でいえば実際に商品が購入されるショッピングカート機能（以下、カート機能）をメインに担当しているチームで2022年7月に組成されました。 カートチーム組成のキッカケ BASEの課題としてEOLを迎えたフレームワークからの移行を進めています。その中でもカート機能はまず初めに移行が完了した機能になります。ですが、移行して終わりではありません。サービスは成長していくので併せて機能を改修していく必要がありますが、新しいアーキテクチャを理解せずに間違った方向で改修が進むと複雑な負債を生み出してしまう可能性もあります。またアラート対応やパッケージ更新などの日々の運用もあり下記のような課題がありました。 新しいアーキテクチャをどう適切に開発していくのか？ アラート対応やパッケージ更新などの運用はどうするか？ 上記の課題をカート機能をリニューアルしたエンジニアが有志的に対応していましたが、スケール面において好ましくない状況だったため、カートチームとして組成して、開発・運用・グロースを含めて責任を持つのが望ましい形なのではないかと考えた結果、リニューアルしたエンジニアを集めてカートチームが誕生しました。このチームをマネジメントする立場になったのですが、当初、私はチームトポロジーで紹介されているチームでいえば、コンプリケイテッド・サブシステムチームの役割をイメージしていました。 コンプリケイテッド・サブシステムチームとは、システムの中でスペシャリストの知識が必要となるパーツを開発、保守する責任を持つ。ほとんどのチームメンバーがその分野のスペシャリストでなければ、理解や変更が難しいようなサブシステムを担当するチームになります。 カート機能は決済が行われるサービスのコア機能であり、お金というユーザーのセンシティブな部分に関わることや決済を行う外部システムの仕様などを踏まえて開発するので専門的な知識が必要になります。そのため、この役割が良いと考えて他チームのカート領域の開発を巻き取り認知負荷を下げつつ責任を持って開発をしていけるように動き始めました。 進めていく中での課題 組成時の課題として巻き取るのは難しいのでは？というのがありましたが、案外いけるのではと思いカート機能に関わる案件を各チームからヒアリングしたのですが、やはり案件が多く当時のメンバーの数では案件を捌ききれない可能性が高い。またメンバーを増やすといってもカートチームに関わるチームは複数あり、採用は同じスピードで進むのでメンバーが不足している状況は続きそう。案件に優先順位を付けて対応していくことはできると思いますが、カートチームの対応待ちで他チームの開発が滞ってしまうとサービス成長を止めることに繋がり、本末転倒の話なので避けたいと考えていました。 イネイブリングチーム その課題を解決する上で役立ったのがイネイブリングチームのような役割のイメージでした。 イネイブリングチームとは、特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、プロダクトのデリバリー全体に関わる開発チームの能力ギャップを埋めるのを助ける役割のチームになります。 カート機能は専門的な知識が必要になる機能ではあるものの他チームの要件が絡んだ改修が入ることが多く、ビジネスに求められているプロダクトの成長を考えると一部のチームではなく開発チーム全体で改修していける体制がゴールだと考えました。新しいアーキテクチャを理解してもらいカート機能を他チームにも開発できるようになってもらう。周囲とのギャップを埋めていくための役割が良いのではないかと思い、メンバーから話を聞きながら下記の進め方が良さそうと判断をしました。 他チームの開発にカートチームのエンジニアが参加してカート機能開発を行う カートチームのエンジニアのサポートのもと、他チームにカート機能開発を行ってもらいカートチームがコードレビューすることで伝えながら品質を維持する 勉強会のようなものでアーキテクチャの理解を全体に展開することも検討しましたが、個人のスキル差は存在するので伝える粒度が難しいことや変更されていくため継続的なアクションが必要という観点があり、案件ベースで触ってもらいながら伝えていく方法を地道ですが選びました。 現在の状況 2022年7月にカートチームが組成してから5ヶ月目になります。組成時はまだ整理が追いつかずメンバーにマルチタスクをお願いすることもありましたが、現在は1つのタスクに集中しています。また他チームをサポートする体制も取れてきており他チームのメンバーにカート機能を伝えていくことも徐々にできていて、カートチーム要因で開発が遅れることは避けながらもカート機能の品質を維持するということは実現できています。採用に関しても自分たちでメンバーを増やしていくことできていて開始時は4人でしたが現在は8人になりました。 今後の課題 日々の問い合わせ対応やアプリケーションのアラート対応、パッケージ更新やデプロイなど、運用面は改善できると考えていて、チーム内でまだ偏りがある決済知識の平準化を含め、日々の問い合わせからの継続的な改善サイクル、ショップの増加と共に増えていく決済トランザクションをどう処理するか？という未来の課題に向けてのアクションなど。カートチームとしてカート機能・決済に責任を持って品質を維持することから高めていけるような取り組みを今後していきたいと考えています。 さいごに ここまで読んでいただきありがとうございました。 最後になりますがBASEを一緒に支えてくれるエンジニアを絶賛募集中です！ A-1.BASE_Webアプリケーションエンジニア／ショップオーナー向け開発 / BASE株式会社 A-1.BASE_エンジニアリングマネージャー / BASE株式会社 明日は @applepine1125 と @osushi_maguro の記事です。お楽しみに〜。

この記事は BASEアドベントカレンダー の7日目の記事です。 初めに こんにちは。Owners Marketingチームの竹本です。 この記事では最近BASEに入社した私がどのようなオンボーディングを経てBASEの開発フローやチームに馴染んでいったのかを紹介できればと思います。結論を先に言うとBASEのオンボーディングフローは非常に体験が良く、スピーディーにチームに溶け込めていけたという実感があります。これからBASEに入社される方や入社を検討される方の参考になれば幸いです。 自己紹介 改めましてBASEの竹本と申します。私は今年の10月15日にBASEに入社し、フロントエンドエンジニアとして働いています。所属はOwners Marketingというチームで、ネットショップを開きたいと思われている方にBASEを選んでいただけるような改善活動やネットショップ公開までを迷いなくスムーズに行えるような機能開発を行っているチームになります。 私は元々はバックエンドエンジニアで、主にPHPを書くエンジニアでした。少し前までフロントエンド領域の知識はjQueryとBEM程度の知識しかありませんでしたが、近年のフロントエンド領域の進化やエコシステムの広がりは興味を惹かれるものがあり、プライベートで現在主流となっているフロントエンド開発を体験してみたり、トレンドになっているOSSを覗いてみたりするようになりました。そんな中、運良く前職でPCアプリをElectronで新規開発するという案件に関わらせていただき、そこで改めてWebフロントエンドという領域の奥深さと幅広さを実感しました。その案件が落ち着いたタイミングでフロントエンドを主軸にやっていきたいと思い転職活動をしたところ、縁があってBASEに入社することになりました。 BASEは新卒の頃からPHP系のカンファレンスでよくお見かけしていましたし、テックブログも参考にさせていただいていたので、よく知っていた企業ではありました。BASEへの入社を検討するにあたって改めてそれらを見返し、入社の決め手となったのは以下の記事を読んで技術の幅を広げながら業務を楽しめそうだと感じたからになります。 次世代の管理画面を作るフロントエンドの取り組み BASEのノーコードはどのように実現されているのか？ 私のオンボーディング日記 ここからは私の入社初日からのオンボーディング体験を、日記形式でお届けします。 なお、以下の内容はあくまで私個人の話になりますので、オンボーディングフローは所属するチームやロールによって多少違うことにご留意ください。 1日目 コロナが落ち着いていたこともあって物理出社しました。オフィスに着くとチームメンバーとメンターの方が歓迎してくれました。普段はリモートワークでお仕事をされているそうですが、この日は顔合わせのために全員出社で迎えていただけたらしくとても嬉しかったです。 この日のお昼はチーム全員でひつまぶしを食べにいったのですが、そこである程度チームの雰囲気や人となりを知ることができたと思います。皆さん気さくで話しやすく技術に対して明るい方ばかりだったので、このチームなら上手くやっていけそうだとこの時から感じていたと思います。 帰ってきてSlackを覗いてみると onbording-takemoto チャンネルができており、入社時点でオンボーディング中になんでも聞けるチャンネルが用意されていて安心感がありました。「やるぞ〜」という気持ちが湧きましたね。 業務初日は自分のMacbookのセッティングをしたり、業務で使用するアカウントの申請を行ったりして終了となりました。 2日目 2日目は主に環境構築を行いました。BASEのローカル開発環境はDockerで構成されており、またセットアップ作業のほとんどがスクリプト化されていて、いくつかのコマンドを叩くだけで環境構築が完了します。途中、少しつまづくところもありましたが基本的にはドキュメントを読んだり、Slackで聞いたりすることですぐに解決しました。前職・前前職と環境構築は一大作業だったので、 特定の誰かに聞かないと作業が進められない という状況に陥らなかったことが振り返ってみて非常に良い体験だったなと思います。余った時間でリポジトリのREADMEを読んだり、コードリーディングしたりしていました。 3日目 環境構築も終了したところで、最初の開発タスクに取り掛かります。BASEでは入社してからできるだけ早く最初のリリースを行えるよう取り組んでいます。これはリリースするまで作業を通じてBASEの開発フローを理解してほしいという意図があります。これは非常にありがたく、開発に必要なドメイン知識の理解とタスク起票からリリースまでの作業フローを分けて考えることができました。私が最初に振られたタスクはある画面の文言の一部を修正するというものだったので、私はこのタスクに取り組む間、以下のような点を理解できるように努めました。 - タスクはどのように起票されるのか - これから触ることになるコードはどのようなディレクトリ構成でどのような書き方になっているか - PRを作る時のフォーマットはどうなっているのか - どのタイミングで誰にレビューを受けるのか - 社内開発環境へのアップロード方法と本番リリースの手順について 3日目は上記タスクをリリースできる状態まで持っていって終了しました。 4日目 いよいよ最初の修正をリリースします。BASEのリリース作業は完全に ChatOps 化されていて基本Slack上のみでリリースが行えるようになっています。今回は修正内容が軽微だったので動作確認する項目もほとんどなく、スムーズにリリースに行うことができました。この時は入社してわずか4日目で最初のリリースができたことに感動しました。デプロイを高速・高頻度に行える工夫が随所にあり、新しく入った人でもリリースを行える仕組みがあったのでサービスの改善を高速に回していけそうだなと感じました。 5日目以降 5日目以降は時々入る新入社員向けの研修を除けば、オンボーディング感がグッと薄くなった感覚がありました。BASEの開発チームの多くはスクラム開発を採用していて、私のチームでもスクラム開発を行なっています。入社から1週間が経つ頃にはメンターやチームメンバーのサポートを受けながらではありますがスプリントバックログにあるタスクを普通にこなすようになっていました。スクラム開発に加わってからもSlackのオンボーディングチャンネルは存在していましたし、EM・メンターと毎週1on1が設定されていたので、疑問や不安を抱えたりすることはありませんでした。 オンボーディングで良かったところ ここからは私が体験したオンボーディングフローで良かったと感じた点を挙げていきます。 質問・相談しやすい雰囲気がある 前述の通り、BASEでは入社するとSlackに onbording-〇〇san チャンネルが出来ます。 分からないところや疑問に思ったことはこのオンボーディングチャンネルで呟くと、チームメンバーがこれでもかというくらい親切に教えてくれます。メンターの存在も相まって、 分からないことが出てきても大丈夫 という安心感がありました。 ドキュメントが整備されている 誰かに聞かないと作業を進められない状況がオンボーディング期間に起こると誰に聞いていいのかわからず、ストレスになりがちです。BASEでは業務で知っておくべきことは基本的に社内WikiかリポジトリのREADMEに分かりやすい形でまとまっているので、少なくとも私はこの事態に陥らずに済みました。普段からドキュメントをメンテしてくれる人たちに感謝しかありません。 社内の人と交流を持てる制度がある BASEでは メンターランチ という制度があります。これは新入社員が社内の人とランチした時に、その費用を会社が負担してくれるという制度になります。この制度を使って普段業務で関わることのない人と交流を持つことができました。リモート環境下で社内のつながりが希薄になる中、こういう制度があることはとてもありがたかったです。 今後より良くしていくために 私の所属するOwners Marketingチームは比較的最近発足した若いチームで、私の入社後にも２名ほどチームにジョインされた方がいました。短い期間でオンボーディングが立て続けに発生したので、躓きやすいポイントやドキュメントの意図が正しく伝わっていない点が徐々に明確になってきました。これについては現在ドキュメントやオンボーディングフローの見直しが進められていて、次に入社される方にはより良いオンボーディングを行えるようになっていると思います。 終わりに 冒頭にも書きましたが最高のオンボーディング体験でした。入社から1週間も経たないうちに最初のリリース、スクラム開発の参加、チーム外の人との交流と盛りだくさんの内容をこなせて充実した日々を過ごせました。 BASEは このブログ や Youtube , 技術カンファレンス等で積極的に業務で取り組んでいることを公開しています。私がBASEに入社するきっかけになったのもこれらのアウトプットから会社として取り組んでいることや課題について知ることができたからでした。この記事もまた「BASE気になってるけど入ったらどんな感じなんだろう」と思われる方の参考になってくれると嬉しいですね。BASEのサービスや技術的な取り組みが気になった方は、ぜひ他の記事やYoutubeも覗いてみていってください。 ここまで読んでいただいてありがとうございました！ 明日は松雪さんの「Real World Full Cycle Developers」と@osushi_maguro さんの「ユーザーリサーチを活かしたメールマーケティング」の2本立てです！お楽しみに！

はじめに 本記事は BASE アドベントカレンダー 2022 の6日目の記事です。 はじめまして！BASE株式会社で、ネットショップ作成サービス「BASE」のプロダクトチームのマネージャーをしている @yusaku と申します。記事を書くに当たって、自分がいままでやった1on1を振り返りつつ、数えてみました。   時期によってもちろん変動はあるのでざっくり試算ではありますが、社内では自分の組織でのメンバーや上長と週1回の15分〜30分の1on1、新しく入社して頂いた方がいるオンボーディング時では毎日15分の1on1を行っていたので、週5~15回くらい1on1していました。またプライベートでは、プロコーチとしてパーソナルコーチングも行っており、2022年では100回ほど1on1を行っていたので、 合わせて500回以上は1on1をしていました。 その結果わかった1on1で大事なこと を記事にしていきたいと思います。自分なりに大事なことを言語化することで、普段1on1をしている方の助けに少しでもなれば幸いです。 1on1ってなんだろう 最近では1on1に関する本（ yahooの1on1 や、 シリコンバレー流1on1 ）もよく目にするようになりましたが、そもそも1on1とは 「上司と部下が定期的に行う、”アジェンダのない”1対1のミーティング」 のことです。 一般的には週に１回、少なくとも月に１回の頻度で行われ、もともとシリコンバレーで生まれたマネジメント方法ですが、国内でも多く取り入れられています。 BASEでも、もちろん行われており、月1回30分以上行うことを推奨しています。 1on1ってなんのためにやるの？ では、1on1はなんのために行われるのでしょうか？ 進捗報告？ 　→いいえ。チーム全体でやったほうが効率が高いはずです。 目標設定？ 　→いいえ。すでに決まった目標であれば、ドキュメントでの共有でいいはずです。また目標は週ごとに変わるものではないですよね。 雑談？ 　→いいえ。雑談であれば、ランチや立ち話、懇親会でもよいのではないでしょうか。 1on1は「メンバーのための時間」 です。 個人的にさらに補足すると、気づきが生まれ行動や経験や学びが促進されるための時間だと捉えています。週1で30分の時間は１ヶ月の割合にしたらたったの1〜2%の時間でしかないので、1on1以外の時間における、行動や経験にどれだけ影響できるかが大事です。 話を聞けていない状態が最も危険 行動や経験を促進するメンバーのための時間である1on1にも関わらず、上司が話を聞けていない1on1が、最も危険な状態です。オンラインだからといって、Slackなどのコミュニケーションツールを見ながら相手の話を聞いていたことはありませんか？ 話を聞けないと、信頼関係を損ない、心理的安全性が担保できず、下記の３つの危険な状態に陥ります。 リスクに気が付けない →心の声「ちょっと不安なことがあるけど言い出しづらいな、また今度でいっか。」 組織と個人のWillがどんどんズレていく →心の声「なんか納得言ってないけど、相談してもムダだし、話すのは控えよう」 新しいことが生まれない →心の声「やりたいことを思いついたけど、提案しても詰められそうだし、失敗したら怒られそう。相談するのは辞めていこう。」 このような状態にならないように、ここからやってみると良いというポイントを考えてみました。 相手の話をちゃんと”聞く”ことからトライしてみよう 大事なことは、相手の話をちゃんと”聞く”ことです。そのためには、 ①言葉以外にも集中して聞く ②反応する」 ③キーワードに気づく という３つのポイントがあります。このポイントからトライしてもらえると良いと思います。 ①言葉以外にも集中して聞く 人の話を聞くということに対して、実は３段階のレベルが存在します。 レベル１ 相手の話を聞き（聞いたフリをし）ながら、自分のことなど相手以外のことを考えている状態です。例えば、「1on1中に、PCを開きながらSlackなどを追いながら聞く」のは、まさにレベル1の状態と言えます。 レベル２ ちゃんと相手の言葉を理解するべく話を聞けている状態です。このレベル２から話を聞いている状態と言えます。自分主体ではなく相手が主体であることが重要です。 レベル３ 相手の言葉だけでなく態度や雰囲気も含めて聞く ことができている状態です。 例えば「大丈夫」という言葉1つとっても「大丈夫です…」「大丈夫です！！！！！」といった話し方や表情で、どういう気持ちで話しているかは違うはずです。（字で雰囲気を伝えるのが難しいですが） このレベル３の状態を意識して、話を聞くことが重要です。 ②反応する 話を聞くときに心がけてほしい次のポイントは、聞いている際に 「相槌」「オウム返し」「フィードバック」 といった、話を聞いている反応を行うということです。 例 相槌 ：うなずき。「なるほど」「うんうん」といった反応 オウム返し ：相手が行ったことをそのまま繰り返す反応。 ex)「ちょっと最近忙しいんです…」→「忙しいんだね」→「そうなんです。◯◯に追われてて〜」 フィードバック ：相手の態度や雰囲気について言及するという反応。「今日はなんか楽しそうだね！」「なにか焦っているように見えるよ」 話に対して反応することは、話を聞いてくれているという 相手への安心感を生みます 。双方向に会話していく上で重要なことなので、最初はわざとらしいかもと思っても、まずはやってみることをオススメします。 ③キーワードに気づく 話を聞いていると、この単語ってどういう意味や意図で使ってるのかな？ということが必ずでてきます。知っている情報やバックグラウンドが異なるので、 人によって意味が異なる ことは多いです。 そこから認識がずれていくこともあるので、そういった単語をキーワードとして拾ってみて、「ちなみに、◯◯ってどういう意味あいで使ってる？」などと聞きましょう。そこから 認識をすり合わせて行くことが始まる ので、そういったキーワードを拾っていこうとする姿勢で話を聞きましょう。 話を聞くことによる変化 実際に自分が経験したエピソードを一例としてシェアします。（個人の話なのでかなり抽象的ですがご了承ください。） --- その人は、いつもいつもなにかに追われていて「忙しい」をよく口にしていました。1on1もシンプルに終わることが多く、1on1が進捗報告の時間になっていました。 ただ愚直に話を聞き続けた結果、少しずつ「なぜ忙しいのか」という自分の課題に対して話してくれるようになりました。 よくよく話を聞いてみると「期待に答えるために、自分がなんでもやらなければいけない」と思っていることに気づき、その結果「周囲に頼れていない」「自分で抱え込みすぎてパンク」している状態になっていることがわかりました。 そこからは、自分が完璧である必要はないことを強く意識して、周囲に頼むハードルを下げるために積極的にコミュニケーションを取るなど、周りの情報を取りに行く行動を多くするようになっていきました。 --- 1on1で話を聞くことで気づきが生まれたり変化が生まれたエピソードとして参考になれば幸いです。 まとめ 今回は話を聞けていない状態に対して、まずトライして欲しい３つのポイントについて記事にしてみました。 人の話を聞くことは、 相手への興味を持つこと 思います。相手に興味があれば、話は自然に聞けますし、相手に気づくことも増えます。ぜひ相手への興味を大事にしながら、相手の話を聞く姿勢に向き合ってみることから初めてみてください。 明日は satoshi_takemoto の記事が公開予定です、ぜひご覧ください。

はじめに はじめまして。エンジニアの近藤( @kon_engineer )と申します。本記事は BASE アドベントカレンダー 2022 の6日目の記事です。 本記事では、私が苦い経験から学んだ、スクラム開発で未来の落とし穴を回避する考え方について書きたいと思います。具体的には、ユーザーストーリーの優先度を決めるとき、ユーザーにとってどれだけ価値を提供するかという視点だけでなく、プロジェクトとして何がリスクで、それを回避するために何からやっていくのか、しっかりバランスを考えるべきだった、という経験談を記載します。また、本記事で事例として記載するスクラム開発は、1スプリントごとにリリースする形ではなく、スプリントをある程度回して、大きな機能が出来上がったら都度リリースしていたスクラム開発の形式になります。 ユーザーストーリーについて ユーザーストーリーは、システムがユーザーに届ける価値を表現するものです。例えば、ショップオーナーは、管理画面で任意の配送可能日時を指定して、ショップに反映することができる、といった形で、登場人物が何をできるのか明確にするものであり、スクラムチームがスプリントで達成するべき重要なものと思います。 ユーザーストーリーの優先度について ユーザーストーリーの優先度を決めるためには、いくつもの考え方があると思います。私たちのチームでは、ユーザーにとって最も重要で、このストーリーがなければ後のストーリーは成り立たないものの優先度を高くしていました。この判断基準自体は間違っていなかったと思います。ただ、優先度としては後半に取り組むストーリーで、一度もチームメンバーが触ったことのない領域の開発がありました。その時は、優先度も高くないし、それほど難しい機能でもないから何とかなるだろうと思い、あまり注視していませんでした。これは良くなかったです。 リリース手前のスプリントで初めて大変さに気づく リリースも近くなったスプリントで、今まで経験がないBASEの領域の開発を行いました。その結果、修正量は少なかったとしても、その領域を深くまで理解していなければ影響範囲が読めず、開発が自分達にとって難しいことがこのタイミングで分かりました。結局、当初の見積りより倍以上の時間がかかってしまい、チームメンバーに助けられてなんとかリリースに間に合った、というギリギリの開発になってしまいました。開発を進めていくと実は大変だったというのはあるあるですが、元々知見がないのは分かっていたので、もう少しやりようがあったと思います。 どうすればよかったのか 懸念があるユーザーストーリーの優先度は上げる 今回の事例では、機能としての優先度が高くないストーリーであったため、詳しくない領域の開発を後ろに回してしまいました。しかし、プロジェクトとして事前に不確かな部分、不安な部分を早めに潰して安定した開発をすることは、ユーザーにとって優先度の高い機能を開発することよりも、時として重要であると考えます。なぜなら、懸念を後回しにすることで、プロジェクトの失敗確率が上がったり、全体の工数が伸びてしまうのであれば、長い目で見るとユーザーにとっても不利益であるためです。もちろん、ただ分からないからという理由で、闇雲に優先度を上げることはよくありませんが、プロジェクトの懸念が払拭されて成功率が高まるのであれば、今やった方が良いと思ったものは、優先度を上げる検討をした方が良いと思います。 懸念があるユーザーストーリーとはどういうものかについて、もう少し補足したいと思います。私が考えるものは、以下の図でユーザーストーリーBにあたるものです。 ユーザーストーリーの重要度はCの方が上であるが、ユーザーストーリーBは例えば使ったことがない技術を使用する必要があるとか、外部サービスと連携しなければならなくて、その調査が必要であるといったことで、考えなければいけない課題が多く存在するような状態です。この場合は、ユーザーストーリーCよりも先んじてBをやった方が良い場合があると考えます。 調査タスクを切る ユーザーにとって重要なストーリーから届けたい、しかし技術的に懸念があるストーリーなどは事前に備えておきたい場合に、当該ストーリーの調査タスクだけ切って、先に問題がないか確認することも有効だと思います。一度もチームメンバーが開発したことのない領域や技術であったり、技術的に実現できるのか分からない課題がある場合、後々何かしら問題が起きる場合があります。特に手戻りが発生して、すでに開発もしくはリリースしたストーリーに影響する事態は避けたいので、今取り組んでいる優先度の高いストーリーを安心して進めるために、事前調査して懸念を払拭しておきます。 ユーザーストーリーの優先度は常に見直す ユーザーストーリーの優先度は、最初に決めたら動かさないものではなく、状況によって柔軟に変更すべきものだと思います。今回の事例では、一度決めた優先度でそのまま開発を進めてしまっていました。ユーザーストーリーの優先度を見直す機会を設けていれば、そういえばこのユーザーストーリーは懸念はないかなど、改めて議論する場が用意されるので、もう少し早めに開発する上で懸念があることに気づけたかもしれません。 おわりに 本記事では、自分の経験を通じて、スクラム開発におけるユーザーストーリーの優先度決めについて記載いたしました。読んでいただいた方の助けに少しでもなれば幸いです。 明日はsatoshi_takemotoさんとtoshさんの記事が公開予定です、ぜひご覧ください。

この記事はBASEアドベントカレンダーの5日目の記事です。 こんにちは！BASEのCRM３チームでバックエンド開発を担当している オリバ( @toshi_oliver )です。2022年11月に入社したので、今回が初のブログとなります。 はじめに 前提 環境構築 デプロイ おわりに はじめに devblog.thebase.in さて、今回はAWSのサーバレスサービスを代表すると言っても過言ではない、AWS Lambda（以下、Lambda）に関する記事を投稿します。 BASEのバックエンドの大部分はPHPで開発されており、システムの一部にLambdaを使用しているのですが、Lambdaのランタイムでサポートされている言語は以下となっております。 Node.js Python Ruby Java Go .NET Core ご覧の通り、PHPはサポートされておりません。 では、PHPの使用は断念しなければならないのかというとそうではなく、カスタムランタイムを使用することでPHPの使用が可能となります。 しかし、 公式ドキュメント を見ると、ランタイム用のbootstrapファイルやシェルファイルを用意し、それをzip化しさらにLambdaレイヤー化する必要があります。 Lambdaはプログラム開発に集中するためのサービスであるにも関わらず、PHPを選択することで手間が増えてしまうのは本末転倒であります。 また、 公式ブログ によりコンテナイメージを使用する手段もありますが、DockerfileとBootstrapファイルの管理が必要となるため、やや手間が増えます。 そこで、本記事ではLambdaにてPHPのカスタムランタイム環境を簡単に構築できる、 bref を紹介します。 前提 anyenv(1.1.5) phpenv(v0.9.0-rc.1) PHP(8.1.0) AWS CLI(2.9.1) SAM CLI(1.65.0) bref(v1.7) 環境構築 空のディレクトリ上でComposerを使ってbrefをインストールします。 $ composer require bref/bref プロジェクトの初期化を行います。 $ vendor/bin/bref init 以下のメッセージが出力されます。brefでは、Webアプリケーション用またはイベントドリブン関数用のLambdaのどちらかを構築するか選択できるので、今回は 1 を選択します。 What kind of lambda do you want to create? ( you will be able to add more functions later by editing `serverless.yml` ) [ Web application ] : [ 0 ] Web application [ 1 ] Event-driven function ディレクトリ配下に以下のファイルが生成されました。 ├── sserverless.yml ├── vendor │ └── async-aws │ └── ... ├── composer.json ├── composer.lock └── index.php デフォルトで serverless.yml が生成されます。これはサーバレスのIacツールである Serverless Framework (以下、sls)で必要となるテンプレートファイルです。今回はIacツールにAWS SAM（以下、SAM）を使用するので、serverless.ymlを削除しSAM用のtemplete.yamlを作成します template.yamlのLayersパラメータに、 bref公式ドキュメント に紹介されているLambda Layerの最新ARNを指定します。今回は arn:aws:lambda:ap-northeast-1:209497400698:layer:php-81:34 を指定します。注意してほしいのが、Webアプリケーション用とイベントドリブン用で対象のARNが異なっており、Webアプリケーション用を選択した場合は php-81-fpm:34 用のARNを選択する必要があります Runtimeに provided.al2 を指定しておりますが、これはAWS が提供するパブリックの ECR に配備されている provided:al2 のイメージをベースイメージとして指定しています template.yaml AWSTemplateFormatVersion : '2010-09-09' Transform : AWS::Serverless-2016-10-31 Description : Sample SAM Template for handson-bref Globals : Function : Timeout : 3 Resources : HelloWorldFunction : Type : AWS::Serverless::Function Properties : FunctionName : hello-world-function CodeUri : . Runtime : provided.al2 Handler : index.php MemorySize : 1024 Timeout : 30 Layers : - arn:aws:lambda:ap-northeast-1:209497400698:layer:php-81:34 index.php <?php declare ( strict_types = 1 ) ; require __DIR__ . '/vendor/autoload.php' ; return function ( $ event ) { return 'Hello ' . ( $ event [ 'name' ] ?? 'world' ) ; } ; デプロイ BASEではサーバレスのIac管理をSAMで行うことが多いので、SAMを使用したデプロイを実施します。 本来なら sam build を使用してビルドを行いたいのですが、カスタムランタイムを設定している場合はmakefileを自身で用意する必要があり手間がかかってしまうので、Lambdaパッケージ用のS3バケットを用意します $ aws s3 mb s3://furukawa-bref-test --profile {任意} SAM CLIを使用してパッケージングを行います。 $ sam package \ --template-file template.yaml \ --output-template-file bref-output.yaml \ --s3-bucket furukawa-bref-test \ --profile { 任意 } SAM CLIを使用してデプロイを行います。 $ sam deploy --template-file bref-output.yaml \ --stack-name furukawa-bref-test --profile { 任意 } --capabilities CAPABILITY_IAM デプロイが完了したので、Lambdaコンソール上で試しにテストを行います。 問題なくLambda関数を実行できました。 おわりに brefを使用することで、DockerfileとBootstrapを使用せずに、LambdaランタイムをPHPに設定することができました。ただし、brefを使用する際に以下の点に注意が必要です。 brefで用意されているLambda Layerを使用すると、sam buildを使用したデプロイができない bref(v1.7)ではarm64に対応していない GitHub Issue によると、β版のbref(v2.0)ではarm64に対応するようなので、もうしばらく時間が必要 Lambda LayerのARNに、${bref:layer.php-81}を指定することでPHP8.1の最新のマイナーバージョンを取得してくれるが、 slsのみの対応 次回は、brefを使用してSlackbotを作ってみたいと思います。 明日は、kondo.hirotakaさん、yusakuさんの記事です。お楽しみに！！

Vue 2 でコンポーネントテストを書くために こんにちは。プログラミングをするパンダ（ @Panda_Program ）です。本記事は BASE アドベントカレンダー 2022 の4日目の記事です。 本記事では Vue 2 + TypeScript 環境に Testing Library を導入する方法をご紹介します。なお、Testing Library の使い方については本記事では触れていません。当該ツールの具体的な利用方法を知りたい方は 公式ドキュメント をご覧ください。 Testing Library とは何か Testing Library は Kent C. Dodds 氏が作成したコンポーネントテスト用のフレームワークです。 test-utils など他のテスト用フレームワークと異なり、コンポーネントの内部実装を意識する必要がなく、ユーザーがアプリケーションを使用する観点からテストを記述できる点に特徴があります。 以下で test-utils と Testing Library の公式ドキュメントからテスト記述例をピックアップして見ました。以下は完全に同等のテストではないですが、書き味や設計思想が異なる様子がテストコードから見て取れます。 vue test utils のテスト実装例 import { shallowMount } from '@vue/test-utils' import HelloWorld from '../HelloWorld.vue' describe ( 'HelloWorld.vue' , () => { test ( 'renders props.msg when passed' , () => { const msg = 'new message' const wrapper = shallowMount ( HelloWorld , { propsData: { msg } } ) expect ( wrapper.text ()) .toMatch ( msg ) } ) } ) Testing Library のテスト実装例 import { render , fireEvent } from '@testing-library/vue' import Component from './Component.vue' test ( 'increments value on click' , async () => { const { getByText } = render ( Component ) getByText ( 'Times clicked: 0' ) const button = getByText ( 'increment' ) await fireEvent.click ( button ) await fireEvent.click ( button ) getByText ( 'Times clicked: 2' ) } ) Vue でコンポーネントテストを記述するのであれば、少し前までは test-utils というツールを使うのが一般的でした。 しかし、Vue 3 の 公式ドキュメントが Testing Library を推奨していること 、2022年現在では React でテストを書くにあたり Testing Library がまず選ばれること、 Storybook を使ったインタラクションのテスト や Cypress を使ったE2Eテストの記述に Testing Library が使えること から、フロントエンドのテスト実装方法の主流を学べるのみならず、コンポーネントテスト以外にも応用できる知識が得られると考えてこちらを採用しました。 Testing Library は Vue 向けの Vue Testing Library を用意しており、これは test-utils を薄くラップして Testing Library 方式でテストの記述を可能にしたものです。Vue Testing Library は Vue 3 向けのみならず、最新ではないものの Vue 2 にも対応したバージョンが存在します。 ところが、次で説明するように Vue Testing Library をインストールしただけでは弊社の Vue 2 環境で Testing Library は動作しませんでした。そこで、以下では Vue 2 環境でテストを実行可能にするために実施した工夫を紹介します。 Testing Library を Vue 2 に導入する Testing Library Vue が使えなかった理由 Testing Library Vue が使えなかった理由を簡単に記します。 Testing Library の公式ドキュメントによると、Vue 2 では @testing-library/vue@5 を使うことを求められています。2022年12月時点で @testing-library/vue v5 の最新バージョンは v5.8.3（以下、5系と呼ぶ） です。 この Vue 2 対応の5系ではライブラリ側で Vuex に対する依存が明示的に存在しており、これが弊社の環境で5系の動作しない原因でした。 render.js 内の以下のコード store が必ず Vuex に限定される ため、テストを実行すると Vuex 関連のエラーが発生するのです。 // src/render.js export function render ( ... ) { /// ...省略 if ( store ) { const Vuex = require ( 'vuex' ) localVue.use ( Vuex ) vuexStore = store instanceof Vuex.Store ? store : new Vuex.Store ( store ) } /// ...省略 } BASE では、コンポーネントを跨ぐグローバルな状態管理に独自実装の Store を利用しています。これは弊社のプリンシパルテックリードである @ukyo が TypeScript で実装したものです。同期処理、非同期処理をシンプルに分けられて使いやすく型補完が効く上に、目まぐるしく変わるフロントエンドのトレンドや、「Vuex は辛い」「最近は Pinia（ピーニャ） がいいらしい」など Vue コミュニティの動向を気にすることなく、サービス開発に集中できる代物です（なお、現在は社内での利用のみを想定しており、OSSとして公開していません）。 つまり、弊社では Vuex を使用していません。ただし、ライブラリ側の制約から Store に Vuex を 利用しないと Store に接続するコンポーネントのテストが不可能です。 そこでチーム内で検討した結果、Testing Library Vue の render.js をコピーして一部書き換えることにより、Vuex への依存を不要としつつ Testing Library を利用したテストを書けるようにする対策を取ることを決めました。フォークしたりコードをコピーするデメリットよりも、コンポーネントのテストを書いてリグレッションに備えるというメリットが上回ると考えた結果の意思決定でした。 Vue 2 で Testing Library のテストを書くための対策 弊社のVue 2 環境で Vue Testing Library に依存せず Testing Library のテストを書くための具体的な対策は2つあります。 1つ目は render.js の Vuex 依存の箇所を削除することです。これはあまり特筆することはありません。まず Testing Library Vue の src 配下のファイル index.js fire-event.js render.js をプロジェクトにコピーし、前記の render.js の Vuex 依存箇所を削除しました。 そして、export された render 関数を使ってコンポーネントテストを記述したところ、Vuex 関連のエラーは解消されました。 しかし、グローバルなコンポーネントである社内向け共通コンポーネント集 BBQ を利用したコンポーネントに対するテストや、 Vue Router を使ったルーティングのテストを記述するにあたり、別のエラーに遭遇しました。これらを一つ一つ解消していき、最終的に出来上がった関数が2つ目の対策です。 それは、render.js をラップする関数 customRender を作ったことです。この関数の責務は、Store や Props を引数として render 関数に渡したり、グローバルなコンポーネントを登録する処理を実行することです。 // custom-render.ts import BBQ from '@baseinc/bbq' import { Store } from '@web/vue-store' import { createLocalVue } from '@vue/test-utils' import { I18n } from '@web/shopadmin' import Vue from 'vue' import VueRouter , { RouteConfig } from 'vue-router' import VeeValidate from 'vee-validate' import { render } from './render' import { addCustumValidators , getCustomOptions } from '../vee-validator-setup' type State = Parameters <typeof Store.create > [ 0 ] type Options = { initialState: State // Store の初期状態 props?: Record < string , any > // コンポーネントに渡す Props routes?: VueRouter | RouteConfig [] // ルーティングの定義 } type ConfigurationOption = { localVueOption?: ( localVue: Vue ) => void storeOption?: ( store: State ) => void routerOption?: ( router: VueRouter ) => void } export const customRender = < V extends Vue >( component: any , // this makes me sad :sob: // https://github.com/testing-library/vue-testing-library/blob/main/types/index.d.ts#L51 { initialState , props , routes } : Options , { localVueOption , storeOption , routerOption } : ConfigurationOption = {} ) => { const localVue = createLocalVue () // バリデーションライブラリの登録 addCustumValidators () localVue.use ( VeeValidate , getCustomOptions ()) // 社内共通コンポーネント集の登録 localVue.use ( BBQ , { prefix: 'bbq-' , } ) // Store の登録 localVue.use ( Store ) // i18n 対応 localVue.use ( I18n ) return render ( component , { localVue , store: Store.create ( initialState ), routes , props , } , // この第3引数は Testing Library Vue の v.5.8.3 の render 関数の第3引数に合わせている ( localVue: Vue , store: State , router: VueRouter ) => { localVueOption?. ( localVue ) storeOption?. ( store ) routerOption?. ( router ) } ) } customRender 関数を使ったテストの記述例を掲載します。これは名前の入力欄に空文字を書き込んだ時、バリデーションエラーとなりエラー文言が表示されるというテストです。input で入力した内容は直接 Store で管理しています。 import { customRender as render } from '../custom-render' test ( '名前が空欄の時、エラー文言を表示する' , async () => { render ( Component , { initialState: getInitialState () } ) const input = screen.getByLabelText ( /名前/i ) await fireEvent.update ( input , '' ) expect ( screen.queryByText ( '名前を入力してください' )) .toBeInTheDocument () } ) このテストが正常にパスすることにより、「BASE の独自 Store に接続したコンポーネントに対するテストが可能なこと」「グローバルなバリデーションライブラリのインタラクションがテストできること」「input は社内共通コンポーネント由来であるが、それに依存するコンポーネントのテストができること」の3点が確認できました。 なお、普段 React を書いている方向けに補足すると Vue 2の場合は input の入力値を直接 Store に書き込んでも、当該コンポーネント以外のコンポーネントが再レンダリングされることはありません。その結果、アプリケーションのパフォーマンスが劣化する懸念はないため、このような作りを許容しています。詳しくは Vue.js の公式ドキュメント「他のフレームワークとの比較」 のページをご覧ください。 以上で「Vue 2 で Testing Library の導入方法を紹介する」という本記事の目的は達成しました。ただ、せっかくのアドベントカレンダーなので、ここからは付録として Vue Router で画面遷移するテストの書き方の紹介と、Testing Library 導入がアクセシビリティ（a11y）の段階的な改善に繋がったというエピソードを紹介します。 付録 Vue Router で画面遷移をするテスト 本環境での Vue Router を使ったテストの書き方を紹介します。ページのアクセス時にログイン判定を行い、ログイン済みであれば /mypage に、非ログイン状態であれば /login に遷移するという架空の仕様を想定します。 この時、テストコードは以下のようになるでしょう。 import '@testing-library/jest-dom' import { waitFor } from '@testing-library/dom' import Component from '../settings-container.vue' import { render } from '../../testing-library' import { getInitialState } from '../../store' import { routes } from '../../routes' type Options = Partial < ReturnType <typeof getInitialState >> const setup = ( options?: Options ) => { const { route } = render ( // この render は上記で紹介した customRender Component , { initialState: { ...getInitialState (), ...options } , routes } , { routerOption: ( router ) => { router.push ( '/settings' ) } , } ) return { route: route () } } test ( 'ログイン済みのユーザーはマイページに遷移する' , async () => { const { route } = setup ( { isLoaded: true } ) await waitFor (() => expect ( route.path ) .toBe ( '/mypage' )) } ) test ( '非ログインユーザーはログインページに遷移する' , async () => { const { route } = setup ( { isLoaded: true , isCreated: true } ) await waitFor (() => expect ( route.path ) .toBe ( '/login' )) } ) render の返り値である route の中身は以下のような関数です。 // render.js export function render ( ... ) { // ... return { ... , route: () => wrapper.vm.$route } } なお、 Testing Library v5.8.3 での Vue Router のテストの書き方の例は公式の GitHub にも掲載されている ので、そちらも併せてご覧ください。また、もう少し上手く書けそうな気はしているものの現時点では十分に役割を果たしているため、今後さらに Vue Router を使ったテストケースが増えた段階でリファクタリングを実施しようと思います（インクリメンタルな設計）。 テスト駆動の a11y 改善 コンポーネントテストを書くことが、共通コンポーネントの a11y（アクセシビリティ）を改善するきっかけにもなりました。ここでは2つ事例を紹介します。 1つ目は、「ドラッグ&ドロップでファイルをアップロードできる」というコンポーネントの対応です。このコンポーネントを使って画像アップロードのテストを記述していた際、Testing Library で一般的なセレクタである getByLabelText() で input タグを取得できませんでした。 upload 原因は、 bbq-upload-box が Props に id 属性を受け取れなかったことです。 screen.getByLabelText('ファイルアップロード') と記述してテストを実行すると、ラベル「ファイルアップロード」に対応する form が見つからないというエラーが表示されます。 // セレクタで input を取得できない < div > < label for = "file-upload" > ファイルアップロード </ label > < bbq-upload-box label = "画像" icon = "image" accept = "image/png" @change= "uploadImage" ></ bbq-upload-box > </ div > そこで、 bbq-upload-box が Props に id 属性を受け取れるように改修し、テストの記述と実装を続けました。 // セレクタで input を取得できない < div > < label for = "file-upload" > ファイルアップロード </ label > < bbq-upload-box id = "file-upload" // この行を追加 label = "画像" icon = "image" accept = "image/png" @change= "uploadImage" ></ bbq-upload-box > </ div > 2つ目は、ボタンとしてクリックできるアイコンの対応です。アイコンボタンを含むコンポーネントのテストを書くにあたり、Testing Library のクエリを使ってこのボタンをクリックしようとしました。しかし、このままでは要素をうまく取得できませんでした。 icon buttons そこで、 bbq-icon-button コンポーネントに aria-label を渡せるように書き換え、利用側のコンポーネントからラベルを指定する変更を加えました。結果的にアイコンボタンをクリックした際に発火するコールバックのテストが書けたのみならず、Storybook の a11y プラグインの「Buttons must have descernible text」という指摘も無くなりました。 icon button a11y 対応の観点では、これらの改修内容はそれ自体ごく基本的なものだと思います。しかし、テストを書かなければ自分達でこの状態を発見することはなかったでしょう。もし気づいているのであれば既に誰かが修正しているはずです。対応内容の大小よりも、テストを書くことが a11y 改善のきっかけに繋がったことを喜ばしく思います。 ぜひ Testing Library を使ってフロントエンドでもテストを書いてみてください。 明日は @toshi-oliver さんの「AWS LambdaをPHPで使うためのベストな方法」です！ぜひご覧ください。

この記事は BASE Advent Calendar 2022 の3日目の記事です。 どうもこんにちは、ShopFrontチームの青木です。 主に ショップデザイン 関連機能の開発を担当しています。 今回は、チームのEMをしていた頃に、メンバーのGitHubやKibelaの活動など一箇所でまとめて見れるWebアプリを作成した話になります。 作成したWebアプリについて 自分のページのスクリーンショット 構成 ローカル環境で利用することを想定したもの 環境変数に各種PAT等設定をし、Asana API, GitHub GraphQL API, Slack APIを利用しています フレームワークにはNext.js, Bootstrap5を選定しました 主な機能 メンバーごとに、期間を指定して、以下のようなことができます。 Asanaのアサイン中のTask、GitHubの活動、Kibelaの活動、Uniposのリンク、Google カレンダーのiframe埋め込み、geekbotの投稿を表示 Asana、GitHub、Kibelaの活動をMarkdown形式でコピー どのように活用しているか 週次定例で共有する雛形に Asana、GitHub、Kibelaの活動をMarkdown形式でコピーできるので、それを週次定例で共有する雛形にして、定例資料作成にかかる時間を短くできるようになりました。 1on1での報告をスムーズに 週次で行っていたEMとメンバー間での1on1では、Asana、GitHub、Kibelaの活動に活動を見た上で、業務面での報告をコンパクトに出来るよう心がけていました。 内省に 期間を1ヶ月や3ヶ月、半年、1年などにすることで、自身がどういうことをやっていたのか見ることができます。 プロジェクトの振り返り会や、評価面談に向けての準備にも活用しています。 作ってみての感想 基本的に各サービスのAPI活用は読み出しのみなので、そこまで時間をかけずに実装できました 散らばっている公開情報を意味ある形にまとめるだけでも、活用できるシーンが生まれて、便利だなと思っています Asanaの項目やコピーする機能は実装当初なかったのですが、ありがたいことにチームのメンバーがほしいとPR作成してくれました！感謝！ 最後に 明日は、 @Panda_Program さんによる「Vue 2 + TypeScript 環境に Testing Library を導入する」です！お楽しみに！

はじめに この記事は BASE Advent Calendar 2022 と Looker Advent Calender 2022 2日目の記事です。 こんにちは。BASE 株式会社 New Division BASE BANK Section にて、Engineering Program Manager (以下EPM) 1 をしている永野( @glassmonekey ) です。 私達のBASE BANK Section チーム (以下 BANK チーム) はBASEの中でも、新規事業の金融系のプロダクトにフォーカスしたチームになります。特に新規事業なので、日々の不確実性にどう向き合って行くかをテーマに日々仕事をしています。 不確実性に向き合うためには、日々リリースしていくしかありません。そしてそれを観測するための分析基盤も日々のリリースに耐えうる、つまりはアジリティを保つ必要があります。 今回はどのようにアジリティを保ってデータ基盤を日々運用しているかをテーマに導入と活用の紹介をいたします。 データ基盤をこれから導入しようとしている方や、データ基盤を社内に普及させようと尽力されている方々の参考になれば幸いです。 ちなみに、今回の内容は7月に開催された Lookerユーザー会 で発表した内容がベースになっているので、そちらももしよかったら御覧ください。 EPMの役割 最初に、私の役割であるEPMとはなにか？を簡単に説明させてください。 私は現在、 YELL BANK というプロダクトのEPMをしています。 EPMの役割としてはざっくりですが、以下のようなことを日々やっています。 * 開発のリードや開発プロセスの改善 * 設定したリリーススケジュールへの責任 * プロダクトのクオリティの担保 * プロジェクト、プロダクトの技術的な阻害要因の排除 * ステークホルダーとの適切なコミュニケーション * 意思決定やエスカレーションの実施 特に私としては、早期リリースとリリース頻度には重きを置いていています。 最初の企画では3ヶ月かかる想定のものでも、スコープの調整をすると1ヶ月になりそうか? もしかしたら、工夫すればもっと早くリリースできないか？を考えていく感じです。 なぜなら、我々のつくっているプロダクトは不確実性だらけなので、わからないことばかりです。 それらの不確実性と向き合っていくには少しでも早くリリースして学習を重ねていくしかありません。 では、リリースした結果を学んでいくにはどうしたらいいでしょうか? 特にチームメンバーは全員がエンジニアというわけではありません。それぞれの立場で見る景色が違うため、KPIのような一定の定量的な指標を北極星にして目線をそろえていく必要があります。 そこで、目線をそろえるために定量的な指標を管理していくためにデータ基盤が登場します。 データ基盤とEPM 一般的にデータ基盤というと、Data Ware House(DWH)やらデータレイクといった言葉がでてくるのではないでしょうか。 我々としても、データ基盤のDWHには BigQuery を使い、BIツールには Looker を使っています。 もともと Redash を使っていましたが、クエリ管理の課題などから最近はLookerへの移行が進んできました。 Lookerへの推進はデータプラットフォームチームが全社的にリードし、我々BANK チーム としてはそれに則った形です。 しかし、この状況だと日々のリリース変更の度に、データプラットフォームチームへ都度依頼してデータの変更を共有しないといけないので若干非効率です。 そこである程度アジリティを保ちつつ、人的リソースも有限なので下のような体制での運用を始めました。 全社的なデータ基盤はデータプラットフォームチームが責任を持つ。 BANKチームの細かな分析指標は、日々のリリースに責任を持つEPMが責任を持つ ETLからELT ではデータプラットフォームチームとEPMがどのように分業を進めていったを説明します。 一般的なデータ基盤において重要なプロセスに以下の3つのプロセスが挙げられます。 * Extract(抽出）... データをソースから抽出する。 * Transform(変換) ... データを必要に応じて加工する。 * Load(格納)... データ基盤に格納する。 一昔前では、Extract、Transform、Loadの順に行われたのでETLという略称で呼ばれていました。聞き馴染みのある方も多いのではないでしょうか。 この中で、一番変更可能性が高い箇所はTransformになります。分析したい点やプロダクトのリリースによるデータ変更による影響を受けやすいためです。 従来のETLプロセスでは、LoadがTtranformに依存している形だったので、Transformの変更の影響をLoadが受けやすいという構造でした。DWHを作るような規模のデータだとペタバイト級のデータを扱うことも珍しくなく、頻繁にLoad処理を変更することは現実的ではないでしょう。そのためTransformを変更することが難しいという状況を生んでしまい、アジリティを下げる要因だったのではないでしょうか。 一方で、最近ではETLの代わりにELTという流れが主流になってきました。つまりは以下ように変更可能性の高い、Transformの処理を最後に持ってくるわけです。 実際我々のチームでも、アプリケーションを変更した我々自身でデータ分析基盤の最終的な内容を変更するという体制を取りました。そのおかげで、リリースした内容の速報を翌日にはダッシュボードで作ったりといった柔軟な運用体制を敷くことができました。 つまり、Transformを我々EPMが責任を持ち、ExtractとTransformは全社的な部分はデータプラットフォームチームが、我々のチームが管理しているデータソースはEPMが整備するといった分業体制となりました。 特に、Lookerだと、 派生テーブル によって気軽にELTが実現されている点で重宝しています。 クエリを書いてTransformを書く役割と、日々のKPIを管理してダッシュボードを作る役割を分けられた点は、他のBIツールには難しかった点かなと感じています。 とはいえRedashなどの他のBIツールでもクエリが書けるなら、同じような運用はできると思われます。 プロダクトライフサイクルに組み込む 現在、我々のチームが管理しているDatabaseやlog情報をそれぞれ日毎または日時でBigQueryに同期する形を取っています。 基本的にはembulkで一部Python のスクリプトをECSのタスクスケジューリングで実現しています。 基本的に同期するデータは、ほぼ生データをそのままBigQueryに入れるようにしています。 分析しやすいデータの整形といった処理はBIツールといった分析者の近いところで実現する方式をとっています。前述したELTです。 この方式を採用した理由としては、データのロード部分はデータ量の関係から頻繁な変更は難しいと考えた点が大きいです。分析観点という変化のしやすい内容をロード部分に組み込むと分析基盤としてのアジリティが下がってしまうことを懸念したためです。 最近は、PMMといった日々の施策に責任を持つメンバーも増えてきたので、ダッシュボード作りはPMMに任せつつダッシュボードに必要な情報はEPMが責任を持つといった分業体制で基盤周りの活動をしています。 もともと、BANKチームのエンジニア組織はフルサイクルエンジニアを掲げて全てのプロダクトライフサイクルに関わることを大事にしています。その中に分析基盤へのフィードバックも組み込んだ形を取るようになったといえます。 フルサイクルエンジニアに関しては同僚の松雪( @applepine1125 )が、 このあとblogを書いてくれるはずなのでこうご期待!! 書いてくれました。 devblog.thebase.in あと、Lookerを活用して良かった点に日付の情報を以下のようにTimeframeとして定義しておくとシームレスに週次、月次、Quoaterといった形に拡張できる点は便利だなと感じています。 dimension_group: event_date { type: time time_frame: [ time, date, week, month, quarter, year ] } 具体的には、日々の振り返り用のデータをそのまま拡張して、役員会議の資料にも活用できる点です。このことにより、メンバーから経営層まで視点が合わせられるので、視座に関わらず同じ北極星を追いながら仕事ができていると感じます。 最後に 今後の展望として、データ基盤を作った体制ができたので、プロダクトへのフィードバックの仕組みづくりとそれを推進していくメンバーの採用を進めていきたいと考えています。 現在はembulkで雑にデータを転送していますが、今後プロダクトにフィードバックすることを考えるとGlueやSage Makerの活用も考えていけたらなと思っています。 そこで一緒にプロダクト作っていく仲間を絶賛募集中です。 もしちょっとでも興味あるとか、知見あるよという方ぜひ私までDMか、以下のフォームから応募お待ちしています!! 冷やかしでもいいよ!! open.talentio.com 明日はダーツが得意な @ao_kiken さんによる、「チームメンバーの活動を知る工夫」です。楽しみですね!! 参考文献 プロダクトのデリバリー、クオリティに責任を持つEngineering Program Managerという役割 ↩

この記事は 2022 BASEアドベントカレンダー 1日目の記事です。 こんにちは！開発担当役員のえふしんです。絶賛、来季の組織構造の設計中なので、何を考えながら組織図を検討しているか？ということを書いてみたいと思います！ 組織検討の基本としては、サービスの拡大、組織の拡大に対して仕事のやりやすさ、スピード感を如何に実現しながら事業を伸ばしていくか？というテーマで組織を考えていきます。 組織構造は各社各様のものがあると思いますが、多くの会社さんではビジネスのトップラインを伸ばすチームを主体に、今ある課題をこなしていくチーム構成であることが多いことでしょう。 また、ビジネスの守りを支えるチームもあります。守りの裏返しは攻めと言いますか、何かを守り抜くことで、売上や利益の下支えを行う課題解決については経営課題として上がるため、それ専用のチームが作られたりします。 我々で言うと、決済機能の保守がそれに該当します。決済機能はただサーバを動かしているだけで済むものではありません。BASEの上で販売される商品をチェックするなどの加盟店管理責任を果たすことや、悪意のある決済からショップを守る不正決済管理などが該当します。 一方で、新機能開発を専念しているWebサービスの会社で、いつも悩みのタネになるのが、過去に作り込んでしまった不具合修正を誰がどうやって時間を割いて直していくかということではないでしょうか。つまりすでに動いているサービスのクオリティや安定性の維持の作業で、誰がどのようなプライオリティと責任で担っていくのかという課題です。 （事象がクリティカルではない）不具合修正に傾倒しすぎると新規機能開発が遅れている可能性が高くなり、新規機能開発を優先していると、いわゆる技術的負債が解消されないであるとか、プロダクトクオリティが低いままになるというリスクがあります。 こういう部分はなんらかしらの問題が起きない限りビジネスイシューには上がりにくく、マネジメントは開発チームに委ねられているのが実情だと思います。そして現場では大なり小なり問題が起きているため、このことに対するジャッジメントはCTOが担っているのではないでしょうか。 以前、個人のブログでも以下のような記事を書いたことがあります。 note.com ここで書いてあることをざっくり書きますと、足元のソフトウエア資産の維持（技術的負債の解消も含む）、セキュリティの維持などを行う保守作業等の必要性はエンジニアしかジャッジメントできない。一方でエンジニアの作業快適性の維持など、直接的に売上には貢献しないけど、放置も良くないという間接的なバリューへの貢献でもあったりするので、余計にその判断責任を担うためにもCTO職が必要であろうということが書いてあるわけです。 そして、不具合修正等の実作業ですが、昨今はCRE（Customer Reliability Engineering）などと言うチームを作って、顧客満足度を実現するための組織を作るところもあります。このチームはすごく意義、意味のある取り組みではありますが、言うて実態は社内の誰かが作りこんだ不具合修正を担う、若干のとばっちり感が否めないチームであるという部分で、感情的な難しさを醸し出したりもします。 そもそも、まず適切な不具合修正は難しい作業です。スキルが問われます。サービスのドメイン知識も必要なので、とりあえず人を雇ってきて、直してください〜で済む人はベテランエンジニアである確率が高いでしょう。 歴史的経緯を調べるためにステークホルダーを理解する人間関係も必要です。 そういうことができる人だったら新規開発もできる可能性が高いので、ビジネスプライオリティを優先する組織では、遅かれ早かれそういう人は新規開発に回るはずです。 そうではなく、もしベテランのエンジニアの人が教育者的な視点を持ち、守りの要を担ってもらえたら最高です。 でもWebサービス企業は歴史が浅いので、製造業などにいるリタイア間近のベテランの工員の人などはあまり存在しません。みんなもっと若いので、新規開発などを通じて自分のスキルを高めていきたいと思うのが人情というものでしょう。 なので、CREは、その会社の歴史的経緯に支えられた属人の活躍に委ねられている組織なんじゃないかな？と思ったりします。組織構造としては極めて維持が難しいチームではないかと考えたりするのですが、どうでしょうかね。理想論ではなくリアリティのあるCREチームの作り方を是非お聞きしてみたいです。 受託感という言葉について 話は変わりますが、Webサービス企業では「受託っぽい」と言う言葉が使われて忌み嫌われることがあります。多くは、よくない組織構造を起因として「上から案件が降ってくる」「スケジュールや仕様などでエンジニアサイドの決定権や拒否権がない」などの「やらされ仕事」という言葉に対して使われがちな表現です。いわゆる多重請負の下位レイヤーの人の話がたくさん出回っていた時期があったので、こういう言葉が使われがちです。 僕は以前、受託開発も担うWeb制作会社にいたので、一次請けであれば、もっと議論もできるし、そもそも見積もりでお断りもできるし、お客さんやSIerの「上に言っちゃったから今更断れない」にぶつかることはあっても、そのことを共有し、最大限助けてあげようという割と前向きなメンタリティで仕事ができていたので、受託開発も楽しかったです。 とはいえ後に、Webサービス企業に転職をするわけですが、次に何をしたかったかというと、自分がかけた時間を、すべてそのサービスの成長に結びつけたいということでした。 どうしても当時僕が関わっていた受託開発だと、契約条件としても納品するまでがビジネスで、そのシステムはお客様の資産ですし、それがどう運用されているかまで、当時は関われなかったので、どう成功した、どう失敗したのかまでは関われませんでした。また新機能提案なども、お客様にお金をいただかないと責任を持てないというオーバーヘッドが、当時の僕のスキルでは無駄だと思っていたし、何よりお客様が判断できることしかできません。 ギーク的なノリで「とりあえずやってみる」 自分たちの責任でチャレンジしてみるなどもできないわけです。 もちろん、これは当時の僕のスキルと環境がそうだっただけで、最近はDXの名の下で、アジャイルプロセスを使いながら運用を伴奏するサービス開発の受託ビジネスなども立ち上がってきて、レベニューシェアの仕組みが連動できれば面白いですし、DAO的な形で出資し合うビジネスもありでしょう。昔より面白くなってきたので、個人的にはそういう仕事にも興味があります。 ...それはともかくとして、Webサービスのエンジニアは、そのサービスの生殺与奪を握っているので、新規開発だけでなく、そのサービスの安定性維持、不具合修正、セキュリティ、サービス運用なども全部自分たちの責任の元でこなすべきだと思っています。それこそが主体的にWebサービスに携わるエンジニアの矜持だとも思っています。 でも、どうしても仕事として見ると、開発計画にあるプロジェクトを優先的にやらなきゃ！って思う人もいますし、たしかにそれは重要なのですが、かと言って、それだけに心を囚われてしまうのも、僕はむしろ「受託っぽいと言われやすい価値観かな」って思うところもあります。 もっとワガママに自分たちが守っているサービス全体を守るんだという意識の元で、新規プロジェクトもこなしつつ、サービスを維持するエンジニアリングスキルを高めていく方が絶対楽しいと僕は思っていますし、それができた人が、当社でもCTOであったりプリンシパルテックリードなどの重責についていることは、一応書いておきます（要するにその主体性、スピード感と技術力を兼ね備えた人材がわかりやすくエンジニアとして出世するノウハウということです） 攻めと守りを両立させる 我々のSlackには、#cs_qというお客様からの問い合わせの中で技術的な調査や回答を行うチャンネルがあります。 以前は組織も小さかったので、基本的に問い合わせに気がついた人が回答するという牧歌的なコミュニケーションチャンネルでしたが、いつしか問い合わせも増え、人も増えた流れで、CTOやプリンシパルテックリードが、まだその肩書がつく以前から問い合わせ対応に他の人達よりも爆速で対応し続けてしまい、かつ彼らが持っている開発プロジェクトもスケジュールに間に合うようにするために残業時間が爆増したため、その負荷分散のために、当番制で担当するように変わりました。 今は、マネージャ判断で#cs_q対応の当番リストから外さない限りは、原則としてプロジェクトに参加しているエンジニアも含めて、全員体制で対応をしています。 以前のアドベントカレンダーでもこういう記事を書いています。 devblog.thebase.in 我々は現在、こういう体制で対応をしていますが、一方で、どうしても現場目線では#cs_q対応はプロジェクトが遅れる要因として語られたりするため、ビジネス最適化という側面では、こういった守りの対応のための別チームを組成してみては？という話が出てくるわけです。 なので、組織構造をトップラインを伸ばす方向だけに最適化するとそういう話になってしまうわけです。ビジネスジャッジメントを優先しすぎてサービスの安定性、継続性、ソースコードの劣化に伴う開発生産性が損なわれていくようなことにはならないように、かつ、Webサービスのエンジニアとして、自分たちで作ったものは自分たちで直す、という当たり前のことをやり続けられる組織構造を維持しないといけないとは思っています。これはテックベンチャーとしてのこだわりポイントではないかと思っています。 もちろん管理者目線では両立できる組織構造でそれぞれが最速で動くような組織の方がきれいなので、将来はそうなったらいいなとは思いますが、エンジニア目線では「それでWebサービスに携わってると言えるのかなぁ、仕事楽しいのかなぁ」という気持ちを持ちながら、２つの価値観を考えているという感じですかね。 責務のドメイン分割が作業効率にだけ最適化されただけの状態が正解だとは思わないという話でして、答えの出ない話ではあるのですが、うっかりすると自分自身も効率性だけを考えて組織設計をしがちだったりするので、気をつけなきゃなと考えながら組織図案を書いてる今日このごろです。 アドベントカレンダー ２日目はBASE BANKチームの永野( @glassmonekey )さんによるデータ分析基盤の管理運用についての話です。お楽しみに！ 2022年のアドベントカレンダーのスケジュール