Contenu connexe Similaire à 第３回enPiTシンポジウムBizApp分野代表発表 Similaire à 第３回enPiTシンポジウムBizApp分野代表発表 (20) 14. 月 火 水 金木 土
計画し
日土
実際のスプリント
14
15. 月 火 水 金木 土
毎日
確認しながら
日土
計画し
実際のスプリント
15
16. 月 火 水 金木 土
毎日
確認しながら
作って
日土
計画し
実際のスプリント
16
17. 月 火 水 金木 土
毎日
確認しながら
作って
できたものを
レビューして
日土
計画し
実際のスプリント
17
19. 月 火 水 金木 土
毎日
確認しながら
作って
できたものを
レビューして
やり方を
レビューする
日土
計画し
実際のスプリント
19
20. 14
月 火 水 金木 土
毎日
確認しながら
作って
できたものを
レビューして
やり方を
レビューする
日土
1.5h × 4コマ × 11週 × 3人 = 198人
実際のスプリント
計画し
20
50. • 指導者
• 管理者 わたしわたし！
• 支援者 ゴトウさん
• 伝道者
• 意思決定者 わたしわたし！
50
51. • 指導者 コーチ陣？
• 管理者 わたしわたし！
• 支援者 ゴトウさん
• 伝道者 不在
• 意思決定者 わたしわたし！
開発に徹す
51
72. 参考
• 『SCRUM BOOTCAMP THE BOOK』
– 2013 西村直人、永瀬美穂、吉羽龍太郎著
• アジャイル開発手法特論講義資料
– 2014 永瀬美穂
• 2014 Qcon LT資料
– http://www.slideshare.net/MihoNagase/enpit-
bizappaiitqcontokyo2014
– 2014 永瀬美穂
72
Notes de l'éditeur 本日お話する内容はこのようになっています。まず、わたしたちが講義で何を学んだか、次に講義で学んだことをどう実践したか、そしてまとめに入ります。
この発表では私のチームのプロセスやプロダクトについて、私の個人的な所感を交えながらお話します。
わたくしは竹葉と申します。SCSK株式会社というIT企業で、研究開発をしております。enPiTには業務としてではなく、自己研鑽で参加しました。
それではまず、この半年間のenPiTの学習スケジュールからお話します。
学習スケジュールはこんなカンジです。６〜８月は事前学習としてアジャイル開発手法特論を勉強しました。土曜日に２コマ、３時間の講義を受講しました。その後に９月末に１週間の短期合宿を受けました。
合宿といっても泊まりではなくて、昼一から夜までのスケジュールです。
私の場合は朝に仕事行って、午前中が終わったらすぐ大学に向かって、昼からRuby On Rails、Github、TravisCIといった技術系の演習を受けて、夜はえらい人のお話を聞いて、帰って寝て次の日また仕事、というようなカンジです。正直、みっちりで結構キツかったです。
そしていよいよ分散PBLが始まります。
ということで知識の実践について、分散PBLで開発したアプリケーションの紹介と、プロセスの紹介をします。
その前にスクラム開発について少し触れます。スクラム開発について知らない方？？
ごく抜粋するとこんな特徴があるんですが、ここに書いてある用語とか、スクラム開発とかわからなくても大丈夫です。ちょっとだけ触れます。
スクラム開発は透明性、検査、適応がキーワードになっていて、作業を見える化して、問題を小さいうちに発見して摘んで、この調子で進んでって大丈夫そうか確認して、方向転換を柔軟に行っていきます。
作業の計画、開発、振り返りを１つのサイクルとして、このサイクルを回すごとにアプリケーションもチームも成長させていきます。
チームには役割を持つ人がいます。
アプリケーションについて考えるプロダクトオーナーと、チームを上手く進めるスクラムマスター、それからアプリケーションを開発する開発チームです。
このスプリントと呼ばれる一定の期間、この例では２週間のサイクルを繰り返し、デモで受けたレビューをアプリケーションに反映させて価値を上げていきます。自分たちの進め方についても良い点、悪い点を洗い出して改善していきます。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
実際には私たちは１週間スプリントで開発していました。開発に充てられたのは週４コマ分です。まず計画して、月曜に２コマ分作業して、水曜日に２コマ分作業していました。もちろん仕事があるので、仕事終わって18:30に集合して、21:30解散というスケジュールで動いてました。そして土曜日にコーチや他の受講生に対してデモを行って、その後にその１週間を振り返って良い点や悪い点について話し合います。１週間あるように見えるんですが、活動したのは土、月、水のみです。１コマが1.5hで、週4コマ、それを11週で3人だったので約198人時のプロジェクトとなります。
会社で毎日このプロジェクトに取り組んでいたとすると大体2週間くらいの換算になります。
社会人だからこそ教科書通りにやるのって難しいし、挑戦しがいがあります。特にタイムボックス厳守！残業しないっていうのって、仕事やりきりたくなっちゃうし、上司の目もあるし、かなり難しいと思います。
後藤さんと遠藤さんは業務とは違う分野の技術を勉強したいという目的があったので、それを実践できるようにしようという方針で始めました。
そんな３人が開発したプロダクトについてご紹介します。
その名もあいまいランチ！早速デモをお見せします。
最初はランチに迷う人向けで、単純に和食食べたいとか場所選ぶようなアプリだったんですが、真面目にスクラムやってるチームがふざけたもの作ったら面白いんじゃないかっていうので、男性のタイプを選んで、その趣向からランチのお店を進めるというアプリに仕上げました。
最初はランチ迷っている人に対して有無を言わさず二郎をオススメするというとんでもないアプリでした。
それにスタートページが付いたり
最終的にはこんな素敵なUIになりました。
ここからは11週間、どんな風なプロセスを経てきたかをご紹介します。
５週目くらいまでは色々ありながらも浮き沈みを繰り返しながら進めてきました。
半分を過ぎたあたりでいくつか挑戦してみたことがあります。その１つがこれです。
ただ際限なく作業してしまうし、バグも増えてくるので、予想よりも進捗は良くなかったです。ただ、わからないことがあったときに心置きなく調べられるのは良かったです。
もう１つ、得意分野をやってみることにも挑戦しました。フロントエンジニアである後藤さんに画面を担当していただき、内部実装を業務で行っている遠藤さんに内部実装をお願いしました。
これで劇的に生産性が上がったんです！なんてうまくいきません。が、ちょっとは上がりました。
問題は自分が１番得意なので、誰にも相談できずに抱え込んでしまうということです。
挑戦してみて開発の調子は上がったり下がったりでした。もくもくと開発に取り組みすぎて、開発者が３人集まっているだけでチームっぽくなくなってしまったり、もうenPiT終了が見え始めて寂しさからモチベーションが下がってしまうこともありました。
ただ、アプリケーションは確実に成長を重ねてこれました。
画面だけでもガラっと変わるのがわかると思います。どんどん使う気になるようなアプリになっていますよね？
自分たちの納得いくマイルストーンまで到達できました。最後の方は業務も忙しかったり、３人全員で集まれる日も少なかったのですが、笑顔で終わることができました。
11週のチームの活動を振り返ってみて、良かったことがあります。
わたしたち３人はもちろん性格も業務内容もバラバラなのですが、そのおかげかとても良いバランスでノウハウ共有できたと思います。
また、ユーザが求めるアプリケーションに成長させるにはユーザのフィードバックが非常に重要となります。開発者視点で凝り固まって、錯綜しそうになっても、このフィードバックで舵を切ってこれました。
スクラム開発や、勉強したいことや、失敗失敗失敗しながら、会社や１人だけでは挑戦しにくいことにも挑戦できました。
ここでユーザフィードバックがどんな方向転換ができたかをご紹介します。
ページから見切れていた「運命で決める」が人気ということがわかり、１番選びやすいところに置きました。
また、最終的なオススメ店舗を10個挙げていたのですが、ランチで迷ってるのに更に迷ってしまうという声があり、１店舗のみオススメするスタイルに変えました。
また、スクラムマスターを務めた私が、自信の振る舞いを振り返ってみて１つ、気付いたことがあります。
誰がスクラムマスターだったのかという話です。というのも、私はスクラムマスターに向いてないと感じたからです。
が、私が思うにスクラムマスターは後藤さんだったんじゃないかと思っています。プロダクトオーナーは後藤さん１人ではなくて、まあ開発も３人でしているし、３人でアプリケーションについて色々考えていました。
みなさんご存知ですか？リーダー的なものにはこんな要素があるみたいです。
この中で私がやってたのは管理者と意思決定者です。計画とか進捗の管理、ファシリテーションや最終的な議論の進む方向は私が決めていました。チームに規律はもたらせましたし、それで上手くいっていたこともあったと思っています。
けどスクラムマスターには、チームを和ませたりメンバーを励ますとか、この支援者でいることが重要だと思ってます。それを上手くできていたのは後藤さんだと思います。
指導者や技術とか進め方の指導する人なので、コーチ陣、伝道者はゴールを明確にして俺に付いてこい的な人なので、不在として、また遠藤さんは開発に徹していたとして、こんな役割だったかなと思います。
けどこうしてみると、支援者だけでもチームは成り立ちません。私がいなかったらチーム崩壊してるなという面もあります。
教科書ではスクラムマスターは１人しかいないように見えましたが、別に１人である必要はなくて、メンバーで補完し合っていられるなら特にスクラムマスターとか役割にこだわる必要はないのかなということに気付けました。
総じて、このenPiT全体で得たことをカードにしてまとめてみます。
最後に私の個人的なまとめをさせていただきます。
まず、教科書通りに色んなイベントやルールに従ってきましたが、暗黙的に従うだけではだめだとわかりました。
例えばテスト。技術的にテストの書き方がわからなくて、見た目ではちゃんと動いているのに、テストが書き終わらなくてスプリント完了できないということが多々ありました。じゃあテストって書く意味あるの？そこは優先度下げて、目視のテストを充実させるのでいいんじゃない？という風に切り替えることができました。
また、３人で議論していると「なんでこの人わかってくれないの」ってことがありました。でも、「私の言い方がもしかして悪かったんじゃないか？」と、自分の中に原因を探せるようになりました。
また、人の手を動かすには感情を動かすことが大切で、ただこれやってください、って言うんじゃなくて、こういう理由で困ってて、これやってくれると助かるんです、とか、これするとあなたにこんないいことありますよ、っていうとみんなハッピーになれるんです。
それから、大学とか会社とか、いつも同じ場所に同じ時間にみんなと集まれるってすごく貴重なんですよ。ねえってすぐ話しかけられて、うん、ってすぐに返事してくれる環境って、これだけですごい効率化なんです。
ここには語りきれない多くの学びがenPiTにはありました。本当に参加してよかったです。
吉岡さん、永瀬さん、中鉢先生、事務局の方々
今日わたしが発表の機会をいただけるのも事務局の方や、資料のレビューをしてくださった永瀬先生や中鉢先生や、色んな方の協力のおかげです。色んな人に支えられてるっていうことは本当にありがたいです。
