はじめまして。ロコガイドに去年の11月中旬にジョインした松田と申します。ロコガイドではiOSアプリエンジニアとしてトクバイアプリの開発に携わっています。
この記事ではトクバイアプリ開発でのチーム開発の紹介と入社して3ヶ月が経過した私の感じたことをご紹介できればと思います。
私の経歴
まず始めに私の経歴を簡単に説明しますと、SIerでの大企業向けの汎用機システム開発やWebサービスのサーバサイドの開発、そしてiOSアプリの受託開発に長く携わってきました。開発手法としては、主にウォータフォール型の開発やチケット駆動のアジャイル開発を経験してきました。今回のメイントピックであり、スクラム開発に代表される「チーム開発」というものは前職で多少経験した程度になります。
開発フロー
トクバイアプリは2週間に1回の定期リリース制を導入しており、1スプリント2週間のスクラムで開発しています。
開発フローは一般的なスクラムに則った、プランニング〜開発〜レビュー〜レトロスペクティブという流れになっています。上図では「おさわり会」が「レビュー」に、「振り返り」が「レトロスペクティブ」に該当するものになります。
そして2週目の水曜にあるコードフリーズまでを案件開発として、残りはQAやバグ対応をメインに、次スプリントに行う案件の事前調査、さらにはCI/CD整備やアプリ全般の改善対応などをしています。
なお図に記載されている各イベントは私のカレンダーに登録されているものをそのまま記載したものになりますが、例えば「おさわり会」など独特な名前のイベントが、この図にあるもの以外にもロコガイドには数多くあります。入社した当初はカレンダー登録の案内を見て「何のイベントだろう？」と戸惑ったこともありましたが、今はこういった名前の付け方にこの会社の雰囲気がよく表れているなと感じています。
さて話が脱線しましたが、次からこれらのイベントの中からいくつかをピックアップしてご紹介します。
warm up & スプリントプランニング
スプリントプランニングとは「スクラムガイド2020」*1に説明があるように、スプリントを開始するに当たってプロダクトバックログから今スプリントで作業するバックログアイテムを抽出し、見積もりを行い作業計画を立てるイベントになります。
前職ではこのプランニングにかなりの時間が掛かっていました。
というのも、プランニング時に初めてプロダクトオーナーから今スプリントで作業する各バックログアイテム（案件）の概要の説明があり、その説明をもとに開発者は見積もりをしていました。そのため案件内容によってはその場で一度コードを確認してからポイント出しをすることになり、時間を多く掛けてしまうことになっていました。
トクバイアプリ開発では、プランニングの前の週に「warm up」というイベントが設けられています。ここでは、次スプリントで作業すべきバックログアイテムの予告および概要が知らされます。つまり前もって対応範囲を確認しておくことができますし、事前準備をしておくことができるわけです。それによりプランニング時に余分な時間を取られることもなくなり、見積もりにおいてもある程度目処をつけた状態で見積もることができます。
このように「warm up」というインベントは、スプリントプランニングの補助的な役割として、効率的なプランニングのためのとても有効な方法だと思いました。
おさわり会
先程少し触れた「おさわり会」ですが、「どんなイベントだろう？」と思われた方もいるかもしれません。私がトクバイアプリの開発に参加して一番特徴的だと感じたのがこの「おさわり会」というイベントでした。そこでこの会について詳しくご説明します。
このイベントはスクラムイベントにおけるスプリントレビューに「近しいもの」になります。
スプリントレビューについて「スクラムガイド2020」では、
スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする。
とあります。
したがって多くの現場ではスプリントでの進捗確認や開発されたプロダクト、追加された機能が要件や仕様を満たしているかの確認の場であることが多いのではないでしょうか？
「おさわり会」もスプリントで追加された機能の他のメンバーへの共有とレビューの場になるので基本は同じです。
ただし、「おさわり会」での主要な目的はユーザー体験やユーザー価値を最大化できているか、ロコガイドのバリューの1つである「ユーザーファースト」になっているかを確認することになります。
具体的なやり方としては参加メンバーに実際にアプリを触ってもらって意見をもらいます。その際、いちユーザーとして先入観なく意見を挙げてもらいたいので、細かい仕様の説明はせず簡単な機能の説明と確認方法、例えばその機能の表示の仕方といったものだけに絞って説明します。このようにあくまでユーザー目線で触ってもらえるように気をつけています。そしてトクバイアプリにはHuruhuruというレポーティングライブラリが導入されていますので、手軽にとにかく気になったことはなんでもチケットに起票してもらいます。
その後の流れとしては、起票されたチケット（「いい！」といったお褒めのチケットもあります！）についての説明、それに対する改善案についてこちらもラフに意見を挙げてもらいます。必要であればその機能のPJ責任者を交えて、ここからはユーザー体験だけではなく要件まで踏み込んでより詳細な対応可否、対応方法、対応時期について話し合いが行われてリリースへと向かいます。
以上が「おさわり会」の流れになります。
この「おさわり会」に参加してみると、ロコガイドという会社がユーザー体験やユーザファーストについてかなり重要視していることを肌で感じることができます。
例えばラベルの文言1つをとっても、その言葉がユーザーの頭にスッと入る表現になっているかをワイワイ話し合うこともあります。さらには要件を満たしていたとしてもユーザー操作の邪魔になっていないか、といった内容の議論が毎回熱く交わされます。
このように「おさわり会」は、これまでエンジニアとして仕様を満たすものを実装したことで満足していた私にとって、大変刺激を受ける場となっています。
振り返り（レトロスペクティブ）
前掲した図の「振り返り」はレトロスペクティブイベントを表しており、多くの現場と同様に「KPT法」を用いて振り返りを行っています。
特段一般的な振り返りと変わったことはありません。
それでも私が特徴的だと感じたのは、私が所属しているモバイルチームなどの職種毎のチームや各プロジェクト毎に定期、不定期問わず「振り返り」が数多く行われていることです。
トクバイアプリの開発ではプロジェクト進行中に少しでも課題として感じたことや気付きがあったことについて、随時タイミングを見て「振り返り」を行っています。
このように、どんな些細な問題もなあなあにして持ち越すことなく、常に課題解決や改善に取り組みながらPDCAを高速に回す習慣がメンバー全員の共通認識としてあることを感じられるイベントになっています。
実際にこのことを特に感じられたのが前述した「おさわり会」でした。
私が入社した当初、「おさわり会」は進め方があいまいで時間が多く掛かってしまっている、新しく参加した人が何をすればいいのかわからない、ユーザー体験を最大化するのが目的にもかかわらずそもそもの仕様についての議論が始まってしまう（これらの議論は有益ですがあくまでユーザー目線での確認であること、話が拡散してしまい時間が足りなくなるといった点などで）といった課題がありました。しかし私達モバイルチームとディレクターで振り返りをしながら、この会の目的を明確化かつ体系化していくことで、現在は当初の目的を果たせる場へと改善しています。
その他全体を通して
チーム開発全体という観点で見てみると、前職では各チームがそれぞれ独立しており、チームごとに開発の進め方が異なっていたため、スプリントサイクルも統一されておらず各チームがそれぞれ自分たちのスケジュールに沿ってプロジェクトを進めていく状況でした。したがって、突然「xxまでにこの対応をお願いします」といった割り込みが発生することも多々ありました。
しかしトクバイアプリの開発では、ディレクターやデザイナー、エンジニアが同じスプリントでお互いの状況を把握、確認しながら同じゴールを目指してプロジェクトを進めているため、変な軋轢が生まれることもなく、安心かつ集中して作業に取り組むことができていると感じています。
一方、課題だと感じたものはQA周りでした。この前の記事できしけんさんが1人目のQAエンジニアとしての記事を書いてくれていますが、私が入社した時点ではQAエンジニアが不在であり、またQAのやり方もテスト仕様書があるわけでもなく機能実装者がなんとなく触って確認するような感じでした（ただしQAの整備に向けて既に動き出してはおり、一部のプロジェクトではテスト仕様書を作ってテストしていたようでした）。
しかしこれに関しては、きしけんさんによりまずはリグレッションテストが急ピッチで整備されてきており、前掲した図にある通り開発フローの一部に組み込まれています。そしてQAエンジニアとモバイルエンジニア、ディレクターでテスト項目書をひととおり通すなど体系化されてきています。
なお、先日は私がこのリグレッションテストを通してバグを発見して対応するなど、早くも成果が出ました。
今後は新規機能のQAについて、より早い段階から開発エンジニアとQAエンジニアでテスト計画や検証観点の洗い出しなど連携を取りながら、実装〜検証〜フィードバックを早く回せるフローを作っていければと思っています。
また、もう1つ課題を挙げるならば、振り返りの項で書いたようにコミュニケーションが活発な分、会議体が多いことです。私も入社して数ヶ月はチームの、プロジェクトの、入社研修のといったミーティングが次々と入り作業時間の確保に苦戦しました。これをチームのKPTでプロブレムとして挙げたところチームメンバーからも同意を得、開発チーム全体の「振り返り」の場で共有してもらいました。このように入社後の数ヶ月だけでも既に2回、ミーティングの見直しややり方についての改善が検討されています。
このように少しでも課題として声を挙げるとチームやプロジェクト内でキャッチアップしてくれて、さらに全体で話し合って解決に導いてもらえるので心理的安全性の高い環境だと感じています。
まとめ
以上、トクバイアプリのチーム開発について入社して3ヶ月の私が感じたことを紹介してきました。
ロコガイドは、特にアプリやサービスといったプロダクトについては「ユーザーファースト」が、プロジェクトや業務においては振り返りによる高速なプロセス改善や課題解決が強みだと感じています。
また今回ご紹介しきれませんでしたが、施策結果を共有する会、チームやプロジェクトを超えた振り返り共有会といったものもあります。このように各チーム、メンバー皆が同じ目標、同じゴールを目指している一体感、まさに「スクラム」を組んでいるようなチーム開発だと感じました。
もしこのようなチーム開発に参加してみたいと思われる方はぜひご応募ください。
