kubellで認証チームのエンジニアをやっている田中浩一（@Tanaka9230）と申します。この記事はkubell Advent Calendar 2024 シリーズ1、11日目の記事です。
認証チームとは、「Chatwork」のログイン画面を含む認証系＋一部セキュリティ系、およびアカウント管理系を担当領域としたフィーチャー・チームです。認証系の中核には「Auth0」というIDaaSを導入していて、その運用も担っています。
◇
会社内での認証チームへの期待役割は、今、大きく変わりつつあります。今までは、「Auth0導入とそれに伴う周辺機能や運用系の改善」でした。今後は、「BPaaSを前提に、事業横断的に認証サービスを提供すること」にフェーズが移りつつあります。
本記事は、認証チームが、これまではどのように運営されていて、それがどのように変遷していって、現在はどうなっているか、今このタイミングで振り返ってみよう、というものです。
第I期：専任”Tech-サブPO”時代
認証チームは、スクラムのプラクティスを土台として運営されています。Why-Whatを担うプロダクトオーナー（以降、PO）がいて、Howを担う開発チームがある、というかたちが基本となります。
弊社には、開発組織とは別に、プロダクト戦略を担うプロダクトマネージャー職（以降、PM）がおります。認証チームにも領域担当のPMが付いています。
認証チーム発足当初は、スクラムの文脈で言うPOの役割を、領域担当PMに担っていただく、という体制としていました。加えて、DEVメンバーから一人、チーフPOたるPMをサポートする役割として、専任のサブPOを出していました。
ここで、「POチーム」と書いていますが、POチームとは、POの役割を一人では無くて、複数人で担おう、というプラクティスです。スクラムのPOは、プロダクトについての”最終意思決定権限者”であると言えますが、意思決定に至るまでは、VoC、アプリログ、A/Bテスト、PoC等々、さまざまな調査・分析ワークを経る必要があります。これらを一人でやっていくには物理的に無理があるだろう場合、POチームを編成する事が一つのプラクティスとなります。
「POは一人でやるべきで、複数人でチームを組むのはアンチパターンである」としている論も多いですが、チームを組んでも、「チーフ」を明確にすることで、最終意思決定が揺れる問題の発生を抑えることが出来ます。
上の図は、当時の体制は「チーフPO + サブPO の POチーム」という枠組みだったのだ、と、今から振り返ってみてそう捉えられる、としてその様に描いたものです。明らかにPM一人では捌けない物量のPOワークがあり、DEV側からサポートを出すことは自ずと必要だったのですが、当時時点では、"実質的にPO役割を担っているPM"がいて、そこに加えて"DEVから出してるPOの様な役割"、という二重構造をどのように捉えたらいいか悩んでいました。
◇
その頃のJiraチケット運用の様子です。
「ユーザーストーリー」、「タスク」、ほぼJiraのデフォルトのままです。ひとつ、「見積もれないもの」という課題タイプを追加していました。文字通りそういう課題タイプです。これはストーリーポイントを見積もるのに情報が足りない時に、調査やPoCを行うことを表したチケットです。ユーザーストーリーをReadyにするためのもろもろ準備ワーク、と言うこともできます。「ユーザーストーリー」だけをストーリーポイント計上対象としていました。
ほぼJiraのデフォルトのまま、開発チームによる、開発チームとしてのワークに焦点があたったチケット編成でした。
ここで、「開発チームとしてのワーク」は、Jira上でプロダクトバックログとして管理されていたわけですが、「POチームとしてのワーク」の管理は、当時のチーフPO & サブPOの個人技で回っていて、開発プロセス的に定式化はされていませんでした。
第II期：”全員でPOチーム”体制立ち上げ期
2024年春頃、サブPOを担っていたメンバーが、会社の全体最適観点から、他チームへ移籍となりました。
そこで、残ったメンバーで、新たにどういう体制にするか決める必要がありました。
- 新たに誰かが専任サブPOを担うか、
- 「全員が兼任サブPO」をやってみるか、
二つの選択肢が挙げられました。
ここで、後者の「全員が兼任サブPO」を、（KPTの）Tryとして、始めることとしました。
この"全員兼任サブPO"、という試みをTryすることとした背景ですが、“Will”面では、少々私の個人的信念や確信を通していただいた面があります。
ひとつは、開発のエンジニアも、基本的には全員がWhy-Whatの視座を獲得すべきだ、という信念です。もうひとつは、Why-Whatへの投入リソースと、Howへの投入リソースは、だいたい1:1でよいだろう、という確信です。開発チームが4人ならば、POチームも4人で編成されててよいだろう、ということです。
とはいえ、そんな"全員兼任サブPO"なんてものが、実際どうして実現できたのか？という疑問もあるかもしれません。
”Can”の面では、振り返ってみると、二つの成功要因があったかな、と思います。
一つ目は、第I期の時代から、「ATDD」あるいは「受け入れテスト」というものに取り組んでいた事です。その過程で、「POの立場の目線」とはどんなものか？Whatの視座とはどんなものか？一定の慣れ、あるいは親しみが、チームメンバー全員に備わっていたかな、と思っています。
もう一つは、全社方針として、「QAプロセス」の導入、定着をずっと進めていた点です。QAプロセスを語るには、その前提として、開発プロセスに意識的になる必要があって、この点でも、自分たちがやってることがどんなバリューストリームで流れているのか、メンバーひとりひとりの理解が、それぞれ深まっていたかなー、と。
これらのことが、"全員兼任サブPO"体制を実施可能な下地となっていたのかな、と、今振り返って、その様に思います。
◇
実際の運用では、順次いろいろな新しいプラクティスを整備していきました。
POチームMTG:
- PM以下全員参加の、いわばチームの最高意思決定会議です。週2回定期開催。
スプリント当番:
- スクラムイベントのファシリ担当を、1週交代で担うこととしました。
「リファインメントの進め方」:
- 進行に惑わない様に、簡単にマニュアル用意しました。
QAプロセス:
- 「DEVロール」と「サブPOロール」を兼任した場合の最大の懸念が、両方の目線が混じってしまって、PO目線で語るべき場面で、DEV目線で評価してしまう場合が生じる事でした。この問題に対しては、「受け入れテスト」的な観点や視座を維持することが重要な防波堤となります。形式化されたQAプロセスは、「受け入れテスト」的な目線を見失わない様にする重要な仕組みとして機能しました。
ちなみに、QAプロセス運用プラクティスとして、Jiraチケットに「受け入れテスト」のテストスイートを紐づける事をしています。テストスイートはTestRailを用いて管理しています。このテスト管理のために、Gherkin記述 → GitHubプルリク → TestRail反映したり、Jira → TestRail連携したりする、いい感じのToolingが整備されています。下記記事で紹介されていますので、ご参考に。 creators-note.chatwork.com
◇
”全員でPOチーム”体制立ち上げ当初期のJiraチケット編成は、特に工夫なくそれまでの「ユーザーストーリー」、「タスク」、「見積もれないもの」の3種編成をそのまま踏襲しました。つまり、「開発チームとしてのワーク」に焦点があたったチケット編成、のままということです。
ここで課題が浮上しました。
認証チームでは、ずっと開発パフォーマンス指標として、d/d/d (deploys / a day / a developer)を見てきました。（ただし、認証チームでは少々アレンジしていて、デリバリーに関わる消化ストーリーポイント数 / a sprint / a developerという指標となっています。）良くも悪くも、認証チームのd/d/dはずっと安定していました。別に上がるわけでもないですが、下がるわけでもない。あまりにも何も変わらないので「この指標見る必要あるの？」という疑問も出つつあったところでした。
そのd/d/dがじわじわ下がってきました。
つまり、「ユーザーストーリー」以外の、「見積もれないもの」チケットや、「タスク」チケットがやたら増えてきたのです。POチームとしてのワークは、ほぼ全て「PoC」や「なんらか調査」として認識されるでしょう。これらのワークが、元来の開発チームとしてのワークたる技術検証やその他タスクに、どんどん混入してきているのだろう、と、容易に考えられます。
元来の開発チームのワーク以外のワークを積極的にやっていこう、という話な訳で、そうなることは想定内、とは言えます。
少し寄り道しますと、今回d/d/dがじわじわ下がってきた、という現象が見られたわけですが、それは、あまりにも変化無いので無意味では？と思われていた指標をずっと測定してきていたからこそ見えてきた現象です。何か積極的に指標を向上させる、という狙いを持っていなくても良くて、逆に、「変化してないよね？」ということを確認するために指標を取り続けて、普段通り＝いわば"平熱"であればOK、そこから外れたら"何かが起きてることのサイン"、として運用するのもアリなんだなー、という学びがありました。
d/d/dがじわじわ下がることは、元来の開発チームのワーク以外の、POチームとしてのワークをしているので、そうなることは想定内とはいえ、POチームとしてのワークの内容が、実際具体的にはどんな内容のものがどの程度の量発生しているのか、よくわからない、下がったd/d/dを説明できる程度の量のPOチームとしてのワークが発生しているのか、可視化できてない、この様な課題認識に至りました。
開発プロセスのバリューストリームを描いて、どのタイミングで何をしているか割り当てていって分析してみることとしました。
第III期：”全員でPOチーム”体制成熟期
開発のバリューストリームは、下の様に整理されました。
「POチームMTG」で実際的には何をしていたのか？、というと、「PM部内レビュー会」へ持っていくネタを集めたりロジックを作ったりしていた、のです。「PM部内レビュー会」とは、案件の”やるやら”および優先度をVPoPと合意形成する会議体です。（担当PMに改めて確認しました。）今回このバリューストリームを描く事で初めて、開発チームの担っている範囲のプロセスと、PM（PM部）の担っている範囲のプロセスを接続して、即ちフルサイクルとして、理解することができました。
このバリューストリームの図に、運用していたJiraチケットを置いてみます。
過去のチケットを振り返って、各チケットでやってたことを分析、整理してみました。すると、次の様になりました。
「見積もれないもの」チケットとしてやってたワーク、「タスク」チケットとしてやってたワークには、それぞれ、「PM部内レビュー会に持っていくまで」のワークと、「PM部内レビュー会でGoが出た以降」のワークが混ざっていた、ことがわかりました。
それでは、きちんと分別してみましょう、ということで、
上図の様にチケット編成をアレンジしてみました。この新しいチケット編成は、以下の様な思考から導き出されています。:
「PM部内レビュー会」は、開発意思決定プロセス上、最重要なアクティビティであると分かった。
「POチームとしてのワーク」には、「PM部内レビュー会に持っていくまで」のワークと、「PM部内レビュー会でGoが出た」以降のワークとに分けられることが分かった。
だったら、えいやと、前者を「ディスカバリー」に、後者は「デリバリー」にマップしてみたらどうか？
元々「見積もれないもの」チケットとして行なっていたワークには、ディスカバリーとしてのPoC等と、デリバリーとしての技術検証や全体設計が混ざっていた。これらを分別して、「ディスカバリー」チケットと、デリバリーとしてのワークを表す「全体設計」チケットを用意することとする。
元々「タスク」チケットとして行なっていたワークには、"その他もろもろ"が含まれていた。内訳を分析すると、結局の所、ディスカバリーとしてのワークをサポートするもろもろ調査等か、運用・保守面、あるいは開発者体験面の改善ワークかに大別できることがわかった。前者は、「見積もれないもの」由来のディスカバリーのワークと統合してよいだろう。後者は、別途「開発者ストーリー」というチケット種別を設けて、陽の目があたる様にしよう。
加えて、チケット再編成するこの機会に、バリューストリーム中の全活動を、一定定量的に把握できる様に、全てのチケットにストーリーポイントを付与することとしました。
具体的には、「ディスカバリー」チケット、「全体設計」チケットのワークは、基本的にはタイムボックスで見積もられる様なものです。が、1h〜2hのタイムボックスを仮に1ストーリーポイントだとして換算して、ストーリーポイントを割り振ることとしました。
また、今まで「UXに直接関わらない機能や部位の開発」は、タスクチケットとして、ストーリーポイント計上対象から外していましたが、「ユーザーストーリー」に対して新たに設けた「開発者ストーリー」は、ストーリーポイント計上することとしました。
第IV期：デュアル・トラック体制完成期（あるいは、まとめ）
認証チームの開発プロセス運用に、新たな地平が見えてきました。
一つのチームで、ディスカバリーとデリバリーの両輪を一体的に回す様なスタイルには、「デュアル・トラック・アジャイル」という名前が付いていたんですね！
「PM部内レビュー会」を境に、ディスカバリー・トラックとデリバリー・トラックとに分けて捉えられる、そうしよう、という点が今回のカギです。とすると、「POチームとしてのワーク」は、ディスカバリーとデリバリーに跨っています（いました）。元々は、「POチームとしてのワークも可視化しよう」というモチベで始まりました。しかし、例えば「全体設計」チケットに基づくワークは、「POチームとしてのワーク」と「開発チームとしてのワーク」の両側面を持っています。デュアル・トラック体制の下では、この点を分別しても、あまりうれしみは無いと思えました。そういう観点よりも、デリバリーサイドのワークとディスカバリーサイドのワークのバランスを見ることの方が、フルサイクル開発プロセスの最適化に寄与すると思えます。
現在の認証チームのJiraのバックログには、スクラムのいう「プロダクトバックログアイテム」以外のチケットが乗っています。（これまでに挙げたチケット種別以外にも、障害対応、運用対応チケットがあります。）むしろ、「プロダクトバックログアイテム」と言えるだろうチケットは、「全体設計」、「ユーザーストーリー」、「開発者ストーリー」の3種類のみ、です。
以下は現在運用している（完全な）Jiraチケット一覧です。
なお、ここでのストーリーポイントは"アウトプット"量の見積りとなります。（"アウトカム"量は、「「ユーザーストーリー」のストーリーポイントに、施策ごとの適当な係数を掛けたもの」として扱うのだろう、と考えています。）
この様なチケット運用によって、チームのフルサイクル全てのアクティビティが一定定量的にトラッキングできる準備が整いました。チケット毎のサイクルタイムを追えるとともにともに、施策毎にディスカバリーからデリバリーまでの総リードタイムも追えるでしょう。（施策に対応してエピックを作っています。）チケット種別毎の消化ストーリポイント比率の推移を追うことで、d/d/dに対してディスカバリーワークがバランスしているか見たり、フルサイクル開発プロセス中のボトルネックを見極めることもできそうです。今後、こういった感じで、フルサイクル開発プロセスの全体最適マネージのプラクティスを固めていきたいと、と考えています。
