よくある課題と解決方法
ここからは、筆者らがディーバで実際に直面したことや、執筆者の1人の梅田さんが理事を務めるMIJSの製品技術強化委員会などで話題になったことなどを元に、よくある質問と回答について10個とりあげてみます。
1. スプリントミーティングの長さの目安は2時間なのか？
長くても有益である場合があります。プランニングミーティング・レトロスペクションミーティングが長くなる傾向は否めません。一般的なミーティング全般に言えることですが、「これは皆で共有する価値があるか」「これは皆で議論する価値があるか」を考えた上で、見極めを行います。
ディーバの場合、新しいメンバーの学習効果であったり、作る対象にまだ曖昧さが残っていたプロジェクトの前半では、皆が共有して考えることに特に有効であると考えられたため、全体ミーティングに多くの時間を費やしました。一方、プロジェクト後半では、各人が何をやっているかが阿吽の呼吸でわかってきたり、細分化された設計／課題に対して必ずしも全員で考える必要がない場面が増えてきたりしたため、別ミーティングで設定するようになりました。
2. いつ設計するのか？プランニングミーティングで設計するのか？
プランニングミーティング時点では、タスクの工数を見積もることが必要なので、基本的にはそれまでに必要な設計を行っておく必要があります。一方、アジャイル開発では事前に詳細設計を先行しないとも言います。
これはYesかNoかではなく、何を実装するかでバランスが変わってきそうです。会計システムでの税金の計算など、始めから仕様にブレのない実装については、トップダウンで事前に詳しく明示的に設計されている方がよいかもしれないですし、フレームワークよりで開発者裁量の大きい実装については、荒い要求レベルで済むかもしれません。必要に応じて前のスプリントで設計のみのタスクを設けるのがよいでしょう。ここは何をドキュメント化するかということとも関係します。
3. 気がついたらスプリントを工程で切ってしまったがよいか？
スプリントを導入しても、設計、実装、単体テスト、結合テストとタスクを分割していたのでは、それはミニウォーターフォールであり、逆に管理工数がかかったり品質が下がったりするかもしれません。やはり継続的統合やテスト駆動開発などの技術的エッセンスが含まれて、初めて繰り返し開発が意味を持ってきます。
技術と管理はアジャイル開発の両輪をなすものであり、優先順としてはまず技術的な視点が必要となり、それから（スプリントなどの）管理的な視点へと変わってくるでしょう。ただ、間接的なタスクになるほど手動の工程が残ることは確かなので、一様に両輪が完全である必要はないでしょう。
4. プランニングするタスクはどこまで含めるか？
原則として、すべての活動をタスク管理システム上に登録します。ミーティング、セミナー参加、有休予定なども含めます。あと、忘れずに入れておきたいのが、中身は予想できないけれど発生するバッファタスクです（ディーバではアドミンタスクと呼んでいます）。「いつも予想できないタスクでこれくらい取られる」ことを事前に想定し、スプリントごとに予定バッファ時間を設定します。例えば、週40時間のうちの8時間はアドミンタスクにします。タスク管理システムは作業実績時間を入れることもできるので、日報としての役割も果たせますが、その中でバッファをどれくらい消化したかで、次のスプリントでどれくらいバッファを設定しなければいけないかが見えてきます。
これらによって、常に皆の予定タスク時間が同じ時間（例えば40時間）になるように設定されます。すべての活動を記録することで、実際どの程度間接的なタスクに時間を取られているか、どの程度自身でコントロールできない時間があるかを把握できるようになります。
ディーバでは日米で同じスプリントを回していたことがありました。その時に意外に考慮が必要だったのが、国民の祝日でした。最終的には、タスク管理システムに祝日も含めて管理を行い、どちらの国で働くメンバーであっても予定作業時間の総計が10daysになるようにしました（余談ですが、日本人は有休消化が少ないと言いますが、祝日は意外と他国に比べて多いようです）。
5. タスクの終了基準が曖昧になってしまわないか？
アジャイル開発では、設計書はあまり書かず、テストコードは書きますがテスト仕様書は書かないため、何を持ってタスクの終了を判定するのかが曖昧になりがちという指摘があります。
まずすべきことはコミュニケーションによって仕様を深く共有することです。コードレビューやテストコードレビューを節目節目に入れたり、ペアプログラミングといった手法を取るのもコミュニケーションの1つとして位置づけられます。ただ、仕様決定者がコードを書かない人物であり、かつ、デモだけでは仕様の実現性を網羅しきれない場合も当然あります。業務アプリケーションでは顕著かもしれません。この場合、設計書・テスト仕様書を書くことが現実的に必要になってくるでしょう。どのタスクにおいてどのドキュメントを利用するか、スプリントのタスク設定時に明確にされていれば良いのではないかと思います。
6. タスクは担当制で、皆で共有するほどではないのだが？
短期的には、担当者ごとに開発領域を割り当てた方が効率的です。しかし、少しの非効率さがあってもメンバー間での担当をオーバーラップさせていく方が、長期的に柔軟で協力的なチームになっていきます（ただ、同時に各領域（機能）に「第一人者」を置くことも悪くない案です。領域内の統一感や最終的なチェック機能を持たせることができます）。管理者がスプリントごとのタスク割り当て時に意図的に担当を変えることを心がける必要があります。
7. スプリントに予定したタスクが終わりきらなかったらどうするか？
スプリントを導入したとしても、問題が発生し予定したタスクがすべて終わりきらない「遅延」が発生することがあります。その場合でもスプリントの終了日時は変更せず、結果として次のスプリントに繰り越されることになります。次のスプリントで割り当てが可能な新しいタスクは当然減り、結果的にリリースまで影響するかもしれません。
第3回で説明したように、リソース、スケジュール、スコープのいずれかに手を入れられる余地を残しておく必要があります。例えば、下記のような対応が必要となります。
- バックログの優先度を明確にし、特にリリースにMustなものを最低限に抑える。一方でNice To Haveな機能もリストする
- リリースまでのスプリントのうち、1つ～2つ分ぐらいはバッファとして設定する
- リリースまでのすべての機能をコミットすることはせず、不明瞭な部分は不明瞭であることを共有する
アジャイル開発に関するウェブサイトや書籍の情報は、最近とても充実しています。特に今回の内容についてピックアップするとしたら、次の2点をお勧めします。技術的な内容にはほとんど触れていないので、さまざまなバックグラウンドを持つ方におすすめできます。
- 『アジャイルソフトウェア開発スクラム』ケン・シュエイバー、マイク・ビードル 著、ピアソンエデュケーション、2003年9月
- 『アジャイルな見積もりと計画づくり』マイク・コーン 著、毎日コミュニケーションズ、2009年1月
