システム開発という場合、対象を何にするかで開発の様相がだいぶ違うように思う。ところが、世の中の議論はそこのところを一緒くたにしている。
この場合の対象というのは、片やプロダクト開発というか、ソフトウエア開発のことである。もう一方は、アプリケーション開発で特に業務アプリケーション開発のことである。この二つは、同じ開発といってもずいぶんと違うのである。もっと言えば。業務アプリケーションの場合に、開発という言葉が適当ではないのではないかと思う。
わかりやすい例え話で言うと、家を建てる場合、建築材料や工法は開発するというが、家を開発するとは言わないで建築するとか構築するとかと言う。システム開発の場合の業務アプリケーションは家に相当するから、業務アプリケーション開発と言わず、業務アプリケーション構築と言うべきなのである。
そもそも、このあたりの考え方が一般化されていないので、つい業務アプリケーションは開発するものだと思ってプログラミングし出すのである。
家の例え話をもう少し言うと、家にも建売と新規建築もあり、戸建と集合住宅もありという風にその用途や生活力でいろいろなタイプのものが作られる。ただ、それでもほとんどは真さらな状態からではなく、部材や資材の組合せで作られる。ユニット工法とかモジュール工法である。
ですから、オブジェクト指向開発だとか構造化技法だとか、よくわからない要求開発だとかが、ソフトウエアの開発には有効かもしれませんが、いかに業務アプリケーションの構築には無力なのかがわかるのではないでしょうか。
システム開発も建物の建築のようにできないものだろうか。そのためには、開発という概念を捨て去ることなのだ。部材や資材に相当するプロダクト、ソフトウエアを開発するのは当然必要であり、またそれを組み立てる工法も開発すべきものであるが、あとはそれらを使って組み上げるだけにすべきなのだ。
いま試行している「BPWeb2.0」のフレームワークというのは、まさにＳＩの世界を建築の世界並みにしようという考え方なのである。ＳＩすなわちシステムインテグレターというのは、本来そういう姿のものではなかったのか。システムインテグレーションがプログラミングしていたら何がインテグレーションだと揶揄されてしまう。
「BPWeb2.0」には、建築工法にあたる構築技法と部材･資材に相当するプラットフォーム、それと大工さんの養成である教育･研修といったプログラムが詰まっている。このフレームワークでシステム構築を行なえば、コードレスで、すでに出来上がったコンポーネントを組み合わせるだけで業務アプリケーションが構築できるのである。
この方法論は、低コスト化や短納期といったメリットがあるが、もっと大きな効果は来るべき「工事進行基準」という会計基準の変更への対応ではないかと思っている。このことについてはまた後で書く。