Supersonic agile

Supersonic Agile Development

1

S. Yoshihara2013/3/13

2x Speed

2

Agile is so fast, but ・・・• アジャイル開発はプラクティスを効果的に組み合わせることによって、開発チームの生産性を最大限に引き上げることができる

• しかし、要件を決める側にはこれとったプラクティスはなく、アジャイルのスピードにあわせて忙しなく重要な要件も決める必要がある。複雑なシステムになれば、ストーリーや画面だけでは仕様の是非を判断できない

• つまり、開発は超高速で走っているが、要件は目先の判断になってしまい、全体俯瞰では見当違いな方向に走っている可能性があるということである

COPYRIGHTS S.YOSHIHRA

3

Agile+Usecase

• まず、要件分析を全体俯瞰で体系的に行うためにユースケース分析を行う。ただし、アジャイルとはスピードが違うので非同期にタスクが組めるようにする


ユースケース分析要件分析

アジャイル開発

ユースケース分析が終わったものからアジャイル開発を行う。ユースケース分析とアジャイル開発は非同期に行えるように別チームとするユースケース分析はユースケース一覧の優先度が高いものから行う。ユースケース分析が終わったものからアジャイル開発を行うユースケース分析ではユースケース図ではなくユースケース記述を使う

4

Agile+MDA+DDD=“Supersonic speed”

• MDA（Model Driven Architecture）ツール– 要件分析のモデルをアジャイル開発まで確実に伝達し、速やかに開発を行うためには支援ツール群が必要である。MDAの考え方はそれを実現するためのものである。生産性を向上させるためにMDAも適用する

– ただし、ビヘイビア（ Behavior）はプログラミングする方が効率が良いので扱わない

• DDD（ Domain Driven Design）のコンセプト– DDDを全面的に適用するのではなく、モデルをそのまま実装に繋げるコンセプトを、MDAツールと組み合わせて利用する


5

• Tech Features– Agile– Usecase– MDA (Model Driven Architecture)– DDD (Domain Driven Design)

• “Supersonic Agile Development”– 上記の高度な技術を最適に組み合わせにすることで、超高生産性なシステム開発を実現する

– この技術を使いこなすためには、必要なスキルとツールを備えた専門チームが必要である

Supersonic Agile Developement


6

Overview


ユースケース一覧

MDAツール

モデルとソースコードの差分抽出と同期支援

アジャイル開発（実装 +単体テス

ト）

システムテスト

リリース

イテレーション　（スプリント）

要件分析

ユースケース分析

ドメインモデル（ DDD ）優先度の高い

ものから分析分析済で、優先度の高いものから開発

開発済のものが、リリースできる単位になった場合

セキュリティ、負荷、障害テストなども

行う

要件分析チーム

開発チーム

プロダクトオーナー

ユースケースの分析済、開発済などのステータスを管理する。更に、ユースケースに優先度を付けることで計画、スコープ管理に使う（プロダクトバックロ

グ相当）

7

サービス• ユースケース定額（ Pay per usecase ）

– 生産性の責任は開発側が負担すべきと考え、ユースケース当たりの価格は定額とする。計画よりも生産性が低かった場合でも追加料金は請求しない

– 開発総額はユースケース数に固定単価を掛けあわせて算出する。開発中にユースケースが増えた場合は追加料金が発生する

– 契約形態は請負・準委任ともに可能とする。どちらもユースケース一覧を作成して見積りをする。請負ではユースケース数を先に決め、開発途中で未開発のユースケースは入れ替えることができる

– ユースケース定額にすればアジャイル開発でも請負（事前にコストを決めるという意味で）が可能になる


8

サービス• 生産性 2 倍（ 2x Speed ）

– 業界標準のメトリクスをもとに独自に調査した標準的な生産性を基に、 2倍の生産性を基準とする

– 基準生産性に達成しなくても、ユースケース定額なので追加料金は発生しない。その分、期間バッファは適切に設定する

• 品質保証– 不可能なものを除いて全てのモジュールはテスト自動化を行う（更にテスト観点によって手動によるテストも行う）

– 開発費用に定率を上乗せすることで、瑕疵担保期間を延長することができる


9

サービス• メンバー保証– Supersonicを習熟したメンバーだけで編成する。安いだけのオフショアなどはもっての外である

• まる見え保証– 進捗、課題、生産性、品質指標は全て見える化する。当然、これらのデータは顧客企業と開発側で全く同じものを参照する


10

仕様変更の考え方（ Q）ユースケース Aを開発したが、顧客企業の判断でユースケースの内容はそのままで画面だけを変更したい。画面を改修するためのコストはどうなるのか？（ A）開発済のユースケースの画面を変更する場合には追加料金は発生する。多少の変更であれば 0.5UC単価とする

（ Q）ユースケース Aを開発したが、顧客企業の判断でユースケースの内容を変更して A ｀にした場合、 A`に改修するためのコストはどうなるのか？（ A)基本的にユースケースが変更されれば追加料金は発生する。多少の変更であれば 0.5UC単価とする


11

• ユースケース数が 100 個のプロジェクトを想定する– Supersonic Agile Development

• 総開発工数： 79 人月

– 従来型（ウォーターフォール）• 総開発工数： 129 人月

要件定義 : 14MM

工数を小さく、期間は短く


ユースケース分析 : 14MM

アジャイル開発 : 50MMシステムテス

ト15MM

開発 : 100MM


15MM

期間短縮

※一般的に、人員は同時投入する程、生産性は落ちるため、上の例では無理なく人員を投入した場合を想定している

12COPYRIGHTS S.YOSHIHRA

Agile+Usecase 技術詳細

13

ユースケース分析• ユースケース分析では、ユースケース図ではなく、ユースケース記述を作成する

• ユースケース記述とは別カタログとしてビジネスルールを定義する。ビジネスルールはユースケース横断的に参照されることになる


ユースケースUC001



ビジネスルール　 BR100



14

ユースケース一覧（ Product Backlog）• 要件分析とアジャイル開発を非同期に並行して行うために、ユースケース一覧がバックログの役割を果たす

• 要件分析がボトルネックにならないように生産性と担当数を最適化しなければならない


ユースケース分析要件分析


ユースケース一覧ユースケース

ユースケース

未分析なものを、ユースケース分析する

ユースケース分析が終わったものは分析済にする

未分析分析済

優先度に応じて、ユースケース分析やアジャイル開発するユースケースを選択する

ユースケース

ユースケース

ユースケース

ユースケース

ユースケース

ユースケース

ユースケース

ユースケース

ユースケース

ユースケース

ユースケース

ユースケース

分析済のものをアジャイル開発する

開発済

15

ユースケース標準 FP

• トランザクションファンクション– 仮に、平均的なユースケースに 4 ～ 8のシナリオのステップがあるとすれば、その半数程度がシステムが行うステップである

– システムが行うステップではアクターとの何らかの相互作用が発生していると考えられる。 FPでいう EI/EO/EQの何れかである

• データファンクション– ユースケースあたり、 0.6 個の ILFがあると仮定する– ユースケースあたり、 0.3 個の EIFがあると仮定する

• ユースケース標準 FP– 上記の前提で、 NESMA 概算法を使って計算すると 14.7 ～ 22.7FPとなる

– 標準 FPは、 1UC=20FPとする


16

開発目標生産性• 業界標準 FP生産性の２倍を目標とする

• 業界標準 FP生産性

– 20FP/MM（基本設計～結合テスト）

• Supersonicの開発目標生産性40FP/MM


•15FP/MM（基本設計～総合テスト）（出典： SEC:ソフトウェア開発データ白書 2012-2013）上記の業界標準 FP生産性では総合テストまで含まれているが、 Supersonicのアジャイル開発は結合テストまでである。よって、業界標準 FP生産性から総合テストを除いた生産性を仮定する

17

要件分析生産性と担当数比率• 要件分析生産性– 7UC/MM　（過去の経験より）

• 開発目標生産性　※前述– ユースケース規模を 1UC = 20FPと仮定する– 40FP/MM = 2UC/MM

• 要件分析・開発担当数比率3.5 ≧ 開発担当数／要件分析担当数

※つまり、開発よりも要件分析の生産性を高めにすることでボトルネックを回避する


18

チーム制• Supersonicは専門チームのみが提供できるサービスである。専門チームの基本構成は次にように決める– Supersonicチーム（ 10 名）

• マネージャ： 1 名　（兼プロダクトオーナー支援）

• 要件分析チーム： 3 名　（ドメインモデラー 1 名含む）

• 開発チーム： 5 名• アーキテクト： 1 名※プロジェクト特性に応じてサポートが追加になることはある　（例えば、最近だと Hadoopのようなスペシャリストが必要な分野）

• プロジェクトの規模に応じて、 n 個のチームを組み合わせる（例えば、 20 人が必要なら、 2チーム編成とする）


19

アジャイル開発• スクラムベースのアジャイル開発を行う• スプリントは 2 週間を単位とする。標準編成のチームには開発者は 5 名なので、 1スプリントあたり、5UCが完成することになる

• スプリント計画では、ユースケース一覧から分析済の 5UCを優先度に従って選択する（大きすぎるユースケースが無いことを開発チームで確認する）

• 他、アジャイルプラクティスを実践する


1 週目 2 週目

1 スプリント

1ユースケース1 週目 2 週目

1 スプリント

1ユースケース

　スプリント▼計画

　スプリント▼計画

20

生産性２倍（ 2x Speed）• 標準 FPと開発目標生産性から 40FP/MM = 2UC/MMとなり、 2 週間で 1ユースケースを作成することになる

• 1ユースケース当たり 2 ～ 4画面だと仮定すれば、MDAツールなどの支援があれば実現可能な生産性である

• 想定スケジュール– 1 人日 =スプリント計画、要件分析インプット– 2 人日 =HTML作成（ 3画面）– 2 人日 =画面開発– 2 人日 =ビジネスロジック＆ DB開発– 2 人日 =テスト（単体 + 結合）– 1 人日 =レトロスペクティブ※ 都度、顧客企業へのフィードバックを行う



Agile+MDA+DDD 技術詳細

22

MDA（Model Driven Architecture）• 一般的なMDAと同じように、要件分析で作成したモデルからソースコードを出力し、ソースコードに実装するまでをシームレスに行えるようにする

• 最新のモデルがソースコードに反映されては困るケースもあるので、スプリント毎のブランチ管理をMDAツールが行う

• モデリングツール（ astahや EA）のプラグイン、開発環境（ eclipse）のプラグインを用意する


ユースケース

ビジネスルール

ドメインモデル

モデリングツール

MDAツール

ソースコード（開発中）

開発環境

リポジトリ

23

DDD（ Domain Driven Design）• DDDの必要性

– Supersonicのような要件分析と開発が同時並行に行われる場合には、要件分析のモデルとソースコードが１対１に対応付くことは最重要である（逆に言えば、 TransactionScriptは採用できない）

• Evansの DDD– Eric Evansの DDDは名著である。扱われている話題も広

範囲に渡る。最も重要なのは、ドメインに業務知識が適切に表現されていて、そのままコードに定義されることである

– 業務知識であるビジネスロジックをエンティティに定義することで、ビジネスロジックを DRYに保てる


24

DDDのポイント• ビジネスロジックを SQLで書いてはいけない？

– ビジネスロジックをドメインが隠蔽していれば、そのロジックが Javaなのか SQLなのかはクライアントには関係ない

– ドメインレイヤーとインフラストラクチャレイヤーの境界が、教科書的見地から曖昧になるのは大きな問題ではない

– 躊躇せず、 SQLを利用すべきである

• JOINはタブーなのか？– JOINの是非は、 DDDの目的である業務知識の適切な実装ということと無関係である

– JOINのロジックをドメインが隠蔽し、 JOINの結果をバリューオブジェクトで返せば良い（何の遠慮があるものか）



その他技術詳細

26

メトリクス• 生産性

– スプリント完了時にリポジトリにコミットしたソースコードから半自動的に FPを計測する

– 生産性は、スプリント毎、開発者毎に全て計測する。スプリントによる生産性の傾向と予測まで行う

– ユースケースのシナリオ数、ビジネスルール数、画面数などと生産性との相関も全て自動的に計測する

• 品質指標– 全モジュールのカバレッジを計測する– 全ての自動テストの結果を集計する– システムテストのバグ傾向分析や、ユースケース単位のバグ傾向分析を行い、レポートする


27

DevCloud

• リポジトリ、ビルドサーバ（ CI）とテストサーバ、バグトラッキングなどの開発環境はクラウドを使う。これらのツール群は Supersonic向けに最適化された標準構成のものを利用する（定額課金）

• クラウドでテストされたものは、顧客企業のオンプレミスなどに移行するか、顧客企業が望めばクラウドのままサービスインすることも出来る

• クラウドの開発環境はリリース後も顧客企業は利用し続けることもできる


Repository Build(CI)Bug Track

TestServer

Cloud

28

ビジネスモデル


29

成果型 SIモデル• ユースケース定額は成果型 SI

– ユースケース数に定額単価を掛けて課金する– よって、人月型 SIではなく、成果型 SIである。よって、技術革新によって生産性を向上すれば、その分の原価を減らし、粗利を増やすことができる

• ユースケース定額単価は、競合他社に対して競争力のある価格とする（高生産性であるから実現できる）


要件定義

開発


要件分析



競合他社

Supersonic

30

ユースケース定額• 競合他社のモデル価格– 業界標準 FP生産性（ 20FP/MM）だと、要件定義を含めて 1UC=200 万円程度になる

• ユースケース定額単価– 1UC = 180 万円　※競合よりも割安– Supersonic開発目標 FP生産性（ 40FP/MM）だと、要件分析も含めて 105 万円程度になるが、バッファとして 75 万円を乗せる


※ユースケースによっては非常に難易度が高い可能性がある。それらの場合、例外的にユースケース定額が適用されないケースはありえる。バッチも同様にユースケース分析をすることを想定しているが、バッチによっては１つのユースケースでも難易度が高い可能性がある。複雑な集計処理や、ビッグ・データを扱う場合などである。これらは、顧客への説明、提案書や契約書などに記載する

31

• ユースケース数が 100 個のプロジェクトを想定する– Supersonic Agile Development

• 総開発工数： 79 人月 = 開発総額 1.8 億円

– 従来型（ウォーターフォール）• 総開発工数： 129 人月 = 開発総額 1.94 億円

総額でも割安で、期間は短く


要件定義 : 14MM

ユースケース分析 : 14MM

アジャイル開発 : 50MMシステムテス

ト15MM

開発 : 100MM


15MM

期間短縮1.8 億

1.94 億


Summary

33

まとめ• Supersonic Agile Developmentとは– Agile+Usecase+MDA+DDDの超音速開発– 成果型 SIモデル

• サービス（価値）は– ユースケース定額– 生産性 2倍（ 2x Speed）– 品質保証

• MDAツールで装備• メトリクス（生産性、品質）を常に共有• Cloudで開発環境を提供


※ 具体的な生産性を謳うのは他にない


Give us carrots!

35

Incentive novelty goods

• “1.5x Speed”を達成したら– Supersonic Towel

• “2.0x Speed”を達成したら– Supersonic T-shirt

• 更に、“ 3.0x Speed “を達成したら– Supersonic Character-Figure　（その前にキャラクターを決めなきゃ）


Documents

Supersonic agile