Slackを見るのが仕事な僕と4つのスクラムチーム
はじめに
はじめまして、西内です。仕事中の一人称は僕なので、この記事でも僕と言うことにします。
で、アペルザではどういうことをしているかと言うと、リリースマネージャーだったりスクラムマスターだったりQAだったり、薄く広く横断的なときもあれば深く関わることもある。そんな感じです
……が、「あなたは何している人なの？」って聞かれたら、いつも🤔となります。
強いて言えば、↓かも知れません。
さて、本記事では別の視点から見たアペルザという組織についてお伝えできればな、と思っています。
想定している対象読者は「転職潜在層など、アペルザのプロダクト開発に興味を持ってくれた人」です。
「ふ〜ん、こんな感じなんだ」と思ってもらえたなら、記事を書いてよかったと感じます。
というわけで、内容的には特に学べることはないんじゃないかと思っていますが、もしも参考になったのであればそれはそれで幸いです。
あと、プロダクト開発やスクラム開発に関する用語が出てきます。想定読者的に、それらについての説明は省略させていただくので、予めご了承を。
「Slackを見るのが仕事」と呟くことになったきっかけ
入社後にやったこと
最初は業務委託でした。
前職を完全に辞めた状態だったので、フルタイムでお試しするという”てい”ですね。
※フルタイムではなくとも、副業で関わっていただいて雰囲気を知っておくことも出来るっぽいです。
まずはリリース周りの管理や整備などを行っていきました。
そこにはいくつか課題がありました。
チケットでリリース対象物を管理しているものの、リリース直前になってもリリース可能な状態であることを示すステータスになっていなかったり、リリース対象であるはずのチケットが管理対象外になっていたり、その他もろもろ。
「管理対象外になっていた」について補足すると、アペルザではチケット管理にはJIRAを使っており「修正バージョン」という項目でいつリリースするのかを管理しています。その項目に何も設定されていない場合、第三者のテストが行われなかったり、リリースに必要な準備ができていなかったり、最悪のケースではそもそも対象のアプリケーションがリリースされない恐れがあったりします。
当時はEM(エンジニアリングマネージャー)の染谷さんやQA(クオリティアシュアランス/品質保証)リードの佐々木さんがリリース管理を担ってましたが、二人とも多忙な身だったためか、少し疎かになっていたように見えました。
僕がそのあたりをごっそり巻き取った感じになります。
最初のうちは愚直にチケットステータスやコメントで判断して、1つ1つ担当者に聞いていました。
現在では後述する各スクラムチームでリリース対象物を管理するようにもなっています。それでも少なからず確認する機会はありますが、数は激減しましたし、大抵は担当チームに聞くという形になりました。
修正バージョンについても同様で、チームごとに管理するようにしてもらい反映漏れがほとんどなくなりました。
冒頭のスクリーンショットについて述べると、リリース日の数日前に各チームリーダーやEM/CTOなどが集まって話す場(リリースレビュー)で使われる資料のテンプレートです。その場ではDDL/DMLの実施タイミングやAWSリソースのデプロイ状況だったり、リリース作業に関するリスクだったりを確認しています。
[学んだこと、行動によって生まれた変化]
- 権限移譲というほど大袈裟なことではないものの、チームに任せたり伝え続けることでプロセスが定着していく実感があった
- リリースレビューを行うことによる、リリースに対する安心感が生まれたこと
- 入社間もない身では認知できないものの、他者からの言葉で貢献していることに気づけた
スクラムチームの立ち上げ
入社から数週間後に1つ目のスクラムチームが組成され、そこに僕はスクラムマスターとして入り、アジャイルコーチである藤原さん(@daipresents)と共にチームビルディングをはじめました。
アペルザクラウドWebFaxを作ったチームなので、FAXチームと呼ぶことにします。
FAXチームは国籍が様々で言語は日英混在しており、ほぼ日本語しか話せない僕は手も足も出ず、スクラムイベントのときはコーチの藤原さんにおんぶにだっこでした。
ちなみに過去のアペルザでもレトロスペクティブ(ふりかえり)をやっていたようですが、長続きしなかったみたいです。それはもしかしたら言語の壁が厚かったからかも知れません。
その点、今では日英混在するチームでは英語を話せるコーチの藤原さんやEMの染谷さんたちがファシリテーションをしてくれており、レトロスペクティブなどが継続して実施できるようになりました。
さて、立ち上げ期に僕が他に何をしていたかというと、正直あんまり覚えていません。もしかしたら何もしてなかったかも知れません。
ただ少なくとも「スクラムっていうのはこうやるんだぞ」みたいなことはあんまり言っていなかった気がします。「教科書的にはこうだけど、」という話をした記憶はありますが。
それよりも、FAXチームで発生している課題をどうやって解消していくかに時間を使っていたっぽいです。
たとえば、
- 開発する機能の優先度はどうするのか
- リリースにはどのチケットが対象で、機能的なスコープはどこまでか(いわゆるMVPの話)
- チケットに記載する内容やレビュー
などで、プロジェクトマネジメント的なことを当時のプロダクトオーナーでやFAXチームのリーダーとよく話していた記憶があります。
そしてスプリントを重ねていくうちに、このあたりの調節が良い感じになり不具合の数が減るなど品質面も良くなり、FAXチームの成果は向上・安定していきました。
[学んだこと、行動によって生まれた変化]
- コミュニケーションの大事さ
- 何が正解かはわからないので、目の前のことに向き合いよく観察するようになった
スクラムチームが4つに
2020年も残り3ヶ月という頃には社員数も増えていき、その頃から今現在まで4チーム(+α)存在するようになります。
この頃は、「スクラムってなに？」「ストーリーって？」「受け入れ基準は何を書けばいいの？」そんなことに答えるかのように、社内向けの記事を書いては開発部全体に向けたミーティング、通称All-hands Meetingで発表したりしていました。
FAXチームにはスクラム経験者がいたからか最初の段階から受け入れ基準が書かれており、とはいえそれがうまく機能していないように思える時期もありつつも、最終的にはこれも定着するようになりました。
新しく増えた3チームでは、当初はこの受け入れ基準を書くという方法はあまり受け入れられてもらえずといった状況もありました。オフショアのQAチームとのコミュニケーションの方法としては、受け入れ基準を使うのが良いという実感があったり、そのことがレトロスペクティブの良いこととして挙げられたり、FAXチームではそれでうまくいっているという事例も後押ししたりして、今では当たり前になっています。
現在のアペルザでは開発する機能を考え管理していく上で、次のようなことを各チームで行っています。
- MVPを意識し「あったほうがいいかも知れない」みたいな機能は作らない
- 優先度を決め、優先度が低い機能は次のリリースからは外れる可能性があることを合意する
- 受け入れ基準を記載し、開発する内容の認識齟齬をなくしていく
- リリース対象のチケットには修正バージョンを付与する
これらがアペルザの開発チームの共通のプロセスになっています。
そこからさらにチームごとに特色があります。
あるチームではデイリーミーティングに30分ほど時間を確保していたり、あるチームでは2週間スプリントの中間で実際に動作するアプリケーションを使ってレビュー会をしたり、またあるチームではJIRAだけでなくNotionも使ってタスク管理をしていたりします。
これらは何らかの課題を解決するために工夫した結果です。どういった方法で解決するかはチームの状況やメンバーの興味関心も絡んでいるかと思います。いずれにしても、これらの解決策がうまくハマった(と感じる)ので、定着していったのかな、と感じています。
[学んだこと、行動によって生まれた変化]
- 十人十色という言葉があるように、個人だけでなくチームにも色があることがわかったこと
- 各チーム、MVPへの意識が段々と強まっていったこと
- また、他の人やチームが何をしているかに関心を持つようになっていったこと
これから
(引用画像中央上: アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：オルタナティブ・ブログ )
(引用画像左下: アジャイル・スクラムチームの成熟度モデル / Agile and Scrum Maturity Model )
(引用画像右下: アジャイル・DevOps時代のCD成熟モデル / The Continuous Delivery Maturity Model in Agile and DevOps )
ここまでは僕が入社してからの変化をざっくりお伝えしてきました。
ここからは少し先の話に入ります。
個人的な妄想であったりEMの染谷さんとも話していることではあったりしつつも、がちっと決まっているわけではない……程度の話です。
今回は「アジャイルのライトウィングとレフトウィング」を例にして述べていきます。
これまでのアペルザでは主に「レフトウィング」に取り組んで来ました。それ自体もまだまだで発展途上だとは感じる一方で、少なくとも僕が入社した当時と比較するとけっこう変わったなあと思います。
そしてこれからは「ライトウィング」に取り組む機運が高まってきていると感じています。
その理由は様々ですが、そのうちの1つとして、機能追加によるテスト範囲の増加やデグレなどが目立つようになってきて見過ごせなくなりつつあることでしょうか。
現在チケット駆動開発やバージョン管理はもちろん、ある程度自動化された継続的デプロイのシステムはありますが、それら以外のプラクティスをほとんど行えていない状態です。
下記は取り組み始めていることの一例です。
- ユニットテスト(フロントエンド/バックエンド)
- 自動ビルド時にテストや静的解析(*組み込み済み)の実行
- DDDによる設計やリファクタリング
- 一部のチームで実践中(詳しくは冒頭で紹介した海老原さんのnoteを！)
また、他にも課題は色々とあります。具体的にどこに問題があるかは伏せますが……。
- サービスごと(チームごと)のリリースがやりづらい
- ロールバックがしづらい
- リリース時に切り替えるタイミングが制御しづらい……etc
おわりに
ここまで読んでくださり、ありがとうございました。
この手の記事を久しぶりに書いた身としては、言語化や情報の整理がまだまだだなぁ、と感じました。
最初に述べたとおり、少しでも雰囲気や課題感が伝わり、カジュアル面談などの話のネタにでもなればと思います。
というわけで、We're hiring!! (1回言ってみたかった)
この記事が気に入ったらサポートをしてみませんか？