こんにちわ、 id:uniq です。
社内のとあるプロジェクトにてSprintを行っております。
チームには（たぶん）認定スクラムマスター研修をうけたメンバーはおらず、その Sprint は独自のものだと思います。
2週間に1回、水曜日にリリースし、その後にSprint MTGをします。まれにバタバタして、Sprint MTGの後にリリースになっちゃうこともありますが、それでも、レビューやテストはだいたい済んでいる状態でMTGをします。
その Sprint MTG では、未達・達成済みの確認を行い、KPTをします。未達時の課題・改善について、これ気になった・やっちゃった、これ良かった、これやりたい。
ユーザー動向の数字を見たりもします。そして次のゴール設定をします。
Sprint MTG で「追い切り担当」に任命された方が、「このissueどうなってますか〜？コンコン」のドアノック係。
「プロジェクトの全体進行を円滑に進めるためのリマインド」をしてくれるサポートさん。ありがたい。
「ウッ」と思わずに（思っちゃうこともあるけど笑）、快く対応し、自分のissueは責任もって進捗を更新・共有していきます。
そうそう、このSprintでの朝会はやっていません。思いついたら聞く（手が空き次第、もしくはタイミング共有して後日に返答・対応など）、issueはしっかり更新する。そうできているのも追い切り担当さんのおかげかも。
Sprintの真ん中に中間MTGがあり、着地確認をおこないます。ゴール達成の精度を高めることが目的です。必要に応じて、ゴールの見直しをおこないます。
Sprint MTG・中間MTG には、デザイナーも参加しています。
デザイナーが Sprintに参加する際、いくつかのアンチパターンをよく見聞きしますし、私もいろいろ経験して歯がゆい気持ちになったり苦労しました。（勉強になりました。）
このビルディット風 Sprint が、良い方向に向くヒントになればなーと思いまして、記事を書きます。
さーて、何から書こうかな…？
アンチパターンを紹介して、読んでくれた人と問題認識の気持ちを合わせてから、こうしてるよ〜って書こうかな〜…
…と思ったんですが、アンチパターン書いてたらとっても悲しくなってきたので、ビルディット Sprint のお気に入りポイントの紹介にしようと思います。
「なに開発しよっか？」ってところから参加できる。ユーザーにとっての課題に目を向ける。
まずはこのお気に入りポイントから。
「ユーザーにとっての課題」について、最近のこと、前々からあること、MTGでよく話します。Slackでも。
「今回はこの課題から手を付けてみよっか」という話から参加できると、さまざまな良いことがあります。
- デザイナーならではの解決方法が提案でき、ベストな解決方法への協力ができる。
- デザイナー発のが「正」ということが言いたいのではなく…、その提案から、他メンバーのコメントが入り、課題そのもの・工数面やコスト面などから考えて「今ベストな解決方法」に辿りつけているなあ、という手応えがあります。
- たとえば issue の粒度を小さくすることで、課題解決の対応が早めにできたり
- たとえば エンジニアに早めに提案できることによって、様々な事情を汲み取れったデザイン、技術的な考慮がなされたデザインが作れます
- 時間に追われない。
- 開発のスケジュール決めに参加できるので、現実的な工数で挑めるし、そのため、アウトプットの質が良いと思っています。（エンジニアを待たせている状況での間に合わせデザインではない）
- なによりもモチベーションがあがる。
- 個人的に「言われたものだけを作る」というのが苦手でして…！「何を作るか？」から参加できるのは楽しいです。
- 先のSprint、先の先のSprint、先の先の先の先のSprintにも目を向けることができる
- 「なに開発しよっか？」という話のときに、「AはBが終わってからだね」とか「Cはココだけ着手して、アッチの部分はあとで実装するっていうのも出来るね」という話もしています。先の先の先〜まで見据えられるということは、デザインを作っていく立場として、計画を立てやすいし、「どのユーザー行動に着目しようかな」の、目処が立てやすいです。
- 次々sprintのためのデザインを用意しながら、今のsprintのための実装フォロー（エンジニアさんから画面のレビュー依頼など）に対応するための準備がしやすいです。
Happyだらけかもしれませんが、、ちょっと難易度の高いことを常に意識しないといけません。
それは「全体を俯瞰する」ってやつです。
自分都合、デザイナーの作りたいデザイン都合の目線だけではなく、
プロジェクト全体、チーム全体、サービス全体を俯瞰しないと、ついていくことができずに、ただ参加してる・聞いているだけになっちゃうかもしれません。
具体的になにをするかというと…
- 「Sprint 全体の目的はなにか？ゴールはなにか？」を把握する。
- 自分以外の issue の内容・動きも把握し、上記の目的とどのような関わりがあるか、また、そこから発生するデザインまわりの課題はないか把握する。（エンジニアリングのことがわからなくて把握できないissueもありますが、アサインされているエンジニアに聞いて、「具体的にどんなissueか」を把握します。）
- 全体の目的からの、デザインの課題はないか、他に動けるところはないかを見ていく。また 先回りして動く ということもやっていく
プロセス改善によるチーム成長
これ、私が勝手に思っていることなので、PMのとみたさんは全く意識してないかもしれないです。
中間MTGの目的のところを見て欲しいです。
「着地確認をおこないます。ゴール達成の精度を高めることが目的です。」って書いてあります。
「ゴール達成の精度を高めること」
「精度を高める」
これです。
（大事なことなので３回言いました）
もちろん「間に合わなくてもいっか」と甘えモードになりながらゴールを決める…ということではないです。
どんな風にいい感じなのかうまくテキストで書けなかったので、図にしてみました
見積もり…難しいですよね！
ぜんぜんうまくいかない。
最初の予想に反して難しいこともある。
頑張っても工夫しても、うまくいかないことがある。
なぜかな？
ボトルネックになってること。
メンバーが協力できること。
手数少なくして、そもそもの課題が解決できないか？
そういったことを相談できます。
チームとしてユーザー課題に向き合ってる。
チームとして開発のプロセスに問題ないか？と向き合う。
これによって、課題が言い合える信頼しあってる感がしまして…チームとして成長しているな〜と思っています。
（そりゃ、期日どおりに絶対にコレを！…と、頑張らなきゃいけないときもありますが！）
目的は、計画通りにやることではなく、課題解決をすること
Sprintって、あっちこっちから振ってくる天災みたいなものにチームでいい感じに対応する術な部分もあるかなあと。
「以外と難しかった！」っていうのがけっこうたくさんあるし、hotfix対応（これ直さないとサービス止まっちゃうので対応しなきゃいけないやつ）があるかもしれない。
そこを、それなりに疲弊はするんだけれども、いい感じにチームで気持ちよく対応する。
早くリリースすること、、、計画通りにやること、、、うん、そりゃしたいさ！ぱぱーっといい感じのデザイン仕上げて「うにさん、早いねーすごいねー」ってホメられるのも嬉しい。
でも他のメンバーはどうだろう？
私のぐちゃぐちゃの デザインコンポーネントに頭を悩ませてないか？
私のぐちゃぐちゃの CSS 設計に頭を（以下略）
ユーザーはどうだろう？
このデザインで良かった？
そもそもデザイン大事な場面？
いやいや実は、そこまで工数かけなくても、もっと手抜きで早く出来上がってるので良かった？
リッチな画面いらなかった？
計画や目標はあるし、大事なことだけれども、
そもそものユーザー課題を見失わないこと、また、私達チームが気持ちよくスムーズに（様々な山や壁に直面しながらも）それでも楽しく開発できるチームに成長できる道具、
それが、このお気に入りのビルディット風 Sprint かなあと思いました。
まとめ
このやり方は、私がこのプロジェクトにおいてお気に入りではあるものの、「どのチームでも合うはず！」というわけではないと思います。
実際に社内でも、メンバーやプロジェクトのフェーズに応じて、Sprint 設計は様々あります。
ただ、楽しくモノづくりをしていきたい…という気持ちは、共通かもしれません。
お仕事は大変です。責任はつきものです。
「その後、みんなみんな平和に暮らしましたとさ…」というお話は、現実にはないです。
ちょっとしんどいことのある中でも、いまできる最高のものをワクワク作りながら
チーム成長につなげていきたいなあと思っています。
おこりんぼさんも、なまけものさんも、のんびりやさんも、泣き虫さんも、みんなみんな笑顔でいきましょう！🍩
チームメンバー募集中です！
