開発の現場「受託型アジャイルモデル」

最終回の今回はアジャイルモデルにおける開発ドキュメントを作成する上での重要なポイントを解説していきます。アジャイルモデルはソフトウェアの要件を最初にすべて決めるのではなく、開発を進めながら顧客の要望に柔軟に対応していくのが特徴です。そのため、顧客と開発業者が1つのチームとして、同じ場所で作業をすることが推奨されます。仕様決定者が常時プロジェクトに滞在しているため、要件の獲得や仕様の確認作業をスムーズに進めることが可能です。

しかし現実には請負という契約形態に縛られて、事前に要件の大枠を決めなければならなかったり、顧客と開発業者が別の場所で作業せざるを得なかったりするものです。そこで本記事では、このような場合を「受託型アジャイルモデル」と呼び、このモデルにテーマを絞って、開発ドキュメントを作成するポイントを考えていきます。

顧客との開発ベンダーとの間で、開発計画を合意する

アジャイルモデルでは、各イテレーション開発の直前に、顧客が重要だと判断した機能から開発を進めていきます。したがって、優先順位の決定が重要なポイントになります。優先順位を決めるためには、まず開発候補となる機能を明確にしなければなりません。また、それぞれの機能の開発に要する作業時間なども明確になっている必要があります。

アジャイルモデルは、こうした情報を常に顧客と合意し、共有していくことによって、各イテレーションの開発範囲のダイナミックな変更を可能にします。

通常のアジャイルモデルでは、仕様決定者である顧客がいつもそばにいるため、簡便な方法で開発範囲を明確にできます。簡便な方法の例としては、ストーリカードとタスクカードという2つのカードを使用する方法があります。ストーリカードとは洗い出した要件や機能の概要を記述したものです。タスクカードとはそのストーリカードに書いてある要件や機能を開発するために必要な作業と作業コストを記述したものです。エクストリームプログラミングの場合、それらのカードを使用して、今後のイテレーション開発でどのカードのタスクを行うかを話し合いで決めていきます。

それでは受託型アジャイルモデルの場合、開発業者は顧客とどのような手法で開発範囲を合意していけばよいでしょうか。

受託型アジャイルモデルの場合は、同じ場所での作業を前提とすることはできないため、通常のアジャイルのやり方では難しいでしょう。また作業場所が離れている顧客に対しても、開発範囲を相談できるようなドキュメントを用意し、それをコミュニケーションの材料として合意形成を行っていくことを考えていかなければなりません。当然、合意の手段にはメールが使用されることになりますので、ドキュメントはメール送信を前提として作成されるべきです。

ドキュメントの具体例としては、図1のように2つを用意するとよいでしょう。1つ目は、機能とその内容を洗い出したドキュメント（タスク一覧）です（図1上）。これは開発に必要なタスクと優先度および作業時間を顧客と合意するために使用します。

2つ目は、1つ目のドキュメントで定義されたタスクの実施状況を明らかにするドキュメント（状況管理一覧）です（図1下）。そのタスクがいつどのくらいのコストで完了したのかを開発ベンダーが記入し、タスクの完了確認を顧客が記入します。1行が1タスクに対応しており、毎回のイテレーション開始前にどの行の作業を行うかをチョイスしてから開始します。

開発状況がこの2つ目のドキュメントに蓄積されていくと、顧客も開発者もこのくらいの機能であれば、このくらいの費用（期間）があればできるということがだんだんと見えてきます。

アジャイルモデルでは、働きすぎ（週40時間以上）はよい結果を生まないという考えがあります。上記のように、顧客と開発者との間で開発スピードについての共通認識がもたれるようになると、無理のない開発ボリュームについての認識も共有され、各メンバーの作業時間の調整も容易になります。これにより、過剰な負荷がかかって開発者の集中力や開発効率が低下したり、ひいては疲労で倒れてしまって突発的な遅延が発生したり、といったリスクを低減することができます。もちろんこれは開発業者ばかりではなく顧客にとっても大きなメリットです。

これら2つのドキュメントを顧客と毎日共有することで、顧客の要求変更などに対しても前向きな対応が可能になり、よりアジャイルモデルらしい開発を行いやすくなるでしょう。 次のページ