モバイルオーダーを開発する中で役立った5つの取り組み

始めに

STORES エンジニアの waniji です。このたび STORES では STORES モバイルオーダーというサービスをリリースしました。

www.st.inc

価値の高いプロダクトをスピード感を持って開発するため、チームでさまざまな取り組みを実施してきました。その中でも、特にやってよかったと感じた取り組みを5つ紹介します。

1. リリースフェーズを区切る

モバイルオーダーで実現したいことは多岐にわたりましたが、すべてを盛り込むとリリースが後ろ倒しになってしまうため、優先順位を明確にする必要がありました。そのため、リリースまでのマイルストーンとしてリリースフェーズを区切り、そのフェーズごとのスコープを明確にしました。今回の開発では社内リリースと正式リリースを含め、4つのフェーズに分けています。

各フェーズのスコープは、「モックレベルのものが動く」「最低限の機能が動く」「本番リリースに最低限必要な機能が動く」「正式リリースに必要な機能がすべて動く」という内容にしており、どのフェーズでも必ず動作することを条件にしています。これは、動くものを作ることで、実際に動かしてもらい操作感を確かめてフィードバックを得やすくしたり、プロダクトの理解度を高めるという狙いがあります。

多くの物事を同時に考えすぎるとワーキングメモリが不足し、集中力や判断力が低下して開発のパフォーマンスが落ちます。リリースフェーズを区切ることで、今回のスコープに含まれない事柄は次のフェーズに送ることが可能です。こうして同時に考えるべき事柄を絞ることで、スピード感を持って開発を進めることができました。

また、開発が進んだ後に初めて気づくことが多く、当初の検討内容を見直す場面もありました。プロダクトへの理解度が低い状態で、深く検討しすぎないことの重要性も実感しました。

2. ステージング環境に開発者が共用するストアを作る

開発者が各々のストアを作成して動作確認を行うことが多いのですが、これはプロダクト理解を深める点では良いものの、さまざまなパターンのデータを作る手間がかかります。モバイルオーダーでは販売する商品のパターンが多く、必要最低限のデータを作るのも一苦労でした。

そのため、開発チーム用のストアを作り共用しました。STORES には従業員を管理する機能があり、開発者を従業員として招待して権限を与えることにより、簡単に複数人でストアを管理できます。こうすることで、機能追加後の全体共有やスプリントレビューでの発表がスムーズになりました。

新しいメンバーが参加した際も、従業員として招待するだけで簡単にストアを使えるようになるため、運用も楽です。さらに、従業員機能のドッグフーディングも出来て一石二鳥でした。

3. 全体を俯瞰出来る状態を作る

私はプロダクトを開発・運用する際、全体を俯瞰出来る状態にすることを重視しています。細部まで見るのではなく、どのアプリケーションがやりとりを行っているのか、リクエストの流れはどうなっているのか、大まかな機能は何か、といった粒度で把握します。この俯瞰的な視点を維持するために、図を活用しています。図を用いることで、複雑な情報を視覚的に整理し、関係性や構造を一目で理解しやすくなります。

具体的には、リクエストの流れやアプリケーション間のやり取りを把握するためにシステム構成図を作成しています。これにより、プロダクトがどのシステムと連携し、どのチームと密に協力すべきか、また懸念事項が何かを明確にできます。さらに、障害が発生した際の影響調査や迅速な解決にも大いに役立ちます。

機能に関しては、Figmaで管理されている各ページのデザインを参照することで、全体の機能構成を把握しています。これにより、デザインと機能の整合性を保ちつつ、開発チーム全体が同じビジョンを共有可能になります。

モバイルオーダー開発チーム内や、関連システムのチームと議論する際、俯瞰図やデザインをお互いに見ることで認識の齟齬を減らし、スムーズに物事を進めることが出来ました。

4. 複雑な機能の理解を助けるドキュメントを書く

図で全体を俯瞰し、細部はコードで理解することが多いですが、コードだけでは理解が難しい複雑な機能も存在します。モバイルオーダーでは、商品の組み合わせパターンや決済ページが該当します。

昨今、認知負荷を下げることが重要と言われていますが、その機能が持つ内在的な複雑さは取り除くことができず、向きあっていく必要があります。すべての開発者がコードを何度も読み込んで理解するのは効率が悪いですし、こういった複雑な機能は一度理解しても時間が経つと忘れてしまうので、また理解に時間をかけることになります。この理解を助けるためにドキュメントを作成しました。

複雑なパターンが存在する機能では、類似パターンに名前をつけドキュメント化することで、理解しやすい状態にしました。これにより、理解度が高い状態でスプリントプランニングを進めることが出来て、計画の質を高めました。

決済ページでは、クレジットカードのトークン化や3Dセキュア対応などが関わり、複雑なやり取りが増えます。そのため、シーケンス図を作成し処理の流れを可視化することで、理解を助けるようにしました。こちらはプルリクエストのレビューや、セキュリティチームとのやり取りで活用しました。

5. 記憶喪失になる前に情報を簡潔に残す

プロジェクトが進むにつれて、過去に決めたことをどんどん忘れていきます。職種を問わず、程度は異なりますが、誰もが忘れてしまいます。SlackやGitHub Issueに記録されていれば運良く見つけることもできますが、口頭で話した内容は残りません。議事録があれば探すことも可能ですが、日々の会話や昼会で話したことは記録するのを忘れがちですし、議事録が大量にある場合は探すのも一苦労です。

これらの問題を解決するために、意思決定したことを簡潔に残すようにしました。技術的な意思決定はADRとしてGitHubに書き、プロダクトに関する内容はesaに記録しています。

プロダクトに関する内容については、各機能ごとに記事を作成し、現時点での意思決定内容、将来的な構想、意思決定した日時と内容のサマリー、そしてSlackのリンクを記載しています。内容は長くなりすぎないように気をつけています。長すぎるドキュメントは読まれず更新もされなくなるからです。

この取り組みは途中から始めたもので、メンバー全員が意識して残せている状態ではないですが、それでも役立つタイミングは多いです。