プロジェクトのループと4つのスキル

本連載で言及するアジャイル開発者の4つのスキルはプロジェクトのループを正しく「1周」させるためのスキルです。それぞれのスキルとループ構造との関わりを順番に説明します。ここで説明するのは，プロジェクト全体レベルでの適用についてです。

ストーリの作成

ストーリの作成は，プロジェクト全体レベルのループの出発点です。ソフトウェアへの要求を，ユーザ価値の視点から，ユーザの語彙を使って数行の文章で記述したものがストーリです。たとえば「閾値ベースの通知対象者選択機能を実装する」ではなく「設定された閾値を越えている対象者を一覧から選択して通知できる」といったようにです。

ストーリそのものに詳細を含める必要はありません。必要に応じて補足するドキュメントや仕様書を用意して対応します。

ストーリは受け入れテストと対をなします。ストーリは，受け入れテストを書くことができ，受け入れテストに成功すれば「正しく」ソフトウェアが作られていることを検証できるような記述を心がけます。アジャイル開発者の腕の見せどころです。

テスト駆動開発（TDD）

プロジェクト全体レベルでのTDDは，ストーリに対する受け入れテストの定義（と実行）です。受け入れテストには2つの役割があります。

• ストーリが実現できたことの検証手順
• 作業のゴール

テストを定義する際には，文字通り「そのテストが作業のゴールであり，そのゴールへ向かって開発が駆動されていくこと」を念頭に置いてください。

すでに述べたとおり，具体的な開発作業はストーリをタスクに分割して取り組みます。タスクの分割は「受け入れテストに成功するためには何をすればよいか？」という視点から行います。タスクを分割しきれたかどうかを判定する質問は，「⁠分割したタスクをすべて完了させれば，受け入れテストに成功できるか？」です。

受け入れテストの自動化

受け入れテストの実行は，必ずしもすべてが自動化されている必要はありません。誤解されていることも多いのでここで補足しておきます。現場での受け入れテストは，自然言語で書かれた文書（注5）であることも多いです。

TDDではテスティングフレームワークの利用を強調するので「テスト実行の自動化」が注目を集めがちです。しかし，開発対象のソフトウェアの特性や受け入れテストのケースによっては，実行を自動化するためのコストが非常に大きいものもあるからです。

実行の自動化は重要な要素ですし，取り組む価値のある課題ですが，TDDの本質ではありません。繰り返しますが，TDDの本質は「そのテストを書くことが開発を駆動するか？」を問い続けることです。

リファクタリング

プロジェクトは1回のループでストーリの実現に必要な作業を行うわけですが，その作業全体を通してリファクタリング――システムの振る舞いを変えずにソフトウェアの設計を洗練させる――を行います。

ユーザ価値とリファクタリング

リファクタリングは，プロジェクトのループを継続させていくうえで必要な作業です。しかし，リファクタリングはユーザ価値を提供し続けるために基盤としてこの上なく大事なものではありますが，ソフトウェアの振る舞いは何も変わらないので直接的にはユーザ価値を提供しません。

ですから，リファクタリングが直接ストーリとして表現されるのはよほど特殊な例外的状況にあることを心得てください。ユーザ価値を提供するストーリと関連させたタスクとして，日常的継続的に少しずつコツコツと進めていくのがリファクタリングです。

リファクタリングの手順を実践できることもアジャイル開発者として必要なスキルですが，どうやってプロジェクトの日常的な作業に組み入れていくかの作戦を考えられることは，さらに重要なスキルです。

計画づくり

計画づくりは，プロジェクトの各回のループがリズムを持って正しく回転するように定めるプロセスです。計画づくりでは，どのストーリをどういった順番で実現していくのかを，ストーリの見積りを踏まえたうえで，タイムボックスに収まるようにビジネス的な優先順位に従って決定します。

アジャイルな開発スタイルと従来型の開発スタイル（いわゆるウォーターフォール型）との比較に，「⁠アジャイル VS. 計画駆動」という図式がよく用いられますが，アジャイル開発も計画を重視します。

後述しますが，アジャイル開発ではさまざまなレベルで計画づくりを行います。計画づくりを実施する頻度は，一般に計画駆動と呼ばれている開発プロセスよりも格段に多くなります。

計画に対する両者のアプローチの違いは，状況に応じた計画づくり（プランニング）を重視するか，立てた計画（プラン）を予言として絶対視するかです。「⁠プランニング重視（アジャイル）VS. プラン重視（計画駆動⁠）⁠」と考えたほうが実態に即していると思います。

計画と見積り

計画づくりにあたっては，ストーリやタスクを見積る必要があります。アジャイル開発での見積りは作業量の相対サイズで行います。

見積りについて言及すると，この連載の枠の範囲を大きく逸脱してしまいます。ここでは見積りについてのヒントを一つだけ紹介します。あなたが「見積り」と「コミットメント」と「ターゲット」の違いについて説明できないようであれば，今すぐ『ソフトウェア見積り』（⁠注6）を読んでください。

注5）

受け入れテストはプロジェクトの進行とともに変化していくので，私の周囲では保守しやすいようにWikiに書くことが多いです。

注6）

『ソフトウェア見積り ― 人月の暗黙知を解き明かす』（⁠Steve McConnell（著⁠）⁠，田沢 恵／溝口 真理子（訳⁠）⁠，久手堅 憲之（監修⁠）⁠，日経BPソフトプレス）