Agile 試行の評価　　～Ａｇｉｌｅ導入の目的に対して～

ＳＭＳＭ

４． Agile 試行の評価　　～Ａｇｉｌｅ導入の目的に対して～

 確認したかったポイント

 １．システムの価値を最大化

システム開発の費用と期間を固定しシステムの価値を最大化

 ２．開発者のモチベーション向上

自立的な活動

 ３．開発者の能力向上

開発者全員が計画、監視、制御、外部設計に関わることで能力が向上する

 ４．改善活動の定着化

 ５．QCDの評価

 品質： JUAS 報告によるとウォーターホール型開発よりバグ数１．５倍

 コスト：繰返し開発による手戻り量

 納期：「顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供」

２モ

チベ

ーシ

ョ

ン

Ingenious Dynamics

P.40 ４．１　システムの価値を最大化

 スプリント毎の価値の最大化

ユーザの要求を実現する時間ユーザの要求を

実現する脳

外部設計基本設計ＰＧ開発ＩＴ

１人のＳＥ

　＋ＰＭ・ＰＬのレビュー

１つの価値観価値観×価値観

チーム全員

複数名が１つの設計に参加する

→複数のアイデアが出る

ウォーターフォール型

１０Ｈ／機能

１４Ｈ／機能＋　５Ｈ／機能

動くものができることによって

さらに設計アイデアが出る

→設計時間をより多くかける

アジャイル型

★本ＰＪに現れた現象★

・議論の時間が増える

　（計画時に20%のバッファ確保）

・ＩＴフェーズでも機能追加

・設計リードタイムは1/2

・設計コストは２倍

・ホワイトボードで設計　（イメージ合わせ）

　→直ぐにダメと指摘できる

機能に対する価値を高めている

２モ

チベ

ーシ

ョ

ン

Ingenious Dynamics

P.41 システムを構成する機能

４．１　システムの価値を最大化

 機能別に見る価値の最大化

機能の価値

１　　２　　３　　４　　５　　６　　７　　８　　９　　１０

「スプリント毎の価値の最大化」

→より価値を高める

「繰り返し開発による価値の最大化」

→より価値のある機能を選択し開発する

さほど価値（効果）の高くない機能

２モ

チベ

ーシ

ョ

ン

機能

Ingenious Dynamics

P.42 ４．２　モチベーションの評価　　メンバー７名にアンケート

なぜ好印象をもってもらえたのだろう？

２モ

チベ

ーシ

ョ

ン

 スクラム開発について

「従来のウォーターフォール型と比べてどうですか？」

←　とても　　　　やや　　どちらともいえない　やや　　　　とても　→

良い　　　　　　|---○---+---+---|　悪い

面白い　　　　　|---○---+---+---|　面白くないやる気がでる　　|---+-○---+---+---|　やる気がない効率的　　　　　|---+----○---+---+---|　非効率

効果的　　　　　|---+-○---+---+---|　非効果的

 スクラムを続けたいか？

←　とても　　　　やや　　どちらともいえない　やや　　　　とても　→

続けたい　　　　|---○---+---+---|　続けたくない

Ingenious Dynamics

P.43 ２モ

チベ

ーシ

ョ

ン

４．２　モチベーションの評価　　

 仕事が楽しくなる５つのキーワード

「ありがとう」といってもらえる仕事

「なぜ、何のために」がわかっている仕事

「ゴール」が見える仕事

「昨日より今日が」前進している仕事

「おめでとう」が言い合える仕事

スプリントレビュー

ユーザ（ＰＯ）から直接フィードバック

Ｓ計画ミーティング①など

ユーザ（ＰＯ）と直接コミュニケーション

スプリントゴールスプリント期間

レトロスペクティブ

バーンダウンチャートの着地をみんなで喜ぶ

•メンバーみんなで目標に向

かってやっていけた

•相談しやすい

•自主的に他の人のタスクを引

き取る

•機能設計するときに目的を意

識するようになった

•Ｔｒｙに対する結果が２週間後に

出る

•要求変更をエーッと思いながら

も取り込めた

•１次開発ではＰＧ担当でなぜは

わかってなかったが２次開発では要求を理解しながら取り組めた

•１次に比べて機能が充実した

•機能設計で細かい事にこだわ

らない、ゴールを重視

スクラムのルール ^{アンケート結果}

　・仕事が楽しくなるポイントを押さえているスクラムのルール　・アンケート結果も対応

使命感使命感

達成感達成感

成長実感成長実感

一体感一体感充実感充実感

参考文献

　「仕事が楽しくなる！２５のルール」

　大林伸安,ダイヤモンド社

Ingenious Dynamics

P.44 ４．３　開発者の能力向上

２モ

チベ

ーシ

ョ

ン

開発者の能力 ^ベテラン ^中堅 ^若手ＰＪ管理能力

（計画・監視・制御）

外部設計能力

プログラミング能力－

統合テスト能力

Ingenious Dynamics

P.45 改善の分類

① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨

計画

進捗

設計開発コミュニケーション

４．４　改善活動の定着化　～レトロスペクティブの Try ～

　・スプリントが終わる度にレトロスペクティブを実施

　・一人一人が必ず発言するので自ずと改善意識が高まる　・次の２週間ですぐ実践できる

投入予定

時間を積上日別人別

投入計画前半

/

後半

計画

PG

完了

予定日の意識

UT

ｴﾋﾞﾃﾞﾝｽ作成指示

PG

開発タスクの細分化

とトレース遅れﾘｽﾄで

ﾄﾚｰｽ

全員でｲﾒｰｼﾞ合わせ

打合せ中にﾀｲﾑｷｰﾊﾟｰ

外部ﾁｰﾑとの調整は前倒しで

要求・仕様を理解する期間の確保

ﾎﾜｲﾄﾎﾞｰﾄﾞに見たﾁｪｯｸ欄

後半に回してもいいタスク

プログラム構造図の記述予定工数の

80%

で計画

若手２名の指導

ス　　プ　　リ　　ン　　ト

２モ

チベ

ーシ

ョ

ン

Ingenious Dynamics

P.46 ４．５　 QCD の評価

 Ｑ：品質

 時間あたりの欠陥作り込み（ＰＧ開発）　　→組織標準より約２０％多い

 規模あたりの流出欠陥（リリース後３ヶ月）→組織標準より約１５％少ない

 Ｃ：コスト　生産性

 規模（ＦＰ値）あたりの開発工数　→組織標準とほぼ同じ

※但し、今回は計測したのは機能拡張ＦＰ値（派生開発型）

　組織標準はアプリケーションＦＰあたりの標準工数なので

　厳密な比較ではない　（機能拡張ＦＰでの標準工数は規定無い）

 Ｄ：納期

 約２週間毎に対象機能を確実にリリース

　動くソフトを継続的にリリースできた

　厳密な比較はできていないが、さほど悪くならない　欠陥作り込みは多いが流出はむしろ少ない

２モ

チベ

ーシ

ョ

Agile 試行の評価 ～Ａｇｉｌｅ導入の目的に対して～

ＳＭ ＳＭ

４． Agile 試行の評価 ～Ａｇｉｌｅ導入の目的に対して～

 確認したかったポイント

 １．システムの価値を最大化

システム開発の費用と期間を固定し システムの価値を最大化

 ２．開発者のモチベーション向上

自立的な活動

 ３．開発者の能力向上

開発者全員が計画、監視、制御、外部設計に関わることで能力が向上する

 ４．改善活動の定着化

 ５．QCDの評価

 品質： JUAS 報告によるとウォーターホール型開発よりバグ数１．５倍

 コスト：繰返し開発による手戻り量

 納期：「顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供」

２ モ

ー シ

ン

Ingenious Dynamics

P.40

４．１ システムの価値を最大化

 スプリント毎の価値の最大化

ユーザの要求を 実現する時間 ユーザの要求を

実現する脳

外部設計 基本設計 ＰＧ開発 ＩＴ

１人のＳＥ

チーム全員

→複数のアイデアが出る

ウォーターフォール型

１０Ｈ／機能

１４Ｈ／機能 ＋ ５Ｈ／機能

さらに設計アイデアが出る

→設計時間をより多くかける

★本ＰＪに現れた現象★

機能に対する 価値を高めている

２ モ

ー シ

ン

Ingenious Dynamics

P.41

システムを構成する機能

４．１ システムの価値を最大化

 機能別に見る価値の最大化

１ ２ ３ ４ ５ ６ ７ ８ ９ １０

「スプリント毎の価値の最大化」

→より価値を高める

「繰り返し開発による価値の最大化」

→より価値のある機能を選択し開発する

さほど価値（効果）の高くない機能

２ モ

ー シ

ン

Ingenious Dynamics

P.42

４．２ モチベーションの評価 メンバー７名にアンケート

なぜ好印象をもってもらえたのだろう？

２ モ

ー シ

ン

 スクラム開発について

「従来のウォーターフォール型と比べてどうです か？」

良い |---○---+---+---| 悪い

面白い |---○---+---+---| 面白くない やる気がでる |---+-○---+---+---| やる気がない 効率的 |---+----○---+---+---| 非効率

効果的 |---+-○---+---+---| 非効果的

 スクラムを続けたいか？

続けたい |---○---+---+---| 続けたくない

Ingenious Dynamics

P.43

２ モ

ー シ

ン

４．２ モチベーションの評価

 仕事が楽しくなる５つのキーワード

「ありがとう」といってもらえる仕事

「なぜ、何のために」がわかっている仕事

「ゴール」が見える仕事

「昨日より今日が」前進している仕事

「おめでとう」が言い合える仕事

スプリントレビュー

ユーザ（ＰＯ）から直接フィードバック

ＳＭＳＭ

４． Agile 試行の評価　　～Ａｇｉｌｅ導入の目的に対して～

システム開発の費用と期間を固定しシステムの価値を最大化

２モ

ーシ

４．１　システムの価値を最大化

ユーザの要求を実現する時間ユーザの要求を

外部設計基本設計ＰＧ開発ＩＴ

１４Ｈ／機能＋　５Ｈ／機能

機能に対する価値を高めている

２モ

ーシ

４．１　システムの価値を最大化

１　　２　　３　　４　　５　　６　　７　　８　　９　　１０

２モ

ーシ

４．２　モチベーションの評価　　メンバー７名にアンケート

２モ

ーシ

「従来のウォーターフォール型と比べてどうですか？」

良い　　　　　　|---○---+---+---|　悪い

面白い　　　　　|---○---+---+---|　面白くないやる気がでる　　|---+-○---+---+---|　やる気がない効率的　　　　　|---+----○---+---+---|　非効率

効果的　　　　　|---+-○---+---+---|　非効果的

続けたい　　　　|---○---+---+---|　続けたくない

２モ

ーシ

４．２　モチベーションの評価　　

スプリントゴールスプリント期間

バーンダウンチャートの着地をみんなで喜ぶ

スクラムのルール ^{アンケート結果}

　・仕事が楽しくなるポイントを押さえているスクラムのルール　・アンケート結果も対応

４．３　開発者の能力向上

２モ

ーシ

開発者の能力 ^ベテラン ^中堅 ^若手ＰＪ管理能力

プログラミング能力－

改善の分類

設計開発コミュニケーション

４．４　改善活動の定着化　～レトロスペクティブの Try ～

　・スプリントが終わる度にレトロスペクティブを実施

　・一人一人が必ず発言するので自ずと改善意識が高まる　・次の２週間ですぐ実践できる

２モ

ーシ

４．５　 QCD の評価

 時間あたりの欠陥作り込み（ＰＧ開発）　　→組織標準より約２０％多い

 Ｃ：コスト　生産性

 規模（ＦＰ値）あたりの開発工数　→組織標準とほぼ同じ

　組織標準はアプリケーションＦＰあたりの標準工数なので

　厳密な比較ではない　（機能拡張ＦＰでの標準工数は規定無い）

　動くソフトを継続的にリリースできた

　厳密な比較はできていないが、さほど悪くならない　欠陥作り込みは多いが流出はむしろ少ない

２モ

ーシ

４．６　 Agile 試行の評価　まとめ