Open@ReeL 概要説明
2011/12/01 版

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

1

目次
1

基本概念

2

プロセス概要

3体制

4

契約と変更管理

5

ツール

6

プラクティス

2
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

1.1 課題とその背景■ 課題

システムの複雑化 → 要件定義が纏まりきらない
変化スピードアップ → 要件変更が発生する■ 背景☑ 日本国内では圧倒的にウォーターフォールプロセスが採用されているが、要件変更に柔軟に対応するプロセスが求められる。
☑ 海外ではアジャイルプロセスを適用した大規模システム開発の成功事例が増えてきた。
☑ アジャイルプロセスに向いたツールが整備されてきた。

■ 日立ソリューションズでは、日本でも適用可能な大規模システム開発向けのアジリティ開発手法「COMMONDATION-ReeL」を開発。

「COMMONDATION」は、株式会社日立ソリューションズの登録商標です■ 日立ソリューションズ独自部分を取り除いた部分をOpen@ReeL として公開。

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

3

1.2 ReeL の基本理念• 基本的な考え方– アジャイル開発手法に取り入れるべき良い点がある• 要求変更の対応コストの削減• 顧客満足度の向上• 幸せなプロジェクトの追及– 日本固有の事情がアジャイル開発手法に合わない• SI案件に見られる一括請負型の受託開発構造• 顧客と SIer の密接な関係• ウォーターフォール型に特化して磨き上げた品質管理能力

新しいアジリティ開発手法の開発が必要
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

4

1.3 アジリティ開発手法の開発■ アジャイルといえども要件をできる限り速く固めるのが理想☑ 要求フェーズで要件確定度を上げる☑ ユーザビリティ・テスティングによるエンドユーザからの早期フィードバックを得る■ 要件変更による修正量を削減☑ ドキュメント量の削減と簡易化☑ ドキュメントリバースによる自動生成■ 修正スピードアップ、コストの削減☑ テスト自動化☑ プログラム自動生成☑ ドキュメント自動生成☑ 仕様確定のスピードアップ☑ オフショア活用■ 導入容易性を追求☑ 既存のWFプロセスとの親和性を重視☑ V字モデルの底辺からの段階的な導入
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

5

1.4 Open@ReeLの特徴■ ウォーターフォールとアジャイルの融合☑ ウォーターフォール型の段階的にリスクをヘッジできるメリットを活かして、大きく要求(従来のWF)／反復／検証(従来のWF)の３つのフェーズに分割☑ アジャイル開発に顕著にみられるフィードバックの仕組みを各所に導入■ 請負契約での要件変更への柔軟な対応☑ 請負契約では、事前に納期と成果物の内容を決定する必要があるが、一部に要件変更の余地を残して、全体を見積もり合意する☑ 要件変更可能な枠の管理方法について、顧客と合意する■ 要件変更への対応コストの低減☑ 修正コストを低減するため、ドキュメントの軽量化とツールによる自動化環境を整備☑ 要件変更に対応可能な開発体制を作る為、内部でアジャイル開発のプラクティスを採用。

■ プロジェクトへの導入コストの削減☑ ストーリー／タスク管理ツールや開発／テストツールの標準環境を整備☑ 管理者向け／エンジニア向けの教育を整備
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

6

目次
1

基本概念

2

プロセス概要

3体制

4

契約と変更管理

5

ツール

6

プラクティス

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

7

2.1 WFとAgileの融合
WF

Agile

ReeL
調整

• 適用レベル(工程種類)の限定• 適用期間の限定

メリット• リスク制御 (デリバリーの安定化)• 継続的改善効果 (生産性の改善)
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

8

2.2 プロセス全体像作成フェーズ

要求フェーズ検証フェーズ

要件定義（ステージ２未確定分）

要件変更

要件変更

要件定義
（全体）
要件変更

要求フェーズには基本設計(一部詳細)まで含める。
また作成フェーズには結合テストまで含める。
プロジェクト毎に要調整。

要件変更

開発
画面設計
アーキテク
チャ検証

ステージ１
（主機能開発）共通部品
設計

ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

ステージ２（サブ機能開発）
ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

保守ドキュメント作成
ｲﾃﾚｰｼｮﾝ

ＤＢ設計

単体テスト・結合テスト（イテレーション内で実施）

テスト（総合テスト、システムテスト）

総合テスト・システムテスト計画

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

9

2.3 フェーズ分割の考え方
ウォーターフォールの良さを残しつつ、アジャイル開発の反復の仕組みを取り入れる
要求フェーズ作成フェーズ••••

受託開発を想定して、ある程度の要求の明確化のフェーズを設ける
要求については、曖昧さを許容する
大規模開発を想定して、アーキテクチャ検証や体制(共通基盤・開発標準)の整備期間とする。
成果物のドキュメントとしては最小限に抑える••

要件の取り違えや変更を早期に検出する為、小さい反復(イテレーション)を何度も繰り返す体制的に頻繁なリリースに耐えられない場合に備えて、イテレーションをまとめたステージの概念を導入する。
基本イテレーション単位で、ユーザーに確認できるものをリリースする。
開発フェーズ中でも、要件変更を受け入れる
イテレーション内では、頻繁なリリースや仕様変更に耐えられるように、アジャイル開発手法のプラクティスを積極的に導入する。

•••

テストフェーズ••

これまでの品質管理のノウハウを生かすため、最後にテスト用のフェーズを別枠で用意する。
受託開発を想定しているので、納品や引き継ぎに必要なドキュメントなどのリソースも、ここで整備する

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

10

2.4 ステージとイテレーション
作成フェーズ以降、段階的リリースのタイミングに基づくいくつかの「ステージ」に分割「ステージ」は「イテレーション」と呼ぶ固定長のタイムボックスで区切る
要求フェーズ検証フェーズ作成フェーズ
ステージ２

ステージ１

１月目

２月目

３月目

４月目５月目

６月目

ステージ１

ステージ３

７月目

８月目

９月目

１０月目

ステージ２

ステージ４

１１月目

ステージ３

１２月目

４

ステージ
（中間）成果物の主要な顧客向けリリースのタイミングを定める区切りである。作成
フェーズと検証フェーズにおいて定義し、作成フェーズのステージは３～４回のイテレーションで構成する。

ｲﾃﾚｰｼｮﾝ
１ｲﾃﾚｰｼｮﾝ
２ｲﾃﾚｰｼｮﾝ
３ｲﾃﾚｰｼｮﾝ
４ｲﾃﾚｰｼｮﾝ
５ｲﾃﾚｰｼｮﾝ
６イテレーション
繰返し型開発の繰返し単位。
基本的に全イテレーションを同一の長さとする。作成
フェーズに適用する（他フェーズに適用してもよい）。
11
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

2.5.1 要求フェーズ
ビジネス分析
アーキテク
チャ設計
システム
構成設計
画面設計
開発
基準作成

全体モデル構築

ユーザ機能リスト作成

ユーザ機能単位計画

ビジネスフロー図の作成

ユースケースの抽出

シナリオの作成

アーキテクチャ設計

アーキテクチャ検証

フレームワーク・処理方式設計

プロトタイプ開発

インフラ設計ハード／ソフト／ネットワーク設計
画面設計開発設計

開発基準作成

用語定義、画面レイアウト、コーディング、ＳＱＬなど

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

122.5.2 作成フェーズ
ステージ
ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

３回目のイテレーション

１～２回目のイテレーション
イテ
レーシ
ョ
ン
計
画

開発（タスクの実行）

テスト計画

ビイ
開発者 ュ テ
テスト ー レーシ
顧客
ョ
ン
テスト
レ

毎日のミーティング
１日

3週間

4日

1日

イテ
レーシ
ョ
ン
計画
１日

開発
（タスクの実行）

開発者
テスト

ビイ
ュ テーレーシ
顧客
ョン
テスト
レ

1週間

１週間

テスト計画
毎日のミーティング
2週間

1日

１ヶ月

１ヶ月

実装するのに必要なタスクを検討する。
イテレーションゴールを決定する。
イテレーション計画作業に慣れるまでは２～３日としても良い実行可能なデモンストレーションをユー
ザを含めた関係者全員に発表する。
・レビュー会議（２時間程度）
その後、チームで反省会を実施する
・ふりかえり（２時間程度）

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

13

2.5.3 作成／検証フェーズのテストプロセス
作成フェーズ
ステージ１～２
ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

検証フェーズイテレーション
イ
テ
レーショ
ン
計
画

③開発者
テスト

①開発（タスクの実行）

④顧客
テスト

②テスト計画毎日のミーティング

作業名

No.

内容

①

開発

単体テストは、コーディングと同時に行う

②

テスト計画

結合テスト計画を作成する③

開発者テスト

開発者が結合テストを実施する

④

顧客テスト

顧客が結合テストを実施する

イ
テ
レーショ
ン
レビ
ュ
ー

ステージ３

ステージ４

⑤開発者テスト⑥顧客テスト

No.

作業名

内容

⑤

開発者テスト（総合テスト）

総合テストを実施する

開発者テスト（システムテスト）

システムテストを実施する

顧客テスト

顧客が最終確認テストを実施する⑥

14
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

目次
1

基本概念

2

プロセス概要

3体制

4

契約と変更管理

5

ツール

6

プラクティス

15
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

3. 体制
複数チームの自発的な連携に基づき、それを促進するための体制設計
フェーズ別体制•••

要求フェーズと、作成・検証フェーズで体制を変える（別契約であることを想定している）
要求フェーズは、要件定義の他、アーキテクチャ設計、基本設計、開発基盤など開発全体にかかわる共通部分の構築を行うため、集結した体制で実施する
要求フェーズの参加者が散開して作成フェーズの体制を立ち上げることで、要件や基本設計、開発基盤などの要求フェーズ成果物の伝播を効率化する

大規模開発対応••

作成フェーズは、複数の開発チームによる並行開発体制をとる
チーム間調整の仕組みとして、ファシリテーター、統合チームを置く

顧客の参加••

顧客の参加はできる限り要請し、特にプロダクトオーナーの役割はフルに期待する
ただし基本想定では各チームに常駐されることまでは期待せず、代わりにブリッジ的な役割としてチーム毎のＢＡを置く

分散開発対応••地理的に分散する場合は、チーム単位にする（チームメンバの居場所が分かれないこと）
マスタとＢＡがブリッジの役割を果たす

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

16

3.1 体制図Ｐ２作成フェーズ

Ｐ１要求フェーズＰＯ

ＢＡ

Ｐ３検証フェーズ

上位会議メンバＰＭ

ＰＭ

ﾌｧｼﾘﾃｰﾀｰ

ﾌｧｼﾘﾃｰﾀｰ

ＩＴＡ

顧客チーム

業務開発チーム

ＢＡ
ＢＡ

統合チーム

ＰＯ

ＩＴＡ

ＱＡ

ＢＡ

ＢＡ

ＢＡ

ＱＡ

マスタ

マスタ

マスタ

ＱＡ

エンジニア

エンジニア

エンジニア

モデラー

マスタ

エンジニア

エンジニア

エンジニア

DB担当

マスタ

エンジニア

エンジニア

エンジニア

エンジニア

エンジニア

エンジニア

共通担当

エンジニア

エンジニア

エンジニア

共通担当

テスター

テスター

テスター

マスタ

モデラー

作成フェーズでは、上位層ス
クラムと業務開発チーム層ス
クラムの２層構造

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

SI担当

17

3.2. チーム間結合の管理
複数の開発チームをまとめる為に、統合チームが小さく要件を砕いて、開発チームに委託する。
オフショア活用を想定

統合チーム
INPUT
・要件・アーキテクチャ
・開発基準
etc.

イテレーション

イテレーション

イテレーション

イテレーションOUTPUT
・成果物
・ドキュメント・指標データ
etc.

チームA
チームB
チームC
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

18

3.3 タスク管理
イテレーション

統合
チーム(開発チーム複数[1] 先行検証[2] ストーリー決定

アーキテクチャ
設計書([3] タスク分割)[9] ストーリー別受入れ[10] 全チーム
成果物結合[7] タスク消化
状況確認

成果物

タスク一覧
[4] タスク再分割[8] ストーリー別
タスク完了[6] タスク消化)[5] タスク割り当て

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

19

3.4 役割の割り当て
担当者

略称

作業

作業内容

プロジェクトオーナー

PO

仕様決定

プロジェクトの発注者で仕様決定を行う

プロジェクトマネー
ジャPM

プロジェクト管理

プロジェクトの責任者。プロジェクト計画を策定し、体制を整える。人材スタッフや資源、予算、スケジュール、品質などを管理し、プロジェクトを円滑に進める。

プロジェクト纏め

プロジェクトを纏め、最大の成果を引き出すリーダー。

要求分析

要件の粒度を揃えるための作業。要件を詳細まで決めることはしない。UMLではユースケースを利用する。業務フローはアクティビティ図で作成する。要件定義チェックリストを利用する。要件をリストアップして、大雑把 な見積もりが出来るようにする。

ビジネス分析

アジャイルのストーリーを導きだすために、ビジネス分析を行う。ビジネス分析とは、業務を整理していき、ビジネスプロセスをつかむ。また、ビジネスプロセスから起動される機能（ユースケース）を明確する。

アーキテクチャ設計

システム全体のアーキテクチャを設計する。フレームワーク、画面周りのツール、データベース、アプリケーションサーバーなどの選択。ハードウェア構成、ネットワークなどの設計。 アプリケーションアーキテクチャの設計。

モデラー

概要設計

全体のソフトウェアの構成を把握する為、概要の設計を事前に行なっておく。UMLによるモデリングやデータモデリング等を実施する。

マスタ

チーム纏め、設計・プログラミングチームを纏めてエンジニアを率いる。

エンジニア

設計・プログラミング

ユーザ機能を実装する。

テスター

テスト

テスターは、BAやストーリーカードを元にテストケースを作成する。

DB担当

DB設計、管理データベースの設計、管理を行う。

SI担当

構成管理

成果物の構成管理を行う。

共通担当

共通化

共通コンポーネントや部品の開発と提供を行う。

QA

品質保証

成果物の品質に責任を持つ。

ファシリテーター
ビジネス
アナリスト

ITアーキテクトBA

ITA

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

20

目次
1

基本概念

2

プロセス概要

3体制

4

契約と変更管理

5

ツール

6

プラクティス

21
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

4.1 契約の考え方• 見積もりとコスト管理の原則的な考え方– 基本的に大半の要件が事前に確定可能であることを想定する。
– 付加的に、追加・変更可能な要件の存在を許容する。
不確実性の管理について– 要件における不確実性を事前に定めた一定の大きさ(バッファ)内に限定する– バッファをコスト換算するに当たって、顧客に対して説得力のある見積りの単位を使う
具体的な方法について
不確実要件– 応用プラクティスとして定義する。

確定要件

22
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

バッファ

確定
見積り

4.2 変化に強い体制の構築
不確実性に対応する為に– 要件管理方法に加えて、開発体制自体を変化に適応しやすいものに変える必要がある。
アジャイルプラクティスの積極的な導入変化に強い開発手法とは– 予見型から適応型へのパラダイムの変換• 変化を防ぐのではなく、変化を受け入れる(=適応する)– 以下の2つの側面を持つ
1. 適応力のある開発体制を構築可能⇒ 反復・リファクタリング・TDD・CI・シンプル設計

2. 変化を検出しやすい仕組みがある⇒ 反復・ペアプロ・レトロスペクティブ・スタンドアップミーティング・バーンダウンチャート

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

23

4.3 ドキュメント「最小限のドキュメント」の観点• 関係者間の暗黙知の共同化を促進– 充分なコミュニケーション、コードの共同所有などのプラクティスの採用• 共同化によってカバーできる伝達の範囲では、形式的なドキュメントの作成を避ける– プラクティスの採用度合いや効果如何で、必要なドキュメントのボリュームは変わる– カバーできないことがあり得るケース：• 地理的に分散したチームで、フェイスツーフェイスの機会が限られ、（時差などで）同期的なコミュニケーションが困難• 一括発注のような垂直分業形態での開発が必須の場合• プロジェクトの完了時、伝承のためのドキュメントは必要– 保守ドキュメント作成の工程を設定

Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

24

目次
1

基本概念

2

プロセス概要

3体制

4

契約と変更管理

5

ツール

6

プラクティス

25
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

5. ツール関連図
共有サーバ③ソースを取得し、ビルド、テストなどを自動実行
継続インテグレーション

開発者PC
設計

①IDEと各種ツールを連携させ、効率的に開発自動生成

IDE
ビルド

メトリクス

単体テスト

コード解析

その他（性能など）

ビルド

メトリクス

単体テスト

コード解析

構成管理

②ソースを構成管理ツールへ格納/取得

回帰テスト④情報を取得し、タスクと関連付け表示

管理者

タスク管理

プログラマ

☑ 継続インテグレーション
ソースの品質確認☑ タスク管理
タスク登録、作業記録など☑ テスト/品質管理
テストの作成、実施など
その他（脆弱性など）

テスト/品質管理
コミュニケーション☑ 継続インテグレーション
ソースの品質、進捗確認など☑ タスク管理
タスクの承認・割当、工数管理、スケジュール管理など☑ テスト/品質管理
テストの承認、品質確認など

脆弱性の調査などを実施
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

26

目次
1

基本概念

2

プロセス概要

3体制

4

契約と変更管理

5

ツール

6

プラクティス

27
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

6.1 期間のプラクティス
期間のプラクティス
No.

プラクティス

説明

1○

要件定義、作成、テスト工程の分離全体を要求/作成/検証の３フェーズに分け、要件定義工程で基幹部分を決め、要件の変更は開発のイテレーション単位で対応する

2

○

段階的反復

開発工程では、複数のイテレーションからなるステージごとで段階的に実装する

3○

イテレーション計画

イテレーションの初めにイテレーション計画を行う

4◇

毎日のスタンドアップミーティング

毎日、チームごとに全員参加の短時間ミーティングを行う

5○

レトロスペクティブ

イテレーションの最後に振り返りを実施する

6○

プロジェクト状況の見える化

プロジェクト状況を関係者に常時公開する。

7○保守ドキュメント作成

プロジェクトの後工程で、保守用ドキュメントを纏める

8○

イテレーション毎の顧客確認テスト

イテレーションごとに顧客確認テストを行う

9◇

開発チームの事前準備

要件フェーズの中で開発チームの教育や標準作成等の事前準備を実施する

イテレーション内テスト

イテレーションの最後に自動化テストの充足作業等をまとめて実施する

10○: 必須プラクティス◇: 推奨プラクティス
無: 任意プラクティス

28
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

6.2. 体制のプラクティス
体制のプラクティス
No.

プラクティス

説明

11

機能ごとのチーム編成

複数チームで構成する場合は、チームの規模を１０人以下のメンバ構成に維持し、分割可能な機能単位に振り分ける

12○

ファシリテータとマスタ

プロジェクト全体はファシリテータ、階層構造の場合は、マスタが各チームを纏める

13

○

顧客チーム

顧客または顧客代理がプロジェクトメンバに入る

14

ブリッジＳＥ

分散開発の場合は、拠点間の橋渡しを行うブリッジＳＥをおく

15

組織的なサポート体制

全社的なサポート体制を活用する

チームビルディングのプラクティス
No.

プラクティス

説明

16

表彰

モチベーション向上のため優れた成果を出したものを表彰する

17

レクリエーション

プロジェクトメンバのコミュニケーションとモチベーション向上

18

トレーニングコース

ＲｅｅＬの前提教育

契約とコスト管理のプラクティス
No.

プラクティス

説明19◇

目標コスト契約

顧客との契約に事前にバッファを設定する目標コスト契約を用いる
要件の曖昧度をコスト換算して見える化する

20○

変更コスト管理

機能追加・変更に対するコスト管理
要求変更を受け付け、取り入れるかどうかの判断を適宜実施し、円滑な対応を行う。

FP法によるバッファ算出/見積もり

FP法を用いて、事前のバッファの算出や見積もりを行う

21○: 必須プラクティス◇: 推奨プラクティス
無: 任意プラクティス

29
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.

29

6.3 開発技法と基盤の運用
開発技法のプラクティス
No.
22

プラクティス
○

23
24

○

25
26

○

27

説明

業務フローとストーリーによるビジネス分析

業務アクティビティに注目したストーリー抽出を行い、業務機能単位にストーリーベースの開発を行う

二段階ゴールストーリーと機能の二段階ゴール

テスト駆動開発

テストが開発を主導する、テスト駆動型の開発とする

ペアプログラミング

２人１組の開発

リファクタリング

常にリファクタリングを行いながら開発する

チケット駆動開発

全ての作業をチケットとして登録し、管理する

基盤運用のプラクティス
No.

プラクティス

28

説明

開発環境の迅速な提供

社内外のクラウド環境等を利用した迅速な環境構築

29○

毎日のビルド基本的に毎日ビルドを行う。特にステージごとの最終イテレーションでは必須とする

30

○

構成管理

チーム、プロジェクト単位で構成管理を行う

31

チーム間共通基盤

複数チームによる並行開発における開発基盤の共有

32

進化的な開発基盤

チーム間共通基盤の進化的な更新管理

33

段階的なリポジトリ構成

複数チームによる並行開発における、中央ー分散の階層的なリポジトリ管理○: 必須プラクティス◇: 推奨プラクティス
無: 任意プラクティス

30
Copyright (C) TECHNOLOGIC ART INCORPORATED, All Rights Reserved.