1. アジャイルな開発プロセスを導入するために 考えなければならないこと 2010/3/19 Ryutaro YOSHIBA
2. はじめに ✤ 「アジャイル」という言葉 ✤ 開発現場の上位層まで認知されてきましたが ✤ 一方でバズワード的に扱われて興味を持たれない ✤ 表面的な理解に基づいて現場に導入してうまくいかないと判断される ✤ という状況が多いのではないでしょうか？ ✤ このセッションではアジャイルな開発プロセスにおいて考えなければならないこと について、特に「組織」、「人」に焦点を絞ってお話いたします
3. アジェンダ ✤ アジャイルの基本中の基本 ✤ アジャイルな開発プロセスの導入の前に ✤ 経営者・上司へのアプローチ ✤ チームビルディング・人材育成 ✤ 顧客へのアプローチ ✤ アジャイルな開発プロジェクトのはじめ方 ✤ 最後に
5. アジャイルの基本理念 ✤ アジャイルマニフェスト ✤ ✤ 2001年に、ケント・ベック、マーティン・ファウラー、ケン・シュウェイバーら、17 人によって採択されたAgileソフトウェア開発の原則 基本理念 ✤ 人同士の相互作用 ＞ プロセスやツール ✤ 動くソフトウェア ＞ 包括的なドキュメント ✤ 顧客との協調 ＞ 契約交渉 ✤ 変化への対応 ＞ 計画の遵守
6. アジャイルの12の基本原則 ✤ 我々は価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の満足度を高めることをもっとも優先します ✤ 要件の変更は例え開発の後期であっても受け入れます。アジャイル･プロセスは変化を味方につけることによってお客様の競争力を引き上げます ✤ 動くソフトウェアを2~3週間から2~3ヶ月というできるだけ短い時間間隔で繰り返し引き渡します ✤ ビジネスをする人と開発者はプロジェクトを通して日々一緒に働かなければなりません ✤ 意欲に満ちた人々を集めてプロジェクトを構成します。ですから彼らが必要とする環境と支援を与え仕事が無事終わるまで彼らを信頼してください ✤ 開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は面と向かって話をすることです ✤ 動いているソフトウェアこそが進捗の最も重要な尺度です ✤ アジャイル･プロセスは持続可能な開発を促進します。スポンサ、開発者、ユーザは一定のペースで永続的に保守できるようにしなければなりません ✤ 卓越した技術と優れた設計に対する不断の注意こそが機敏さを高めます ✤ 単純さ - 作業せずに済む量を最大限に引き上げる技量 - が本質です ✤ 最良のアーキテクチャ、要件、設計は自己組織的なチームから生み出されます ✤ どうしたらチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します
7. アジャイルな開発プロセスの特徴 ✤ ビジネス価値を基準 ✤ ✤ 小さい単位でリリース ✤ ✤ 次の機能の選択や開発を行う前に、前の機能の選択、開発、テスト、デプロイを全て完了させる 依存性の排除 ✤ ✤ 機能が誤っていても、早期検出が可能になる 全て完了させて次へ ✤ ✤ ビジネス上の価値を基準に優先順位付けされた機能順に開発 機能レベルでのリスクが、他の機能に関連しないよう独立させる 無駄を省く ✤ 無駄を省くという基本思想のもと、今必要ではないものには手を触れない。必要になってからアクションを 起こす
8. アジャイルはリスクマネジメント ✤ リスク ✤ 必要なものが本当に必要な時に出来上がるか ✤ 無駄なコストが発生する可能性 ✤ 不確実なものを大きく予測しそれに従って行動する 優先度の高いものから着手 するため、早い段階でリスク が発覚 結合試験あたりからビックバンに よるリスク、受け入れ試験での仕 様相違リスク等が顕在化 アジャイルは顧客、開発側双方にとっての リスクマネジメント手法
9. アジャイルは単なる技術論ではない ✤ 現場の開発者の方は、 ✤ アジャイル＝技術的な課題解決方法 ✤ アジャイル＝個別のプラクティス ✤ アジャイル＝現場の話 ✤ と思われているかもしれませんが、 ✤ アジャイルは単なる技術論ではありません。色々なことを意識する必要があります
11. 導入の目的を考える ✤ ✤ アジャイルな開発プロセスの導入の目的 ✤ ウォーターフォールでやっていてうまくいかない？ ✤ 顧客の満足度を向上したい？ ✤ もっと開発現場が楽したい？ ✤ もっと利益を上げたい？ ただ現状がうまくいっていないのでアジャイルへというアプローチはうまくいかない
12. 現状分析のすすめ ✤ アジャイルな開発プロセスの導入の前に「何が」「どのように」うまく行っていないの か？を棚卸する必要がある ✤ 棚卸できていない＝改善のプロセスが働いていない ✤ 問題が把握できなければ、改善のしようもなく、目標の設定もできない ✤ 極論すれば、現状の問題はアジャイルな開発プロセスの導入とは関係のないところ で解決できるかもしれない ✤ 問題をオープンにするところからプロセス改善ははじまる ✤ 現状に目をつぶらない
13. 導入の目的検討の視点 ✤ ✤ どのような視点で考えるべきか？ ✤ 開発現場の視点 ✤ 経営者、管理者の視点 ✤ 顧客の視点 すべてのステークホルダー視点で考える！
14. 目的達成の判断指標を考える ✤ なにをもってアジャイルな開発プロセスの導入に成功した、と言えるのかを事前に 考えておく必要がある ✤ 顧客満足度の向上？ ✤ プロジェクトのQCD？ ✤ エンジニアのQOL？
16. 立場によるアジャイルの意味の違い ✤ ✤ 経営者、管理者 ✤ ビジネス・経営戦略としてのアジャイル ✤ トップダウンでのアプローチ 現場開発者 ✤ 現場改善としてのアジャイル ✤ ボトムアップでのアプローチ
17. 組織における問題 ✤ ✤ ピラミッド組織における問題 ✤ 特に中間層は変化を恐れる ✤ 通常職能別組織に分かれており、社内での責任論になりやすい ✤ 顧客の価値よりも社内の政治を重視してしまう文化 ✤ 意思決定プロセスが長くビジネス機会を損失しやすい ✤ 意思決定プロセスが形式的な準拠に終始しやすい ✤ 責任範囲を超えた範囲については思考停止する これらが組織のアジリティ向上の妨げとなっている。これらの問題の解決は経営者、管理 者のミッション
18. 組織が変化しないことのリスク ✤ ✤ ✤ あらゆる企業には競争相手が存在する ✤ 競争相手は進化しつづける ✤ 自組織が変化しない場合、相対的な競争力は低下していく 顧客のニーズや市場環境が変化する ✤ いままで提供していたものに価値がなくなる（かもしれない） ✤ 顧客はもっとQCDを求めるようになる ✤ 組織の存続自体が目的化されてしまう 変化を先送りすることで、ゆっくりと組織が衰退に向かっていく
19. どうやって行動するか？ ✤ ✤ ボトムアップアプローチ ✤ なぜ変化が必要なのかを、説明・納得してもらうための材料を用意する ✤ ビジョンやゴールを準備する ✤ 自分の所属しているチームを巻き込む ✤ 巻き込む人のレイヤーを上げる ✤ 高い視点を保ち、全体のことを考えている上司・経営者 ✤ 自己の保身、立場を気にする人は巻き込まない ✤ ビジョンの実現のためには一時的に痛みを覚えるかもしれないという覚悟を持つ トップダウンアプローチ ✤ 会社全体の推進支援が得られやすい、改革への抵抗勢力が排除しやすい、という点でトップダウンアプ ローチは有効
20. どうやって行動するか？ ✤ ボトムアップアプローチ ✤ なぜ変化が必要なのかを、説明・納得してもらうための材料を用意する ✤ ビジョンやゴールを準備する ✤ 自分の所属しているチームを巻き込む ✤ ✤ ✤ 可能な限り、ボトムアップ・トップダウンの 巻き込む人のレイヤーを上げる 双方からアプローチする！ 高い視点を保ち、全体のことを考えている上司・経営者 ✤ 自己の保身、立場を気にする人は巻き込まない ✤ ビジョンの実現のためには一時的に痛みを覚えるかもしれないという覚悟を持つ トップダウンアプローチ ✤ 会社全体の推進支援が得られやすい、改革への抵抗勢力が排除しやすい、という点でトップダウンアプ ローチは有効
21. 説明・納得してもらうための材料 ✤ 導入には、説明と納得の材料が不可欠 ✤ 外部の調査事例や内部プロセスの分析結果を用意する ✤ 人が納得するためには、客観性と論理性が必要 ✤ 例：①海外の導入実績調査事例 ✤ 例：②オフショア開発との比較 ✤ 例：③懸念するであろう点についての答えの用意 ✤ 例：④パイロットプロジェクトの実行結果を具体的な指標データとともに経営上 位層に報告し関心を引く
22. ①海外での調査事例(1) ✤ The State of Agile Development ©2008 VersionOne ✤ 80カ国3061人の回答者 ✤ 自社でアジャイルな開発を行っているプロジェクト の割合 ✤ プロジェクトの半分以上をアジャイルな開発で実 施している企業が50%程度
23. ①海外での調査事例(2) ✤ STATE OF AGILE SURVEY ©2009 VersionOne ✤ アジャイルな開発プロセス導入で得られた メリット ✤ 優先順位の変更に対応できるようになった ＝90% ✤ プロジェクトが可視化された＝83%
24. ②アジャイルとオフショアの比較 ✤ オフショアとAgileを比較した調査 ✤ 調査結果は20年間に行われた8000のプロジェクトを対象とし、似たようなLOC規模のものを比 較したもの ✤ プロジェクト全体の平均コストは350万$で、オフショアの場合320万ドル、Agileの場合は220万 $が平均となった ✤ 時間という面で見ると、オンショアで12.6か月、オフショアで9.6か月、Agileで7.8か月が平均 ✤ 品質面でみると、オンショアは平均2702の不具合、オフショアは驚くことに7565の不具合。そし てAgileの場合はたった1372個の不具合 ✤ オフショアの方がプロジェクトコストが少なくなったとしても、不具合の補修にお金がかかること になる ✤ オフショアは実はコストカットには繋がっておらず、Agileの方が安くできる可能性が高い
25. ②アジャイルとオフショアの比較 ✤ オフショアとAgileを比較した調査 ✤ 調査結果は20年間に行われた8000のプロジェクトを対象とし、似たようなLOC規模のものを比 較したもの ✤ プロジェクト全体の平均コストは350万$で、オフショアの場合320万ドル、Agileの場合は220万 $が平均となった ✤ 品質面でみると、オンショアは平均2702の不具合、オフショアは驚くことに7565の不具合。そし てAgileの場合はたった1372個の不具合 ✤ オフショアの方がプロジェクトコストが少なくなったとしても、不具合の補修にお金がかかること になる ✤ オフショアは実はコストカットには繋がっておらず、Agileの方が安くできる可能性が高い オフショアという変化を選択できたのなら、 ✤ 時間という面で見ると、オンショアで12.6か月、オフショアで9.6か月、Agileで7.8か月が平均 アジャイルという変化も選択できるかも！
26. ③導入への懸念 ✤ ✤ 導入に際しては以下の点に懸念を持つ人が多い ✤ 事前の計画がない ✤ ドキュメントがない ✤ マネジメントされない ✤ 予測できない ✤ 管理職が変化に反対する ✤ スケーリングできない アジャイルなプロセスの価値感や方法論について正しく 説明することで懸念を解消する必要がある
27. ③導入への懸念 ✤ ✤ 導入に際しては以下の点に懸念を持つ人が多い ✤ 事前の計画がない ✤ ドキュメントがない ✤ マネジメントされない ✤ 無計画、ドキュメントなし、マネジメントなし、 スケーリングできない、というのはよくある誤解！ 予測できない ✤ 管理職が変化に反対する ✤ スケーリングできない アジャイルなプロセスの価値感や方法論について正しく 説明することで懸念を解消する必要がある
28. ④パイロットプロジェクトの評価(例) ✤ アジャイルの実績/ウォーターフォールでの想定内容との対比 成果物定義の相違故に 単純比較はできないが、 比較評価としては十分参 考になる
30. 顧客のおかれた状況 ✤ ビジネスの環境の変化 ✤ 迅速な意思決定と具現化が求められる ✤ 変化しないことは市場から見捨てられるリスクがある ✤ 顧客自身が変化していくことが強く求められる ✤ IT投資の目的の変化 ✤ ✤ ✤ 業務効率化から戦略実現へ いままではコスト削減、業務効率化ができていれば良かったが、システムが他 社との競争力の源泉になってきている よいシステムを早期に市場に投入することが、強く求められる
31. 顧客に伝えるべきこと ✤ ✤ アジャイルな開発プロセスで実施することの宣言 ✤ より早期に価値を市場に投入することの重要性 ✤ 計画適応主義から変化適応主義へ ✤ プロジェクトの計画と契約スキームの変更 ✤ 納品物とそれらの価値についての合意 ✤ 顧客がよりプロジェクトに積極的に関わる必要性 もちろん理解されない場合もある ✤ 縦割り組織、予算主義、丸投げ主義な顧客 ✤ 耳障りの良い言葉だけを伝えない ✤ 結果ではなく価値も必ず伝える
32. 顧客に伝えるべきこと ✤ アジャイルな開発プロセスで実施することの宣言 ✤ より早期に価値を市場に投入することの重要性 ✤ 計画適応主義から変化適応主義へ 顧客と同じゴールを目指すために、 ✤ 納品物とそれらの価値についての合意 プロジェクト開始前に必ず伝える！ ✤ ✤ プロジェクトの計画と契約スキームの変更 顧客がよりプロジェクトに積極的に関わる必要性 ✤ もちろん理解されない場合もある ✤ 縦割り組織、予算主義、丸投げ主義な顧客 ✤ 耳障りの良い言葉だけを伝えない ✤ 結果ではなく価値も必ず伝える
33. 契約スキーム ✤ ウォーターフォールの契約スキームでアジャイルなプロジェクトを実施することには 大きなリスクがある ✤ アジャイルとウォーターフォールにおける要件、リソース、時間の考え方を開発側も 意識する必要がある ✤ 「契約交渉より顧客との協調を」とはいえ、契約内容ゆえに失敗するプロジェクトも 多い！
34. 一括請負をアジャイルな開発に適用する問題 ✤ 一括請負契約は危険な幻想（マーティン・ファウラー） ✤ 顧客企業が一括請負契約を望んだ場合、受託側は、利益の最大化という動機のために仕様 変更は受け入れない。または仕様変更のたびに追加費用を請求する ✤ または開発側は仕様変更分の費用を先に見積もりに追加している ✤ 受託側は当初の計画から変更「させない」ことに主眼を置くので、顧客のビジネスでの状況 が変わっても、システムを変化させる動機が弱い ✤ 顧客から受託側に対して強い政治的な力がかかりやすく、それによって発生するリスクが最 後まで残る ✤ 端的にいえば、お互いの利益が相反しやすい契約スタイルである、といえる ✤ 一括請負するのであれば、顧客との協業的関係が既に成り立っていることが前提
35. 一括請負をアジャイルな開発に適用する問題 ✤ 一括請負契約は危険な幻想（マーティン・ファウラー） ✤ 顧客企業が一括請負契約を望んだ場合、受託側は、利益の最大化という動機のために仕様 変更は受け入れない。または仕様変更のたびに追加費用を請求する ✤ または開発側は仕様変更分の費用を先に見積もりに追加している ✤ ただし、現在の日本的企業のほとんどはシステム開発を委託する際に、 受託側は当初の計画から変更「させない」ことに主眼を置くので、顧客のビジネスでの状況 内容の決定度合いに関わらず、一括での見積りを求めてくるので、 が変わっても、システムを変化させる動機が弱い どう対応するかをよく検討するべき ✤ 顧客から受託側に対して強い政治的な力がかかりやすく、それによって発生するリスクが最 後まで残る ✤ 端的にいえば、お互いの利益が相反しやすい契約スタイルである、といえる ✤ 一括請負するのであれば、顧客との協業的関係が既に成り立っていることが前提
36. 主な契約パターン ✤ アジャイルな開発プロジェクトの契約パターンはさまざま ✤ スプリント契約 ✤ 固定価格・固定スコープ ✤ 実費精算契約 ✤ 実費精算契約（固定スコープ、上限コスト付き） ✤ 実費精算契約（変動スコープ、上限コスト付き） ✤ フェーズ開発 ✤ ボーナス／ペナルティ条項 ✤ 固定利益 ✤ 早期中止、変更無料 ✤ ジョイントベンチャー
38. オペレーションプロセスの変化 ✤ 従来のコマンド・コントロール型から、自律化・自己組織化への変化が求められる ✤ コマンド・コントロール ✤ ✤ 上司の命令に従っていれば良い、という価値観 ✤ メンバーはやらされ感を持つ ✤ 上司の指示を遵守したかどうかが評価の観点に ✤ 人が育たない。通常は上司の劣化コピーに… ✤ 現状に不満をもつ優秀な人から順に退職… 自己組織化 ✤ 上司は責任とチームで解消できない問題の解決を担う ✤ 上司は後方支援、ファシリテーター役になる ✤ チームを信じる
39. チーム運営 ✤ チームのビジョンの共有 ✤ ✤ ✤ チームがチーム足りえる目的を共有することでチームメンバーのモチベーション を維持する 自己組織化した組織における改善のループ ✤ 常に改善できることがないか？という意識を持つ ✤ 気づきの場としてのレトロスペクティブ（ふりかえり）の活用 ✤ ふりかえりで出た問題をそのままにしない、アクションが実行されているかを追跡 する そのチームの一員であることを誇りに思えるように
40. 現場リーダーや管理職の役割の変化 ✤ 従来の役割・振る舞い ✤ 求められる役割・振る舞い ✤ ピラミッド組織 ✤ ネットワーク型組織 ✤ コマンド・コントロール ✤ 自律・自発の支援 ✤ 権威的 ✤ 民主的 ✤ 流動性がない ✤ 流動性のある ✤ 答えをいう ✤ 導く ✤ 叱る ✤ 褒める ✤ 否定 ✤ 肯定 ✤ マイクロマネジメント ✤ チームの自主性に任せる
41. 現場リーダーや管理職の役割の変化 ✤ 自己組織化されたチームで仕事をできるようにするためには、外部からのマイクロ マネジメントを止める必要がある ✤ 通常チームは指示があればそれに従ってしまうものであるため、外部からの指示が なくならない限り、チームは自己組織化したチームにはならない
42. サポート行動 リーダーシップのモデル(SL理論) ✤ SL理論 => リーダーシップの形態はメンバー の成熟度によって変わるという理論 ✤ S1からS4に向かってメンバーが成熟していく S1：指示型。意思決定はリーダーが行う S2：説得型。考えを説明し疑問に答える S3：参加型。意見を聞き意思決定を支援 S4：移譲型。任せる situational.comから図を引用 指示的行動
43. アジャイルなチームのリーダー ✤ ✤ リーダーが持つべきもの ✤ 強いビジョンを持っていること ✤ ビジョンの中に揺らぎない信念を持ち、チームを前に進め、困難に打ち勝つために約束・決定すること ✤ リーダーはビジョンの素晴らしさを共有するために、十分なエネルギーと熱意を注ぐこと ✤ リーダーは人の話を聞いて対応できること ✤ リーダーは問題解決能力を持っていること ✤ リーダーは多くの邪魔が入ってもゴールの達成に集中する ✤ リーダーは決定を下すことができる ✤ リーダーは周りに教えることを厭わない、よいコーチである ✤ 周りを信頼し、正直であること 別にアジャイルなチームに限らない
44. 人材育成について ✤ ✤ チームが人を育てる ✤ OJTによるマンツーマンな人材育成ではなく、チーム全員が協力しあってお互いの能力を向上 させる ✤ チーム内での勉強会などの開催も有効。僅かな時間的投資が後に何倍にもなる ✤ 自分がコミットしたことを守ろうとする文化。過小コミットしない文化 ✤ 文化や環境によって人の成長速度は変わる 評価プロセスの透明性 ✤ 誰もが納得する評価基準 ✤ アジャイルな開発プロセスにおける透明性を懲罰に利用しない ✤ 評価の不透明さは、人が育たなくなる第一歩
46. 対象プロジェクトの選定 ✤ 対象プロジェクト ✤ 小規模プロジェクトから始めて実績を作る ✤ いきなり大規模プロジェクトや分散プロジェクトで実施するのはリスクが高い ✤ アジャイルな開発プロジェクトは顧客の協力が必須であるため、顧客の協力が 得られやすいプロジェクトを選ぶ ✤ ミッションクリティカルなプロジェクトは避ける
47. 体制 ✤ 体制（チーム）構築は非常に重要 ✤ アジャイルな開発プロジェクトの成否は人にかかっている ✤ チームにはアジャイルな開発プロジェクトの経験者を入れる。難しいようであれ ば外部のコーチやトレーナーを利用する（外部のコーチの導入はトップダウンアプ ローチでのアジャイル導入の場合はやりやすい） ✤ 全員同席できる場所を確保 ✤ チームのメンバーは他の案件を兼任させない ✤ ただしDBのパフォーマンスチューニングエンジニアなど特殊職能の人は除く ✤ メンバーの技術力はもちろん大事だが、コミュニケーション力はもっと大事
48. 利用するプロセス ✤ どのようなプロセスを利用するかはプロジェクト開始前に決めておく ✤ はじめてのアジャイルな開発の場合は、Scrum＋XPのハイブリッドがおすすめ ✤ アジャイルな開発の経験がない場合は、まずは教科書的にプラクティスに従う ✤ ある程度慣れるに従って、チーム自身で改善、カスタマイズしていく ✤ モニタリングと自己評価 ✤ 新しいプロセスを導入した当初は、以前よりも生産性が下がるかもしれない。定着期 ゆえなので、そこで諦めない
49. ツールに対する考え方 ✤ アジャイルな開発プロジェクトで利用するツール群 ✤ SCM、自動テスト、バックログ管理など ✤ プロセスとツールの同時学習は負荷が高い ✤ 本当に必要なツールを用途にあわせて選択 ✤ ツールをベースにしてプロセスを規定し過ぎない ✤ 全てのチームで同じツールが適切であるとは限らない ✤ 改善のループの中で徐々にツールの適用範囲を増やす ✤ 大規模アジャイルや分散アジャイルにおいてはアジャイルプロジェクトマネジメントの専用ツール や、各種コミュニケーションツールによるサポートは欠かせない ✤ ツールの導入“自体”を目的にしないこと！
50. (参考)ツールの利用割合 ✤ アジャイルなプロジェクトでもExcel大活躍！
51. 横展開に向けて ✤ 横展開する前に、まずパイロットチームのプラクティスを醸成する。表面的な結果の みから早急に横展開しない ✤ 横展開の際もパイロットチームと同じように体制に気を配る ✤ 一度にパイロットチームを解体して、多チームに分散してもうまくいかない ✤ 横展開したチームがパイロットチームと同じ文化、プラクティスになるとは限らない。 成功体験を単純にあてはめようとしないこと ✤ 横展開したチーム同士がコミュニケーションできる場を用意する
53. これからどう行動するか？ ✤ あなたにとってのアジャイルとはなんですか？ ✤ 今日ここに来た目的を是非もう一度考えてください ✤ 現状分析してみよう ✤ 社内の仲間を増やそう ✤ 説得ではなく納得 ✤ 一緒にセミナーにいったり ✤ 一緒に悩んだり ✤ 外部のコーチやコンサルをうまく使おう ✤ そして何よりも、あきらめないで続ける
54. 私にとってのアジャイルとは？ ✤ 私にとってのアジャイルとは、目的実現の道具 ✤ 顧客の価値を実現したい ✤ 現場の開発者を幸せにしたい ✤ 自社にきちんと利益をあげたい
