プロセス志向はシステム開発プロジェクトのすすめ方にも影響を与えます。まず大きな観点として、プロジェクト規模という側面と開発工程という側面から見てみましょう。

最初のプロジェクト規模では、これまではかなり広い範囲を一気に導入するビックバン方式がとられる場合も少なくはありませんでした。ERPの導入などはこの方式の方が、無駄なインターフェースを作らなくてもいいとか、データ移行と整合性の維持が容易といった理由からよく行なわれています。

ただ、これだと非常に多人数のプロジェクトとなり。そのマネジメントが大変でそこの調整コストが甚大となってしまいます。その点、プロセス志向では、部分的、段階的導入がやりやすくなると考えられます。

プロセス志向というのは、プロセスがシステムの骨格を形成するということだから、広義の解釈ではSOAという概念の上に成り立っていると言えます。このSOAの考え方は、一度に全部のサービスを一斉に動かさなくてもよく、しかもサービスの挿げ替えが可能ということですので、ビックバンではない導入方式がとれるというわけです。

一方、開発工程というところを考えてみると、従来のウオーターフォール型の開発は減ってきたとはいえまだまだ行なわれているのではないでしょうか。とくに大規模になればなるほどこの方式になります。

このウオーターフォールというのは、最終的にはシステム化要件からきちんとプログラム仕様書を起こし、それに基づいてコーディングするというのが前提ですから、前回の開発編で述べたようにコードを書かないシステム構築になっていった場合は、おのずと限界があると思います。

ですから、プロセス志向のプロジェクトでは、ユーザ要求から、それを実現するためのプロセスを設計し、コンポーネントを組みたてて実装してしまうわけですから、テクニカルスペシャリストというより、業務をよく知った人が少人数で作り上げてしまうという形態がとれるのです。

実際には、ユーザのひととFace to Faceでテンプレートを見せながら、ああじゃないこうじゃないと言いながら、組み上げるイメージです。セル生産やイテレーションの要素が入ったものになります。そうしたアジャイル的なシステム構築となるはずです。

そうなると、プロジェクトメンバーで必要な人材は、ユーザの人たちとプロセスをつくっていくビジネスプロセスデザイナー（ビジネスアナリスト）、システム構成を考え、セキュリティや運用設計ができるITアーキテクト、そしてできたらデータ管理をするデータアドミニストレーターがいれば、プロジェクトが回せることができます。

そして、この構築段階のプロジェクトでは登場しませんが、部品やフレームワーク、アダプターを予め作っておくクリエータの存在も重要です。これだけ少数精鋭にしておけば、非常に短い構築期間でしかも質の高いシステムを作ることができます。

こうして、プロセス志向は、ウーターフォール型開発から少数精鋭によるアジャイル的な開発への移行を促すのです。では、従来のコーダーはどうなるのでしょうか。これについては、人材編で書いていきます。