rubyによる自治体様向け大規模基幹系業務システムの...

Rubyによる自治体様向け大規模基幹系業務システムの

開発事例～島根県様向け予算編成支援システム～

Ruby World Conference 2012

Copyright(c)2012 Techno Project. Co., Ltd. All Rights Reserved.

～島根県様向け予算編成支援システム～

2012年11月8日

株式会社ワコムアイティ今岡克己

株式会社テクノプロジェクト飛田健一朗

○月補正予算

当初予算

予算編成支援システムとは行政事務の中核となる「予算編成事務」の効率化

予算要求から決定に至る各事務で必要となる書類を作成

要求査定議案書作成

Copyright(c)2012 Techno Project. Co., Ltd. All Rights Reserved. 1

予算書予算書議案書

内部協議内部協議議会議会

DB DB DB 帳票作成にかかる職員様の労力や

負担を軽減

開発に至った経緯(1/2)

クライアント／サーバ型システム（サーバ分散型）

クライアントパソコンにアプリケーションを配置

【画面】MS Visual Basic 5 ／【帳票】Pegasus Reports 1.56

既存システムの概要既存システムの概要

PGMPGM

A拠点 B拠点


サーバ：4台

パソコン：約600台

DBPGM

DBPGM

データ通信

Web型システムが主流となっている今日では、二世代ほど前の構成で開発されたレガシーシステム。

開発に至った経緯(2/2)

クライアントパソコン環境の変化に伴うシステム改修（OSのバージョンアップ）

MS Visual Basic 5 のサポートが既に終了

Windows VISTAではPegasus Reportsが動作しない

既存システムの課題既存システムの課題

クライアント環境には依存せず、ブラウザのみあれば動作するシステム、つまりWeb型システムへの移行が必要。


つまりWeb型システムへの移行が必要。

で解決！

業務要件(1/2)

既存システムの仕様を踏襲既存システムの仕様を踏襲

業務フロー業務機能踏襲する仕様

C/S型既存システムの仕様を踏襲する再開発

画面に関して、きめ細かく設定できるC/S型に比べ、Web型は制限事項が多い

画面レイアウト帳票レイアウトデータベースレイアウト

必要な機能改善も実施（44件）


【画面数】２２５【帳票数】１１４【テーブル数】９２

開発規模

利用者からは使い慣れた画面や操作性にギャップが生じる懸念がある

開発の生産性が全体コストに大きく影響

生産性を向上する仕組みづくりが必要

過去に例のない大規模なシステム開発

業務要件(2/2)

利用者数は600人、大量データ出力帳票あり利用者数は600人、大量データ出力帳票あり

●業務の特性上、特定の時期に集中して利用される。

ピーク時は同時100人程度の利用が想定


●1帳票当りの最大規模として、出力データサイズ：１３MB

同時アクセス数や処理データ量が多いと、性能劣化を引き起こす懸念がある

性能を確保する仕組みづくりが必要

同時アクセス数や処理データ量が非常に多い

システム構成(1/2)

サーバ構成サーバ構成

利用者パソコン（約600台）

サーバ群（プライベートクラウド）

Web/AP1サーバ

Web/AP2サーバ

DBサーバ

帳票サーバ


負荷分散装置

二重化によるサーバ単位の負荷を軽減

帳票生成処理専用化による他処理（DBアクセス等）の影響を抑止

ディスク容量 80GB

メモリ 4GB

CPU X5670 （2.93GHz/6コア）

ディスク容量 300GB

メモリ 8GB

CPU X5670 （2.93GHz/6コア）

Windows XP,7

Internet Explorer 6,8

システム構成(2/2)

ソフトウェア構成ソフトウェア構成

種類既存システム開発システム選定理由

AP（ｵﾝﾗｲﾝ）

Visual Basic 5 Ruby 1.9.2Ruby on Rails 3.0.7

AP COBOL V7.2 COBOL V10.2 既存資産（COBOL）の活用による全体コス

（プロジェクト発足時点の）最新バージョンを選定

業務要件（既存システム仕様の踏襲）を踏まえ、コスト・品質・性能のあらゆる側面から検討し、新規部分と踏襲部分を決定！


（ﾊﾞｯﾁ）ト低減・品質確保

DBMS Oracle 10g Oracle 11g 互換性からデータ移行に掛かるコスト低減既存資産（DB操作プログラム：PL/SQL）の活用による全体コスト低減・品質確保

Print Pegasus Reports 1.56 Interstage ListCreator V9.2＜富士通製＞

帳票生成速度、および開発実績あり

OS Windows Server 2003 Red Hat Enterprise Linux 6（DB、帳票サーバはWindows Server 2008）

Windowsと比較してRubyの処理速度が上Passengerの適用

OSS製品商用製品

必要なスキル・ノウハウ

予算編成業務既存システムの仕様・運用

実施体制(1/3)

業務

自治体市場におけるプロジェクトマネジメント・Ruby業務システムの開発実績

管理

RubyをはじめとしたOSSに関する開発技術・技術者教育

技術

スキームスキーム

開発に必要スキル・ノウハウを保有する島根県内の企業で実施


務システムの開発実績

ワコムアイティテクノプロジェクトネットワーク

応用通信研究所

【総工数】約100人月超【開発メンバ】 20人

飛田

実施体制(2/3)

業務

データ移行

研修運用

インフラプロマネ

役割分担(1/2)役割分担(1/2)

設計

開発手法の理解が必要

Ruby1.9系/Rails3.0系の技術習得が必要


業務AP開発

標準化

インフラ構築

プロマネ

開発規約の作成共通部品の作成プロトタイプの作成

既存システムの仕様が分からない…既存システムの仕様の理解が必要

複数企業によるスキームにおいては、各社の”強み”だけでは実施出来ない。

実施体制(3/3)

役割分担(2/2)役割分担(2/2)

【プロジェクト開始】

業務、既存システムの仕様の説明

【プロジェクト開始】業務

データ移行

研修運用

インフラプロマネ

設計


開発規約の作成共通部品の作成プロトタイプの作成【開発工程前】

Ruby1.9系/Rails3.0系の注意点

各社の役割を遂行するのに不足するスキルやノウハウの分析・把握必要なタイミングで補完する取り組み（勉強会、ドキュメント作成など）

【プロジェクト開始】プロジェクト計画開発手法

業務AP開発

標準化

インフラ構築

プロマネ（飛田）

開発の進め方(1/3)

2010年度 2011年度 2012年度

1月 4月 7月 10月 1月 4月 7月

スケジュールスケジュール

要件定義

概要設計

1年5ヶ月／ウォーターフォール型開発

設計書作成仕様凍結

開発範囲の確定


定義詳細設計

プログラム開発・単体テスト

結合テスト

総合テスト

試行運用

本運用

標準化

標準化工程の設置によるルール作り早期の開発着手によるルールの検証

成果物（設計書、ソース）のバラつきを抑止

手戻りによるリスク（コスト増大、納期圧迫）を抑止


Point①：標準化工程の設置Point①：標準化工程の設置

画面・帳票設計規約（レイアウト、ドキュメント記述）画面HTML作成手引き（テンプレート、記述ルール）画面HTML部品集（コントロールとコードを集約）

規約作成

既存システムの踏襲既存共通部品の活用（他システムでの作成分）使用手引書の作成（処理、引数・戻り値、使用例）

共通部品作成

プロトタイプの作成（画面・帳票より選定）プロトタイプ説明書の作成（コード解説）逆引き一覧（処理と説明書の紐付け）

プロトタイプ作成

開発に使用する「もの」だけでなく、「もの」の使い方も含めて作成。


（コントロールとコードを集約）Rubyコーディング規約

（処理と説明書の紐付け）

お客様に実機上で画面の見栄えや操作性を確認頂く。システムで実現する範囲と制限事項として了承頂く範囲とを合意。（コストや品質の側面から）


Point②：開発の早期着手Point②：開発の早期着手

開発機能をサブシステム単位に５グループに分割し、五月雨式に開発。

設計規約・開発規約共通部品

同等処理が散乱！部品化しよう！

フィードバック


概要設計詳細設計プログラム開発・単体テスト機能Grp①

機能Grp②

・・・・・・・・・・・・・・・

概要設計詳細設計プログラム開発・単体テスト

機能Grp⑤

概要設計詳細設計プログラム開発・単体テスト

成熟したルールの適用が可能

開発結果(1/2)

生産性生産性

開発規模

開発工数

２４３ Kstep

１０５人月（概要設計～結合テスト）

開発生産性２．３１ Kstep／人月


C/S型からの再開発（既存システム仕様の踏襲）

ウォータフォール型開発

概要設計～結合テスト

納品用ドキュメント作成が必要（設計書、テスト仕様書・成績書）

類似システムや類似手法による開発のコスト計画として活用

開発結果(2/2)

性能性能

画面名 A画面 B画面使用頻度（同時使用）が多い画面より選定

処理機能検索実行帳票出力サーバ処理より選定

データ量 14件 11ページ過去データより平均値を選定

多重度 1多重 5多重過負荷 1多重 5多重過負荷【1多重】単一アクセス【5多重】5台同時実行（平均値）【過負荷】21台で任意操作

【試験方法と試験結果（一例）】


【過負荷】21台で任意操作

処理時間（秒）

既存 1.1 ─ ─ 4.1 ─ ─ ストップウォッチでの計測

既存システムは、環境制約等により一部実施不可

新 0.7 1.5 1.6 3.2 3.9 4.2

DB操作プログラム（PL/SQL）のチューニング

memcache-clientをDalliに変更 ⇒ memcache-clientは既に非推奨。常に情報収集が必要。。。

既存システムより性能アップ多重度が増えても大幅な性能劣化には至らず

ただし、最終結果に行くつくまでには、以下の対策が必要であった。

本稼働後の状況

品質

Ruby / Ruby on Railsの根本に起因するトラブルはなし

致命的なアプリケーションに係るトラブルはなし

システム基盤に係るトラブルはなし

システム性能に関するお客様からのクレームはなし

納期予定通り、2012年7月本稼働


性能

システム性能に関するお客様からのクレームはなし

（既存システムと比較して「早くなった」との声も頂いている）

システム資源圧迫によるシステムダウン・性能劣化はなし

Rubyによる大規模基幹系業務システムの実現を、実績をもって証明できた。

今後への期待

自治体市場における”Ruby”ビジネス拡大の期待

Ｃ／Ｓ型で稼働しているシステムは存在

大規模基幹系業務システムへのRubyの適用が可能実績

市場


”Ruby”を武器としたIT企業のビジネス拡大の期待

島根県内のＩＴ企業で実施競争力

自信

rubyによる自治体様向け 大規模基幹系業務システムの...

Documents

rubyによる自治体様向け大規模基幹系業務システムの...