コロナに負けないリモートスクラム開発のノウハウ

コロナに負けない リモートスクラム開発のノウハウ JANOG46 Meeting 資料 2020/8/28 佐々木 健

はじめに ● 本日は東京から参加です ● 沖縄に行きたかったけど残念 ● でもコロナに負けずに素晴しいJANOG46を新しい 形で実現してくれたホスト、スポンサー、スタッフ に感謝!!!!!!

注意事項とお願い ● ネットワークの話も、技術っぽい話もしません ● そういうのがお好きな人は裏番組がお勧め ● 本セッションはゆるふわに喋ります ● ● リモートから喋ると聞いている人の顔が見えないの で、さみしい気分になってきます 適当にいろいろな方法で つっこみを入れてくださいませ 適当に拾っていきます

自己紹介 2018/8〜 2019/10頃まで無職 長い夏休み!! イベントの裏方してたり おっさんレンタルされたり バイオリン弾いたり 夏のアルバイトをしたり スクラムマスターやったよ →本日の話

アジェンダ ● スクラム開発についての説明 ● リモートスクラム開発の実際 ● ● ツールの選択 ● 仕事の進め方 ● スプリントレビューでやること 質疑応答 Wikimedia: Ajanta_caves_panorama_2010 (CC BY-SA 4.0)

スクラム開発って何？ ● Wikipediaより↓ スクラム（英: Scrum）は、ソフトウェア開発におけ る反復的で漸進的なアジャイルソフトウェア開発手 法の1つである。....(とても長い説明が続く).... Wikimedia: ST_vs_Gloucester-Match-23 (CC BY-SA 3.0)

• https://ja.wikipedia.org/wiki/スクラム_(ソフトウェア開発)

ウォーターフォールじゃダメなの？ ● 歴史と伝統!!! ● みんな知ってる安心安全!!! ● すぐに使えるツールも沢山!!! ● 役割分担、作業分担も明確!!!

ウォーターフォールじゃ駄目なの？

ウォーターフォールは なぜうまくいかないことが多いか？ ● 不確実なことに弱い ● 予想外のことがおきたときに全体に影響が出てしまう ● ● リスク対応のためにあらかじめ余裕を持たせたりするのが王道だ けどそれはコストにはねかえってくる 変化に弱い ● 顧客要望の変化、社会的な環境変化、等があると全体的 に手戻りが発生する ● 手戻りしたときには担当メンバーは離脱してたり

じゃあどうする？ ● 予測と測定を繰り返して不確実性を減らす ● 変化はするもの、と許容して対応できるようにする スクラム開発

スクラム開発開始のハードル ● 知らない単語が沢山あってこわい ● 役割分担が良くわからない ● メリットが説明できない ● やらない理由を探すのは簡単 ● コストが増える ● スクラム開発プロセスを動かすためのコスト ● スクラムマスターのコスト ● 教育コスト ● 顧客や関係者への説明が大変 ● やったことがない ● SIerが対応してくれない

それでもスクラム開発やろうぜ!! ● 変化しなきゃ死んじゃうよ!!! ● とりあえずやってみればなんとかなるよ

こんな風に説明すれば良い？ ● ● ● ● ● ワールドスタンダードなやり方は取り入れる一手 ベストプラクティス(良い型)の集合なので、取り入 れることによっていろいろなメリットがあるよ チームが強くなるよ リスクマージンが減らせたり、手戻りも減ったりする ので最終的にコストは下がるはず 新しいことをするのは楽しいよ

スクラム開発の良いところ(用語解説1) ● ● プロダクトバックログ ● 最終成果物を書いておくところ ● 最終成果物が何なのかを全員で常に共有 ● 定期的に進捗確認をすることで達成度を全員で共有 ● 最終成果物の追加変更も柔軟にできる スプリントバックログ ● 今の期間(スプリント)にやることを書いておくところ ● 今のタイミングでやるべきことを全員で共有できる ● 今誰が何をやっているかがすぐわかる

スクラム開発の良いところ(用語解説2) ● ストーリーポイント ● ● ● あるタスクにどのぐらいの工数がかかるかをみんなで見積る 想定工数は人によって違うけど、お互いの認識をすり合わせていくその違いに て合わせていくことでタスクの内容についての意識合わせもできる ● 作業の全体量が把握できるので無茶な計画を防ぐことができる ● チームとして作業できる工数量を把握することができる スプリント ● 決められた期間毎に開発活動を行なう ● スプリントの最後にレビューとふり返りを実施する ● 期間毎にチームの成長が実感できる ● 期間毎に新しいことにチャレンジをしたりメリハリがつけやすい

スクラム開発の良いところ(用語解説3) ● インセプションデッキ ● ● ● プロジェクトの目的やゴール等を明確化するためのドキュ メント これを書くことでチームメンバーの意識を合わせることが できる 無駄な作業や方向性のずれを防ぐことができる

(参考)お勧めの本 ● SCRUM BOOT CAMP THE BOOK ● https://amzn.to/2EKlq23 ● 漫画入り ● サクっと読める ● 最近新版が出た

• https://amzn.to/2EKlq23

スクラム開発についての 概要説明はここまで ここからは 実際にやったことを話すよ

どこでスクラム開発をしてたか？ ● 「Fog World Congress 2018」でのフォグコンピュー ティングの日中台相互接続デモシステムの開発 ● ● Fogコンピューティングテストベッドの構築 ● ● https://www.sakura.ad.jp/information/pressreleases /2018/10/01/1968198098/ https://research.sakura.ad.jp/wp-content/uploads/2 019/08/dicomo2019-s-kikuchi.pdf JPNIC roamon project ● https://upload.apnic.net/uploads/apricot2020-roam on-08_1581988484.pdf

• https://upload.apnic.net/uploads/apricot2020-roamon-08_1581988484.pdf
• https://www.sakura.ad.jp/information/pressreleases/2018/10/01/1968198098/
• https://research.sakura.ad.jp/wp-content/uploads/2019/08/dicomo2019-s-kikuchi.pdf

プロジェクトの共通点(Good) ● 決済者が明確 ● プロジェクトメンバーの中に決済者がいる ● 期間(締切)は決まっている

プロジェクトの共通点(Bad) ● 作るものが曖昧 ● メンバーがお互いを良く知らない ● 全員リモート作業 ● 全員フルコミットじゃなく、隙間時間に作業

Badポイントへの対応策1 ● ● 作るものが曖昧 ● →インセプションデッキで意識合わせ ● →プロダクトバックログで作るものを明確化 メンバーがお互いを良く知らない ● →SNSで繋る ● →チャットでコミュニケーション ● →ストーリーポイントにおけるコミュニケーションによりお互いの得 意分野が見えてくる

Badポイントへの対応策2 ● 全員リモート作業 ● →共同作業できるようなツールを揃える ● ● 使ったツールは後で説明するよ 全員フルコミットじゃなく、隙間時間に作業 ● ● ● →朝会(デイリー・スクラム)はやらない →非同期に作業を進められるようにチャットベースでコミュニケー ション →スプリントレビューだけは時間を決めて集まって実施

目的 利用したツール ツール名 コメント 開発リポジトリ 成果物置き場 GitHub 一番メジャーだと思うので特別な理由がな ければこれ一択かと。 カンバン スクラムボード Trello スクラム用のツールは他にも沢山ある。 Trelloはスクラム用にはいまいちと言われ ているけど、わりとメジャーなツールだ し、わかりやすい。 メッセージのやりとり 各種通知用 Slack 一番メジャー。 チャンネルを沢山作れたり、webhookが利 用できたり、やっぱり便利。 情報整理 コミュニケーション等 Kibela Wiki的なツールは手軽に情報を整理するの にやっぱり便利。 ツールは沢山あるけどKibelaはマークダウ ンで書けるのが嬉しい。 リモート会議用 appear.in WebEx 今ならZoomを使うかなあ。 もしくはTeamsとかMeetとか

最初にやること1 ● ツールの準備、アカウント発行 ● インセプションデッキ作成 ● ● ● プロジェクトの意識合わせを最初にする プロジェクトの手引き作成 ● 使うツールの一覧、使い方 ● スクラム開発についての簡単な説明 キックオフミーティング ● 上で作ったものを説明

最初にやること2 ● プロダクトバックログ作成 ● ● 最初のスプリントバックログ作成 ● ● 雛形は誰かが雑に作って、みんなで確認しながら肉付けしていく 最初の期間にやることをタスクカードとして書き出す ストーリーポイント(見積り) ● タスクカードに見積り工数を付けていく ここまでやればスプリントが開始できる!!

Trelloを使う前の環境準備 ● ストーリーポイントのためのブラウザ拡張は各自入 れとく ● ● Scrum for Trello (Chrome版もFirefox版もある) TrelloのPower-upとしてSlackとの連携を設定する ● ● ● 通知をSlackに飛ばすだけでもわりと便利 全部飛ばすとうるさいので、カードの作成、移動、を通知するぐ らいで良い 無料版だとPower-upが1つしか使えないのがちょっとキビシイ

Trelloのリスト配置 プロダクト バックログ スプリント バックログ 着手 作業中 レビュー 待ち スプリント XX完了分 過去のスプリント 完了分 …

Trelloのリストの使い方 リスト名 プロダクト バックログ どんな用途で使うか ● ● ● ● スプリント バックログ ● ● 着手、作業中 ● レビュー待ち ● ● スプリントxx 完了分 過去のスプリント 完了分 最終的に完成させる成果物のリスト 作業はすべてここに書いてあるプロダクトを完成させるため に行なわれる 上に書かれているもののほうが優先度は高め。 スプリントレビューの際に、毎回それぞれのプロダクトがど の程度完成に近付いているかチェックを行なう 今のスプリントでやるべき作業単位に書き出したもの 上に書かれているもののほうが優先度は高め。 作業に着手したカードを置いておく場所 作業が終わったらここにカードを移動させる スプリントレビューの際に、作業内容を確認(レビュー)する カードの作成、 移動のタイミング ● ● ● ● ● ● 該当するスプリントで終わったカードを置く記録場所 ● ● 過去のスプリントの記録を残す場所 ● 最初に作成する カードは固定、ずっと移動 はしない スプリントレビュー時に次 回やることを追記する 作業時に担当者が移動 作業終了時に担当者が移 動 スプリントレビュー時にレ ビュー待ちからここに移動 させる 記録用なので移動しない

カードの記述の仕方 ● 詳細説明は、誰が読んでも内容がわかるように書くこと ● ● ● コンテキストをちゃんと書いて、ストーリーとして読めるようにする チェックリストを記述する ● 完了条件を明確にする ● クローズできる条件を書いておく 対応するプロダクトバックログがわかるようにラベルを付ける ● 対応するものがプロダクトバックログがなければプロダクトバックログを見直す ● 作業を行なう人をメンバーとしてアサインする ● ストーリーポイントはスプリント開始時にみんなで行なう ● 作業の記録はコメントとして残しておく

作業の進め方 ● 作業に着手した場合はカードは「着手済み」に移動する ● 作業が終わったら「レビュー待ち」に移動する ● ● ● その際に実績値を感覚で入力する スプリントレビューのタイミングで「レビュー済み」のカードをレビューし、問 題がなかったら「スプリントxx完了分」に移動させる スプリントレビューの最後に、新しいスプリントバックログを作成する ● ● ● とりあえずタイトルだけ書くぐらいのラフな感じで タイトルだけでもストーリーポイントは可能なのでストーリーポイントも付け る チェックリスト等の詳細な内容は後で追記しても良い

スプリントレビューの方針 ● ● スプリントの最後に実施する ● だいたいスプリントは2週間ぐらいが楽 ● 決まった時間にやる感じでスケジュールを組む 1時間で終わらせたい ● アジェンダに沿ってサクサク進める

スプリントレビューのアジェンダ1 ● レビュー(20分) ● Trelloのカードを確認 ● ● ● レビュー待ちのものを完了に持っていく ● 判断はプロダクトオーナーが行なう ● 記載漏れがあればその場で追記 ● 工数が書いてなければそこも記載する 作業中のものについても内容を確認する カードになってないけどやった作業があればそれもその場でカード 化する

スプリントレビューのアジェンダ2 ● ふり返り(20分) ● 今回のスプリントでうまくいったことは何か？ ● 問題や課題になったこと ● 改善したほうが良いこと ● 次のスプリントでトライしたいこと ● プロダクトバックログの見直し ● Trelloのバックログを確認 ● チェックリストを付けながら最終成果物の達成状況をみんなで共有する

スプリントレビューのアジェンダ3 ● 次のスプリントの計画(10分) ● 新しくやることを追加 ● ● スプリントバックログを作成 ● カードを追加していく ● できれば説明、チェックリストも記述したいけど、時間がなければ後日でも良い ストーリーポイント ● 新しいカードについて見積もっていく ● 見積もり修正が必要なカードがあれば見積を修正する ● ● 誰かが、これ修正したほうが良いんじゃない？、と言ったら検討する 工数が大きすぎるカードがあったら適切に分割する

スプリントレビューのアジェンダ4 ● その他連絡事項等 ● なにか共有したほうが良いことがあれば共有 ● 次回のミーティングの予定は念のため共有しとく

トライしたいこと、について ● ● スプリントレビュー時にチームが良くなるようなことを考えて やってみる取り組み たとえばこんなのはやってみた ● 自己紹介を書いてみよう ● 雑談チャンネルに積極的に書きこもう ● くだらない話を雑談チャンネルに書こう ● 朝起きたら、おはよう、とチャンネルに書こう ● 各人が時報チャンネルを作って作業メモを書いていこう ● 今日の気分をチャンネルに書こう ● 良かったことを共有しよう

なんか難しそう？？ ● ● ● 「型」としてベストプラクティスが定義されてるだけ 効率良く仕事できるようになるのでリモートワークと 相性はとても良いよ スプリントを1、2周してみるとすぐに身につくよ

やってみた感想 ● ● スクラム開発手法を使って、ほぼリモートメンバー だけで3プロジェクトを回してみたけど、それなり に上手く回ったよ なかなか良いのでみんなもやろう

質疑応答の時間

別の場所で聞かれたこと ● スクラムはミーティングが多くなってしまってその 分工数が増えてしまう弊害があるのでは？ ● ● →ミーティングが必要なら、ミーティングをするというカードを 作って内容を可視化するのがお勧め。カード化することでミー ティングの工数も明確化されるし、ミーティングのゴールも明確 になるよ。 開発したものをテストする環境等はどう作ったか？ ● →Dockerを使って、各人が自分の手元で開発とテストを完結で きるようにした。Docker便利。たまたまDockerが使いやすい規 模の仕事だったのは正直ラッキーだった。