********************************************************************** セッションs4・b テーマ：アジャイル開発とスクラム講師：平鍋健児(チェンジビジョン、永和システムマネジメント) 日時：2012/8/2313:00〜14:20 参加人数：31名(開始時)33名(終了時) ********************************************************************** ・講師紹介　以下の会社をやっています　　・永和システムマネジメント　　・株式会社チェンジビジョン　　　　　+エディタastah(旧:JUDE)の開発　　　アジャイルプロセス協議会，フェロー　要求開発アライアンス，理事　ソフトウェア工学が大好き　　翻訳した本も多数　　　　　例)マルチパラダイムデザイン，リーン開発の本質　　アジャイル開発とスクラムとう本があります　　　　　[質問]この本を読んだ事がある人いらっしゃいますか? 　　　　　　　=>数名手を挙げる　　　　　本日アウェイだと思っていたので大変うれしいです　　　　　アジャイル開発とスクラムという本に書かれていない内容を取り上げる　　　　　ことにします　組み込みエンジニアにアジャイル開発を説明するのは難しい　V字モデルが定着しすぎている　　・>アジャイルと整合しないんですよね　　アジャイルは品質を無視しているわけではない　　　　　コードとテストの成長を常に行い，自動テストを常に行えるようにする　　　　　これにより変更に耐えられるようにする　JamesGrenning(AgileManifestoの著者の１人) 　テスト駆動開発による組み込みプログラミングという著書のなかに以下のことが　書かれている　『アジャイルにソフトウェアを開発にしていくとこに一番大事な指標はテスト可能か　どうかという点であり，そのことがいい分割をうむ』・アジャイルとは　ミッション・リスク分割型ビジネスとウォーターフォールモデル　　作った機能のうち45%が全く使われていないということがおこる　　開発途中に要求が動いてしまうということが多々ある　　実現したい全体のスコープを見通して開発を行っていく方法　　　　　最後に動くものができる　ミッション・リスク共有型ビジネスとアジャイル開発　　市場や要求が動くため少し作ってそれを見せてうまくいくかどうか確認して　　次を作った方がいい　　一番必要そうなものを作ってみてそれが受けたら他の部分の開発を進めていく　　のでもよいという考え方　　従来の開発方法だとビジネスとITがゴールを分割してしまっているので綱引きが　　起こっていた… 　　　新しい機能を追加したときに最初の仕様書には書かれていないという問題が　　　起こったりする　　　　行間仕様が起こりにくい　　　　ビジネスとしてのゴールが共通認識であればよいが必ずしもそうではない　　プロセスとしてのアジャイル　　　　要求の中でビジネス的に優先度が高いものから実現していく　　　　(1,2週間というサイクルで繰り返していく)　　　　　　短いサイクルで分析、設計、実装、テストを並列に行う　　　　　動くものが徐々にできあがり成長する　プロジェクトを爆弾に例えると分かりやすいですよ　　ウォーターフォールだとでかい爆弾を分析・>設計…という風に回していくイメージ　　最後にテストを行い完成なのだが，完了するまでのフェイズで爆発したら大きな　　損害がうまれる　　アジャイルは大きい爆弾だと危険だから小分けにしてまわしていくというイメージ　　小さな爆弾だと分析・>設計…と回していくなかで爆発することもあるんですけど　　爆弾自体は小さいのでダメージを最小限に抑えられる　　一回全行程をまわしきれたら爆弾の回し方のコツを掴んできて作業効率が徐々に　　上がっていく　　　　だんだんスムーズになってきて何回かに小分けにした爆弾を運ぶことができるよう　　になる　　　アジャイルは開発の中で開発工程を学習していく　　逆に全行程を完璧にこなせるという状況であるのならば　　ウォータフォールモデルのほうがはやくできてしまうと思います　　　道をつくるときに広い道をつくるときには計画しやすい　　　どんだけのアスファルトと日数が必要か? 　　しかしジャングルに道をつくるのは難しい　　経験値がないので見積もりがうまくいかないためです　　今から解こうとしている問題が　　　　　+変わりやすい　　　　　+今まで誰もやったことがない　　　　　　　という条件が当てはまる場合ははアジャイル開発が向いている　　しかし2週間で動くものを作るのはすごく難しいことなんですよ(ケーキの例) 　　ウォータフォールモデルだとホールケーキを1層目2層目…とつくりあげていき　　全体をクリームで覆ってデコレーションして完成という流れがつかめる　　一方アジャイルはまずショートケーキを作れといわれているようなもの　　スポンジの形などがばらばらになる可能性もあるので　　最後にホールケーキにするために統合の調整を行う必要もある　　　　・>その技術はリファクタリングであったりソフトウェア工学で紹介される　　技法などが挙げられる・スクラムのフレームワーク　スクラムはアジャイル開発のフレームワークで最もわかりやすいもの　そのなかにやるべきことがたくさん含まれている　フレームワークといわれるのはプロセスに所以がある　今から作りたいというものの機能をリスト(製品バックログ)にして　スプリント(イテレーション)を単位として開発を進めていき　出荷可能ソフトウェアを開発する　24時間毎に朝会をやってチーム一体となって開発を進めていく　スクラムチームで運営する　　・スクラムマスター　　・プロダクトオーナー:何を作るかということを全て知っている人,バックログ責任者　　・開発チーム:実際のインプリメントを行う人(テスターも検証もみんな含まれる) 　　みんなで作業を分担するのではなく、みんなで作業を分け合う!! 　　技術的に得意なところはあるんですけどスキルがばらけている　　　　アジャイルソフトウェア開発においては"価値"、"原則"、"実践"という要素が存在する　　価値:まずこれを共有すること　　原則:考え方としての方針　　実践:具体的に現場毎に作る　　アジャイルソフトウェア開発宣言　　　　　プロセスやツール　よりも　個人と対話を　　　　　包括的なドキュメント　よりも　動くソフトウェアを　　　　　契約交渉　よりも　顧客との協調を　　　　　計画に従うこと　よりも　変化への対応を　　　　　　　(左側も重要だが右側が超重要であると捉える) 　　アジャイルのpracticeは2つの種類に分けられる　　　　　ソーシャルプラクティスex)共働でゴールに向かうチーム環境をつくる　　　　　技術プロセスex)高速に石橋を叩いてわたる開発環境をつくる　　　　　　今回はソーシャルプラクティスについて中心的に話していきます　　アジャイルはソーシャール(人と人が会話をしていく方法)エンジニアリングしていく手法　　　　チーム環境にまでフォーカスする開発をするようになってきているのはアジャイルの功績　　　　タスクかんばん:作業の見える化．ToDo(未実施),Doing(実施中),Done(完了)で作業を管理しボードに張り付ける　　　各自の作業を指示しなくても毎朝自発的に作業開始　　　Doing(作業中)になっているタスクが残り続けているとチームメンバーが助けてくれる　　　新しいチームになるとアナログでタスクを管理するようにしています　　　1週間目は2重管理になってもいいから進捗の管理、共有を徹底する　　　　　　　　子供が夏休みの宿題をするときに同じ事を冷蔵庫のボードを作ってやらせました　　　地域新聞という宿題が最後まで残っていた　　　残っているということがアナログで分かるため父である私が助け舟を出せた　　　どの作業の進度が悪く、どの作業が終わっていないのかということが共有できる　　　チーム一丸となってプロジェクトに必要なやるべきことをこなしていくことができるようになる　　　例)先輩が過去にやったことがあるタスクなどが存在した場合助言ができたりする　　　本来目には見えないソフトウェア開発を見えたり触れたりする事で気付きはかなり増えます　　　作業がどのように流れているかというのを見るようにして動いている風にする　　　ということだけでも気付きが多いので是非やってください　　　・滞留状態のタスクが無かったらその前工程の作業を止めて流れを作ったり　　　　するとよい　　　　ボトルネック発見に繋がれば作業の効率化をはかれる　　　　バーンダウンチャートもいいですよ　　　　　これだけで3時間ほどしゃべっちゃうので今回は割愛します　　あんどん　　　　　異常の見える化　　振り返り　　　　　カイゼンの気付き　　　　　　　Keep(良い点)、Problem(悪い点)、Try(次回挑戦)を出す．　　　　　　　全員で意見を出し、暗黙知の共同化と形式知化を行う　　　　　　　生物の進化と同じでうまくいったものを残し、そうでなかったものは　　　　　　　捨てる．この選択を自ら行うことが大事　　プラクティスの方法はいくらでもあるので　　自分たちにあったプラクティスを選んで進めていくことが大事　　・Scrumと野中郁次郎　　この話は日本ではあまりしていないのでよく聞いてくださいね　　　　野中先生　　　　　最初の文書は英語で書く(だいたい本も英語から始まる) 　　　　　冗談のセンスがめちゃくちゃいい　　　　　Scrum 　　　　　SECIモデル　　　　　実践知フロネシス　　　　　フラクタルモデル　　　　最初のスクラムの本『AgileSoftwareDevelopmentwithScrum』の著書中に参照されて　　いる論文を書いた　　Thenewnewproductdevelopmentgameという論文を書いた　　　　　　・新製品開発に焦点をあてた本　　　　　　・日本の生産業からの学びを書いた本　　　　　　・リレー形式はやめてラグビー(スクラム開発の由来)のように　　　　　　　チーム全体で前ヘ進むことを促している　　　　　　・この本はソフトウェアについて一行も書かれていない　　　　　　・バトンパス式のモデルは辞めて、時にボールは後ろにいくかもしれない　　　　　　　がチーム一丸となって進んでいくモデルで開発していこうといういこと　　　　　　　が書かれている　　AgileandLean 　　　　　　・現在ではAgileとLeanはほとんど同義で使われるようになってきた　　　　　　・TOYOTA生産方式の製品開発が海外で取り上げられると一気にLean開発が　　　　　　　広がる　　　　　　・製品開発するだけでなくてどのようにして顧客を巻き込んでゆくか・SECIモデル　　知識創造は暗黙知と形式知の相互変換運動である　　暗黙知ex)自転車の乗り方　　　　・言語文書で表現するのが難しい　　　　・主観的身体的な経験値　　　　・特定の文脈毎の経験の反復によって体化される思考スキル　　　　　(思い?メンタル?モデル) 　　　形式知　　　　・言語?文書で表現できる　　　　・客観的?理性的な言語知　　　　・特定の文脈に依存しない一般ていな概念や論理　　　　　(論理-問題解決手法-マニュアルデータベース) 　　　　・蓄積や後継ができる知識のこと　　　　・知の受け渡しができる　　上記の暗黙知、形式知の相互作用のスパイラルアップが大事である　　プログラミングには多くの形式知と暗黙知が含まれている　　人間がここまで発達しているのは形式知を得ることができているから　　氷上のメタファー　　暗黙知の上に形式値が乗っている　　水面下の領域には膨大な感覚イメージ的な経験知があり，　　それを共有し変換して新しい知を作り出す　　"Sticky"information 　　　　　一般に製品開発に必要なナレッジは2つに分けられる　　　　　　　シーズ-ナレッジ、もう一つはニーズ-ナレッジ　　　　　ユーザがほんとうに欲しいものは紙に書き出しにくい　　　　　顧客とあって話をするべきである　　組織的知識創造の行為　　　　　まずは暗黙知から始まる　　　　　その暗黙知の形式化を試みる　　　　　形式化することができれば知識を組み合わせることができる　　　　　形式知を形式知に変換して新しい知識を生む　　　　　　それを行おうとすることで再び体の中に入ってくる　　　　　　　そういうループで知識は動いている　　　　<松下ホームベーカリーの物語> 　　田中郁子氏がホームベーカリーを製品化しようとしたときに　　まずパン屋に弟子入りした　　　　　暗黙知暗黙知変換のチャンスを得た　　実際に弟子入りしてパンを作る工程を学び　　データだけからでは得ることができない知識を手に入れた　　　　　パン職人がパン生地を引っ張っているということに気付く　　その引っぱり工程をホームベーカリーに取り入れることで満足のいくホームベーカリーを作成できた　　知は形式値からはじまらない　　　　　最初に思いがなかったら知は生まれない　　　　議論よりエピソードのほうが伝わりやすい　　　　　実際のストーリをつたえるということは暗黙知暗黙知伝達としている　　知識を生み出すサイクルを繰り返すことが大事　　DesignThinkingとの関係　　　　　どのようにアイディアをつくるか　　　　　　　Role・Playing 　　　　　　　　　　実際にユーザの立場を経験する　　　　　Bodystrorming 　　　　　　　　　　ブレインストーミングのように頭だけでやるのではなく　　　　　　　　　　実際に体を使って体験をする　　　　　　　　　　　　暗黙知として得る情報も多くある　　　　　SECIモデルとアジャイルプラクティス　　　　　　　　・Socialisation,　　　　例)SprintDemo,VisitUsers,PairProgramming 　　　　　　　　・Externalisation　　　例)storyWriting,CodingStandard 　　　　　　　　・Internationalization　例)EverythingaboutLearning 　　　　　　　　・Combination例)SprintPlanning 　　知識創造マシンとしてのスクラム　　　　　要求とユーザに関する知機(成長するソフトウェア製品) 実践知リーダー　　アリストテレスの3つの知　　　　・エピステーメー=化学や哲学　　　　・テクネー=技術、スキル、工芸　　　　・フロネシス(Phronesis)=実践からの知恵　　実践知リーダーシップの6能力　　　　・良い目的を作る能力　　　　・場をタイムリーに作る能力　　いま-ここの経験の共有が場の基盤　　　　・対象に棲み込む・indwelling 　　プロダクトオーナの仕事　　　　　体でもって自分の思いを伝える　　　　　仕様書に書かれていないものを体をつかっていかに伝えるかということろにスクラムという考えが役立つ質疑　　時間の都合により質疑応答はありませんでした． ■まとめ本セッションでははじめにウォーターフォールモデルとアジャイル開発の相違点について説明していただいたうえで，アジャイル開発のフレームワークであるスクラムについてお話をしていただきました．周囲のメンバーとのコミュニケーションにも焦点を当てているアジャイル開発ではそもそも知識がどういうものなのかという点を抑えておくことが必要になってきます．そのため野中郁次郎氏の紹介を交えてSECIモデルのお話をしていただき、知識がどのように生まれどのように循環しているかとう説明をしていただきました．仕様書に書かれていない部分を体を使っていかに伝えるかということがプロジェクトを円滑に進めていく上で大事になってくるということでした．以上