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