はじめに
11/13に、スクラム関連の勉強会を探していて見つけた、
「みてねのMeetup #3 ★4.7の価値創造を実現する開発プロセス」に行ってきました。
メモがてらまとめを。
みてねのProduct Ownerによるサービス紹介
私自身は独身なので使ったことのなかった、みてねのサービス紹介がありました。
デザインがめっちゃApple風だなと思いましたが、洗練されていて良い！
私もいずれ結婚して出産することがあれば、使いたいです。
みてねのスクラム開発
Speaker：酒井 篤さん（Engineering Manager/Scrum Master）
資料：
チームの歴史
「メンバー数にキャップがある」という話が印象的でした。
私自身はメンバー7人のチームでスクラムマスターをやっていますが、
これ以上増えたら1人1人が見えなくなるのかなとぼんやり思っていたのでなるほどという感じでした。
増えてみたらそのキャップに気付けるのでしょう。。。
スクラムチームの変遷
小規模でスタートしたみてねの開発チーム（スクラムチーム）の変遷について。
スクラムメンバーとステークホルダーの人数は8人→30人、
スクラムチーム（開発チームのほうが正しいのかなと思いました）1つ→3つになったそう。
3つのチームは下記で、イベントの参加人数30人は壮大だなと驚きました。
- アプリ開発（エンジニア9人＋4人） →30人でイベントやってるらしい
- SRE
- コンテンツ開発
大きいスクラムチームのメリット/デメリット
みてねのような大きいスクラムチームのメリットとデメリットについても話してくださいました。
メリット
- 1回のスクラムイベントで全員と意思疎通できる
- リリースプランニングがやや楽
デメリット
- スクラムマスターの負担が圧倒的に大きい、スクラムマスターはチームのSPOF
→全員がスクラムマスター化し、チームができるようにすれば良い
スクラムマスター自信はもっと省エネな活動ができるようにする
「スクラム行動指針」を作る（ケーススタディ的な感じ）
「スクラムイベントの台本」を作る チェックボックスにそって1つずつ埋めていけば終わる
「バックログテンプレート」を作る ※未完成 - スクラムイベント中の内職促進
→出なくていいイベントは出ない
アプリが顧客に届くまでのイベント
続いては、スクラムチームで行っているイベントについて。
名称は違いますが、うちでも1. と2. を開催しているので、すこし親近感と安心感が。
みてねのチームのように、
PBIの有無にかかわらずプロダクトの抱える課題についてざっくばらんに話せるとより良いなと思いました。
- バックログ準備会
プロダクトの課題や解決策を議論 - バックログリファインメント
ストーリーポイントを見積もり、POが優先順位付け - チーム内レビュー会
機能単位でみんなで動かし、リリースの可否を決める
スプリントレビューを待たなくてもOK - スプリントレビュー
バックログがどこまで終わったかを確認する - リリース
- 監視とCS待受
- スプリント打ち上げ
みてねのプロダクトを改善するエンジニアリング
Speaker：松石 浩輔さん
資料：
続いては開発チームサイドのお話。
歴史あるプロダクトにおいて起こりうる問題
- 属人化
- 性能劣化
- 細かい不具合
- ライブラリの更新、脆弱性発生
- CS対応のコスト増加
→新しい機能を作りたいが、改善もしたい
この辺は私もドキドキする話でしたが、
歴史がある＝売れてる、ニーズがあるということで本来は嬉しいこと。
なのに中身のプログラムや開発者が嬉しくない状態は私も非常に嫌で、関心ごとの1つでした。
既存機能を改善するための3つの取組み
みてねのチームでは下記3つの取組みをしているそう。
- エンジニアの知見共有会
→属人化を防ぐ取り組み、サーバ負荷・アプリクラッシュ・古いライブラリの監視 - CS担当当番エンジニア
→週替りで、サーバとアプリを1人ずつ置く - 自動化
→「スロークエリ出す君」「ライブラリ監視君」…名前（笑）
CS担当当番というのは面白いなと思いました。
聞いたところ、その分の工数を考慮するのではなく、あくまでも週替りで担当を決めてやるだけとのこと。
レトロスペクティブで振り返る機会はあるし、
そもそも対応したものに関しては何らかの形で記録が残るから問題にはならないのかしら。
稼働が高くなりすぎないような仕組みだけは考えないとなと感じました。
デザイン環境やワークフローの改善
Speaker：渡辺 直也さん（デザイナー）
資料：
①Gitを使ったデザインデータ管理
かつてはGoogle Driveを使っていたが、
データのhistoryが分からなくなる問題発生してしまったため、Gitに切り替えたとのこと。
そもそもうちのサービスに専任のデザイナーがいないので若干実感のわかない話ではありましたが、
デザイナーでGitが使えるというのはすごくプラスになるのだなと思いました。
デザインデータ管理をGitで行うために、Git LFSを使っているそうです。
- Gitの拡張機能
- 100MB以上のファイルも扱える
- Sketch、AI、PSDも対応
- 50GB 月5ドル
②apkサイズの最適化とSketch pluginの導入
画像が大きかったり、最適化されていなかったりしたとのことで、
使っていなければ削除、使っていれば最適化したそうです。
Git hooksやSketch Pluginを使ってルール化し、仕組みづくりをしたとのこと。
Pluginを作るところまでやってしまったのはすごいなと思いました。
③XCodeを使ったプロトタイピング
XCodeでプロトタイプを作ることで、
より製品に近い形でプロトタイプが作れるようにしたそう。
プロトタイピングツール
プロトタイピングルールには二種類あるとのことで、
トランジションタイプがいわゆる紙芝居のようなもの、
インタラクションタイプがまるで実際のアプリのように動かせたりテストしたりできるものだそう。
- トランジションタイプ：Sketch、Prott、Invision
- インタラクションタイプ：Framer、Origami Studio、Proto Pie
当時、トランジションタイプしか存在していなかったらしく、
インタラクションタイプのプロトタイプを実現するためにXCodeを選択したそうです。
顧客価値を最大化するユーザー駆動開発の実現
Sperker：佐藤 リョウさん
資料：
Y Combinatorのスタートアップの原則
「顧客と会話すること」が大切。
顧客の問題とプロダクトが一致するだけでいい。
- プロダクトを作る
- 顧客と話す
- 適度な運動・食事・睡眠
顧客の声を聞くツール（顧客チャネル）
- 電子メール
- ストアレビュー
- ユーザ行動分析
- アンケート
- インタビュー
CSチームのミッション
- ユーザと対話し、ユーザ体験を最良にする
- ユーザを理解し、プロダクトにフィードバックする
→スクラムチームの一員
CSチームが受け取った顧客の声を、エンジニアに伝える手段がいろいろあるよう。
ここ、本当に重要だなと。
エンジニアが顧客の声を聞く機会って、思ったよりないんですよね。
App Followでレビュー投稿をSlackに自動投稿できるらしい。
うちのチームでも使えるかも…。
アンケート・インタビュー
SurveyMonkey を使っていて、
アンケート→プレサーベイ→インタビューの流れで実施しているそう。
かなりお金のかかる調査だと思うのですが、これを定期的にできるってすごい…。
顧客理解と開発のサイクル実現
- システム化：ルーチンに、機械で
- アクセス性：透明性、非同期でいつでも
- 振り返り：成果を確認し、次に活かす仕組み
懇親会
その後は懇親会。
（出席せず退散させていただくつもりだったのですが、カニのお寿司を見つけてつい参加…）
みてねのチームではスクラムマスターを2人で分担しているらしく、
スクラムマスターが孤独の存在にならないので素敵だなと思いました。
（とはいえ他チームと情報共有する際には不便もあるのでは？と思ったり）
終わりに
他社のスクラムチームのプラクティスを聞く機会はなかなか少ないので、
なるほどこうやって応用しているのか！と面白く聞けました。
特に、スクラムマスター、開発メンバー、デザイナー、CSと
異なる立場の人からスクラムに関する話を聞けたのはいい機会だったと思います。
まだ私の見ているチームでは「カイゼンのサイクルが気持ちよく回る」状態には到達できていないので、
これからチームへの応用を考えていきたいです。