機械学習・データ部 / データチームの @irotoris です。こんにちは。
データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。
データチームの開発スタイル
データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。
その月曜朝の計画会で、まずプレスリリースを書いています。
プレスリリースとはなにか？
本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるための文書です。データチームのユーザーである社内メンバーに向けて「従業員体験がどうなるか」というメッセージを書きます。
AWS の What's New ブログをご存知でしょうか？AWS では新機能がリリースされると Amazon Data Firehose と Snowflake Snowpipe Streaming を使用してデータを Snowflake にストリーミングする のようなページが公開され、SNS では「よさそう！」「待ってた！」「これどう使うんだ？」のようなコメントが並びます。
文章の構成は以下のようになっていることが多いです。
- 今回の新機能・改善によってできるようになったこと
- いままでどうだったか
- 顧客にとってどんな価値があるか
- 使い始めるためのドキュメントリンク
実際に真似てチームで書いている文書はこちら。サッと書ける文章量です。
 |
ステータスやリリース月の他に、対象ユーザーやタグなどを属性として設定しています。また開発の最中に発生した技術選定や仕様検討がある場合は、別途 ADR (Architecture Decision Record) や Design Doc にまとめてプレスリリースにリンクしています。
AWS の What’s New ブログが好きなので真似て全部文章で書いていますが、もう少し項目を構造化してテンプレート化したいところ。
プレスリリース駆動開発のリズム
データチームではこれまで兼務メンバーが多くあまりスクラム開発の様相はなかったのですが、人数も増えてきたことでプロダクト開発チームに倣って、データチームでもスクラム開発を整え始めました。こんな感じで回しています。
- 月曜日のスプリント計画会で、今週 or 今月開発する機能や改善をリリースとして書く
- レビュー予定日を入れて、今週開発するものの認識をチームで揃える
- 金曜日のスプリントレビュー会で、リリースに値するかどうかを検査する
- やったこと、できたものに敬意を払いつつ、ここってどうなってる？こういうケースは？…などもっと価値を高めるためのツッコミ会として定義
- OK ならその場でステータスを「利用可能」または「プレビュー」に変更する
- NG の場合は指摘内容を持ち帰り修正して次回レビューへ
なぜプレスリリースをスプリント計画時に書くのか
使われないものを作らないため
タスクに取り掛かる前に顧客への提供価値を顧客に向けて言語化することで、自分自身のやること・課題への解像度を上げ、使われるものを作ろう、という試みです。この文書がスラスラ書けない場合、作るものが実はよくわかってなかったり、HOW に寄ってしまっていたり、ユースケースが曖昧だったりします。自分自身でも書けないのにチーム内での認識も揃うはずはありません。
また、データエンジニアリングにおける技術の変化はとても早く、新しい技術や不確実性を下げるための検証も行います。その場合でも、その検証の先にあると思われる顧客への価値を意識して書くことで、真に使われるものを作るためのタスクとして認識することができます。
 |
負債返済系タスクでも同様のことが言え、負債返済後に実行可能になるチームや基盤の能力が、価値提供の速度だったり、既存機能の品質を上げるのであれば、それは間接的には「使われるものを作る」ことになると思っています。
内部的な目標設定と動機づけ
自分たちがやると決めたことをやり切るために、最初に計画・目論見を明文化して最後にやれたかどうかを検査しようという意図もありました。もともとバックログアイテムにも達成条件は書いてありましたが、自分の文章で改めて顧客に対して提供しようとしていることを書き出すとやる気が上がるでは？という仮説です。
これからのこと
データチームでのプレスリリース駆動開発を紹介しました。
まだ始めて3週間ほどでいろいろ試している最中です。直近は技術検証的なタスクも多く、顧客価値に直接つながるようなものは少なかったのですが、将来的な提供価値を目指すための道しるべとして機能していたように思います。同僚から「このプレスリリースの方向は違うと思う」みたいなフィードバックをもらって設計議論に発展することも。また、チーム外への発信もしやすくなりました。チームの月報を書くときに今月のアップデートをこのプレスリリースベースで行っています。
これらはチーム開発をよくするために行っている取り組みですが、今後は AWS 社の What's New ブログのように、社内ユーザーとの距離をもっと近づけるツールとしても設計していきたいなと思っています。
毎回思うんですが、インフラやデータ基盤、SRE チームのような横断・基盤系のチームって目標管理や OKR の運用難しくないですか？特に立ち上げ初期と改善フェーズで当然力学も違うので、毎回試行錯誤しています。
そんなよもやま話に付き合ってくれる方、もしいたら @irotoris とお話しませんか。最後にカジュアル面談のリンクだけ置いておきますね。それでは 👋
