さった1月14日に、今年始めの Wagby セミナー講師を勤めました。受講者は企業の情報システム担当者が多かったため、貴重な意見を伺うことができました。
Wagby の評価は非常に高く、"予想以上に機能が豊富で、充分使えそう。" というご意見を頂戴しました。ではすぐに導入いただけるかというと、そう甘くはありません。次のような壁があるようです。
これまでさまざまなアプリをつくりすぎており、いずれも保守で手一杯。Wagby でさらに新しいアプリをつくると、過去システムとの統合という観点で、また複雑度が増す。
つまり、社内アプリケーションの構築に関するポリシーを決めるのが先だということです。これは多くの企業で共通の悩みでしょう。皮肉にも Wagby の開発生産性の高さが、この隠れていた問題をあぶりだしてしまうのかも知れません。
悩みが深いことは承知の上で、私の考えをまとめます。私がもしユーザー企業の CTO の立場なら、という気持ちで書きます。
1990年からはじまったオープンシステムブームから20年が経過し、さまざまな開発手法が登場しました。言語やプラットフォームの違いを取り払えば、それらはいずれも「どうやって生産性の高いプログラムを書かせるか」という視点で差別化されてきました。しかし何らかのプログラムを書くことは変わらず、そこでソースコードの保守が発生します。書けば書くほど自縄自縛な状態になってしまうことに多くのユーザー企業は悩んでいます。
2011年からの10年間を見据えた IT 化計画で、この発想を変えてみませんか？
キーワードは「アジャイル」と「プログラムを書かない開発（ソースコードの自動生成）」です。
もちろん完全なノンプログラミングは難しいでしょう。しかし、できるだけ書かないという信条を掲げることで、開発スタイルは一変します。また、アジャイルを掲げた意図は、最初から完成形を目指さないことです。利用者が多いほど仕様策定は紛糾します。そこでまず小さくつくり、フィードバックを受け、少しずつ改善というサイクルを進めます。そうする中で、当初かたくなに主張されていたユーザーからの要求が（つかっていく中で）変わることも十分、考えられます。
何度も会議を重ねるよりも、動くものを出す。
それがアジャイル開発の真骨頂です。そしてアジャイル開発を支える技術基盤に、ソースコード自動生成を適用します。これが新しい開発スタイルです。
繰り返します。既存アプリの統合、素晴らしい UI、最小のコードで動作する RAD ツールなどの導入は、既存の開発スタイルの部分最適解として魅力ですが、本質は 20 年前と変わらないままです。次のステップとして、例えば "開発生産性10倍" という目標を掲げてみてはいかがでしょう。または "利用者要求から1週間後にリリース" といったものでもいいでしょう。それをクリアするためには、これまでとは違った発想が求められます。
新しいビジョンを掲げて、変化に強い情報システム部門に進化する。今、社内システムの内製化が脚光を浴びていますが、これを単なるコスト削減策とするのではなく、次の高い目標を実現する "きっかけ" として総合的に捉えるチャンスにしていきましょう。
