Ruby 業務システム開発の実績 2007 年 IPA( 情報処理推進機構 ) 実証事業 IPAオープンソフトウェアセンターがRuby/Railsを基幹業務に適用する実証事業を実施松江市殿 ) 医療介護高額合算システム ( 日本初 : バッチ処理を含む基幹業務全体 ) 約 50 人月 2007.

Size: px

Start display at page:

Download "Ruby 業務システム開発の実績 2007 年 IPA( 情報処理推進機構 ) 実証事業 IPAオープンソフトウェアセンターがRuby/Railsを基幹業務に適用する実証事業を実施松江市殿 ) 医療介護高額合算システム ( 日本初 : バッチ処理を含む基幹業務全体 ) 約 50 人月 2007."

みりあやまがた
5 years ago
Views:

1 ~Ruby が切り開くイノベーション ~ ( 新システム分野と開発標準 ) 2011 年 7 月 22 日島根県情報産業協会会長吉岡宏 1

2 Ruby 業務システム開発の実績 2007 年 IPA( 情報処理推進機構 ) 実証事業 IPAオープンソフトウェアセンターがRuby/Railsを基幹業務に適用する実証事業を実施松江市殿 ) 医療介護高額合算システム ( 日本初 : バッチ処理を含む基幹業務全体 ) 約 50 人月 ~ オン :14 本バッチ :24 本業務開発チーム :6 名テクノプロジェクトマツケイ共通技術チーム :3 名ネットワーク応用通信研究所 2

3 医療介護高額合算システム 2007 年度 IPA 公募事業医療介護の高額合算システム ( 松江市殿 ) 住民記録システム国民健康保険システム ( 医療保険 ) 後期高齢者システム ( 医療保険 75 歳以上 ) 介護保険システム既存業務システム ( メインフレーム C/S) 住民異動情報自己負担額資格情報支給額情報自己負担額資格情報支給額情報自己負担額資格情報支給額情報医療介護高額合算システム Ruby 開発システム窓口業務内部処理市民相談支援申請受付証明書通知書発行など自己負担額合算支給決定支払い登録口座振替情報など大量テータ処理精度の高い帳票印刷再印刷やヘーシ指定印刷バッチ処理環境 Copyright(c)2011 Copyright(c)2009 Techno Project. Co., Ltd. All Rights Reserved. 3

4 メインフレームのオンライン構造 (MainFrame) 端末オンライン制御メッセージ振り分け多重端末多重会話主プロ業務処理業務処理画面定義体画面定義体画面定義体 D B アクセスルーチンデータベースネットワーク DB C/S システム 3 階層開発プレゼンテーション層アプリケーション層データベース層業務処理に集中して開発できる環境 RDB Best System Structure

5 Webアプリ (Railsシステム構造) Ruby on Rails( 機能分割 : モテルヒューコントローラ ) 端末 W E B サバ Apache 等 R A I L S 制御コントローラコントローラコントローラ業務処理業務処理業務処理ビュービュービュー画面定義体画面定義体画面定義体モデル Active Record データベース MySQL 等 Ruby on Rails M: モデル (DBマクロ) 検索挿入更新削除のSQL ( 一部業務も含む ) V: ビュー ( 画面定義 ) HTML ヘルハー HTMLエティター(Webテサイナ) C: コントローラ ( オンライン制御業務処理 ) 業務ロジック

6 Rails でも C/S システムと同様な画面 IF( コンボボックスオプションボタンサブウィンドウ等 ) 窓口に市民が来た時の対応 1 つの画面で完結 ( 画面遷移の少ない処理 ) ( 上段 : 申請者情報, 中段 : 受給履歴下段 : 申請内容 ) 6

7 生産性 (2008.2) 前提条件全工程 (100%) 設計工程 ( 基本設計詳細設計 ) 30% 製造工程 (PG 設計プログラミング単体テスト ) 40% テスト工程 ( 結合テスト総合テスト運用テスト操作研修 ) 30% Ruby Rails と既存の基幹業務の開発方法との生産性比較比較方法 : 初めての Rails 開発経験者にヒアリングを実施対象者 : 前提として Rails 開発を2~3 回こなし習熟した場合に生産性はどのようになるか 50 代 SE 2 名 30 代 SE/PG 3 名 (COBOL,VB,Javaによる基幹業務の開発経験者) 設計工程 (30%)+ 製造工程 (40%) 3/4+ テスト工程 (30%) 全工程 (90%) 10% 改善変わらない 25% 改善変わらないウォータフォール開発開発要員は当初から全員投入し Ruby 教育やプロト開発を実施するドキュメント設計工程 : 基本設計 / 詳細設計書テスト工程 : テスト仕様書 / 成績書詳細設計はプログラム単位に詳細な機能説明を記述プログラムのロジックを記述するプログラム設計書は作成していない ( 比較の元となる開発もプログラム設計書 : 未作成 ) 基幹業務の特性としてチェック処理が多い 1 つのデータ登録に 100 ステップ程度の整合性チェックなどが頻繁にあるどの言語で開発しても生産性の改善はできない自動テスト機能は使用していないアジャイルのような繰り返し開発に有効であるがウォータフォール型の開発ではテスト手順の登録作業にかえって工数が増大すると考えた Copyright(c)2011 Copyright(c)2009 Techno Project. Co., Ltd. All Rights Reserved. 7

8 開発標準 :COBOLer の復活 (2007~) ベテラン SE(COBOLer) が Web システムの開発に参加できる 1ウォータフォール開発 ( 設計製造テスト ) 2 厳格なコーディング規約 (Rubyの自由度をなくす) 3 日本語のDB 項目名称 ( 設計書とソースの見易さ ) 4SQL 記述 ( 判り易さ但し便利な部品が使えない ) 5バッチ処理も同一言語で開発 6 構造化設計 ( 業務ロジック重視従来のトキュメント類 ) 7 少ない部品 ( 少量の部品から始める覚え易さ ) 8 画面定義 (HTML) は専任化 :Webテサイナー 9クラス設計 : テーフル毎の業務ロシックを含めたアクセスルーチン COBOLer 向け Ruby/Rails 教育コース by テクノプロジェクト 8

9 開発システムの事例 (2007~2010) 県内自治体県内自治体県内自治体県内財団法人医療機関医療機関金融機関県外ソフトウェア業県外ソフトウェア業県外情報サービス業経済産業省しまね産業振興財団島根県遺失物管理システム行政システム施設予約システム施設管理システム勤務管理システム化学物質管理システムホームページ業務系システム ( パッケージ開発 ) Railsを用いたシステム開発支援ソフトウエア構成管理システム地域経済情報化基盤整備補助事業 ( 地域連携 : 島根 2 社 + 広島 2 社 ) 教育講座業務開発者のための Ruby/Rails 実践母子寡婦福祉資金システム (iofw iofw) 再開発業務心身障害者扶養共済システム (iofw iofw) 再開発業務約 40 人月約 35 人月約 20 人月約 12 人月約 18 人月 - 約 4 人月約 20 人月 - 約 50 人月 - - 約 40 人月 9

10 アジャイル開発 (2010) Rubyビジネスモデル研究実証事業 ( 製造業向けアジャイル開発 ) 生産ラインの各種機械の検査記録システム顧客情報システム部門 :1 名 SE/PG:3 名開発期間 (6 カ月 ) と予算 ( コスト ) 確定システム仕様は作りながら決定目標レベル設定但し顧客満足度優先結果 : 未達その後顧客側で完成アジャイル ( スクラム方式 ) 定期的な顧客リリース (2 カ月単位 ) 仕様調整開発チーム内は 2 3 週ごとに結合テスト早い段階で整合性確認テスト駆動開発 ( テストファースト + リファアクタリング ) ペアプログラミング見られるという緊張感ダイナミックな作業割り振り前提 : 開発者の業務理解度が平準朝会夕会基本 10 分時々議論の場にもなる 10

11 ウォータフォールアジャイル生産性と品質良いものがオープンソースで提供される Ruby+Rails 環境を前提にした米国製品道具の活用 ( テストツール課題管理ソース管理テフロイ ) 部品の活用 (GEM ハッケーシ Rails フラクイン社内部品 ) プログラミング作業加工組み立てテスト駆動開発 ( テストの自動化 + リファクタリング ) 生産性向上 + 品質向上 11

12 開発標準を目指してアジャイルを業務システム & 請負い契約に取り込む開発手法 1 開発方式とドキュメント 2 開発チーム 3テスト駆動開発 4ペアプログラミングとソースレビューツール 5プロジェクト管理開発ツール 6 外部ライブラリィの活用帳票作成ツール品質生産性顧客満足度開発者満足度全ての向上に向けて 12

13 開発手法 1 開発方式とドキュメント (1) 設計 : ウォータフォール業務システムは一般的に制度法律慣習が詰まった複雑なもの DBアクセスでは多くの更新系処理が発生するイレギュラー処理設計が重要特に DB 設計最終トキュメント : メンテナンス手引書として整備 ( 含む納品物 ) 構成品管理表基本設計書詳細設計書操作運用マニュアル開発途中はホワイトボードのデジカメ化でも OK (2) 実装 (PG 設計 ~ 結合テスト ): アジャイル = 素早く繰り返し繰り返しの中で早め早めの顧客確認 ( 満足度 ) と開発チームの整合性確認顧客リリースは2~3カ月の単位で段階的に行う実装は2~3 週単位に進捗と品質の確認を行う 13

14 開発手法 2 開発チーム短期開発 (1 年以内 ): 最初から全員投入チームワークコミュニケーション PG の役割 :SE 補助作業業務習得先行開発若手エンジニアの業務ノウハウ修得の場朝会 ( スタントアッフミーティンク ): 短時間一人一人の進捗と予定の報告ダイナミックな作業割り振り ( 朝会で調整前提 : 全員が同一な業務ノウハウ ) 複雑な業務では不可能である 3 テスト駆動開発テスト手続きの登録 & 自動テスト ( 含むテストテータ登録 ) 効果 : 品質向上 ( テストの自動化 + ソースの最適化リファクタリング ) 単体機能テスト ( ロジックの内部仕様 ) 評価 : 活用 : ホワイトボックステスト ( モテルヒューコントローラモシュール単位 ) 繰り返し [ 1 テストケース登録ロシック記述 ( 数ステッフ ) リファクタリング ] 機能テスト ( 業務の外部仕様 ) 評価 : 活用 : ブラックボックステストユーザサイドのテストレグレッションテストの容易性ライフサイクルでの活用品質向上 14

15 開発手法 4 ソースレビューとペアプログラミング (1) 基本パターンソースレビューコーディング規約遵守第三者の目に触れることが重要タイミングは単体テストの終了段階開発者 : 中級レベル以上は単独開発が基本 (2) オプションペアプログラミング開発者 : 初級レベル (Rails 初心者新入社員アソシエイト業務初めて ) 早期立ち上げを目的に中級レベルのエンジニアがトレーナ役を担当しつまづきを最小化する初心者が質問しやすい環境を強制的に作る 15

16 ツール 5 プロジェクト管理開発ツール Ruby:1.9 + Rails:3.0 ( Ruby:1.8 + Rails:2.3 ) Arel(DB),CSS( 画面 ) Redmine Subversion NetBeans Cucumber 案件管理 ToDo Subversion ソース履歴管理 (Redmineと連携) NetBeans 開発ツール (IDE+ソースエティター) Cucumber 結合テストツール ( 画面単位外部 : ユーササイトテスト ) 日本語によるテスト仕様記述 Capistrano デプロイ ( 本番環境への更新モジュール反映 ) データベース新規開発 MySQL PostgreSQL 既存クラアントサーハシステムの Web 化 Oracle SQLSever の継続使用複合キーのサポート部品あり 16

17 ツール 6 外部ライブラリィの活用便利な部品の活用 ( ネット上 + 社内実績 ) 部品の活用度に応じて生産性品質向上部品の管理が重要帳票ツール活用ノウハウ逆引き更新情報ライセンス MIT 実績プロジェクト利用者使用上の注意事項 Ruby/Rails のハーション等例 :Pagenation 帳票画面の一覧表および次ページ送りの部品ライブラリィ : GEM パッケージ Rails プラグイン Java 用 :JasperReports(iReport) Rubyより利用可能 Ruby 用 :ThinReports( 帳票エティタヒューア :PxDoc) オーフンソースでマツケイより提供 (TPJ グループ企業 ) 将来構想 :HTML5ヒューア開発 PDF 化機能 17

18 繰り返し回数の最適化業務ノウハウ習熟度高低繰り返し頻度のグラフ低多最多少多多少最少少プロジェクトチームの開発経験度 (Ruby/Rails アフリ新技術を含む ) 高最少 : プロト開発設計工程での実画面相当の画面を作成し顧客確認 ( 操作性 ) 1 回 ( 設計 + 実装 ) 少 : スパイラル開発サブシステム単位設計 1 回実装 2~3 回基本設計 1 回 2~3 回 ( 詳細設計 + 実装 ) 1 回目は主要画面中心多 : アジャイル開発基本設計 1 回 n 回 ( 詳細設計 +m 回 ( 実装 )) 最多 : アジャイル開発 = 無謀実装 : フロクラミンクテスト結合テスト + 顧客確認第三の軸顧客要件や利用者ニーズの変化のスピード変化の速いネットビジネスなどは変化を吸収するフェーズ ( 繰り返し ) を当初計画に盛り込む 18

19 新システム分野への展開 Ruby 業務システム開発初期コストが少ない全てオープンソースで構築できる (DB も ) テストが容易である Rails + アジャイル短期繰り返し開発非定型の業務へ EXCEL を使った統計分析の報告業務担当者の交替により継続性がなくなる定期的な報告時の基礎データをシステム化し継続性のある報告 ( 質の向上 ) エビデンスのための定期的な記録作成点検ヒアリング ( 機械類システムプロジェクト組織企業 ) をシステム化し時系列分析や情報の見える化が可能基幹の業務から外れたものトラブル報告問題点管理派遣社員の作業時間管理的確な指示指導改善へ ( ホワイトカラーの生産性向上 ) 19

20 システム提供側の変革イノベーション Ruby アジャイル開発を業務システムに適用顧客創造これまでシステム化の対象範囲から外れていたものをシステム化の新分野として新しい顧客を創り出してくれるビジネス拡大オープンソースの活用技術 ( リテラシィ ) アジャイルによる業務システム開発新システム分野へのチャレンジ 20

21 Ruby の広がり 1 米国で認められた製品の逆輸入 ( 海外で認知 ) 2 競争激化によるコストダウン要求有償ソフトから無償あるいは低価格ソフトへ OSから言語まですべてのミドル製品がオープンソースで揃う 3 国の支援 ( 世界で通用する国産技術 ) 経済産業省 (IPA) や総務省の支援国地方自治体での調達指針 2006 年総務省ガイドライン : オープンな標準製品 2011 年 3 月 JIS 化完了 4C/SシステムをWeb 化するタイミングクラウドサービスの時代 5 Ruby/Rails の業務システム開発標準 21

22 ご清聴ありがとうございました 22