お出かけアプリ「Prism Japan」の開発をウォーターフォールからアジャイルに変えるためにやったこと

再生速度

要約を読む

開発チームの連携が不十分で、フロントとバックエンドが情報共有できず、意見のすり合わせが行われなかったことが課題でした。そこで、スクラムというアジャイル手法を導入し、チーム全体で開発プロセスを共有できる仕組みを作りました。その結果、チーム間の連携が改善され、開発の進み方がスムーズになり、手戻りが30％減りました。スクラムを始める前に、全メンバーでスクラムの基礎を勉強しました。これにより、誰もが同じ前提で開発を進めることができ、チームの理解が一致しました。その後、2週間のスプリントを設定し、プロダクトオーナーがストーリーを作成し、毎日15分のデイリースクラムを開始しました。このイベントを通じて、メンバーがお互いの進捗を把握できるようになりました。スクラムの実施を通じて、メンバーが仕様について気軽に話すようになり、アプリの機能に対する意見交換が活発になりました。特に、スクラムマスターが中心となってイベントを回すのではなく、メンバー全員がスクラムを支えるようになってきました。最初の2ヶ月で、スクラムが自然に回るようになったと感じています。プロダクトオーナーがユーザーの課題を再定義し、データをもとに意思決定を進めました。ジョブ理論を使ったワークショップで、アプリがユーザーに提供すべき価値を明確にしました。また、ユーザーログの分析を実施し、実際にユーザーが使っている行動を確認することで、開発の方向性を確実に決められました。開発の途中で、プロダクトオーナーとエンジニアの「やりたいこと」が合っていなかった問題がありました。これを解決するために、スプリントリファインメントとスプリントプランニングを活用しました。リファインメントでは、要件の合意と見積もりを明確にし、プランニングでは達成可能なゴールを決めました。これにより、エンジニアが自らの作業に責任を持ち、提案もできるようになりました。導入後、フロントとバックエンドの連携が改善され、開発の手順がスムーズになりました。チーム全体で議論が深まり、アーキテクチャレベルの話題も議論できるようになりました。また、作業依頼ではなく、ユーザーストーリーに基づいた開発が進み、メンバーの主体性が高まりました。結果として、開発メンバーが成長し、アプリの品質も向上しています。

AI が生成した要約です。正確な内容は本文をご確認ください。

KINTOテクノロジーズのソフトウェアエンジニアの五条です。
『Prism Japan』という、AIがお出かけ先を提案してくれるモバイルアプリのバックエンドを開発しています。
今回は、Prism Japan のプロダクトオーナーをしている 齋藤と共著で、比較的規模の大きいアジャイルチームで、どのように Prism Japan を改善していったのかを紹介します。
 Prism Japan とははじめに、私達が開発している Prism Japan について、簡単に紹介させてください。
Prism Japan は一言でいうと、「AIがお出かけ先を提案してくれるアプリ」です。
「休日にお出かけしたいけど、どこに出かけようか決まってない…」
そんなときに Prism Japan が使えます。
たとえば「気分で検索」機能では、好みの写真を選ぶだけで、ユーザーにおすすめな旅行スポットを提案します。
ユーザーは写真を眺めながら、気分に合った旅行スポットを探すことができます。
2022年8月にiOSアプリをリリースし、Android版は2023年4月にリリースしました。

2023年10月末現在で累計の会員登録数は3万人を超えています。
 Prism Japan の開発体制Prism Japan は iOS と Android で利用できます。モバイルアプリを開発するチームは、
iOS 開発チーム
Android 開発チーム
で分かれています。
バックエンドは
API 開発チーム
AI 開発チーム
で分かれています。それぞれの分野の専門性を持つメンバーが開発を担当します。
開発チーム以外にも企画・分析・デザインを担当するチームがあります。
プロジェクト全体の方向性を決めて、ユーザーの必要とするであろう機能を考えているのがプロダクトオーナーです。
Prism を主担当としているメンバーで 15人、サブ業務として開発に関わっているメンバーを含めると 20 人となります。
アジャイルチームとしては比較的大所帯と言えるかもしれません。
 アジャイル開発を軌道に乗せるためにやったことPrism Japan 開発チームは、現在はひとつのチームで開発していますが、以前はフロントエンドとバックエンドチームで別チームとして開発を進めていました。
チーム間の作業調整が必要なときは、Slack のチャンネル内でお互いに作業を依頼していました。

作業を依頼したあとは、各々のチームに完全に任せる形です。
組織上、所属部署が分かれていることが分業の背景にありましたが、チームの運営において以下のような課題がありました。
フロントエンド⇔バックエンド間で開発過程を共有しないため、チーム間で意見のすり合わせが行われない
フロントエンド⇔バックエンドをまたいだチーム全体の改善が生まれない
作業の依頼ベースで開発が進むため、プロジェクトマネージャーと遠いメンバーはオーナーシップを持ちにくい
Prism Japanの初期開発が一段落した段階で、アプリの改善フェーズに適した開発方法に切り替えるべきという議論が始まりました。
上記の課題に対処できる開発方法を検討する中で、ユーザーの反応を見ながら柔軟に仕様変更を行うことができ、モバイルアプリとの相性がよい「アジャイル開発」に切り替えるという点は早々に決まりました。
中でもチーム内でも有識者がいて、課題であったコミュニケーション面でのメリットも大きい「スクラム」を手法として採用することになりました。
 ゼロからスクラムを立ち上げる手順チームメンバー全員がスクラムを経験してきたわけではありません。そのため、スクラムとはどのようなものかをチームメンバー間で共有する必要がありました。
スクラムマスターとなった小山が講師となり、チームでスクラムを学ぶところから始まりました。
詳細は下記の小山の記事を参考にしてください。
iOSエンジニアが認定スクラムマスター研修を受けてスクラムマスターをやってみた話
 先ず（勉強）会より始めよ「これからはスクラムで開発していきたい」というときに、まずはスクラムについての勉強会から始めるのは非常に有用だったと感じています。
チームメンバー全員に前提となる基礎知識を共有した上で、「これからスクラムを始めるぞ」と意識付けができたからです。
 スクラムイベントを設定する勉強会の次の週から、スクラムイベントを設定しました。最初は手探りだったので、スクラムマスターとプロダクトオーナーが中心となって、それぞれのイベントで何をやるかを話し合いました。
はじめに行ったのは以下のような作業です。
2週間のスプリントを設定する
プロダクトオーナーがストーリーを作成する
毎日15分のデイリースクラムを始める
スプリントプランニングを設定する
スプリントレビューを設定する
スプリントレトロスペクティブを設定する
スクラムマスターが主導して、まずイベントを設定して走り出しました。
この記事ではスクラムイベントの詳細については触れませんが、
スクラムマスターが主導してイベントを設定する
スクラムマスターとプロダクトオーナーが密に連携して、イベントを動かす
といった具体的なアクションを起こすことで、スクラムが動き出した感覚があります。
特にスクラム開始時点の手探り状態では、チームを動かしていくスクラムマスターの情熱と、やりながら改善していく姿勢が非常に重要だと思います。
 チームビルディングスクラム開発を通じて感じたのは、チームが育つ感覚です。
特に、次のような点でスクラムの成長を感じています。
仕様についての議論が気軽に行えるようになった
アプリの機能に対するメンバーの意見交換が活発になった
スクラムマスターだけに頼ることなく、スクラムを回せるようになった
どの組織でも同様かと思いますが、最初からスクラムがうまく回っていたわけではありません。
スクラムでチームを組み始めて最初の1ヶ月は、プロダクトオーナーの齋藤とスクラムマスターの小山が中心となって、常に「チームを良くする方法」を探っていました。

スクラムが淀みなく回るようになるまで、だいたい2ヶ月を要しました。
 プロダクトオーナーの役割と悩み一般的なスクラム開発におけるプロダクトオーナーの役割は開発要件をプロダクトバックログという形で管理し、開発の方向性を定めることでプロダクトの価値を最大化することです。
Prism Japanにおいてもこの点はもちろん最重要ではありますが、『プロダクトの価値の最大化』のために意思決定を行うことは簡単ではなく、当初は自分の決定が正しいのか、本当にユーザーに必要な機能なのかと、悩みは尽きませんでした。
悩みを解決するために２つのことを実行し、今では確かな判断基準をもって意思決定できるようになりました。
 やったこと①：Prism Japanが解決するユーザー課題を再定義ジョブ理論のフレームワークを元にしたワークショップをスクラムメンバー全員で実施しました。
理論についての細かい説明は割愛しますが、これによりPrism Japanがどのような価値をユーザーに提供するアプリであり続けるべきなのかという根幹となる部分を定義することができました。
 やったこと②：データドリブンな意思決定の導入プロダクトオーナー自身がデータエンジニア・データアナリストとしての経験を持つことから、ユーザーログの設計やアプリ利用状況の可視化、課題仮説を元にした分析などを積極的に行っています。
これにより、既存のアプリにおける課題、リリースした機能がユーザーに受け入れられているかなどを確かめつつ、開発方針に落とし込めるようになりました。
 スクラムで発生した課題と解決するためにやったこと最後に、スクラムで開発を進める中で発生した課題と、それを解決するために私達が何をしてきたかを紹介します。
 [課題]プロダクトオーナーとエンジニアで「やりたいこと」の認識が合っていなかったスクラムでの開発を始めた当初は要件や仕様を正確に適切なタイミングで伝えることに苦労しました。

そもそも開発着手まで具体的な仕様が決まっていなかったり、口頭でのすり合わせに頼ってしまい、メンバー毎の認識に違いがあったりと原因は様々でした。
 [解決方法]スプリントリファインメント、スプリントプランニングの活用関係の良いスクラムでも礼儀は必要です。

依頼の仕方やタイミングがスクラムイベントにきちんと組み込まれたことは非常に効果がありました。
 スプリントリファインメント次回スプリントが開始になる前の週に実施されます。
プロダクトオーナーがユーザーストーリーについて説明を行い、要件の合意と簡易的な見積もりを行います。

プロダクトオーナーはこの日までに次回スプリントで対応したいユーザーストーリーを確定しておく必要があります。
 スプリントプランニングユーザーストーリーやタスクの優先度を決めた上で、スプリントで達成するゴールを合意します。
過去の実績と照らし合わせて実現可能な作業内容であることも確認するので、エンジニアがスプリント内で実施する内容に責任と自信を持つことができます。
 アジャイルスクラムを導入した効果導入当初の細かな課題はあったものの、以前の開発方法における課題に対してはどのような成果があったかを振り返ってみたいと思います。
フロントエンド⇔バックエンド間で開発過程を共有しないため、チーム間で意見のすり合わせが行われない
デイリースクラムで双方が取り組んでいる内容が把握できるようになったという効果がありました。
その他にもリファインメントやプランニングといったイベントではバックエンドの実装方針に対して、フロントエンド側の要望を元にした議論も活発に行われるようになり、開発をスムーズに開始できたり、細かい手戻りなども大幅に減らすことができました。
フロントエンド⇔バックエンドをまたいだチーム全体の改善が生まれない
エンジニアがアプリをよりよいものにしたいという主体性・責任感をもって議論に参加するようになったため議論のレベルも以前より数段上のものになったと感じています。
パフォーマンスや今後の拡張性などを意識したアーキテクチャレベルでの議論も行われるようになり、チームが分かれていては議論にすらならなかった内容が、きちんとまとまるようになりました。
作業の依頼ベースで開発が進むため、プロジェクトマネージャーと遠いメンバーはオーナーシップを持ちにくい
作業依頼ではなく、あくまでも依頼するのはユーザーストーリーの実現となったため、エンジニアがそれぞれ実現のための最適な方法を考え、ときには提案まで行うようになっています。

開発自体の改善もそうですが、スプリントをこなすごとに多くのメンバーが成長し続けられていることも実感できています。
 最後に開発メンバーと企画・運用メンバーが共通の目的を持ち二人三脚で改善を進めているという点は特徴的かと思いますが、アジャイルスクラムでの開発を進めている方・これから始めようという方のご参考になれば幸いです！
また「Prism Japan」はリリースから1年少し経過したばかりでアプリもメンバーも絶賛成長中です。

こんな体制で開発されたアプリがどのような成長を遂げていくも是非体感してみてください！
 Prism Japan を触ってみたい方へPrism Japan は下記のリンクからインストールできます。
iOS: App Store
Android: Google Play