アジャイルソフトウェア開発
事例紹介
株式会社 テクノロジックアート
アジャイルソフトウェア開発グループ
東條 大介

Copyright Technologic Arts Inc.

1

アジェンダ 事例紹介z プロセスの選定
z プロセスの開始
z ふりかえり 最後に

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

2

事例紹介

〜プロセスの選定

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

3

システム概要

機密保持のため、当該スライドはカットさせていただきます。

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

4

採用プロセス・技術の検討
 前提
z ドメイン知識を持つコンサルタントが参画
z オブジェクト指向のスキルを持つエンジニアを4〜5人準備可能 課題
z サービス時間帯（日中）の稼動停止は許されないz アプリケーションの仕様はまだ定まっていない
z ユーザは数百人超
z データの重要度は極めて高い、ミッションクリティカルz 規模に対して納期が短い

 採用技術の検討
z アーキテクチャに拘束はない

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

5

採用プロセスの検討
出典 「アジャイルと規律」

人リチャード・ターナー・バリー・ベーム（レベル2/3の割合）
15%

計画駆動
25%

重要度

変化の度合い（1ヶ月あたりの要求変更）（欠陥時の損失）
35%

アジャイル
5%

多数の生命
10%

貴重な資金

50%

快適
3人

30人

300人

90%

50%

10%

規模

文化（人数）（カオスで繁栄する割合）
Copyright (C) TECHNOLOGIC ARTS INCORPORATED, All Rights Reserved.

6

採用プロセスの検討
出典 「アジャイルと規律」

人リチャード・ターナー・バリー・ベーム（レベル2/3の割合）
15%

スキルの高い25%
エンジニア
４〜５人参画重要度

計画駆動

変化の度合い（1ヶ月あたりの要求変更）（欠陥時の損失）
重要資金も失われる

35%

アジャイル
仕様は定まって5%
いない
10%

多数の生命
貴重な資金

50%

快適
3人

開発人数は１０人程度

規模（人数）

30人

300人

90%

高い自由度
50%

10%

文化（カオスで反映する割合）
Copyright (C) TECHNOLOGIC ARTS INCORPORATED, All Rights Reserved.

7

採用プロセスの検討

△

○◎

◎

◎

重要
資金が失われる

開発人数は１０人程度

スキルの高いエンジニア
４〜５人参画

仕様は定まっていない

高い自由度

プロジェクトは計画駆動開発よりアジャイル開発向きと判断

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

8

採用技術の検討

Perl/CGI
PHP

新規システムの立ち上げにあたって、今さら感あり
スクリプト言語なのでスケーラビリティに難あり

Ruby

オブジェクト指向
スクリプト言語なのでスケーラビリティに難あり.NET.NETに明るいエンジニアが当時不在
知識習得のオーバーヘッドに時間がかかる
Windowsプラットフォームのスケーラビリティ

Java

ミッションクリティカルなシステムで実績多数最有力候補、無難な選択

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

9

工程の整理

シナリオテスト

要件定義〜基本設計
開発

結合テスト

システム
アプリケーションアーキテクチャ設計 アーキテクチャ設計

導入準備〜導入

アジャイルプロセス適用
 開発の前段として以下の成果物を定義
z ワークフロー（ＵＭＬ/アクティビティ図）
z データモデル（ＵＭＬ/クラス図）
z システム化機能一覧
z 画面紙芝居（ＨＴＭＬ）
z システムアーキテクチャ構成、アプリケーションアーキテクチャ構成

 要件定義後の開発〜テストフェーズにプラクティスを適用
z 適用可能な範囲で、適用可能なプラクティスを使う
Copyright (C) TECHNOLOGIC ARTS INCORPORATED, All Rights Reserved.

10

事例紹介

〜プロセスの開始

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

11

メンバー構成

機密保持のため、当該スライドはカットさせていただきます。

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

12

事前準備
 以下のプラクティスの適用を検討
プログラマチーム

ユーザ

テスト駆動開発

コーディング規約

全員同席

Test Driven Development

Coding Standard

Sit Together

設計改善

コード共同所有

短期リリースDesign Improvement
Refactoring

Collective Code Ownership

ペアプログラミング

常時結合

Pair Programming

シンプル設計
Simple Design

Continuous Integration

最適ペース
Sustainable Pace

Small Releases

計画ゲーム
Planning Game

ユーザーテストCustomer Test

メタファ
Metaphor

常時利用
Copyright (C) TECHNOLOGIC ARTS INCORPORATED, All Rights Reserved.

時々利用
13

ツールの準備 開発環境の整備
z 構成管理 / Subversion¾ SQLスクリプトも管理

z 結合マシンと自動ビルド / LinuxサーバーとAnt¾ ウェブとバッチでそれぞれ準備z タスク管理 / 影舞
¾ イテレーティブな開発では随時不具合が発生する

z 統合開発環境 / Eclipse¾ リファクタリング支援機能を活用する¾ Junitを使用してTDDを実践する その他
z ホワイトボードz 開発に関わる人はロールに関係なく1つのオープンな部屋に

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

14

プロセスの進行＜プロジェクト＞＜サブプロジェクト＞＜日々の作業＞

機能（作業）を定義する
アーキテクチャを選定する
機能（作業）を見積もる

数理想日程度のざっくりとした見積機能（作業）をイテレーションに割当機能（作業）をタスクに分解する
タスクを見積もる
タスクを消化する（成果物を結合）
問題あり

問題あり

結合された成果物を確認する

サブシステム間で結合する

問題なし

問題なし

機能単位でプロジェ
クトを進める導入

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

15

プロセス進行上の問題点
 仕様の伝達z 人数が多いため、仕様の伝達が上手く行かない（口頭では厳しい）
z 特にPGへの仕様の伝達にドキュメントが必要
z 上手く行かない場合はプラクティスに拘らず、柔軟な対応を！

 進捗の可視化
z サブプロジェクト間の進捗調整が難しい
z 長期的な予測が立てずらいz サブプロジェクト内でのスタンドアップミーティングの他に、サブプロジェクト間での打合せが必要

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

16

事例紹介

〜ふりかえりCopyright (C) TECHNOLOGIC ARTS INCORPORATED, All Rights Reserved.

17

結果 全ての機能要件を満たす
 アーキテクチャが整っている
 運用開始後もさしたる不具合がない 納期に対して余裕を持ってリリース
 予算超過がない 厳しい残業がない（退職者、体調不良者ゼロ）
 必要最低限のドキュメントが整っている

当たり前のこと、でも難しいことをアジャイルのエッセンスで実現出来た

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

18

プロセス進行上のポイント
 要件定義z 運用設計やデータモデル、システム化機能の整理を予めしておく 言語やアーキテクチャ
z 極力使い慣れた言語、フレームワーク、ライブラリを使う
z レイヤリングする

 立ち上がりz プロジェクトの進め方に試行錯誤や戸惑いがある 品質の確保
z TDDは部分的に適用 → ユーティリティクラスなど
z 適用が難しい部分は従来型のテストを実施し、品質を確保

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

19

プロセス進行上のポイント
過去の実績

14

プロジェクトの立ち上がりは、どうしてもオーバーヘッドが発生！

12
10
8

ストーリ
タスク

6
4
2

５

第４

第３

第第第２

0
１

・言語は慣れたもの！
・フレームワークは慣れたもの！
・要件定義は事前に・イテレーティブ開発経験者を投入！

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

20

最後にCopyright (C) TECHNOLOGIC ARTS INCORPORATED, All Rights Reserved.

21

アジャイルで使うテクニック
 プラクティスの実践のためにz チームにスキルのあるエンジニアを投入する事は欠かせません。
z トレーニングや開発の実践の中で、以下のようなスキルを身につけていく必要があります。
難しいオブジェクト指向
基礎的なＵＭＬ

デザインパターン

リファクタリング
ＴＤＤ
アーキテクチャ
シンプル設計開発言語知識

ビルド構成
インフラ知識常時結合
短期リリース

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

22

 ご静聴、ありがとうございました。

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

23