サントリーウエルネス DX推進部の齋藤です。2024年1月に入社し、Comadoのネイティブアプリ開発チームのリーダーを担当しております。
今回の記事では、アジリティ向上を目指して、Comadoのネイティブアプリ開発チームをカイゼンしている話をします。
Comadoとは
私が担当しているComadoは、サントリーウエルネスのお客様が無料でお使いいただける健康行動アプリとして、2022年10月からサービスの提供を開始しました。ファーストリリースから2024年5月現在までのおよそ1年半は、機能のエンハンス、UI/UXのブラッシュアップ、不具合対応を継続的に実施しています。
アジリティ向上の必要性
はじめに、Comadoの開発戦略を説明します。
(抜粋)
目の前の事業を実現しながらも将来の事業成長に合わせ、開発チームとしてのアジリティ向上やシステムの進化も実現します。
今回フォーカスするキーワードは、アジリティ向上です。
アジリティとは「俊敏性」を意味します。VUCAの時代、ビジネス環境は急速に変化しており、企業はこの変化に迅速に対応する必要があります。
プロダクト開発においても、アジリティの高さが求められます。
プロダクト開発Aと比較すると、プロダクト開発Bは同じ期間で複数回検査と適応のループを回しています。これにより、ユーザーからの要望やニーズを短い期間で取り込むことができ、ユーザーが本当に求めていた価値に近づくことができます。つまり、アジリティの高いプロダクト開発は、プロダクトの本質的な価値に迅速に辿り着くことができます。さらには、ユーザーの要望の変化にも素早く適応できます。
サントリーウエルネスおよびComadoチームはアジリティ向上を目指しています。理由は2点あります。
- 弊社が他社にない新たなウエルネス体験を提供しているため
- 弊社は、従来の健康食品だけを売るビジネスから脱却し、顧客接点を増やしLTVを最大化するためにDXを積極的に進めています。特にComadoは、新しいウエルネス体験を提供するプラットフォームとして位置づけられており、ユーザーのニーズに迅速に対応することを目指しています
- 健康行動アプリは多くの企業や個人がリリースしているため
- Comadoは健康行動アプリに分類されますが、多くの企業や個人デベロッパーが健康行動アプリをリリースしています。経済産業省の調査によると、ヘルスケア関連のアプリ・サービスの市場規模は2021年に248億円、2025年には887億円に達すると予測されています。1
アジリティ向上を実現する要素
アジリティ向上を実現するために必要な要素は以下だと私は考えています。
- アジャイル開発
- Scrum、XP、Leanといったアジャイル開発の方法論は、短いイテレーションを通じて迅速に変更に対応できます。これにより、アプリケーションがユーザーのフィードバックやビジネスの変化にすばやく適応できます。
- DevOps
- 開発と運用を統合して、アプリケーションのデリバリープロセスを自動化することで、変更を素早くリリースできるようになります。特に、Four Keysの改善、27のケイパビリティ(2024年5月現在)の獲得により、素早くデリバリーできるようになります。
- 変更容易性の向上
- アーキテクチャに従って責務が正しく分離されたソースコードは、変更箇所を素早く特定できます。また、変更容易性が高いソースコードは、技術的負債を貯めにくく、本来やるべき実装にフォーカスできるようになります。
- マインドセット
- 上記のプロセスを形式的に導入するだけでは、アジリティ向上は実現できないです。柔軟性、適応性、目的志向、チーム学習、継続的なカイゼン、自己組織化を通じて、チームが変化に素早く適応していくためのマインドセットを持つことが必要十分条件だと思います。
上記をまとめると以下の関係性になります。
私はアジリティの向上を目指して、小さい範囲でできるところから実施しました。
カイゼン活動
「アジリティ向上を実現する要素」を軸に行ったカイゼン活動について紹介します。
ちなみに、改善をカタカナ表記しているのは、Leanやアジャイルに深く影響を与えたTPS(トヨタ生産方式)での用語である「カイゼン」からきています。
アジャイル開発
本プロジェクトでは、スクラム開発を採用している体でしたが、実質一定のタイムボックスに区切ったウォーターフォール開発の状態になっていました。関連するチームやステークホルダーも非常に多いため、この開発プロセスを一気に変更し、真のアジャイル開発を導入するのは困難です。
そのため、開発全体のプロセスやルールは守りつつ、アジャイル開発、とりわけスクラム開発のエッセンスをチームに導入することから始めていきました。
スクラム開発は「経験主義」「リーン思考」に基づいたアジャイル開発のフレームワークで、以下の三本柱の考え方に支えられています(スクラムガイド2020から抜粋/改変)。
- 透明性
- 創発的なプロセスや作業は、作業する人とその作業を受け取る人に見える必要があること。
- 検査
- スクラムの作成物、プロセス、ゴールに向けた進捗状況は、頻繁に検査する必要があること。
- 適応
- 成果物が受け入れられなかった場合は、適用しているプロセスや製造している構成要素を検査し適応する必要があること。
この三本柱に基づいてカイゼンを行いました。
作業の透明性の確保
私がジョインする前は、チームのタスクや課題が以下の場所に散らばっていました。
- Jiraの複数のプロジェクト
- Confluenceの議事録のメモ
- Slackの会話
これにより、いくつか問題が発生していました。
- 各タスクのステータスが不明
- 担当者不在のタスクが存在しタスクのフローが滞っている
- 各メンバーが何をやっているのかわからない
これに対するアプローチはシンプルで、チーム専用のJiraプロジェクトを作成し、そこに全てのタスクを集約、担当者を明確にすることでした。
チーム専用のJiraプロジェクトにより、チームの状況、各タスクのステータス、各メンバーの稼働状況が一目でわかるようになりました。これでチームが行うべきタスクをコントロールできるようになりました。
チーム活動の検査・適応
「経験主義」を体現するためには、チーム活動の検査・適応が必要だと考えています。この具体的なアクションが「ふりかえり」です。
私がチームにジョインする前もふりかえりは実施されていましたが、運用上以下のような問題点がありました。
- 実施頻度が1ヶ月に1回
- カイゼンの機会が1ヶ月に1回しかない
- ふりかえりで出たアクションを振り返っていない
- 「適応」した結果を「検査」しておらず、アクションが本来の目的を失い形骸化している
- ふりかえりでメンバーの対話や議論が生まれていない
上記の課題に対するアプローチも極めてシンプルで、1週間に1回ふりかえりを実施することにしました。また、前週のふりかえりで出たアクションや、新しく始めた取り組みを中心にふりかえることで、プロセスの検査適応のループを回すようにしました。
この取り組みを始めてからは、1週間ごとに、平均しておよそ3件ほどのカイゼンを実施しています。チームにカイゼンの文化が芽生え始めています。
ふりかえり中は、可能な限りメンバーの発言を促して、議論や対話を生み出しています。また、Slackのスレッドで、メンバー同士が気軽に対話しています。
DevOps
自動テストの実装
私がジョインした当初、プロダクションコードの実装が優先され、自動テストのテストコードが実装されいませんでした。品質の担保は、実装担当者やQA担当者が手動で確認していました。
この背景としては、アプリケーションが最初に実装された当初、リリースの納期が最優先事項とされていたため、プロダクションコードの実装が優先されていたためです。その後のエンハンスや変更についても、その時の実装方針がそのまま受け継がれる形になっておりテストコードが実装されていませんでした。
現在のフェーズは既存機能のエンハンス、変更が開発の中心になっています。開発者が安全にプロダクションコードを変更するためには、他のコードのふるまいを変えていないか担保する必要があると思います。
そのためには、自動テストは必須だと考えています。そこで、プロダクションコードとテストコードをセットで実装する方針にしました。
ただ、闇雲にテストを書くとメンテナンス性が低いテスト、意味のないテストが次々と生み出され、かえってテストが負債になります。そこで、以下の項目をまとめて、テストを実装する開発者に共有しました。
- テストを書く目的
- 自動テストはカバレッジを担保する目的ではない。プロダクションコードにフィードバックしコードの品質を高めることや、振る舞いを担保することで自信を持ってリファクタリングすることが目的である
- テスタビリティを向上させるアーキテクチャ
- 疎結合、高凝集
- インターフェース分離
- テストのテクニック
- Test Double
- AAAパターンなど
- テストのアンチパターン
- Software Unit Test Smells
- テストファーストな開発
- いきなりTDDは難しいと思うので、テストとプロダクションコードの距離を近づけるように意識すること
CI/CDの導入
CI/CDの導入は開発メンバー中心にカイゼンしました。
自動テストの件数が増えてくると、継続的インテグレーションのプロセスでテストを回したくなると思います。そこで、Pull Requestごとに自動テストを実行して後にビルドするパイプラインを構築しました。
また、モバイルアプリはアプリケーションをストアにリリースするまでに多くの手順を実施する必要があります。その手順の中で自動化可能な手順をパイプラインとして切り出して、リリースの効率化を図りました。
変更容易性の向上
私がジョインする前から、Clean Architectureの考え方をベースにしたMVVM Architectureの導入を進めていました。詳しくは思い切ってNativeアプリのリファクタリングを実施してみたをご参照ください。
マインドセット
こちらについては長くなるので別の記事でご紹介させていただきます。
意識したこと
メンバーの意見には常に耳を傾けること
カイゼンを持続可能なものにするためには、メンバーや開発チームが望んでいるカイゼンに取り組むことが重要だと思います。メンバーが納得感を持たないカイゼンは、単に私のエゴにしかならなず、ハレーションを産んでカイゼンすること自体が倦厭されるようになると思います。
したがって、メンバー全員との定期的な1on1やふりかえりを通じて、モチベーション、理想の開発体験、チーム活動の感想など様々な観点の意見をいただきました。 その意見を参考に、カイゼンの方針を決めていきました。
小さな変化を繰り返すこと
私はXPが非常に好きです。人を中心とした開発手法の考え方が自分に合っています。
XPの原則の中に、ベイビーステップ というものがあります。大きな変化は効果が大きいですが、失敗した時のリスクも大きいです。バッチサイズを小さくすることで、リスクを抑えながら進めることができます。
カイゼン活動も同じだと思います。大きいカイゼンは失敗のリスクがあります。小さな成功体験を積み重ねていき、チームが自信を持ちながらカイゼンの範囲を着実に広げていくのが大事だと思っています。
心理的安全性を保つこと
カイゼンは、ある種不確実なものに対しての挑戦であると思います。挑戦には失敗がつきものです。失敗を恐れていてはカイゼンは進みません。したがって、失敗しても誰も責めないようにチームで合意して、心理的安全性を高めるようにしていきました。
「守・破・離」の守を意識すること
プロジェクト全体で新しいプロセスが開始されている状態でした。まずはそのプロセスをちゃんと回せるようにしました。新しいプロセスをうまく回せるようになった上で、チームの中で小さな変化をもたらし、その変化に効果があれば範囲を広げていくことを意識しました。
反省
カイゼン活動を実施していく中でいくつか反省点もあります。
効果を評価できていない(数値でファクトを語ることができていない)
目の前の課題に対して定性的に評価し、効果が大きそうなものから着手しています。しかし、その課題が本当に課題なのか、定量的に評価できていません。したがって、効果も定量評価できていません。今後はモニタリングできる指標を用いて、カイゼンの効果を可視化したいと思っています。
開発チーム内の個別最適となっている
ネイティブアプリチームの中でのカイゼンに注力していますが、これはあくまでプロダクトのライフサイクルの局所的な範囲での部分最適となっています。目指すべき姿は、開発のアジリティを向上させるだけではなく、プロダクトのアジリティを向上させてユーザーに価値を提供できる状態になることです。今後はプロダクトのバリューストリームの全体最適にも挑戦していきたいと思っています。
正直なところカイゼン活動は発展途上です。まだまだやらなければいけないことはたくさんあります。上記の反省点を踏まえて今後も頑張りたいと思います。
最後に
メンバーの多大なる協力の甲斐もあり、カイゼンの輪が回りはじめ、アジリティ向上のスタートラインに立てたと思います。メンバーのみなさまにはこの場を借りてお礼申し上げます。
弊社では、ユーザーのウエルネス実感向上に貢献するため、エンジニアの募集をしています。本記事にも書きました通り、裁量を与えられて色々なことにチャレンジできる環境があります。興味がある方はぜひカジュアル面談をできればと思います。
最後までお読みいただきありがとうございました。