PowerPoint プレゼンテーション

Size: px

Start display at page:

Download "PowerPoint プレゼンテーション"

あきたけますはら
4 years ago
Views:

1 Agile Japan 2017 シンアジャイルアジャイルでつくるミライアジャイル実践7年目のベテランPMが語る 3つの極意私たちがたどり着いた深アジャイル 2017年4月13日株アドヴァンストソフトエンジニアリングシニアマネージャー渡会健

某工業大学機械工学科を卒業後某財閥系の宇宙分野のソフトウェア開発会社に入社最初の 3 年は何故か防衛系のハードウェア開発に従事その後現 JAXA( 当時は NASDA) のソフトウェア開発に従事する 1996 年 ~2000 年にかけて JAXA に出向し発注側の立場でシステム開発に関わるその時に Project Management に興味を得る出向から戻ってきた後は受注側として

2 某工業大学機械工学科を卒業後某財閥系の宇宙分野のソフトウェア開発会社に入社最初の 3 年は何故か防衛系のハードウェア開発に従事その後現 JAXA( 当時は NASDA) のソフトウェア開発に従事する 1996 年 ~2000 年にかけて JAXA に出向し発注側の立場でシステム開発に関わるその時に Project Management に興味を得る出向から戻ってきた後は受注側として JAXA 向けのシステム開発に従事この頃に PMP 資格を取得した 2007 年 1 月 PMP 資格を有効に生かすために Project Management を専門とするコンサル会社に転職この頃に Agile に出会う 2009 年 10 月にやっぱり現場のモノづくりが恋しくなって現在の株式会社アドヴァンストソフトエンジニアリングに転職現在所属会社において Agile 開発の実績を積み上げ中 Agile 開発の実践者 (PM の立場からの ) であり実践経験だけは豊富です PMI 日本支部アジャイル PM 研究会アジャイルソフトウェア開発技術者検定試験コンソーシアムに所属 2

すべて共著ですアジャイル検定公式テキストアジャイルソフトウエア開発技術者検定試験レベル1対応

プラクティス導入実践事例失敗から学んだ成功への秘訣アジャイルの魂 2016 マナスリンク第三部

3 すべて共著ですアジャイル検定公式テキストアジャイルソフトウエア開発技術者検定試験レベル1対応リックテレコム第3章アジャイル開発におけるプロジェクト管理 3.6 計画づくり 3.7 見積もり 3.8 品質 3.9 ドキュメントアジャイルの魂 2015 マナスリンク第二部アジャイルの現場からプラクティス導入実践事例失敗から学んだ成功への秘訣アジャイルの魂 2016 マナスリンク第三部アジャイルの現場からあなたとつくるアジャイルニアショア先とつくるチームビルドやってみたらプロセスやツールよりも個人と対話をでしたアジャイルの魂 2017 マナスリンク本日配布された本書にも寄稿しています 3

社名株式会社アドヴァンストソフトエンジニアリング設立 1986 年 8 月資本金 9,500 万円社員数 113 名 * 札幌本社 40 名東京支店 73 名 2017/4/1 現在本社札幌市厚別区下野幌テクノパーク1-2-16 支店東京都中央区銀座

4 社名株式会社アドヴァンストソフトエンジニアリング設立 1986 年 8 月資本金 9,500 万円社員数 113 名 * 札幌本社 40 名東京支店 73 名 2017/4/1 現在本社札幌市厚別区下野幌テクノパーク支店東京都中央区銀座 ASEビル事業認証 (1) ソフトウェア受託開発 * 技術者派遣を含む (2) システム開発及び導入コンサルティング (3) ソフトウェアパッケージ開発及び販売 ISO27001 *2008 年 6 月取得 P マーク *2013 年 4 月取得 4

5 経営理念ソフトウェア技術を通じて社員と家族そして関係するすべてのお客様の幸せを追求する弊社自体の主力開発プロセスはW/F Agile開発はまだ1 2割程度というのが実態です Agile開発は2011年から請負開発として実践開始主にWebシステムが中心一括請負開発を中心に様々な業界業種を問わず実績を積み重ねる官庁医療 ISP 金融教育自動車放送情報サービス等追加開発等も併せてこれまでに数十案件以上の納入実績あり 5

6 １アジャイルを正しく理解してもらう極意２計画の極意神話や誤解を解くアジャイルこそ計画が大事３チームビルドの極意チームビルドが成功の要 6

7 １アジャイルを正しく理解してもらう極意神話や誤解を解く 7

8 全ての基本 Agile Manifesto アジャイルソフトウェア開発宣言を正しく理解してますか 8

アジャイルソフトウェア開発宣言私たちはソフトウェア開発の実践あるいは実践を手助けをする活動を通じてよりよい開発方法を見つけだそうとしているこの活動を通して私たちは以下の価値に至ったプロセスやツールよりも個人と対話を包括的なドキュメントよりも動くソフトウェアを契約交渉よりも顧客との協調を計画に従うことよりも変化への対応を価値とするすなわち左記のことがらに価値があることを

9 アジャイルソフトウェア開発宣言私たちはソフトウェア開発の実践あるいは実践を手助けをする活動を通じてよりよい開発方法を見つけだそうとしているこの活動を通して私たちは以下の価値に至ったプロセスやツールよりも個人と対話を包括的なドキュメントよりも動くソフトウェアを契約交渉よりも顧客との協調を計画に従うことよりも変化への対応を価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおく 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 , 上記の著者たちこの宣言はこの注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい 99

10 10

11 一番価値の有るのは動くソフトウェアなのでいくら完璧なドキュメントがあっても動かないソフトウェアじゃだめですよって言ってるだけです保守や運用に必要なドキュメントはAgileでもきちんと作るべきです 11

12 12

13 計画はAgileでもとても大事ですまた可能な限り守るべきですそうしないといつまでも終わりませんただ計画に固執して変化を受けれなくなってはいけませんよと言っているのです 13

14 14

15 Agileを導入しても多くの場合納期短縮早くもできませんし安くもなりません何故なら価値に焦点を当てるのでより価値を生み出すために思考する時間は長くなるし要員もマルチタレント性を要求されるので単価が高くなりがちです間違いや失敗に早く気付いて軌道修正できる出来たものから早く利用できる最終的に優先度の低いものは作らないので安いと感じる早く軌道修正することで無駄な作業を最少化でき安いと感じる 15

16 16

17 大半は開発手法以前の問題困っている問題の大半は Agile WFどちらであっても発生するプロジェクトマネジメントの範疇の問題であることが多い予算が少ないとかやることに対して期間が短いとか WFが良い場合もある AgileとWFは対立ではありません選択肢ですむしろ最初から仕様変更発生しないことが確定している場合や大規模開発する必要がある場合は WFの方が効率的です 17

18 18

19 Agileでは期間とリソースをコミットしてそれに応じた要求仕様変更含むの量で調整していきます要求は調整事項なのですなので仕様変更しても仕事の量は増えません一定の仕事の量の範囲で優先度の高いものから対応していき優先度の低いものは実施しないという調整が重要です仕様コミット期間リソース Agile WF 調整期間リソース要求 19

20 アジャイルをやり続けて思ったこと 20

いちいち周りを説得するのが面倒です特にお客さん側の間違ったAgileの理解を解消するのはとても時間がかかるし根気もいります

21 WFよりも向き不向きの人がハッキリしますなのでチームビルドはより大変です何でも短いサイクルで実施していくのでスピード感はありますが結構頭も心も疲れます長時間稼働すれば何とかなる世界ではありませんまだ正しく理解していない人が多いのでいちいち周りを説得するのが面倒です特にお客さん側の間違ったAgileの理解を解消するのはとても時間がかかるし根気もいりますコントロールはWFよりも大変です常にチームを注意深く見て自律を即すための微妙なコントロールをきめ細かく行う必要があるので WBSとにらめっこしかできない管理者では管理しきれません 21

決断をする必要がありますプロダクトの方針や疑問には即断即決していただく必要がありますその為

22 コミュニケーションをより濃密にとる必要があるためお客様の時間を確実に奪います打合せの時間が長くなる問合せや電話の頻度が高くなる随時フィードバックして頂く必要がある常に短時間で決断をする必要がありますプロダクトの方針や疑問には即断即決していただく必要がありますその為開発するシステムの目的や優先順位を常に決められるべく社内調整などを先回りして根回していただくなど調整の負荷が沢山かかります 22

23 仕様を満たすのではなくお客様にとっての価値を第一に考えるのでより臨場感や貢献感を抱きやすくチームメンバーは積極的に成長しますお客様も少しずつ見える形で自分たちのシステムが出来上がっていくので感情移入がしやすく積極的になってくれ易いですそして最大の価値を手に入れやすくなりますいつもみんなで課題に立ち向かうことがしやすいのでチームメンバーは孤独感を感じている暇がありません 23

24 自分が正しく理解していなければ相手にも理解してもらえない Agileをやるなら覚悟が必要自分もチームもお客様も 24

25 ２計画の極意アジャイルこそ計画が大事 25

26 アジャイルを適用するプロジェクト変化を積極的に受け入れるにおいて 3か月後の未来を正確無比に予測できますか 26

27 スタート 1 か月後 2 か月後 3 か月後ブレ幅はどんどん大きくなる 27

28 3か月後スタート 1か月後 2か月後ブレ幅を最小に抑えることが出来るよくあるイテレーションの期間 2週間精密な計画を立てるのを予想ができる範囲内にすることで無駄な計画を立てないで済むこれがイテレーション計画 28

29 でもそれだけじゃ足りない約束している期間内でどこまでいけるのかが判らなくなってしまう 29

30 イテレーション 1 の開始前にどのイテレーションでどのユーザストリーを実施するかを計画するイテレーション 1 イテレーション 2 イテレーション 3 イテレーション 4 イテレーション 5 イテレーション 6 優先度 1 のユーザストリー優先度 2 のユーザストリー優先度 3 のユーザストリー優先度 4 のユーザストリー優先度 5 のユーザストリー優先度 6 のユーザストリーこれによりイテレーション 1 開始前時点の予想到達点を一旦見極めます 30

31 イテレーション 2 の開始前に全体の変化度合いを見極めプロジェクト全体計画を見直すイテレーション 1 イテレーション 2 イテレーション 3 イテレーション 4 イテレーション 5 イテレーション 6 優先度 1 のユーザストリー優先度 2 のユーザストリー優先度 2 (3 より優先度が高いユーザストリーを加える ) 優先度 3 のユーザストリー優先度 4 のユーザストリー優先度 5 のユーザストリー上記例では新たな優先度の高い 2 が加わることで最初は 6 あったユーザストリーが 5 までしかできないことがわかります 31

32 イテレーション終了ごとに全体の変化度合いを見極めプロジェクト全体計画を見直すことを繰り返すイテレーション１イテレーション２イテレーション３イテレーション４イテレーション５イテレーション６イテレーションが進むごとに常にその時点での最終ゴールがわかるようにしておくことが重要最初に洗い出したユーザストーリーを全部やりきることが目的では無いその時々で一番価値の高いもの優先度の高いものを作ることが重要 32

洗い出したタスクを無条件に完遂する事をコミットする必要はない明らかにタスクがはみ出ることが判明した場合ははみ出るタスクを明確

33 イテレーションの初日にそのイテレーションで実施予定のユーザストーリーをタスク半日から1日で終了する単位に分割するそのタスクをイテレーション内でチームで完遂することをコミットする但し洗い出したタスクを無条件に完遂する事をコミットする必要はない明らかにタスクがはみ出ることが判明した場合ははみ出るタスクを明確化し次以降のイテレーションに送るはみ出たタスクをどこで消化しプロジェクトの最終到達点をどこにするかはプロジェクト計画の見直しで調整する持続可能なペースを計画的に守ることも重要 33

34 計画は立てるが常に見直し計画の完遂ではなく価値実現にこだわる計画は厳守だけすれば良いものでは無く変化を受け入れて前に進むための道具にしか過ぎない 34

35 ３チームビルドの極意チームビルドが成功の要 35

36 最初キックオフが肝心自律的チームを生み出す 5つのマインド 36

37 37

38 実現するのは要求された仕様ではなく成果物が生み出す価値であるというマインドです仕様通り作れば良い訳ではなく価値を生み出す仕様を一緒に考えましょうというマインドですアジャイルのマインドとしても最重要とされている特徴です 38

39 39

40 個人の価値観は異なっていて当たり前ですその強みを活かしてそれぞれを補い合うことさえできればより強いチームができると考えていますまず自分と違う他者の個性を受け入れるところからお互いを認め合うマインドです 40

41 41

42 常に個人のみに責任を押し付けないというマインドです目標を達成するのはチームであって個人が担当した範囲だけ目標を達成しても意味がありませんチームの一員として常に何ができるかを考え皆がチームのために働きチームが個人を助けるというマインドです 42

43 43

44 失敗してもそれを糧に次のイテレーションで素早く Agileに改善できれば結果としてチームとして全体効率が上がります失敗を恐れてビクビクしながら作業しなくても良いよねという前向きなマインドです 44

45 45

46 アジャイルのスピード感で仕事をするとかなりの集中力を必要とします常に考えることが多いので全力で取り組むと定時内だけでもエネルギーを使い果たしてしまいますチーム全体のベストパフォーマンスを維持していくためには持続可能なペースを守ることが重要になってきますタスクが終わらなければ帰るなよとは言わないマインドです 46

47 マインドを維持する５つの仕組みプラクティスを継続して実施し続ける 47

48 48

49 イテレーション毎にチームメンバー全員が参加してのスプリント計画立案を行いそのイテレーション内で実施するタスク全てを議論して洗い出し中身を詰めていきますこの段階では誰がどのタスクを担当するかを決めないため自分が担当するかもしれませんよって全員が全タスクに関して真剣に議論することになります重要なのは上司からの命令ではなくチームが自分たちでイテレーションの成果を考えコミットするということですそしてそれはチームの約束になるのでチーム全体で助け合う土壌が育ちますそれを繰り返して定着させていきます 49

50 50

イテレーション計画でタスク化したものをカンバンと言われる方法で全員が見える場所に張り出し

51 イテレーション計画でタスク化したものをカンバンと言われる方法で全員が見える場所に張り出しその日の朝に自分がどのチケットをやるかを自発的に決めてもらいます自分が取ったタスクはチケット管理ツール私たちはRedmineを使うことが多いですに登録し実施した内容などはそれぞれのチケットに記載していくことで透明性を確保して情報を全体で共有することができますイテレーション内にタスクを完遂することはチームとしてコミットしたことなので苦戦中で止まっているメンバーがいても放置されることはありませんよって個人が孤立しないような仕掛け出来上がりますこれを1日から半日の短いサイクルで繰り返し行っていきます 51

52 52

53 朝ミーティング夕ミーティングは顔を突き合わせてスタンドアップで行いヘルプ要請があれば直後に関連のある人たちでショートミーティングを行いますその利点は問題をメンバー相互に発見できるスパンが短いということですこの利点をチーム自身が自覚すると困ったときにチームに迷惑をかけないために早めにアラームを出すという文化が生まれてきますいわば落ちこぼれを作り出さないための仕組みですね更にこれが進むとチームにこの技術知識が足りないと感じた人が率先してチーム内勉強会を開いたりもし始めますこうなると放っておいてもチームの技術力団結力は高まっていくばかりとなります 53

54 54

スプリント計画で洗い出したタスクがどれだけ消化できているかを手書きで壁に張り出しておきます重要視するのは完了実績の積み上げ線ですこれを見ることでチームでコミットしたタスクを完遂するためのペース配分ベロシティをチーム全体が考えるようになりますこれが定着すると前のスプリントよりももっとベロシティを上げたい

55 スプリント計画で洗い出したタスクがどれだけ消化できているかを手書きで壁に張り出しておきます重要視するのは完了実績の積み上げ線ですこれを見ることでチームでコミットしたタスクを完遂するためのペース配分ベロシティをチーム全体が考えるようになりますこれが定着すると前のスプリントよりももっとベロシティを上げたいという欲求がチーム全体に自然と広がり私たちの事例ではほとんどのケースで最初の頃スプリントに比べての倍やそれを超えるベロシティを終盤に発揮してくれるようになりましたただしこのベロシティは初期のイテレーションでは思ったように上がりませんでも大丈夫チームがマインドを忘れないように忍耐強く見守り続ければ必ず期待以上のベロシティを上げてくれます 55

56 56

イテレーションの終了時に KPTを用いてメンバー全員が必ず発表する機会を設け個々人の考え方や感じ方をお互いに直接知ることができる環境を作ります時にはメンバーの素朴な疑問が大きな改善点の発見につながりチーム力向上に大きく寄与することも有ります改善点を決める時も上司が押しつけで行うのではなく

57 イテレーションの終了時に KPTを用いてメンバー全員が必ず発表する機会を設け個々人の考え方や感じ方をお互いに直接知ることができる環境を作ります時にはメンバーの素朴な疑問が大きな改善点の発見につながりチーム力向上に大きく寄与することも有ります改善点を決める時も上司が押しつけで行うのではなくメンバー全員で決めていきます私たちの場合はもう一つのT Thanks を加えています感謝する方もされる方も日頃では言えない感謝を堂々と伝えることが出来チームの結束力が高まりますこれを繰り返すことでチームの問題は徐々に改善され最適な自律化されたチームの成長を即することができます 57

58 最初にチームマインドを生み出し仕組みでチームマインドを維持するコマンダーマネジメントではなくサーバントマネジメントがチームの自律化を生む 58

59 59

60 ご清聴ありがとうございましたこの発表で Agile に今一つ踏み出せない方々の背中を少しでも押すことが出来れば望外の幸せですご質問ご用命などございましたら下記までお願いいたします渡会健 ( わたらいたけし ) t-watarai@ase.co.jp Web 60

<4D F736F F F696E74202D208A4A94AD82C6895E977082F082C282C882AE B8DC C E >

<4D F736F F F696E74202D208A4A94AD82C6895E977082F082C282C882AE B8DC C E > 開発と運用をつなぐアジャイル最新トレンド ~ アジャイルを誤解していませんか? ~ 会社紹介会社名本社設立資本金代表者事業内容株式会社テクノロジックアート (Technologic Arts Incorporated) 東京都文京区小石川 1-28-3 NIS 小石川ビル 2 階 1989 年 12 月 5 日 39,980,000 円代表取締役長瀬嘉秀コンサルティング ( アジャイル開発