業務用かどうかに関わらず、ソフトウェアの開発ではユニファイド・プロセスが重要であると考えます。ユニファイド・プロセスはAgileやScrum、Extream Programming等と相反するものではなく、ユニファイド・プロセスがカスタマイズされたものであると考えられるからです。元来、ユニファイド・プロセスはプロジェクトや組織によってカスタマイズされることを期待しており、適切なカスタマイズは、ユニファイド・プロセスの導入効果を最も発揮する重要な手法です。 業務用ソフトウェアの場合、このプロセスの単位は大小さまざまであると考えます。大きなひとつの構築プロセスと小さな改修プロセスや機能追加プロセス、技術検証プロセスなどが同時に推進していくことの方が多く、構築がひと段落してから第2フェーズの機能追加、バグ改修といった”裕福な”プロジェクトはそう多くはありません。多くの場合、運用しながら並行して機能追加や既知の潜在バグ改修といったプロジェクト推進が求められます。 このような形態のプロジェクト推進に対応しやすいと思われるのがAgile Unified Processです。Rational Unified Processを簡素化したAgile Unified Processは、規律をベースとするプロセス推進法であり、 Test-Driven Development (TDD)やAgile Modelingなどを含み、それらの作業を簡略化するツールの使用が推奨されています。Agile Unified Processは、大小さまざまな各プロセスの規律がイテレーション後に充足、改修されながら確立されていくため、最初に試験的なプロセスが必要となります。 […]
・ユニファイド・プロセスとPLM、ALM 前回作成したブランチとマージの仕組みはProduct Lifecycle Management（以降「PLM」）とALMに登場する成果物の管理の枠組みに過ぎません。この枠組みに則って成果物のバージョンを管理していく必要があり、たとえば文書管理であれば、ALMやPLMの役割は下図のようになることを提案しました。 文書定義の役割分担 文書管理においてPLMとALMの管理を完全に切り離し、ALMの管理のみをTFSで行うことでソースと文書のバージョン管理を同期させることを計画しました。ALMの管理機能は、バージョン管理、進捗や人員リソースの管理、品質管理、ビルドやリリース管理、変更管理や追跡などがあり、これらすべての運用を定義する必要があります。まずバージョン管理については、メジャー、マイナー、リビジョン、ビルドのそれぞれのインクリメント・ルールとして、新機能（メジャー）、機能拡張（マイナー）、バグ修正（リビジョン）、ビルド（リファクタリング）という標準的なバージョニングを採用しました。この際、シェルブとチェックインをロールごとに使い分けるように計画しました。 コミットのワークフロー チケット（TFSでの呼称は「ワークアイテム」）のステータス管理やロールについては、次項「プロセスを社内のワークフローに落とし込む」に詳細を解説しますが、ワークフローの最後のロールである「ビルド管理者」（おそらくは開発責任者）が、すべてのチケットのステータスを管理する点が重要です。このロールこそがアプリケーションのバージョンをコントロールするロールと言えます。 このロールに必要な知識として、プロセス定義の手法があります。バージョンのインクリメントに対する管理プロセスを策定するうえではCMMI（定義済みプロセスの定着を目的とした能力成熟度統合手法）、Scrum（少人数におけるコミュニケーションを中心としたスプリント推進によるプロセス確立手法）、Agile（ウォーターフォールを細分化したイテレーションによる柔軟なプロセス確立手法）がありますが、今回の提案ではAgileでTFSのインストールを行うことを提案しました。提案先の企業では、明確な開発プロセス、管理プロセスが確立されていなかったため、試験的なプロセスを策定し、それを繰り返しによって微調整しつつ確立する必要があったからです。 この試験的なプロセスを充足、改修することを目的とした微調整であることはチーム全員に周知する必要があります。開発者にとってもより良いプロセスを確立するために試験的なプロセスを行っているのであり、開発者のフィードバックが次のイテレーションの試験的なプロセスになるので、同じプロセスを繰り返すのであれば、確立されたプロセスに対するCMMI方式に移行する必要があると考えたからです。 試験的なプロセスは、ユニファイド・プロセスに則って策定しました。業務用ソフトウェアの開発ではユニファイド・プロセスに則ってAgileのイテレーションを計画すべきと考えたからです※：コラム「Agile Unified Process」参照。 ユニファイド・プロセスは、オブジェクト指向開発誕生以前からソフトウェア開発手法として確立されていたいくつかの手法をオブジェクト指向開発に適した形に統合した反復型開発手法です。これにはUMLなどオブジェクト指向から生まれた図での表現なども含まれますが、それらは組織やプロジェクト、ソフトウェアに適した形でカスタマイズされること（この場合変形ではなく、ユニファイド・プロセスの各要素の取捨選択）を期待されており、ユニファイド・プロセスという明確に定義されたプロセスがあるわけではありません。もっとも有名な実体化されたユニファイド・プロセスはラショナル・ユニファイド・プロセスです。