第3回例会報告
6月16日、第3回システムイニシアティブ研究会（例会）が開催されました。今回の参加者は55名。前回から2週間ほどしかあいてない、変則的な開催日程となりましたが、多くの方にご参加いただきました。
最初に、木内会長から「ユーザー主体開発によるベンダーへの丸投げ依存からの脱却が本会のテーマ。そのためにはユーザーの意識改革が重要である。本会では議論に重点を置いて、それを通して真髄を明示してゆきたい。」と、当会の趣旨をあらためてお話いただきました。設立1年目の当会では、例会のたびに新しい会員の方が参加されるので、このような趣旨の確認は重要です。
今回は、講師の内山さんから、「情報経費を半分以下に！ システム開発のパラダイムシフト」というタイトルで、アプリケーション・ジェネレータを使うことによって、システム開発のパラダイムシフトをしよう、というご講演をいただきました。業務定義を「知識ベース」に蓄積し、選択した言語のソースコードを自動生成するGeneXus、ソースコードは生成せず、知識ベースをもとにインタープリタとして動作するSapiens、Excelで入力した設計情報からWebアプリケーションを作る国産のWagbyなど、複数のアプリケーション・ジェネレータのベンダーの方々も出席し、さまざまな質問が飛び交いました。
GeneXusによる開発
- 業務要件定義、外部設計はDOAで今まで通り行う。
- 外部設計情報に基づいてツールの知識ベースに入力する。
- ソースコードが自動生成されてコーディング、テスト、変更にかかわる工数を1/2~1/3に下げることができる。
- 業務変更に対してはプログラムを修正せずに、知識ベースの変更で対応する。コーディングバグフリーのソースコードが生成される。
設計者によると、GeneXusの目的は「未来の変化からビジネスを守ること」。ビジネス変化に伴うシステム変更に、柔軟に、迅速に、高品質に対応することを目的として開発されたそうです。
事例として、ドトールコーヒー、ＪＡＬパックハワイ、東洋大学などをご紹介いただきました。東洋大学では、目標管理を含む新たな人事システムを開発したのですが、
・業務定義 520機能（要件定義・外部設計はユーザーが実施）
・テーブル定義 283（システム開発・結合テストはベンダーがGeneXusで実施）
・画面定義 407（半分ぐらいに抑えるはずだったが、ユーザー要望で倍に）
・帳票定義 177
・ソースコード 450万ステップ
というとても大きなアプリケーションが、バグなしで動いているそうです。
オフショアからの脱却
総務省19年度「情報通信白書」によると、オフショア開発に出される業務範囲で最も多いのは、プログラム作成（93.8％）、単体テスト（86.5％）だそうです。この部分はアプリケーション・ジェネレータで置き換えられる部分であり、それによって「オフショアから脱却することができる」と内山さんは言います。「開発・テストを、単に人件費の安いオフショアに出すというのでは、システム開発のパラダイムは全く変わっていない。ビジネス環境の変化には、変化（パラダイムシフト）で対応するべき。」と講演をしめくくられました。
質疑内容
講演の後は、ガートナージャパンの山野井さんのファシリテーションで、各テーブルでの議論が行われました。そこで出たＱＡのいくつかをご紹介します。
Ｑ：素晴らしいツールだが、どうしてこれまで広がらなかったのかが不思議。ベンダーが開発するのではなく、ユーザー自身が利用すべきツールではないのか？
Ａ：人月ベースの開発でビジネスをしているベンダーは、このツールは売らないだろう。自社のビジネスモデル自体を否定するようなものだから。こういう会を通して、ユーザー側でシステム開発を変えていかないといけないのでは。
Ｑ：人月ベースの見積もりから、どのような方法に転換すべきなのか？
Ａ：（会場内でツールベンダーの方に聞いたところ）ベンダー側からは機能ベースやデータ項目ベースの見積もりが試みられている。むしろ、ユーザー側から人月ベースの見積もりが求められてしまう状況がある。
人月ベースの考え方は、ベンダーとユーザーの間で一種の通貨単位のようになってしまっているようです。
議論の場では東洋大学の大場先生（CIO）も飛び入りで解説をしてくださいました。
「業務現場の人々が、現物の情報をベースに業務の流れを整理して、正確に記述することができるはず。紙の情報をフォルダなどに整理しているでしょう？それが業務の単位となっている。その整理ができているのであれば、業務設計ができる。最も大切なことは、ベンダーやツールではなく、業務現場の人が業務の流れや情報の手続き理解して管理できるようになること。そのような人材を生み出すことが本質。」と、業務設計ができる人材の育成の重要性を語られました。
情報システム部門は要件定義のファシリテータになる
最後に、木内会長からの講評として「業務を知る現場ユーザーが要件をまとめる、外部設計もまとめられる。このようなツールを使えば、システム開発までも手掛けることができる。そのような環境では、情報システム部門の役割がおのずと変わってくる。ユーザー要望で画面数が倍になってしまった例が示されたが、情報システム部門は、それを適切な数におさえるなど、『要件定義のファシリテータ』としての立場が重要になってくると考えられる。」と話されました。
アプリケーション・ジェネレータに限らず、優れたツールや手法を取り入れ、システムの開発方法を大きく変えるということは、費用の考え方、企業内でのユーザーと情報システム部門の役割など、あらゆることが変わる。それが成功するかどうかは、ユーザー自身が変わることができるかどうかなのだと思いました。あらためて、「パラダイムシフト」の意味を考えた時間でした。
吉田太栄（システムイニシアティブ研究会事務局）
