こんにちは、今期から Zaim のアプリ開発チームリーダーになった @y_sumida です。

Zaim では不具合の修正を除き、だいたい 3〜4 週に一回のペースでアプリをアップデートしています。最近、敢えて iOS 版と Android 版でリリースするタイミングを変えたところ、開発の効率が非常に良くなったので、その理由や背景を紹介しようと思います。

開発が効率化＆不整合が発見しやすく

ここ数か月、Zaim では iOS 版をリリースした後に Android 版を公開する、というサイクルで機能を公開しています。この流れにするメリットは、大きく二点あります。

（１）Android 版の開発に迷いがなくなる
（２）プラットフォーム間の仕様の不整合を発見しやすい

Android チームは、既にリリースしている iOS 版を実機で動かして仕様を確認しながら開発できます。当初の仕様に抜け漏れや不明瞭な点があったとしても、iOS チームが先に潰しているので、手戻りがなく迷うことはありません。また逆に、Android 版の実装で発生した疑問から、iOS 版のバグや仕様の考慮漏れが見つかることもあります。

プラットフォーム間の仕様が合致していない部分を見つけやすいという副次効果もあります。Zaim は歴史的な経緯によって、iOS と Android で微妙に仕様が異なる部分が存在します。しかも、ドキュメント化が追いついていません。iOS と Android の仕様を横断的に把握しているメンバーは少ないため、これをきっかけにドキュメントが進むという良い機会となっています。

結果として、全体の開発効率が大きく向上しました。

大幅にリリース日が遅れた過去の失敗に学ぶ

こうした「時差」を持たせた開発フローは、当初から意図して選択したわけではありません。チームの状況に合わせて試行錯誤した結果、こうなった……というのが正直なところです。

きっかけは、「iOS と Android を同時にリリースしようとしたら、スケジュールが大幅に遅れてしまった」という、過去の大失敗です。大規模なリニューアルだったことを差し引いても、非常に効率が悪い開発になってしまいました。

機能拡大に合わせ、仕様を決定するまでの関係者が増えたことが、その理由に挙げられます。

仕様にはアプリエンジニアだけではなくサーバーサイドのエンジニア、デザイナーも関わり、さらにそれぞれの人数が増えたことで、最終決定までに時間がかかるようになりました。また、iOS と Android のエンジニアが別々に仕様を確認するため、互いが指摘した点を反映し伝わるまでにタイムラグがあり、手戻りが多く発生してしまいました。

さらに当時、仕様書として使っていたスプレッドシートが非常に使いづらい状況でした。

仕様が変わっても、どこに修正が入ったのかが検知しづらく、把握に時間がかかっていました。

きっかけは Android のリファクタリング

ちょうどこの頃、Android 版は何度かリファクタリングに取り組んだ期間があったこと、Android チームより iOS チームの開発メンバーが多くなったことなどにより、明らかに iOS チームの方が開発スピードが早くなりました。

そこで、Android はリファクタリングやそれに伴う不具合の修正を優先し、まずは iOS で機能追加を進めようという判断になりました。これをきっかけに、iOS の先行リリースという体制が始まっています。

また、仕様書にスプレッドシートを使うのを止めて GitHub で管理し始めたのも同じ頃です。

8 ステップで仕様策定から開発までを完了

では、現状の Zaim の仕様策定から開発、リリースまでの流れを見てみましょう。現在、Zaim ではデザインには Sketch と Abstract、仕様書には GitHub を使っています。

（１）デザイナーが要件を Sketch で起こす
（２）Sketch を Abstract でエンジニアと共有
（３）iOS チームが Abstract を確認しつつ、不明点をコメントで確認
（４）私またはデザイナーが GitHub 上に仕様書を作成する
（５）iOS チームが Abstract と仕様書をもとに実装を始める
（６）実装中に判明した問題点や仕様漏れを仕様書にフィードバックする
（７）Android チームの定例で仕様変更の経緯やハマりポイントを共有する
（８）Android チームは実装中に気づいたことを仕様に反映する

この流れに沿うことで、手戻りの少ない、スムーズな開発フローを実現できるようになりました。

なお、仕様の統一は「Android と iOS で UI を一緒にしよう」という意味ではありません。プラットフォームごとにガイドラインが異なりますので、正しいとされるデザインは違いますし、既存の実装による差分も存在します。

こうした差異は、仕様書に可能な限り詳細に記述しています。

余談ですが、チームの状況によってプロセスが変わっていったので「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というコンウェイの法則に当てはまるのかなと思ったりしています。

今後は iOS・Android で交互に開発を進めたい

全体としては今の所うまく回っているものの、複雑な仕様になってくると先行チームの負荷が高くなりがちなので、改善したいと考えています。

また、現時点ではすべての仕様が GitHub に集約できているわけではありません。今後は仕様に関するすべての情報を GitHub に一元管理していく予定です。

そして、将来的には iOS チームと Android チームで別々の機能を交互に開発できるようになりたいなぁと妄想しています。

終わりに

iOS 先行のサイクルを逆転させてやるぞという Android アプリ開発者の方や、仕様をどんどん決めていくぞというディレクターの方、お待ちしております！