1. アジャイルなマインドでいこう！ 2009/06/27 minamo

2. コントロール 本題に入る前に・・・ みなさんの参加しているプロジェクトは、きちんと コントロール されていますか？

3. コントロールされていないプロジェクト コントロールされていないプロジェクトは・・・ Ｑ：状況は？ Ａ：（多分）納品日には（どの仕様が入るか判らないけど）間に合います（と思いたいです） ->とにかく頑張れ！

4. コントロールされたプロジェクト コントロールされたプロジェクトは・・・ Ｑ：状況は？ Ａ：計画から、３日遅れています。 ○○の実装は間に合いますが、○○は難しいかもしれません。ただし、××をやめれば、両方入れられますが、いかがいたしましょうか？

5. コントロールされたプロジェクト たとえ状況が悪くなっても、対策を立てられる スタッフも、下手な不安・不満を抱かない

6. プロジェクトは コントロールするもの

7. ただし コントロール ≠ 管理

8. 管理ではない プロジェクトは管理するものじゃない プロジェクトはマネジメント／コントロールするもの

9. コントロールする方法 プロジェクトをコントロールする方法が、 開発手法 プロジェクト マネジメント手法

10. 主な開発手法 ウォーターフォール プロトタイピング スパイラル ＸＰ スクラム リーンソフトウェア開発

11. 主な開発手法 アジャイル開発 ウォーターフォール プロトタイピング スパイラル ＸＰ スクラム リーンソフトウェア開発 今回はココ

12. アジャイル開発とは Agile 敏しょうな、素早い、機敏（きびん）な

13. アジャイル開発とは ＜ アジャイルソフトウェア開発宣言 ＞ プロセスやツールよりも、 個人と対話 を優先する 包括的なドキュメントよりも、 動作するソフトウェア を優先する 契約の交渉よりも、 顧客との協調 を優先する 計画に従うよりも、 変化への対応 を優先する

14. アジャイル開発とは ＜ アジャイルソフトウェア開発宣言 ＞ プロセスやツール -> 個人と対話 ドキュメント -> ソフトウェア 契約の交渉 -> 顧客との協調 計画に従う -> 変化への対応

15. アジャイル開発とは 何かひとつの開発手法を指すのではなく、この思想に沿った手法全般を示す 学問的な観点からではなく、現場から生まれた手法がほとんど ベストプラクティスの集まり

16. ゲーム業界でも増えてきた ２００７年くらいから、ゲーム開発でも欧米を中心に採用例を聞くようになってきた（２００３年くらいから採用されてきたという話も） ＧＤＣ ２００７「 Game Design in Agile Development 」 ２００９「 Advanced Scrum and Agile Development 」 などなど

17. 主なアジャイル開発手法 ＸＰ（エクストリーム・プログラミング） スクラム リーンソフトウェア開発

18. 今日話すこと！

19. 重要視するプラクティス アジャイル開発の共通項 イテレーション駆動（反復型開発） 仕様を進化させる フィードバック／ふりかえり

20. イテレーション駆動 （反復型開発） アジャイルなマインド その１

21. サイクルの単位 リリース α ・ β 版など イテレーション １週間～４週間 日付単位 １にちごと リリース単位 イテレーション単位 日付単位

22. イテレーションとは 開発行程における１サイクル ほとんどのアジャイル系手法では、１週間～４週間に定めている イテレーションの終わりには、常に評価出来る形で動作するソフトウェアが存在する

23. ＰＤＣＡサイクル マネジメントの基本となる考え方。 Ｐｌａｎ （ 計画 ） Ｄｏ（実行） Ｃｈｅｃｋ（評価） Ａｃｔ（改善） Plan から Act まで順番に行い、再び Plan に戻る。 こうして、継続的にカイゼンしていく。 Plan Do Check Act

24. それぞれに対してＰＤＣＡを回す リリース α ・ β 版など イテレーション １週間～４週間 日付単位 １にちごと リリース単位 イテレーション単位 日付単位 ＰＤＣＡ ＰＤＣＡ ＰＤＣＡ

25. イテレーションのタイムボックス化 遅れによってずるずると引き延ばされると、泥沼プロジェクトと化す イテレーションは基本的に延ばさない（タイムボックス化） 期間を延ばすのではなく、仕様を区切る ->メリハリが生まれる

26. 計画し続ける手法 イテレーションごとにＰＤＣＡ ↓ アジャイル開発とは プロジェクト全般にわたって 計画し続ける 手法だった！

27. フィードバックを受ける イテレーションごとに制作チーム外（プロデューサーとか）からの フィードバック を受ける 目に見える成果としてモノがあるので、判断しやすい 進捗に安心できる

28. 不確実性のコーン time ×0.25 ×4.00 最初の見積もりは最低と最高に１０倍以上の開きがある 実際に信頼できる見積もりは、 プロジェクト中盤にならないと出てこない ↑開発スタート時 ↑イテレーションＸ

29. イテレーションの利点 変化に対応 する！ 進捗のトレース がしやすくなる（実装計画が立てやすい） 目に見える形で プロジェクトが進む パーキンソンの法則（学生症候群）を利用する

30. 仕様を進化させる アジャイルなマインド その２

31. よく聞く言葉 「最初に完璧な仕様書を書いてから、実装していけば最短で良い物が作れる！」 「最初に書く仕様書は出来る限り詳細に！ 未定部分があると後で苦労する」 そんな風に考えていた時期が、 私にもありました。

32. 仕様は変わる方が自然 仕様が変わるシチュエーション 現行案よりいい案が出た -> 出る方が自然。むしろ出ないのはおかしい。 ムジュンが見つかった -> 無い方が良いが、完璧な人間などいない。 市場の状況が変わった -> １年もすれば、色々変わる。 環境の制限が変わった -> 会社的、人員的、予算的状況は常に変化する。

33. 特にゲーム開発は・・・ 特にゲーム開発は、途中でいい案が浮かぶことが多い 実際にそれを入れた方が良くなるのだったら、入れるべき もちろん、状況を考えてから決定を下す必要はある

34. ゲームにおける一番の欠陥 ゲームにおける、一番の欠陥は何か？

35. 面白くないことが 一番のバグだ！

36. ゲームを面白くする方法 トライ＆エラーの積み重ねが、ゲームを面白くしていく つまり、仕様を進化させていくことこそが、ゲームを面白くする方法だ！ 「また仕様変更かよ」とぼやいてるヒマはない。仕様を進化させろ！

37. これからは仕様変更をこう言おう 「へへ、また仕様が進化したＺＥ！」

38. そのためのイテレーション イテレーションで区切られていれば・・・ イテレーションの区切りが仕様を進化させるタイミング 常に動くソフトウェアを見て、仕様を検討できる

39. ふりかえり アジャイルなマインド その３

40. ゲーム開発は実に非効率だ 多くのゲーム開発は、何もしないと非効率な進め方になる ジャンルや作品の特徴ごとに、創るものが違うのだから当然のこと

41. アジャイル的な考え方 プロジェクトの最中に、人／チームは成長していく

42. 知識には２種類ある 基本知識／技術 仕様書作成能力やプログラミング能力、グラフィックセンスなど プロジェクト知識／技術 プロジェクトに関する知識、専用ツールの技術、今回のチームメンバーと上手く連携を取るノウハウ。 両方の成長が期待できる（するべき）が、 ふりかえりを行うと特に後者が伸びる！

43. ふりかえり ＰＤＣＡのなかで、Ｃｈｅｃｋが一番出来ていない項目 重要だと判っていても、やらずに終わってしまう プロジェクトを進めるのには必須ではないが、チームが成長するには必須！

44. 反省ではなくふりかえり よくプロジェクト終了時に行われる反省会とはすこし違う 行うのは、反省ではなくふりかえり いいことは保つ、悪いことはカイゼンする、試してみたいことにチャレンジする

45. ふりかえり手法 ～ＫＰＴ～ ふりかえり手法「ＫＰＴ」 Ｋｅｅｐ／Ｐｒｏｂｌｅｍ／Ｔｒｙ 一番手軽で強力なふりかえりフレームワーク

46. ふりかえり手法 ～ＫＰＴ～ Keep Problem ・タスク管理が上手くいった（佐々木） ・グラフィックチームとの連携（本間） ・差し入れが美味しかった（佐々木） ・ムダのないミーティング（田切） ・休日出勤が多かった（佐々木） ・仕様書の抜けが多すぎた（田切） ・実装プライオリティを間違えた（本間） 保っていきたい点と 問題があった点を書き出す 媒体はなんでもかまわないが ホワイトボードや付箋を 使うと便利

47. ふりかえり手法 ～ＫＰＴ～ Keep Problem ・タスク管理が上手くいった（佐々木） ・グラフィックチームとの連携（本間） ・差し入れが美味しかった（佐々木） ・ムダのないミーティング（田切） ・休日出勤が多かった（佐々木） ・仕様書の抜けが多すぎた（田切） ・実装プライオリティを間違えた（本間） ・そもそも、見積もりが甘かった（佐々木） Try ・知識共有のため、 社内勉強会を開く（佐々木） ・新しいソフト「XXX」を試してみる（田切） ・仕様書レビュー会をしっかり開く ・タスク管理の項目に、 プライオリティを追加する ・タスクの見積もり結果を、 一度全員に見せてコミットしてもらう 最後に、Ｔｒｙから実際に何をやるか決める

48. ふりかえりをチームで行う利点 抱え込んでいた不満点やアイディアを放出する場になる 意見をぶつけ合うことが出来る 良かった点と悪かった点を明確に意識／共有できる

49. プロジェクト中にふりかえることが大事 プロジェクト知識・技術が溜まる プロジェクト中に振り返ることにより、Ｔｒｙ項目をすぐに実行に移せる 人／チームが進化していく！

50. アジャイルな考えは どこでも通用する

51. 今回紹介したもの アジャイルの基盤 イテレーション駆動 面白さを生み出す 進化する仕様 チーム／人が成長するための ふりかえり

52. 柔軟な思考を持つ プロジェクトは生もの 柔軟な思考で対応する 変化を受け入れる

53. アジャイル開発手法は使えない場合も ＸＰやスクラムなどの開発手法は、プロジェクト／チームメンバーによっては適さない場合もある しかし、今回語った思想の部分は、どんなプロジェクトでも重要な役割を果たす

54. 最後に・・・ Agile とは

55. そして、もう一つのＡｇｉｌｅ Agile イキイキとした

56. イキイキとした クリエイティブライフを 送りましょう！！