気がついたら Ruby...

Copyright 2011 FUJITSU SOCIAL SCIENCE LABORATORY LIMITED

気がついたら Ruby で製品を作ってました　～ Rubyを使ったパッケージ “ききマネージ” 開発顛末記～

２０１１年９月６日

株式会社富士通ソーシアルサイエンスラボラトリ第一キャリアビジネス本部業務ソリューション部

堀部　貴之

1 Copyright 2011 FUJITSU SOCIAL SCIENCE LABORATORY LIMITED

 第一部 Ruby（Ruby on Rails）との出会い

 第二部アジャイル開発による「ききマネージ」製品開発

 第三部 Rubyインタフェースを持つミドルウェア開発

 まとめ

アジェンダ


第一部 Ruby（Ruby on Rails）との出会い


Ruby（Ruby on Rails）との出会い

 アジャイル勉強会の実践（Ｓｔｅｐ０）  期間：2008年3月～ 2008年9月

 概要：Ruby on RailsによるWebアプリケーション開発

　　　　　（自社製品「ききマネージ」の前進）

 「ききマネージ」社内システム開発（Ｓｔｅｐ１）  期間：2008年10月～2009年３月

 概要：Ruby、Ruby on Railsによるアプリケーション開発

 「ききマネージ」製品開発（Ｓｔｅｐ２）  期間：2009年４月～ 2010年6月

 概要：Ruby、Ruby on Railsによるアプリケーション開発


Ruby（Ruby on Rails）との出会い

 Ｒｕｂｙインタフェース開発

 期間：2009年7月～現在

 概要：Ruby拡張ライブラリによるRubyインタフェース開発


第二部アジャイル開発による「ききマネージ」製品開発～Rubyアプリケーション開発～


「きき」とは？

情報漏洩災害

ＰＣ携帯電話・ＰＨＳ可換媒体

機　器

紛失危　機

「機器」を管理し「危機」を未然に防ぐ

「危機」発生時の内部統制を支援し迅速かつ的確な対応を可能とする


ききマネージとは何か？


小額資産は管理されていない?

機器の小型化による情報漏えいの危機

根絶することが難しい紛失事故

モバイル機器紛失は身近な脅威

居酒屋又置厯忘れ？

電車内双置厯忘れ？タクシーに置き忘れ?

どこかに忘れた!

身近に迫る紛失の危機


モバイル機器管理の苦労

支店探すのが大変

管理者

負担が集中

責任問題

情報漏えいの危機

各部署を訪れての現品確認

移動する機器は管理しづらい

紛失しやすく、気づくのも遅れやすい

大事な小額資産みえないわからない


みんなで管理する

さぼってるな

クロスチェック

あります

見える化

小額資産管理

　ききマネージ　

自分のモバイル機器を

みんなでクロスチェック

みんながセルフチェック

みんなに”見える化”


紛失の可能性を減らす

ききマネージ

携帯電話から簡単にチェック

チェック状況を確認

こまめな定期チェックの支援

携帯電話のWEBブラウザからチェック

ききマネージからの自動電話でチェック

ききマネージ：http://www.fjssl.co.jp/products/package/kiki-manage/


「ききマネージ」本体機能全編にわたり、Rubyを利用

Redhat Enterprise Linux 5.x (IA-32)

Apache Httpd

Passenger (mod-ruby)

Postgre SQL

Asterisk

AMI AGI

Ruby

ｊQuery Prototype

.js Ruby on Rails

「ききマネージ」アプリケーション(Ruby)

「ききマネージ」の構成


「ききマネージ」開発の経緯

アジャイル勉強会社内システム開発

Step0

＜社内ベンチャー・オーディション＞社内システム開発の予算化

＜社内ビジネス・コンベンション＞製品開発の予算化

製品発表（2010/5）富士通フォーラムへ出展

3月 6月 9月 2008年 3月 2009年 2010年

Step1 Step2

製品開発勉強会Ｒｕｂｙ実践

＜富士通SSLベンチャー制度＞事業化したいアイデアを募集し

予算を付けサポートする


アジャイル勉強会（Step０）

 勉強会

 社内の有志を募り、アジャイル勉強会を開催

　→アジャイル開発手法の調査・情報共有

 アジャイル開発を実践してみよう！

　→アジャイル開発によるシステム開発の実践へ

 アジャイル開発に適してる開発言語は？

　→Ruby on Railsは評判が良い


アジャイル開発をなぜやってみようと考えた?

 手戻り

 お客様は必ず仕様変更する！

 仕様変更すると工程をさかのぼって仕様書から修正し直し、

　テストもやり直し

 無駄な仕様

 最初にあれもこれもいると詰め込み仕様

 でも完成した頃にはいらない機能･･･

引用元: http://www.atmarkit.co.jp/im/carc/serial/redge/72/01.html


アジャイル開発の価値

 価値  プロセスやツールよりも個人と対話を重視する  包括的なドキュメントよりも動くソフトウェアを重視する  契約交渉よりも顧客との協調を重視する  計画に従うことよりも変化への対応を重視する

　我々はソフトウェア開発のプロとして　　　左辺も大事だが、右辺により価値をおく

http://www.agilemanifesto.org/iso/ja/


アジャイル開発の原則

 原則（抜粋）

 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

 動くソフトウェアを、2～3週間から2～3ヶ月というできるだけ短い時間間隔で提供します。

 等・・・

http://www.agilemanifesto.org/iso/ja/principles.html


アジャイル開発とは

リリース機能A

リリース機能Ｂ

リリース機能C

リリース機能D

リリース機能E

リリース機能F

3ヶ月  アジャイル（俊敏な）開発

2週間/イテレーション設計、製造、テスト

機能A機能B機能C機能D機能E 機能F

要件A 要件B

要件C 要件D

要件E 要件F リリース要件

要件A 要件B 要件C 要件D 要件E 要件F

業務にすぐ投入!

全要件を詳しくは決めておか

ない

思っていたのと違う…

手戻り･･･

変化していくビジネス環境

 ウォーターフォール開発

要求定義　　基本設計　　詳細設計　　製造・単体テスト　　結合テスト　　総合テスト　　受入テスト


Step0. アジャイル勉強会


開発概要（Ｓｔｅｐ０）

 開発内容

 「ききマネージ」のWebアプリケーション開発

• Web画面で携帯電話、USBなどの小額資産の所持確認ができる機能

 開発言語

 Ruby on Rails •  Ruby on Railsは初体験！（初心者）

 開発手段

 XP • １週間のイテレーション開発

＜ききマネージWeb画面＞


開発体制（Ｓｔｅｐ０）

顧客上司／社内システム担当者

開発チーム (３～５人　「ききマネージ」PJ)

要員D 要員B 要員E

要望

（

吐吟ー

呁抽出）

吐吟ー

呁決定

（

計画吉ー

吷）

要員Ｃ

開発（設計、実装、テスト）

提供

（

受入吝吐吟）

1週間（1イテレーション）

・・・

リーダA


開発成果（Ｓｔｅｐ０）

  Ruby on Railsの特徴を利用し、短期間で開発することができた

  Ruby on Railsの特徴

1.  コード自動生成

　　コマンド一発で、開発の枠組み（ＭＶＣ）が自動生成

2.  ＣｏＣ：設定より規約

　　ムダな設定が不要

3.  ＤＲＹ：Don’t Repeat Yourself

　　同じ処理を繰り返し実装しない

  社内ベンチャー・オーディションで、Webアプリケーションのデモを交えたプレゼンテーションを行うことで、効果的にアピールできた

  →社内システム開発の予算を頂いた


Step１. 社内システム開発




Step0




3月 6月 9月 2008年 3月 2009年 2010年

Step1 Step2





社内システム開発

 開発内容

 携帯電話の保管確認を自動化する機能

ききマネージ

①保管確認番号を

　あらかじめ登録

③個人の認証番号を入力

②自動発信・IVR応答

④保管確認が完了

①個人の認証番号を登録

ＯＳＳのＰＢＸ（Ａｓｔｅｒｉｓｋ）

②保管確認用の電話発信電話発信データ更新

Ｒｕｂｙで電話発信、およびデータ更新機能の開発を実施


アジャイル開発の手法

アジャイル開発

XP(エクストリームプログラミング)

Scrum開発・・・その他　OpenUP、AUP、

DSDM、リーンソフトウェア開発、アダプティブソフトウェア開発、Rational Unified Process（RUP）、MSF、FDD、

クリスタルクリア、EssUP 等


XP（エクストリーミング・プログラミング）

 様々なプラクティスの集合体

 計画ゲーム

 テスト駆動開発（テストファースト）

 ペアプログラミング

 リファクタリング

 コードの共同所有

 等･･･

短期間で変化に対応するための様々な工夫(ベストプラクティス)集


開発体制（Step0から継続）

顧客上司／社内システム担当者

開発チーム (５～１０人　「ききマネージ」PJ)

リーダA

要員Ｉ要員B 要員Ｊ

要望

（

吐吟ー

呁抽出）

吐吟ー

呁決定

（

計画吉ー

吷）

要員Ｃ

開発（設計、実装、テスト）

提供

（

受入吝吐吟）

1週間（1イテレーション）

・・・

ＸＰの実践


開発成果（Ｓｔｅｐ１）

  Ruby on Railsとの連携機能の実装に苦戦   Webアプリケーション開発（Ｓｔｅｐ０）

•  Ruby on Railsの仕組みを知らなくても実装できた

  Rubyアプリケーション開発（Step1）

•  Ruby on Railsのレールから外れた機能（Web以外の機能）の拡張時にRuby、およびRuby on Railsの中身（実装）に関する知識が不足していることを痛感した

　　例えば・・・メソッドが動的に定義されるため、メソッド呼び出しのつもりがローカル変数への代入と解釈され、データが保存されなかった、など。

  ペアプログラミングやコードの共同所有を行い、チーム内でRubyに対する知識を共有することができた

  →Rubyの習得に役立った


反省点（Ｓｔｅｐ１）

  チーム体制   リーダが顧客との仕様調整～作業・進捗管理を実施していたた

め、開発機能の拡張に伴い、作業負荷が増大！   メンバに適切に作業を割り振ることができず、イテレーションごと

に動くソフトウェアを提供することができなくなった

  ＸＰの実践結果   計画ゲーム：○   テスト駆動開発（テストファースト）：△   ペアプログラミング：○   リファクタリング：×   コードの共同所有：○


Step２. 製品開発




Step0




3月 6月 9月 2008年 3月 2009年 2010年

Step1 Step2





開発概要（Ｓｔｅｐ２）

 開発内容

 製品化へ向けた機能改善

 テスト駆動型（テストファースト）開発とリファクタリングの実践

 開発言語

 Ｒｕｂｙ、Ruby on Rails

 開発手段

 XP＋Ｓｃｒｕｍ開発


アジャイル開発の手法

アジャイル開発

XP(エクストリームプログラミング)

Scrum開発・・・その他　OpenUP、AUP、

DSDM、リーンソフトウェア開発、アダプティブソフトウェア開発、Rational Unified Process（RUP）、MSF、FDD、

クリスタルクリア、EssUP 等


Scrum開発とは

プロダクトバックログスプリントバックログバーンダウンチャート

PO SM Team

デイリースクラム

スプリントプランニング

スプリントレビューふりかえり

出荷

役割

道具

儀式

スプリント


Scrum開発の役割

 プロダクトオーナ

 ビジネス視点で製品（価値）に対する責任を持つ

 プロダクトバックログの管理（優先順位付け）

 スクラムマスター

 チーム内外のファシリテーション

 外部との折衝

 チーム

 ５～６人の開発チーム

 実装とテスト

 作業プロセスと作業結果の責任を持つ


Scrum開発とは

プロダクトバックログスプリントバックログバーンダウンチャート

PO SM Team

デイリースクラム

スプリントプランニング

スプリントレビューふりかえり

出荷

役割

道具

儀式

スプリント


Scrum開発の道具と儀式

 マネジメントプロセス／プラクティス

 スプリント

• ２～３週間のイテレーション

 プロダクトバックログ

• 優先順位付けされた要件リスト

 スプリントバックログ

• スプリントで実行する作業リスト

 スプリントプランニング

• スプリントバックログを作成するミーティング

 デイリー・スクラム

• 毎日定時にミーティング（朝会）

 スプリントレビュー

• スプリント終了時の受入


Scrum開発の価値

 確約

 約束したことを確実に実現すること

 専念

 確約したことの実現に専念すること

 隠さない

 たとえ自分に不利なことであっても隠さないこと

 尊敬

 自分と異なる人に敬意を払うこと

 勇気

 確約し、隠さず、敬意を払うために勇気をもつこと


Scrumプロジェクトの体制

プロダクトオーナー上司ステークホルダー社内シス担当者

部門管理者

IMS推進責任者

部門管理者部門管理者

IMS推進責任者 IMS推進責任者

ザ・チーム (2～4人「ききマネージ」PJ)

スクラムマスター兼任要員A

要員D 要員B 要員C 要員E

要望

問合わ厽

同吴ー

吟

営業

社外顧客

営業

要望

吮呄吗吆吟

吧吚吆呄吇

吐吟ー

呁ー

、

見積、実装

社内調整、意見集約

社外顧客社外顧客

社内リリース

アジャイル啓蒙


開発成果（Ｓｔｅｐ２）

  チーム（自己組織化）として開発を行うことができた   Ｓｃｒｕｍ開発に注力することで、テストファースト、およびリファクタ

リングを確実に実践することができた

  ソースコードの保守性が向上し、「ききマネージ」の製品化を実現できた

  ＸＰの実践結果   計画ゲーム：◎   テスト駆動開発（テストファースト）：○   ペアプログラミング：◎   リファクタリング：○   コードの共同所有：◎


アジャイル開発のメリット

 重要なものを優先して実装することが可能  製品の「価値」が高いものから開発することができる

 ソフトウェアを早期にリリースすることが可能  イテレーション単位に動くソフトウェアを提供するため、すべての機能が実装されていなくてもシステムの運用を開始できる

 すべての要件定義が確定している必要がない  イテレーション開始時までに要件を確定しておけば良い  確定した要件に問題があってもフィードバックのコストが低い

パレートの法則（80対20の法則）「システムが重要としている20%の部分を優先的に実装することができれば、システムとしての存在価値は十分に保たれる」


アジャイル開発を失敗するコツ

 1.スピード感が無い

 2週間以内に動くモノが作れないと破綻!!

 2.テストを全部手動で行う

 繰り返し機能を継ぎ足し開発するので、デグレード確認試験を繰り返す工数が後になるほど大変なことに!!

 3.リファクタリングしない

 繰り返し機能を継ぎ足し開発するので、後になるほど増築を繰り返した家屋のように倒壊しやすいものに!!


アジャイル開発で

Ruby on Railsを使用した感想


(1)スピード感


スピード感

アジャイル開発には短期繰り返しを実現するための

スピード感が必要

Ruby on Railsのスピード感が最適!


スピード感

Ruby on Railsはなぜスピード感があるのか!?

コードの自動生成 CoC: 設定より規約

DRY: Don’t Repeat Yourself


スピード感

Rubyなんてできるヒトいないよ!

OSS(無料)のフルスタックフレームワークなのですぐに始められる


スピード感

 Ruby技術者認定試験制度

 弊社（富士通SSL）ではわずか6ヶ月で

• Gold 11名

• Silver 33名 • ※現在もどんどん増加中!

 Ruby Association Certified System Integrator Gold 認定済み •  http://www.ruby-assn.org/ja/certification/sierlist.htm

Ruby技術者はどんどん増える!


(2)テスト駆動開発


テストの枠組みも自動生成

 コマンド一発でモデル、コントローラ、ビュー、そしてテストまでの枠組みが自動生成される

% script/generate controller


テスト駆動開発

 プログラム本体よりも先にテストケースを書くスタイル

 Ruby on Rails (RUnit)で自動テストを先に書く

"  テストデータ(fixture)、テストコードを用意する作業はかなり手間がかかる

"  しかし、具体的にテストコードを書くことで、設計の検証になった


テスト駆動開発

 Hudsonで毎日自動テストを実施

"  テストが通る(パスする)ことで、コーディングしたものが正しく動作すること、デグレードがないことが常に確認できる


(3)リファクタリング


リファクタリング

 スクリプト言語なので、修正したらすぐにテストできる

 ＣｏＣやDRY原則により、同じことを書くのにJavaより短く書けるため、修正ステップ数が少ない

 ダックタイピングや動的型付けにより柔軟な変更が可能 (JavaでいうInterfaceが不要！)


したがって Ruby on Railsは

 1.スピード感がある

 2.テストを自動化しやすい

 3.リファクタリングしやすい

変化を受け入れ易い

Ruby on Railsはアジャイル開発に最適


悩ましいところ

 ドキュメントがまだまだ弱い  ＣｏＣなのに整備された規約リファレンスが無い

 汚く書こうと思えばやはり汚くかけてしまう  →最低でも構造化プログラミング、オブジェクト指向の考え方での設計は必須


第三部 Rubyインタフェースを持つミドルウェア開発～Ruby用インタフェース開発～


開発概要

 クライアント／サーバ型のシステム（ミドルウェア）開発を実施

＜システム構成＞

クライアント

Cアプリケーション C-I/F

Cアプリケーション C-I/F

サーバ

Ruby-I/F Rubyアプリ C-I/F

Cアプリケーション（ミドルウェア）

 Rubyアプリ向けのインターフェース（I/F）開発を担当

Rubyアプリからも利用できるように C-I/Fのwrapperとして

Ruby-I/Fを提供


Rubyインタフェース開発

 RubyはC言語で開発

 Rubyには機能を拡張するための拡張ライブラリ

 Ruby I/Fは拡張ライブラリを使用してC言語で開発

 開発で使用しているRubyのバージョンは1.8.7

 Ruby1.8系はGreenスレッド


C言語とRubyのスレッド動作の違い

 C I/F（C言語）の場合

 Ruby I/F（Ruby）の場合

CPU1

CPU1

CPU2

スレッド1

スレッド2

スレッド1とスレッド2は CPU1とCPU2で並列して処理される

POSIXスレッド

スレッド1とスレッド2は CPU1で時分割で処理される

Greenスレッドスレッド1 スレッド2 スレッド1 スレッド2

スレッド3

CPU2

処理の切り替え（コンテキスト）を OSが実行

処理の切り替え（コンテキスト）を Rubyが実行

スレッド1 スレッド2 スレッド1 スレッド2

スレッド1

スレッド2

処理待ち（Ｉ/Oなど）

処理待ち（Ｉ/Oなど）


Green Threadの並列動作の実現

 処理の切り替え（コンテキストスイッチ）をＲｕｂｙの実装レベルで制御

 適切に設定しないと、処理効率が悪くなる

クライアント

①データ生成

②データ送信

③データ受信

サーバ

データ受信

データ処理

データ送信

④処理終了

例えば・・・



クライアント

①データ生成

サーバ

データ受信（１）

データ処理（１）

データ送信（１）

GreenThread1

②データ送信

③データ受信

④処理終了

⑤データ生成

⑥データ送信

⑦データ受信

⑧処理終了

データ受信（２）

データ処理（２）

データ送信（２）

コンテキストスイッチ

処理待ち

GreenThread2



 問題

  I/Oなどの処理待ちが発生する処理（システムコール）を実行すると、Ruby上の全ての処理がブロックされてしまい、Green Thread の並列動作を実現できない

 対策

 待ちが発生する処理（システムコール）をTRAP_BEG/TRAP_ENDで囲む

 リトライ処理を追加

Ruby実行環境（Ruby Main Thread）

Ruby用timerスレッド（Pthread）

GreenThread-1 GreenThread-2

TRAP_BEG

システムコール

TRAP_END

10msごとに

SIGVTALRM を送信

条件②：シグナルによる割り込み

条件①：フラグをオン

割り込みエラーをチェックし、コンテキストスイッチを実行



クライアント

①データ生成

サーバ

データ受信（１）

データ処理（１）

データ送信（１）

②データ送信

⑤データ受信

⑥処理終了

③データ生成

④データ送信

⑦データ受信

⑧処理終了

データ受信（２）

データ処理（２）

データ送信（２）

処理待ち

GreenThread1 GreenThread2

スレッド1の処理待ち中にスレッド2の処理を実施することで処理効率が良くなる


その他、苦労話

 Ruby GC（Garbage Collection）との不整合

 RubyのGCにより、Ruby Native Thread以外のPthreadで使用中のメモリ領域が開放されてしまった

 Green Thread 間の同期処理の実現

 クライアントの処理はPthread上での並列動作を前提としていたため、Green Thread 間の同期（待ち合わせ処理）でデッドロックが発生した

 他にも色々


まとめ

 Ruby 拡張ライブラリを使用することで、Rubyに対する知識を深めることができた

 Rubyを「使う」ための情報は多いが、「作る」ための情報は少ないと感じた

 Rubyのソースを点検し、動きを確認しながら開発を実施してきたため、時間がかかった

 トラブル発生時の解析に時間がかかった

 Rubyの問題？Ruby-I/Fの問題？の切り分けが難しい

 Rubyのソースにデバックを追加し、処理をトレースしながら解析を実施してきた

Rubyは日本発のプログラミング言語として初めて

JIS規格化されており、ミドルウェア開発の分野でも期待！


まとめ


終わりに

 Rubyアプリケーション開発

 Ruby on Railsを採用し、素早く開発を行うことができた

 Ruby、およびRuby on Railsは、アジャイル開発に適している

 一方、課題としてオブジェクト指向等のスキルが足りないとソースの保守性が落ちてしまうこともある

 Rubyインタフェース開発

 ミドルウェア開発でも、Rubyを活用することができた

 しかし、Rubyを「作る」ための情報が少ないため、開発に時間がかかった

所感として・・・ Rubyは「作る」ものではなく「使う」もの


謝辞

Ruby開発者・有識者の皆様に感謝すると伴に

今後の更なるご活躍を期待しております。

気がついたら Ruby...

Documents

Transcript of 気がついたら Ruby...