経緯
「複雑化する仕様、委託先との契約形態、稼働スケジュールやキャパシティーという課題を全部解消し、ついでに、雪や地震等で、委託先の変更を迫られてもすぐに対応できるシステムを作ってくれ」と言われて、一体どのようなソリューションにすれば、正しい課題解決ができるのか。そのような緊急度が高く、要件が極めてふわっとしている状態でプロジェクトが難航している中、CTOの泉に突拍子もなく「この課題は、この会社と一緒に共同で解決してみてくれないか？」と言われ、出会ったのがPIVOTALと、その会社が推奨するXPでした。
開始前：XPについて
書籍 エクストリームプログラミング などを読んで勉強しました。ただ、書籍の内容は理解できるのですが、本当にそうなのか？という疑問を抱きました。
- 疑問１: ペアプロは生産性が下がるのではないか？
- 疑問２: 将来を見越した設計よりシンプルな設計？
ペアプロ（ペアプログラミング）とは
文字通り二人で共同でプログラミングを行うことです。ディスプレイ、キーボード、マウスを２個づつ用意し、コードを書く「ドライバー」、仕様書を確認したり全体構造を考えたりする「ナビゲーター」に分かれて作業します。詳しくはこちらの wiki へ。
メリット
- ペアプロすると途中で脇道に逸れず集中して開発できる
- 議論しながら進めるので１人で開発するよりもいいものがアウトプットできる
- コードは２人で見ているので、コードレビューをしなくてすむ
- コードの共同所有が進むため属人性が排除できる
開発
体制
- PM 2名(raksul 1名 pivotal 1名)
- エンジニア 4名(raksul 2名 pivotal 2名)
方針
XPの方針であるユーザー価値を提供することを主眼として、「シンプルな設計・実装」にのっとり進めました。
開発プロセス
以下の手順で開発を行ないました。
- PMがストーリーを書く
- ストーリーは細かく（1時間〜1日程度の大きさ）
- 受け入れ条件は明確に
- ユーザー価値のある最小単位で
- エンジニアとPMでストーリーの計画をする
- ストーリーの見積りなど
- エンジニアはペアで実装する（ペアプロ）
- エンジニア間で毎日ペアの交代
- テストコード実装（テストファースト）
- コード実装
- PMが受け入れテストを実施する
ストーリーとテスト
ストーリーの粒度はかなり小さく、受入条件が明確でした。これによって何をテストすべきかが分かり易く、テストケースが書きやすくなりました。
例えば、「Form を表示する view を作る」とした場合、Form の Submit ボタンが表示される （以降、ストーリを参照のこと）などです。
以下に実際のストーリーとテストのサンプルを記載します。(英語ですが…）
#ストーリー例
Title: Suzuki can see input form for supplier simulation
AS Suzuki
GIVEN I'm logged in
WHEN I'm on the supplier similation page
THEN I should see the following input fields:
- Size
- Type
- Weight
- Color
- Volume
- Lead time
AND I should see a "Simulate" button
note:
no design
# テスト例
assert_select 'form'
assert_select 'input[name="order[size]"]'
assert_select 'input[name="order[type]"]'
assert_select 'input[name="order[weight]"]'
assert_select 'input[name="order[color]"]'
assert_select 'input[name="order[volume]"]'
assert_select 'input[name="order[lead_time]"]'
assert_select 'input[type="submit"]', text: 'Simulate'
ストーリーの粒度が小さいことの、その他のメリットとして、仮に、認識の齟齬があったとしても、早い段階で間違いに気がつくことができ、無駄な開発を行わずに済みました。また、ストーリーを消化しやすいため、開発がリズムに乗り、プロジェクトの前進感が味合えました。
XPを体験して
当初思っていた２つの疑問は以下のように晴れました。
疑問１: ペアプロは生産性が下がるのではないか？
定量的な比較は難しいですが、生産性は思ったよりも上がった気がしました。上記で記載したペアプロのメリットを享受できたと思います。その中でも特に良かったのは、コードの共同所有が進み、開発者の入れ替わりがあった際も生産性が落ちなかったことです（今回は３人ほど入れ替わりがありました）。
デメリットを挙げるとすれば、２人とも実装方法が分からず調べてみないと分からないといった状態が続くようであれば、効率が悪いということでしょうか。また、エディター環境が異なると、毎回設定などを切り替える必要があったので、その点が面倒でした。
疑問２: 将来を見越した設計よりシンプルな設計？
シンプルな設計で進めたことは良かったと思います。プロジェクト中、要求が変わった際、手戻りが少なかったです。また、テストにより、変更容易性が担保され、設計を変更しやすかったのも良かったです。結果、機能をはやくエンドユーザーに提供することができ、万々歳でした。
最後に
XPという初めて試みる開発手法で、当初は不安な部分もありましたが、実際に体験することで、メリットを肌で感じることができ、有効な開発手法であると思えるようになりました。現在、ラクスルでも部分的にではありますが、XPの手法を取り入れ、実践中です。まだまだ、課題はありますが、XPで開発したいという方、興味が有る方はぜひぜひ連絡お待ちしております。