こんにちは。 テストエンジニアからサービス開発エンジニアにロールチェンジした、茂呂一子です。 先日リリースしました、iOSクックパッドアプリのリニューアルプロジェクトに参加し、サービス開発エンジニアとしての第一歩を踏み出しました。
今回は、アプリのリニューアルをすすめていく中で、試してみたことについて、お話しします。
アプリリニューアルの内容やそのデザイン意図については、13年続いた「つくれぽ」をリニューアルした話｜Misaki Kubosaka｜noteが詳しいので、こちらをお読みください。
リニューアルプロジェクト第1フェーズの問題点
iOSアプリのリニューアルプロジェクトは、とても大きく、機能を段階的にリリースするため、3つのフェーズに分けて開発していくことが決まっていました。 そのため、開発チームはメンバーの追加をしつつ、複数回の開発サイクル(仕様決定、設計、実装、検証)を繰り返すことになりました。
クックパッドのサービス開発では、主に、ディレクターとデザイナーが企画と仕様決めを行い、エンジニアが実装し、ディレクター/デザイナーが作成するテストケースを元に検証を行うという方法が取られます。 以後の「ディレクター」は、企画と仕様決めに責任を持つディレクターとデザイナーの両方を指します。
私が参加したのは第1フェーズの途中からで、そこではテストケース作成をはじめとした検証を担当しました。 第1フェーズでは、 テスト期間の開始間際まで仕様の整理が行われていたり、不明瞭になっていた箇所への仕様追加がされたりしていました。 どうにか第1フェーズの開発を終え、リリースすることはできましたが、仕様が不明瞭なまま開発をすすめていくことに大きな不安を感じました。
その次の第2フェーズでは、私は開発エンジニアとしてモバイルアプリ開発をすることにしていました。 第1フェーズの反省から、いかに仕様の決定を早期に行うかを考え、仕様の抜けを早く検知する手段を講じる必要がありました。
第1フェーズのすすめ方の問題点はいくつかありました。
- ディレクターが仕様を決めるが、複雑なユーザー状態すべてを考慮できなかった
- 影響範囲が大きいため、たくさんの仕様の検討会が行われており、ディレクターが結論を精査する時間がとれなかった
- どこまで決まっているかの管理をディレクター任せにしてしまったことで、ごく少数の人間だけが仕様を知っている状態が発生した
- 実装担当は共有された情報から仕様を理解していたが、細かな認識の齟齬があることに後々まで気づけなかった
- 後々発覚した認識の齟齬を埋めるために、仕様追加がされ、開発スケジュールがずるずると伸びた
仕様を実現していく上で必要な情報共有が不足している、ディレクターから実装者への一方通行であることが問題と考えました。
そこで、仕様の不明瞭な点を実装開始前に明かにする、そのために情報共有の精度をあげる方法を探すことにしました。
テストケースの作成を通じて、仕様を詳細化する
仕様の情報共有の精度をあげる方法を2案考えました。
- ディレクターに仕様詳細化をお願いし、その共有を実装担当者とする時間を設ける
- 第1フェーズでは、やっているつもりだができていない状態だった
- タイトなスケジュールの中では、実現可能性を考慮してセカンドプランを選択するべき場面があるが、それをディレクターだけでは判断できない
- ディレクターと実装担当者が会話した上で、実装担当者が仕様を詳細化する
- 仕様の検査に確実に2者の視点が入るので、情報共有の不足を低減できる
- 実装担当者のシリアルタスクのため、実装前に詳細化を完了しやすくなり、その結果、仕様追加の追跡がしやすく無理な変更の抑制ができる
案1は、第1フェーズで結果的にうまくいかなかった方法とあまり差がないこと、また、実装のコストや難易度の反映が遅くなる危険があったため、案2を採用しました。
私が属した機能グループでこの取り組みを行いました。大きく2つの機能を実装するグループです。
新機能に対して、ディレクターと実装担当者間で仕様の共有会を行い、そのインプットを元に実装担当者が仕様を詳細化しました。 このとき、ユーザー状態や利用状況の網羅性をあげるため、分析が網羅的になるようテストケースを作成するという手段をとりました。
テストケースというフォーマット
テストケースは、一般に、状況設定と操作と期待結果の組み合わせを列挙するものです。 とある機能において取り得る状況を網羅するには、テストケースの状況設定を細かく分析できるかが鍵です。 状況設定を細かく分析しやすいと考えたので、テストケースのフォーマットを利用することにしました。
そのとき使用したフォーマットは以下のものです。
一部は選択式にしつつ、その他のデータやユーザーの条件は自由設定にしています。 これまでの経験から仕様に現れない操作は忘れられたがちなため、操作は選択式にしました。
例えば、画面の通信エラーが起きたときの振舞いは未定義になりがちなので「通信エラー」、文字入力に関するバリデーションエラーの扱いを考慮してもらうために「文字入力」などを用意しました。 他には、細かな機能の出し分けがあるため、ユーザーステータスも選択式にしました。
仕様詳細化の効果
実装担当者は、テストケース作成を通じて、不明点/検討されていない点をリストアップしました。それをディレクター、デザイナーと共に解消した上で、実装を開始しました。
成果物としたテストケースは、その後ディレクターが加筆して検証フェーズで利用されました。 加筆といっても、この取り組みをしたのは新機能まわりだけだったので、ディレクターが新規に作成した既存機能との関連を見るテストケースの方が圧倒的に多いです。
検証フェーズでは、実装担当者が作成したテストケースの周辺では、ディレクターの追加したテストケースによって、大きな仕様差異が発覚することはありませんでした。
仕様詳細化をする段階で、問題を発見できたことで、第1フェーズに比べて安定した進行でリリースまで漕ぎ着けることができました。
リリース後の振り返りでは、エンジニアからは「実装開始前にテストケースができていたことで、仕様の不明点が洗い出せてよかった」と高評価を得ました。 一方、ディレクター陣からは、エンジニアが作ったテストケースにディレクターが手を入れるという形をとったため、検証の信頼性が低いので今後はディレクターがテストケースを作る、という評価を得ました。
実装担当者がテストケースを作成する是非
一般的に、実装担当者が作成するテストケースでは見つけられない不具合が多い、という信頼性の低さがあります。 テストケースが先でも、実装が先でも、先に考えた理解の範囲に引きずられて、網羅性が上がらないことは想像しやすいと思います。
ディレクター陣からの評価が下がった原因も、「実装担当者が作成したテストケースを検証に使った」ことにあると考えられます。
詳細化の分析手段としてテストケース作成のフォーマットに載せたことで、仕様の検証精度は上がった可能性はありました。 実装担当者からの反応はよかったので、仕様を理解する、過不足なく機能を実現することには貢献したと考えられます。
しかし、その成果物を流用させてしまったことで、 検証能力が低いテストケースであるために不具合件数が減ったのか、 実装精度が高いことで不具合件数が減ったのか、の区別ができなくなっていました。
私が検証のためのテストケース作成と完全に分離せず、成果物の流用を許容してしまったことで、有用性の評価が十分にできなかったのは残念でした。 あくまで詳細化の過程の成果物であり、検証用途ではないとするべきでした。
この手の信頼性問題は、コンセンサスを得ていない手段を使ったことで結果が下がった可能性をゼロにできなければ、マイナスに取られる他ないので致し方ないと思っています。
反省点はありますが、「仕様を考えている人以外も混じえて、実装開始前に仕様を明かにする」ことで、スムーズに開発をすすめることはできました。
次回は、成果物が一人歩きしても問題ないよう、用途を制限することと、誤解の生じる利用のされ方を回避することが必要になるでしょう。 分析の助けになることが重要のため、成果物の形をテストケース以外にできると、外部からの誤解も減らせると思えるので、他の形を模索したいと思います。
クックパッドではモバイルアプリの品質を安定させたいiOS/Androidエンジニアを募集しています。 https://info.cookpad.com/careers/
