チームのアジャイル Tatsuhiko Mitsui 

今日話すこと 今のチームでやってるアジャイルなことをいろいろご紹介します how的な話を中心にしてますが、チームとしてどういうモチベーションで取り組んでいる かを理解してもらえるとありがたいです → ぜひ何か持ち帰ってもらえれば🐇 

開発手法と基本的なところの ご紹介 

どうやってるの？ スクラムでやってます！ ❏ ちゃんと全部のイベントやってるよ！ ❏ 1週間スプリント ❏ 各種イベントは以下のようは配置 (詳細は次のページから ) 

プランニング ❏ 事前にやっておくこと ❏ エンジニア: 各PBIの受け入れ条件を明確にして、 SPをつけておく ❏ PO: 順番を並び替え、次スプリントでやりたいことを明確にしておく ❏ プランニング時にやること ❏ POからその時点で検討しているスプリントゴールを共有してもらう ❏ 次スプリントに入れたい PBIを上から確認&サブタスクを切っていく ❏ 一通りPBIの確認が終わったら「作業計画表」に落とし込んで見る ❏ どこまでこのスプリントに積むか見定め、決定する ❏ 必要に応じてスプリントゴールを調整し、最終決定 ❏ スプリント開始！ 

作業計画表: テンプレ 

作業計画表 

作業計画表 ❏ PBIがこのあたりで終わりそうかな〜というのを配置してみる ❏ 各種イベント(スプリントレビューや誰かのおやすみ等々)も配置する ❏ ※これは計画なのでスプリント中には動かしません ❏ これをやりはじめてよかったこと ❏ SP的にいけそう、と思っても実際に可視化してみるとしんどそうとか気付ける ❏ デイリースクラムやレトロスペクティブのタイミングで「よかったこと」や「わるかったこと」を把握しや すい -> 仮説検証がよりよくできる！ 

バックログリファインメント ❏ 厳密にはスクラムイベントではないですが、時間とってやるようにしてます ❏ POとエンジニアでsyncするのが目的 ❏ 次のプランニングまでにチケットをReadyにできるように話し合う ❏ リファインメントの場で Readyにすることもある ❏ できないものとかはプランニングまでに各自やっておく ❏ (あんまり特別なことをやってはいないつもり) 

チーム内での「チケットがReadyな状態」とは ❏ 端的にいうと以下 ❏ ストーリーであればストーリーポイントがついている ❏ 調査系チケットであれば TimeBoxを設定している ❏ ストーリーポイントもしくはTimeBoxでの見積もりができている状態とは？ ❏ 上記は開発者側で見積もりができていることを指す ❏ 見積もりをするためには PBI上で「どういう目的」で「何をする必要があるか」が把握できるようになっ ている必要がある ❏ そのため必然的にWhat (提供したい価値　/ 解決すべき課題) と 完了条件 / 受け入れ基準 がPBI に整っていなければいけない ❏ -> プランニングのタイミングでは「なにをやるか」の話ではなく、「どれをどこまでどう やるか」の話にフォーカスできる 

スプリントレビュー ❏ 事前にやっておくこと ❏ エンジニア: レビュー対象のものをコンフルに列挙しておく ❏ スプリントレビュー時にやること ❏ レビュー対象のものを順に見ていく ❏ 今後のスプリントに影響しそうなことがあれば「スプリント中の状況の変化などの共有」として相談す る(参考: https://www.ryuzee.com/contents/blog/7133 ) ❏ 気をつけてること ❏ リリース可否を判断する場ではない ❏ 「作ったものが仕様通りか」というのはスプリントレビュー外で事前に話しておく ❏ -> あくまでこのスプリントレビューでは「実際意図した通り作ってみたけどどうだろ」というところの仮 説検証をする場にする 

レトロスペクティブ ❏ Jiraのスプリント閉じます ❏ 現状可視化されているデータとしてはJiraのスプリントレポートくらいしかみてないで す ❏ 本当はもうちょいいろんな指標とか見れたらいいんだろうけど整備中 ❏ スプリント閉じたらすぐふりかえりそのものに移ります 

レトロスペクティブ ❏ ファシリテーターはローテーションしてます ❏ ふりかえり手法もそのタイミングごとでファシリテーターが「このふりかえりでやれた らよさそう」というのをピックアップして実施してます ❏ アイスブレイクにはすごく雑多なことを共有してもらってます ❏ ※本当は日頃から気軽にそういう話ができたらいいんだろうなと思いつつ 

デイリースクラム ❏ 現状２つ存在してます ❏ 朝: エンジニアだけのデイリー ❏ 夕方: チーム全体のデイリー ❏ エンジニアのデイリー ❏ シンプルに当日の作業計画を考えます ❏ なにかネタがあればデイリーの + / ⊿ をやるようにしています 

デイリースクラム ❏ チーム全体のデイリー ❏ スプリント内の状況確認 ❏ その他チーム全体として共有事項があればシェアや相談 

その他独自イベント 

モブ会 ❏ 開催日時: 毎日16:30~17:00 ❏ チーム全員が集合して、なにか相談事があれば相談するし、とくになければみんな で各々の作業をする時間です ❏ (当初のうちは)意図して集まる場を作っておいたほうがハッピーかなと思い設置 ❏ ※夕方にあるチームのデイリーと微妙に役割かぶってたりするから実はちょっと調 整したいと思ってる😇 

エンジニアふりかえり ❏ 開催日時: 水曜11:00~12:00 ❏ 最近のレトロスペクティブの場だと「課題としてはわかるものの、具体的なtryに落と し込みにくい。もっと個別で話したほうがよさそう」みたいなネタがぼちぼち多くなっ てきた ❏ とくにエンジニアだけで本当は解決できたり、もしくはエンジニア側である程度固め てからチームにエスカレーションしたほうがよいものとかもある ❏ それらの話をする場 ❏ 普通のレトロスペクティブより「tryにつなげる」ことを少し意識している 

ふりかえりの全体感 

雑感 ❏ 多分そのうち慣れてきたり、チームのフェーズが変わってきたタイミングで各種イベ ントの再整理をする必要があると思う ❏ -> イベントを増やしまくって結果として作業時間が減ってベロシティが下がったりあ がらなかったりしたら意味がない ❏ 引き続きうまく良い変化を取り入れていきたい 

アジャイルな取り組み 

どーやって開発進めてる？ ❏ ほぼモブプロでやってます！ ❏ 11:00 ~ 18:50くらいまで原則モブプロでやってます ❏ ※みんなだいたい10:00頃出社してます ❏ 19:00ギリギリまでやると19:00ちょうどにあがれなくなることが多いため ..(なお現実) ❏ あるPBIやるぞ〜となったらみんなでやります ❏ 誰かがドライバー ❏ 他の人がナビゲーター ❏ さらにもうひとりが俯瞰してみてるマン (or たまに必要に応じて細かな作業をやったり ) ❏ → チームとしてはあくまでそのタイミングで一つの PBIだけに集中するようにしている 

ほぼモブプロバナ ❏ ドライバーに関してはちゃんとうまく定期的にまわしたり、そこまで強くない分野のと ころをドライバーが担当する、といった形になってたりします ❏ PRのレビューとかないです。PR作ったらほぼそのまま混ぜます ❏ その場で指摘できるので「うわーこんな細かいところ指摘してごめんな」みたいな感情がなくなりま す ❏ 各種IDEの共有機能でみんなで同じコード触りながら進めれます 

続: ほぼモブプロバナ ❏ Q. つかれない？ ❏ A. 最初は結構疲れた気がする。今は慣れた (多分) ❏ Q. それって効率的なの？ ❏ 長期的に見たら効率的なんじゃないかと思ってます。原則チーム内の全員が全部のコードの内容 を知ってます(ちょっと盛ってるけど ) ❏ 良し悪しは置いといて、例えば手が開いてる人がその PBIのテストケースを考えたりとか、ホントに 細かいところの作業をしたり、とかで「その PBI単位」でのフロー効率の最適化は目指せます 

❏ Q. ほんとにいいことしかないの？ ❏ そんなことはない() ❏ 例えばCopilotくんはIDEのシェア機能に参加してる側には効かなかったりする ❏ モブでやってるとチームとして「終わらせるぞ」みたいな意識が向きすぎると斜に構えた見方をしにく かったりする(そういう意味ではPRレビューはフラットな視点で見れるので価値はありますよね ) ❏ あんまりにもやること、方向性とかが見えてないものには向かない ❏ あたりがついてるタイプの調査とかはみんなでやるとよい ❏ そもそも「なにからはじめたらいいんだ？」みたいなやつとかは個人作業にして、ある程度お 互い見えはじめたタイミングで合流してモブモブとかのほうがよい 続々: ほぼモブプロバナ 

意思決定の話 -> チームの誰が意思決定してもいいようにした い ❏ 能力/技術力 ❏ チームとか特定の組織体としての目標 ❏ 周辺情報 これらが揃っていれば誰が意思決定と遂行をしても同じような結果になるのでは？ -> そうなるようにチームとして各要素をあわせていく 

スタンス的なところ ❏ 誰が何をやってもいい ❏ みんなでできるようになる/みんなでつくる(このビアバッシュの発表もそう) ❏ 適宜仮説検証をしていい方向に変化していこう ❏ →アジャイルソフトウェア開発宣言ぽいことしてる！() 

おしまい