前回のエントリでは、ソフトウェアは二種類あると述べましたが、これは正確ではありません。
ある程度の規模以上のソフトウェア（システム）は、時間やユーザにより変化する部分と変化しない部分の二面を必ず含んでいます。例えばWebのECサイトの例で考えると、利用者が使うWebの画面で提供することは、扱うモノや使い勝手の向上など高い頻度での変化がありえます。別の側面では、何らかの手段で決済処理は必須ですが、システム構築に先駆けてその手段（どこかの決済代行サービスを利用する等）が確定していることは少ないでしょうし、サービス開始後になんらかの理由（例えばよりコスト面で有利な別のサービスがあった）で変更せざるを得ないことも十分に考えられます。
それに対し、Webなどのユーザインタフェースを介して直接エンドユーザに利用され、何らかの手段で決済や商品の流通がなされるという本質的なサービス／システムの目的は変化しません。社内の経理システムを作ったのに、突然ある日からコンシューマ向けの占いサイトにしたい、なんてことはないんです。
こういった変化しない部分は機能要件によって決まるものではなく、目的を達成するためにおのずと導かれる非機能要件に基づいており、一般的にシステムアーキテクチャと呼ばれるものがこれにあたると考えることができます。基盤となる技術（例えばJavaなどの開発基盤技術やSOAなどコンポーネント技術）やミドルウェア、ソフトウェアフレームワークが要件定義に先行してプロジェクトの開始時点で決定し、構築（開発）されるのはウォーターフォールなプロジェクトでは一般的ですね。
どのようなシステムでもこの二面を持つ、ただそのシステムの特性によって変化する部分と変化しない部分の比率が大きく異なるだけです。小規模のシステムで非機能要件も厳しくなければ汎用的なミドルウェアやソフトウェアフレームワークをそのまま利用し、ソフトウェア開発のほぼ全てが変化する部分の開発に当てられます。昨今のシステム、特にWebアプリケーション（サービス）の多くがこの傾向にあり、アジャイル開発プロセスを採用することでより高い効果を上げる（価値を生み出す）ことができると考えられます（ただ、こういったシステムの場合はそもそも開発プロセスなどなくてもそこそこ動くものは作れちゃいますが・・・）。
一方である程度以上の規模のシステムになると自らアーキテクチャを設計する、構築することが必須になってきます。汎用的なフレームワークの組み合わせだけでは十分ではなく、それらをベースに必要な機能を作り込み余計なものをそぎ落として独自のフレームワークを構築したり、場合によっては専用のミドルウェアを開発するようなこともあるでしょう。専用とはいわないまでも汎用のミドルウェアに必要な機能をカスタマイズ／チューンすることはメーカーが主導する大規模なシステムでは珍しいことではありません。
どのようなシステムにも変化する部分としない部分があるということを意識しなければなりません。残念ながらウォーターフォール開発プロセスを適用する多くのプロジェクトが、本来変化する部分すなわち機能要件は変化しない前提で開発を進めて、結果的に変化に追随できない問題を生んでしまいます。そしてそのしわよせが発注元のお客様（要件を定義できないのが悪いという発想）、あるいは開発先（要件を取り違えたのが悪いもしくは単にお客様との力関係）のいずれかにくることになります。
アジャイル開発プロセスが大規模なシステム開発には適用できないという一般論も同じ原因によります。単に人数の問題だけではなく、変化する部分と同じ視点で変化しない部分を捉えてはいけないのだろうと思います。
ではどのように捉えて取り組んでいけばよいか、また機会を改めて考えていきます。
hogehoge
hugahuga
12月 192008