Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Re:エンタープライズへのアジャイル開発の導入事例

shoyoshi
November 19, 2016

 Re:エンタープライズへのアジャイル開発の導入事例

エンタープライズアジャイル勉強会

shoyoshi

November 19, 2016
Tweet

More Decks by shoyoshi

Other Decks in Technology

Transcript

  1. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by いまさらアジャイル巡業 in Tokyo Re:エンタープライズへのアジャイル開発の導入事例 「アジャイル開発で絶対に外せないコアプラクティス」 吉原 庄三郎 2016/11/19 ウルシステムズ株式会社 http://www.ulsystems.co.jp mailto:[email protected] Tel: 03-6220-1420 Fax: 03-6220-1402
  2. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 1 はじめに アジャイル開発を書籍に書いてあるように実践しても上手く行きません。特にエ ンタープライズにアジャイル開発を適用するには制約(しがらみ)が多く、プロ ジェクトの状況にあわせてテーラリングすべきです そこで、アジャイル開発の本来の価値に立ち返り、アジャイル開発として最低 限行うべきであるコアプラクティスを考えました。本日はコアプラクティスを軸に エンタープライズにアジャイル開発を適用する事例を紹介します
  3. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 2 自己紹介 吉原 庄三郎 (ヨシハラ ショウザブロウ) – [email protected] – ウルシステムズ株式会社  アジャイル推進室 室長 – https://www.ulsystems.co.jp/ – 書籍執筆  はじめての設計をやり抜くための本(翔泳社) – ISBN:9784798117065 – 定価:本体2,380円+税 – 最近のWeb連載  ZDNet - まだまだ応用できる--今から始めるアジャイル開発の勘所 – http://japan.zdnet.com/cio/sp_15agile/ – コミュニティ活動  アジャイルプロセス協議会、エンタープライズアジャイル勉強会など
  4. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 3 目次 1. アジャイルのコアプラクティス 1. アジャイルは難しい!? 2. 「過ぎたるは猶及ばざるが如し」 3. アジャイル開発の「ユーザー価値」 4. アジャイル開発の3つのコアプラクティス 5. アジャイルコーチは開発チーム状況に 合わせてバランスをとる 2. 事例紹介 1. ここから本題 2. プロジェクトの概要 3. プロダクトオーナー・プロキシ 4. プロジェクトのスケジュール 5. コーチングプラン 6. 最低限のプラクティスを導入する 7. プロジェクトの進め方 8. ①ユーザーストーリー抽出と全体計画 9. ②イテレーション0 10. ③イテレーション1 11. ユーザーの反応 12. 立ち上げのポイント 13. ④イテレーション2 14. ⑤イテレーション3 15. 開発生産性は上昇 16. 自己組織化の成熟レベル 3. まとめ
  5. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 4 アジャイルのコアプラクティス Re:エンタープライズへのアジャイル開発の導入事例
  6. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 5 アジャイルは難しい!? 色々な人からアジャイル開発で失敗した事例を聞くと、多くのケースでアジャイ ルをやることに頑張りすぎていることに気が付きました 例えば、アジャイルソフトウェア宣言にある4つの価値と12の原則をきっちり守 り、プラクティスも何十個も適用してしまうのです。忠実にアジャイルをやろうと すればするほど、イテレーションでやらなければならないことが増えていきま す。アジャイルをやることに頑張りすぎてしまい、肝心のシステム開発は遅々と して進みません ①原則を守って、プラクティ スも沢山適用して忠実なア ジャイルをやるぞ! ②アジャイルってやること多 くて、なかなかシステムを開 発できないなぁ ③もっとアジャイルになるため に、ドキュメントは廃止しよう。 プラクティスも追加しよう ④どうやっても生産性 があがらない・・・アジャ イルって難しい 悪循環?
  7. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 6 「過ぎたるは猶及ばざるが如し」 プラクティスを増やせば増やすほど上手くいくのであればアジャイル開発はもっ と簡単ですが、残念ながらそうではありません。理由はアジャイルというより、シ ステム開発というものが人間を中心にした活動だからです。極端なやり方は人 間がついて行けません どこまでやるか、このバランスを取ることが必要です。ウォーターフォールでも プロジェクトマネージャーが普通にやっていることです。アジャイルではアジャイ ルコーチがこのバランスを取ります アジャイル ウォーターフォール 上手くいかないから、もっと アジャイルのプラクティスを 追加しようか・・・ この線より左にいくとアジャ イルの価値を達成できない。 これがコアプラクティス
  8. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 7 アジャイル開発の価値 ウォーターフォールでよくある机上で定義した要件と、実際にリリースされたシ ステムとのギャップを埋めるということです ギャップを埋めるためには、どうする? – 超短期イテレーションで素早く動くシステムをユーザーに見せます – ユーザーは動くシステムを実際に確認してフィードバックします – フィードバックを計画的にシステムへ反映します アジャイルの価値とは、超短期イテレーションを繰り返すことで、 ユーザーが本当に望むシステムを実現すること フィードバック 動くシステム 超短期 イテレーション ユーザー 確認 何度も繰り返す イテレーションの度に実際に 動くシステムを操作して確認する
  9. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 8 コアプラクティス アジャイル開発に詳しい人ほど、多くのプラクティスを駆使しようとします。しか し、先にも述べたようにプラクティスを多くすればするほど悪循環に陥り、成功 する可能性は低くなります そこで、コアプラクティスというものを考えます。アジャイル開発の価値である超 短期イテレーションを実現するためのキーとなるプラクティスをコアプラクティス と定義します 超短期イテレーション ??? ??? ??? コアプラクティス アジャイル開発の価値 (ユーザー価値) プラクティスA プラクティスB プラクティスC プラクティスD プラクティスE プラクティス
  10. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 9 3つのコアプラクティス これ以外は従来(ウォーターフォール)の手法でも構いません。まずは、超短期 イテレーションに慣れることが重要です。しばらくして慣れてきたらプラクティス を追加すべきです ① 優先度に従って開発する  ユーザーストーリーでも機能一覧でもいいのでプロダクトオーナー相当の人に優先度 を付けてもらう。その優先度に従って順番にイテレーションで開発する ② ユーザーレビューをする  ユーザーに動くシステムを使ってもらって意見をもらいます。仕様変更や仕様追加が あれば優先度を付けて、次のイテレーションの計画に反映します ③ ふりかえり/デイリーミーティングをする  日々のデイリーミーティングや、イテレーションの終わりのふりかえりを行います。ユー ザー満足、品質、生産性を改善するためにはどうするかを話し合います
  11. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 10 アジャイルコーチは開発チーム状況に合わせてバランスをとる アジャイル開発はクスリのようなものです。どんな良薬も沢山投与しては逆効 果です。患者の状況に応じて適切な量とタイミングで投与すべきです アジャイルコーチは主治医のように相手の状態を診断して、適切な量とタイミン グでプラクティスというクスリを投入します アジャイル ウォーターフォール アジャイルコーチがバランスをとる 超短期イテレーションを回すための3つのコアプラクティス • 優先度に従って開発する • ユーザーレビューをする • ふりかえり/デイリーミーティングをする
  12. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 11 事例紹介 Re:エンタープライズへのアジャイル開発の導入事例
  13. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 12 ここから本題 先に上げたコアプラクティスを軸にして、 最低限のプラクティスを見繕って、 実際にアジャイルコーチを行った 事例を紹介します
  14. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 13 プロジェクトの概要 会員向けポータルサイトをアジャイル開発で再構築します 背景 – 顧客は某会社の情報システム部門です。以前からアジャイル開発を導入したいと考 えていました。今回、最適なトライアルプロジェクトがはじまることになりました 開発規模 – 画面20程度 – バッチ5程度 開発体制 – プロダクトオーナー 顧客メンバー – 開発チーム 顧客メンバーから数名 – アジャイルコーチ 私(吉原) – 顧客メンバーは全員がアジャイル開発をやったことがありません。どちらかと言え ば、「本当にできるの?」と懐疑的でした
  15. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 14 プロダクトオーナー・プロキシ 今回、プロダクトオーナーは情報システム部門が担いました。業務部門にお願 いするには負担が大きすぎるからです。日本のエンタープライズシステム開発 では最も多いパターンだと思います。この場合、プロダクトオーナーがユーザー の要求を取りまとめます 通常のプロダクトオーナーの責務 今回のプロダクトオーナーの責務(エンタープライズでは多い) 開発チーム プロダクト オーナー ユーザー 開発チーム プロダクト オーナー 要求や優先度 の決定 要求や優先度 の決定 要求や優先度 の取りまとめ
  16. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 15 プロジェクトのスケジュール プロジェクトは5ヶ月程度あるが、アジャイルコーチによる支援は最初の3ヶ月 だけです。残り2ヶ月は顧客メンバーだけで運営します ユーザーストー リーの抽出と 全体計画 イテレーション開発 リリース アジャイルコーチ(3ヶ月) 開発全体(5ヶ月程度)
  17. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 16 コーチングプラン まず、今回のプロジェクトでは現場のメンバーはアジャイル開発に半信半疑な ので、まずはアジャイル開発の価値を実感してもらう必要があります。価値を実 感できればモチベーションも上がり、良いサイクルを作れます 早めにアジャイル開 発の価値を実感 ユーザーに動く画面を 早めに見せる 生産性を高める プラクティスを最 低限にする イテレーション期 間を短く 作業場所を同じ 部屋にする イテレーション期 間を2週間 ゴール アクション 既存の開発標準 を出来るだけ踏襲 する 良い サイクル ①ユーザーに動く画面 を早めに見せる ②ユーザーが喜 んでくれる ③ユーザーが喜べ ば、開発チームも喜 ぶ ④開発チームは、 はりきって開発する
  18. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 17 11 継続的インテグレーション プロダクトの問題を早期に効率的に発見する 12 テスト自動化 デグレーションを防止する 最低限のプラクティスを導入する 今回実践したプラクティス 途中から状況にあわせて本格的に導入したプラクティス # プラクティス 内容 1 超短期イテレーション 2週間毎に動くプロダクトを開発する 2 インセプションデッキ 開発チームでゴールと進め方を共有する 3 ユーザーストーリー 顧客の要求を端的に表す 4 相対的な見積り ストーリーポイントで相対的に見積る 5 全体計画 リリースに向けての規模見積やスケジュールを決める 6 イテレーション計画 イテレーションで開発する対象を決める 7 デイリーミーティング 1日単位で開発チームの進捗と課題を共有する 8 ふりかえり 開発チームがより高い能力を発揮できるように議論する 9 プロダクトバックログ 顧客の要求の内容、完了条件、優先順位を管理する 10 かんばん メンバーの作業内容を見える化する
  19. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 18 プロジェクトの進め方 ①ユーザーストーリー抽出と全体計画のタイムボックスは2週間です ②イテレーション0を開発準備として1週間とります。開発準備をすることでイテ レーション1以降の生産性を高めます。ユーザーに動く画面を見せることで、良 いサイクルを作ります。イテレーション0はバッファでもあります。万が一、① ユーザーストーリー抽出と全体計画が遅延したときに吸収します ③イテレーション1以降はイテレーション開発です。期間は2週間とします。短く することで頻繁にユーザーに動くシステムを提供します ①ユーザース トーリー抽出と全 体計画 ②イテレー ション0 ③イテレーション1 ④イテレーション2 ⑤イテレーション3 続く 1週間 2週間 2週間 2週間 2週間
  20. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 19 ①ユーザーストーリー抽出と全体計画 「ユーザーストーリー抽出と全体計画」の目的 – 開発を行うために要求分析や全体計画などを行います タスク 1. オリエンテーションの実施 (約1日) 2. インセプションデッキの作成 (約2日) 3. ユーザーストーリーの作成と優先度付け (約3日) 4. 全体計画の策定 (約4日) ユーザーストーリーは100点を狙いません – 3日間とタイムボックスを決めたのであれば、その期間で収まるように作業をします。 手元にある状況を整理して、課題を明確にしてユーザーにヒアリングできる状態にし ます。スピード感を持って行います 全体計画が成立しないことも – 抽出したユーザーストーリーを一覧にして、ストーリーポイントを見積ります。ストー リーポイントと生産性(ベロシティ)の仮定値で計算すれば、全てを開発するための 期間がわかります。実際、当初予定していたマイルストーンを超えることもあります ①ユーザース トーリー抽出と 全体計画 ②イテ レーション 0 ③イテレーショ ン1 ④イテレーショ ン2 ⑤イテレーショ ン3
  21. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 20 ②イテレーション0 イテレーション0の目的 – イテレーション1からスムーズに開発するために、開発標準や開発環境を整備しま す。更に、要求に関する課題をユーザーヒアリングします – 仮に、前の「ユーザーストーリー抽出と全体計画」が遅延する場合は、このイテレー ション0をバッファとして使って、吸収します タスク 1. 環境構築とサンプル開発 2. ユーザーヒアリング&レビュー 3. ふりかえり  開発標準や開発環境は開発チームが慣れているものを使います – 特に問題がなければ、開発チームが今まで使ってきた慣れているものを利用しま す。ウォーターフォール向けに作られているものは重厚長大なので、変えるという よりも、不要なものを間引くのが良いでしょう。間引くだけなら時間もかかりません ①ユーザース トーリー抽出と 全体計画 ②イテ レーション 0 ③イテレーショ ン1 ④イテレーショ ン2 ⑤イテレーショ ン3
  22. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 21 ③イテレーション1 イテレーション1の目的 – 優先度が高い機能から、動く画面を確実に幾つか作り上げます タスク 1. イテレーション計画を立てる 2. ユーザーヒアリング&レビュー 3. 開発する 4. ふりかえり  兎に角、動く画面を確実に幾つか作り上げます – 2週間で数画面を確実に作り上げます。2週間で1人あたり1画面であれば、無理 な生産性ではないでしょう – ウォーターフォールではこのタイミングで動く画面を見せる事はあり得ないので、 ユーザーは驚き、そして喜ぶことでしょう。さらにユーザーから仕様変更などの フィードバックがあれば、優先度に従って対応します。対応の早さにユーザーから の信頼は高まります。開発チームのモチベーションも上がります ①ユーザース トーリー抽出と 全体計画 ②イテ レーション 0 ③イテレーショ ン1 ④イテレーショ ン2 ⑤イテレーショ ン3
  23. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 22 ユーザーの反応 打ち合わせの終わりに、ユーザーに今回の開発の進め方についての現時点で のご感想を伺いました。「いいね。すぐに修正してくれるのがいい。今までなら 完成してから見せられるので、文言を修正するだけでも費用がかかっていた」 とのコメントを頂きました 「素早く開発して、すぐに確認する」ことがユーザーとの信頼関係を作る – 仕様を確認した画面を、翌週には開発して動かして見せます – ヒアリングした内容を、短期間に開発して、実際に見せることによって、ユーザーと の間に信頼関係が生まれてきます 打ち合 わせ 打ち合 わせ 今日はこの画面につ いて仕様をヒアリング させてください 前回の打ち合わせで話をし た画面ですが、開発してきた ので確認をお願いします 翌週には見せる
  24. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 23 立ち上げのポイント ①ユーザース トーリー抽出と全 体計画 ②イテレー ション0 ③イテレーション1 ④イテレーション2 ⑤イテレーション3 続く 1週間 2週間 2週間 2週間 2週間 立ち上げ ユーザーから好評を得て、開発チー ムのモチベーションを上げます 出来るだけ、慣れ親しんでいる開発 標準や開発環境を利用します アジャイル開発に慣れます ユーザーストーリーの作成も全体計 画も100点を狙いません
  25. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 24 ④イテレーション2 イテレーション2の目的 – 顧客メンバー主体でプロジェクトを運営しはじめます。デイリーミーティングやふりか えりを顧客メンバーが仕切って行い、アジャイルコーチはそれをサポートします タスク 1. イテレーション計画 2. ユーザーヒアリング&レビュー 3. 開発 4. ふりかえり  自己組織化への第一歩 – ユーザーからアジャイル開発の進め方に好評を頂いたので、それを追い風にしてメ ンバー主体で運営できるようにします。そのためには自己改善を強化する必要があ るがあります。ときには、企業文化にメスを入れる必要があるかもしれません ①ユーザース トーリー抽出と 全体計画 ②イテ レーション 0 ③イテレーショ ン1 ④イテレーショ ン2 ⑤イテレーショ ン3
  26. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 25 ⑤イテレーション3 イテレーション3の目的 – 引き続き、顧客メンバー主体でプロジェクトを運営します。アジャイルコーチはサーバ ントリーダーシップでサポートします – 状況をみて、プラクティスを追加するなどやり方を改善します タスク 1. イテレーション計画 2. ユーザーヒアリング&レビュー 3. 開発 4. ふりかえり プラクティスを追加するなど、やり方を改善する – ふりかえりなどで課題(Problem)として上がった内容で、プラクティスを追加するこ とで改善するものがあればチームで追加の是非を話し合います。実際にあったのは 品質問題でした。単体テストのカバレッジを高めつつ、さらに手動テストをイテレー ションの終わりに行うことにしました ①ユーザース トーリー抽出と 全体計画 ②イテ レーション 0 ③イテレーショ ン1 ④イテレーショ ン2 ⑤イテレーショ ン3
  27. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 26 開発生産性は上昇 開発チームがアジャイル開発に慣れてきて、ユーザーからの好評も後押しする ことで開発生産性は少しずつ上昇してきました 最初はイテレーショ ン0での準備もあり 高い生産性 少し難しい機能 を開発する リズムに乗り始める。 もっとプラクティスを 追加したくなる アジャイル開発が楽しく なってくる。もっとプラク ティスを! ※少ないプラクティスか ら始めているので、逆に 慣れてくるとプラクティ スへの渇望が湧き上 がってくる。理想の形
  28. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 27 自己組織化の成熟レベル 開発チームの自己組織化の成熟レベルを次のように定義して、アジャイルコー チとして評価しました 成熟レベル 開発チームの状況 必要な支援 1 初期 メンバーはタスクを指示される。タスクに課題が あっても解決に動けない アジャイルコーチが必要 2 自立 メンバーはタスクを指示される。タスクに課題が あれば解決することができる。必要なら周りの助 けを求められる アジャイルコーチが必要 3 課題解決 メンバーはタスクを指示されるが、自分のタスク だけでなく、他のメンバーの課題も積極的に解 決する アジャイルコーチが必要 4 自己運営 ゴールを達成するためのタスクを自分たちで作 り出せる。進捗管理や課題管理など自分たちで 運営できる 少しアジャイルな状態。ア ジャイルコーチがふりかえ りに入る 5 自己改善 ゴールを達成するために自己分析して、自分た ちで改善を行える。自分たちでルールを決める ことができる アジャイルな状態。アジャイ ルコーチは居なくてもよい 3ヶ月前 現在 大きく成長
  29. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 28 まとめ Re:エンタープライズへのアジャイル開発の導入事例
  30. ULS Copyright © 2011-2016 UL Systems, Inc. All rights reserved.

    Proprietary & Confidential Powered by 29 シンプルなアジャイル開発に徹して、ユーザー価値を追求しましょう アジャイル開発を成功させるのであれば、ユーザーから好評を得て、開発チー ムのモチベーションを高め、良いサイクルを回すことを目指すべきです そのためには超短期イテレーションを実現するための3つのコアプラクティスを 実践しなければなりません。ただし、これ以外のやり方は、従来(ウォーター フォール)のやり慣れた方法にします 最後に、アジャイル開発をプロジェクトの状況に合わせていくためには、アジャ イルコーチに支援をしてもらった方が上手くいきます 【コアプラクティス】 ① 優先度に従って開発する ② ユーザーレビューをする ③ ふりかえり/デイリーミーティングをする