1

「Ruby ビジネスモデル研究実証事業」

全体報告書

平成 23年 3月 31日

島根県

2

目次

1. 開発実証の目的 ........................................................... 3

1.1. 実証事業の背景、目的 .................................................... 3

1.2. Ruby言語の特徴 ......................................................... 3

1.3. 公募内容 ................................................................ 4

2. 実証事業の提案概要 ....................................................... 4

2.1. 提案概要 ................................................................ 4

2.1.1. 実証事業の対象システム .................................................. 4

2.1.2. ビジネス特性 ............................................................ 7

2.2. 提案された開発手法のあり方 .............................................. 8

2.3. 反復漸進・顧客参加型の概要 .............................................. 8

3. 各事業者の実施結果 ...................................................... 20

3.1. 実施体制 ............................................................... 20

3.2. 実施スケジュール ....................................................... 22

3.3. 実証する Rubyを使った開発手法 .......................................... 22

3.4. Ruby言語の有効性と課題 ................................................ 25

3.5. 開発環境の有効性と課題 ................................................. 26

3.6. 実証した開発手法、プラクティスの有効性と課題 ........................... 28

3.7. 実施体制の有効性と課題 ................................................. 33

3.8. ユーザー満足度に及ぼす有効性と課題 ..................................... 35

3.9. 品質・信頼性及び開発管理に及ぼす有効性と課題 ........................... 37

3.10. 顧客の意見 ............................................................. 39

3.11. Rubyの特徴を活かす開発手法の今後のビジネス利用の可能性と活用分野 ...... 41

3.12. Rubyの特徴を活かす開発手法の今後のビジネス利用での課題と克服策 ........ 43

4. 総括 .................................................................... 48

4.1. Ruby・反復漸進・顧客参加型開発の特徴と顧客満足度の関連 ................. 48

4.2. 課題とアドバイザリーボードからの提言 ................................... 50

5. Rubyビジネスモデル研究実証 アドバイザリーボード事業について ............ 55

5.1. アドバイザリーボード事業の委託先 ....................................... 55

5.2. アドバイザリーボード事業の研究会メンバー ............................... 55

3

1. 開発実証の目的

1章では、本事業における目的に照らし、県から何を公募したのか、を記載する。

1.1. 実証事業の背景、目的

昨今の厳しい経済不況の中では，ソフトウェアを利用する顧客が IT 投資を抑制する傾向にあり，オー

プンソース・ソフトウェアの利用や，真に必要とされる，価値ある機能に限った開発が求められている。

特に近年は，ビジネス環境の変化のスピードが増しており，顧客ニーズに迅速に対応し，また，顧客ニ

ーズの変化に柔軟に対応できる開発が求められている。

しかしながら，従来のソフトウェアの開発手法では，必ずしもこのような課題やニーズに対応出来て

いるとは言えない状況であり，より顧客ニーズを俊敏に実現し，継続的に柔軟にシステムを改良できる

開発手法の検討が急がれる。

このような市場動向の中で，島根県ではプログラミング言語 Ruby を軸とした IT 産業振興施策に取り

組んでいる。プログラミング言語 Ruby の特徴を活かし，顧客ニーズを素早く的確に捉え，顧客満足度

を高めるための開発手法を明らかにすることで，前述の課題に対する解決策に繋がり，更には，県内企

業の競争力の強化と，顧客からの直接受注により下請構造から脱却し，元請へと構造転換することが期

待される。こうした新しいビジネスモデルの創出とそのモデルを実践できる県内企業の登場が必要とさ

れる。

1.2. Ruby言語の特徴

Ruby言語の特徴として，主に以下の４点を挙げることができる。

① オブジェクト指向

Ruby は，純粋なオブジェクト指向言語として設計されており，すべてのデータをオブジェクトとして

統一的に取り扱うことができることが特徴である。

したがって，オブジェクト指向の特徴を活かし，テストし易いモジュール分割が可能となり，継続的

な改良を容易に行うことが可能となる。

② 動的型付け

Ruby は，プログラムの実行時に型が決まる動的型付け言語であるため，実行時にクラスの情報を取得

したり書き換えたりできるリフレクションが容易に実現でき，プログラムが簡素になることが特徴であ

る。

したがって，動的型付け言語の特徴を活かし，柔軟なプログラミングが可能となり，柔軟な改良を容

易に行うことが可能となる。

③ インタプリタ型

4

Ruby は，コンパイル無しで書いてすぐに実行できるインタプリタ型の言語であるため，手軽にプログ

ラムを試すことができることが特徴である。

したがって，インタプリタの特徴を活かし，素早く動作確認することが可能となり，俊敏な要求の確

認を行うことが可能となる。

④ シンプルな文法

Rubyは，オブジェクト指向に基づいた一貫した文法を持っている。Javaや C#に比べ，非常にシンプル

で一貫性のとれた記述ができるため，可読性や保守性が高いことが特徴である。

従って，シンプルな文法の特徴を活かし，可読性の高いシンプルなプログラミングを行うことにより，

高い保守性と生産性を維持して継続的かつ俊敏な改良を行うことが可能となる。

1.3. 公募内容

事業目的を基に、以下の公募を行った。

① 近年のビジネス市場の傾向を踏まえ，顧客のニーズに応え，顧客の視点に立ったソフトウェア提

供サービスを実現することを目的に，プログラミング言語 Rubyの特徴を活かした開発手法を提案

すること。

② 提案する Rubyの特徴を活かした開発手法が，「1.1実証事業の背景、目的」で示すソフトウェア提

供サービス業が抱える課題，県内 IT産業が抱える課題の克服にどのように影響を及ぼすかについ

て提案すること。

③ 提案する Rubyの特徴を活かした開発手法が適しているビジネス特性を明らかにし，また，今回の

実証事業で取り組む対象システムを具体的に提案すること。

④ 提案者が，今回提案する Rubyの特徴を活かした開発手法を，今後どのようにビジネスに活用する

のかについて，顧客から直接開発案件等を受注する元請企業化目指すことを前提として，その取

組を具体的に提案すること。

⑤ 今回提案する対象システムの，今後のビジネス市場における収益性，拡大可能性を提案すること。

⑥ 提案者が，今回の実証事業の対象システムのユーザと，どういった体制で実施するのか，具体的

に提案すること。

⑦ 今回の実証事業において，顧客満足度の有効な評価手法について提案すること。

⑧ 今回の実証事業において，品質，信頼性及び開発管理に対する評価手法を提案すること

⑨

2. 実証事業の提案概要

2章では、県からの公募に対して、どのような開発手法の提案があったのかを記載する。

2.1. 提案概要

2.1.1. 実証事業の対象システム

5

① テクノプロジェクト

テクノプロジェクトが実証開発する対象としたのは出雲村田製作所の「日常点検システ

ム」である。出雲村田製作所では、工場内の設備点検を日常的に実施しているが、従来は

担当者が紙とペンを持ち、手書きにて点検項目の記録を行っていた。この業務運用では、

以下の課題が発生していた。

記入作業の負荷

紙の保管

結果集計の困難性

結果追跡の困難性

これらの課題を解決するために、日常点検結果のデータベース化を図り、日常点検に

関連する業務のシステム化を行う。

このシステム化により出雲村田製作所では、ひと月あたり 1200万円のコスト削減を目

標としている。さらには、ムラタグループ他拠点への展開も視野に入れている。

② NaCl

NaClでは以前よりレセプトコンピュータシステムの開発を行っており、その開発の経

験・ノウハウを基に、昨今注目を浴びているクラウド環境上などで構築する Webサービ

スとして医療機関へ何かサービスを提供できないかと模索していた。

医療機関によっては、診療に関する情報がレセプトコンピュータシステムに蓄積され

ている。この情報を基に、分析した結果を診療方針の策定に利用することができると考

え、世の中のレセプトコンピュータシステムを利用する医療機関をターゲットに、付加

機能として診療情報を分析するシステムを提供することが出来ないかを考えた。

なお、こういった分析を行うシステムはレセプトコンピュータシステム毎に専用のオ

プション機能として存在したり、パッケージとして販売されたりしているのが一般的で

あった。

③ プロビズモ

プロビズモが実証開発する対象としたのは「益田永島学園明誠高等学校向けの通信課程

向け教務システム」である。通信課程向け教務システムは一般的な全日制のそれとは異な

り､生徒毎に異なるカリキュラム(履修計画)を作成し､スクーリングやレポートの結果よ

り成績を導き出す必要がある｡また､出欠の概念も無く､従来の全日制教務システムの拡張

としての構築は困難であった｡

④ 日本ハイソフト

㈱メディアスコープ（島根県松江市）は、平成２０年度に総務省より採択を受けた「ユ

6

ビキタス特区」の中で行っている、次世代放送通信技術である MediaFLO と非接触 ICカー

ド技術「Felica」を搭載した「あいポケット」（８つ機能を備えることができ、複数の店

舗や施設でポイントを１枚のカードで対応できる。電子マネーWAON機能も搭載可能。）

を活用し、回遊性動向などの可視化とこの結果を受けた販促支援サービスを志向してい

る。

そこで、㈱メディアスコープが志向している店舗の販促支援サービスについて、専用

カードリーダ端末を通じて得られた情報について、CRMとビジネスインテリジェンス（BI）

によりマイニングすることで、店舗の販売促進や新しい地域振興策の立案などに役立て

ることができるシステムを開発する。

今回の実証実験で開発するシステムは、会員向けサービスと、店舗側及び経営分析シス

テムである。前者は、「FeliCa」を搭載した会員カードに会員が加盟店舗、施設等で購買

活動をする度に、購買ポイントを付与し、そのポイントに応じて加盟店等でサービスを

受けられる仕組みであり、後者は、会員カードの情報から、そのポイント利用状況につい

て分析し、加盟店での販売戦略等の参考となる解析ができるシステムである。最終ユーザ

ーである加盟店等へのサービスインを行いながら、その結果をフィードバックし、継続的

にシステムを開発することとした。

7

2.1.2. ビジネス特性

以下に、実証事業における対象システムのビジネス特性を記載する。

テクノプロジ

ェクト

NaCl プロビズモ 日本ハイソフ

ト

受発注形態 受託 自社パッケー

ジ

受託 受託

計画 or 探

索

計画・探索バラ

ンス型

探索型 計画重視 探索型

不確実性 ある程度予測

はできる

高い 見られない 高い

複雑性 見られない 見られない 見られない 見られない

高速適応性 見られない 見られない 見られない 見られない

各社理由は様々があるが、不確実性についてはある程度高いシステムが対象となっており、柔軟な対

応が求められる。複雑性、高速適用性は、今回の対象システムでは見られなかった。また、ビジネス特

性の詳細内容を以下に記載する。

① テクノプロジェクト

ユーザーである製造部門のフィードバックを得ながら、使用性の高いソフトウェアを開発す

る必要がある。

製造現場では常日頃より改善活動を実施しており、点検作業もその例外ではない。そのため、

日常点検システムについても、開発の過程で、その改善に対して柔軟に対応していく必要性

がある。

その不確実性は稼動後の運用段階においても想定されるため、高い保守性も求められる。

② NaCl

将来的なカスタマイズコストなどを最小限に抑えたい。

医療機関の要望を反映したシステムを開発するためには、医療機関の担当者が開発に参加し

て頂き、実際にどういったシステム・機能にニーズがあるかをヒアリングしながら開発する

必要がある。

早期なサービスインを実現する。

③ プロビズモ

早期にシステムを導入し、事業を軌道にのせる。

8

業務にマッチした機能を有するシステムの導入。

事業拡大に合わせて拡張できる柔軟なシステムの導入。

必要な機能が未知である。

④ 日本ハイソフト

作りたいものの概要は決まっているが、細部迄の仕様は決まっていない。

成果物を早く見たい。

仕様の途中変更もある。

2.2. 提案された開発手法のあり方

ビジネス特性より、不確実性の高い対象システムの構築に対して柔軟な対応が求められる。その為、

各社からは、以下の特徴を持った開発手法の提案があった。

① 反復漸進型であること

すこしずつ要求を確認しながら進めることができ，顧客ニーズに合ったシステムを実現することが可

能となるから。

② 顧客参加型であること

隠れた顧客ニーズを引き出しやすく，顧客ニーズに合ったシステムを実現することが可能となるから。

実証事業では、Ruby を用いて反復漸進型と顧客参加型な開発手法を採用した時に、顧客満足度にどの

ように寄与するのかを検証した。

2.3. 反復漸進・顧客参加型の概要

反復漸進・顧客参加型の開発手法として、以下がある。実証事業では、いずれかの開発手法やプラク

ティスを採用している。

① 反復漸進・顧客参加型の代表的な開発手法

反復漸進型で顧客参加型の特徴を持つ代表的な開発手法として Scrumと XP1があげられる。Scrumや XP

または Scrumと XPの組み合わせは，国際的な動きとしてアジャイル的な開発手法で行われているプロジ

ェクトの約 8割2を占めている。

また、採用率は 2%程度と尐ないが、大規模開発にも耐え得る開発手法として FDDがある。いわゆる「開

発」に特化した従来技法とは異なり、プロジェクト管理の手法も持ち合わせていることが特徴である。

1 Craig Larman, Agile and Iterative Development: A Manager's Guide, (Addison-Wesley Professional, 2003) [訳: 児高慎 治郎

ら, 初めてのアシ ャイル開発 ~スクラム，XP，UP，Evo て 学ふ 反復型開発の進め方~, (日経 BP 社, 2004)]

2 IPA 非ウォーターフォール型開発に関する調査結果 http://sec.ipa.go.jp/reports/20100330a.html

9

② 反復漸進・顧客参加型開発の特徴

反復漸進型で顧客参加型の開発手法の特徴として，主に以下の４点を上げることができる。

i. 可視性

従来型の開発手法の場合，開発の初期に要件定義を行い，最後に納品するまで状況が見えなくなるこ

とが多い。

反復漸進・顧客参加型開発の場合，イテレーション毎に打ち合わせリリースを行い，実際に動くソフ

トウェアを見て進捗を確認することができる。

ii. 技術リスク低減

従来型の開発手法の場合，最後までソフトウェアが動いているところを確認することができない。そ

のため，開発の後半になって各機能を一気に結合したときに動かないということがよくある。

反復漸進・顧客参加型開発の場合，最初のイテレーションから動くソフトウェアを作成し，徐々に機

能を追加してくため，最後になって結合してみて動かないということがない。

iii. 変更容易性

従来型の開発手法では開発の初期に要件を確定しなければならない。要件確定後に要件の変更があっ

た場合，大きな手戻りが発生する。

反復漸進・顧客参加型開発ではイテレーション毎に尐しずつ要件を受け入れていく。そのため，動く

ソフトウェアを確認しながら，要件を変更したり，優先順位を入れ替えたりすることができる。

iv. ビジネス価値

従来型の開発手法では最後の最後（顧客の受入テストが完了する時点）までリリースすることができ

ない。

反復漸進・顧客参加型開発ではイテレーション毎に動くソフトウェアを作成し，顧客が受入を行うた

め，開発の途中段階でも顧客が本番リリースする価値があると判断すれば，本番リリースすることが可

能である。

10

③ 反復漸進型開発の流れ

イテレーションは Scrum では 2～4 週間、XP では 1～3 週間が適度な長さとされている。イテレーショ

ンは、[見積りと計画作り] → [開発] → [デモとふりかえり] という大きな流れで進める。以降に、そ

れぞれの流れの説明を記載する。

i. 見積りと計画づくり

リリース計画ゲームないしはイテレーション計画ゲーム（後述）において、顧客は要求を出し、優先

順位付けを行う（優先順位付けされた顧客の要求リストをプロダクトバックログと呼ぶ）。開発者はプロ

ダクトバックログから優先順位の高い要求を選択し，顧客と一緒にストーリーを作成する。できたスト

ーリーに対して開発者は見積りを行う。ストーリーの見積り結果と開発チームの開発速度（ベロシティ

と呼ぶ）を照らし合わせ、開発者はイテレーションで実施するストーリーを顧客に対してコミットメン

トする。

11

ii. 開発

イテレーション中は日々のプラクティスを行い開発を行っていく。

Scrumを採用している開発チームは一般的に毎朝、スクラムミーティングを行い、開発のリズムをつく

る。

iii. デモとふりかえり

イテレーション終了後にはリリースを行い顧客からのフィードバックを受ける。また，顧客とともに

「ふりかえり」を行うことで，現状の問題を抽出し次イテレーションでの課題づくりを行い，チームの

改善活動を行う。

ふりかえりの進め方については「プロジェクトファシリテーション実践編：ふりかえりガイド 3」が参

考になる。

④ 顧客参加型開発のチーム体制

顧客参画型の開発手法では顧客を含めてチームであり，チームが開発に関する権限を持つことが望ま

れる。以下に Scrumでのチーム体制例を記載する。

i. 開発チーム

品質管理，プログラミング，データベース設計等の，専門的なスキルを有する，要求をリリース判断

可能なプロダクトの断片に変える。開発ベンダが請け負うことが多いが、近年、内製化の動きが進んで

おり、顧客側の担当者が開発チームに参画することもある。

3 http://www.objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf

12

ii. プロダクトオーナー

プロダクトで実現したい要求の管理に責任を持ち，チームが実施した作業を保証する。顧客が多数い

る場合でもプロダクトオーナーは基本的には 1 人である。顧客から出てきた要求の優先度や仕様に関す

る最終決定権を持ちチームに要求を依頼できる唯一の人である。具体的には、プロダクトオーナーは開

発者と共同でストーリーを作成する。また、リリース計画ゲームおよびイテレーション計画ゲームに参

加し、イテレーション（スプリント）で実装するストーリーについての開発チームからのコミットメン

トに対して承認を与える。プロダクトオーナーは顧客側の責任者が担当することが多い（ユーザー部門

の責任者が望ましいが、情報システム部の責任者であることも多い）。

iii. スクラムマスター

チームが正しくスクラムを実践出来ている事を保証する。そのためにプロダクトオーナーや開発チー

ムに対して様々な支援を行う。プロダクトオーナーと開発チームの間に立って、第三者的な立場で調整

事を行うことが求められるため、外部のコンサルタントに委託する例が増えている。

⑤ 反復漸進・顧客参加型の代表的なプラクティス

反復漸進型で顧客参加型の開発手法には様々なプラクティスがあり，それらを組み合わせて開発を行

う事で，顧客満足度の向上が図れる。以下に例として，IPA 非ウォーターフォール型開発に関する調査

の報告書より Scrumと XPのプラクティスを抜粋する。その他の開発手法やプラクティスは同報告書を参

照。

リリース計画ゲーム

顧客にとってソフトウェアの価値が最大になるよう，次

の運用リリースのスコープ（開発範囲）を定義。顧客が必

要な機能を説明するためにストーリーカードを書き，開発

者がその作業時間を見積もる。それから，顧客は次のリリ

ースでどのカードを実装するのかを選択する。

イテレーション計画ゲーム

顧客はイテレーションで実装するストーリーカードを選

択する。そのストーリーカードごとに，プログラマがスト

ーリを実現するためのタスクリストを(カードまたはホワ

イトボード上で)作成する。

小規模で頻繁なリリース 可能なら 1～3週間ごとにリリース。顧客はリリースごと

にフィードバックする。

システムのメタファ

設計をうまく伝えるために，システム全体や各サブシス

テムを覚えやすいメタファ（喩え）で表現し，主要なアー

キテクチャのテーマを描写する。

XP

13

シンプルデザイン

将来の変更の可能性を推測して設計しない。今すぐ必要

でない汎用のコンポーネントを作成しない。コードの重複

をなくし，クラスやメソッドか 比較的尐なく抑えられた，

簡単に理解できる設計をすべき。

テスト駆動開発 テスト対象のコードよりも、先に単体テストを書く。

受け入れテスト

全ての機能は自動化された受け入れ(機能)テストに組み

入 れる。受け入れテストは顧客と協力して作成する。顧客

はテストに使える内容の受け入れ基準定義書を作成する。

頻繁なリファクタリング 全てのテストが通ることを確認しながら，きめ細かいコ

ードや大規模な設計要素を単純化する。

ペアプログラミング

アプリケーションコードは必ず，2 人のプログラマが 1

台の コンピューターに向かって作成する。定期的に交代し

ながら交互にコーディングを行う。ペアは，タスクが変わ

れば頻繁に組みなおされる。見ている側の人は，リアルタ

イムコードレビューを行っていることになり，入力してい

る人よりも幅広い考えが出来る(テストなどについて考え

られる)。メンバーが相互に学習する。もっと規律を持って

プラクティスを遵守し，ダラダラせずにもっと多くの時間

を実際のプログラミングに割くよう仲間同士でプレッシャ

ーをかけ合う。リアルタイムのコードレビューによって欠

陥を削除できる。また、ペアの一人が行き詰まったときで

も先に進み続けられる根気と洞察力が保たれる。

共同所有権 チーム体が共同で全てのコードに責任を持つ。変更要求

を必要としないため，開発速度が向上する。

継続的インテグレーション

単体テスト・受け入れテストが存在し，継続的インテグ

レーションによって，コードに問題が起きたときには即座

にわかる。チェックインされたコードは全て，継続的に結

合テストが繰り返される。

持続可能なペース 時間外労働無しを基本とする。

チーム全体が一緒に 顧客にプロジェクト専任者を出してもらい，開発者と共

通のプロジェクトルームに常駐してもらう。

コーディング規約 コードの共同所有，頻繁なリファクタリング，ペアプロ

グラミンのパートナの頻繁な組み換えを行うためには，全

XP

14

員が同じコーディングスタイルに従う必要がある。

ふりかえり リリース後にチーム全体でイテレーションをふりかえる

事でチームの改善活動を行う。

ゲーム前計画

ゲーム前計画の期間中，利害関係者はだれでも，機能，

ユースケース，機能拡張，欠陥などの一覧を作成し，「プ

ロダクトバックログ」に記録することが出来る。プロダク

トバックログの所有者として一人のプロダクトオーナーが

任命され，要求はプロダクトオーナーを通じて取り決めら

れる。

スリント計画

各イテレーション(スプリント)を開始する前に，2 つの

ミーティングを続けて開催する。最初のミーティングでは，

利害関係者が集まって，プロダクトバックログとリリース

バックログの精度を上げ，優先順位を付け直し，今回のイ

テレーションの目標を決定する。優先順位は，通常最も高

いビジネス上の価値やリスクによって決定される。2 つ目

のミーティグでは，スクラムチームとプロダクトオーナが

集まって要求をどう実現するか熟考し，目標を達成するた

めのタスクを列挙した「スプリントバックログ」を作成す

る。イテレーションの作業が進むにつれ，スプリントバッ

クログは更新される。

原則 30 日のイテレーション 作業は原則 30 日(カレンダー上)のイテレーションに分

割。 それぞれをスプリントと呼ぶ。

スプリントバックログのグラフ

作成

スプリントバックログのタスクの推定残り作業時間をグ

ラフ にまとめたもの(バーンダウンチャート)。毎日スクラ

ムミーティングまでに，このグラフの更新版を壁に貼り出

すことが推奨されている。

自律的な組織化チーム

イテレーションの期間中，経営陣やスクラムマスターは，

イテレーションの目標をどのようにして達成するか，問題

をどのようにして解決するか，作業順序をどう計するかに

ついて，(判断を依頼されたり，報告された障害を取り除く

必要がない限りは)チームに口出しをしない。

スクラムミーティング 毎日，同じ時間，同じ場所で，チームメンバは輪になっ

てミーティングを開き，特定の同じ質問をして，各チーム

Scrum

15

メンバが、それぞれ答え、立ったまま行う。15～20分程度

で終わらせる。ホワイトボードの前で行い，報告されたタ

スクや障害はすべて書き留める。書き留めた障害をスクラ

ムマスターが消すのは，その障害が取り除かれた場合だけ

である。その場にいないメンバ－が参加できるように，ス

ピーカーで会話できる電話機を使う(参加は必須である)。

質問は次のとおり。

1.前回のスクラム以降，何を行ったか?

2.今から次回のスクラムまでに何を行うか?

3.イテレーションの目的を達成する上での障害は何か?

4.スプリントバックログに追加するタスクはあるか(新

しい 要求ではなく，忘れられていたタスク)

5.チームメンバから刺激を得て(技術的なこと，業務知識

などで)何か新しく学んだことはあったか?

イテレーションに追加してはな

らない

イテレーション期間中，経営陣はチームや個人に対して

作業を追加してはならい。中断されずに集中できるように

する。万が一何かを追加しなければならない場合は，代わ

りに他の作業をなくすのが理想である。

スクラムマスターのファイアウ

ォール

スクラムマスターは，チームが外部からの作業依頼によ

って作業を中断されないよう気を配る。中断された場合に

は，その原因を取り除いたり，政治的な問題や外部のマネ

ジメントの問題に対応したりする。

1時間以内の判断 スクラムミーティングで障害が報告され，スクラムマス

ターの判断が必要な場合には，即時に，あるいは 1 時間以

内に判断を下すのが理想である。「悪い判断でもないりはま

しだし，後で破棄することもできる」という価値が奨励さ

れている。

1日以内の障害除去 スクラムミーティングで報告された障害は，次のミーテ

ィグの前に取り除かれるのが理想である。

ニワトリとブタ スクラムミーティングの間はスクラムチーム(ブタ)だけ

が発言することが出来る。そのほかの人(ニワトリ)は，出

席 できるが黙っていなければならない。CEOも同様である。

7人のチーム 1 チームのメンバは最大 7 人にすることが推奨されてい

る。大規模プロジェクトでは複数のチームを編成すること

になる。

共通の部屋 チームは共通のプロジェクトルームで一緒に作業するの

が理想である。

Scrum

16

日次ビルド 尐なくとも 1 日 1 回，プロジェクトのチェックインされ

たコ ードをすべて統合し，回帰テストを行う。

スプリントレビュー 各イテレーションの最後には，スクラムマスター主催で

レビューミーティングを行う(最大 4 時間まで)。チーム，

プロダクトオーナー，その他の利害関係者が参加する。こ

のレビューでは製品のデモを実施する。レビューの目的の

一つは，システムの機能，設計，長所/短所，チームの作業，

今後の問題が置きそうな箇所について，利害関係者にらせ

ることである。

上記のプラクティスは様々な特性に影響しており、以下に品質特性の向上が望めるプラクティス、品

質管理・開発管理に関わるプラクティス、顧客参加が推奨されるプラクティスの一覧を記載する。表中

の背景色が赤色のプラクティスはエンジニアプラクティスと呼ばれており、品質特性・品質管理・開発

管理に強く影響を及ぼす。

Scrum

17

品質特性 品質管理 開発管理 顧客参画機能性向上 信頼性向上 使用性向上 効率性向上 保守性向上 移植性向上 統合管理 スコープ管理 コスト管理 品質管理 リ スク管理 外注管理 計画時 開発時

XP

リ リ ース計画ゲーム ◯ ◯ ◯ ◯ ◯

イテレーショ ン計画ゲーム ◯ ◯ ◯ ◯ ◯ ◯

小規模で頻繁なリ リ ース ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯

システムのメ タ フ ァ ◯ ◯

シンプルデザイン ◯ ◯ ◯

テスト駆動開発 ◯ ◯ ◯

受け入れテスト ◯ ◯ ◯

頻繁なリ フ ァ クタ リ ング ◯ ◯ ◯ ◯ ◯ ◯ ◯

ペアプログラ ミ ング ◯ ◯ ◯ ◯

共同所有権

継続的インテグレーショ ン ◯ ◯ ◯ ◯ ◯ ◯ ◯

持続可能なペース ◯ ◯

チーム全体が一緒に ◯ ◯ ◯ ◯

コーディ ング規約 ◯ ◯ ◯

ふり かえり ◯ ◯ ◯ ◯

Scrum

ゲーム前計画 ◯ ◯ ◯ ◯ ◯ ◯

スプリ ント計画 ◯ ◯ ◯ ◯ ◯ ◯

◯ ◯ ◯ ◯ ◯

スプリ ントバッ ク ログのグラ フ作成 ◯

自律的な組織化チーム ◯

スク ラムミ ーティ ング ◯ ◯ ◯

イテレーショ ンに追加してはならない ◯

スク ラムマスターのフ ァ イアウォ ール ◯

◯ ◯

◯ ◯

ニワト リ と ブタ ◯

◯

共通の部屋 ◯ ◯ ◯ ◯

日次ビルド ◯ ◯ ◯ ◯ ◯

スプリ ントレビュ ー ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯

FDD

ドメ イン・ オブジェ ク ト ・ モデリ ング ◯ ◯ ◯

◯ ◯ ◯ ◯ ◯

クラスの責任者 ◯ ◯

◯ ◯ ◯

インスペクショ ン ◯ ◯

構成管理 ◯

定期ビルド ◯ ◯ ◯ ◯ ◯ ◯

結果の申告と 可視化 ◯ ◯ ◯ ◯

不具合の除去

テストに関する特徴

レビューに関する特徴

品質指標に関する特徴

ユーザーにおける品質管

理

スケジュール管理

組織・ 要因管理

コ ミ ュ ニケーショ ン管理

顧客からのフィ ードバック を求める

原則30日のイテレーショ ン

1時間以内の判断

1日以内の障害除去

7人のチーム

feature 毎の開発

feature チーム

18

⑥ Rubyの特徴を活かした顧客参画／反復漸進型開発に必要なスキル

Ruby の特徴を活かした顧客参画/反復漸進的な開発を行うに当たり，開発者として求められるスキル

を下図にまとめた。

Rubyの特徴であるオブジェクト指向を土台としてモデリング、デザインパターンは、オブジェクト指

向言語での開発を行うのに必須のスキルである。その土台の上にバージョン管理、ユニットテスト、自

動化が一体になることで、2 階部分のテスト駆動開発、計画づくり、ストーリーの作成、リファクタリ

ングのスキルを支えることができる。以下に対象スキルと関連するスキルやプラクティスの対照表を記

載する。

スキル 関連するスキルやプラクテ

ィス

説明

オブジェクト指向 モデリング

デザインパターン

オブジェクト指向言語での開発を行う

場合の必須スキル。

モデリング シンプルデザイン シンプルな設計を行う上で必要とな

る。 デザインパターン シンプルデザイン

バージョン管理

共同所有権 ソフトウェア開発において信頼性のあ

るリポジトリを持つ事は必要不可欠で

あり，顧客が満足するソフトウェアを

開発するうえで必要となる。また，チ

ーム内でソースコードを共同所有する

うえで必要不可欠となる。

ユニットテスト

テスト駆動開発 テスト駆動開発を行う上でユニットテ

ストのテストコードを記述するスキル

が必要となる。

19

自動化

継続的インテグレーション

日次ビルド

自動化を行っていない場合は，ビルド

を手動で流さなくてはならず，多大な

コストが発生してしまうが，自動化す

ることによりビルドを常時行うことが

できる。

テスト駆動開発

テスト駆動開発

頻繁なリファクタリング

テスト駆動開発はソフトウェア開発技

法であり，ユニットテストのテストコ

ードを記述できるスキルやスムーズに

実行を行うための自動化のスキルが必

要となる。

計画づくり イテレーション計画ゲーム

スプリント計画 ー

ストーリー作成 イテレーション計画ゲーム

スプリント計画 ー

リファクタリング 頻繁なリファクタリング ー

20

3. 各事業者の実施結果

3 章では、各実証事業の結果を記載する。各項の①～④は各事業者からの評価コメントを抜粋してい

る。⑤は各実証事業の結果をアドバイザリーボードが取りまとめたコメントを記載している。

各事業者からの評価コメントから顧客満足度を評価するため、以下の指標を用いた。

顧客顧客満足度の分析、および評価は 4章の総括に記載する。

顧客側の指標 ベンダ側の指標

ビジネス価値

ROI，TimeToMarcket，収益

性，拡大可能性，ライフサ

イクル

収益性，拡大可能性

プロダクト 利用品質 品質（内部・外部），信頼性

プロセス 生産性，納期，コスト，リスクの回避

人・組織 信頼関係，情報共有，柔軟

性

信頼関係，情報共有，柔軟性，創意工

夫，モチベーション，人材育成

3.1. 実施体制

テクノプロジ

ェクト

NaCl プロビズモ 日本ハイソフ

ト

ユーザー ○ ○ ○

プロダクトオ

ーナー

○ ○ ○ユーザーと

イコール

○

評価者 ○

レビュアー ○

プロジェクト

マネージャ

○プロジェク

ト責任者が該当

○リーダー、

ユーザー窓口が

該当

○スクラムマ

スターといって

いるが実際には

マネージャに近

い

スクラムマス

ター

○実際には開

発リーダーにな

っていた

開発者 ○ ○ ○ ○

トラッカー ○

コーチ ○ ○コンサルタ

21

ントが該当

技術アドバイ

ザ

スクラムマス

ターといってい

るが実際には技

術アドバイザに

近い

○支援スタッ

フが該当

① テクノプロジェクト

コーチは開発チームとプロダクトオーナーを支援。プラクティスの適用についても、チー

ムの成長を勘案して適当なタイミングで導入を提案した。また、ふりかえり等のイベント

において適宜ファシリテーターを務め、チームで考える力を引き出し、チームの成長を促

した。

トラッカー・評価者というロールをおいた。

スクラムマスターが開発者を兼務。

② NaCl

レビュアーというロールをおいた。

プロダクトオーナー・開発者ともにレビュアーとやりとりする。

レビュアーは 2病院。

③ プロビズモ

スクラムマスターはどちらかというと Ruby の技術アドバイザ。

実質、コードを書く開発者はひとり。

プロダクトオーナーは 2名。

④ 日本ハイソフト

スクラムマスターはどちらかというと開発チームのプロジェクトマネージャ。

プロダクトオーナーは 2名。

コンサルタントは開発チームとプロダクトオーナーを支援。

⑤ まとめ

4プロジェクトすべてに存在したのが開発者とプロダクトオーナーである。

いずれのプロジェクトもプロダクトオーナーがキーマンであるといえる。NaCl のプロジェ

クト以外では顧客企業からプロダクトオーナーを選出していた。いずれのプロジェクトで

も非常に協力的であった。

スクラムマスターは NaCl のプロジェクト以外には存在したが、いずれも本来の目的を果た

22

せていない。

いずれのプロジェクトも開発者のほとんどが Ruby やアジャイル開発の初心者であった。

3.2. 実施スケジュール

テクノプロジ

ェクト

NaCl プロビズモ 日本ハイソフ

ト

リリース 4 ヶ月で 2 回

リリース

本番リリース

はしていない

最後の 1回 最後の 1回

スプリント期

間

1〜2 週間 1,2 回目は 30

日

3,4 回目は 30

日を超える

1ヶ月 1週間

イテレーショ

ン数

10 イテレーシ

ョン

4 イテレーシ

ョン

3 イテレーシ

ョン

21 イテレーシ

ョン

① テクノプロジェクト

１〜2週間でイテレーションをまわした。

② NaCl

前半で Ruby on CyberFrameworkを開発し、後半で診療情報分析システムを開発した。

③ プロビズモ

事前に計画フェーズをもうけた。

④ 日本ハイソフト

1週間でイテレーションをまわした。

⑤ まとめ

1週間でイテレーションをまわすプロジェクトと、事前に設計フェーズをもうけて 1ヶ

月でイテレーションをまわすプロジェクトに大きく分かれた。

3.3. 実証する Rubyを使った開発手法

23

① テクノプロジェクト

開発手法はスクラムを採用している。

開発のライフサイクルとしては、2,3 ヶ月毎にリリースを行い、リリース期間中は 1、2週

間のスプリントを繰り返す。

スプリントは、見積りと計画づくり — 開発 — デモとふりかえりを繰り返す。

② NaCl

レビュアー側の意見をヒアリングしながら開発サイドの一方的な判断ではなく両者の判断

で対応した。

ストーリーを分析した上でカテゴライズすることにより、自社サービスとして価値のある

ものを選定した。

③ プロビズモ

開発のフェーズを計画 、 実装(反復) 、 評価に分けて実施した。

実装フェーズに関しては、スプリント計画 － 実装・テスト — リリース・ふりかえり、を

繰り返す。

ユーザーとベンダーも遠隔地におり、リーダーとスクラムマスター、開発者も遠隔地にい

た。

④ 日本ハイソフト

開発手法は、XP＋スクラムのハイブリッドである。

開発チームがマルチベンダーである。

また、各社が実践したプラクティスを以下の表にまとめる。

テクノプロジェク

ト

NaCl プロビズモ 日本ハイソフト

完了状態の定義

ユーザーストーリ

ー

ユーザーストーリ

ーマッピング

プロダクトバック

ログ

リリースプランニ

ング

リリースバーンダ

スプリント計画

原則 30 日のイテ

レーション

振り返り

シンプルデザイン

頻繁なリファクタ

リング

スプリント計画

30 日のイテレーシ

ョン

ウォークスルーレ

ビュー

テスト駆動開発

テスト自動化

コーディング規約

頻繁なリファクタ

リング

リリース計画ゲー

ム

イテレーション計

画ゲーム

小規模で頻繁なリ

リース

シンプルデザイン

コーディング規約

ふりかえり

24

ウンチャート

スプリントプラン

ニング

プランニングポー

カー

ベロシティ駆動計

画

タスクボード

スプリントバーン

ダウンチャート

スプリントレビュ

ー

スプリントふりか

えり

リリース

リリースふりかえ

り

スタンドアップミ

ーティング

振舞駆動開発

受入テスト駆動開

発4

リファクタリング

ペアワーク

ニワトリとブタ

共通の部屋

語る作業場

勉強会

ペーパープロトタ

イピング

リリースバーンダ

ウン棒グラフ

パーキングロット

チャート

学びたいものマッ

プ

ソースコードの共

有

ふりかえり

日次ビルド

ユーザーの参画

スクラムミーティ

ング

プロダクトバック

ログ

スプリントバック

ログ

バーンダウンチャ

ート

スプリントレビュ

ー

4 振舞駆動開発、受入テスト駆動開発の説明 http://gihyo.jp/dev/serial/01/agile-transparency/0005

25

遠隔地でのミーテ

ィング共有

⑤ まとめ

いずれのプロジェクトもスクラムをベースとした開発手法（反復漸進型・顧客参加型）を

採用した。

反復漸進型に関しては、いずれのプロジェクトも複数回のイテレーション（スプリント）

を実施している。

顧客参加型に関しては、NaCl（自社パッケージ）以外のプロジェクトでは顧客側からプロ

ダクトオーナーを選出している。

3.4. Ruby言語の有効性と課題

① テクノプロジェクト

必要なソフトウェアや情報をすぐに入手できる。そのため、短期間で開発に着手すること

ができた。

Ruby はアジャイル開発手法に関連するツールが豊富であるため、Ruby および Ruby を取り

巻くツールの特徴を活かすことができた。

プロダクトのコード量が尐なくてすむ。

変化（進化）する言語のため、バージョン選定が難しい。

② NaCl

Ruby 言語で記載することで、レビュー時などで即座にソースコードを変更し、レビュアー

に対して機能の確認を柔軟に行うことができた。

Ruby 言語の特徴を活用し、レビュアーからの要望やロジックについては随時変更でき、カ

スタマイズが容易な実装を行えた。【変更容易性】

Ruby を利用したことで細かい変更点や、不具合の改修について、実装し即座に動作を確認

できる形で実装を行えたことで、開発者の負担を減らし、かつカスタマイズ性が向上する

ような形で構築することができた。【変更容易性】

③ プロビズモ

Rubyに関しては、特になし

④ 日本ハイソフト

テキストデータを主として扱ったが、Ruby の強力な文字列制御機能により、他の言語より

も遙かに効率よく開発できたように思う

プログラムが比較的簡単に作成できた。頭に浮かんだ命令をそのまま直感的に書いても言

26

語仕様が豊富なおかげでエラーが起きることも尐なかった。これらの利点は今回のアジャ

イル手法における短期間の開発サイクルにおいてとても役に立った。

Ruby の機動性や柔軟性を用いた開発環境が整備されたことによって、より迅速・柔軟に顧

客にニーズに応えることができる

Ruby 開発経験が無い開発者が、経験者に若干の説明を受けただけで、最終的には簡単な伝

票入力画面が作成できるようにまでなった。これは一般に言われている、他言語に比べて

容易に作成できる Rubyの特徴と Aloneの特徴の１つであるシンプルな文法により、ソース

コードを見れば、何が記述されているのかが把握できた。【情報共有】

⑤ まとめ

Rubyを使うことで開発スピードがアップする。

ユーザーの目の前でプログラムを修正して、すぐに確認してもらうことができる。

Rubyに関する情報やツール（特にテストや自動化に関するもの）は多く、入手もしやすい。

Rubyや関連のフレームワークは習得が容易で開発者の立ち上がりが早い。

3.5. 開発環境の有効性と課題

テクノプロジ

ェクト

NaCl プロビズモ 日本ハイソフ

ト

ITS Redmine Trac Redmine

バージョン管

理

Subversion Subversion

テスト環境 PaaS

フレームワー

ク

Rails Ruby on

CyberFramework

Rails Alone

デプロイ Capistrano

ユニットテス

ト

RSpec RSpec

インテグレー

ションテスト

Cucumber

Webrat

Factory Girl

anyWarp

Capture/Replay

開発環境 NetBeans

CI Hudson CI

帳票・グラフ BIRT

コミュニケー

ション

OpenMeetings

① テクノプロジェクト

27

「Ruby on Rails」や「Capistrano」を活用することにより、動作可能な Web システムを短

期リリースすることができた。

「RSpec」や「Cucumber」を活用することで、品質を作りこみながら変化に適応することが

できた。

必要なソフトウェアや情報をすぐに入手できる。そのため、短期間で開発に着手すること

ができた。

Ruby はアジャイル開発手法に関連するツールが豊富であるため、Ruby および Ruby を取り

巻くツールの特徴を活かすことができた。

RSpec(ユニットテストフレームワーク)や Cucumber（受入テストツール）は思ったより導入

しやすかった。

Cucumber がプロダクトオーナーと開発メンバーを繋ぐ共通言語となった。テストコードが

自然言語に近い

JavaScript を用いている機能については、テストの自動化を実現できなかったことは課題

として挙げられる。

② NaCl

Ruby on CyberFrameworkでは、従来の Java 環境での開発と比べて業務ロジック開発の手間

とスピードが大きく改善された。

業務ロジックの結果確認を一瞬で済ませることが可能である。

「Ruby が表示ロジックを記述」、「CyberFramework が DB アクセスと GUI を記述」と明確に

分担が分かれているため、極めて尐ない工数で開発・Web 型アプリケーションへの移行が完

了した

Ruby on CyberFrameworkを使うことで、元々Java で実装されたコンポーネントや機能を再

利用することができた。その結果、実績・安定感のあるシステムを開発できた。【信頼性】

CyberFramework の持つコンポーネントを利用し、同じ機能であっても別の分析方法を提案

し、かつ Rubyを利用してレビュー時に瞬時に動作を変更する、といった方法でレビューを

行い、レビュアーに具体的に機能のイメージを伝え、真に欲しい機能を抽出できた。【外部

品質】

③ プロビズモ

Trac上のバックログの消化状況およびバーンダウンチャートによって、進捗管理が可能

ツールを使うことにより、分散開発でもメンバーが開発状況を確認することが可能

タスクの分割方法や、日々の開発サイクルに適応できないとバーンダウンチャートが意味

のないものとなってしまう

分散開発環境により、遠隔地のユーザーでもシステムを実際に動作させながら機能を確認

することができた。

増加する要望への対応が課題（スコープクリープしないようにする）。

28

開発環境の安定性の確保が課題。

ツールを使いこなすスキルの習得が課題。

より円滑な会議を実施するために、TV 会議の利用経験値が必要。

TV会議はあまり意味がなかったようにも思う。

④ 日本ハイソフト

Aloneは Rubyコードで利用するデータ構造から HTML入力フォームなどをある程度自動生成

してくれる機能があるが、開発時間が十分とれないときは、この機能によって「見た目は

不十分でもとりあえず使える状態」にまで素早くもっていくことができ、大いに役立った。

Aloneは設置が簡単、理解が浅くてもとりあえず動く入出力画面を作ることができる

軽量で習得が容易な、Ruby で作動するフレームワーク Alone も、言語の習得、教育等にか

かるプロジェクト立ち上がりの準備期間の短縮に大きく貢献してくれた

Ruby 開発経験が無い開発者が、経験者に若干の説明を受けただけで、最終的には簡単な伝

票入力画面が作成できるようにまでなった。これは一般に言われている、他言語に比べて

容易に作成できる Rubyの特徴と Aloneの特徴の１つであるシンプルな文法により、ソース

コードを見れば、何が記述されているのかが把握できた。【情報共有】

⑤ まとめ

自然言語でテストコードを記述することが可能である。そのため、ユーザーとのコミュニ

ケーションに一役買った。

Rubyに関する情報やツール（特にテストや自動化に関するもの）は多く、入手もしやすい。

Ruby以外の部分（画面まわりなど）についてはテストを自動化しにくい。

Rubyや関連のフレームワークは習得が容易で開発者の立ち上がりが早い。

ツールを活用することにより、遠隔地との分散開発は可能であるが、ツールの使いこなし

にノウハウが必要。

3.6. 実証した開発手法、プラクティスの有効性と課題

① テクノプロジェクト

有効性

スプリント単位毎にプロダクトオーナーに、リリース時には実際のユーザーに、デモを行

い使用性に関するフィードバックをもうらことができた。【使用性】

工場見学を通じて、実際の点検現場にてユーザーの意見を直接聞くことができた。また、

実際の現場で開発したソフトウェアを利用しているシーンを見ることもでき、開発チーム

側もユーザーエクスペリエンスを意識して意見を交換することができた。【使用性】

当初予定していたストーリーを全体の半分の期間で完了させ、その後のスプリントでは追

加要求を受入れた。【柔軟性】

29

「受入テスト駆動開発」を自動化したことで、今後の保守性を高めることができた。【保守

性】

「受入テスト駆動開発」においては、Ruby 開発での定番ツールである「Cucumber」を用い

ることで自然言語に近い表現で動作する受入テストを記述することができた。そのため開

発メンバーでなくても、そのソフトウェアの仕様を理解できた。その結果、開発メンバー

とプロダクトオーナーの間の共通言語として利用することができ、保守性を高めるのに有

効であった。【保守性】

マインドの変化（前向き、アクティブ、目的意識）。【モチベーション】

問題点を長期化しない（朝会、夕会、ふりかえり）。

チームで挑む姿勢＆安心感。

同じ価値に向かう姿勢（作業のやりがい、楽しさを感じた）。

チームが（個人も）成長できた（勉強会、スプリント）。【成長性】

良いことも悪いことも丸見え。【透明性】

（顧客と開発チーム間の）共通の用語。【情報共有】

朝会、夕会によりメンバーの進捗状況が把握できた。【情報共有】

遠隔開発は、Web 会議システムやアプリ共有機能を用いて可能である。

スプリント期間終了時にふりかえりをすることでチームも問題点を修正することができた。

振舞駆動開発/受入駆動開発の導入により仕様変更、改善要求を受け入れやすい。

テストコードがプログラム仕様書になる。

課題

プロダクトオーナーとチームメンバー双方の理解が（より）必要。

顧客企業と開発企業という緊張感を持ち続けていられたか。

計画づくりに時間が掛かり、プロダクトオーナーに掛かる負担が大きい。

見える化ツールの一部が形骸化（リリースバーンダウン棒グラフ、ベロシティチャート）

した。

メンバーの技術レベルの引き上げ、新規技術の導入に時間が多くかかった。

チームのベロシティが上がらなかった。

② NaCl

有効性

作業内容（要件や仕様）について開発工程の中で模索しながら進めることで、真に欲しい

機能の抽出を行えた。【外部品質】

要件の洗い出しとこれのブラッシュアップに、レビュアー、プロダクトオーナーが積極的

に参加する機会を短期間に継続して提供できた。【外部品質】

リファクタリングを採用した結果、開発者にとっての Ruby 言語の理解が向上した。【成長

性】

リファクタリングを通してソースコードを整理し、機能毎の実装についてコーディングル

ールを統一することが出来、保守性を高めることができた。【保守性】

30

課題

本サービスを開発する際に、製品にニーズがあるかどうか、また他社の製品が市場でどの

ような割合で展開されているかなど、あまり議論できなかった。最終的にコストの影響を

受けるのは弊社であり、リスクを考えた場合はこういった市場性などを検討し、弊社側か

らもレビュアーから要件を抽出するだけではなく、機能選定についてより活発に議論に参

加できる知識や情報を取得する必要がある。【ビジネス価値】

③ プロビズモ

有効性

割込要求や変更要求に対しては、短時間で対応できた。【変更容易性】

Rubyを使用することで、短期間に機能を作りこむことが可能であった。【生産性】

スプリント途中又はスプリント完了後に、不確定だった要件がより鮮明にみえる形になる

為、眠っているユーザー要件を掘り起こし易い。【外部品質】

不確定なことが多い状況での構築着手にも関らず、この方式ゆえ完成できたのではないか

と思う。

小さい機能から積み上げる今回の方法は、この事業で開発したシステムやビジネスの特性

に適していたと思う。

優先順位を明確にすることにより、ユーザーにとって価値のある機能から作りこむことが

可能

課題

Ruby on Railsのテストコードを記述する経験がないにも関わらず、テスト駆動開発（TDD）

を試行したために工数が増加した。【生産性】

技術的課題の解決に時間を要した、1ヶ月という開発サイクルを習得するまでに時間を要し

た、分散開発環境への適応に時間を要したなどの理由により、受け入れた要求をスプリン

ト内ですべて実現できず、次スプリントへの持ち越しが発生した。【納期】

画面の変更が頻繁に行われるため、画面操作テストスクリプトの修正工数が増加した。

細かな部分の変更が多発して本来の目的である機能実装に影響が出てしまう可能性もあり

タスク管理（タスクの優先度付けなど）をしっかりする必要があった。

アジャイル手法だからといって、全ての要件を受け入れられる訳ではない。よって、あれ

もこれもできるだけ実装してほしいという要望は叶えられない。

プロジェクト開始当初、プロジェクトを円滑に進めるためには、ユーザーとの関係をより

よくする必要があると考え、ついユーザーの要求を取り入れようとし過ぎたことで、ユー

ザーに過剰な期待感や満足感を抱かせてしまい、結果一部ユーザー満足度を下げてしまう

ことにつながってしまった。

④ 日本ハイソフト

有効性

31

開発者は一週間後が締め切りという事で余計な事を考えずに作成に集中することが出来、

生産性の面から見るとプラスに作用した。【生産性】

イテレーション計画時に作業時間を見積り、そのタスクに対しての実際の作業時間を測る

事により、見積り工数時間と実作業時間との対比が出来、見積り工数の精度向上が図られ

た。【成長性】

顧客、開発者双方より有益な意見が多く出され、完成度の高い成果物を顧客に提供するこ

とが出来た。【外部品質】

顧客においては、毎週、毎週成果物が見られることにより、開発の進捗の見える化が図れ、

上司への報告も容易になった。【透明性】

成果物をエンドユーザー様にお見せし、現場の生の声を反映させる事が可能となり、尐し

ずつシステムを開発し、ビジネスモデルに合わせてシステムを成長さることができた。【外

部品質】

Rubyで開発された軽量フレームワークである「Alone」を用いたことで、機能実装のスピー

ドアップが図れた。【生産性】

顧客が毎週定例会に出席する事と成果物を見ることにより、システムへの認識が深化し、

当初想定していなかった活用策に気づき、当初あった目的以外の機能追加の要望が出てく

る事が多々あった。【外部品質】

無駄な機能を開発者サイドで開発することはなかった。これは、毎週のリリースに顧客が

参加し、イテレーションによってリリースされるソフトウェアを見たこと、ストーリーを

顧客が提示した際に、開発者サイドとの議論によって、必要最低限の機能を１週間という

イテレーションの中で実現したことによって得られた結果である。【生産性】

開発言語が Rubyであったため、顧客が求める機能を 1週間という短いイテレーションの中

で実装することができ、それを顧客に確認をしてもらい、その結果を踏まえてから、デザ

インやバックエンドの追加機能、修正を行ったので無駄な時間を費やすことがなかった。

【生産性】

言葉（呼称）の定義を明確化（統一）したために、顧客と開発者間での呼称による齟齬が

軽減され、同じ事、同じ物のことをお互いが言っているはずなのに、呼称の違いで別物と

して考え、話しが噛み合わず無駄な時間を費やすという事がなくなった。【情報共有】

ルール設定により過度の記述の省略を行わないよう配慮したことから、学習コストの低減、

開発メンバー間のスムーズなコミュニケーションが図られた。【情報共有】

一週間サイクルでの PDCA が回せ、問題の早期発見と業務改善に大いに役立った。【内部品

質】

顧客に対して注文を付けることが可能となるまでにコミュニケーションが深まった。何で

も言い合える関係は、成果物に目に見える形で現れてきて、そういう意味でも有効性が実

証された。【信頼関係】

最初に仕様らしい仕様を全く決めず、ストーリーという形で希望する仕事や動作を明らか

にしていき、ストーリーごとに細分化した小さな設計を積み重ねる形で全体を構成した。

その課程で小さな齟齬はでるものの、ほとんど問題を発生させずに開発を終えることがで

32

きた。発生した問題も、一週ごとのリリース＆レビューのおかげで、問題が大きくなる前

に摘み取ることができていたように感じる。【外部品質】

データベース設計に関していえば、要求、すなわちストーリーが明らかになるごとに適宜

見直しをおこない、常に最適な状態になるように心がけて小さな改廃を繰り返しており、

結果的にリファクタリングと同等の効果があったように思う。【内部品質】

ほとんどの方々と初対面だったにもかかわらず、コーチの指導と手法の実践により、プロ

ジェクトの非常に早い段階から頻繁で良好な意思疎通ができた。【情報共有】

タスクごとに細分化した仕事の管理や他メンバーの仕事との連携の見える化（Redmine の活

用）など、有効に機能していたと思う。特にメンバーどうしが遠隔地で作業しているので、

これをなくしては進捗の管理など、とても手間（管理コスト）のかかることであったろう。

【情報共有】

ストーリーの作成、優先順位の割り振り方など、アジャイル手法の考えに基づいたユーザ

ー側の開発者に対する振る舞い方までコンサルタントに指導してもらったおかげで、ユー

ザーと開発者側で大きな食い違いが起きることなくプロジェクトを進めていくことができ

た。【情報共有】

毎週の定例リリース会議を重ねることで、経験の浅いメンバーも自分の疑問解決、提案も

できるようになりプロジェクトチームの成長を見ることができた。【成長性】

課題

ユーザーが頻繁にその時点の成果物を確認、仕様を決定するやり方だが、もともとシステ

ム開発に関しては経験も無く、専門的な知識にも乏しい人間にとっては負担が大きいと感

じた。【情報共有】

実際に今回ビジネスとの同期をとってシステム開発を進めていったため、ストーリーが枯

渇することが見受けられた。

基本となるプログラムのコーディングスタイルが正しいかそうでないかの判断が出来なか

った。

開発者同士のコミュニケーションはあまり多くなかったように思う。明確に作業分担が決

まっていたこともあり、他の人が開発しているところに対して意見を言い難かった。

⑤ まとめ

有効性

頻繁に顧客と直接コミュニケーションをとることにより、ユーザーのニーズを引き出しや

すく、ユーザーの望むものが開発できる。

反復のサイクルで追加の要望を柔軟に取り込むことができる。

エンジニアリングプラクティスを実践することにより、保守性・変更容易性を高めること

ができる。

受入テストを自然言語に近い形で記述することができるので、顧客と開発者のやり取りが

円滑になる。

プロセスのライフサイクルの中に、情報共有や改善の仕組みが組み込まれている。

33

Rubyを使うことで高い生産性を維持できた。

開発者がモチベーション高く仕事を進められる。

課題

計画づくりなどで、プロダクトオーナーへの負担が大きい。

開発者に高い技術力が要求される。

3.7. 実施体制の有効性と課題

① テクノプロジェクト

有効性

顧客企業からの開発者が参加した。はじめの 1 ヶ月は常駐、次の 1 ヶ月は隔週での常駐、

残りの 2 ヶ月は遠隔開発（出雲村田製作所での開発）という形態にした。チームの一員と

しての信頼関係、モチベーション、そしてソフトウェア開発のスキルを向上させた上で、

出雲村田製作所に戻って遠隔開発を始めた。

Web会議システムを常時接続し、常にコミュニケーションを取れる状況にする。

スプリントふりかえりなどのイベントは可能な限り参加する。

アジャイル開発手法の経験のないチームが取り組む場合、チームの羅針盤としてコーチの

設置は必須であると考える。

課題

プロダクトオーナーの役割について、開発チームとの間の役割分担は明確に規定したが、

プロダクトオーナーが所属する情報システム部門とユーザーである製造部門との間の役割

分担については明確に規定せず、プロダクトオーナーに委任した形であった。そのため、

開発チームが直接ユーザー部門と役割分担をしていた従来のやり方に比べて、開発チーム

とユーザー部門との関係性における不透明さをもたらしたのではないかと考えられる。【透

明性】

開発が行われている部屋は開発企業（テクノプロジェクト）内にあった点である。開発状

況を可視化している部屋（「語る作業場」）とステークホルダーの場所が距離的に離れてい

た。プロダクトオーナーも含めた開発チームと、ステークホルダーとの間の進捗報告、情

報共有の場の設定がなされていなかった。開発チームとステークホルダーとの関係性につ

いては、全てプロダクトオーナーに任せきりになっていた。【情報共有】

ステークホルダーを交えた上でのふりかえりは、期間中に一度しか実施しなかった。【情報

共有】

透明性を理解してもらうために、ステークホルダーにもスプリントレビューなどに積極的

に参加してもらう、あるいは開発環境を見学してもらうなどの継続的な働きかけが必須で

あると考える。【透明性】

プロダクトオーナーのレベル（システム知識、業務知識）によって進度が左右される。

プロダクトオーナーが開発チームとエンドユーザー、もしくは開発チームとユーザー企業

34

の経営層の間に入って、両者の利害を調整することが難しいと思われる。

② NaCl

有効性

異なる視点からレビューを受けるためユーザーに偏らない機能改善を行うことができた。

【外部品質】

外注メンバーの業務知識のレベルを発注側であるプロジェクトリーダーが十分に把握して

開発をスタートしていなかったため、開発当初の進捗は期待を下回るものであった。しか

し、対面でのミーティングを重ねることによって双方のレベルの把握と理解を得て、更に

はメールや振り返りの実施等による情報共有を行うことで対応し効率的な開発を進めるこ

とができた。【生産性】【情報共有】

プロダクトオーナーが 2 レビュアーのあいだに入ることにより、要件のイメージをさらに

深く議論し、方向性を保ちながら仕様を決定できた。

両レビュアーとも、率直に意見を述べて頂き、開発手法についても開発者と議論しながら

作り上げ、実際に動作する形でレビューすることで、開発者との距離を縮め、満足度の高

い機能を開発することができた。【協調性】

レビュアーからの意見を聞くことでシステムの位置づけ、またこちらで想定していなかっ

たすばらしい機能などを開発できた。【ビジネス価値】

尐なくともプロジェクト内で顧客とのヒアリングを担当するようなマネージャや、開発の

取りまとめを行うような開発リーダーにアジャイル開発の理解があれば、アジャイル開発

の実践は可能あると考える。

課題

レビュアーが作成するシステムに対して知識を持っているか、またイテレーションを実施

する上で時間的に協力頂けるか、などといったことを検討する必要がある。

イテレーション初期に機能のイメージが無い状態では、レビュアーからはプロダクトオー

ナーの思いと違う機能を要求することが有る。

レビュアーの要求通りに開発するのではなく、プロダクトオーナー側についても検討や仕

様決定の指針などが必要である

開発側で要件を整理するための開発する分野への知識や、マネジメント能力、またレビュ

ー後の振り返りによっての次回レビューへの対策が必要である。

本事業の開始時に明確なゴールを設定しなかったため、プロダクトオーナーが仕様決定に

悩むことがあった。これは「４（１）」の方法で回避したが、ある程度コンセプトなどは明

確にすることで、プロダクトオーナーの負担は軽減すると考える。

③ プロビズモ

有効性

35

地理的に離れた複数拠点でも、分散開発環境でプロジェクト運営は可能。

プロジェクトリーダーと実装者が、拠点が離れていてもプロジェクト運営は可能。

課題

ユーザー側に実装チームメンバーやスクラムマスタメンバが出むかない会議で、ユーザー

と実装チームメンバーとの意思疎通がうまく出来ない事象が発生した。

会議の内容により、会議方法（対面か TV会議）を検討する必要がある。

④ 日本ハイソフト

有効性

指導者の存在はとても重要であると感じた。

課題

顧客が言うままにシステムの基本目的から外れた物を作成するのは、限られた期間内に顧

客が最低限必要な機能を実装したシステムを開発する上で障害となる。

コンサルタントがいなかったり、講習を受けていなかったりする顧客に、どう円満に納得

させるのかが課題である。

具体的な開発方針を決定する前に必ず技術的に可能かどうかの検証作業が発生した。本来

は、プロジェクトで利用する言語、ツール、環境にいたるまで、プロジェクトチーム全員

が精通しているか、尐なくとも精通している人間がチームに存在することが望ましいと考

える。

⑤ 総括

ステークホルダーの意見を調停する役割をプロダクトオーナーが担うことが重要。

ステークホルダーとの調整事や報告をプロダクトオーナーに一任すると、開発チームとス

テークホルダーのあいだで不透明性が生じる。

アジャイル開発にはじめて取り組むチームでは、コーチ・コンサルタントの支援があるこ

とが望ましい。

遠隔開発を行う場合は、最初は同じ場所で仕事をしたり、定期的に顔を合わせてミーティ

ングしたりすることによって、チームを機能させることができる。

3.8. ユーザー満足度に及ぼす有効性と課題

① テクノプロジェクト

有効性

ユーザー部門の要求が迅速に取り入れられ、使用性の高いものになっている。【使用性】

スプリント毎に動くソフトウェアを確認頂けるため、「体感速度は高い」。【生産性】

期限通りに何らかのアウトプットが出る。【生産性】

高いモチベーションをもって、取り組めている。【モチベーション】

36

顧客参加型の開発手法を取ることで、開発企業との密接な関係が生じ、それが刺激となっ

て成長を促した。「勉強会」による学習意欲の向上や、「ふりかえり」による改善意識の醸

成が、成長に大きく影響を与えた。【成長性】

「スタンドアップミーティング」などの場で、コミュニケーションを促進するためにファ

シリテーターを設置したことは、コミュニケーション能力の向上に役立った。【成長性】

「人間性が高い」「真摯に取り組んでいただけた」という面を評価して頂けたのは、顧客参

加型の開発手法を通じて顧客に近い立場で開発を進めたことが大きいのではないかと考え

る。【成長性】

できたシステムが提供するビジネス価値が大きい。【ビジネス価値】

変更コストは低いと期待している。【変更容易性】

課題

早くアウトプットは得られるが、期待する生産性が出ていない。【生産性】

初めて取り組む開発手法であったため、初期学習やコミュニケーションの進め方の模索に

コストが掛かった。【コスト】

外部からみて見え難さがある。【透明性】

柔軟に変更要求に対応できているが、アジャイル開発手法が初めてのメンバーでの取り組

みであり、プロダクトオーナーによる要求出しが初期段階（リリースプランニング）で十

分でなかったことや、エンジニアリングプラクティスの習得のために開発者のユーザース

トーリーの割合が当初多かったことなどから、まだ製品の変更受容性について評価できる

段階ではない。【変更容易性】

② NaCl

有効性

アジャイル開発手法の採用によりレビュアーがイメージし易い環境を短期間に提供し、レ

ビュアーから真にニーズのある機能を抽出し、原則性のある機能を実現することで、プロ

ダクトオーナーとしてビジネスに直結する成果が実現できた。【外部品質】

イテレーションの実施や、振り返りの実施により、短期間で進捗もしくは結果を提示し開

発の動きを見える化することは、レビュアーの観点からすると、プロジェクトに対する信

頼が生まれ協力度合い（モチベーション）にも影響した。【モチベーション】【協調性】

③ プロビズモ

有効性

進捗報告については、開発環境で利用する開発者向けのツールでは伝わりにくいと考える。

今回は、ユーザー向けには進捗報告資料を改めて作成したために、満足度は良かった。よ

って今後も同様の方法がよいと考える。【情報共有】

課題

受入要件全てを実現できなかった。開発チーム側の不慣れ（経験不足）が原因と考える。【生

37

産性】

TV 会議については、使用方法の複雑性や実施方法、視覚範囲の仕様的な要因により、ユー

ザーが不快を感じた。【情報共有】

スケジュールの遅延時並びに計画要件と実現要件で差異が発生した場合(計画要件を全て

満たさなかった場合)の対応方法で工夫が必要。特に計画要件と実現要件に差異が発生した

場合の理由や原因の説明には、ユーザーが分かり易い情報の提示が必要である。【情報共有】

④ 日本ハイソフト

有効性

アジャイル開発手法を取り入れたことで、顧客の業務を理解し、それを受けてどの機能を

優先的に実装してもらう必要があるかを整理したストーリーカードを開発側へ提示したこ

とで、顧客が求める機能を実現できた。【外部品質】

⑤ まとめ

有効性

ユーザーとのコミュニケーションを頻繁にとることにより、安心感を与えた。

短い間隔でユーザーからの要望を取り入れることにより、ユーザーの望むものを実現する

ことができた

ユーザーの意見を直接聞く機会が頻繁にあることは開発者のモチベーションアップにもつ

ながる。

課題

開発スピードが従来型の開発手法に比べて飛躍的にアップするわけではない。

見える化のプラクティスだけでは開発の透明性が確保できない。マネジメント向けの報告

が必要。

3.9. 品質・信頼性及び開発管理に及ぼす有効性と課題

① テクノプロジェクト

有効性

品質を高めるためのプラクティスが充実しており、品質的には問題はないと考えられる。

具体的には、「完了状態の定義」（開発チームと顧客間）、「スタンドアップミーティング」（開

発チーム内）や「スプリントレビュー」（顧客からのフィードバック）に見られるように、

ウォーターフォール型開発手法で言うところの工程より短い期間で品質を高める措置を講

じることができた。【内部品質】

顧客参加型の開発によって、顧客にとって必要十分な品質を求めることができた。顧客と

開発チームで品質についての合意を事前に行い、「完了条件の定義」に組み込み、それを「ス

プリントレビュー」などで適宜見直すという進め方が良い。【内部品質】

38

プロダクトオーナーだけでなく、開発チームもプロダクトに対する理解を持ち、受入テス

ト項目の漏れを減らす努力が必要である。本事業で行った、スプリントレビューや工場見

学のように、開発するソフトウェアへの理解を深める機会を活かし、受入テスト項目に対

する開発チームからのフィードバックが行えると、品質向上に役立つと考える。【内部品質】

テスト駆動開発（振舞駆動開発、受入テスト駆動開発）への評価が高く、従来の内製での

開発（非テスト駆動開発）に比べて、製品コードの提供とともにテストコードが整ってい

る点は、品質への安心感を与えた。【内部品質】

課題

開発チームの生産性を説明する上で、「要求される機能がソフトウェアとして実装されて動

いた」ということを生産性計測の満足条件とするのか、「全ての実装された機能が動いてい

ることが保証されている」という満足条件も加味するのか、によって全く生産性の計測値

および説明が異なってくる。また、ソフトウェアに自動テストが配備されていないと保守

性に影響が出て来るため、リリースまでの視点だけでなく、リリース後の運用や変更も加

味した生産性の議論が必要である。【生産性】

② NaCl

有効性

Ruby の場合、十分なスキルが無い場合は、開発するシステム全体のコーディング規約や、

画面規約、命名規約などを整理し、リファクタリング、XP、テスト駆動開発などのプラク

ティスを採用することで、開発システムの品質やコードの可読性などは向上する。【内部品

質】

③ プロビズモ

有効性

バグは短時間で修正できており、スプリントを重ねてシステム規模が増加しても修正時間

の増加はない。【保守性】

分散開発でも品質への影響はなく、コード修正内容のトレースとシステムへの修正反映が

迅速に可能。【内部品質】

早めに実装方法などを先回りして調査・検討して頂いたお陰で、本実装時の時間短縮やバ

グ発生率の低下につながった。【内部品質】

課題

発生したバグの種類で最も多いのは「仕様の抜け」である。システムの仕様は、ユーザー

とのコミュニケーションで決定しているが、細かな仕様までは確認しきれなかった。コミ

ュニケーションのみでの伝達には限界があると考える。【内部品質】

④ 日本ハイソフト

有効性

39

開発者サイドから見ると、品質・信頼性、開発管理に関して一定水準以上の有効性が認め

られた。

課題

顧客サイドから見ると、大変よく利用する層の場合は「操作性」「信頼性」、ほぼ毎日利用

する層の場合は、「操作性」「安全性」、その他の層は、「有効性」「操作性」においての満足

度が低い結果となった。

⑤ まとめ

有効性

テスト駆動開発やリファクタリングなどのエンジニアリングプラクティスを実践すること

により、品質への安心感をもたらした。

アジャイルでは従来型の開発手法よりも短い期間で品質への対策を講じることができる。

顧客とのコミュニケーションを密にすることにより、過剰でも過小でもない求められる品

質のものを出すことができた。

課題

口頭でのコミュニーションに依存したために、「仕様の抜け」によるバグが発生した。

3.10. 顧客の意見

① テクノプロジェクト

Good

プロダクトの規模とチームの速度を数値化することで計画が立てやすい（ベロシティ駆動

計画）。【予測可能性】

現場との調整、人のアサイン、設備投資計画がやりやすい。【予測可能性】

決められたリソースで最高の価値が提供してもらえる。【ROI】

本来の目的の達成のために、より有効な価値（量より価値）が提供してもらえる。【ROI】

利用者に価値を創造する能力が身に付く。【成長性】

利用者と開発者の間に信頼関係が生まれる。【信頼関係】

Bad

ユーザーストーリーの優先順位付けが難しい。

スプリント期間内にユーザーストーリーが消化できない場合での対応が難しい。

ユーザーの思い描く画面イメージがプロダクトに反映されるのに時間が掛かった。【生産性】

プロダクトオーナーの工数がかかる。

変化に対応するための工数が大きい。【変更可能性】

現場としては第一段階の運用をスタートできるが、もう尐しスピードが欲しいという要望

はある。【Time to Marcket】

40

② NaCl

Good

データ分析を決められた形式で帳票に出力するものはあるが、画面で見る事が出来るもの

は無いので、そういう点については満足している。

医者は設計書を見てもわからないから、できた画面を見ながら直す手法の方が良いと思う。

医者は好き勝手なことを言うから、それを全て実現するとごちゃごちゃした画面になって

しまう。それは見やすくない画面だが、医者に取っては使いやすい画面になる。そのため、

発注者が画面を見ながら修正を加えていく手法が良い。

実際に利用できるシステムが出来、自分が欲しい機能を開発してもらえるところ。

Bad

開発環境を整備する期間が長かったため、動作するシステムを見ることが出来たタイミン

グが遅かったような気がする。もう尐し早い段階で実際のシステムが見られると、さらに

機能追加出来たかもしれない。【生産性】

③ プロビズモ

Good

従来の開発手法より、ユーザーが開発に踏み込める分、より技術的な裏付けや作業工数の

算出根拠が明確に必要になる。【透明性】

Bad

打合せ決定して実装しても、変更があり実装方法まで大きく影響する変更に関しては手戻

りが発生しているようにも感じた。

どうしてもユーザーからの要望が膨らんでしまいがちになる危険性がある。（当初に開発完

了イメージが未確定の為）

開発手法上の専門用語が特殊で（例：スプリント、インクリメンタル開発等）、ユーザーに

意味が伝わりにくい。

成果物が曖昧なまま、開発が進んだ

④ 日本ハイソフト

Good

ユーザーがシステムを使って直接利益を生み出す立場であったため、ビジネスプランに同

期した開発が可能であった。

ユーザーが開発の場に参加する事のメリットとしては、開発状況をすぐ把握でき、完成し

た機能ものを即使える事がある。

Bad

要望を細分化する事、優先順位の高い必要な機能を選ぶ事が難しく、スタートにおいて大

きく後れを取った。

41

細分化及び優先順位付けの作業は手法が決まっておらず、特に優先順位付けは、作業を難

航させていた問題点がどこにあるかもユーザーサイドの目線からはわからなかった。ユー

ザーが開発の場に参加し、プロダクトオーナーとして役割を果たすにはコンサルのアドバ

イス無くしては難しいと感じた。

イテレーションサイクルが週 1 回で有った事は、非常に効果的ではあったが同時に負担で

もあった。

⑤ まとめ

Good

量より質が高くなる。

信頼関係が生まれる。

動くものベースで確認できるため、分かりやすい。

開発の状況がすぐに把握できる。

開発計画の予測可能性が高くなる。

Bad

ユーザーストーリーの作成や優先順位付けが難しい。

ユーザーに負担をかける。

開発のスピードが思ったより出ていない。

3.11. Rubyの特徴を活かす開発手法の今後のビジネス利用の可能性と活用分野

① テクノプロジェクト

製造部門の生産革新、改善はトライ＆エラーが必須のため合うのではないか。

これまでの構築スピードに不満や期待値とのずれがある場合。

株式会社出雲村田製作所殿の全部門への適用可。できればプロダクトオーナーとなり得る

人材のいる部門。

パッケージ製品を始めとした自社製品・サービスの開発や機能追加において、実証した開

発手法は有効に働くと考える。お客様が価値を得られる最小単位の機能（MMF）を意識した

リリースを行うことで、市場への Time to Market を短縮することができる。また、想定さ

れる高い保守性を活かすことで、お客様からのフィードバックを製品・サービスに適宜反

映させることができると考えられる。

元請（直接販売）ビジネスの拡大。今回の実証事業を通じて、エンドユーザーとの関係を

深化できる手応えを感じた。

「スプリントレビュー」や「ふりかえり」といった非エンジニアリングプラクティスは、

すぐにでも適用できる。

ソフトウェア開発のみならず、チームの自己組織化を支援するサービスとして、ユーザー

企業に提供していきたい。

42

島根県においては Rubyに関する研修や勉強会も多く、プログラミングスキルを身に付ける

土壌があり、実際に Ruby を学習するユーザー企業も増えつつある。ユーザー部門のソフト

ウェア開発を実証した開発手法を用いて支援していきたい。

Ruby を活用したエンジニアリングプラクティスについては、既にテクノプロジェクトが提

供している「Ruby 研修・教育」のカリキュラムに加えていきたい

パッケージやサービス（SaaSなど）開発には適しているだろう。

自社（出雲村田製作所）への適用は全社的に一気呵成に適用するのではなく、徐々に展開

していくのが良い

② NaCl

大学病院や研究機関などの先端医療分析分野：必要な業務ロジックを平易にかつ自在に記

述できる環境が求められている。

総合病院でのインシデントレポート作成：分析の途中で医師達から分析ロジックに対して

多くの注文が入る。

自社サービスの構築。自社サービスという開発で、本開発のように開発初期に実現したい

アプリケーションの完成形のイメージが薄い場合、開発しながら機能についてヒアリング

を行い、ビジネスとして価値のある機能、アプリケーションを選定することが必要である。

その選定の過程で多くのレビュー回数が必要であり、かつレビューで抽出した要望を早期

に実現できる開発手法としては、開発手法のアプローチとして最適なアジャイル開発手法

が適している。また、Ruby 言語の機動性とアジャイル開発手法を組み合わせることで、自

社サービスでの開発において有効な手段であると考える

③ プロビズモ

新規事業向けITシステムや情報系システムなどリリース時期が重要で早く実現したいシス

テム。

イントラネットシステムや CRM、SFA など費用対効果が求められるシステム。

B2Cなどユーザーの意見をシステムに取り込みたいシステム。

当初完成予想及び要件決定がほとんどされてなく、ユーザーが業務をかかえ要件定義に時

間がさけないようなケースではとても有効な開発手法と感じた。

④ 日本ハイソフト

企業内のある一部分のシステム開発で、それは他のシステムと密接に連携していなく、基

本的にその中でクローズしていて、尚且つ短期間（３ヶ月ぐらい）で開発完了するような

業務システムならば、この開発手法でも十分活用できるのではないかと思われる

⑤ まとめ

新規事業などで不確実性が高いシステム

43

早期に本番リリースしたいシステム

ユーザーの要望や要求が頻繁に追加・変更されるシステム

自社パッケージ。製品をタイムリーにリリースすることができる。

元請けビジネスの拡大。

Rubyやアジャイルの導入支援。

3.12. Rubyの特徴を活かす開発手法の今後のビジネス利用での課題と克服策

① テクノプロジェクト

契約

完成された成果物を取り決めるのは難しく、変更要求が多かったところをみると、請負契

約は難しい。

今回のようにユーザー企業が主体的にシステム開発に関わることができれば、ユーザーへ

の価値提供という同じ目的に向かって、準委任契約でソフトウェア開発に取り組むことが

できる

今回のようにユーザー企業が積極的に参加し、そして開発されたソフトウェアに対する責

任をユーザー企業が持つことができるケースであれば、準委任契約が妥当であろう。

人材育成

今後新たにアジャイル開発手法に別の開発者が取り組む場合、どのようなスキルアップ手

段を取るのが良いのかを検討する必要がある。

ソフトウェア開発経験がない、一般的なユーザー企業の担当者が、いかにプロダクトオー

ナーの役割を担うことができるか、といったプロダクトオーナーのスキル支援についても、

課題を感じた。

ペアワークを取り入れることで、経験者が初心者をサポートするように進めると良い。

「認定スクラムマスター研修 (CSM)」 および「認定スクラムプロダクトオーナー研修

(CSPO)」の受講するとよいと感じた。

プロダクトオーナーのアサインが課題と感じており、業務への精通だけでなく、開発チー

ムへの歩み寄り（システムへの理解）も重要であるとの認識がなされている。

体制

パイロットプロジェクトを選定し、まずは取り掛かることから始めると良い。また取り掛

かるに当たってはアジャイル開発手法についての実績のある指導役（コーチ）を設置する

ことをお勧めする。

経験豊富なコーチによる支援が、プロダクトオーナーのスキルアップには重要である。

コミュニティ

島根県でもこのようなコミュニティが形成され、人材育成が活発になることが望まれる。

② NaCl

44

契約

アジャイル開発手法では開発を行いながら仕様を決定する手法のため、開発する前の仕様

が必ずしも契約満了時に網羅されている保障が無く、契約の仕様として機能の仕様を定義

することが難しい。そのため、アジャイル開発手法を採用し、外注先と開発を行う場合に、

契約では成果物として開発するシステムの仕様を決定することが課題として考えられる。

この課題を克服するためには、契約時では仕様をある程度柔軟な記載とし、機能名などは

極力明言しないようにし、仕様を柔軟に変更する契約が望ましいと考える。

機能が事前に決まらないために、費用をどのように決めるか、といったことが課題として

考えられる。この課題を克服する方法として、作成するシステムの位置づけを明確にし、

最低限の機能要件を設定し、おおまかな期間を設定してその期間内で開発する人員を最低

限の人数を参画させるようにし、その人員のコストと期間で費用を出す方法が考えられる。

人材育成

外注先が Rubyに精通していない場合、期待する成果が上がらないためにイテレーション毎

の成果が見込めず、満足なレビューが出来ない恐れがある。また、アジャイル開発手法に

精通していない場合は、開発工程の進め方で効率良くイテレーションを回せなかったり、

リリース毎の品質などを確保したりすることが難しくなり、サービスインの遅れなどが予

想される。

発注者側ではアジャイル開発手法に精通した人員をプロダクトに配置し、外注先を含め管

理・運営することでアジャイル開発手法の工程が円滑に進むと考える。また、外注先での

Rubyの習熟度については、開発前にコーディング規約の整備や、Rubyでの開発教育などを

行うことである程度は開発を円滑に進めることができると考える。ただし、開発について

はやはり Ruby言語に精通した人間を１人以上配置し、開発するソースコードを定期的にレ

ビューしたり、精通した開発者と XP などの方法で技術向上を開発工程で期待したりするこ

とが重要ではないかと考える。

自社サービスで Ruby 言語を利用したアジャイル開発手法を実践する場合、プロダクトオー

ナーへいかにアジャイル開発手法の意義を伝え、最大限の協力をして頂くかが重要である

と考える。プロダクトオーナーがアジャイル開発手法を理解出来ていない場合、アジャイ

ル開発手法の特徴である、変化する仕様を整理出来ず、製品のコンセプトが揺れる可能性

が有り、発注者として求めるシステムが構築出来ない可能性がある。

外注を利用した開発において、アジャイル開発手法を採用する場合、開発に携わる開発者

の Ruby のスキル、アジャイル開発の理解について事前に発注者側は把握する必要があると

考える。

体制

アジャイル開発手法に精通した人員を発注者側に配置するか、またはコンサルタントなど

を導入し、アジャイル開発手法に不慣れな業者を導く事で、開発初期から一定の成果が期

待できると考える。

顧客参画

「顧客が開発に参加する時間が取れるか」や、「顧客側のメリットの理解」ということが課

45

題としてある。顧客が開発に参加し、真に欲しい機能を開発者と共に開発出来るかはアジ

ャイル開発手法において重要なため、発注者側の理解が必要と考える。また、アジャイル

開発のような、先に仕様を決定しない方法の場合、顧客に不安感が生まれる可能性も懸念

されるため、顧客に対してアジャイル開発手法のメリットを十分に説明するための提案が

必要と考える。

③ プロビズモ

契約

リファクタリングにより、常にソースコードは見直されるためステップカウント法での見

積もりは合わない。機能規模を基本にした手法で見積もるのが良いと考える。機能規模を

数値化する手法としては、ファンクションポイント法、ストーリーポイントなどがある。

請負型のシステム開発において、イテレーション(スプリント)毎に見積もりを行うことは

難しい。開発の前にシステムの要件を整理する計画フェーズを設け、初期見積もりを行う。

変更要求や新たな要望が発生した場合は、再見積もりを行う。再見積もりのタイミングと

してはイテレーションの区切りなどが挙げられる。

初期見積もり額での契約を基本とし、初期見積もり額に、バッファとして変更分を上乗せ

した額を予算とする。

発注者と開発側は、修正コストがバッファを超えないよう最大限の努力を行う。

請負契約の場合、検収、納品してからの本番運用しかできない。そこで、発注者とは別に、

エンドユーザーを開発プロジェクトに含めることで、イテレーション(スプリント)毎の本

番運用を行う。

人材育成

インクリメンタル開発を始めとするアジャイル開発経験者の不足

インクリメンタル開発を始めとするアジャイル開発手法のユーザー側の理解不足

開発者にもコミュニケーション能力が求められる。

インクリメンタル開発を始めとするアジャイル開発手法は、実際に経験しないと身に付か

ない。

Rubyを使ったシステム開発では、書籍や教育ではすべてをカバーすることはできないため、

インターネット上の情報に頼らざるを得ない。情報の真偽の判断能力、数多くあるライブ

ラリの選別能力や有益性などを見極める能力が必要とされる。

プロジェクト参加者には、使用する開発環境を有効活用できる能力が必要とされる。

アジャイル開発手法を適用する場合は、ユーザー側コストオーナや担当者もアジャイル開

発手法を理解しておく必要がある。開発者側からの説明のみではなく、研修受講や試行な

どが必要である。

Ruby の実践的な開発経験、JavaScript や Ajax、Database など Web システムに関連するス

キル、各種ツールを使いこなすスキルを持ったメンバーが必要となる。

1ヶ月という開発サイクルを習得する必要がある。

テストコードを書くことは、初心者には敷居が高い。

46

④ 日本ハイソフト

契約

準委任契約でも構わないという顧客に対してはそれで契約し、準委任契約が難しい顧客に

対しては、従来通りに要件定義を時間を取って行った上で、工数を算出し、見積りを提出

後、請負で契約する。

人材育成

顧客と開発者をセットとして教育講習する場が必要である。

スクラムマスターが開発スコープと進捗を把握し、顧客と開発者双方に適時に公平なアド

バイスを与えられるスキルを持たなければならない。この様な人材をどう育てるかは 1 つ

の課題である。

顧客はベンダーに丸投げではなく、一つ一つの作成物に関して、密接に関わって、一緒に

なって作っていくという手法である。顧客への理解と協力をどのように得るか、顧客への

教育をどうやって行うか、が課題である。

顧客参画

「顧客」にどう理解してもらい、どう協力してもらうか、が課題である。

PR

県内ＩＴ企業に「アジャイル」という開発手法がある事を知って貰うことから始めるべき

であろう。

⑤ まとめ

契約

最終的な成果物を取り決めるのが難しく、途中での要求変更が発生することを考えると、

請負での契約は難しい。準委任契約が適している。

人材育成

Rubyやアジャイルに熟知した開発者の育成が必要である。

アジャイルに関してはユーザーの育成も必要。特に、プロダクトオーナーの役割や振る舞

いについて理解してもらう必要がある。

体制

アジャイル開発にはじめて取り組む際には外部のコーチ・コンサルタントが参画するのが

望ましい。

顧客参画

アジャイル開発では顧客にも相当の負担を強いることになるが、メリットを理解して、協

力してもらうことがポイントとなる。

コミュニティ

Rubyやアジャイルのコミュニティをバックアップする。

PR

47

県内 IT企業に向けた「アジャイル」のアピール活動を行う。

48

4. 総括

4章では、実証事業の結果から Rubyを用いて反復漸進型と顧客参加型な開発手法を採用した時に、顧

客満足度にどのように寄与するのかを評価した。

4.1. Ruby・反復漸進・顧客参加型開発の特徴と顧客満足度の関連

Rubyと反復漸進・顧客参加型（＝アジャイル）の特徴を活かした開発は、結論として顧客満足度向上

に効果があることが分かった。その理由を以下の図を用いて説明する。

Rubyとアジャイルの特徴を生かした開発は、①ビジネスへの適応性向上、②個人・組織の成長性、

③新しい価値の発見の 3つの特徴的な顧客満足度を向上させている。

① ビジネスへの適応性向上

Rubyにはアジャイル開発をサポートするような定番になっているツールがあり、これらを活かした開

発をすることにより、開発スピードがアップし、修正してすぐに確認することが可能になる。このこと

は、頻繁に顧客とベンダーが対話し、動くものをベースにユーザーのニーズを引き出していく、反復漸

進・顧客参加型の開発を強力に支援するものである。

また、アジャイルのエンジニアリングプラクティスを実践することにより、保守性・変更容易性を高

めることができ、システム規模や複雑性が大きくなっても高い開発スピードを維持することができる。

② 個人・組織の成長

49

Rubyやアジャイル開発は「人」に副次的にフォーカスしている。モチベーション高く、顧客とベンダ

ーが信頼関係を築き、お互いを高め合いながら開発を進めることができる。これによって、個人・組織

の成長を感じることができる。

一方、Rubyやアジャイルのいずれを実践するにもスキルが必要とされるが、幸いこれらの学習をサポ

ートする環境やコミュニティがたくさんある。特に、Ruby に関しては島根に開発者のまつもとゆきひろ

氏がいるというのが島根県の大きなアドバンテージになっている。

③ 新しい価値の発見

反復漸進・顧客参加型の開発は、構築しているソリューションの価値に着目し、動くものをベースに、

顧客とベンダーが繰り返し対話していく。それにより、当初想定していなかったソリューションの効果、

必要機能、実現手段、等を発見することに繋がる。可能であれば、ユーザーを巻き込み実際に使用した

際のフィードバックを頻繁に取り込んでいくことで、よりユーザーの価値に繋がるソリューションを構

築することができ、新しい市場を開拓することに繋がる。

50

4.2. 課題とアドバイザリーボードからの提言

実証事業から出てきた結果に加え、現在のソフトウェア産業の問題点、顧客ニーズの変化、それらに

伴う産業構造の変化を勘案すると、Rubyを使ったあるべきビジネスモデルとして、反復漸進・顧客参

加型の開発手法が適していると考えられる。

同時に、実証事業を行った結果からは、反復漸進・顧客参加型の開発手法を実践する上でのいくつか

の課題が浮き彫りになった。以下の図に本事業のまとめと実践上の課題をまとめた。

51

これらの課題に対処するためユーザー企業、ベンダー、サポート環境（公官庁・地方自治体、学術・

研究機関、コミュニティ）に対して提言と目指すべきゴールをまとめた。

52

① ユーザー企業への提言

ユーザー代表者の育成、経営者の理解

アジャイルを使って円滑に開発を進めるには、ユーザー企業が情報システムの仕様に関するプロジェ

クトの代表者を置き、が反復を繰り返していく中で開発を行う対象や範囲を判断していかなければなら

ない。その為には、その判断ができるユーザー代表者の育成が必要である。さらに、アジャイルを使っ

た開発を成功させるためには、そして、ユーザー企業の経営者がアジャイルを使った開発に理解があり、

代表者に適切に権限を委譲していることが鍵となる。

ビジネス領域の見極め

今回の実証事業では比較的小規模な情報システムの開発を対象とした。しかし、現実には規模や適用

分野などが異なる様々な開発がある。本事業では、それらの全てにおいて Rubyとアジャイルが適してい

るという結論を出しているわけではない。ユーザー企業で行っているシステム投資において、この組み

合わせが生きるようなビジネス領域を見極めて頂きたい。特に、仕様が頻繁に変化する場合、早期投入

が求められる場面、不確実性が高い場合、さらには競争力のために作りながら仕様を発見していくよう

な場面があれば、積極的に Ruby とアジャイル開発の適用を検討していただきたい。

② ベンダーへの提言

開発者の育成

各事業者の報告から、Ruby やアジャイルを使った開発にはスキルが必要であり、未経験者だけでチー

ムを組んでもうまくいかないという結果が出た。未経験者がチームを組むときにはチームに Rubyやアジ

ャイルを使った開発を推進できるコーチを参画させ、実践の中で育成するべきである。また、地域コミ

ュニティ等へ開発者を参加させることで、社外の経験者との相互育成にも着目して頂きたい。

現場重視と改善

本報告書にある各事業者の実証結果はあくまでも一例である。報告された事例は参考にはなるが、こ

れをそのまま実践してもうまくいとは限らない。一般的な方法論の知識やスキルを着けた後で、各ベン

ダー、ユーザー企業のビジネス特性やプロジェクトのコンテキストに合わせて現場で工夫し、自分たち

に合った開発の進め方を試しながら改善していくことが肝心である。

③ サポート環境に対する提言

官（官公庁・地方自治体）に向けて

実ビジネスでの検証

今回の実証事業は島根県の助成で行われたため、ユーザー企業とベンダーのあいだに金銭のやり取り

が発生しないモデルであった。そのため、ユーザー企業とベンダー双方に妥協が見られた点もある。今

53

後は実際に契約が発生する実ビジネスで Rubyビジネスモデルの検証を行っていただきたい。

保守性・変更容易性の評価

いずれの事業者も実証事業の短期間で開発を行ったため、開発終了後の保守性・変更容易性について

は検証できていない。長期間にわたって観測しなければ正確な検証ができない指標値に関しては、今回

の実証事業に参加した事業者から、事業期間終了後も定期的に取得していただきたい。

契約モデルの整備

今回の実証事業では、ユーザー企業とベンダーのあいだで金銭のやり取りが発生するような契約は行

われていない。しかし、実ビジネスを考えたとき、従来型のソフトウェア開発の契約はアジャイル開発

には適さないことが指摘されており、契約の問題についても創意工夫して取り組んでいただきたい。こ

れについては『IPA非 WF開発 WG成果報告書』が参考になる。5

④ 学（学術・研究機関）に向けて

スキルを持った人材の供給

オブジェクト指向、モデリング、デザインパターンは、Rubyでシステム開発を行うのに必須のスキル

である。更には、必須スキルの上にバージョン管理、ユニットテスト、テスト自動化を組み合わせるこ

とでアジャイル開発の主要なプラクティスを実践できるようになる。実社会での人材の立ち上がりを早

くするためにも、社会に出る前の段階でより実用的なエンジニアリングスキルの教育と、可能であれば

プロジェクト型教育(Project Based Learning)による定着を図っていただきたい。

⑤ コミュニティに向けて

情報共有の場

Rubyとアジャイル開発を使ってシステム開発をうまく回すには、一企業や一個人で成長していくには

限界がある。それぞれが学んだノウハウを流通させていきユーザーや開発者が効率よく成長していくこ

と、他者と支えあうことによるモチベーションの維持や向上が必要である。イベントや勉強会などによ

る情報共有の活性化や、人と人の繋がりの場の提供に努めていただきたい。

⑥ まとめ

本事業では、「Rubyの特徴を活かし、顧客ニーズを素早く的確に捉え，顧客満足度を高めるためのソ

フトウェア開発手法とは何か？」を探った。

5 IPA「非ウォーターフォール型開発 WG 活動報告書」http://sec.ipa.go.jp/reports/20110407.html

54

その結果、反復漸進型・顧客参加型の開発手法が適している事が分かった。反復漸進型の開発手法は

小さく素早く作り、頻繁に提供することで顧客価値とのズレを小さくし、ビジネスへの適応性を向上さ

せることができる。顧客参加型の開発手法は、顧客と開発者が積極的に対話することでユーザー企業と

ベンダーが顧客価値を共有・発見・創造することができる。Rubyの特徴はこの開発手法を強力に支援す

ることができる。

この開発手法が適していると言える背景には、ソフトウェアを作ることが価値だった時代から、ソフ

トウェアを使ってもらうことが価値である時代に変化していることがある。年を追う毎にビジネス環境

の変化のスピードは増しており、顧客価値も変化し続けている。作り終えたソフトウェアは時間が経つ

ごとに顧客価値とのズレが大きくなりソフトウェアの価値が減尐していく。そういった環境の中で、顧

客満足度を高めるには、顧客からフィードバックを得て、顧客価値の変化に合わせてソフトウェアを追

加・変更し、ソフトウェアの価値を増大させていく必要がある。

この開発手法は、ユーザー企業にはビジネス価値の向上や市場の創造を、ベンダーにはモチベーショ

ンの高い開発者の育成や競争力の向上を、ユーザー企業とベンダー双方に対してはうれしさや幸せ・楽

しさをお互いに共有し、生き生きと働ける環境をもたらす。その結果、効果的なビジネスの構築と新し

いビジネスの創造ができる IT企業／ユーザー企業が育つ。それが、本事業の最終目標である県内企業の

競争力強化と下請け構造からの脱却に繋がる。

今後、Ruby ビジネスモデルを使い、島根県が IT 産業の中核として発展していくためにも、本報告資

料が活かされることを願っている。

55

5. Rubyビジネスモデル研究実証 アドバイザリーボード事業について

5.1. アドバイザリーボード事業の委託先

(株)永和システムマネジメント

5.2. アドバイザリーボード事業の研究会メンバー

委員長：

平鍋 健児氏

(株)永和システムマネジメント取締役副社長

(株)チェンジビジョン 代表取締役社長

アジャイルプロセス協議会フェロー

委 員：

濱 勝巳氏 (株)アッズーリ代表取締役社長、アジャイルプロセス協議会会長

倉貫 義人氏 TIS（株）所属、SonicGarden カンパニー長

鷲崎 弘宣氏 早稲田大学基幹理工学部情報理工学部准教授

前川 徹氏 サイバー大学 IT総合学部 教授

伊久美 功一氏 (独)情報処理推進機構 ソフトウェア・エンジニアリング・センター

以上