アジャイルってなんなんだ！？：ブラックアジャイルによろしく（4/4 ページ）

本企画はWeb開発企業『クレイ』におけるアジャイルソフトウェア開発の経験を漫画「ブラックジャックによろしく」の名シーンを挿絵に紹介するドキュメンタリーです。

[吉岡礼貴，クレイ]

「相対見積もり」

　個々の「ユーザーストーリー」に対して、「チーム」は開発規模を見積もり、「プロダクトオーナー」に知らせなければなりません。なぜなら、開発規模の大きさはコストの大きさであり、「プロダクトオーナー」は「ユーザーストーリー」の価値とコストを勘案して優先順位を決定するからです。

　「相対見積もり」とは、見積もりを人月などの絶対的な単位ではなく、相対的な値で付けることを指します（単位としては便宜的に「ポイント」を用いることがよくあります）。例えば「商品を人気順に並べて見られる…… 2ポイント」といった調子です。

　「相対見積もり」を導入したのは、ほどほどの精度の見積もりを素早く行うためです。なぜ素早く見積もれるかというと、相対見積もりでは、ほかのユーザーストーリーと比較した開発規模を主観的に答え、具体的な作業内容を決定しないからです。

　つまり、ポイントが「1」のあるユーザーストーリーよりは大変だけど、ポイントが「3」の別の「ユーザーストーリー」より簡単、ということであれば、「2」ポイントを付けます。最初の「ユーザーストーリー」にポイントを付けるやり方はいくつかあり、例えば一番簡単なものを「1」ポイントとするのは分かりやすいと思います。

　「具体的な作業内容を決めない」ということは、「要件の詳細が決まっていなくても適用できる」ということでもあります。プロジェクトの序盤にすべての要件を詳細に決めようとすると、コストが掛かるうえに、それは大抵間違っています。相対見積もりはあいまいな要件に適用できる、つまり「早期に見積もれる」という意味でも「素早い」やり方なのです。

　最後に「相対見積もり」から「絶対見積もり」への変換について説明します。スクラムでは1スプリント当たりに消化できるポイント数を「ベロシティ」と呼びます。「ベロシティ」は開発速度を表します。「ベロシティ」が分かれば、「相対見積もり」を「絶対見積もり」へ変換できます。

　「ベロシティ」を求める一番良い方法は、実際に数スプリント実施することです。しかし、それより前に「絶対見積もり」が必要な場合は、「ベロシティ」を予測します。「ベロシティ」には「チーム」のスキル以外に、製品の分野や用意された開発環境、「プロダクトオーナー」のスキルなど、あらゆる要素が影響するため、正確に予測することは不可能です。

「ブラックジャックによろしく」佐藤秀峰（漫画 on web http://mangaonweb.com/）より

　つまり、正確に見積もることは不可能ですが、それはどんな見積もり方法を使っても同じです。正確さにおける「絶対見積もり」に対する「相対見積もり」の優位性は、「相対見積もり」では「スプリント」を進めるにつれて勝手に正確さが上がっていくことです。

　「相対見積もり」では具体的な作業を決めないため、「絶対見積もり」に比べて見積もりのやり直しが発生しにくくなっています。一方で、「スプリント」を進めるごとに「ベロシティ」の実測値を得られるため、見積もりをやり直すことなく勝手に正確さが増していくのです。

「コードの共同所有」と「継続的インテグレーション」

　「コードの共同所有」とは、「ユーザーストーリー」の担当者を決めずに手の空いた人が実装し、完成したコードも誰でも修正して良いというルールのことです。クレイでは、プロジェクトごと1つのGitリポジトリを用意し、全員でそこにコミットをプッシュしています。

　「継続的インテグレーション」とは、新しいコードをプロジェクトのソースツリーから乖離したままにせず、できるだけ早くマージすることを指します。コードの共同所有と継続的インテグレーションには以下のメリットがあります。

• 仕掛りの「ユーザーストーリー」が減る
• 「ユーザーストーリー」同士の依存性に起因する待ちが発生しにくい
• 自然にお互いのコードをレビューでき、ミスを早期に発見できる
• チームメンバーへの負荷が偏らない

　アジャイル化を始めたころ、クレイではプロジェクトのリポジトリとして主に「Gitorious」というオープンソースを利用していました。ブランチの運用としては、Gitorious上のmasterブランチを製品コードとし、「チーム」メンバーがローカルで開発したコードを早いもの勝ちでmasterにマージ、プッシュするという、極めて原始的なやり方でした。

Gitoriousの使用例のスクリーンショット

　このやり方では、出来上がったコードを最短の時間で製品にマージでき、上に挙げたメリットを得られましたが、コードが汚くなるのも早く、のちに改善の対象になりました（後述）。

朝会

「ブラックジャックによろしく」佐藤秀峰（漫画 on web http://mangaonweb.com/）より

　朝会はチームが毎日やる短い立ちミーティングで、下の3つを伝え合うのが一般的です。

1. 昨日やったこと
2. 今日やること
3. 障害になっていること

　クレイでは「障害」になっていることの代わりに「気になっている」ことを伝えることにしています。これは、「障害」というほどのことでなくても、発言できるようにするためです。

　いうまでもなく、問題は早期発見できるに越したことはなく、メンバーが個人的に感じている不安を共有してもらうだけで、問題を未然に防げることがあります。「障害」を「気になっている」といい換えるだけですが、これはクレイ内で成果を上げていると実感しています。

　また、朝会はパソコンを使わず立ってやるのが一般的ですが、クレイでは大抵座ったまま向かい合い、ラップトップを膝に乗せてやります。そもそも「パソコンを使わない」とか「立って」というのは、素早く集合して短時間で終わらせるのが主な目的ですが、クレイのオフィスは小さいので「集合」する必要がそもそもなく、朝会で発表することをラップトップにメモしてる人も多いので、今のやり方になっています。

「ブラックジャックによろしく」佐藤秀峰（漫画 on web http://mangaonweb.com/）より

次第に表面化する問題点

　このように、クレイのアジャイル化初期には、改善の仕組みと変化に対応する体制だけがありました。しかし実際のプロジェクトでは、より長期的な計画やメンテナンス性を保ったコードなど、求められるものが他にもあり、次第に問題が表面化するようになりました。

　後編では、それらの問題と、実際に取った対策を紹介します。

著者プロフィール

吉岡ひろき

株式会社クレイ所属。認定スクラムマスター、Ruby on Railsプログラマ

ソフトウェア開発プロセスの継続的改善に強い関心を持ち、日々取り組んでいる。