事例に見る初めてのアジャイルの要素適用 - IPA事例に見る初めてのアジャイルの要素適用～プロセス改善活動でのアジャイル導入～

事例に見る

初めてのアジャイルの要素適用

～プロセス改善活動でのアジャイル導入～

2012年1月16日

(株)豆蔵山田悦朗

IPA発表用

Copyright © 2011 MAMEZOU Co., LTD. All rights reserved

アジェンダ

• 本日は、以下の３つをお話します

– アジャイル導入にあたって知っておくべきこと

– プロセス改善におけるアジャイル要素の適用

– アジャイルを導入するにあたってのポイント

1


自己紹介

• 略歴 – 専門分野プロセス改善、標準化支援、ＰＭ教育 – ＳＩ企業にてシステム開発に従事。製造、流通、金融など複数のプロジェクトにおける開発、リーダー、ＰＭを経験。豆蔵では、CMMIによるプロセス改善や、ＰＭ講座の講師などを手がける

– ＰＭＰ、認定プロダクトオーナー、認定スクラムマスター

2

Copyright © 2011 MAMEZOU Co., LTD. All rights reserved 4

アジャイルの基本


開発プロセスはウォーターフォールが主流

5

データ引用：ソフトウェア開発データ白書（IPA/SEC）


ウォーターフォールの前提

• 要求はすでに存在し、それらを十分に伝達できる – 無形の知的資産が持つ特性

• 計画通りの要員で、計画通りの生産性が得られる

– 計画通りの要員であっても、生産性にはブレがでる事実

• 変更は小さく、十分に管理できる – 開発が長いほど変更頻度は大きくなる事実

• システムの統合はうまくいく

– アーキテクチャを主軸に立てられた計画によって書かれた大量のコードは、多くの場合、統合に失敗する事実

6

ウォーターフォールは、何事も起こらない｢平穏無事なシステム開発｣を前提にしている


襲いかかる現実

開発の実情

業務が複雑かつ曖昧

開発初期段階ですべての要求を見通せない

開発期間中に要求が変化しがち

異種混合のアーキテクチャ

技術刷新が激しい

短期の開発

新規開発の経験者が尐なくなった


アジャイル開発プロセス

8

分析設計実装テスト

分析

設計

実装

テスト

一度限りの開発工程

連続的な取り組み

従来

アジャイル


アジャイルの前提

9

全ての計画と要件を整え、作業開始

全ての要件を達成したら、作業終了

定義された予測可能な

いくつかの明確な目標と優先度の高い要件を整え、作業開始

目標を達成したら、作業終了

実測に基づく

ウォーターフォール

アジャイル


価値の逆転

10

要求

リソース日程

計画

駆動

価値

駆動

要求

日程リソース固定

見積もられる

要求は本質的に固定されるものではなく、要求の一部がユーザにとって価値の大部分を提供する信念に基づいている

ウォーターフォールアジャイル


アジャイルの期待効果

11

要求提供者（何をしたいか）

What

要求実現者（どう実現するか）

How

早く作って検証する

HowからのアイデアでWhatを洗練する

Agility


アジャイルとアジャイルプロセス

• アジャイル開発とは、 – アジャイルプロセスを忠実に実践することではなく

– アジャイル精神（ソフトウェア開発に対する心の持ちようや、取り組む態度）を守ること

12


アジャイルマニフェスト

13

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。


アジャイル開発１２の原則

14

• 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます

• 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します

• 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです • 動くソフトウェアこそが進捗の最も重要な尺度です • アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません

• 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます • シンプルさ（ムダなく作れる量を最大限にすること）が本質です • 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます • チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します


スクラムのプロセスフレームワーク

15

プロダクトバックログ

スプリントバックログ

プロダクトオーナー

チーム

スプリントプランニング第一

スプリントプランニング第二

スクラムマスター

プロダクトバックログ調整・見直し

スプリントレビュー振り返り

デイリースクラム

2～4週間

プロダクト

ToDo Doing Done

タスクボード


アジャイル要素の適用事例


プロジェクト概要

17

項目概要

お客様の業務Ｗｅｂサービスの企画、開発、運用豆蔵の役割開発部門のプロセス改善支援（SEPGチーム）関係組織企画部門、業務部門など

開発体制顧客：企画、業務、開発部門開発（要件定義まで）：内製開発（基本設計以降）：内製、SIベンダー混在

プロセスウォーターフォール

プロセス改善の課題を解決するために、アジャイルプロセスの仕組みを利用することによって、案件立ち上げ時の見通しを良くすると同時に、そこに携わる部門の役割分担を整理した事例

概略


お客様の状況

18

見積・承認レビュー開発案件依頼A

要求要求要求

案件依頼B

要求要求要求

リリース企画部門

業務部門

案件依頼C

要求要求要求

開発部門

承認権限者（マネージャーなど）

見積・承認

見積・承認レビュー開発リリース

案件依頼D

要求要求要求

業務部門見積・承認レビュー開発リリース

案件依頼E

要求要求要求


：：：

レビューリリース開発

開発部門・マネージャー・リーダー

案件の担当割り

開発部門（リーダー）


お客様の状況

19

見積・承認開発案件依頼A

要求要求要求

案件依頼B

要求要求要求

企画部門

業務部門

案件依頼C

要求要求要求

開発部門

承認権限者（マネージャーなど）

見積・承認

見積・承認レビュー開発リリース

案件依頼D

要求要求要求

業務部門見積・承認レビュー開発

案件依頼E

要求要求要求


：：：

開発部門・マネージャー・リーダー

案件の担当割り

お客様が問題意識を

強く持っていた領域

開発部門（リーダー）


課題と対応方針

20

リソース競合による開発着手遅延

• 案件の対象が、特定サービスへ偏る場合が多く、要員のリソース不足に陥りがち

案件が各部門の都合で発生

• 企画、業務、運用など各部門の都合で様々な案件依頼が発生するため、ハンドリングの負荷が高くなりがち

要求の粒度がバラバラ

• 機能修正などの保守開発からサービス追加などの新規開発まで、様々な要求を「案件」という単位で扱うため、管理が煩雑になる

一部の要求が固まらない

• 要求の確定までに時間が掛ることが多いために、開発コストなどがかさむ

•見積り、承認作業など案件立上げの負荷が増大した •２度手間の開発や横断的な対応漏れが発生した

•リソース不足により、新案件を延期した •リソース確保のために開発中の別案件を止めて、リソースを確保した

•部門や個人で記述形式が異なり、要求の理解に時間が掛った •要求の大きさが異なるため、影響範囲の把握に時間が掛った

•要求確定待ちになり、開発作業中断した •開発が間に合わず、当初予定していなかった２段階リリースになった

要求の一元管理リソースを安定確保する枠組み要求の粒度揃え着手要求の

調整・見直し


タイムボクシングスプリントバックログストーリー化（分割）優先順位の調整・見直しプロダクトバックログ

施策

21

リソースを安定確保する枠組み

• 定期的なリリースタイミングを計画し、開発期間とリソースを固定化する

• その枠組みの中で実現可能な要求に取り組む

要求の一元管理

• 要求（要件）をサービス単位にプロダクトバックログで一元管理する

要求の粒度揃え

• 開発期間に応じてプロダクトバックログから優先順位の高い要求を案件化し、スプリントバックログを作成する。

• この際、要求をストーリー化（分割）することで粒度を揃える

着手要件の優先順位付け

• 確定度合いやビジネス価値などを元にプロダクトバックログの優先順位を定期的に見直す

要求の一元管理リソースを安定確保する枠組み要求の粒度揃え着手要求の

調整・見直し

主に「要求の管理および案件化するまでの『交通整理』」にアジャイル要素を適用


ただし…

22

• 開発工程（ウォーターフォール）は変更しない – お客様自身が、そこまでの変化を望んでいない – ＣＩ環境などが整備されていないため ⇒ スクラムフレームワークの枠に拘らず、現行ルールとスムーズな連携

• 決裁承認の社内ルールは変更しない

– 全社的な決済ルールの変更が必要になるため時間がかかりすぎる ⇒ プロダクトオーナーの役割を、承認と実務に分離

• その他 • プロジェクト用のスペースは用意できない

– 複数案件を掛け持ちしているメンバーが多いため、1か所に集めて作業することが難しい

• 壁に何らかの情報を掲示することは出来ない – 別プロジェクトの情報が丸見えになる（かも） – 社内の『美化』ルールに抵触する（かも）

⇒ プロダクトバックログとスプリントバックログは、Redmineで管理


チーム

作業範囲

プロセス全般の推進および支援

概要

新プロセスの役割設定

23

開発チーム PO（実務）チーム

•期間、リソースの計画と調整 •PBの優先順位付け •統合チームの決定を承認 •次期PBの検討 •（レビュー）

•案件化の対象（要求）の提案 •要求の洗練（ストーリー化） •ビジネス価値の明確化 •工数見積り •完了の定義 •レビュー •PBの更新

•開発の実施 •レビュー •振り返り

PO（承認）チーム SEPG

•プロセス実施の支援 •改善点の洗い出し •プロセス再定義




着手要求の調整・見直し

部門横断的なプロセスの改善にスクラムのプロセスフレームワークを利用

兼務


新プロセスの全体像

24

期間、リソース計画

プロダクトバックログ

決裁

追加（随時）ストーリー化

レビューリリース

スプリントバックログ

更新（定期的）見積り書（ XX月- XX月）

開発要求

要求

要求

振り返りプロダクトバックログ調整・見直し





スプリント計画#1 スプリント計画#2

従来通り（変更なし）


新プロセスの効果

• 『価値』を議論するようになる – 「営業が必要と言ったから」「他のサービスもやってるから」などは通用しない

– ビジネス戦略上の優先順位を共有

• 要求を理解しやすくなる – 要求の記述、規模感のブレが尐なくなり、管理（開発）し易い単位になる – 開発効率を考えた優先順位の提案が可能になる

• 見積りの作業負荷が軽減される

– 精緻な見積り金額の承認（説明）工数が不要 – 各ストーリーごとの作業工数に専念

• 各部門の敷居が低くなる

– PO（実務）チームによる人材交流、知識の共有 – 課題、問題点を共有する機会が自然に増加






今後の展望

• 新プロセスの適用拡大（と洗練） – スモールスタートの対象サービスで人材の一部を入れ替え – 対象サービス拡大に伴い、スモールスタート経験者を再配置

• 開発部分のアジャイル化

– ツールの整備（構成管理ツール、テスト自動化、CI環境など） – ストーリー単位で開発 – デイリースクラム – バーンダウンチャート

• ストーリーの相対見積り

– プランニングポーカー – ストーリーポイント


アジャイル要素適用の勘所


プロセス適用にあたって

29

組織のルールと対峙せず、柔軟な姿勢が必要

• 「自分へ還元される納得感」がポイント

合意形成

• 急に全ての権限を委譲するのは現実的ではない場合が多い • 影響範囲と効果のバランスを見極める（ステークホルダー、期間など）

承認、決済

• 一括請負から準委任へ徐々に移行

ベンダー契約

•SEPG内の合意 •承認権限者、各部門長へ入念な事前説明 •各部門を行脚して説明会を実施 •最後に全員を集めて適用開始を宣言（キックオフ）


スモールスタートのススメ

30

意識の高い協力者と一緒にプロセスを開始すれば、スムーズに走り始める

•アジャイルに積極的なメンバー •プロセス改善の施策を積極的に取り入れていたメンバー

実施メンバー選定

• 2度手間の開発、横断的な対応、リソース不足による開発中断など問題意識が高いサービス、チーム

対象サービス選定

•上記の条件に合致するメンバー、サービスに対してSEPGが集中的に支援

適用支援の集中

•取り組み状況を定期的に公開し、周囲の支援を取り付けやすくする

周囲へのアピール


プロダクトオーナーの心構え

31

プロダクトオーナー自身の意識改革と周囲と協力が重要

• ビジネス価値に基づいた要求を出し、優先順位を決める – 問題の本質を理解するために努力する責任がある – スキルに応じて、実務がわかるメンバー（チーム）の支援を仰ぎ、プロダクトオーナーが孤立しないように心掛ける

– 協力を仰ぎながら、プロダクトオーナー自身のスキルアップを図る

「我々は“医者”であって、“ウェイター”ではない。」～認定スクラムトレーナー Jeff Patton 氏～


まとめ

• アジャイルは、要求をコントロールしやすく、見通し良くするプロセス改善にも活用出来る。

• アジャイル適用には、クリアしなければならない課題があります（組織・人、慣習、契約・・・）

• 組織が一体となってアジャイルに取り組めば、成功確率は高まり、得られるメリットは大きいでしょう

32


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

ご質問、ご意見につきましては [email protected] へ

mailto:[email protected]



Documents

事例に見る 初めてのアジャイルの要素適用 - IPA事例に見る 初めてのアジャイルの要素適用 ～プロセス改善活動でのアジャイル導入～

事例に見る初めてのアジャイルの要素適用 - IPA事例に見る初めてのアジャイルの要素適用～プロセス改善活動でのアジャイル導入～