第3回　選択される開発内容

はじめに

本連載では、「⁠透明性」というキーワードで、アジャイル開発について説明してゆきます。前回は、開発者が顧客に対して透明性を提供することの重要性について解説しました。その一つの大きな手段として、継続的かつ頻繁なリリースを取り上げています。しかし、部分的に出来上がった画面を見せられて、顧客は何ができあがっていて、何が不足しているのかをどのように判断すれば良いのでしょうか?それを判断する為には、事前に今回のリリースで何を開発し、何を開発しないのかについて、顧客自らが選択し、意思決定しておく必要があります。第三回目の今回は、このような顧客による開発内容の選択の意味について、整理してみたいと思います。

ストーリーについて

一般的なウォーターフォール型のソフトウェア開発では、まず要求仕様を整理し、そこから機能を洗い出します。要求仕様は、顧客の言葉で表現された、利用する側からみたソフトウェアの振る舞いです。対して、機能はソフトウェアの内部構造や仕組みであり、開発者側からの視点でシステムを描き直したものとなります。

そして、タスクの洗い出しや担当の割り当て、進捗の管理といった作業には、後者の機能を単位とすることが通常です。例えば、機能一覧を元に WBS とガントチャートを描いて開発の進捗を管理する、といったやり方です。

このようなやり方をとった場合、要求仕様から洗い出された機能一覧は、開発工数を十分に予測できる程度にまで詳細化されています。顧客にとっては、各項目の必要性を判断することが困難な一覧となります。

アジャイル開発を適切に進めるには、顧客に開発の状況の透明性を高めることが大切です。進捗の管理に、顧客が中身を把握できない機能一覧を利用することは好ましくありません。そこで、システム用語で記載された機能ではなく、顧客の用語で書かれたストーリーを単位として開発を進めることになります。

ストーリーとは、ソフトウェアの振る舞いを簡潔に表したものです。以下に例を示します。カード一枚に記載できる程度のボリュームです。

アジャイル開発で想定されるストーリーの使われ方は以下の通りです。ソフトウェアに必要な振る舞いをストーリーとして洗い出します。各ストーリーに依存関係は無いので、顧客はその中から次のイテレーションで実装するストーリーを選びます。通常、最も必要なストーリーから順に選択します。開発者は、選択されたストーリーを優先度を意識しながら実装していきます。

方法論により、ストーリーに該当する概念の名称や位置づけ、記載内容に違いはあります。しかし、顧客が自らストーリーを(間接的にせよ)選択するという点では変わりありません。この顧客にとってのストーリー選択の自由こそが、アジャイル開発の柔軟性の最大のメリットとなっています。

その為にも、ストーリーは依存関係が無く個別に選択可能であり、顧客が理解できる用語で記載されていなくてはなりません。

ストーリーの難しさ

顧客の理解できる言葉でかかれたストーリーを単位とすること、そして各イテレーションにおいては選択されたストーリーを実装対象とすることをご説明しました。

しかし、実際に試してみると、顧客に理解できる用語で、依存関係なくストーリーを杓子定規に記述することは、実はかなり難しいことが分かります。

例えば、コネクションプールの仕組みを DAO に組み込む作業が発生したとします。どのようなストーリーで表すでしょうか?

このように、各振る舞いに共通の内部処理は、外部の振る舞いとしては見えにくいものがあります。顧客にその作業の影響範囲や必要性を適切に示すことがちょっと難しくなります。他にも、セキュリティ関連の実装といった、非機能要件への対応等もストーリーとして記述しにくいものとなっています。

表現しにくいからといって特定のストーリーの中に含めてしまっては、ストーリー間に依存関係が生まれる可能性が高まります。またストーリーが肥大化し、イテレーションに納まらなくなるかもしれません。

これらの解決方法は単純に一通りではありません。

大切なことは、顧客が判断可能なものにすることです。そしてイテレーションに十分に収まる程度に小さく分割されていることです。もし顧客が判断可能な内容であれば、ストーリーの一つとして挙げてしまって構いません。工数が小さいものであれば、一塊りにした別のストーリーをしてもよいですし、最も関連の強いストーリーに含めてしまっても良いでしょう。

個別にストーリー化しなくてはならないような機能でしたら、そこの実装はコストがかかるという意味で、顧客とっては重要なリスクです。きちんと時間をとって説明するのが開発者の責任です。

特に、イテレーション期間が短い場合、ストーリーが限りなく細分化されることがあります。そのような時にはより機能やタスクに近いストーリーが発生することになります。

例えば、"メール送信機能" というストーリー名称は OK でしょうか? NG でしょうか?

ここでの目的は、顧客が開発の状態を把握できるように透明性を高めることです。つまり、顧客がメール送信機能といったときに処理の内容を想像できればよく、誤解を与えたり、どの部分まで含むのか判断に迷うようではだめです。その為、開発者側からあげたストーリーについては、十分説明をすることが大切です。

ストーリーを優先順位付けする

これまで見てきたように、顧客は自分が理解できる言葉で、ソフトウェアのストーリーを一覧にすることができました。アジャイル開発の特徴は、このようなストーリーのリストを常時編集できる点にあります。逆に実装に入る前に、全てのストーリーを詳細に分析しておく必要はありません。直近のイテレーションで実施する作業について、詳細化できていれば十分です。

それでは、具体的にどのようにしてストーリーを管理すべきでしょうか?比較的前衛的なアジャイル開発手法では、ストーリーをカードに書いて、開発者の部屋に貼りだすことが推奨されています。顧客も同じ部屋でカードを共有します。

しかし、顧客と同じ部屋で同じカードを共有できる環境は、やはりレアケースです。ツールを使って、オンラインで共有できるようにするとよいでしょう。具体的には、Trac や Redmine 等のチケット管理ができるツールです。おもなチケット管理の機能としては、作業をチケットとして登録し、担当割当・作業中・確認待・完了済等といった状態管理やカテゴリ別の分類、レポートの表示等があげられます。ストーリーをチケットとして登録するような使い方をするのですが、もちろん、ただの Excel のシートにストーリー名を列挙する方法でも構いません。

ツールの使い方のポイントとしては、顧客が優先順位付けをできるようにすることです。

優先度が高・中・低といったカテゴリ分けの管理方法では、顧客は十分に優先順位を意識することができません。また順位をチケットに記入する方式では順番の入れ替え作業が煩雑になってしまいます。並び順のように、同じ優先度が存在しない状態を維持することが推奨されています。

しかし、あくまでツールの使い方に過ぎません。現実的には、何をイテレーションに入れるのかは、顧客と開発者との間で十分にコミュニケーションを取って決定すべきです。

顧客にとっての優先順位づけとは、割り当てたストーリーは全て消化されるわけではないので、より欲しいものと欲しくないものとを選択するという意味があります。つまり、

・予想より早く終わる可能性もあるので、多めにストーリーを割り当てておく必要がある。
・予想より時間がかかる可能性もあるので、割り当てたストーリーが全て消化されるとは限らない。

という状況を作り出すことです。

そのリスクを認識してもらい、予定からの変動分の調整方法を顧客と開発者の間で合意を取っておく必要があります。その為のシンプルな手法として全てのタスクを優先順位順の並べ換えをし、優先順位の高いものから実装するというルールを用いているにすぎません。裏を返せば、変動分の調整方法さえ顧客と合意が取れていれば、無理に優先順位を厳密に管理する必要はありません。

進捗管理方法

このように、ストーリーをイテレーションに割り当てる方法は分かりました。それでは、イテレーションに割り当てられたストーリーの消化状況を、どのようにして顧客に見せるのでしょうか?具体的には進捗報告の方法となります。

ここでのポイントは、ストーリー毎の進捗率は出さないという点です。なぜならば、

進捗率が実際の残時間を正確に表わさない
進捗率の算出にかかる工数は削減したい

からです。いずれにしても、ソフトウェア機能に 80% の完成はありません。完成したか、未完成かのどちらかです。

顧客との信頼関係を維持するという意味でも、開発者は顧客をミスリードするような数値は出すべきではありません。ストーリーの状態から機械的に算出できる完了ベースの報告をするのが良いでしょう。つまり、予定していたストーリーのうち、どれとどれが完了したのかだけを達成度合いの数値に含めるやり方です。

この辺りの詳細は、やはり方法論によりまちまちです。例えば、FDD のようにプロセスでストーリーの消化に必要なマイルストーンを定義してあり、マイルストールのクリアをもって進捗とするようなものもあります。また、スクラムのバーンダウンチャートのように、ストーリーの見積もりを随時改定し、残所要時間で管理するやり方もあります。いずれにせよ、仕掛り途中の進捗の測定が、工数がかかるわりには恣意性が強く無駄な管理コストを削ろうとした結果、削減対象の作業とみなされるという点では共通しています。

実際に要した作業時間をトラッキングしないという特徴も共通です。

なぜこのようなやり方をとるのでしょうか?

完了予測をして、それの遵守で評価がされるとした場合、完了予測には不測の事態に備えたバッファを上積みするのが通常でしょう。アジャイル開発では個々のタスクに対するそれらのバッファは無駄だと考えられます。見積りバッファは、全体で一つあればよく、個々の見積りは50% の確率で前倒しとなり、50% の確率で遅延するような、本当の予測値を使うべきです。

前倒し分と遅延分とで相殺しあうような、予実の変動を許容し、バッファを廃したギリギリの見積りを開発者から引き出す為には、実績のトラッキングから解放する必要があります。

そして、開発リスクの管理には、結果ベースの残作業時間があれば十分なのです。

顧客の手に軌道修正のハンドルを

これまで、顧客の視点でストーリーを切り、その進捗をストーリーの完了度合いで報告するやり方を説明してきました。

その根底には、予測よりも、軌道修正を重要視するという思想があります。

ケント・ベックは、この作業を自動車の運転に例えました。つまり、目的地に車体を向けて、アクセルを踏むだけではいけません。ハンドルを握り、常に細かい微修正を繰り返しながら、車を進めることが必要なのです。

顧客がストーリーを管理する = 細かく軌道修正する。これこそが、アジャイル開発のパラダイムの転換であり、アジャイル開発が上手く機能する秘訣でもあります。その為には、タスクの一覧、進行中のタスクと、完了予測時期等といった軌道修正に必要な情報の開示が欠かせません。顧客自身が、それをリアルタイムで把握し、リスクを管理できる仕組みを整える必要があります。それこそが顧客に対して、開発の透明性を高めるという意味なのです。