システム自動生成ツール「GeneXus」
を用いたユーザ視点開発

2012年3月16日
株式会社ウイング GeneXus事業部
ARTech社公認 GeneXusインストラクター

山内 啓悦

目次
１．弊社の「三種の神器」ご紹介
1.1 システム自動化ツール「GeneXus」
1.2 GeneXus SYSTEM-Template（GST）
1.3 GSTによる開発メソドロジー「ST-REAM」

２．「ST-REAM」による開発事例
2.1 要件定義
2.2 方式設計とプロトタイピング開発
2.3 開発、試験

３．自動化ツール利用における品質
3.1 システム自動化ツール「GeneXus」から見た考察
3.2 GeneXus SYSTEM-Template（GST）から見た考察
3.3 開発メソドロジー「ST-REAM」から見た考察©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 2

１．弊社の「三種の神器」ご紹介
弊社におけるGeneXus開発では以下の３つの要素は欠かせないものなっており、まさに「三種の神器」となっています。
①システム自動化ツール「GeneXus」
全ての根幹、DOAによる自動化ツール「GeneXus」。生産性、保守性の高さもさることながら、資産継承効果が魅力的。

②開発基盤「GeneXus SYSTEM-Template」
GeneXusのコア・ナレッジベースとして利用することで更なる生産性向上を促進する役割を持つ。
ユーザ視点の開発には欠かせない。プロトタイプ開発の根幹を成す。

③GSTによる開発メソドロジー「ST-REAM」
GST専用開発メソドロジーである「ST-REAM」により、「システムの見える化」を可能にすることができる。開発者がユーザと同じ目線で構築していくことができるのがメリット。
©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 3

1.1 システム自動化ツール「GeneXus」
DOAによるシステム自動化ツール「GeneXus」
業務仕様（業務内容の記述：What）から、様々な実装環境に合わせた実現方法（ロジック：How）を推論し、自動的にシステムを生成するというDOA（データ中心アプローチ）による、世界で唯一の統合開発ツール。
特長①
データ分析結果と業務ルールを入力することにより、「プログラム言語」、「データベース」、「実行環境」を意識することなく、システムを自動生成！
特長②
日進月歩のIT技術は、GeneXusに任せて、技術者は業務仕様把握に努めることができる。GeneXusは「SEのツール」！
特長③
GeneXusは20年以上の歴史を持ち、世界約30ヶ国で利用されている。

©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 4

1.1 システム自動化ツール「GeneXus」
GeneXusにおける最大のメリット「資産継承」
GeneXusはシステムのライフサイクルに視点を置き、システム資産を永続的に継承可能。

©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 5

1.1 システム自動化ツール「GeneXus」
詳細は「はじめてのGeneXus」で・・・
GeneXusの説明を仕始めるとGeneXusのお話だけで終わってしまうので、詳細については、
日経コンピュータ 9/29号「アプリケーションの自動生成に挑む南米のツールを基幹系に活用」
または、「はじめてのGeneXus」
にてご確認ください。

※「はじめてのGeneXus」は新潟県内の大きな書店、またはAmazonでも購入可能です。

©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 6

1.2 GeneXus SYSTEM-Template（GST）
GeneXusにおけるシステム構築基盤「GST」
GSTには、「ログイン画面」「メニュー画面」「業務サンプル画面」「グラフ画面」「共通部品」「技術サンプル」などが標準装備されており、早期のプロトタイプレビューが可能となる。

プロトタイプレビュー！システムの「見える化」！
©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 7

1.3 GSTによる開発メソドロジー「ST-REAM」
開発メソドロジー「ST-REAM」（System Template - Rapid and Easy Architecture
Methodology ）主に以下の成果物を作成
・ﾃﾞｰﾀﾓﾃﾞﾙ（ERD） ・機能一覧 ・ﾃﾞｰﾀﾌﾛｰ（ﾃﾞｰﾀと機能の連携）

要件定義

機能一覧より汎用性の高い機能数個をピックアップし、3回のスパイラルレビューにより製造（完成品）。製造後、プロトタイプ機能の外部設計、内部設計、単体ﾁｪｯｸﾘｽﾄを逆引きで起こす

GST

PD（Prototype Development）フェーズ
ﾌﾟﾛﾄﾀｲﾌﾟ製造
UI設計（ﾌﾟﾛﾄ）

BL設計（ﾌﾟﾛﾄ）方式設計

主に以下を定める・標準UI、外部連携方式、ｱｰｷﾃｸﾁｬ構造方式

RAD（Rapid Application Development）フェーズ※１名の担当者が１機能につき下記プロセスを実行

UI製造
UI設計

製造

単体試験

UCL（ﾕﾆｯﾄﾁｪｯｸﾘｽﾄ）

ﾕｰｻﾞﾚﾋﾞｭｰ

BL設計

GeneXusにて外部設計を行い、結果を外部設計書に反映

主に振る舞い、ﾃﾞｰﾀﾁｪｯｸ、詳細CRUDについて記載

ﾌﾞﾗﾝﾁﾃｽﾄﾌﾞﾗﾝﾁﾃｽﾄｼﾅﾘｵ

ｼｽﾃﾑﾃｽﾄ©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

PCL（ﾌﾟﾛﾄ）

Page 8

２．「ST-REAM」による開発事例
Ｈ社 人事総務システム インプリメントシステム※人事総務系システム（クラウド）へのSI情報設定システム。

規模：約８０人月（第１段階）
期間：Ｈ11年１月～Ｈ１２年１月※第３段階（H14）までの予定

Ｊ社 ＭＤ本部系／店舗支援システム
規模：約１００人月
期間：Ｈ11年１２月～※現在継続中S社 輸出入管理システム※クラウドシステム及びパッケージシステム

規模：約４０人月
期間：Ｈ11年１２月～※現在継続中©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 92.1 要件定義
要件定義の最終成果物は「DFD」（Data Flow Diagram） とする。
機能一覧
（機能要件）

DFD
ERD（データモデル）

機能（Function）とデータモデル（Entity）の統合図！
©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 10

2.2 方式設計とプロトタイピング開発●システム・プロトタイピング開発
システムの5～7%の機能規模感によりシステムのプロトタイプを作成する。
※機能プロトタイプではない。

●方式設計
システムによって必要な方式について定義し実現可能なアーキテクチャ設計を行う。

＜代表的な方式設計＞●共通機能要件●非機能要件（ログ出力方式、権限方式
帳票出力方式等・・）●外部IF連携方式●標準UI設計
Etc・・©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

プロトタイプに反映！

システムプロトタイプ（5～7%）

システム全体規模

Page 11

2.3 開発、試験RAD開発のイメージで、「設計→開発→試験」を繰り返し行います。
担当者１名当たりの割当機能につき、RAD開発を行い、定期的に機能レビューを行う。
※UI：User Interface BL：Business logic UCL：Unit checklist

機能A

UI設計

BL設計

UCL

製造・UT

機能B

UI設計

BL設計

UCL

製造・UT

機能C

UI設計

BL設計

UCL

製造・UT

©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 12

機能レビュー３．自動化ツール利用における品質
自動化ツールの利用における品質について、下記３つの視点から考察します。
①「GeneXus」からの品質考察②「GeneXus SYSTEM-Template（GST）」からの品質考察③開発メソドロジー「ST-REAM」からの品質考察©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 13

3.1 システム自動化ツール「GeneXus」からの品質考察◎ 良いところ①GeneXusは、統合開発環境（IDE）としての側面を持っているため、管理におけるデグレート等が発生しにくい。
※グループ管理ツール「GeneXus Server」使用時②GeneXusの自動化されている箇所においてはテストする必要がなく、「人の手」が入った場所（任意の設定及び簡易コーディング、画面デザイン）についてのみテストを行うことができる。
③データモデル（DBMS）とサーバサイドアプリケーション、クライアント（HTML画面）が密接に繋がっているため、それぞれのＩＦテストを行う必要がない。
※データモデルの変更による画面の自動変更も可能※クロスリファレンス機能による影響分析も可能※バージョン管理機能、履歴管理機能による復元も可能④クロスタイプスクリプティング、ＳＱＬインジェクション等に「製品として」対応している。
⑤フルＡＪＡＸ対応も自動的に行われているため、ＡＪＡＸ動作テストが不要。
©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 14

3.1 システム自動化ツール「GeneXus」からの品質考察
×or△ 気を付ける必要があるところ①GeneXusそのものに不具合があった場合、対応に時間がかかる。
②純粋な意味でのホワイトボックステストを行うことができない。
※プロパティ設定や簡易コーディング等にて分散しているため③ＤＯＡに沿っていないデータモデルをＡsＩsで利用し、アプリケーション側だけをリプレースする場合は、開発は可能ではあるが生産性は落ちる。
※ＤＯＡに沿っていないデータモデル例
・汎用マスタのような、利用目的が明確でないマスタが存在
・ｎ：m関係の結びつきを多用している・キー無しテーブルが存在©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 15

3.2 GeneXus SYSTEM-Template（GST）からの品質考察◎ 良いところ①何かとぶれやすい画面インタフェースの標準化を容易に行うことができる。
②コーディング規約をあまり意識しないで開発ができる。
（テンプレートがサンプルであり、かつコーディング規約）③すでに品質検証済みである、各種処理部品を利用することができる。
※ＣＳＶ出力や文字列操作部品、ログ出力部品等が存在※これらの部品そのものはテスト不要④特に画面による振る舞い（挙動）についても、事前にユーザレビューし、認識を合わせることができる。
×or△ 気を付ける必要があるところ①GSTの仕様からかけ離れた業務仕様、または過度なリッチクライアントな挙動を求められた場合、効果が半減する。
©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 16

3.3 開発メソドロジー「ST-REAM」からの品質考察◎ 良いところ①ユーザーレビュー主体で開発を進めていくため、ビックバンが起こりにくい。
②ユーザーに単体テスト完了機能について、早い段階で確認作業を行ってもらうため早期の品質向上が見込める。
③システムプロトタイプを標準仕様とするため、各画面での仕様統一を行いやすい。

×or△ 気を付ける必要があるところ①スケジュール管理が煩雑になる傾向があるので、PMの力量が求められる。
②GeneXus技術者は「SE」としての技能も必要となる。
※ただし、GeneXusスペシャリストは各PJに１名以上は立てる©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 17

お客様の“欲しい”を想像し、共に“喜び”共に“発展”します

ご静聴いただき誠にありがとうございました。

©Copyright 2012 WeING Co.,Ltd.All Rights Reserved.

Page 18