こんにちは。 kintoneのAndroidチームに所属している向井田 (@mr_mkeeda) です。 私は元々Androidエンジニアですが、最近まで自チームの抱えている問題意識と向き合うためにスクラムマスターを兼務していました。
今回のブログは、サイボウズのスクラムマスターで企画したリレーブログの1つになります。 このリレーブログは「スクラムマスターとは何をするのか？」を様々な事例を通して考える企画になっています。
私自身、スクラムマスターを名乗ってから「スクラムマスターとは何か？」が分からないまま仕事をしてきました。 そんなときにこのリレーブログ企画が始まったので、これを機会に自分のやってきた仕事をふりかえり、スクラムマスターとはどんな仕事なのか考えてみました。
kintoneのモバイル体験を良くしたい
私は社内の営業の方からkintoneのモバイルについて改善の提案を受けたことが何度かあります。 PdMと話すとkintoneのモバイル領域で実現したいことを持っていそうな印象を持ちます。 kintoneのモバイルはまだまだ良くできそうなのに、実際に開発しリリースしている機能にkintoneのモバイル機能はそれほど多くないと感じます。
需要があるのに開発が十分に行えていないような状況が続いている原因は、kintoneのモバイル開発をするチームや体制にあるのではないかと考えるようになりました。 私は1人のモバイルアプリを開発するエンジニアとして、なんとかkintoneのモバイル開発を阻んでいる問題を解決したいと思うようになりました。
そして、2023年4月に私はkntone開発チームへ異動しました。
kintoneのAndroidチームに参加した私は、開発を妨げている要因を探してチームにいくつか改善を提案しました。 ここからは、私が指摘した問題と改善案をいくつか紹介します。
1. チームが優先すべきタスクをチームで決める
チームメンバーはそれぞれ忙しく活動していましたが、みんながそれぞれの判断でタスクを取っていたため、複数のタスクが同時並行で着手され一つも終わらないスプリントがたくさんありました。 効果の大きさは置いておいて、みんながやっている活動はすべてAndroidアプリのためになるリファクタや機能開発でした。 それなのに1週間のスプリントで一つもタスクが終わらないと、ユーザに届けられるものがなにもできなかったことになってしまいます。 せっかく作業したのに成果が出ないのは勿体ないです。
私はチームがスプリント内で必ず達成したいことをスプリントゴールとして設定し、チームでタスクの優先順位を判断するように提案しました。 ゴールがあることでチームが集中すべきものの認識がメンバー間で合うようになり、スプリントで1つもタスクが終わらない事態はなくなりました。
2. リリースについてチームで向き合う
チームはAndroidアプリに対して毎日何かしらのコード変更をしていましたが、その変更をユーザに届ける（リリースする）基準がありませんでした。 基準が無いので、消化したタスクが溜まってきたらリリースする、というような曖昧な運用がなされていました。 いつリリースするかが決まっていないため、試験のスケジュールを立てにくかったり、作ったものが理由なく塩漬けにされているなどの問題がありました。
これに対して私はリリースの定義をチームみんなで話し合うことを提案しました。 議論の末、以下のような定義を決めました。
- リリースの目的
- ユーザーの課題を解決しうる新しい価値を届ける (新機能)
- 作り上げた価値を維持し続ける (リファクタリング、不具合修正)
- 目的を達成するためのリリースの形
- 2週間に一度の、定期アップデートリリース
- 緊急の不具合修正のための、臨時アップデートリリース
リリースについてチームで向き合ったことで、自分たちはユーザになにかを届けているという意識がチームに生まれたと感じました。
3. チームが任される仕事の範囲を広げる
上記2つの提案でAndroidチームは、ユーザにいつなにをどの優先度で届けるかを自分たちで判断していく文化になってきました。 スクラムチームとしてユーザに価値を届ける意識がとても高まったと感じます。 少しずつベロシティも安定してきて、スプリント単位で一定のアウトプット量が出せるようになってきました。 しかし、この時点ではAndroidチームが生み出すアウトプットの質は特に変わっていません。 チームは何かを作ってはいますがリファクタリングや不具合修正が多く、冒頭で述べたようなkintoneに期待されているモバイル機能の価値向上はまだできていないように感じていました。
そこで、次はチームに任される仕事の内容を変化させて、チームが生み出すアウトプットそのものを変えることにしました。
チーム間の関係性を考えてみる
Androidアプリチームに任される仕事について考えるにあたり、まずkintone開発チーム全体の中でAndroidアプリチームの立ち位置を考えてみました。
kintoneのAndroidアプリは、ネイティブアプリ技術者が不足していた歴史や、JavaScriptカスタマイズというプロダクト特性もあり、ほとんどのUI部分をWebアプリチームがWeb技術で開発しています。 いわゆるWebViewでUIが描画されているアプリになります。 現在のAndroidアプリチームはWeb技術で作られたUI部分の変更を自分たちではできず、Webアプリチームに依頼して開発する形になっています。
このようなチーム体制だと以下のような課題があります。
- AndroidアプリチームはAndroidアプリの機能開発をする際に自チームで完結できる領域が狭く、Androidアプリチームで作れるものが限られてしまう
- Webアプリチームはモバイル機能だけでなくPC機能も担当しており、モバイル機能ばかりを優先するわけにはいかない
この状況を何かしら変えなければ、kintoneのモバイル機能の価値を向上させる速度を早められないと考えた私は、Androidアプリチームの外に目を向け、kintone開発チーム全体の方針を決定している人たちに相談を始めました。
実際に相談した人たち
- PdM
- Webアプリチームのリーダー（社内ではエンジニアリングマネージャーと呼ばれている）
- アジャイルコーチ
- マネージャー
相談をする前はAndroidアプリチームだけで悩み、チーム単体でできる改善をするにとどまっていたため、kintone開発チーム全体で見ると局所最適になってしまっていました。 まだ具体的な方針は決まっていませんが、チーム外の人とkintoneのモバイル開発の課題を議論できる状況になったことで、Webアプリチーム側と協力しながら課題に向き合っていける形になったと思います。
自分の活動をScrumMasterWayに当てはめてみる
ここまで、kintoneのモバイル開発を良くするために私が行った活動を振り返ってきました。 まとめてみると、私のやってきたことはScrumMasterWayで示されている順番どおりになっていると感じました。
まずは第1レベル
ScrumMasterWayの第1のレベルは「私のチーム」です。ここでのスクラムマスターはチームメンバーのようなものです。開発チームの視点でものごとを見ていて、いろいろなアジャイルプラクティスを説明したり、スクラムミーティングをファシリテートしたり、妨害事項を取り除く手助けをしたり、チームをコーチしたり、すごいチームにしたりします。
Androidアプリチームに参加して最初の頃に以下を提案したとき、私はチームメンバーの1人として意見していました。
- チームが優先すべきタスクをチームで決める
- リリースについてチームで向き合う
今思えば、チームメンバーの1人として問題を自分ごとに捉えていたので、積極的に改善する気持ちになれたのかもしれません。 私の中でスクラムマスターのイメージといえば、スクラムマスター自身が問題を直接改善するというより、一歩引いてスクラムマスター以外の人間の背中を押すイメージが強かったです。 しかし、今あらためてScrumMasterWayを読むと、私のようにチームメンバーの1人として直接問題解決に動くスクラムマスターが居てもいいのかもしれないと思いました。
第2レベルへ
では、3. チームが任される仕事の範囲を広げる はどのように捉えましょうか。 3はユーザに向けて提供する価値をより大きなものにするために、kintone開発チームの中でAndroidアプリチームの役割を見直すものです。 これはScrumMasterWayの第2レベルに当てはまると解釈しました。
ScrumMasterWayの第2のレベルは「人間関係」です。スクラムマスターはチームをもっと高い視点から見ていて、チーム自身が外界との関係をより良くするための、ティーチング、メンタリング、ファシリテーション、コーチングのスキルに焦点を当てます。プロダクトオーナーに優れたビジョンを構築するよう指導したり、他のチームとの会話を促したりします。自己組織化された大きなエコシステムを構築します。
第2レベルはチームと外の関係性に着目すると書いてあります。 実際に、私はAndroidアプリチームの外の人と議論を重ねて、Androidアプリチームの次のアクションを決める活動を始めました。
自分の考え方にも視点の変化がありました。 以前はAndroidアプリチーム単体でうまく活動できるように発想していました。 最近はkintone開発チーム全体の成果の一つとしてモバイルの価値向上があり、その成果に対してAndroidアプリチームはどんな活動をすればよいか？と考えています。 視点を少しチームの外に広げると、新しい発想が生まれるようになった気がします。
この頃から、社内で私はスクラムマスターではなくエンジニアリングマネージャーと呼ばれています。 エンジニアリングマネージャーは、チームメンバー、チームが扱う技術、kintone全体の方針を理解し、チームをリードする役割と社内では定義されています。 社内で役割の名前は変わりましたが、エンジニアリングマネージャーはチーム外との関係性を考える第2レベルのスクラムマスターと捉えられると考えています。
このあたりは、小田中育生さんのブログでも言及されていて、共感しました。
「スクラムマスターって何をするの？」に対する私なりの答え
私の場合、kintoneのモバイル体験をもっと良くしたいという気持ちを持ち、手段を問わず行動してきました。 その結果、エンジニアという枠を超えてスクラムマスターやエンジニアリングマネージャーなどの役割を担うことになりました。 役割の名前は状況に応じて変わりますが、根本にあるのは チームやプロダクトを良くしたい という思いです。
私以外の「スクラムマスター」と名乗る人たちも、同じように「チームやプロダクトを良くしたい」という気持ちを持って行動しているのではないでしょうか。 もしあなたがチームやプロダクトを良くしたいと思っているなら、今の役職名に囚われず、少しずつでよいので勇気を持って行動してみてほしいです。
