本日、「内製化を支援する、というビジネスの詳細を伺いたい」というお客様の元へ伺い、当社の考える内製化成功の秘訣をお話してきました。
過去に EUC (End User Computing) という名の下に、エンドユーザが大量の Excel マクロを作成したことは誤りだったと考えられています。細かい点にこだわるほどマクロ（プログラム）の量が肥大化し、結果的に業務の変更にマクロ（プログラム）変更が追いつかなかったのです。また、そのマクロを保守できる人は原則一人だけ（作成した本人のみ）であるため、その人がいなくなると保守もできないという状況です。これは Excel だけでなく、Access や FileMaker など、既存の EUC ツールすべてに共通する問題です。
その後、Java による Web ベースの業務アプリケーション開発が中心となると、学ぶべき要素技術の量が格段に増えてしまったため、エンドユーザによる開発は無理ということになりました。COBOL 時代に逆戻りしたかのように、情報システム部門による内製化は陰をひそめていきます。
それでも私達が再び内製化にスポットをあてているのは、もちろん Wagby の登場が前提です。それは、過去に失敗した EUC ブームのときと決定的に異なっていることがあるためです。一言で表現すると、
プログラム（マクロ）を書かないでよくなった。
ことです。より正確には、
プログラム（マクロ）を書いてはいけません。
プログラムを書くから、保守ができなくなるのです。何を当たり前な...と怒られそうですが、Wagbyの本質は「完全自動生成により、仕様書と稼働しているシステムが完全に 1:1 の関係にある」ことです。Wagby が生成するソースコードは一切、気にしなくてよいのです。そうなるとソースコードの変更にかかる時間コストがゼロになりますので、業務設計者は仕様書の変更（と、データの移行）だけでシステムを改変できます。
これでようやく、現場手動の PDCA サイクルが機能します。これまでの情報システムで PDCA サイクルが回らないのは、Check のあとで改変要求が発生しても、その修正にコストがかかるためです。修正コストの外注費が発生しないとなると、改変のための敷居は著しく下がります。
私の知る限り、類似のソースコード生成ツールは雛形の生成後にプログラムを書きます。Wagby はエンドユーザによる内製化を視野に入れているため、徹頭徹尾、プログラムを書かせない方向に導きます。Wagby と他社製品の最大の違いは、この哲学にあります。
