ペアプログラミングとテスト駆動開発でアプリ開発の課題を解決
本セッションの前半は、山下真一郎氏が「ヤフオク!公式アプリが品質と技術を高めるために取り入れた開発手法」について語った。
山下氏が担当しているヤフオク!公式アプリが抱える課題は大きく分けて2つある。
1つ目はビルド時間が増え続けていること。ヤフオク!公式アプリのリリースは2010年で、以後6年以上開発が続いている。その間、さまざまな機能が追加されてソースコードの量が膨大になった結果、ビルド時間も大幅に増加してしまった。ビルドの待ち時間が増えた影響で開発効率も低下している。
2つ目の問題は単体テストが書きにくい設計になっていること。自動化できる単体テストの総量が少ないため、それだけでは全機能の動作を保証することができない。手作業のテストで品質を支えている状態だが、時間がかかるためコードを変更してからリリースするまでのリードタイムも増加している。
「開発フローを見直さなくてはいけない」、そんな課題感をメンバー全員が持っていた。
これらの問題を解決するきっかけとなったのが、アジャイル開発が体得できるサービスを企業向けに提供するPivotal Labs社での修行である。同社では「リーンソフトウェア開発」、アジャイル開発の一種である「エクストリームプログラミング」を実践している。
リーンソフトウェア開発は「ユーザーに価値のあるものを届ける、それ以外は全てムダ」という考え方、エクストリームプログラミングはソフトウェア開発をするときのルールを定義した開発手法である。両者を組み合わせた開発手法をPivotal Labs社では「LEAN XP」と呼んでいる。参加メンバーは同社で2カ月間LEAN XPを学び、ペアプログラミングやテスト駆動開発を実践。Yahoo! JAPANに戻ってからもシャドーイングしている。
LEAN XPはプロダクトマネージャー、デザイナー、エンジニアが三位一体で開発していく手法であり、特徴の1つに、エンジニアが必ず2人1組のペアでプログラミングを行うことが挙げられる。
始めに、プロダクトマネージャーが開発する機能を小さく分解する。それらに優先順位を付けてから各ペアにタスクを割り振っていき、各ペアは実装を始める。
次の日、各タスクには前日の担当者が必ず1人残り、新しい人とペアを組む。そこで前日の担当者は、新しく来た人に仕様を説明する。ペアは毎日入れ替わるので、結果的にチームは、案件の仕様に全員詳しくなる。
「このペアプログラミングにより、メンバーは自分が今まで知らなかった実装方法、トラブルシューティング、ショートカットなどさまざまなことを学習し、技術力が短期間で一気に底上げされた」と、山下氏は語る。
ペアプログラミングではソースコードの共同所有という考え方が意識され、山下氏のチームでもそれを徹底している。担当タスクと無関係な場所で問題を見つけた場合でも積極的に解消するなど、助け合いの精神が非常に強くなっている。
ただ、ペアプログラミングには「プライベートな時間が確保しにくい」という側面もある。「私のチームではペア以外で作成したコードは認めていないので、仕事は定時までやって、その後は速やかに帰るよう促している」という。
チームに変化を与えるために、山下氏が重要だと考えているのがテスト駆動開発である。この手法はペアプログラミングと非常に相性が良い。ペアには「ナビゲーター」「ドライバー」の役割がそれぞれ与えられる。最初にナビゲーターが失敗するテストを書き、次にドライバーがテストを通すコードを書く。このコードはテストを通すため、最小限の設計になっている。テストが通ると、ナビゲーターがリファクタリングを行う。テストをパスした実績があることにより、安心してコードを大胆に書き換え、整頓することが可能になる。
しかし、エンジニアに「失敗するテストを書いてほしい」と言っても、いきなりそれを実行するのは難しい。そこで、プロダクトマネージャーは失敗するテストを書きやすくするためのタスクを準備する。
タスクの優先順位と粒度は、プロダクトマネージャーが管理する。それぞれのタスクは、ペルソナ（架空の顧客像）から生まれている。まずは「ペルソナがアプリを起動し、終了する」までの一連の流れからシナリオを抽出する。そこからタスク（LEAN XPではストーリーと呼ばれる）へ分解していく。
ヤフオク!公式アプリの例では、「ケンジ（人名）がJRの中央線でアプリを立ち上げ、ポールスミスのシャツをウォッチリストに登録し、入札する」までの流れを追っている。ポイントは実際にユーザーの気持ちになり、物語を作成することだ。リアルな文章を作成することで、起きうることを実感することができる。
ロジックとデータポイントを抽出すると、その一つひとつが複数のストーリーになる。ウォッチリストに登録するのがロジックで、商品の名前や価格がデータポイントだ。
ストーリーは受け入れテストをしやすくするため、最小単位になっている。例えば｢ケンジが商品詳細画面上の入札ボタンをタップすることができる｣流れを、ケンジになったつもりでストーリー文にすると以下の通りになる。
- GIVEN 私は商品詳細画面を表示している
- WHEN 私は「ウォッチリスト登録」ボタンを見た
- AND 私はその隣に「入札する」ボタンを見た
- THEN 私は「入札する」ボタンをタップすることができるはずだ
頭にある英語の接続詞は、ガーキン（Gherkin）フォーマットと呼ばれている。GIVENは「前提条件」、WHENは「もし」、ANDは「かつ」、THENは「ならば」である。このフォーマットはエンジニアがテストを書きやすくし、非エンジニアでも理解できるものである。また、ストーリーの粒度を一定にすることにも役立つ。
ストーリーを書いて優先順位が確定したら、プロダクトマネージャーからエンジニアにストーリーを渡す。IPMと呼ばれる見積もりミーティングを実施し、エンジニアに「それぞれのストーリーがユーザーにとって価値があるものか」聞いていく。そして技術的な課題の検討が終わったら、ジャンケン見積もりを開始する。
実装はテスト駆動開発で行い、完了したらエンジニアではなくプロダクトマネージャーが受け入れテストを行う。重要なポイントは、「作った人がテストをしない」ことだ。
LEAN XPを取り入れた結果、以前のプロジェクトと比較して、受け入れテストの失敗率が20％から3％に激減した。さらにリードタイムも1/8まで削減できた。
実は、LEAN XPを取り入れたこのプロジェクトの前に、山下氏は凍結してしまったプロジェクトを経験していた。そのプロジェクトでは受け入れテストの失敗率が高く、さらにテストの内容も粗いものだった。現場の雰囲気もどんどん悪くなり、途中まで作ったものをリリースすることができず、苦い思いをした。しかし、「今は小さく価値のあるもの順に作り、常にリリースできる状態にしているので、変化に強いチームになったと感じている」と力強く語る。
山下氏は最後にまとめとして、Pivotal Labs社で学んだ、3つの重要な考えを提示してセッションを締めくくった。
- より小さくより価値の高いもの順に実装を行う
- 単体テストが壊れたら最優先に修復する
- 自分の実装は自分以外が確認する
