【チーム開発】いよいよ始まるよ【80日目】
ここ１週間はnote更新をお休みしておりました。
なにをしていたのかというとアニメ見たりサッカーを見たりしていた（つまり遊んでいた）のですが、基本的に読書は毎日続けていました。
読み進めていたRails本を読了した後、DB設計絡みの本を読んでいたのですが、読み物としてだいぶ面白くないということもあって見て見ぬフリをしていました。。
さて、明日からは最後の山場であるチーム開発が始まるのですが、チームの皆さんの足を引っ張らないためにHTML,CSS,JavaScript,Ruby,Rails,DB,Gitあたりの基礎知識を中心に学習を進めてきました。
大枠は理解できたので、今後はインプットしてきた情報を課題制作を通じてアウトプットしていくことでより深い知識に落とし込んでいきたいと思います。
【学習内容】
・チーム開発前に知っておくべきこと
【チーム開発前に知っておくべきこと】
最終課題ではアジャイル開発という開発手法を、スクラムを用いて進めていきます。
多くの現場では上記の開発手法を導入しており、転職活動においても「チーム開発の経験」はとても大事な経験になります。
同時に「ポートフォリオとして技術力を証明するもの」、「見たこともないエラーなど困難に立ち向かう経験」も得ることができます。
○アジャイル開発とは
システム開発の進め方の１つで、「作りながら考えましょう」なやり方です。
あらかじめ工程、期限が明確に決められているウォーターフォール型とは異なり、作る→見てもらう→作り直す（繰り返し）のように柔軟に進めていく手法です。
よって、いっきにまとめて作業をするのではなく、少しずつ確認をはさみながら開発を進めていく流れになるので、関係者からの継続的なレビューを得ながら、計画を調整しつつ進めていきます。
○アジャイル開発のメリット
①できたものを実際に見ていろいろと判断ができる（とりあえず作って方向性が合ってたらOK）
②方向転換や軌道修正が比較的容易（でたとこ勝負な面もある）
③上手くやれば開発コストを減らせる（いらないものは作らない）
○アジャイル開発のデメリット
①工数が見積もりにくい
②上手くやらないと収拾がつかない（基本的にツギハギ）
③人員の入れ替えが大変
一概にウォーターフォール型が悪いというワケではなく、どちらも一長一短があります。
完璧な要件定義や工程を引けるのであれば、ウォーターフォール型の方が都合がよくなることもあります。
○最低限知っておくべきアジャイル開発のキーワード
・スプリント
1つの開発の周期のこと（今回の開発は1週間）
・スプリント計画ミーティング
各スプリントの初日に実施します。
内容は、当該スプリントでやることと、ゴールを設定し、チームで共有する場を指します。
・スプリントレビュー
各スプリントの終了日に実施します。
プロダクトオーナーや関係者にスプリントの成果をレビューしてもらう場です。
・スプリントレトロスペクティブ
「振り返り」のことです。
スプリントレビュー後、「スプリントのよかった点」「改善したい点」「次回のスプリントで挑戦すること」をチームで共有します。
○スクラム
一口にアジャイル開発といっても様々な種類があります。
その中で今回はスクラムと呼ばれる手法を採用します。
・スクラムとは
チームメンバー全員が主体性をもってプロダクト完成に向けた責任を持つことが特徴です。
リーダーやマネージャーがトップに立ってメンバーを引っ張る形ではなく組織的にはフラッとな状態で開発を進めていきます。
・スクラムのおおまかな流れ
（1）アプリケーションの要件定義
（2）開発の意図を、開発する人々が完全に把握する
（3）実装すべき作業を洗い出す
（4）作業の量を見積もる
（5）スプリントごとに実装する
（6）スプリントの成果を発表する
（7）振り返りを行う
当たり前といったら当たり前なのですが、これを忠実に守りながらチームで開発を進めていくことが求められます。
個人的には(2)の部分、「何を達成するためにそのプロダクトを作るのか」が重要だと思っています。
その理由は、作業を進めるモチベーションの根源になるからです。人間は合理的な生き物なので、理由のないものやモチベーションがわかないものに対して努力をすることはできません。
「プログラミングスクールの転職コースという場」で「チーム開発の経験を積む意味」を開発メンバー全員が理解していることが重要だと思います。
○スクラムの役割分担
・プロダクトオーナー：プロダクトバックログの管理責任者
プロダクトの結果責任を負う立場の人間です。開発チームを活用して、プロダクトの価値を最大化することが求められます。最終決断権を持つのはプロダクトオーナーです。
・スクラムマスター：スクラムの調整役
スクラムが上手くいくようにサポートし、人間関係を円滑にする役目を持ちます。
「課長」のような存在ではなく、「世話役」のようなポジションです。
・開発チームメンバー：実際に開発に携わる
日々開発計画について話し合い、計画に沿ってプロダクトを作っていくメンバーです。
メンバー間に上下関係はなくチーム内での仕事の進め方はメンバー同士で決めます。
○スクラムを用いたアジャイル開発
スクラムチームが組まれてから、開発が終了するまでの流れを確認します。
①要件とゴールの確認
全員で集まり、プロダクトオーナーから「何を作るのか」、「作ることで達成したいことは何か」の説明を受けます。
②作業を洗い出してリストを作成する
プロダクトが完成するまでに必要な工程(要件定義、実装、テスト、公開など)すべてを洗い出し、ひとつのリストにまとめます。これをプロダクトバックログと呼びます。
スクラムの考え方を用いてプロダクトを作成するメンバーは、基本的にはこのプロダクトバックログの中から作業を分担し、遂行していきます。
○開発開始から終了までのサイクル
ゴールやミッションを確認し、やるべきことを一通り洗い出したら、スプリント単位で期間を区切り、開発を進めます。
・スプリント計画ミーティング
当該スプリントで開発する内容を、プロダクトバックログから選別します。
選別してきた作業は、具体的なタスクに分割し、スプリントバックログというリストにまとめ、当該スプリントでのToDoを決定します。
プロダクトバックログからスプリントバックログに移行した際は、以下の様にタスクの細分化をしてから取り掛かります。
#プロダクトバックログ
- Pictweetのユーザーログイン機能を作成する
↓
#スプリントバックログ
- ユーザーテーブルを作成する
- ユーザーログインボタンを画面に表示する
- ユーザーが登録されるまでの処理を書く..など
各タスクには予め担当者を決めるということをしません。
実際に作業をする時に、開発メンバーがスプリントバックログの項目を選択するようにします。
○チーム開発におけるマインド面で意識すべき点について
①メンターに頼り過ぎないようにする
チームメンバーのみで難易度の高い実装に挑戦するにあたり、重要なのが自ら必要な情報を調べ自ら実装を行うという姿勢です。チームの課題はチームで解決する癖をつけていきます。
②論点を明確にした質問をする
一定の時間は自分で調べて、それでも解決できなかったらまずはメンバーに相談するようにします。
質問フォーマットを用いて論点を明確にし、何を解決したいのかを前提として伝えてから相談するようにします。
③チームとして開発に取り組むための仕組みづくりをする
「土曜日は10時に来校し、11時までにデイリースクラムを終えて、それ以外にも1日2～3回アウトプットの時間を設ける」など明確なルールがないと簡単にチームは崩壊します。
スクラムにおいては各々の主体性が求められる一方で、主体性を発揮できるような空間づくりも重要です。
最終的に何を目指して開発を行うのか、そのために何をすべきで、何をすべきではないのか、その点を考えながら各々がチームマネジメントを考えます。
○スクラムマスター
スクラムを調整するスクラムマスターの仕事は、通常の開発に加えて、チームの俯瞰と開発メンバーの関係調整です。
スクラムはチーム全員の主体性が求められますが、特に全体のバランスを見極めることがスクラムマスターに求められます。
スクラムマスターは。感情に左右されず、常に冷静かつ客観的な判断ができる方が適任です（技術力は重視しない）。
○チームでのルールと方針を決める
チーム開発の本来の目的を達成するためには下記の3点は必ず実行しなければいけません。
①ポートフォリオ作成のために十分な開発時間を確保すること
②有意義な開発の時間とするために、良質なチーム開発体制を築くこと
③各々が主体的に開発して、技術的な成長をすること
①～③を達成するためにはルールや方針が必要です。
スクラムマスターは上記を決定するための話し合いの音頭をとっていく必要があります。
話し合い結果の例としてはこのようなものがあります。
・1日に3回は進捗を報告する機会を設けること
・9:30までに集合し、遅刻等の場合は必ず連絡をすること
・メンバーに技術的な相談をするときは、必ず質問フォーマットにまとめてから相談すること
○タスク管理ツール「Trello(トレロ)」でプロダクトバックログを管理する
Trello(トレロ)はタスク管理ツールです。
掲示板のような「ボード」と呼ばれるものの中に「リスト」という単位で各タスクを収納することができ、各タスクはリスト間を簡単に移動させることができます。
アジャイル開発のタスクの管理をすることが可能です
スクラムマスターは、テックエキスパートが用意したTrelloのボードをコピーし、メンバーを招待する形でToDo管理を行っていきます。
○メンバー間でアプリの雛形を共有する
代表者1名がrails newをして新規アプリケーションを立ち上げます。
代表者は作成したアプリケーションの雛形をリモートリポジトリにpushし、メンバーはそれをgit cloneします。
Githubとslackを連携させ、最終課題に関するレビューの通知を受け取れるようにしておきます。
○作業見積り・優勢順位の決定
作業見積りについては、あえて直接の時間で考えず、皆で共通認識として持てるタスクをイメージし、それにかかる作業量を1単位とします。
（例：pictweetの編集機能にかかった時間の共通認識→「3」とするとか）
その後、プロダクトバックログの各項目について見積りを行い、優先順位順に並びかえる
○開発に取り掛かる
スプリント計画ミーティングの実施
プロダクトバックログを作った際に見積もった作業を1スプリント分だけ抜き出し、具体的にどれくらい時間がかかるかを見積もること、そしてそれぞれの作業は何をもって完了とするかを合意することが目的です。
①Trelloのプロダクトバックログのボードの「Todo」の中から、今回のスプリントで終えて欲しい項目を「プロダクトバックログ」から「Todo」抜き出して発表します。
②それぞれの項目の「完了の定義」を決めます。
③開発チームで、項目ごとに完了に向けて必要な作業を洗い出します。挙げた作業は、各項目のカードにチェックリストを作成し、そこに「作業内容 時間」というフォーマットで書き込んでいきます。
○デイリースクラムの実施
スプリントでやると決めた範囲が本当に終わるかを精査することであり、進捗の報告ではありません。
前回のデイリースクラムで予想した自身が終えているであろう作業と、その結果のズレを発見することで、問題を発見しやすくなります。
内容としては、「前回のデイリースクラムからやっていたこと」、「次回のデイリースクラムまでにやること」、「問題点」、「自分が取り掛かっているタスクは「完了の定義」を満たせそうか？」などです。
○スプリントレビューの実施
スプリントレビューは、スプリント計画ミーティングで決めた各項目カードの「完了の定義」を確認する会です。
完了の定義で決めた動作などを、ひとつひとつ確認していきます。
プロダクトオーナーが確認して、OKがでれば完了、NGだった場合は、次回のスプリントに持ち越します。
○スプリントレトロスペクティブ
スプリントレビュー後は、目安30分で振り返りを行います。
「今週のよかった点」「改善したい点」「次回のスプリントで挑戦すること」の3項目を話し合いまとめ、以下のようにチームのSlackのチャンネルに投稿します。
ここまでがアジャイル開発のおおまかな流れになります。
【所感】
正直、僕はとても自分に甘いので、ToDo管理は苦手な部分です。
Jobに関して興味があり自発的に動きたい！と思えるような環境であればとてつもないエネルギーを発揮できるのですが、興味のないことを「○日までに△△と□□をやれ！と言われるとやる気をなくします。（社会人としてどうなの）
会社の仕事の9割5分は興味のない仕事なので、基本的にやる気は満ち溢れず6割程度の力で日々過ごしています。はい。
ただ、今回のカリキュラム（メルカリ開発）は興味のある分野が多々あるので、積極的に取り組んでいきたいと思います。
できればスクラムマスターも務めたいのですが、そこはメンバーと調整の上決定するので、なんともいえません。決定したら報告します。
（スクラムマスターになって音頭をとる側に回らないと、他人任せになってだらけてしまいそう。それを防ぐためのアジャイル開発なんですけどね。）
この記事が気に入ったらサポートをしてみませんか？