アジャイルってなんなんだ!?ブラックアジャイルによろしく(4/4 ページ)

» 2013年04月15日 18時00分 公開
[吉岡礼貴クレイ]
前のページへ 1|2|3|4       

「相対見積もり」

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

 「相対見積もり」とは、見積もりを人月などの絶対的な単位ではなく、相対的な値で付けることを指します(単位としては便宜的に「ポイント」を用いることがよくあります)。例えば「商品を人気順に並べて見られる…… 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プログラマ

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


前のページへ 1|2|3|4       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。