コラム：Agile Unified Process

業務用かどうかに関わらず、ソフトウェアの開発ではユニファイド・プロセスが重要であると考えます。ユニファイド・プロセスはAgileやScrum、Extream Programming等と相反するものではなく、ユニファイド・プロセスがカスタマイズされたものであると考えられるからです。元来、ユニファイド・プロセスはプロジェクトや組織によってカスタマイズされることを期待しており、適切なカスタマイズは、ユニファイド・プロセスの導入効果を最も発揮する重要な手法です。
業務用ソフトウェアの場合、このプロセスの単位は大小さまざまであると考えます。大きなひとつの構築プロセスと小さな改修プロセスや機能追加プロセス、技術検証プロセスなどが同時に推進していくことの方が多く、構築がひと段落してから第2フェーズの機能追加、バグ改修といった”裕福な”プロジェクトはそう多くはありません。多くの場合、運用しながら並行して機能追加や既知の潜在バグ改修といったプロジェクト推進が求められます。
このような形態のプロジェクト推進に対応しやすいと思われるのがAgile Unified Processです。Rational Unified Processを簡素化したAgile Unified Processは、規律をベースとするプロセス推進法であり、 Test-Driven Development (TDD)やAgile Modelingなどを含み、それらの作業を簡略化するツールの使用が推奨されています。Agile Unified Processは、大小さまざまな各プロセスの規律がイテレーション後に充足、改修されながら確立されていくため、最初に試験的なプロセスが必要となります。
この最初に提示するプロセスこそが、Rational Unified Processを簡素化したもので、この簡素化はプロジェクトや組織に応じた最初のカスタマイズのことを指します。
たとえば、アジャイル宣言における4つの価値のうちのひとつに「Working software over comprehensive documentation」というのがあり、要求仕様書や要件定義書を完成させてから基本設計に入るといったプロセスは必須ではなく、私の経験則上、要求仕様や要件定義を部分的にまとめながら基本設計を進めていくことが可能です。要求のほとんどは稼働プラットフォームに依存することなく、要求～基本設計までは、実装上の制約を受けるはずが無いからです。この一連の流れを機能別などに細分化し、イテレーションとして繰り返していく手法がAgile Unified Processの特徴です。これらの定義は結果的に要求仕様書や要件定義書、基本設計書になるかもしれませんし、設計メモやマインドマップになるかもしれません（どのように成果物を作成していくかは規律となります）。ただし、基本設計が部分的に終わった段階で詳細設計を進めるといったことはできません。これがAgileであり、Unified Processである所以だといえます。
もうひとつ重要な点は、全プロセスの規律は簡潔であり単純化されているということです。換言すると、簡潔に単純化できるほどに細分化されている必要があるということです。細分化された規律はソース管理ツールのチェックインポリシーやチケットに反映できます。つまり、プロジェクトに関与するメンバー全員のタスクが数量化でき、その消化率を管理することが重要であり、それらのタスクは「やらなければいけないこと」ではなく「できること」を主軸にしたWork Breakdown Structure（以降「WBS」）を策定できるPMが必要だということです。
この能力が不足しているPMの場合、この規律をガイドラインや規約などで明文化しようとします。ガイドラインや規約を作成すること自体に問題はありませんが、明文化では数量化ができないことに注意が必要です。明文化は、あくまで品質向上のアプローチのひとつです。これについても管理するならば、やはりチケットによる収束率など数量化して管理すべきであり、Agile Unified Processでは管理にツールを活用するよう推奨されています。結果的にプロジェクトがうまく推進できなかった場合に、タスクが数量化されてなく進捗管理ができなかったことに対する反省を行わず、プログラマーやSE、協力会社に責任を転嫁できるようにガイドラインや規約を前もって作成するSIerも少なくありません（あくまで日本の場合です）。