How to resolve compile error: “Apps targeting Android 12 and higher are required to specify an explicit value for `android:exported`"

If your app targets Android12, the document says:

If your app targets Android 12 and contains activities, services, or broadcast receivers that use intent filters, you must explicitly declare the…


When you use Protocol Buffer with Gradle project like Android, major choice of compiler and runtime environment would be either Protobuf Plugin for Gradle by Google (the compiler is called protoc)or Wire Gradle Plugin by Square (the compiler is the same Wire).

In this post from Square, it is said…


FiNCでAndroidエンジニア 兼 スクラムマスターをしている吉田です。

日課は毎朝の散歩とラジオ体操です。

弊社では、2020年7月21日(火)に、糖質管理やアドバイスレポート機能など、ワンランク上の健康管理ができる新しいサブスクリプションサービス「FiNC Plus」をリリースしました。

弊社ではユーザーに価値あるサービスを継続的に提供するためにアジャイル開発を取り入れているのですが、その実現方法は開発チームに委ねられています。そんな中、このFiNC Plusを開発している「dev2」というチーム(以後分かりやすく「Plusチーム」と呼びます)では、スクラムガイドに則ったスクラムでFiNC Plusを開発し、今でも改善を続けています。

しかし、社内でスクラムの知見はまだそこまで溜まっておらず、スクラムの適応も日々試行錯誤しながら改善しています。スクラムガイドにも「軽量 • 理解が容易 • 習得は困難」とあるように、理論は簡単でも実践がなかなか難しいスクラム。

そこで本記事では、我々Plusチームがどのようにスクラムを適応してきたかを以下のステップで紹介します。

  1. なぜスクラムを取り入れたのか
  2. 現状のスクラム体制
  3. これまでに遭遇したスクラムの壁
    ・専属PO不在のスクラムチーム
    ・プランニングの時間でリファインメントをしてしまう
    ・一方通行のバックログリファインメント
    ・スクラムマスターがPM的なポジションや、POと開発チームとの橋渡しになってしまう
    ・チームメンバー同士の信頼関係の構築
  4. 今後の展望
    ・スクラムについてスクラムチームのみんなが理解している状態にして、チームの自己組織的な成熟を支援する
    ・仮説検証を繰り返しながら、どんどん良いプロダクトにする
    ・スクラムをほかチームにもスケールし、社内でのスクラムの知見を増やす

なお、本記事はスクラムについての基礎知識があることを前提としています。

また、弊社の他のチームがどのようにアジャイル開発しているかについては、同じくAndroidエンジニアでキャンプの達人 佐多の↓記事をご覧ください。

なぜスクラムを取り入れたのか

実は我々Plusチームがスクラムを経験するのは今回が初めてではなく、前身となるチームでもスクラムを取り入れていました。そのため、Plusチームがスクラムを採用するのは自然の成り行きでした。

しかし改めて振り返ると、スクラムはプロダクト開発における責務を3つの役割(PO、開発チーム、スクラムマスター)に分散し、かつチームを自己組織化させることで、チーム外から指示されることなく、チーム内でも特定の管理者に依存せず、チームメンバーが互いに協力し合いながら一丸となってプロダクトの改善をし続ける仕組みになっています。FiNC Plusというサービスを長期に渡り継続的に改善しユーザーに価値を提供し続けるためには、チームメンバーひとり一人の相乗効果が大切になってくるので、そういった点でPlusチームにはスクラムが合っていると感じています。

他にも、スクラムはルールが定義されているため社内の他チームにも展開しやすく、また広く普及しているフレームワークなので本や勉強会が豊富で知見を得やすいのもメリットだと感じています。

現状のスクラム体制

ここでは、Plusチームが現状どのようにスクラムを運用しているか簡単に紹介します。

チーム構成

以下のように、合計14名のスクラムチームとなっています。

  • PO 1名
  • スクラムマスター 1名
  • 開発チーム 12名
    (Android 1名/iOS1名/サーバー4名/QA5名/デザイナー1名)

スクラム経験者であれば、この開発チームの人数を見るとゾッとするでしょう。スクラムガイドでも、開発チームが9人を超えると調整が大変になり有益さも減ると書いてあります。しかし、メンバーの入れ替わりなどによる現在のメンバーのスキルセットを考慮し、このような構成となっています。(メンバーが多い苦悩は後ほど共有します)

スプリント

2週間スプリントを採用しています。前身チームでも同じ周期だったので慣れているのと、モバイルクライアントとサーバーがあり、1週間だとどちらかが遅れるとスプリントから溢れやすくバッファ的な意味でも2週間としています。一方、2週間だと「差し込み」が多くなりがちで、1週間スプリントの場合は「次スプリント(1週間後)でやろう」のように差し込みを減らしやすかったり、仮説検証やチームの振り返りのサイクルが早くなるメリットもあり、1週間スプリントとすることも検討しています。

各種スクラムイベント

スクラムガイドに則り、スプリントプランニング、デイリースクラム(朝会)、スプリントレビュー、レトロスペクティブ の各種イベントに沿ってスクラムを回しています。また、プランニングに入る準備としてのプロダクトバックログリファインメントは隔週で曜日固定としています。

FiNC Plus全体定例

その他、FiNC Plusというサービス全体で部署の垣根を超えて早期のコラボレーションを生み出せるように、分析・CS・マーケなど関係する各部署のメンバーが集って週次で進捗報告をする定例を設けています。KGI・KPIの進捗やカスタマーボイス・問い合わせの共有などもこの場で行われています。

これまでに当たってきたスクラムの壁

ここでは、これまでPlusチームがスクラム開発する過程で当たった壁と、それがどう改善されてきたかを紹介します。

専属PO不在のスクラムチーム

現在はPlusチームの専属POがついていますが、少し前まではPlusチームに専属POはおらず、いっときはPO的な立場の人が3人同時にいました。というのも、FiNCアプリには様々な機能がありそれだけ多くの企画が同時に並行して動いている一方、開発ラインが限られているためです。実際、FiNC Plusの開発中も、クライアント側は「食事アドバイス」というPlusとは別サービスの開発もしていました。

バックログが無法地帯
複数POがいても、誰か特定の人がバックログの管理にオーナーシップを取れていれば良かったのですが、当時はそうした状況でもなくバックログの管理責任の所在が不明瞭でした。結果、Plusチームのプロダクトバックログには「FiNC Plus」「食事記録」「食事アドバイス」などそれぞれのPO管理のチケットが立ち並び、それに加えて今となっては不要なチケットエンジニア用語で書かれて中身のよく分からないチケット同じ内容のチケットなどが乱立しており、はっきり言ってカオスな状態でした。

「POさん、バックログはあなたのものです!」
そしてつい最近、開発ラインが増えたことでようやくPlusチームに専属POが1人つくことになりました。そこでまずはPOに「バックログはあなたのものです、あなたが責任を持って管理してください」と伝え、バックログのオーナーシップを専属POにとってもらうことでバックログが整備されるようになりました。 これまでエンジニア用語で書かれていて内容の分からなかったチケットが、実はPlusの品質維持のためにとても重大なものであるとPOが気づけたり、大きな発見がいくつもありました。こうして、改めてプロダクトバックログにあるアイテムを全てPOが目を通し優先度をつけることで、企画だけでなくバグ修正や技術負債対応も含めたPlusチームのロードマップを引き直すことができました。

このように専属POがいることでようやくスクラムの体制が整ってきましたが、一方で、PO/スクラムマスター/開発チームが一つのスクラムチームとしてお互いに協力し合う文化創りはまだまだ改善の余地があると思っています。

プランニングの時間でリファインメントをしてしまう

リファインメントのやり方はスクラムガイドにない
スプリントプランニングは、そのスプリントで「何を」「どのように」開発チームが完了させるかを決める場所です。そしてその判断をするために事前に優先度の高いバックログアイテムの詳細(受け入れ条件や開発規模など)をPOと開発チームで詰める作業があり、これをプロダクトバックログリファインメント(PBR)と呼びます。しかし、PBRの必要性はスクラムガイドにあるものの、その実現方法については一切触れられておらず、自分たちで考える必要があります。

不定期開催のリファインメントで開発リズムが崩れる
これまではPBRの開催タイミングが決まっていませんでした。すると、専属POの不在などもあり、各POがそれぞれ思いおもいのタイミングで開発チームにリファインメントを依頼し、スプリント中の開発リズムが崩れる開発時間が想定外に減ってしまう現象がありました。

リファインメントが開催されずにプランニングが始まる
あるいは逆にPOがどのタイミングで開発チームに依頼したらよいか分からないままリファインメントが開催されず、優先度が高いという情報のみでプランニングが始まり、プランニングの最中でリファインメントを行ってしまうことも多々ありました。リファインメントはユーザーストーリーの詳細を詰める大事な場なので、「プランニング時間内にちょっとだけ」はできません。

リファインメントの日を固定する
このように、突発的なリファインメント依頼とリファインメント漏れを防ぐために、隔週で固定日にPBRをするようにしました。一方、開発リズムという観点では、リファインメントをする日が事前に分かっているとしても、スプリント中に数時間PBRに向き合わないといけないというのは、やはり開発チームにとってはやりづらさがあります。今後は、このPBRをいかに改善していくかが一つのテーマになりそうです。

一方通行のバックログリファインメント

先ほどはPBRのタイミングについて説明しましたが、PBRの質にも改善したい点がありました。PBRはPOと開発チームとがストーリーチケットについて双方向で議論することで、そのストーリーに対する認識齟齬を無くし開発準備が整った状態とする場です。具体的には以下のようなことを話し合います。

  • どんなユーザー体験(ユーザーストーリー)を実現したいの?
  • その背後には仮説・背景・課題があるの?
  • それを満たすにはどんな方法があるの?
  • 受け入れ基準は?
  • 開発規模は?

つまり、プロダクトの価値を高めるための方法をPOと開発チームとで話し合い理解し合うとても大事な場所で、そこでは参加者ひとり一人の 主体的な参加が大切です。

しかしこの議論が双方向にあまりされず、スプリントが始まってからどんな実現方法にするかや受け入れ条件について話し出すことが多く、コミュニケーションコストがかかっていました。PBRという会議体はあっても意義のあるリファインメントがあまりできていない状態でした。

そしてこれは、スクラムマスターである私の責任だと感じています。というのも、そもそもこれまでPBRが何のためにあり、何を話す場で、参加者にどんなことが求められているかを共有できていなかったからです。

なんのための会議体で、何が求められるのかを説明する
そこでチームの振り返りの場を使い、PBRについての説明と、POと開発チームとで双方向の議論が望ましいことをチームに伝えました。説明の際には、アジャイル開発におけるプロダクトバックログのリファインメント方法の提案 より、「リファインメントさえやれば良いのか?」というスライドを引用させていただきました。
また、話し合う項目を明確化するため、プロジェクト管理ツールAsanaのチケットの項目に、既存の開発規模などに加え、「背景(課題)」「実現方法」「受け入れ基準」の項目を追加して、PBRの時間でこれらを埋めるようにしました。


Imagine you have a ScrollView and required to send an impression log of the specific item in the ScrollView.

How to achieve it?

The sample below demonstrates that when the visibility of “4th component” is toggled, toast that: when shown toast Text Four SHOWN!!!, and hidden toast Text Four HIDDEN…


When you want to display text with icons as one TextView like below, how do you achieve it?

One simple approach is to constraint three components: TextView of “Press” and ImageView of camera drawable, and TaxtView of “please!!”.

But what happens when you need to support different languages with string…

nichiyoshi

Android Developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store