IPA 発表用事例に見る初めてのアジャイル開発導入 ~ 見えてきたメリットと課題 ~ 2012 年 12 月 9 日 ( 株 ) 豆蔵堀江弘志アジェンダ本日は以下の 3 つをお話しますアジャイル開発の基本的なことを ( 簡単に ) アジャイル開発の事例アジャイルを導入するにあたってのポイ

Size: px

Start display at page:

Download "IPA 発表用事例に見る初めてのアジャイル開発導入 ~ 見えてきたメリットと課題 ~ 2012 年 12 月 9 日 ( 株 ) 豆蔵堀江弘志アジェンダ本日は以下の 3 つをお話しますアジャイル開発の基本的なことを ( 簡単に ) アジャイル開発の事例アジャイルを導入するにあたってのポイ"

ほだかしのしま
4 years ago
Views:

1 IPA 発表用事例に見る初めてのアジャイル開発導入 ~ 見えてきたメリットと課題 ~ 2012 年 12 月 9 日 ( 株 ) 豆蔵堀江弘志アジェンダ本日は以下の 3 つをお話しますアジャイル開発の基本的なことを ( 簡単に ) アジャイル開発の事例アジャイルを導入するにあたってのポイント 1 1

2 自己紹介略歴専門分野プロジェクト管理プロセス改善ユーザ系 SI 企業でシステム開発やプロジェクト管理に携わった後 2005 年より株式会社豆蔵に在籍大規模プロジェクトの PM コンサルティング PM 人材育成 CMMI によるプロセス改善アジャイルコーチなどを手がける PMP 認定スクラムマスター主な執筆記事などプロジェクトマネジャーに贈るプロセス改善事例集 (TechTarget) BABOK2.0 を読んでみよう情報マネジメント ) BABOK の基本と業務 ( 翔泳社 ) 2 余白ページ 3 2

3 アジャイルの基本 4 開発の実情業務が複雑かつ曖昧開発初期段階ですべての要求を見通せない開発期間中に要求が変化しがち異種混合アーキテクチャ技術刷新が激しい短期開発経験者が尐ない ( 腕の立つSEが尐なくなった?) 5 3

4 開発プロセスはウォーターフォールデータ引用 : ソフトウェア開発データ白書 (IPA/SEC) 6 ウォーターフォールの前提要求はすでに存在しそれらを十分理解 ( 伝達 ) できるだろう無形の知的資産が持つ特性変更は小さく十分に管理できるだろう開発が長いほど変更頻度は大きくなる事実システムの統合はうまくいくだろうアーキテクチャを主軸に立てられた計画によって書かれた大量のコードは多くの場合統合に失敗する事実ウォーターフォールは何事も起こらない平穏無事なシステム開発を前提にしている 7 4

5 乱立する開発プロセスプロダクト重視 XP 軽量 UP FDD DSDM AM 人の関わり方 ( パッシブ ) RUP PF 人の関わり方 ( アクティブ ) WF LSD Scrum ASD APM 8 マネジメント重視資料引用 : アジャイルプロセス協議会アジャイルの前提ウォーターフォール全ての計画と要件を整え作業開始定義された予測可能な全ての要件を達成したら作業終了アジャイルいくつかの明確な目標と優先度の高い要件を整え作業開始実測に基づく目標を達成したら作業終了 9 5

6 価値の逆転要求固定リソース日程価値駆動計画駆動見積もられるリソース日程要求要求は本質的に固定されるものではなく要求の一部がユーザにとって価値の大部分を提供する信念に基づいている 10 アジャイルの前提早く作って検証する要求提供者 ( 何をしたいか ) What Agility 要求実現者 ( どう実現するか ) How How からのアイデアで What を洗練する 11 6

7 アジャイル開発プロセスアジャイル従来分析設計実装テスト一度限りの開発工程分析設計実装テスト 12 連続的な取り組みアジャイルとアジャイルプロセスアジャイル開発とはアジャイルプロセスを忠実に実践することではなくアジャイル精神 ( ソフトウェア開発に対する心の持ちようや取り組む態度 ) を守ること 13 7

8 アジャイルマニフェスト私たちはソフトウェア開発の実践あるいは実践を手助けをする活動を通じてよりよい開発方法を見つけだそうとしているこの活動を通して私たちは以下の価値に至ったプロセスやツールよりも個人と対話を包括的なドキュメントよりも動くソフトウェアを契約交渉よりも顧客との協調を計画に従うことよりも変化への対応を価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおく 14 アジャイル開発 12 の原則顧客満足を最優先し価値のあるソフトウェアを早く継続的に提供します要求の変更はたとえ開発の後期であっても歓迎します変化を味方につけることによってお客様の競争力を引き上げます動くソフトウェアを 2-3 週間から 2-3 ヶ月というできるだけ短い時間間隔でリリースしますビジネス側の人と開発者はプロジェクトを通して日々一緒に働かなければなりません意欲に満ちた人々を集めてプロジェクトを構成します環境と支援を与え仕事が無事終わるまで彼らを信頼します情報を伝えるもっとも効率的で効果的な方法はフェイストゥフェイスで話をすることです動くソフトウェアこそが進捗の最も重要な尺度ですアジャイルプロセスは持続可能な開発を促進します一定のペースを継続的に維持できるようにしなければなりません技術的卓越性と優れた設計に対する不断の注意が機敏さを高めますシンプルさ ( ムダなく作れる量を最大限にすること ) が本質です最良のアーキテクチャ要求設計は自己組織的なチームから生み出されますチームがもっと効率を高めることができるかを定期的に振り返りそれに基づいて自分たちのやり方を最適に調整します 15 8

9 スクラムのプロセスフレームワーク ToDo Doing Done スクラムマスターデイリースクラムタスクボードスプリントスプリントプランニング第一プランニング第二チーム 2~4 週間スプリントレビュー振り返りプロダクトプロダクトオーナープロダクトバックログプロダクトバックログ調整見直しスプリントバックログ 16 アジャイル導入事例 17 9

10 プロジェクト概要項目ドメイン規模期間技術関係組織開発体制概要営業支援システム 3 名 4ヶ月 WebベースのJavaアプリケーション営業部門顧客 : 情報システム担当開発 :SI ベンダープロセススクラム 18 アジャイル導入の背景技術のことはわからない必要なこと出来ること業務のことはわからないやりたいこと要件顧客出来ないこと開発不要なこと双方の課題を解決し手戻りを少なくするにはアジャイルしかない ( 顧客が契機 ) 19 10

11 フェーズイメージ開発フェーズ Nヶ月 Nヶ月 Nヶ月ウォーターフォールアジャイル N 次開発 N 次開発 N 次開発 N N+! N+2 N+3 準備期間移行環境整備教育スプリントスプリントスプリントスプリントスプリント UAT 移行切替 20 プロダクトバックログホワイトボードとポストイット優先順位付けカテゴライズ 21 11

12 要求仕様の定義ドキュメント作成レビューではなくホワイトボードを使って顧客と一緒に議論 22 タスクボードとバーンダウンタスクボードは次第に形を変えたバーンダウンはスプリントの奇跡 23 12

UNDONE のない理想のプロジェクト開発者が仕様開発環境に精通しているベロシティを低く見積もったユーザ (PO) 積極関与が課題解決を早めたユーザ同居でチームが過度に頑張った 24 スプリント中止宣言スプリント途中で大幅な仕様変更発生過去のスプリントでも小規模変更は発生していた

13 UNDONE のない理想のプロジェクト開発者が仕様開発環境に精通しているベロシティを低く見積もったユーザ (PO) 積極関与が課題解決を早めたユーザ同居でチームが過度に頑張った 24 スプリント中止宣言スプリント途中で大幅な仕様変更発生過去のスプリントでも小規模変更は発生していたスクラムチーム ( 開発者 ) が努力で解決仕様変更はルール違反か否か? バックログには大まかなことしか書いていない詳細の仕様 ( 例えば画面 ) はスプリント中に変更できる? スプリント中止を宣言し要求仕様のあり方を議論プロダクトバックログの再整理不要な要求が見出されたシンプルさが本質 25 13

14 アジャイルアンケートプロジェクト終盤でアジャイル導入のアンケートを実施した視点評価説明品質顧客満足 ( 使用適合性 ) という意味では大いに高まったコスト保守コストを含めてみれば大差ない生産性ドキュメント作成負荷が低減され早くモノができた開発期間開発中の手戻りで開発期間は長くなった労働負荷顧客ベンダともに高まったコミュニケーション顧客ベンダーベンダー内部ともにコミュニケーションが活発化した責任分担従来手法のベンダー責任集中から顧客を含め責任が分散した契約毎月契約の煩雑さ月途中の契約終了に対する営業からの嫌悪主にウォーターフォールと比較した視点でのアンケート調査 26 アジャイル導入の勘所 27 14

プロジェクトを成功させるためにはプロジェクトマネジメントも当然必要となる 28 人の向き不向き

15 アジャイルには隠れた前提があるアジャイル開発はエンジニアリングやプロジェクト管理の基礎が前提にあるアジャイルが適用できるのはソフトウェア開発だけアジャイルはエンジニアリングやオブジェクト指向を前提としているプロジェクトを成功させるためにはプロジェクトマネジメントも当然必要となる 28 人の向き不向き誰もがアジャイル開発を気に入るわけではない警告いつもオープンで人間関係もすぐ構築でき仕事へ情熱を持っていて自信をもって事にあたれるそのようなエンジニアばかりではない 29 15

16 プロジェクトや組織の向き不向きすべてのプロジェクトや組織にアジャイルを適用できるとは限らない請負型のプロジェクト品質保証の主体が成果物である組織納期制約が強いプロジェクト要求を分割できないプロジェクト ( 超 ) 大規模プロジェクト ( 超 ) 高品質を求められるプロジェクト 30 スプリント 0(Zero) の重要性無計画無防備にスプリントを開始すれば仕様変更の嵐が吹くスプリント 0 スプリント 1 スプリント N リリーススプリント本格的なスプリントを開始する前に計画および要求定義用のスプリントをおく期間は 1 週間程度プロダクトバックログ ( 要求リスト ) を顧客と開発者が協力して作成するシナリオベース ( 利用者視点 ) でその要求が重要か否か検証する獲得した要求リストに基づきスプリント計画を立てる 31 16

17 顧客側の心構えとスキル顧客側のスキルアップと意識改革が必要不可欠ビジネス価値に基づいて要求を出し優先順位を決める大規模になればなるほどこれは簡単なことではない相当のスキルと経験が必要アジャイル開発が始まる前に顧客側は要求を準備するための仕組みが必要システム化企画ビジネスモデリングなどをしっかりやり俯瞰的な要求合意をしておくつまりは初期要求定義の重要性に回帰する 32 顧客との関係に変革が必要お客様は神様ではない顧客とベンダーが上下関係の意識をもっているとベンダー損になる可能性が高い過去の乗りで仕様変更をすべて受け入れる雰囲気ができあがり顧客のみが得をする発注者 = 上位命令アジャイルでは顧客とベンダーは対等な視点でプロジェクトに参加する仕様変更 ( バックログを変更 ) したら優先度の低い相当規模のバックログを引き下げることが重要受注者 = 下位双方の意識改革が必要 33 17

18 アジャイルと契約形態アジャイルに適した契約形態に安定するまでには時間がかかる固定価格固定スコープ ( 一般的な請負契約 ) アジャイルが推奨する変更に対処しづらい実費精算 ( 変動スコープ + 上限コスト付き ) 顧客とベンダーが協調して求められるビジネス価値を利用できる予算内で達成しようとするベンダーリスクは尐ない顧客は予算内でビジネス価値を達成できないリスクがある準委任契約一般に月単位契約になるためスプリントと合致しない 656 条の指揮命令権の問題は残るスプリント契約スプリントごとに契約する契約手続きが煩雑だが実態には即している 34 まとめアジャイルの最大メリットは本当に必要なものだけを作ることがより実現しやすくなることですアジャイル導入にはクリアしなければならない課題があります ( 組織人慣習契約技術 ) 顧客と開発者が一体となってアジャイルに取り組めば成功確率は高まり得られるメリットは大きいでしょう 35 18

19 ご静聴ありがとうございましたご質問ご意見につきましてはへ 36 19

プロダクトオーナー研修についてのご紹介

情報種別 : 重要会社名 : 株式会社 NTT データ情報所有者 : 株式会社 NTT データプロダクトオーナー研修についてのご紹介株式会社 NTT データ 1 プロダクトオーナー研修概要実践シリーズ!! アジャイル開発上級 ~Scrum で学ぶ新規ビジネスサービス企画立案スキル ~ 研修概要本研修はビジネス環境の変化が早い時代においてお客様のニーズにより早く IT サービスシステムを提供できる人材を育成するために