AI時代の開発プロセス考

Unified Process（UP）は、モデルを中心とした技術体系になっています。 まずモデルを作成し、そのモデルをプログラムに落とし込んでいくことが前提となります。

要求モデルや設計モデルは、UPにおいて設計判断や実装方針の基準として用いられます。 プログラムはそれらを具体化した成果であり、モデルの意図と整合しているかどうかが確認の対象となります。

このようにUPでは、意味や構造をモデル側で確立したうえで実装に進むことが、プロセスとして前提とされています。

UPの大きな特徴の一つは、プロジェクト管理の枠組みがフェーズとイテレーションの二重構造になっている点です。 フェーズは、インセプション、エラボレーション、コンストラクション、トランジッションの四つに分かれています。

フェーズは単なる工程区分ではなく、「次の段階で何を重視し、何を確定させるか」を切り替えるためのメタ構造です。 フェーズの進行に伴い、要求の精度、アーキテクチャの安定度、完成度の重心が変化していきます。

また、UPにおけるイテレーションは、単なる作業の反復ではありません。 各イテレーションは、その時点で得られた知見を踏まえて、「次をどう進めるか」を再設計する単位として位置づけられています。

このようにUPでは、変化を日々の作業に直接持ち込むのではなく、フェーズやイテレーション計画というメタレベルで受け止め、整理する仕組みが用意されています。

Unified Process（UP）は、CBD (Component-Based Development)を前提としたプロセスでもあります。

UPでは、サブシステムやコンポーネントといった単位で責務を分割し、それぞれに明確な境界を与えることで、変更の影響範囲を制御しやすくすることを重視します。

CBDは、設計や実装の技法というだけでなく、プロセス上の重要な意味を持ちます。 コンポーネントの境界が定まることで、どこまでが変更可能で、どこからが安定領域なのかが明確になります。

UPでは、このような境界を比較的早い段階で意識的に設計し、以降の開発を安定させる土台とします。

UPにおけるユースケースは、単なる要求記述ではありません。

ユースケースは、工程全体を貫く軸として利用されます。

これにより、開発の各活動は「どのユースケースを実現するためのものか」という意味づけを持つようになります。 工程管理においても、タスクの消化ではなく、ユースケースの実現状況を基準に進捗を把握することが可能になります。

Unified Process（UP）は、反復的かつ漸進的な開発を前提としています。

UPにおける反復は、分析・設計から実装・テストまでを含む小さな開発単位を繰り返す進め方として定義されています。

これは、工程を一方向に流すのではなく、実装してみなければ明らかにならない技術的・構造的な要因を早い段階で把握することを前提とした設計です。

反復は、こうした要因を工程の後半に持ち越さず、開発の初期段階から顕在化させるための基本的なメカニズムとして位置づけられています。

UPにおける漸進は、最初から完成形を目指すのではなく、開発を進めながら成果物の内容や精度を段階的に確定させていく進め方として定義されています。

要求、設計、アーキテクチャといった要素は、初期段階では暫定的な形で置かれ、反復を通じて徐々に具体化・安定化されていきます。

漸進は、開発の初期段階で全体を確定させることを前提とせず、判断を段階的に積み上げていくための基本的な進行原理として位置づけられています。

UPでは、アーキテクチャが意思決定の中心に据えられます。

アーキテクチャは単なる構造図ではなく、以降の設計や実装の選択肢を制約し、方向づける基盤です。 早い段階でアーキテクチャを確立することで、後戻りのコストを抑え、開発全体の安定性を高めます。

この「アーキテクチャ中心」という考え方は、機能の網羅性よりも構造的な健全性を優先する姿勢を表しています。

Unified Process（UP）の根底にある考え方の一つが、リスク駆動です。

UPでは、作業の優先順位を決める際に、単純な機能順や作業量ではなく、技術的・構造的なリスクの大きさを重視します。

フェーズ構成そのものも、「どのリスクを、いつ、どの段階で低減するか」という視点から設計されています。

これにより、問題が後半で顕在化して破綻するのではなく、早い段階で不確実性を顕在化させ、対処することが可能になります。

ここまで見てきたように、Unified Processは、企業向けの大規模開発から単発のWebアプリケーション開発まで、さまざまなスケールや目的のプロジェクトを想定して設計されたソフトウェア開発フレームワークです。

フェーズ、イテレーション、アーキテクチャ、ユースケース、リスクといった要素は、開発の進め方や判断の粒度を構成するための機能セットとして整理されています。

Unified Processは、これらの機能を組み合わせることで、プロジェクトの規模や性質に応じた開発プロセスを構成できる枠組みとして位置づけられます。

UPは、UML (Unified Modeling Language)で記述したオブジェクト・モデルを一次情報として作成し、モデルから派生する成果物としてプログラムを位置づけています。

一方、アジャイル開発では、プログラムが一次情報となっており、プログラム主導の開発プロセスになっています。

モデル主導とプログラム主導。この点がUPとアジャイル開発の決定的な相違点といえます。

この特徴点が扱っているのは、変化や不確実性をどのレベルで整理し、判断に反映するかという点です。

UPはフェーズとイテレーションの二重構造を持ち、開発全体の重心はフェーズで切り替えつつ、個々の検証や前進はイテレーション単位で行います。 変化は主に計画や再設計のレイヤで整理されます。

一方、アジャイル開発ではフェーズのような上位構造を持たず、イテレーション（スプリント）の中で直接変化に対応します。 両者は同じ課題を扱いながら、柔軟性を発揮するレイヤが異なっています。

この特徴点が扱っているのは、変更の影響範囲をどのような仕組みで制御するかという点です。

UPでは、コンポーネント指向が開発プロセスにあらかじめ組み込まれています。 境界は早期に定義され、以降の変更は原則として局所化されます。

一方、アジャイル開発では、コンポーネント境界の定義や安定化はプロセスとして必須には規定されておらず、開発者やチームの判断に委ねられます。

この特徴点が扱っているのは、作業を何によって意味づけ、どの単位で管理するかという点です。

UPでは、ユースケースが工程全体を貫く管理単位として用いられ、要求、設計、テスト、進捗管理が結び付けられます。

アジャイル開発では、バックログを起点として、ユーザーストーリーやタスクへと分解しながら作業を進めます。 両者は同様の問題意識を持ちながら、粒度や表現方法の異なる手法を採用しています。

この特徴点が扱っているのは、反復によって何を前進させるかという点です。

UPでは、反復は理解や構造を成熟させ、不確実性を減らすための手段として位置づけられます。 成果は、構造の明確化やリスク低減として評価されます。

アジャイル開発でも反復は重要な前進の手段ですが、主に動く成果物とフィードバックを通じて進められます。 違いは、反復を運用するレイヤと評価の観点にあります。

この特徴点が扱っているのは、構造をいつ、どの程度まで確定させるかを、プロセスとしてどこまで担保するかという点です。

UPでは、アーキテクチャが意思決定の中心として位置づけられ、早期に確立することがプロセス上の要請となっています。

アジャイル開発では、アーキテクチャ中心という立場は必須ではなく、構造の確立は実践やリファクタリングを通じて段階的に行われることが想定されます。

この特徴点が扱っているのは、何を優先して取り組むかという判断基準の置き方です。

UPでは、技術的・構造的リスクを明示的に優先し、フェーズ構成自体がリスク低減戦略として設計されます。

アジャイル開発では、ビジネス価値やフィードバックを主な判断材料とし、実行の中で顕在化したリスクを逐次扱っていきます。