さて、いよいよ開発・製造という段階のことになります。プロセス志向という場合、少し拡張して考えた方がいいと思います。すなわち、単にあるがままのプロセスを作っていけばいいというものではないわけで、前回にプロセスの正規化ということを言ったと思いますが、ある程度型にはまったもものにする、いわゆるパターン化をしましょうということです。

そのために必要なのは、「シンプルで一貫化されたきれいなプロセス」であることは何度も繰り返して言っていることですが、そのようなパターン化ができれば、いちいちコードを書く必要がなくなるということが重要なのです。最初からフレームワーク化しておけばいいからなのです。

ただし、このシンプルなプロセスは、パターン化できるレベルの話ですから、そのもっと下のレベルではあいまいなプロセスがあることも何回も言っていますが、そのレベルではゆるくして“場”を与えるようにするだけなのです。そこでは、仕事の流れをいちいちコードで記述するのではなく、情報共有させ、人が動きをつくるようにしておけばよいのです。

ここがプロセス志向の開発に及ぼすインパクトです。ユーザと対峙する開発プロジェクトでは原則コードを書かないことが大きな意味を持つのです。

少々脱線しますが、そもそも“業務システム開発”と言ったとたん、ええーとなってしまいます。こういう場合いったい何を開発するのでしょうか。“業務プロセス”を開発するのでしょうか、“ITシステム”を開発するのでしょうか。

開発というのは何もないところから新たなものを作ることだから、今までなかった新業務プロセスを作るということなのだろうか、もしそうなら、ITは関係ないはずです。ですから、システム開発プロジェクトでやることではないのです。

ではITシステムを開発するのでしょうか。それだったら、逆にどうしてそんなプロジェクトにユーザが入らなくてはいけないのでしょうか。それは、IT側で勝手にやればいいと言われてしまいます。だから、“開発”というのはそぐわない言葉なのです。

問題は、言葉だけのことではなく、実際のプロジェクトで“開発”をしてしまうことにあるのです。だから、思ったものと違うとか、それじゃだめだから変えてとか、最悪デスマーチとなるわけです。

もっと容易に“システム構築”ができることをめざすべきです。以前にも言ったことだが、家を建築するとは言うが開発するとは言いませんよね。家を建てるときにトイレを開発したりしませんよね。

あえて開発と言えば、部屋の形とか生活スタイルのところです。それは、むしろ好きなようにアレンジするといった方があっているような気がします。だから、プロセス志向の開発は、開発するのではなく構築あるいはアレンジするということになります。

そのためには、予め部品やフレームワークあるいはアダプターを用意しておき、それをユーザと顔をつき合わせて組み合わせてしまう工法が求められるのです。

もちろん、部品やフレームワーク、アダプターはコードを書きます。そこを開発プロジェクト段階ではなく、その前に製造しておくことが必要です。

こうすれば、いまのIT業界よりましな建築業と同じような業種になってくると思うのですがいかがでしょうか。