皆様こんにちは 本日はギットラボデブオープスービナーをご視聴いただき誠にありがとうございます イギットラボは日本法人を設立して1年を迎えることになりました昨年は皆様の力重いご支援もあり 設立初年度より非役的な成長を遂げることができましたありがとうございます 本年を慣れちゃうよろしくお願い申し上げますさてギットラボはリポジトリー管理 またcicbを提供する省留書がベースとなっておりますけどもそのほかソフトウェア開発ライフサイプルにおいて必要となる 数多くの機能を用意しております本日から3月におたりソフトウェア開発ライフサイプルにおいてギットラボがどのような効果をもたらすことができるのかを 改めてご紹介させていただきたいギットラボデブオープスービナーシリーズを開催したらく運ぶとなりました本日はアジャイルプランニング 来月はチームコラブレーションに関してまた最初月4月にアプリケーションセキュリティに関して考察してまいります本日はアジャイル公司のエクスパートであるプレイエーションライン株式会社 株式会社やマネコの田中様を招きしてアジャイルの歴史や最新情報を含めてどのようにスクラム開発を推進しておられておりますまた後半はギットラボのネモンマジでアジャイルプランニングのギットラボの適用について 弊社にとよりご紹介させていただきますなおオスモに関してなんですがボリオズムの機能の中に画面下のやや右折になるかと思いますがQ&A機能がございます そちらを立ち上げていただきまして適切になりますがご給入をいただけますとさようならでございますセミナー中にいただいたオスモに関しては随時ペントをさせていただく予定でございますまた表示させていただいているメンドラズジェピーガンダバーセールスアットマークギットラブロッドコンまで応援していただいても問題ございませんよろしくお願いいたします それでは田中様の心よりご視聴くださいでは改めて考えるスクラムプラスアジャイル基本の機編をさせていただきたいと思いますではまずはですね事故紹介からさせていただきたいと思います本日お話をさせていただきます株式会社アマネコの田中両と申します よろしくお願いします私はですねえっとアジャイル開発を10年ほど前からスタートしましてでその後ですね エンジニアとしてのスクラムの経験やら外資系でのスクラムマスター経験であとはスタートアップの立ち上げのエンジニアリングサポートなどを通して現在では株式会社アマネコでアジャイルコーチ権ソフトウェアエンジニアとしてやっております 最近ではですねえっとアジャイルコーチとしてチームのサポートですとか あとは会社全体がアジャイルトランスフォーメーションする時の会社としてのサポートなども行っております本日お話しさせてもらうことなんですけれども大きく3つのテーマに分けてお話しさせてもらおうと思いますまずアジャイルスクラムをなぜやるのか アジャイルスクラムって何それから最後にどうやってスクラムを実践するのかといった話をしていきたいと思います 結構あのベーシックな内容になっていきますし8 応用編の話とかないんですけれども大体30分間楽しんで言っていただければいいかなと思っていますはいではちょっとこの最初に質問ですねアジャイルスクラムをなぜやるのか私私自身 伝える立場でも実践する立場でもアジャイル開発をここ10年ぐらい選択し続けてきていますそれがなぜかというのを端的にお伝えしようと思いますあくまで私の個人の意見ですこの辺りは人によってある程度違いはあると思います 実際にですね8このテーマでちょっと話そうかと思った時に私の知り合いのアジャイルコーチ数名にえっとなぜアジャイルスクラムをやるんでしょうかっていう話をしたところ まあ全員ね答えが違いましたもう人によってはなんかあの まあ なんていうかチームでやるのが楽しいからとかそういった話もいろいろありましたであくまで私の意見としてえっと3点挙げさせてもらいたいと思います まずなぜアジャイルスクラムをなぜやるのか1個目はもうかるからですで2個目には楽しいからです 3個目には生き残れるからですちょっとねこれだけ言うと何でやるのかいまいちわからないと思うので1個ずつ掘り下げていきたいと思いますまずもうかるといったところなんですけれども 企業として何か利益を出すっていうのは結構当たり前の話ですよね皆さんあの時々忘れちゃいたりしますけどもちろん企業が利益を出すことだけを考えているわけではありません 企業にはそれ以外にも社会的責任を果たしたりとかいろいろありますがまずはベーシックな活動として利益を出すということがあります まあ当たり前ですよねこれサボっちゃうと給料を出せませんからねはいで8アジアルスクラムなぜやるのかのところにここでもうかるからというものがあります もうからなかったらそもそもこういったことをやる質はあまりないんですよね8じゃあどうやって設けるのかって話なんですけれども 一番多分端的に計画主義的な動きと違うところというのはビジネスを市場に投入する速度が早いと言ったところですじゃあただし非常に与えるインパクト最初のインパクトは 計画主義と比べて大きいかと言われるととても小さいです比べてみると例えば1年ぐらいかけて計画主義的に作っていったプロジェクトをどんどん 投下するとインパクトは結構でかいですよねただしこれはバクチンみたいなもので大間違いの時もあったりします昨今のですね8情勢を考えると情勢はどんどんどんどん変わっていくっていうのを多分皆さん感じてると思います 1年前に考えていたいいアイディアっていうのが今いいアイディアがどうかはですねわからないですよね に対して8アゼルスクラムだと8そうです市場に投入する速度っていうのは早ければ そうですね1日とか2日で投入したいとかします当然そこで与えるインパクトって小さいんですけれども何らかのフィードバックが書いてきます そのフィードバックを受けてまだ改善しまた投入しといったことを繰り返していきますこうやってどんどんどんどんやっていくことによって素早くトライアンドエラーしていくことによって どんどん移り変わる情勢に対応していきながら何が儲かるのかっていうのを探っていくことができるんですねまたあとですねえっと何が良いのかって作っていく手法として 大体の会社さんでは統計的な手法つまりbi とかって言われるものを使うことが多いんですけれども最近ではあの事例研究法的な手法つまり ux レサーチとかですねそういったものを使うことも多くなってきていますで統計的な手法だとスペシャリストを雇ってその人を任せってこともあり なんですけれども事例研究法的にはチーム相対で当たった方がいいんですねもちろんスペシャリストを雇うんですけれどもスペシャリスト悪魔リーダーになるべき人であって その人に全部お任せといった形ではないんですそういったチームで動くって言ったところも スクラムで動いてあのスクラムやったりアジアルで動いたりとかする時に役に立っていきますなので私はこれを選んでるっていうのがまず一つ目にあります 次にですね楽しい楽しいこといいことですよねでもですねえっとスクラムのトレーナーとかをしていると時々あの大抵企業さんとかと話を聞いていると不思議なことがありまして 楽しいことと仕事は別だみたいに考えているんですがまあまあいるんですよねでも楽しいことと仕事っていうのは別に相関関係も委員会関係もないので楽しい仕事ってあっていいんですよでえっとただし楽しさっていうのは色々ありますよね あの単純にお酒を飲んで楽しいとかあのゲームをして楽しいってのもありますけど ここでいう楽しいというのは仕事をして楽しいつまりチームで働いて楽しいってところに適さしてもらえますでこういったところを突き詰めていくっていうのは最近出てきた動きの中にもありまして えっとワークライフバランスといったことを聞いたことあると思うんですけどもいやいやもっともっと進めていこうよってことでお茶屋さんとかがあのワークアズライフって言ったあの話も出てきていますワークライフバランスっていうのはワークっていう苦しいものとライフっていう楽しいもののバランスを通っていこうよって話なんですけどもワーク仕事をそんなにネガティブに捉えるのではなくて仕事も楽しくしちゃって人生の一部として多化していこうよってのがワークアズライフの大きな話になっていきますまたですね楽しいって言ったところ他の視点から見ますとですねモシベーション3.0の内発的動機って言ったところもありますちょっと聞いたことがない人がいるかもしれないんで言っておきますけれどもモチベーション1.0 2.0 3.0とありまして1.0は生きるための動機ですね生きるか死ぬかって言った時の動機になりますでモチベーション2.0っていうのはえっと外発的動機つまり上司とかから新商品発あの褒められたりバスを受けたりバスを避けたりとかって言うことが同期になるのが2.0になります3.0は内側から湧いてくるものですよねこれはどうやって湧いてくるかっていうのは大体チームで働くことによってお互い刺激し合って湧いてくるって言ったことがまああの短い時間パパって言いますとそういうふうになりますこれが2番目の理由です3番目ですねえっとまあそれらもうかること楽しいこと利益を追求するための行動プラス内発的動機これらがあるとこのそのチームっていうのは長続きしやすいんですね最近よく聞くかもしれませんけどサステナビリティとか継続性とかいったところですねえっと そういったふうにチームが生き残れるようになるんですよでいいチームは8いい組織の構成部品になっていきますそうすると 自然とチームが生き残って各チームが生き残っていけば組織も生き残っていくとえっともうかって楽しいことを両立しながらも継続性がないとあのあまり意味はないんですよね僕自身経験があるんですけれどもスタートアップでえっと 楽しい楽しいっていうことをやってたんですけど実は全然もあの一瞬だけもうけれたんですけどねその後全然継続性がなくてですね 最終的にはですね黒字転換できなくてですねあの何か投資を返せない状態になってしまってえっといろんなまあ引き込もう楽しいことが起きいると言ったことがありましていくら楽しくて一瞬も受けられたとしてもそれに継続性がなかったら結局あまり意味はないんですよその後の行動に なのでやっぱ生き残れることっていうのを考えていくっていうのは非常に大事になりますでアジャイルスクラムをやるとじゃあそれが達成できるのかっていうとそうではありませんそれだけやっていても別に達成はできませんがものを作ったり価値を生み出したりする側そのチームの側やそれを考える人たちの今のところの良い選択肢に僕はなっていると考えていますはいでえっとじゃあ今までえっとアジャイルスクラム僕はなぜやってるのかっていうのは話してきたんですけれどもここからそもそもアジャイルスクラムってなんだろうっていう話をしていきたいと思いますそもそもですね 専門家か言わせるとこのアジャイルスクラムって並べた時点でちょっと実際と何色を示されるかも知れますそもそも違うものですからねでもどうやってどう違うのかっていうのを簡単に説明していきたいと思います ではですね歴史から改めてアジャイルスクラムを考えるって言ったことをこんな感じに年表を簡単に作ってみましたすごくこれはざっくりとした年表なのでえっとこれを堂々と他のところで持っていくのはやめてくださいね 簡単にアジャイルスクラムを勉強するための簡易年表だと思ってくださいでこれちょっと僕の個人の意見なんですけれどもアジャイルのスタード地点 じゃあこの表の見方なんですけど上の方がいわゆるアジャイルの流れ下がスクラムの流れだと思ってくださいで上の方の一番最初1975年ですね えっとブックスが人間の神話って本を出しますこの中で8ますごく端的に人間の神話の人月っていうのはあの1人月2人月の話なんですね 人間の神話って何のこと言ってるかっていうと例えば10人月の仕事があったときにじゃあ2人投入した5人月になって10人投入したら1ヶ月で終わるのかって そんなことはないですよとそもそもプロジェクトに人を投入すれば投入するほど基本的に遅くなっていくんですよっていうのが書かれていますでさらにその中でウォーターフォールいわゆる計画集計計画指導的な考え方っていうのは崩壊するよっていうのがこの時点で1975年です結構前ですよねあの 正直ですね僕の生まれる前になったりするだたいしますその頃か実際とウォーターフォールって良くないよっていうのは実際と書かれてたりしますはいで8アジアエルとウォーターフォールっていうのは2個対立的なものではありませんアジアエルの半島やればウォーターフォールになってウォーターフォールの反対やるアジアエルになるわけではありませんが8アジアエルの誕生には少なくともウォアンチウォーターフォールの8その流れがあったということは僕は否定できないかなと思っていますただしだからといって8 何というか逆の関係にあるわけではないですウォーターフォールが良くないか別のやり方を探そうといって探した結果アジアエルのマインドセットが生まれたといったことになりますでですねこの昔の1975年の次にですね1986年ちょっと読みづらいかもしれませんけどこれ論文ですね8の中いくじろう先生とだけうち広田川先生が書いたthe new new product development game ってやつですねこれはですねアメリカの方から8の中先生たちの方に依頼がありましてアメリカの NASA の方とかでやっているプロジェクトがうまくいかないんだけども日本の企業でやっているやり方がなんかうまくいってそうに見えるから なんか比較検討してみてくれないかということで出た論文になりますでこの論文の中で初めてスクラムといった言葉が出てきます たらし8メインで使われている同じ用語は寂身なんですよね寂身ってことは使われてます8どういったことに使われているかっていうと各部門が縦割部門なんだけれどもそれぞれがちょっとずつカバーしあってうまくやっているっていうところが刺身を 切って並べたこの横から見た感じに見えるから刺身というふうに実際あのローマジというか書かれてるんですねこれ英語の論文なんですけども なんですけどもの中先生も去年かなお年かなの時に公演で言ってたんですけど刺身じゃアメリカへの受けが悪いと 何言ってるかわかんなくなるので似たような形って何かないかって言った時ラグビーのスクラムが肩を組んでる姿が似てるぞということでスクラムっていう言葉を使ったと言ってます ただし別に楽美に壊しいわけでも何でもなくなんとなくで選んだ言葉らしいですはいここで初めて歴史の多分こういうチームワークのことにスクラムといった言葉が出てきます 次にですね1995年研修エヴァーとジェフザザーランド研修エヴァー側がスポッパーっていうふうに書いてあるんですけど そこのシーンはちょっとわからないんですけどもスクラムがというやり方が誕生します1975年にこういうやり方よくないよと言ってみんながいろんなやり方を探してみましたその中で 研修エヴァーたちがスクラムって言ったものをこの1995年に誕生させたんですねそして使っていきました その研修エヴァーとジェフザザーランドですけどその後にアジアルマニフェスト2001年に書くときにちゃんと一緒にこの ちょっとサイトにアクセスしてみられるとわかるんですけど2人ともここのアジアルマニフェストの書き込むのに2人とも立ち合ってますアジアルっていうのは 人間のシーンはでこのやり方が良くないよって言った後にじゃあどういうやり方がいいんだっていうのはみんな方法で探し始めたんですよね方法で探し始めてその中であるイッパが僕たちを同じ方向にある程度向いてるようにやり方は違うけどその中で僕たちが向いてる方向をある程度記念匹的に固めておこうかってことでできたのがアジアルマニフェストですそのうちのイッパがスクラムになります 2000年ぐらいに流行ってたのたぶん XPですねケントベッグの XP が流行ってました エクストリーミングプログラミングですねそっちが流行ってました その後スクラムの誕生の あまり有名ではなかったと思うんですけれども確か2001年に出たですねピータマクブーリンのソフトウェア職人機室といった本の中で 1パラグラフぐらいスクラムやり方があるんだよってことが書かれていたりしますでスクラムがドンと有名になったの僕はこの2009年に スクラムガイドを出した時ですね実際これ英語版しかまだ出てなかったと思うで日本語版が出たの確か確か2010年だったと思います ちょっとごめんなさいそこはサイト見たほうが早いですね2009年スクラムガイドが生まれました スクラムガイドが衝撃的だったとこは何かっていうとまず薄いってことです全部で十数ページしかありません20ページいかないんですよね でかつ pdf で誰でもダウンロードできますでスクラムってのこれを読めばオッケーだよっていうのが本当に衝撃的でした それまで XP とかもう短い薄い本だと言っても100ページは超える本でしたし柔軟ページでやり方をルールがルールブックをまとめたってところは非常に 面白いところでしたさらにえっとすごいところは竹言語翻訳されたこととさらにその 細かくアップデートを繰り返していったんですね最新アップデートは2020年に出てます去年ですね去年の マイスちょっと何月か忘れちゃったんですけども11月かそれぐらい 上映たも間違えてますね10月か11月ぐらいに最新版が出てます時代時代に合わせてどんどんアップデートしていってるんですね さらにこのアップデート8実際には2009年のアップデート2011年のアップデート2013年のアップデート2016年2017年とどんどんアップデートして今2020年版になってますすごいところはアップデートのために 8ページ数が増えないんですよどころか2020年の版は結構減ってるんですね エジスはこれはねアップデートとしては成功している方だと思います対してあの他のメソトロジーでまぁちょっと名前は伏せときますけども最初はそこそこ薄い差し立ったものが今では 電話帳並み電話帳って言ってもみんなわかんないのが辞書並みの大きさになってたりするやつもあるので それと比べると相当成功したアップデートし続けていると思いますでですねそのスクラムガイド2020ですね 変更点がいろいろあるんですけどもその変更点から最近のスクラム問題点を考えてみようと思いますスクラムはいいものなんですけど問題がないわけじゃありません そもそもですねジェフサーダーランド博士の統計調べによるとですね大体60%ぐらいは間違えたスクラムをやっているとかっていう話もありますな問題点もあるんですじゃあどういったところ問題点があるかっていうと いうのをちょっと探っていきましょうとちなみにスクラムガイド2020なんですけども2017年の版の8変更っていうのは ちょっとした文言変更とかだったんですけど2020年の版はねガラッと変わりましたサブを取ってみようと思ったんですけどもそもそも サブが取れないぐらいもドラスティックに変わってます項目としてなくなったとこもありまして項目そうして新設されたとこもあります81ページぐらいあったところが半分になったとこもありますし逆に1 えっと1パラグラスしかなかったところが1ページぐらいになったところもあります相当変わったんですね なので変更点をここにバーって出していくとちょっとそれだけで話が終わってしまうので僕が気になった2点だけちょっと話をさせてもらおうと思います まず第1にですねアカウンタビリティという言葉が増加しましたえーと僕の同僚でですね英語系のアジアルコーチがいるんですけど彼が読み終わったと言ったのがなんかアカウンタビリティ と言葉が増えた気がするっていうふうに言ってましたで僕実際気になって英語版の方の 中身を文字検索して見てみたところ確か2017年の版に比べてアカウンタビリティ と言葉が増えて代わりにレスポンシビリティという言葉が減ったんですね でここなんですけどレスポンシビリティっていうのは日本語だとよくえーとせっ あの結果責任じゃね間違った行動責任かな行動責任って言われますアカウンタビリティは結果責任ですで日本語訳してもなんかいまいちピンとこないんで僕この辺りはあのたまたま同僚に英語系の人がいるのでよく話し合ってみたんですけれどもレスポンシビリティっていうのは結局レスポンスする責任何か反応する責任で行動を終わらせることによって責任が達成されます アカウンタビリティっていうのは会社から一部アカウント借り受けていると何か一部の資産を借り受けてそれを何とかしてうまくする責任があるんだということを言ってました はいでこのアカウンタビリティが増えたってことは結局どういうことだっていうのをちょっと僕も考えてたんですけれども1回ねスクラムガイドがね更新された後にあのこれあのスクラムガイドを更新するのとはねだいたい100人ぐらい行ってるんですよね 世界のトップスクラムトレーナー100が集まってやるわけですよ でその中の人中にもその日本人も入ってましてエバターさんっていうんですけどもエバターさんともちょっとこんな話をしまして最終的にはですねえっとジェフサザーランドさんがスクラムインクのフォーでやりましたの解説会 日本向けのスクラムガイドの解説会があったんですけどそこの中でちょっと結構明らかになりました結局ですねスクラムガイドに書いて言うとみんなやってるだけでその結果に責任をとってないということがありましたつまりデイリースクラムやってますよと スプリントプランニングやってますよやってますよやってますよっていうんだけどじゃあそれは効果出せてるんですかビジネス効果出せてるんですかっていうとそこまで見てなかったりするんですよ なのでそこは更新されてそこまでちゃんと見なさいよあの仕事なんだから仕事法でその会議をやったんだからそれを効果をあげないとおかしいでしょうよということを言っていますそういったこともあってアカウンタビリティと言葉が増えました 次にですね a 指示的部分の削除ですねこうしなさいああしなさいって言ったところが減っていますこれ県庁の合われているのはデイリースクラムのところですねデイリースクラム前はですね開発チームがスプリントゴールを達成するために私が昨日やったことは何か 今日やることは何か障害となるものを目撃したかってことを質問としてするといいですよ 他何してもいいんですけどこういうのが例としてありますよって書いてあったんですけどそこはザクッと消されてまして何してもいいって書いてるんですよ ならよりそこも踏まえてもアカウンタビリティつまりあのビジネス結果を出せよといったメッセージ性が非常に読みとかが出ますスクラムってやるだけじゃダメなんですよねそれでちゃんとビジネスの効果をあげなきゃいけないんですよ もう切るってことは非常に大事なことなんですねはいじゃあ最後にですねどうやってスクラム実践するのかってとこなんですけども えーと一番基本の木8タイトル回収ですけどねスクラムガイドを読んでそのままやる スクラムガイドは2020年度版になってより指示的部分が消されたことによってシンプルになりましたただしシンプルになったって言っても 8それぞれの業態に合わせちゃんと考えてやらなきゃいけなくなったことはなったんですよ前は読めば読んでその通りやればいいやったったんですけども今回はちゃんと意味を読んで理解して 自分たちの業態に合わせ何がいいのかっていうのを考えなきゃいけないことになりました一番多分スクラムガイドを読んで一番最初にあるのは会議だと思うんですね ミーティングのイベントがいろいろ書いてありますスプリントプランニングですとかスピントレトロスペクティブですとか レビューですとかそういったものが書かれていますでよくあるミスっていうミスというか僕がアジアルコーチで見ちゃうのは既存の会議大元々当たる前ですけど スクラム始める前からですね会社としてはビジネスをやっているわけですよ ビジネスに対して何かコンセンサスを取ったり何か決めたりするような会議っていうのはそもそもあるんですよねその会議を消せないんですよね 消さないままスクラムのイベントそのまま追加しちゃう何が起きるかっていうとミーティング地獄になっちゃいます もう月曜日朝か夜までミーティング火曜日朝か夜までミーティングもうヘトヘトになっちゃうんですよねここら辺りをスクラムを導入するときに当然なんか見直さなきゃいけません でもう一つの大きい間違いとしては既存の会議大をそのままスクラムイベントにコンバートするやり方ですね普段やって毎朝やってるやつがあるかこれをデイリースクラムと言い直そうとか こういうことをやってるからこれをあの毎週やってるんだからそれを8スピントプランニングにしてしまおうとかってやつなんですけども そもそもですねえっと会議大っていうのは当然効果が前ディゼンやってた会議大っていうのは参加するメンバーも決まってますしどういった結果があるか分かってるんです それはスクラムのものとは多分違うんですよねもしかしたら一緒かもしれませんが大体その企業内で判断している人ってスクラムやり立ての人が判断してるんですよスクラムのプロフェッショナルがちゃんと効果とか会議大参加しているメンバーを見極めてこれはスピントプランニングと言い直しても大丈夫ですねと言ったわけではなくなんとなく これでしょっていうふうにやってたりするとこれもこれでですねスクラムイベントが軽害化していきます 結局スクラムイベントやるんですけども裏イベントが発生していったりしますいやこれをねちゃんとあのここの部長さんを読んでやらなきゃいけないよねとかって言ったりして別のイベントを発生させてそれがスクラムイベントやってるんですけどそれがねやつで実際でとビジネスが回っていった状態が起きたりするのでちゃんとそのあたりを読んでちゃんと理解しそのままやるって言ったことが大事になっています 次にですねスクラムっていうのはフレームワークですフレームワークっていうのは結局そのままやっただけじゃダメなんですよね それ上にプラクティスモジュールを乗せていかなきゃいけません例えばですね有名なやつで言うと朝会です スクラム会でちゃんと読んでもらうとわかるんですけど朝にやれなんて一言も書いてないんですよで朝会っていうのは朝にやって集まるっていうプラクティスです あとプラクティスで有名なところで言うとユーザーソールですとか看板ですとかジラーを使うですとかバンダンチャートを書くとかいろいろあると思いますがそれぞれ有名なプラクティスプラクティスなんだけであってあなたたちがやる状態にあってるかどうかはわからないんですねそれらを 追加し自分たちでやりながら実験していく必要があります実験的ってどういうことだろうって考えたときにマネジメント3.0から実験的の定義があります成功するか失敗するかわからない状態ということですね 成功するって分かってるものはプラクティスって言って失敗するって分かってるものはミスって言います当然ですねだからそれをやったところうまくいくかどうかわからないなっていう時は実験的だと言っていいでしょだからまずはプラクティスをどんどん実験的に試していってください実験的はどこかを見るのが結果から見れば明らかです 失敗が半分成功が半分だったら多分実験的をうまくいってますもし成功確率が多すぎたりした場合はより 失敗するかもっていう気持ちを強くしたプラクティスをどんどん導入していってくださいで失敗と成功を通じてどんどんどんどんラーニングが溜まっていきます 学びが溜まっていきます学びが溜まっていけば脳図と看板が合ってるとかジラが合ってるとかユーザーストリーって書き方が合ってるとか朝日よりも友会が合ってるよとかって言ったことが分かっていきます そうすれば脳図とスクラムっていうのが分かってくるようになります最後にですねスクラムの専門家を要請もくしは雇用しましょう スクラムガイドにはスクラムマスターを用意しろって書いてありますよくあるミスとしてはスクラムマスターっていうかかりを用意してそれをとりあえずやってみるって言ったことになるんです けれどもこれはですね持ちませんどういったことかって言いますとねえとスクラムマスターっていうのは えーと担当者ロールなんですよつまり役割なんですよ開発者やpmとかと一緒なんですよ そのためのキャリアパスを用意してあげる必要があります会社としてちゃんとスクラムマスターを要請するっていうのはちょっとしたトレーニングに誰かを連れていくとか言ったことではなくてですね ちゃんとキャリアパスを用意しちゃんと小級制度を用意し評価制度を用意するって言ったところが要請すると言った言葉に当てはまりますじゃあですねそれをどうやってやっていったらいいのってところなんですけども まあ大体の場合最初はですねスタートの時は専門家を得ることを僕はおすすめしますあのえっと在野のフリーでいるスクラムマスターの人もいますし 新しく会社をやめるとスクラムマスターの人もいますまたですね僕みたいにあのアジアルコーチとしてそれを派遣している会社もあります 私の会社のあの山根子もそうですけれどもクレーションラインも8アジアルコーチの派遣を行っていますそういった会社は徐々に増えてきています 専門家いなければ雇えばいいんですで必要なくなれば8あの契約を止めればいいんです でその時には当然社内にもうスクラム専門家がいる状態になっているはずですこうやってスクラムをまずはそのままやり そしてプラクティスを実験的にやっていきそれを支える専門家を要請もしくは雇用しチームを育っていきますチームを育てていけば当然会社も育っていきます 会社も変わらなければいけませんそうですね先にキャリアパスなんか会社の協力なしにはできませんチームだけではできないんですよね そうやってスクラムをどんどんどんどん皆さんの中で実験していってくださいはい僕からはこれで話は以上になりますありがとうございました 皆さんこんにちはギットラブソリューションアキテクトの伊藤と申しますアザイル推進するにはチームの育成だったり組織文化の変革プロセスの変革が気になってきます さあにはそれを支えるためのプラットフォームや環境も必要になってきますこのセッションではギットラブを活用してどのようにアザイルプラニングができるかということを考えていきたいというふうに思いますまず簡単に自己紹介させていただきます私自身は 前職はアペイケーションセキュリティのソフトラベンダーにましてCI CDの中でどのようにセキュリティスキャンをするかということをお客さんに提案してきました またその前はいわゆるエサエアという業種で開発ですとか技術調査またはアザイルポータフォーインとはずプロギュストの管理を携わってきました その中で開発プロセスの改善自体にももともと興味があるというふうに感じましてギットラブに参画しました どうぞよろしくお願いしますまずはギットラブについて簡単にご紹介していきたいというふうに思います 簡単に一言で言うと単一のアプリケーションによるデボップスクワットフォームということが言えます皆さんギットラブを活用される方 まあそのきっかけとして多いのはギットリポジトリとしてのツールということが多いんではないでしょうか あた次のステップとしたcicd機能がありますのでそこからcicdを活用していくということもという方も多いかなというふうに思います ただそれらはギットラブのこのデボスデボップスプラットフォームとしての一部でしか過ぎず例えば今回ご紹介するプランニングのところ 計画アザイル計画をする機能ですとかその高速のところパッケージリリースのところで成果物をパッケージしてリリースしてさらにデッポイー環境本番環境を自動的に 設定して監視するという機能もあったりしますまたこれらのすべてのステージを全体として管理してそのスページの可視化をどこにボトネックがあるかという可視化をする機能があったりですとかセキュリティスキャンを試合の中で実施してシフトレフトを目指すという機能もあったりしますこれらのことを一つのアプリケーションでできることがギットラブの最大のセメントに考えています次にこうカテゴリー別に機能を見た時の外観はこんなようになっています ここではいくつか皆さんご存知でなさそうなものをピックアップしていきたいというふうに思います 一つ目はバリューストリーム管理機能ですねこちらは各ステージレボップスのステージに対してそれぞれどれぐらいどこに時間がかかって例えばコーディングに時間かかったというところを注意してどのステージにボトネックなっていうことを特定することができますあとは今回ご紹介するようなアジアエルのプロジェクト管理機能ですとか ベブーパフォーマンスこれはci の中である程度の負荷テスト性能テストを実施するっていうような機能です あとはコンテナーレジストリーこれはどっかイメージを確保する確認するための機能でしてきっとリポジトリーだけでなくてコンテナーレジストリーだったり パッケージレジストリーもgithubでは提供することができます あとは脆弱性脆弱性をセキュリティスキャンスする機能あるんですけどそれをセキュリティスキャンスした結果を一元的に管理する 脆弱性管理機能もあったりですとか次にフィーチャーフラグですね フィーチャーフラグは例えばab テストをした時にとかbっていう切り替えを ギターのUIで簡単にオンオフできるっていうような機能がフィーチャーフラグの機能ですあとはクーバーネティスとの連携ですねクーバーネティスをデプロイ環境として連携し 自動的に設定しデプロイ環境として再連携活用するっていうような機能もあったりします こちらでこちらはその皆さんいろんなツール各種ツールまあ製品オープンソースを含めてお使いだと思うんですけど まあ一般的にこんなようないろんなツールを組み合わせてデブオプスを実現していくかなというふうに思っています 例えばチケット管理システムを調達してまたギットリポジトリは別のソフトウェア使ってさらに ci は人気にして回すということが結構多いんではないかというふうに思いますそこでの課題として考えるのまずその複数のツールには複数の由来がありますので まあそれぞれ違う使いがあってだったいい学習コストがあるかなというふうに思っています また通知もそれぞれのツールかツールから発されてきますしアップグレード時の高感性これは結構重要でここが結構メンテナンスコストが高いとこうかなというふうに思っています例えばあるソフトウェアある開発ツールをアップグレードしたいんですけどそれと連携してプラグインがまだそこに対応してないため結局そのアップゲードを諦めてしまうしまってこともあったりするかなというふうに思います あとは通りごとの権限管理ですねそれぞれのツールで適切な権限を設定しないといけないですし ステージにまたがあった分析ですねここはそれぞれのツールはそれぞれのデータベースを持っていますので人間的な分析は基本的には難しいというふうに考えています 次にギッドアブーのデブオープスベストプラクチスの中でどのように ギッドアブー活用していくかっていうこれはまた別の視点でフローにした図であります 主にその計画からデプロイっていうところまでではあるんですけどまず左側の上流がですね計画のところではエピックやマイルソンというアジャレの概念を使って ポート効力プロジェクトのマネージメントをしていきます実際にはそれぞれの ストーリーユーザーストイレストかタスクっていうのは一周というもので技術していまいわゆるシケットでもあるんですけどその一周を使って それぞれ要件だったりユーザーストーリーを定義していきますその中で実装が必要なものはその一瞬に対してマージリクエストを作成することになりますマージリクエストを作成するとギッドのブランチも作成されて 基本的にはその後このブランチで起きる一連の開発の出来事はこのマージリクエストによって管理されています ソースコーの修正ですとか自動ビュード自動テストですとかあとはレビュー環境開発環境へのデプロイ こういった活動ですとかあとはセキュリティテスト自体もこのマージリクエストを試合の中で実施してしまうということが我が理想というふうに考えています その中いろんなテストだったり確認が通ったらレビューアーによるレビューが行われてサイン承認をもらってこのクリーンなマージリクエストを本流のブランチにマージしていくというような長いになっていますその後は本番環境ですとかステージン環境でのCD自動ビュードテストデプロイということがまた行われていくというようなこんなような流れになっていきます今回はここの左側のエピックマイストーンプロジェクト管理の部分ですね ここについて着目してご説明したいというふうに思いますまずその前にはこのリターブのいろんな要素についてご紹介させていただきます まずはグループについてご紹介しますグループはですね基本的にはそのポートフォリューとかプログラムというよ 呼ばれるような複数のプロジェクトを管理するためのオブジェクトです でまあ場合に言ったらその戦略的な計画ですとかまあ会社全体の統制それらを管理するためのレイヤーを提供しています グループにはエピックというものが所属していますこれはアジアル的な用語ではあるんですけどエピックには機能だったりえっと開発テーマまたはユーザーソーリー大きめなユーザーソーリー えっとユーザーソーリーを集約したものをエピックとして定義したいビジネスの戦略を定義したりすることが多いですエピックには複数の異種を紐付けることができますので まあエピックとエピックとあと異種を使ってこう改装的にこの大きなタスクを定義したりすることができますさらにロードマップというものはこのエピックを 時計的に可視化するための機能です一般的にはより長期的な計画ですね これをスケージュール化して可視化していくための機能ですさらにはプロジェクト中心にを中心に見ていきたいと思いますプロジェクトには チームがコラブレーションしたいですとか計画コーディングアプリケーションでればいろんなその実際の実活動を する基点になっていますまた他の言い方としてはリポジトリーというふうに ギットリポジトリーというふうに描いてもわかりやすいんじゃないかなというふうに思います1プロジェクトは1ギットリポジトリーがありますので まあそのギットリポジトリー周辺で起きることをプロジェクトとして管理するというふうな考え方もできます プロジェクトには一周を一周が所属してここには一般的にはユーザーストーリーバグですとかあとは要件ですねまあこれ引きの機能を含めての要件 あとはタスクというものを定義していきますさらにプロジェクトのマイルストーンというものもあります このマイルストーンというのはアジャイルで言うとマスクラムで言うといわゆるスプリント的なものでしてだいたいその 期間は期間を決めるんですけど1週間2週間1か月というようなケースが多い固定期間の計画だったりしますその固定期間の計画にはリリースを伴うリリースが可能な生活を伴うことが多いです具体的にこの画面を見ながらまあ一周が何か今までご紹介した 要素は何かということを見ていきたいと思いますで一周についてはまず上にこう まあ一周を一周を説明するタイトルがあってまあ下の方に具体的がこの一周の機質がありますこの例ですと具体的な提案があとキャプチャーコミでデザインとして含められていてまあ具体的にこういうこういう由来を作ってユーザーに価値を示すんだということを示していますあと一周にはその集約モードのエピックがありますので 集約モードのエピックを設定してあとどこのマエストに対応するかということも設定しますあとは下の方にウェイトというふうにありますけどこれはいわゆるストーリーポイントというところでそのこの一周のタスクとしての大きさを相対的に定義するものです一般的にはここはプロジェクトによってはフィボナッチ数列12358というような数列を使って相対的にこのタスクを定義して全体のスケジュールに反映していくというような使い方をしますエピック指定しました一周の下の方を見ていきますと まず関連する一周というところが出てきて場合によってはある一周がある一周に依存している依存しているというケースもここで定義でいきますあとは一周の先には開発が必要の場合にはマーディリクエストが必要でここが5つのマーディリクエストが反連付けられています下の方にはコメントや議論をするコメントなんていうものがありまして ここでこの一周に対してリスカッションすることを推奨していますメールでやり取りしてしまうと後で そのメールをもらってない人というのは後から背景っても分からなかったりしますのでできればすべて一周で議論を完結するというのは ギットアブ的な使い方になりますあとは次にエピックですねこれは一周を一周集約したものでより大きなタスクの定義ですね大きなユーザーそういうふうに言ってもいいかなというふうに思います 同様にタイトルや説明欄が一周のようにありますただ違いとしてはこう会支日期限というものがありますのでこの会支日と期限を使ってこの後ロードマップのところで可視化されるんですけど そのスケジュール管理っていうところにつながっていきますエピックは小エピックと一周によって改装化できますので具体的にはこのように小エピックの塊が上の方にあってさらにその小エピックこのレードは小エピックのうちの一つを構成する一周が下の方にいくつか並んでいるということで こういったwbs化がこのエピックによって実現することができます次に一周ボードのご紹介です 一周ボードはいろんな使い方があってこれはウェブベースの一周ボードができることではないですけど いろんな切り口で一周を見ることができますこの例ですとマイルストン別のリストっていうことで それぞれの縦の列がマイルストンですこれは実際にギッドラムの製品の一か月に一かにリリースするバージョンがそのままマイルストン名として定義されていて この一周はどこのマイルストンで対応するべきか今のスコープ的に外れるかどうかということを検討しながら日々調整していくための一周ボードですあとよくありますのはワークロー的な使い方ですね このワークローを実現するためにはラベルをまず作っていただきますそのラベル別に一周の一周ボードのリストを追加していって それぞれの一周がどのステージなのかテスト中なのか開発中なのかレビューが終わったかのかどうかというところを一目で分かるように可視化するための一周ボードです 次にロードマップですねこれは先ほどのエピックを主に可視化するためのビュアでありこの例ですとモバイラプリケーション対応のエピックがありまして その下に2つサブエピックがあってそれぞれの進捗が集約されて見えるかなというふうに思います あとは上の方にも上方にはマイストンも同時に出てきましてこの後ご紹介するマイストンというものもタイムボックスがあって このエピックに対してどういう選挙かというとこもこのロードマップ上で確認することができますマイストンはこのようなタイムボックスですね エピックとは違って一般的には繰り返しのタイムボックスにすることを置くギットラブ製品の場合は毎月1回の1回ずのタイムボックスとして定義していますこれは実際にギットラブの制御回数の例ではあるんですが あまりそのバンダウンチャートとしては例はよくはないんですけどこのマイストンが今回の 今回達成できそうができないかということは一目で分かるかなというふうに思いますここまでで一通りギットラブでアジャエル計画で出てくるような 登場人物をご紹介しましたので実際にデモに入っていきたいというふうに思いますその前にデモのシナリオを少し紹介します 今回スワーグショップの立ち上げノベーティーのショップですねこれを立ち上げて会社製品の宣伝効果を検証するということが目的としています目的効果の効果がどこまであるかということは分からないので一旦その最低限の機能だけウェブサイトとして実装して効果を測定したいというふうに思いますそれを2月までの目標でやっていきますあとは複数回損エピック一周先ほどご紹介したようなものを活用したいですとかスプイントマレーストンですねこれを活用してこれは2週間ごとに切って2週間ごとに今回は公開が2月末以降ですので内部的なリリースを2週間おきにやっていきたいというふうに考えていますいろんなそのエピック機能を実装しないといけない機能はあるんですけど今回は商品最低が一番怖いな商品注文機能についてのエピックについてそこを中心にアジャイルプランニングのデモを切っていきたいというふうに思います実際に今回デモするグループについてもご紹介しますまずあのスワーグショップという大元のグループが定義されていますこれがプロデフトその目標全体を計画するためのグループで実際にはエイシーサイトの立ち上げ用のグループがサブグループにあってあとはそうですねまずはウェブアプリケーションウェブサイトとしてまず公開しますのウェブサイトのプロジェクトがそのグループエイシーサイトのグループの下にあったりあと将来的にはモバイルアプリケーションも対応していくためのプロジェクトがあったりしますあとはインフラとしては今回パブリッククラウド使う予定ですのでそれ用のグループを作ってそのリソース別によりベースとGCPのプロジェクトを設定していますあとは前者的なところで言いますとコウホーマーケティングですねこれをここは別の部署が担当していってただ今回のそのエイシーサイトの公開と同時にプレイスリリースも出してもらわしすぎは言いますのでプレイスリリース用のプロジェクトも今回かかわって期待しますあとは今回エイシーサイトとは別にリアル店舗でもスワグショップを立ち上げるという計画にもなっているのでリアル店舗側のグループだったりそれの決済のための機能をプロジェクトとして定義しています実際にはまずロードマップこれは事前にエピックだったりマイレストンを定義してあるんですけどこのロードマップを見ていきたいと思います中心なこのエイシーサイト公開のためのMVPというエピックですねこれを2月までに対応していくつかの機能最低限の機能を実装していきますまず今回中心な商品注文機能ですねここをここに対していろいろアジャイルカーニングしていきますそれとは別にクレジットカードの決済機能がこれも別のサブエピックとして定義したいですとか先ほどのプレスリリースのところもこれは2月の公開前にプレスリリースしたいという考えですのでそのエピックもここで定義したりしていますスプイントはここにあるように5つ定義していますけど2月末までのスプイントとしてはスプイント3までに必要な機能を対応していく必要があります実際にはこのまず親のエピックを元にエピックを見ていきたいというふうに思いますエピックというのはビジネス的な戦略だったり大きなビジネス価値を定義するものですのでこんなようなビジネス価値を今回は製品の知名度を向上させるという目的で定義していますまたビジネスのゴールとしては今回は認知度が上がったかどうかという検証までを想定していますのでそこをゴールとして、このような機率例としてはこのような機率をしてエピックの定義をしていますまたECサイトの外観イメージです。ここもプロトタイプとして事前に作っておけば皆さん共通の認識でどういうものを作るかということを共有できたいですとかあとは場合にとはこういうワークフローです。のようなものをマックダウンで記載することによってこの後の検証ステップですね。次ステップの検証をどういうふうにやっていくかということを共有したりしています下の方には先ほどのECサイトのプレイスリリースのエピックに対するこれは一周が見えたりあとはクエジットカード、決済機能、これもまた別のエピックとしてエピックと一周を定義しています。今回はこの商品の注文機能についての一周がまだ立ち上げられていないので、ここについてファーニングをしていきたいというふうに考えています。そこの商品注文機能のエピックをクリックして立ち上げましたここではエピックの定義自体はやっていないんですけど実際にここに一周を追加していきたいと思います。ここの追加ボタンを使って新しい一周を追加するということで考えられそうなユーザー総理、サブ機能ということを追加していきます。実際に対応するのはこのWebというプロジェクトですので、全部このWebというプロジェクトに追加していきたいと思います。商品の一覧表示はもちろん必要で、一覧表示は個別の表示という画面も出てきますのでそこは別々の機能として一周を追加していきます。実際には商品カートに追加するのも購入をするためには必要な機能だと思いますので最低限に必要でしょうということで追加していきます。あとは商品の注文ですね。これも実際の注文処理カート追加した後に必要でしてあとは注文した場合にはお客さんにイメールが届く必要があると思いますのでそういったユーザー総理を追加してあと最後に管理者側ですね。他は全部ユーザー側のユーザー総理だったんですよ。管理者はその注文された一覧を見て実際に商品を送り必要があると思いますのでそういった機能もここで追加していきます。ここでこの商品注文機能に対して6つの一周が追加された状態になっています。この開始日記念では事前に設定しています。今回は3位これをマイルストーンに割り当てるために一周ボードを使って割り当てていきたいと思います。一旦ECサイトのグループに戻りまして先ほど割り当てたWebのプロジェクトに行ってそこの一周ボードを使っていきたいと思います。まず出て活用するのはマイルストーン別の一周ボードですね。これを使ってどのマイルストーンで対応するかというところを割り当てていきたいと思うんですけどその前にその一周ウェイトを設定してこれを基にそういったマイルストーンで入りそうかというところも検討しないといけないのでこれを設定して実際にはプロジェクトメンバーとの合意の下にウェイトというものは決まることは多いとは思うんですけど今回プロジェクトマネージャーとして全部どんどん過去の経験からつけていきたいと思います。エピクアはみんなこの商品注文機能というところに割り当てられていることがわかります。まずここの優先順位も基本的にこの商品一覧ですとか個別の表示ですとかあとカートを入れるとこまでも個別表示画面で出てきます。この辺りはエッスプイントの位置でやりたいというふうに取り決めたいします。その後の注文ですとか注文と同時のイメールはまた別のスプイントの二例対応して管理者系の機能はスプイントさん優先順位を少し下げてこういうようなプランニングをしたいというふうに思っています。さらには今マイルストーン別のプランニングをしたんですけどそれまでこのマイルストーンごとのプランニングもしていかないといけないと思いますのでスプイント1の異習暴動の秒に切り替えます。今回はこのケースではこれらのスプイント1ということは決まったんですけどそれぞれ誰が対応するかというところの取り決めもしていきたいと思います。ここでは私と他のデベロッパーレポーターという人がいて例えば私はこの一覧画面やりますということにしてこのカートについてはちょっと異習暴動が多いので別の人にしてこの個別表示もウェイトが5ということでいけそうだということで私に当てたりします。これでいろんな溜まったタスクを起表した異習というものをいろんな人に割り当てることがこの異習暴動で実現できたいします。次に私割り当てられた私自身としてどういうふうな動きをしていくかというとまた自分に割り当てられた異習暴動を今切り替えて例えばこれは実装したよということでツールドにしてこれは対応中またそれが進んでいくとレビューしたりですとか対応が終わったマジクエストを含めて開発が終わればクローズにするということが考えられます。こんなように異習暴動いろんなシチュエーションに合わせて活用していくということがかなり便利になるかの手に考えています。そこで先ほどエピックに戻っていきますとロードマップですねエピックが実際に1つクローズ一緒をクローズしたことによって20%の進捗が出ているそうウェイトに対する振動したウェイトが20%ということでこの進捗の更新というところも自動的にできるという利便性があるかと思いますあとマイストンのバンダウンチャートについては今この時点では何も表示されてないのでこれは別の例ではあるんですけどこんなようなイメージでプロジェストが進むとそれぞれ日が経過してクローズされる異習が出てきてこんなようなイメージでバンダウンチャートが進んでいくというイメージを見ていただけばというふうに思います。下にはまた異習ボードのようなものがいましてそれぞれの異習がどのステータ線があっていうことも確認できたりですとか合計の異習ウェイトがいくつだったりですとかもちろんスタート日期限というものはここに記載されています以上で確かのデモを終わりたいと思いますでは最後に今回はAzure PlanningというところだけではあったんですけどGitHubはGit RepositoryとかCIだけではなくプランニングだったりその後デプロイ全体のマネージメントもできますのでまた他のセミナーを見ていただいて興味を持っていただけばと思います皆さん今回ご参加ありがとうございました。本意味なのはかかってございましたでしょうか本日Azure PlanningについてAzureとはってこととGitHubの適用についてご紹介させていただきました来月はチームコラボレーションに関してキーエンジンの方も含めたGitHubの活用時で並びにチームメンバーの同時並行開発におけるGitHubの一部の流れをでも交えてご案内させていただく予定でございます来月へのWebinarへのご参加お待ちで申し上げますまた本読みなに関しまして本日アンケートの送信を予定しております大変お手伝いを伺って申し上げませんがアンケートやご回答にご協力いただけますと幸いでございますなお本日みなへのご質問またGitHub製品に関するご意見やお問い合わせなどございましたら現在表示させていただけるメダルですjpandabrsalesatmarkgitlab.comの方にお教えいただきますでしょうかそれではこれをもちましてGitHubのWebinarシリーズ第1回アジャイルプランニングを終了していただきます本日はご視聴ありがとうございました