読者です 読者をやめる 読者になる 読者になる

内製化を成功させるためのキーワード

本日、「内製化を支援する、というビジネスの詳細を伺いたい」というお客様の元へ伺い、当社の考える内製化成功の秘訣をお話してきました。

過去に EUC (End User Computing) という名の下に、エンドユーザが大量の Excel マクロを作成したことは誤りだったと考えられています。細かい点にこだわるほどマクロ(プログラム)の量が肥大化し、結果的に業務の変更にマクロ(プログラム)変更が追いつかなかったのです。また、そのマクロを保守できる人は原則一人だけ(作成した本人のみ)であるため、その人がいなくなると保守もできないという状況です。これは Excel だけでなく、Access や FileMaker など、既存の EUC ツールすべてに共通する問題です。

その後、Java による Web ベースの業務アプリケーション開発が中心となると、学ぶべき要素技術の量が格段に増えてしまったため、エンドユーザによる開発は無理ということになりました。COBOL 時代に逆戻りしたかのように、情報システム部門による内製化は陰をひそめていきます。

それでも私達が再び内製化にスポットをあてているのは、もちろん Wagby の登場が前提です。それは、過去に失敗した EUC ブームのときと決定的に異なっていることがあるためです。一言で表現すると、

プログラム(マクロ)を書かないでよくなった。

ことです。より正確には、

プログラム(マクロ)を書いてはいけません。

プログラムを書くから、保守ができなくなるのです。何を当たり前な...と怒られそうですが、Wagbyの本質は「完全自動生成により、仕様書と稼働しているシステムが完全に 1:1 の関係にある」ことです。Wagby が生成するソースコードは一切、気にしなくてよいのです。そうなるとソースコードの変更にかかる時間コストがゼロになりますので、業務設計者は仕様書の変更(と、データの移行)だけでシステムを改変できます。

これでようやく、現場手動の PDCA サイクルが機能します。これまでの情報システムで PDCA サイクルが回らないのは、Check のあとで改変要求が発生しても、その修正にコストがかかるためです。修正コストの外注費が発生しないとなると、改変のための敷居は著しく下がります。

私の知る限り、類似のソースコード生成ツールは雛形の生成後にプログラムを書きます。Wagby はエンドユーザによる内製化を視野に入れているため、徹頭徹尾、プログラムを書かせない方向に導きます。Wagby と他社製品の最大の違いは、この哲学にあります。

Wagby開発スタッフ募集中です!