KRAYのアジャイルソフトウェア開発

『アジャイルソフトウェア開発』という言葉を聞いたことがありますか？アジャイルソフトウェア開発とは、製品全体を一度に設計／実装するのではなく、期間毎に完成させる機能を選択して設計／実装し、それを顧客に公開してフィードバックを得ることで、製品の完成度を高めていく開発スタイルです。

KRAYでは現在プロジェクトのアジャイル化を進めています。そこで今回はKRAYのアジャイルソフトウェア開発について紹介します。

なぜアジャイル？

まず、なぜKRAYがアジャイル化を進めているかについてです。冒頭にも書いた通り、アジャイルなプロジェクトでは、設計／実装／デモンストレーション／フィードバックを反復することで製品の価値を高めていきます。これにより、我々は顧客に対して次ような価値を提供することができます。

• 決められた期間と予算の中で製品の価値を最大にする。
• 定期的に実際の動作するソフトウェアを見せられる。
• プロジェクトの終盤でも仕様変更に対応できる。

また我々自身にとっても、仕様変更に伴う交渉や、作っているものが正しいのかという疑問と不安から開放されるメリットがあります。以下ではKRAYでアジャイルな開発を実現するために実際にどのようなやり方をしているかを説明します。

その前に前提として知っていただきたいのは、アジャイルソフトウェア開発に決まった方法はなく、スクラムやXPといった主流のフレームワークをもとに、チームやプロジェクトに合わせて現場で生み出すものだということです。よってKRAYでやっているやり方も、様々な資料から得た知識をともに、自分たちに合ったものをつまみ食いした形になっています。用語も起源がバラバラだったりしますがご了承ください。

アジャイルなプロジェクトの一生

前回の記事にもざっと書かれていますが、今回はプラクティスという視点から紹介します。

「かんがえるシート」の作成

かんがえるシートはGetting Realとアジャイルサムライからヒントを得た一種のヒアリングフォームです。このシートを顧客と作成する過程で、その製品のコアとなる価値は何なのか、プロジェクトでは何を優先すべきなのかを明らかにします。

ストーリーの抽出

ストーリーとは、ユーザが製品を使うことで価値を得ているところを描写した短い文章です。例えば、「ユーザは自分のアルバムにパノラマレイアウトを適用できる」などです。製品のフィーチャーをこのような数十個のストーリーに分解し、優先順位順に並べます。

優先順位をつけることのできる人を、プロダクトオーナーと言います。プロダクトオーナーは顧客自身にやっていただくのが一番なのですが、プロダクトオーナーの仕事はそれだけではなく、実際に役割を務めていただく条件が整うことは稀で、代わりに社内の顧客担当者が代行しています。作ったストーリーはPivotal Trackerで管理しています。

また、この時点でストーリーの作業量を見積もります。見積もりの単位は「ポイント」です。簡単そうなストーリーは１ポイント、それより難しいのは２ポイント、さらに時間がかかりそうなのは３ポイントです。それより上の数もありますが、その場合はストーリーを分けた方がいい場合がほとんどです。

ポイントは相対的な単位で、実際に何時間かははっきりしません。それよりも１イテレーション（後述）に何ポイント分を完了できるか／できたかに注目します。１イテレーションのポイントの合計をベロシティと言います。ベロシティと残っているストーリーのポイントを見比べれば、いつ頃全てのストーリーを完了できるか一目瞭然です。

イテレーションの開始

イテレーションとは英語で「反復」のことですが、主にアジャイルソフトウェア開発の文脈では計画からデモンストレーションまでのサイクルを指します。イテレーションはプロジェクトの最初から最後まで、決まったタイムスパンの中で行います。タイムスパンの長さはプロジェクト毎に決定しますが、KRAYの場合は今のところ全て１週間です。

イテレーションの最後には顧客へのデモンストレーションがありますが、プロジェクト開始１週間で顧客からフィードバックをもらう価値のあるソフトウェアを作るのは困難です。なぜなら、ソフトウェアの構成の検討や技術的な検証、開発環境の整備などを行わなければならないからです。よってこれらの作業は最初のイテレーションの前に行います。これをイテレーション０（ゼロ）と呼んだりします。

イテレーション０が終わったらいよいよ実装開始です。一度始まってしまえば、あとは契約が切れるまで反復を続けるのみです。

イテレーションでやること

イテレーション計画ミーティング

KRAYのイテレーション計画ミーティングでやることは主に２つ、ストーリーの確認と目標の設定です。ストーリーは短い文章として生まれるため、誤解されていることがよくあります。仕様として機能するように、ミーティングまでに主にプロダクトオーナーが詳細を書き込みますが、それでも誤解は生じます。また、２回目以降のイテレーションでは状況が変わっていることがよくあります。そこで優先順位の高い方から全員で内容を確認していくのです。

目標の設定とは、そのイテレーションでどのストーリーまで完了させるか決めることです。過去のベロシティを参考に、開発チームはどこまで完了させるかを約束しなければなりません。

作業開始！

イテレーションが始まったら、開発チームのメンバーはストーリーを上から取っていきます。誰がどれを担当するかは決められていません。ストーリーの消化については後述します。

デモンストレーション

顧客にはできるだけ定期的にデモの時間を取っていただきます。そしてそのイテレーションで完成したフィーチャーを見せ、フィードバックをもらいます。また、新たなストーリーを追加するために諦めるものや、優先順位の確認もします。

ふりかえり

「ふりかえり」とは、イテレーションのうまくいったところ、問題点、次のイテレーションで挑戦することを全員で挙げて確認するミーティングです。イテレーションの終わりにこれを行うことで、チームのスキルやプロセスが改善されていきます。

毎日やること

朝会

朝会とは、１日の早い時間に行う短いミーティングです。一般的には各自が「昨日やったこと」「今日やること」「問題点」を話すことになっていますが、KRAYの場合は「問題点」の代わりに「気になっていること」を話します。理由は、“問題というほどでもないこと”が挙がるため、本当の問題になる前に気づけることと、何でも話せるためにすっきりした気分で作業にとりかかれることです。この置き換えはとても上手くいっていると感じています。

ストーリーの消化

KRAYの開発チームがストーリーを消化する手順はこうです。

1. Pivotal Trackerで誰も手をつけてないストーリーのStartボタンを押す
2. ストーリーにreviewタグ（後述）が付いていれば設計を図や文章に落としこんで他のメンバーに公開する
3. テストコードと製品コードを書く
4. すべてのテストが通ることを確かめる
5. 共有リポジトリのソースコードにマージする
6. 自動的にサーバ側で全てのテストが実行される
7. 通ったらPivotal TrackerでFinishボタンを押す
8. 結合テスト環境にデプロイする
9. 結合テスト環境で動作確認する
10. 問題なければPivotal TrackerでDeliverボタンを押す
11. プロダクトオーナーにメールが届く
12. プロダクトオーナーは結合テスト環境で動作確認する
13. 問題なければPivotal TrackerでAcceptボタンを押す

ポイントだけ説明すると、まずストーリーの担当者は誰かがStartボタンを押すまで決まっていません。原則として、手持ちの作業が終わった人が優先順位順に上から取っていきます。

こうすることで全てのメンバーがより広い範囲のソースコードに目を通すことになり、問題を発見しやすくなります。また、直前に書いた人のコードを読むことで新たな知識を得たり、逆に教えてあげることができます。

次にreviewタグについてですが、これはPivotal Trackerの機能を使って、作業量の多いストーリーや影響範囲の広いものに印を付けて、全員で検討するルールです。前述の通り、書いた後のコードは自然にレヴューを受けますが、それでは遅いことが予想される場合、先に設計を共有して洗練します。

最後にピックアップするプラクティスは、継続的なインテグレーション（結合）です。複数人で１つの製品を開発するため、作業の同期は重要なポイントです。こまめに（１日に数回〜十数回）結合・テストすることで、デモンストレーションのために必要な作業を溜めません。

また、手順には現れませんが、「完了の定義」というプラクティスも採用しています。これは、そのプロジェクトにおいてAcceptされるための普遍的な条件を列挙したものです。例えば以下のような項目があります（項目はプロジェクトによります）：

• メッセージが国際化されていること
• iPadで動作確認をしてあること
• データが壊れていたら適切な対応をすること

以上のプラクティスの積み重ねにより、常に最新版が動作する状態を保っています。実際に今まで「5分以内に最新版でデモできるようにして欲しい」という要求に何度も応えています。

今後の課題

KRAYのプロジェクトには、お受けする仕事の傾向のため、難しい点がいくつかあります。その１つが、プロジェクトの短さに起因する不安定なベロシティです。

ベロシティは開発速度を表しますが、こなしたストーリーが多い方が信頼できる値になります。プロジェクトが短いと（例えば１ヶ月）信頼できる値になる前に終わってしまうのでメリットを得られません。もちろん、プロジェクトが短ければ見通しを立てるのも楽なのですが、ベロシティがないのは心細さを感じます。

もう一つの課題が、顧客との関係です。我々は可能な限りアジャイルな開発で価値ある製品を作りたいと思っていますが、顧客によってはそういった進め方に全く興味がないのも事実です。たとえアジャイルな開発に興味を持っていても、プロダクトオーナーを努める方には残念ながらめぐり会っていません。

また、契約形態も悩みの種です。事実として、契約時の仕様と満了時の仕様が一致することはないのですが、それをどうやって契約に盛り込み、顧客の社内で承認を得るか、非常に難しい問題です。

以上、駆け足ですがKRAYのアジャイルソフトウェア開発についてご紹介しました。アジャイルな開発で最大限に価値のある製品を作りたい、とお考えの方は是非ご相談ください。