こんにちは！サーバーサイドエンジニアのotaka(@oh_minisera)です。
現在CRE（Customer Reliability Engineering）に所属しており、カスタマーサポート（以下、CS）の生産性向上やユーザー信頼性向上を目的に仕事しています。
読者の中でもエンジニアとしてエンジニア以外のステークホルダーと仕事をされる方はいらっしゃると思います。僕の場合はCSと仕事をする機会が多いです。
その中でこういった課題はないでしょうか？
- CSとタッチポイントが少ないエンジニアにとってCSのオペレーションが把握しにくい
- そのため機能改修の負担が大きい
- いざ完成した機能がCSの意図と合わない
- そのためCSの運用でカバーしている
※ CSを「運営スタッフ」や「営業」など他職種に読み替えていただいても問題ないです👌
開発工数が膨らんだり、運用によるパワープレイも辛いですよね…。
今回はエンジニアとCS間がよりコラボレーションし、大きな負担なく的確なアウトプットができる新戦略、「Embedded CRE」を試行してみました！
今回はEmbedded CREとは何なのか、それを経て何を得たのかを皆さんにお伝えできればと思います。
本記事の3行まとめ
- Embedded CRE とは各チームに組み込まれて活動するCREのこと
- 組み込まれたCREはチームメンバー・CS間のコミュニケーションのハブとなる
- CSやチームメンバーの意図を汲んだ管理画面の実装が低コストで可能となる
Embedded CREとは
Embedded CRE のことを
「CREが職能横断的なプロダクトチームの一員として組み込まれCSの生産性やユーザー信頼性向上を目指す体制」
と僕たちは呼んでいます。*1
「職能横断的なプロダクトチーム」について詳しく話していきます。
株式会社スマートバンクでは、新機能開発や新事業立ち上げ、事業の安定運用などのミッションを元に職能横断的に構成されたチーム（以下、ミッションチーム）毎にプロダクト開発をしています。 このチーム構成では各機能の開発と運用を両立できたり、チーム毎に自律的に動けることがメリットです。*2
また、各ミッションチームはエンドユーザー向け機能以外に管理画面の開発も行います。
しかしながら、普段から管理画面の開発やCSと密にコミュニケーションを取っているCREと他のミッションチームは別のチームとなっています。
そのため冒頭に紹介した課題が挙がってきました。
- CSとタッチポイントが少ないエンジニアにとってCSのオペレーションが把握しにくい
- よって機能改修の負担が大きい
- いざ完成した機能がCSの意図と合わない
- よってCSの運用でカバーしている
そこで、今回はミッションチームの中にCREを組み込み、CREがCSとミッションチームのハブとなることで上記の課題を解決しようと試みました！
やったこと
前提
- ミッションチーム発足した初期からは参画せず、リリースを見据えて管理画面改修の機運が高まっている時期に参画
- 管理画面の改修でやりたいことは何となくあるが、詳細は詰め切れていない状況
- エンドユーザー向けの機能は要件定義が終わり、実装フェーズに入っている状況
- 組み込み先のミッションチームはバーチャルカードを開発しているチーム
全体の流れ
- ミッションチームの解決したいドメインをインプット
- CS、ミッションチームのエンジニア、CREの三者でやりたいことを洗い出す
- CSとCREで詳細を詰めて実装
ミッションチームの解決したいドメインをインプット
ミッションチームに組み込まれて仕事をするということは、ミッションチームがやろうとしているドメインをキャッチアップする必要があります。
今回であればバーチャルカード実装に伴い、バーチャルカードのドメインや既存のカード発行周りの処理についインプットしました。
ここでインプットする時に効果的だったTipsを紹介します。
- Design Doc
- Working Out Loud
Design Doc
Design Doc は特定のドメインの全容について書いてあるドキュメントです。
例えば
- 事業戦略上なぜやるか
- 目標指標
- やること・やらないこと
- 機能要件
- 実装方法
- 結果だけでなく理由・背景
… etc.
途中からプロジェクトに参加した時、「まずどの資料を読み込めば良いのか」と迷う瞬間があると思いますが、今回はDesign Docをハブに情報を収集することができました。
Working Out Loud
言葉通り「大声を出しながら仕事」をします。
実際に声に出す訳ではないですが、自分の作業内容をSlackなどのオープンなチャンネルに書き流していきます。内容は何でも良くて、自分が今やる作業のゴール・目的、今やっていること、悩んでいることなど。
当時ミッションチームに参画したての自分にカウンターパートのエンジニアがいたのですが、質問をする前に僕のログに対してレスポンスしていただき、キャッチアップが捗りました。
Working Out Loud は別で記事を書いていますので詳しく知りたい方はぜひ！
入社1ヶ月の新人がWorking Out Loudを始めてみた - inSmartBank
CS、ミッションチームのエンジニア、CREの三者でやりたいことを洗い出す
CS、ミッションチームのエンジニア、CREの三者でEmbedded CREで達成したいことを話します。
CREが手を動かす前に、CREが誰に対して、どんな状態させたいかを事前にステークホルダーと話しておくと良いでしょう、
今回はバーチャルカードという新たな発行形態が増えることにより、CSオペレーション負荷増加が予想されたため、既存のオペレーション負荷の軽減が達成条件となりました。
また、今回はCREが参画する前にやりたいことをCSとミッションチームシニアエンジニアで出してくれていたので、この時点でリリース前必須、できれば欲しい、リリース後必須と優先度を振り分けました。
やりたいことの詳細をCSとCREで詰めて実装
ここからはミッションチームのドメインを身につけたCREと CSでやりたいことの詳細を詰めて実装していきます。
今回はバーチャルカードの追加に伴い管理画面のカード発行周りの処理に分岐を追加したり、前述したCSオペレーションの負荷を軽減する改修を複数行いました。
CRE内での開発と違う点で言うと、レビューや実装の相談は主にミッションチームのエンジニアたちと行いました。
普段は一緒に開発しないエンジニアから新しい視点を得たり、設計の勉強になったりと自身の刺激にもなりました！
良かったこと
CREの声と開発メンバーの声で分けて紹介します！
CREの声（私）
普段一緒に開発していないエンジニアと開発でき刺激をもらえた
基本はミッションチームの一エンジニアとして働くため、普段共に開発していないメンバーとも開発することになります。
そのメンバーから、特に案件におけるボールの持ち方やキックの仕方、調査や相談方法など、円滑に仕事を進めるためのHowに関して知れるのは良かったです。
レビューや実装の相談は、他チームにいてもできる部分ではあるのですが、普段の仕事の進め方はそのメンバーと近い位置で働かないと観測しにくいので、Embedded CREならではのメリットだと感じました。
他チームの良い点をCREに還元できる
上記のような仕事の進め方もそうですが、他チームでやっている構造化されている良い部分をCREに還元することができました。
例えば、タスクの見積もり会（見積もりをする際にチームメンバーで議論する会）や、朝会で何でも相談して良い時間を作ったり、他チームで運用されている良い構造をCREに持ち込みました。
ミッションチームのエンジニアの声
CREがハブになることにより、CSとのコミュニケーションがスムーズになった
Embedded CREを実施すると、ミッションチーム側とCS側のドメイン知識を持った状態のエンジニアが誕生するのでCSとのコミュニケーションをまるっと担うことができます。
そのため他メンバーがエンドユーザー向けの機能開発に集中できる環境を作ることができました。
また、シンプルに手を動かすエンジニアがチームに一人追加されるということで開発スケジュールに余裕が生まれるメリットも享受しました。
普段触っていないドメインの理解が進んだ
Embedded CREのPRはミッションチームのエンジニアがレビューします。そのためレビュアーは普段触っていないドメインを見るためコストは高くなりますが、その反面ドメイン知識を得られたと言う声を聞きました。
開発内でドメインを属人化させないという効能は一定ありそうです。
次に繋げたいこと
ミッションチームの立ち上げ初期からCREが参加したい
今回は私がEmbedded CREとして参画する以前からミッションチームとCS間でコミュニケーションをとっており、やりたいことを洗い出してもらっていました。
やりたいことを洗い出すにも、CSオペレーションについて知っているエンジニアがいると話がスムーズに進みます。
今回は他の業務で途中からの参画となっていましたが、今度行う際はロードマップ時点で予定を組み込んでおくなどして首尾一貫でCREがミッションチームをサポートできるようしていきたいです。
事前にCREがCSオペレーションをキャッチアップしておく
CREもCSが使う管理画面のシステム的なことは把握していますが、現場でどのように運用されているのか網羅的に理解しているわけではありません。
Embedded CREで参画している最中にカード発行や本人確認周りの仕様を、CSから勉強させてもらうことが多く、「事前に知っていれば…」ということがありました。
対象となるドメインの知識だけでなく運用方法を、ヒアリングや体験などを経て理解する努力が必要と感じました。
こんな時どうしてた？
この記事を見て「Embedded CREやってみようかな…」と思ってくれた方がスムーズに実践できるようQ&Aを書いてみました。
- 普段のCREのお仕事はどうしてた？
基本は朝会、開発の以外の部分はそのままにしていました。週1のCRE定例とCSからのお問い合わせ対応は、Embedded CREしている時も継続して行なっていました。
CRE定例も30min/weekで負荷も少なく、CREを離れていても現在のCREの状況をウォッチするために活用していました。ミッションチーム側の仕事が忙しい時はCSからのお問い合わせはCREの他メンバーに依頼して回していました。
- ミッションチームの定例
基本はミッションチームに配属されることになるので関係する全てのミッションチーム定例に出席しました。
- キャッチアップに時間かかった？
前述していたDesign docやWorking Out Loudの影響もあり、ガッとキャッチアップする時間は1営業日で済みました。そのあとは足りない知識があれば都度身につけました。
- 移籍期間はどうやって決めた？
今回はCRE内で必須にリリースしたい機能もあり、その兼ね合いで約1ヶ月間の移籍と参画する前から決めていました。
- 普段一緒に開発しないメンバーと開発するけどハードル高くなかった？
弊社の性質上、普段から別チームのエンジニアともコミュニケーションをする機会が多く人となりを知っている状態で参画できたのでハードルは高くありませんでした。
人数が増えチームが増えエンジニア間のコミュニケーションが今よりも疎になると最初のハードルは高くなる可能性はあります。
あとがき
今回はエンジニアとCSを繋ぐ新戦略「Embedded CRE」を紹介させていただきました。
Embedded CREをやる前に検索をかけましたが、「Embedded SRE」の実践事例は出てくるが「Embedded CRE」の実践事例は見当たりませんでした。*3
少なくとも「Embedded CRE」の事例に関する記事はこれが最初になるかもです（ほんとか…？）
そして！このような新しい体制も手を挙げればチャレンジできる環境ということを声を大にして言いたいです！
弊社について気になった方はご気軽にカジュアル面談を「ポチ👇」お願いします！！
*1:CREについて詳しく知りたい方はこれら記事やポッドキャストがおすすめです！https://blog.smartbank.co.jp/entry/2023/12/19/112042, https://smartbank.co.jp/podcast/27-tmnb
*2:ミッションチームについてはこちらの記事がおすすめです。https://blog.smartbank.co.jp/entry/2024/11/12/em3
*3:以前この内容でLT登壇していた資料はこちら。https://speakerdeck.com/minisera/embedded-cre-case-study
