kubell Creator's Note

ビジネスチャット「Chatwork」のエンジニアのブログです。

ビジネスチャット「Chatwork」のエンジニアのブログです。

読者になる

DEV発で「POチーム」をやろうとしたら、デュアル・トラック・アジャイルになっていた

kubellで認証チームのエンジニアをやっている田中浩一(@Tanaka9230)と申します。この記事はkubell Advent Calendar 2024 シリーズ1、11日目の記事です。

認証チームとは、「Chatwork」のログイン画面を含む認証系+一部セキュリティ系、およびアカウント管理系を担当領域としたフィーチャー・チームです。認証系の中核には「Auth0」というIDaaSを導入していて、その運用も担っています。

creators-note.chatwork.com

findy-tools.io

  ◇

会社内での認証チームへの期待役割は、今、大きく変わりつつあります。今までは、「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チームを編成する事が一つのプラクティスとなります。

sites.google.com

「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が出た以降」のワークが混ざっていた、ことがわかりました。

それでは、きちんと分別してみましょう、ということで、

上図の様にチケット編成をアレンジしてみました。この新しいチケット編成は、以下の様な思考から導き出されています。:

  1. 「PM部内レビュー会」は、開発意思決定プロセス上、最重要なアクティビティであると分かった。

  2. 「POチームとしてのワーク」には、「PM部内レビュー会に持っていくまで」のワークと、「PM部内レビュー会でGoが出た」以降のワークとに分けられることが分かった。

  3. だったら、えいやと、前者を「ディスカバリー」に、後者は「デリバリー」にマップしてみたらどうか?

  4. 元々「見積もれないもの」チケットとして行なっていたワークには、ディスカバリーとしてのPoC等と、デリバリーとしての技術検証や全体設計が混ざっていた。これらを分別して、「ディスカバリー」チケットと、デリバリーとしてのワークを表す「全体設計」チケットを用意することとする。

  5. 元々「タスク」チケットとして行なっていたワークには、"その他もろもろ"が含まれていた。内訳を分析すると、結局の所、ディスカバリーとしてのワークをサポートするもろもろ調査等か、運用・保守面、あるいは開発者体験面の改善ワークかに大別できることがわかった。前者は、「見積もれないもの」由来のディスカバリーのワークと統合してよいだろう。後者は、別途「開発者ストーリー」というチケット種別を設けて、陽の目があたる様にしよう。

加えて、チケット再編成するこの機会に、バリューストリーム中の全活動を、一定定量的に把握できる様に、全てのチケットにストーリーポイントを付与することとしました。

具体的には、「ディスカバリー」チケット、「全体設計」チケットのワークは、基本的にはタイムボックスで見積もられる様なものです。が、1h〜2hのタイムボックスを仮に1ストーリーポイントだとして換算して、ストーリーポイントを割り振ることとしました。

また、今まで「UXに直接関わらない機能や部位の開発」は、タスクチケットとして、ストーリーポイント計上対象から外していましたが、「ユーザーストーリー」に対して新たに設けた「開発者ストーリー」は、ストーリーポイント計上することとしました。

第IV期:デュアル・トラック体制完成期(あるいは、まとめ)

認証チームの開発プロセス運用に、新たな地平が見えてきました。

一つのチームで、ディスカバリーとデリバリーの両輪を一体的に回す様なスタイルには、「デュアル・トラック・アジャイル」という名前が付いていたんですね!

「PM部内レビュー会」を境に、ディスカバリー・トラックとデリバリー・トラックとに分けて捉えられる、そうしよう、という点が今回のカギです。とすると、「POチームとしてのワーク」は、ディスカバリーとデリバリーに跨っています(いました)。元々は、「POチームとしてのワークも可視化しよう」というモチベで始まりました。しかし、例えば「全体設計」チケットに基づくワークは、「POチームとしてのワーク」と「開発チームとしてのワーク」の両側面を持っています。デュアル・トラック体制の下では、この点を分別しても、あまりうれしみは無いと思えました。そういう観点よりも、デリバリーサイドのワークとディスカバリーサイドのワークのバランスを見ることの方が、フルサイクル開発プロセスの最適化に寄与すると思えます。

現在の認証チームのJiraのバックログには、スクラムのいう「プロダクトバックログアイテム」以外のチケットが乗っています。(これまでに挙げたチケット種別以外にも、障害対応、運用対応チケットがあります。)むしろ、「プロダクトバックログアイテム」と言えるだろうチケットは、「全体設計」、「ユーザーストーリー」、「開発者ストーリー」の3種類のみ、です。

以下は現在運用している(完全な)Jiraチケット一覧です。

なお、ここでのストーリーポイントは"アウトプット"量の見積りとなります。("アウトカム"量は、「「ユーザーストーリー」のストーリーポイントに、施策ごとの適当な係数を掛けたもの」として扱うのだろう、と考えています。)

この様なチケット運用によって、チームのフルサイクル全てのアクティビティが一定定量的にトラッキングできる準備が整いました。チケット毎のサイクルタイムを追えるとともにともに、施策毎にディスカバリーからデリバリーまでの総リードタイムも追えるでしょう。(施策に対応してエピックを作っています。)チケット種別毎の消化ストーリポイント比率の推移を追うことで、d/d/dに対してディスカバリーワークがバランスしているか見たり、フルサイクル開発プロセス中のボトルネックを見極めることもできそうです。今後、こういった感じで、フルサイクル開発プロセスの全体最適マネージのプラクティスを固めていきたいと、と考えています。

次世代データ基盤プロジェクトへのAI導入とSnowflakeブートキャンプについて

データエンジニアのみっつと申します。 この記事はSnowflakeアドベントカレンダーの11日目の投稿です!

今回は、我々のプロジェクトで進んでいるAIの活用と、Snowflake社と共同で実施したブートキャンプを通じた、AI/ML導入への取り組みについて紹介します😃
(ここの文章の大半はAIの力を借りて生成しました😃)

はじめに

近年、AI(人工知能)進歩は目覚ましく、私たちの開発現場でも活用が進んでいます。特に、開発者やデータ基盤利用者の支援において、AIの導入は生産性の向上や新たな価値創出につながっています。

続きを読む

読書会で広がる視点と実践のヒント

この記事は、kubell Advent Calendar 2024(シリーズ 2)の11日目の記事です。

こんにちは。QAエンジニアの稲垣です。 入社3ヶ月目に私が初めて開催した読書会についてご紹介いたします。

思えば、私がプロダクトの方々と深く関わるきっかけになったのはこの読書会でした。 当時、ChatworkプロダクトにおけるQAエンジニアは私1人でした。同じ職種の方がいないことで参加者が集まるのか少し不安でしたが、募集をしたところ10名の方が集まってくださいました。 そのとき開催した読書会についてご紹介いたします。

読書会開催に至った経緯

去年アドベントカレンダーを読んでいたら、奥澤さんの下記の記事が公開されていました。 creators-note.chatwork.com

こちらで紹介されていた衝撃を受けた3冊の中に「LEADING QUALITY」が入っていました。

「LEADING QUALITY」は、ソフトウェア品質はビジネスを左右する要素と捉え、品質の大切さをいかに組織に広め、品質文化を醸成するかが記されており、1人目QAエンジニアとして入社し、品質文化を醸成したいと考えていた私としては見逃せない一冊でした!

また、奥澤さんが背中を押してくださったこともあり、参加者を募り2024年1月〜4月にかけて読書会を開催しました。

続きを読む

次世代データ分析基盤のさらなる飛躍を目指して

こんにちは。データエンジニアのみっつと申します。 この記事はkubellアドベントカレンダーの10日目の投稿です

2024も引き続き次世代データ分析基盤プロジェクトを推進しました😃

今回は、2024年の実績と2025年の展望について、次世代データ分析基盤のさらなる飛躍を目指す取り組みをお伝えします📘
(文章の大半はAIの力を借りて生成しました😃)

参考情報

利用拡大へ向けてステップアップを目指す次世代データ分析基盤開発について - kubell Creator's Note

続きを読む

Storybookで任意のテンプレートエンジンを利用する

kubell Advent Calendar 2024 シリーズ 1の12/9の記事です。

qiita.com

こんにちはkubellのフロントエンド開発部の末竹(magcho)🐧です。

今日においてフロントエンドのUIにおけるカタログ・テスト基盤としてStorybookが採用されることがあるかと思います。 特に最近のStorybookではコンポーネントテスト・UIテスト・振る舞いテストとしての機能が充実しています。

Storybookは公式にReact, Vue, Angular, ...をサポートしており少しの設定でこれらのフレームワーク(テンプレートエンジン)で作られたコンポーネントを掲載できますがそれ以外のフレームワークで作られたものは利用ができません。

本記事では任意のフレームワーク(テンプレートエンジン)で書かれたマークアップをStorybookに掲載する方法について紹介します。

今回は以下のbuttonタグを10個表示するSmartyのマークアップを題材に扱っていきます。

{$lang = "smarty"}
<div>
  {for $i=1 to 10}
    <button>{$i}</button>
  {/for}
</div>
<b>This is {$lang}</b>
続きを読む

チーム内のテスト管理のフロー改善について

こんにちは。認証チームのいまひろです。

こちらはkubell Advent Calendar 2024 シリーズ2の12月9日の記事になります。

さて、認証チームでは、Jiraを使用してプロジェクト管理を行い、TestRailを使用してテスト管理を行なっています。

機能開発は、Jira上に作成された課題(ストーリーチケット)単位で行われ、課題内のユーザーストーリーを満たしていることを保証するために、TestRailによるテスト管理が行われています。

そのため、Jiraの課題の中にTestRailのテスト管理がシームレスなフローとして組み込まれていると、開発のプロセスが全体的に管理しやすくなり、生産性や品質向上につながることが期待できます。

この記事では、チームに導入したテスト管理のフロー改善についてお話しさせていただきます。

続きを読む