三島teNet第9回ワークショップアジャイルな開発とは(公開版)

アジャイルな開発とはアジャイルコーチ

安井力

2015.7.29 三島teNet

「今回いちばん聞きたいこと」を

書きながらお待ちくださいCopyright (C) 2015 やっとむ Creative

Commons Attribution 4.0 International License

本日のアジェンダ

• ソフトウェア開発における課題とは？

• なぜアジャイルなのか？

• 自己組織化ってどんな感じ？

• スクラムと組み込みの関係は？


一番知りたいことは何ですか？

• テーブルごとに自己紹介してください

• 何を聞きに来たか共有してください


安井力 / やっとむtwitter:@yattomhttps://www.facebook.com/yattom

プログラマーJava Python Ruby JavaScript

テスト駆動開発

アジャイルコーチワークショップ現場導入技術支援

コンサルタントモデリングユーザーストーリー


https://www.facebook.com/yattom

宣伝

XP祭り2015「俺も！！」http://xpjug.com/xp2015/


•開催日：2015年9月12日 (土) 10:00〜19:15 (受付開始：9:45予定)

•会場：早稲田大学理工学部キャンパス(東京都新宿区大久保3丁目4-1)

http://xpjug.com/xp2015/

http://www.waseda.jp/jp/campus/nishiwaseda.html

https://goo.gl/maps/XBQja

ソフトウェア開発の課題～アジャイルの背景～


鉄の三角形

スコープ(機能、仕様)

納期予算


http://www.slideshare.net/hiranabe/project-facilitation-at-kanazawarb



役割分担とサイロ化


スケジュールのしわ寄せ

仕様設計開発テスト


納期


鉄の三角形？

「現実的に無理！」

となれば

調整している

スコープ(機能、仕様)

予算期間



距離と時間を縮める工夫と努力



役割分担とサイロ化？

コッソリでも無理してでも話をする

順調なプロジェクトではコミュニケーションも円滑


部分ごとに完成する


納期



総合テスト


ソフトウェアは複雑

• 提供する機能の複雑性

• 内部設計の複雑性

• 構築・保守作業の複雑性

• 関与する人、組織の複雑性


クネビンフレームワーク

「エッセンシャル・スクラム」Kenneth S. Rubin, 翔泳社


複雑な問題への対処

• 方向が正しいか頻繁に確認する

• 全体を把握するため常に状況をチェックする

• 問題を未然に防ぎ、早期に対処する

• 状況に合わせて計画を見直す

• 人間同士のコミュニケーションを大事にする

• 現場で判断する

「あたりまえ」の工夫

非公式な手段Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License

うまくいくならやればいいじゃない


ユーザーを満足させる

誰かを喜ばす

そんなプロダクト

目標は……

vector free http://free-illustrations.gatag.net/2013/08/26/030000.html


http://free-illustrations.gatag.net/2013/08/26/030000.html

うまくいく方法

• 優れたメンバーを集めて任せてしまえばいい

• そのチームで仕様からテストまで全部やればいい

• 作りかけでも顧客に評価してもらえばいい

• 顧客と一緒に開発すればいい

• 1機能ずつ完成してしまえばいい

• 完成したらすぐユーザに提供すればいい

• 不具合があればすぐ直せばいい

• 必要なドキュメントだけ残せばいい


Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries

Jon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

© 2001, 上記の著者たちこの宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。


アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

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

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

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

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

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

価値とする。すなわち、左記のことがらに価値があることを

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

http://agilemanifesto.org/iso/ja/© 2001, 上記の著者たちこの宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。


アジャイル宣言の背後にある原則

1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。



4.ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

6.情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。



7.動くソフトウェアこそが進捗の最も重要な尺度です。

8.アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。



10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

11.最良のアーキテクチャ・要求・設計は、

自己組織的なチームから生み出されます。

12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。


アジャイルとは～「うまくいく」方法の探究～


アジャイルとは

• 価値

• 動作するソフトウェア

• 期間へのコミット

• 改善する

• チームに任せる


価値

• ユーザーにとっての価値＝使えるプロダクト

• 企業にとっての価値＝売れるモノ

• プログラマにとっての価値＝正しく動作すると確認したソフトウェア

• QAにとっての価値＝仕様通りか確認できる成果物

価値がある＝価値があるか判断できる


動作するソフトウェア

• 動作するソフトウェアを機能単位に作る

• 2～4週間ごとに完成する

• 完成＝出荷可能な品質に到達する

• 使ってみてのフィードバックを得る


動作するソフトウェア！？

• 最初からプラットフォームが必要

• テストやQAは毎回おこなう

• 毎回使ってもらってフィードバックを要求する

• 仕様が変わっても受け入れる

• 頻繁に変更や作り直しが発生する

• 事前の完全な設計は不可能(変わるから)


目指すのはユーザの価値

• ユーザは自分が何を欲しいのか知らない

• フィードバックから、本当に目指すものを知る

フィードバック＞変更の苦労


プラクティス

• 漸進的設計

• 多能工チーム

• 継続的結合(CI)、継続的デリバリー(CD)

• テスト駆動開発(TDD)

• 受入テスト駆動開発(ATDD)

• リグレッションテストの自動化


期間へのコミット

• 一定の期間の中で最大の成果を出す

• 何を作るか、頻繁に確認し変更する

• 顧客側に方針や機能の選択権を与える• 期間やコストへの影響も責任を持つ

• 都度つど最適な判断を下し、成果を最大化する


期間へのコミット！？

• 何ができるか、事前に約束しない

• 顧客の判断次第でプロジェクトは失敗する

• プロジェクト全体の詳細なWBS、ガントチャートも作らない(変わるから)


プランニング・オニオン


EMZERO Vol.3(マナスリンク)より引用

……もし気ままに計画を変更しているなら、そうした労力はいくらかムダになるだろう。ムダを減らすために最終責任時点で計画しよう。最終責任時点(Last Responsible Moment)とは、責任を持って判断を下せる最終的なタイミングのことだ……

「アート・オブ・アジャイルデベロップメント」James Shore, Shane Warden オライリージャパンCopyright (C) 2015 やっとむ Creative


将来は正確に予測できない

• 複雑な問題は完全な予測に向かない• 組織、業務、市場、すべての環境は変化する

• 厳然たる事実を受け入れる

• その上での最善策＝常に予測し計画し続ける


計画し続ける

計画から逸脱したら？

現状を踏まえた再計画＞ (昔作った)計画の遵守

• イテレーション(2～4週間)のたびに計画づくりをする

• 直近は細密に、中長期はより大まかに

• 関係者に現時点の計画と変更を周知する

• 何をいつまでに判断すべきかのマネジメントが重要


プラクティス

• プロダクトバックログ

• 顧客同席

• イテレーション計画づくり

• リリース計画づくり、四半期計画づくり

• スタンドアップミーティング

• 幅による見積り

• リリーストレイン


改善する

• 問題を見つけて直す1. 漏れを止める

2. 流れるようにする

3. 新たな流れを作る“3 Faces of Kaizen”原田騎郎 http://www.slideshare.net/kiroh/3-faces-of-kaizen

• 全体最適を目指す

• 改善し続ける• ふりかえりを定期的に実施(毎週～隔週)


http://www.slideshare.net/kiroh/3-faces-of-kaizen

チームに任せる

• 優秀な人材を集め、解くべき問題を与える

• 仕事の進め方もルールも任せる

• マネージャ、リーダーなどを付けない

• 全員ですべての仕事をする• プロダクト定義、分析、品質、開発、顧客折衝など

• 個人の領域を限定せず誰もが全体に貢献する


チームに任せる！？

• 成果はチームの能力に依存

• ベストを出す方法はチーム自身が創る• 失敗は許容し、そこから学んで改善する

• 役割は自然発生する• マネージャやリーダーも発生する ―― 必要なら

• 誰にでも向くやり方ではない

• 組織からの支援は必要• マネジメントと呼んでもいい

• 一人ひとりが全体に寄与する• 「ひとりは万人のために、

万人はひとりのために」(『三銃士』)Copyright (C) 2015 やっとむ Creative


マネジメントゲーム

• 実は「自己組織化ゲーム」


自己組織化

• ゴールと文化を共有する

• メンバー1人1人が自己判断で行動する

• 状況に合わせ柔軟に適応する

• 問題を解決し改善を重ね強いチームとなる

• 唯一絶対の解が存在しない


サーバントリーダーシップ

• チームに“仕える”リーダー

• 指示を出さず、支援する

• チームの気づきと成長を促す


質問・疑問

• 「状況をチェック」ってどうやるの？→ 見える化、情報ラジエータ

• サーバントリーダーは、管理部や総務の仕事？→ 雑用を引き受けるのはサーバントリーダーの一部。チームの様子を見て自覚してない点を指摘、支えるのがだいじ。言ってて自分ができてるか胸が痛みました

• 誰でもできるの？優秀じゃないとアジャイルできないのでは？

→ 向き不向きはあるが、今までの基準とは異なる

• やっとむとしての、アジャイルのいい点、悪い点は？

→ 楽しいから好き。組織や文化に合う合わないがある


野中郁次郎らの論文“The New New Product Development Game”～メーカーとアジャイルの深い関係～


新製品開発の「新しい」方法

• 成功した新製品を開発した様子を調査

• 国内メーカーを中心に• 富士ゼロックス、キヤノン、ホンダ、NEC、エプソン、ブラザー• ３M、Xerox、Hewlett Packard (HP)

• 6つの特徴を提示• 組み込まれた不安定さ• 自己組織化するプロジェクトチーム• 重なり合う開発フェーズ• マルチ学習• 巧妙なコントロール• 組織へ学びを伝達する


チームが自己組織化する

• 自律的• チームのことはチームで決断する• トップマネジメントの介入は最低限(四半期報告など)

• 自己超越性• 自分の壁を自分で破り続ける• 「高品質、小型、軽量、既存品より30％コストダウン

という無茶な目標を与えられ、チャレンジし続けた」(キヤノン)

• 他家受粉(cross fertilization)• 役割を相互に越え、新たな知識を生む• 「プランニング、デザイン、製造、セールス、流通、評

価の担当をすべて1部屋に集めた」(富士ゼロックス)


開発のフェーズ

“sashimi”

https://en.wikipedia.org/wiki/Scrum_%28rugby%29#/media/File:ST_vs_Gloucester_-_Match_-_23.JPG

“rugby”


https://en.wikipedia.org/wiki/Scrum_(rugby)#/media/File:ST_vs_Gloucester_-_Match_-_23.JPG

マルチ学習と学びの伝達

• レベルをまたぐ学習• 個人、グループ、企業

• 職能や組織をまたぐ学習• 学んだことをさらに広げる

• 別の組織• 次の世代• 会社全体

開発の現場で生まれた知識が拡散・洗練を経て企業の重大な資産となる


イノベーションを産み出し続ける組織SECIモデル

http://www.atmarkit.co.jp/aig/04biz/seci.htmlhttp://current.ndl.go.jp/ca1518


http://current.ndl.go.jp/ca1518

http://current.ndl.go.jp/ca1518

うまくいくならやればいいじゃない


スクラム


スクラム

• ３～9名のチーム

• １～４週間のスプリント

• スプリントで機能を完成し提供する

• Whatに責任を持つプロダクトオーナー

• Howに責任を持つ開発チーム

• 両者を支援するスクラムマスター

•継続して改善する

• スクラムガイドで定義(全17ページ)http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf


http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf

プロダクトインクリメント

開発チーム

プロダクトオーナー

スクラムマスター

プロダクトバックログ

デイリースクラム

スプリント


スクラムの価値観

•経験的なプロセス

•透明性

•検査と適応

•自己組織化


スクラムのルーツ

• 日本の製造業• 野中らの論文

• (傍流として)トヨタ生産方式とリーン開発

• 知識の創造と伝達• パターンとパターン・コミュニティ


http://d.hatena.ne.jp/wayaguchi/20130217/1361047033

https://speakerdeck.com/kawaguti/kanban-and-scrum


http://d.hatena.ne.jp/wayaguchi/20130217/1361047033

https://speakerdeck.com/kawaguti/kanban-and-scrum

詳しく知るには


参考文献


質問・疑問


気づきの共有

•2:45まで


休憩 (30分間)


休憩中チーム作り 15:15まで

• いまのグループでチームになります

• チームの「特徴」を探してください• メンバー全員に共通する点がチームの特徴です

例: 「男」「靴が黒」「プログラマ」「住所が同じ市」など

• ただし他のチームと異なるようにしてください

• 特徴を基にチーム名を決めてください気付の共有続けてもいいよ

予告: 休憩後「カンバンゲーム」


「ただし他のチームと異なるように」• 他のチームに聞きに行った人？

• チームに分けた途端に、他の人と話さなくなる

• 気をつけよう！


カンバンゲーム(別資料)


ふりかえり


チームごとに

• ゲームから気づいたことを共有

• どうしたら上手くいった？

↓以下はあとで話すのでまずゲームの話に集中

• 現実の仕事にどう使えるか

• 現実で起きそうな問題と対策


シャッフル！

• チームに半分は残り、半分は他のテーブルへ• できるだけバラバラに

• これまでの話を共有

• 現実の仕事にどう使えるか議論

• 現実で起きそうな問題と対策を考える


ツアー

• 全員で各テーブルを見物して回りましょう

• 「ルール」「枠を越える発想」• ルールを決めた人はそのへんをウロウロしてる

• とりあえず捕まえて聞いてみる

価値の創造＞決められた仕事


さいごに


最後のワーク

• お礼と挨拶

• バディを見つける

• 「1ヶ月後、現状どうか」と連絡する


三島teNet第9回ワークショップアジャイルな開発とは(公開版)

Business

Transcript of 三島teNet第9回ワークショップアジャイルな開発とは(公開版)

三島teNet第9回ワークショップ アジャイルな開発とは(公開版)

Business

Transcript of 三島teNet第9回ワークショップ アジャイルな開発とは(公開版)

三島teNet第9回ワークショップアジャイルな開発とは(公開版)

Transcript of 三島teNet第9回ワークショップアジャイルな開発とは(公開版)