とあるサイダスの開発チーム 第１弾

はじめまして

エンジニアをやっている 勇大(id:yudy0115)と言います。 2018 年春から転勤で沖縄にやってきました。 数年で東京に戻る予定でしたが、あまりにも住みやすく、移住を決意したしだいです。

第１弾として・・・

まず第１弾として、プロローグ的な意味も含めまして、どうして書いていこうかと思ったのか、 どういったことを書いていくのか、を紹介したいと思います。

私のいるチームはスクラムで、2019 年からは基本ずっとモブプロでやっています。

まだまだ勉強中で、日々試行錯誤しています。

普段の取り組みや、悩み、うまくいったことなど、その過程を記事にできたらおもしろいなと思い、記事にしてみました。

サイダスの開発風景と言いますか、雰囲気を紹介できたらいいなと思っています。

※ 普段はこんな感じで常に zoom を使ってリモートで開発してます。念の為モザイクをかけたらほぼモザイクという・・・

zoom でリモート開発

さっそく、昨年末でのふりかえり内容

ほんと唐突ではありますが、昨年末にその時のチーム内で行ったふりかえりの内容が以下の通りです。

• 納期と時間の意識がついた。
• あまりいいものができていないと感じた（もともと予定してたベータ版のリリースも遅れた）
• こなれたら爆速になるかと思ったけど、意外とならなくて難しかった。
• もっとトライ＆エラーが必要かも。
• AWS のサービスをたくさん触れた。
• スクラムをやる前と後であまり違いを感じなかった。
• スクラムの良さを活かしきれていない。
• 作業を分担することが多く、結局タスクの属人化になってしまった。
• スプリントごとのふりかえりで KPT をやっていたが、個人の感想を話すくらいになってしまっていた。
• スクラムマスター的な存在が必要（※そもそもマスターを決めずに進めていたという・・・）
• プログラミングに強くない人でも入りやすくするための施策が必要（※内定者もいるしね）

2018 年を通していろいろ思ったこと、感じたこと

正直言いますともともとは、1人でモクモクと、あれやこれやと試しながら開発していくことが好きでした。 要望されているものが実現できればやったった感はありますし。

しかし、去年を通して何かしら感じることがあったのでしょう。 こういう風に思うようになりました。（1人で聖なる夜を過ごしている時に）

• いいチームってどんなんだろう？
• チームで動くってどういうことだろう？
• 属人化はよくないのは分かってる。じゃあそこから脱却するには・・・？
• 1人でやるのに飽きた
• やったことを共有する、としても１日経てば忘れちゃうよね（少なくとも自分はそう！）
• いっしょに体験することが重要なのでは？

などなど。

そして、そもそもアジャイル開発って？スクラムって？というところからまずは勉強してみようと思いました。 本を読むことは苦手中の苦手ではありますが、何冊か読み（ちゃんと読破したものはありませんが）、 2019 年から始まる新チームで進めていくにあたって、まずはどういう取り組みをしていったらいいかな、というのを考えてメンバーに提案しました。

※ 参考にした本など、後ほど紹介させていただきます！

2019 年始動！

といっても今はもう２月半ば過ぎちゃっていますが。。。

どういうチーム構成かと言いますと、３人です。（少なっ！と感じる方が多いかも？）

私と1人は沖縄。もう1人は東京。 いわゆるリモートメンバーも含めたチーム構成になっています。 といっても、去年３ヶ月間は沖縄でみんな集まってやっていたので気心知れるメンバーです。

まず 2018 年の経験を活かすためにも以下のことを取り組んでいこうとなりました。

ワーキングアグリーメントをしっかり書いてみよう

狙いとしては、去年の反省の中で、ふりかえりがちゃんと KPT になっていない、というものがありました。 それを改善する施策として、ワーキングアグリーメントをちゃんと明文化し、それを軸にしてよかったことや、よくなかったことなどを出していってみよう、となりました。

ワーキングアグリーメントは以下の通りになりました。

• スクラム
  • スプリント
    • 開始曜日：水曜日
    • 期間：１週間
  • デイリー MTG 10:15 〜 10:30
  • ストーリポイントをつけよう：10:30 〜 10:45
  • モブプロのふりかえり：17:00 〜 17:15
  • スプリントレビュー：水曜日の 11:00 〜
  • スプリントのふりかえり：水曜日、ひと段落したら始める
• ドキュメント管理などのツール
  • プロジェクト管理：Asana (Trello のようなボードでタスク管理)
  • KPT：Asana
    • 去年は毎回 Slack にメモ程度に書いていただけなので、ちゃんと見える化するため、タスクのボードとは別ボードで管理
  • ちょっとした文書は Slack のポストを利用しよう
  • 資料となるものは Box に
• その他諸々
  • 仕事のスタイル
    • 基本モブプロで行う（設計、実装など）
    • モブプロは VSCode の LiveShare を利用する
    • ポモドーロ形式でドライバーを交代していく
      • ポモドーロは、25 分作業、5 分休憩、のリズムで行っていく
      • 10:45 〜 25 分 × 3 回
      • 13:30 〜 25 分 × 9 回、できたらいいね
    • プルリク不要
    • 割り込みタスクが発生したらすぐに伝えてね
  • 実装は、テストも含めて完了状態とする
  • OKR
    • 個人でというよりも、むしろ支援出来るものは支援していこう
    • ※ 今年から弊社技術部全体で OKR を設定するようになりました
  • 飲み会
    • 早くあがって飲み行きたい日は早めに申請すること！
    • ※ 特に私用の項目です・・・
  • タイムボックスを守るためにタイマーを使おう
  • A or B で迷った時、工数が少なく済む方でトライしてみよう
  • エラー報告の時
    • キャプチャを添付すること
    • エラーが起きた時の状態（ログインIDなど）を記載すること

全て守られているかと言うと決してそうではありません。

最近はこれらのメンテナンスを怠っています・・・。課題ですね。

この約１ヶ月半で、アグリーメントに追加した方がいいもの（暗黙的に行っていること）や、現状と合わないものがあるので、チーム内で整理し、また後日紹介したいと思います。

ふりかえりを可視化しよう

上のワーキングアグリーメント内にもありましたが、ふりかえりの内容を Slack に記載して埋もれさすのではなく、Asana を利用していつでも見れるように、ふりかえりしやすいようにしたいと思いました。

2019/02/13 時点でのボードの様子がこちらです。

KPT

今は縦の列が５つありますが、最初は単純に Keep, Problem, Try の３つだけでした。

何回かスプリントをまわしていくうちに、

• 「この Keep はもう意識して出来てるね。このカードどうしよう、消しちゃう？」
• 「いや〜、勿体無いでしょ〜。出来るようになったことも溜まっていけば何だか嬉しいし。」
• 「じゃあ、もう１列足して残しとく？」

だいたいこのような会話が出て、「習慣化した Keep」という列を足すことになりました。

１つの例ではありますが、ちっちゃいことでもまずはやって、後で問題、課題が出てきたら改善していこうの精神でやっています。

※ 「習慣化した Keep」はこちらの記事を参考にさせていただきました。

qiita.com

こちらの記事のように Coggle というサービスもしくは XMind のようなマインドマップを描けるツールを使おうか？という話しも出たのですが、まずは使い慣れている Asana でやってみようとなりました。

基本すべてにおいてモブプロでやってみよう

まず、アプリ開発経験を長くやっているのは私1人、ということ。 今後入ってくるであろう新卒のメンバー等の受け入れにも役立てられるのでは？という狙いもあります。

タスクの属人化から脱却したい、ということ。 これは少なくとも、○○の機能のバックエンドなら誰々さんに聞けばいいよね、から、○○の機能であればあのチームに聞けばいいよね、といった具合に、 個人からチームの属人化（属人化って言うの？？）には脱却できるかも、という狙いがあります。

参考にした本など

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

分厚いです（712 P）！お値段もなかなかです！会社にあってよかった・・・ なかなかの量なので、「年末年始休暇で読破してやるぜ！」の意気込みはすぐに捨て去りました。

• 第１部：アジャイル開発
• 第２部：アジャイル設計

を主に参考にしました。

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)

スクラムにはたくさん聞き慣れないカタカナ用語が出てきますよね？（スプリントレトロスペクティブだなんてきっと誰も最初は噛むはず・・・！）

そんなスクラムにおけるたくさんのイベント（プランニングなど）で、どういったことをやったら良いのか詳細に書かれています。

なのでスプリントプランニングではどういったことを意識してやったら良いんだろう？って思った時に読んだりして、辞書的に読んだりしました。

WEB+DB PRESS Vol.102

そもそもモブプロのイメージは、1人がコーディングして、周りがチェックして、みたいなイメージがありました。（ちょっとした監視的な・・・）

でもそうじゃないんだよ、楽しくやれるんだよ、ということが書かれていまして、楽しくモブプロをやっていくにはどうやっていったら良いだろうか、というヒントになりました。

次回予告

第１弾ということもあり、まずは簡単に書かせていただきました。 次回は、実際に取り組んだふりかえりの方法や、モブプロをどう進めたかなどを書いていきたいと思います。

どうもありがとうございました。