はじめに
駅メモ！開発チームの id:kaidan388 です。 昨年の6月に新機能として「アルバム機能」をリリースしました。私はこの開発でリーダーを務めました。
このアルバム機能は、駅メモ！の中でも特に規模の大きな開発となりました。また、これまでの新機能がバトル面の強化やチェックイン・アクセスのしやすさが中心で、ライフログを強化する試みはあまり例がなかったため、「本当にユーザーの皆様に楽しんでいただけるだろうか」という懸念も当初はありました。
今回は、この大規模かつ前例のない開発を無事にリリースまで進めるために、チームで試みた2つの工夫について、そのメリットとデメリットを交えてご紹介します。
アルバム機能について
駅メモ！は、おかげさまで11周年を迎えることができました。これを「20年続くゲーム」にしていくために、ゲームを継続して遊ぶこと自体が楽しさにつながる機能を、より増やしていきたいと考えました。
駅メモ！には、ユーザーの皆様の「おでかけの記録」を残すライフログという側面があります。 しかし、これまでの新機能はバトル面の強化や、駅の回収（アクセス）をしやすくする強化が中心で、このライフログという側面に関わる機能強化は比較的少ない状態でした。
そこで今回、ライフログ機能の強化を行うことになりました。
様々な軸が考えられましたが、まずは情報量が多く、ユーザー様が後から振り返る価値を感じやすい「写真」や「画像データ」の素材としての価値に着目し、それらを記録として残す機能の開発を進めることにしました。 また合わせて、以前からユーザー様からのご要望も多かった「過去の移動ログを残し、いつでも見返せる機能」も追加しました。移動の記録と写真を同時に見ることで、お出かけの思い出としてよりリッチに記録できる仕組みを目指しました。
工夫1：大規模ドッグフーディングの実施
前例のない機能だったため、開発の初期段階から「まずは社員で集中的に遊んでみて、そのフィードバックを元に仕様を変更していく」という方針を前提に進めました。
もちろん、駅メモ！では普段からリリース前に開発したものを社員で動作確認しています。 しかし今回はその規模を拡大し、駅メモ！開発チーム外からも、普段から駅メモ！で遊んでいる社員に参加を呼びかけました。最終的に、普段の動作確認の4~5倍の人数の協力を得ることができました。
この取り組みでわかった、良かった点と難しかった点をご紹介します。
良かった点
1. クオリティの向上
最大のメリットは、やはりクオリティの向上です。 人数が多いだけでなく、駅メモ！の熟練者から、チーム外のライトユーザーまで、多様な視点からの意見が数多く集まりました。これらの意見を集約することで、UI/UXをどのように変更すべきかが明確になりました。
例えば、ドッグフーディング中に参加者から「本当にただ写真を記録するための道具になってしまっていて、ゲームらしい『楽しい』という感情が湧きづらい」という指摘がありました。
このフィードバックを受け、急遽、画像を投稿する際に以下のようなミニでんこ画像を表示する仕様を追加しました。 かわいいでんこの画像を追加することで、シンプルに画面を華やかにしたり、でんこと一緒に記録して旅をしている感覚を高めたりする効果を狙っています。
この追加によってユーザー様の感情にどういった変化が生まれるかを定量的に計測するのは難しいですが、追加後の開発メンバーやドッグフーディング参加者の反応を見る限り、非常に好評でした。
2. 最適な画質の模索
画質についても、シビアな調整が必要でした。 画質を良くしすぎると画像1枚あたりの容量が嵩み、特にサーバーからの配信コストが非常に高くなってしまいます。かといって、画質が低すぎると「画像を記録する」という体験そのものの価値を損ねてしまいます。
ドッグフーディングを何度も行い、参加者から画質についての具体的なフィードバックを受けることで、コストと体験のバランスを見極め、細かく調整することができました。
難しかった点
1. 工数の予想が難しくなる
フィードバックに応じて仕様を変更すると、当然工数も増えます。 後から工数が増えることで、開発の完了時期の予想が難しくなってしまいました。
対応策としてアルバム開発では、以下のようにチケット状況をグラフにして可視化し、期限までに完了できるかに注視しつつリソースの調整などを行いました。 傾きが急になっている箇所は、まさにドッグフーディングの結果を受け工数の見積もりが増加したタイミングです。
2. コードの整合成が取れない
フィードバックに応じて仕様が変更されることで、開発初期に書いたコードと整合成が取れなくなり、結果定期的にリファクタが必要になりました。 これも工数を増やすことにつながります。
3. 環境準備のコスト
そもそも、「本番のアプリで、一部の社員だけがアルバム機能（開発中のもの）を遊べるようにする」という環境を準備する作業自体にも、相応の時間がかかります。
今回は、２種類のビルド成果物を用意しておき、ユーザによってアルバム機能を含むビルド成果物と含まないビルド成果物を出しわける、という方法を取りました。 目的は達成されますが、２回ビルドが必要になるのであらゆる場面で時間がかかってしまい、コストが増えてしまいます。
まとめ
クオリティが確実に上がるという大きなメリットがある反面、その分エンジニアの対応負荷が高くなるトレードオフの関係にあります。 何にでもこの規模のドッグフーディングを行うのはコストパフォーマンスが悪いと感じたため、プロジェクトの重要度や特性に応じて実施を判断すべきだと感じました。
工夫2：アジャイル的な週次動作確認
駅メモ！では通常、ある程度仕様やデザインが固まってから開発（実装）を開始する、ウォーターフォール型に近い進め方を取ることが多いです。
しかし今回は、
- プロジェクト全体の規模が非常に大きい
- 前述のドッグフーディングの結果、仕様変更が予想される
という理由から、従来のように「ある程度の要件が固まるのを待ってから開発する」という進め方ができませんでした。
そこで今回は、要件が固まりきるのを待たず、すでにある程度仕様が確定している画面から順番に開発を着手していきました。 特にドッグフーディングの実施日がマイルストーンとなるため、そこまでにコア機能（最低限、画像がアップロードできる部分など）を完成させる必要がありました。細かいデザイン調整は後回しにして、まずは動くものを優先する、といった判断も行いました。
感覚としては、「いつもの半分の開発工数で、7割くらいの完成度のものを作る」ことを求められるような状況でした。
また、開発と並行して、週に1〜2回のペースで、そこまでの開発進捗についてアルバム機能開発チーム内で動作確認会を行いました。 結果として、「1週間単位で計画立て→開発→動作確認→次の計画立て」という、アジャイル開発に近い体制を取ることになりました。
この方針にも、当然ながら良い点と悪い点がありました。
メリット
1. バグの徹底的な洗い出し
まめに動作確認を繰り返すため、バグを早期に、かつ徹底的に潰すことができます。 実際、今回のアルバム機能は規模が大きかったにも関わらず、リリース時に機能起因の不具合は1件も発生しませんでした。これは大きな成果だと感じています。
2. 段階的なクオリティアップ
大規模なドッグフーディングにかける前、まずは開発チーム内で何度も動作確認を実施しました。これにより、チーム内で見つけた分かりづらい文言やUIの細かい調整を事前に実施できました。その結果、クオリティ向上につながりました。
デメリット
リファクタリングに時間がかかる
この進め方の宿命ですが、一度書いたコードを、後からの仕様変更に伴って何度も書き直していくことになります。 開発の終盤になるほどコードベースは全体的に混沌としていき、変更作業が辛くなっていく、という場面も多々ありました。 「変更に強いコードを書く」という基本がいかに大事か、改めて痛感させられました。
おわりに
今回は、駅メモ！の「アルバム機能」開発において試みた、「大規模ドッグフーディング」と「アジャイル的な週次動作確認」という2つの工夫をご紹介しました。
どちらもメリットだけでなく、工数の増加やコードの複雑化といったデメリットも抱えていますが、前例のない大規模開発を進める上では非常に有効な手段だったと感じています。
リリース後、多くのユーザー様がアルバム機能をご利用くださり、お出かけの思い出を写真と共に記録していただいている様子を拝見し、開発チーム一同、大変嬉しく思っています。
これからも駅メモ！を長く楽しんでいただけるよう、チーム一同、開発と改善を続けてまいります。
