パターンに基づくプロセス設計

前回のおさらい

前回はマイルストンの設定例として、ウォーターフォール型のプロセスモデルからはＶ字モデル、反復型のプロセスモデルからはスクラムを紹介しました。Ｖ字モデルやスクラム以外にも、Ｗ字モデル、ラショナル統一プロセス（Rational Unified Process）など様々なプロセスモデルが存在しています。ゴールにたどり着く道は１つではなく様々です。

プロジェクトの目的が変わってくれば、マイルストンの設定の仕方も変わります。こう言うと当たり前なのですが、実際のプロジェクトでは目的が異なるにも関わらず同じプロセスを採用している場合があります。これでは道に迷うのも仕方ありません。

本稿では、目的に応じてプロセスを設計できるようになることを目指しています。プロセスを設計すると言っても、何も無いところから考えるとなると難しいものです。そこで、プロセスのパターンをいくつかご紹介します。

分析→設計→実装→検証

図1はアジャイル界隈の有名人である平鍋健児氏のブログで紹介されていた図に少しばかり手を加えた図です。図1のサイクルは複雑な問題を解く場合に使うことができます。システム開発は問題解決を行うための手段の1つであり、図1のサイクルはシステム開発に限らず問題解決において適用できます。

図1のサイクルにおいては、解くべき『問題』が始めに存在します。問題は要求とも言えます。解決したいこと、満たしたいこと、つまりはゴールです。問題は時に曖昧であったり、複雑であったりします。例えば、システム開発において顧客からやってくる要求は、問題の本質をとらえていないことがあり、要求に従ってシステムを開発したが顧客の満足を得られないということがあります。この場合は、解くべき問題の設定を誤ったと言えます。

前回の喩えで言えば、「提示された写真と同じ角度から写真を撮影すること」が問題の本質ではなく、「人に喜びを与える写真をそろえた展示会をすること」が問題の本質により近いと言えます。解くべき問題を間違えると、問題は解消できません。確実に解消するために問題を整理して本当に解くべき問題を明らかにします。この過程を『分析』と呼びます。

「問題をなぜ解決したいのか？」「解決するとは何を目指すことか？」のように、「何？」「なぜ？」「何のため？」と問い続けます。これらの問いの答えを整理したものが『分析モデル』であり、分析の結果となります。

モデルとは、複雑な実体を特徴によって分解することで理解を助けるためのものです。例えば、プラモデルは、実物の形態のみを縮小してプラスチックにより造形し表現したものです。複雑な実体を表すためには、複数の表現形式を必要とします。形態を示すものがプラモデルだとすると、他にも動力系統や制御系統を示す回路図のようなものなども必要となってきます。分析モデルも同様に、問題（要求）を複数の視点から表現します。

分析を行った後に、分析モデルで定義された問題についての解法を考えます。この過程を『設計』と呼びます。設計では、時間、費用、技術、人員などのざまざまな制約の範囲内で、最も効率的に問題を解くことのできる方法を考えます。設計の結果が『設計モデル』です。

解法が決まったら実際に問題を解きます。問題を解くために解法を現実化する過程を『実装』と呼びます。実装と言うとプログラミングを想像しがちですが、現実化すること一般を指しています。例えば、「雨をよけるにはどうするか？」という問題について「傘」という解法を考えたならば、「傘をつくること」が実装になります。実装の結果として、問題の『解』が得られます。

そして、「得られた解が本当に問題を解決するのか？」を検証します。この過程を『検証』と呼びます。テストや試験と呼ぶことの方が多いでしょうが、より一般化して検証と呼ぶことにします。先の例で言えば、「傘」により「雨をよける」が可能なのか検証することになります。解により問題を検証した結果として、新たな問題が得られます。この新たな問題に対して、分析、設計と繰り返していきます。