アジャイル / スクラム / チーム開発の［不吉な匂い］まとめ
まずはポエム
やることを考えて自力で実現できるスキルがあれば良い。何か一芸に秀でていればやり方を決めたりはそこそこ好き勝手できるし、自分のやったことに満足したら自分だけは気持ちよく帰れる。って思ってた。
時間外に月何十時間あるいは百数時間コーディングしたり、先輩に昼夜問わずコードを送りつけて見てもらったり、中途採用者のために用意してある受入課題を一人で何回もやり直したりと、あほみたいなことをやっていた。
事実それで設計とコーディング作業の生産性は数倍、数十倍になってきた。
けど、どうもイケてるってのはそれだけじゃあないらしい。ある時期急にそう思った。（遅い）
話してみると、（少なくとも僕の先輩たちのいくらかは）イケてる集団を作れる奴がイケてる奴って考え方らしい。（曲解拡大解釈誇大表現含む）
はじめに
せっかく Engineering Manager vol.2 Advent Calendar 2018 の枠があったので、［1 年前にチームでコーダをやってたとき］〜［急にスクラムマスターをやることにしてうろちょろしていた半年くらい］の間に貯めた悩みや考えをまとめて晒すことにした。
正解ではなくて現時点での自分の考えって感じだけど、どこかのだれかに似たことや活かせる点があったら良いなと思って晒してみる。
人や進捗にダメージを与えながら試行錯誤させてもらったし、ちょっとはアウトもしないと、ってのもある。
前提
- ある程度の内製をしていて、アジャイルやたとえばスクラムをしていたりする
- 考えのとっかかりの箇条書きとしたいので、行間は多めだし詳細な話はかなり削った
- （〜〜の様な状況であれば、）とか（ただし〜〜だと違うけど、）みたいなうっおとしい予防線は張らない
参考
気になり出してから「そういえばスクラムずっとやってるけどちゃんと学んでねーぞ」って思って（遅い）、 1 - 2 月で読み漁った本（読んだ順番は忘れた）
| スモール・リーダーシップ | アジャイルサムライ | scrum boot camp | アジャイル開発とスクラム | カイゼン・ジャーニー | これだけ！KPT | スクラム現場ガイド | リファクタリング |
|---|---|---|---|---|---|---|---|
 |
 |
 |
 |
 |
 |
 |
 |
ざっと読んで気になったところだけ控えて、しばらくしたらメモを見返すという形でやった。
このまとめでそのメモの整理とかもして一息つけたので、また読み返したり別の気になってるのを読んだりできる。
分類とマーク
箇条書きは段落で適当に分類して、以下のどれかのマークを適当につけてみた。深く厳密に分類したりはしてない。全てはふいんき。
原因 / 予兆 / 気づきのヒント
やめた方が良いこと
発生する問題
考え方 / アプローチ
理想の状態（直接の対処方法ではなくて、普段の状態）
qiita の作ってくれる右サイドの見出し一覧を見て、気になったところがあったらそこだけでも役に立てば良いな。
それじゃあ、あとはツラツラと。
デイリースクラム
朝会で「座ってやろうぜ」ってなる
長すぎるのかも？
状況確認だけじゃあなくて、課題解決まで話しているのかも？
だらけやすい
別の作業がしやすくなっちゃう
朝会の［目的］とか［チートシート］とかを見直す
課題の［整理］と［解決］は分ける
長くても 15 分くらいが良い
立ってやる
朝会で「あ、かんばんにはないんですけど、〜〜」ってなる
今必要ないことをやっているかも？
プランニングが間違っているかも？
［やること］と［やらないこと］をちゃんと整理する
かんばんを更新するタイミングをちゃんと作る
みんなで見ながらかんばんを更新している
バーンダウンチャートを見るときに「完了はしてないけど半分くらい終わってるので、実質は理想線です」ってなる
タスクが大きいかも
進行中の作業が多いかも
集まってみんなで嘘みてもしょうがない
まず間違いなく、最終日に全部しっかり完了なんてしない
タスクは小さくする
並行作業数に上限を設ける
実態とバーンダウンチャートが一致している
朝会であんまりかんばんやバーンダウンチャートを見ていない
見てもあんまり意味がないと思っているのかも？
慢性的にバーンダウンしてないのかも？
「実質は理想線です」問題があれば解決する
頻繁に更新されているし、必要な情報がまとめられている
日々予定通りにバーンダウンをさせていて、さらにそれを続けたいと思っている
朝会を毎日同じ時間にしていない
朝会をしなくても困っていないのかも？
朝会でやるって決めたことを 1 日でやりきるサイクルを作る
揃ったらやるってやり方はやめる
朝会の時間は決まっている
朝会をみんなが必要だと思っている
アジャイル
「アジャイルなんだからさっさと終わらせて次いこうぜ」ってなる
ざっと引いた線表に合わせているだけかも？
やっていることに完了条件がないかも？
まず間違いなく、後工程でうまくいかなくなる
ちゃんと終わらせないと次の仮説検証にうまく繋がらない
［やること］と［完了条件］は決めておく
何を［仮説］として何を［検証］するのかははっきり決めておく
「アジャイルなんだからドキュメント書かなくて良いよね」ってなる
「コードがドキュメント」をさぼる口実にしているかも？
［事実］と［決定］と［過程］と［背景］をわけて考えていないのかも？
議論は多いし頻繁に方針転換をするので、むしろ議事録はしっかり残さないとあとですごい困る
［完全なドキュメント］よりも［動くソフトウェア］を相対的に大事にしているだけ
［残すべきドキュメント］と［揮発させて良いドキュメント］に分けて考えてみる
議事録がすぐ確認できて、必要な情報もまとまっている
［プログラムのなぜ］の部分と［システムの使い方］は開発と一緒に整えられる
リファクタリング
「テストはリファクタリングとしてあとで書きます」ってなる
リファクタリングって言うと免罪符になる空気になってるかも？
リファクタリングは［正しく動くコード］を［より良いコード］にする作業だって認識がずれているかも？
テストを書くことをリファクタリングと言わない
テストがないと［正しく動くコード］か判断できない
テストを書くなら実装と別の作業にしない
「コーナーケースの対応はリファクタリングとしてあとでやります」ってなる
処理結果が変わるなら、そもそもリファクタリングではない
これは［バグ対応］とか［仕様の勘違い］とかなので、リファクタリングとは言わない
頻発していると「なんかいつもうまくいかないな」って空気になってくる
なんでも「あとでリファクタリングで」って言ってると、リファクタリングが「あとでやる」以上の意味を持たなくなる
どこまで加味してプランニングしていたのか、みんなで認識を合わせる
頻発するなら前工程のどこかがおかしいので、分析してみる
見積もり
スプリント終了時に「そのタスクは終わらなかったので 3 sp じゃあなくて 5 sp だったってことですね」ってなる
sp をかかった時間だと思ってるかも？
頻発していると「なんかいつもうまくいかないな」ってなる
sp は［工数］じゃあなくて［やることの相対的な大きさ］
思ったより［時間がかかった］のか思ったより［やることがあった］のかをちゃんと分析する
時間を見誤ったなら、ベロシティをあげるアプローチを考える
内容を見誤ったなら、［要件分析］や［完了条件］を見直す
中期計画時にリファクタリングを計上していない
任意の作業だって思っているのかも？
リファクタリングって言って予定を確保するのに抵抗があるのかも？
リファクタリングは絶対に必要
リファクタリング込みで見積もるようにする
［バッファ］とは別に［リファクタリング］の時間を確保する
終盤にまとめてではなく、定期的にリファクタリングが行われる
時期半ばで「進捗がヤバいから休日出勤でカバーしよう」ってなる
［どうして］ヤバくなったのかわかってないかも？
［どれくらい］ヤバいかわかってないかも？
大抵の場合、むやみに稼働をあげても解決しない
多分すぐこうなるチームは毎回こうなってる
遅れは［着手］と［進捗］と［終了］にわけて考える
［どれくらい遅れているか］と［どうして遅れているか］を考える
一度止まって、一息ついてから落ち着いて考える
ヤバくなった要因をまず排除する
スプリントのベロシティに対して各タスクが大きい
4 人で 1 週間に 20 sp の予定なのに、タスクが 3 sp とか 5 sp とかばかり
単純計算だと 1 日に 1 人で 1 sp なので、3 sp のタスクは 1 日では終わらない
1 日で終わらないタスクがあると、次の朝会で「実質は理想線です」ってなりやすい
見積もりミスで 2 sp が 3 sp になった時のインパクトが大きい
タスクを小さくする
ベロシティを大きくする
1 日に 2 - 3 タスクが完了するくらいが良い
ふりかえり（例えば Keep, Problem, Try 方式）
「ふりかえりの時間だからやるよー、はい K と P 出してー」って感じで始まってる
ふりかえりにテーマがないかも？
スプリントで何をやろうとしていたかが、はっきりしていないかも？
バーンダウンしてないなら、別の話をしていないでまずちゃんと終わるように改善する
何についてふりかえるかはちゃんと考える
KPT 以外の適切なふりかえりがないか考えてみる
ふりかえりのテーマがあって、［なんでうまく行ったか］や［なんでうまく行かなかったか］という視点でふりかえる
慣れていなければ仮説や検証なんて難しく考えず、「これをやるぞ！」「さてどうだった？」というサイクルから作る
「この T はやったのでおしまい」ってなってる
T をやることが目的になってるかも？
T に完了条件がないのかも？
T をやったことで P が改善されたかをちゃんと考える
T のアサインと期限と完了条件をちゃんと決めている
過去の P と T や改善の成果を残しておく
課題分析で「別部署が悪い」とか「割り込みが多い」とかになって「どうしよーもねーし...」ってのが多い
自分たちの成果に責任を感じていないのかも？
事実までしか分析していないのかも？
自分たちにできることは本当に何もなかったのか考える
どうしてその状況が発生するのか、背景を考える
一挙に完全に解消できなくても、改善されるならまずはそこからみんなでやってみる
その状況が再発しない（改善される）行動をみんなで考える
コードレビュー（例えば Pull Request 方式）
「何をレビューしたら良いかわからねーっす」ってなる
［何を参考］に［どう］レビューすれば良いかわからないのかも？
何のための PR なのかわからないのかも？
［クラス設計］、［入出力設計］、［エラー設計］、［言語仕様］、［システム知識］、［仕様］とかでレビュー観点を整理してみる
［コンパイルエラー］や［コンフリクト］、［フォーマット］や［リント］などの人間が見なくても良い部分は自動化する
［目的］や［レビューポイント］をちゃんと整える
［レビュー観点］と［レビューのしかた］がまとまっている
B さんのレビューで「これ前に A さんにも言ったんだけど、〜〜」ってのが多い
［レビューする人］対［レビューされる人］みたいな構図になっちゃってるかも？
実装した人以外は関係ないみたいな空気になっちゃってるかも？
レビュー［する］のも［される］のも、みんなでやっているという空気にする
モブプログラミングとかをやってみる
同じ指摘が減り、チームが成長していく
A さんが B さんに指摘できたり、B さんが A さんのやりとりを見て自分で気づいたりする
バグ対応
「出たぞー！直せ！直った！おしまい！」って感じで、分析をしていない
どの工程で検出するべきバグなのか分析していないかも？
自動テストが役に立っていないかも？
分析をしないと頻発する
頻発すると分析をする時間がなくなる
前工程のどこかに問題があるかもしれない
［ぬるぽは自動テスト］、［機能バグはシナリオテスト］みたいに、［何］を［いつ］検出するかを考えておく
期待したバグが期待した工程で発生している
前工程にフィードバックできている
働き方
「とりあえず開催ね」って感じで会議をしている
［アジェンダ］や［目的］がないのかも？
そもそも会議が必要だって思っていないのかも？
不要ならきっぱりやめる、必要なら有効に使う
決定に自分が関わってるという実感と関係をみんなが作る
［アジェンダ］と［決めること］が事前に周知してあり、必要なら［準備］も促す
簡易で良いので決まったことはまとめて、残す
デイリースクラムや会議中に pc を触ってる人がいっぱいいる
作業と会議の優先順位が決まっていないのかも？
全員で決めている感じがないのかも？
デイリースクラムくらいなら pc を持ってこない
聞いてないなら出ない、聞いてるなら対話する
［アジェンダ］と［目的］を整理して、みんなでやるべきことをやる
朝会で「やる」って宣言したことが、何時に終わるか考えてない
1 日の予定を立てていないのかも？
18 時か 22 時かわからないけど、逆算で「今日中」って言っているだけかも？
1 日の見積もり精度が悪いのに 1 週間の見積もりができてるわけがない
1 日の過ごし方を見える化してみる
ポモドーロタイマーとかを使ってみる
何時までに終わらせるつもりかも宣言する
［決まった時間に朝会］をして、宣言通り［狙った時間に終わらせて帰る］
「なぜ？」が詰問になっている
一緒に考える感じがないのかも？
なんでもかんでもとりあえず「なぜ？」って言ってるのかも？
「なぜ〜〜をやらなかったんだ」って言われると答えに窮しやすい
これが辛いと隠蔽したくなってしまう
「どうしたら〜〜をやれなかったんだろう？」って一緒に考える空気にする
［事実］ではなく［背景］にフォーカスする
「なぜ？」は考えを引き出したり、内省を促すために使う
失敗を［責める］のではなく［繰り返さない］という風に考える
何をやっても「どうせ否定される」って感じがある
成果だけしか評価の対象になってないのかも？
足りないという事実だけしか話していないのかも？
第一声で否定しない
足りないことがどうすれば埋まるのかを一緒に考える
［行動］と［評価］は別で評価する
［行動は続くように］、［成果は大きくなるように］する
慢性的に残業をしている
稼働の上げ方が下手かも？
寝坊したり、日中に意識が飛んだりしているかも？
帰る時間を決めていないと、1 日をちゃんと終わらせるサイクルができない
［緊急時や割り込み］による残業と、単純な［進捗リカバリ］の残業はわけて考える
残業によって本当に状況が挽回されているかを考える
残業しないつもりで計画して、慢性的な残業をしない
あいさつや労いがない
まず自分がしてないのかも？
効果を軽視しているのかも？
労わないと、労ってもらえない
誰にでもできるしすごい効果があるので、まず自分からやり始める
言いづらいならサンクスボードとかを使ってみる
相互に良い空気を出せている
みんながやってくれていることによく気づき、良い関係が循環している
おわりに
- 今見返すと「やべぇこれできてない」「あ、これ忘れてた」「これは当然だな、よし腹落ちしてる」ってのいずれもあって面白かった
- タスク消化に必死だったり普段気にしている事が違ったりするから、スクラムマスターをやらないと気づけないことがいっぱいあった様に思う
- コーディングしたい
- 気になり出してからは、まわりの人の何気ない発言で「確かに！」「と、言うことは...！」って学びがあった
- スクラムって「自由！楽しい！」みたいなイメージあるけど、実際は「自分たちで決めないと！その分責任もある！」って感じで相当の覚悟が要る
- コーディングしたい
- アジャイル勢もウォーターフォール勢も互いに訝しんだり敵視したりしてないで、良いところはどんどん反映したら良いのに
- コーディングしたい
一昨日から珍しく風邪をひいていて、間に合わないかと思った。
こんなスケジュール管理とかの話をしておいて間に合わなかったらアホすぎる。
一番大事なのは［体調］ってことだったな。おしまい。