スクラム～仕事が四倍速くなる”世界標準のチーム戦術”～ を読んだ感想メモ

1.読んだきっかけ

7月から後輩ができ、それまで個人でしていた仕事をチームでやる必要が生じた。だけでも一応asanaなどを使ってお互いのタスクの可視化などはしたが、いまいちコラボレーションしている感が無い。その理由としては以下の二点が考えられる。 
・後輩が新入社員のため業務の根幹にかかわることも教えながらのため？
・チームとして仕事をするための仕組みなどが整っていないため？ 
後者の問題解決のヒントになるかも！ってことで読んでみた。

2.内容のメモ

・ガントチャートはPJがそれっぽく進んでいることを見せるには有効だが、実際のPJの管理、マネジメントの成功には全く寄与しない
・経営陣はPJに対して、管理と予測可能性を求める

チーム

・スクラムのサイクルの長さはチームメンバーの経験によりそう？
経験がなければ短め、ある程度仕事をまかせることができるのであれば長め？
・チームの構成メンバーは多様な専門性をもった人間
・チームが大きいときの弊害：情報共有に時間がかかるため
・チームに必要な要素：主体性、チーム内の横断的性質、チームの小ささ、

・daily MTでやること
　1. 昨日何した？
　2. 今日何やる？
　3. 障害になっていることは？

・MTはただの個人ごとの進捗報告ではなく、チーム全体の今日の進捗がmaxになるようにを意識して2を設定する。

無駄

・マルチタスキングをすれば個々の仕事の生産性は著しく低くなる。クオリティやかかる時間は膨大になる。
・作業中にインタラプトが入れば、頭の中で構築中だったものを再構成する羽目になる。
・やるべき仕事が途中ということは、何もできていないと同義。
・ミスに気づいたらすぐに修正する。あとからでは修正作業に何倍もの時間がかかる。

プランニング

・作業時間の見積もりしても、当初の計画からのブレは1/4～4倍まで、つまり16倍のばらつく可能性がある。
・プロダクトを構成するために必要なものを列挙→その後、それぞれの優先順位をつける。
・それぞれの構成要素に関する感覚的なサイズ、労力を見積もる。その際にフィボナッチ数を使って比較するといい。
→労力の見積もりに関して、5と6のように微妙な違いはわかりにくい。フィボナッチ数のように1,3,5,8,13くらいであれば違いがはっきりとわかりやすい。
・上記の見積もりをする際に留意すべき点が2つある。
　　-ある人の見積もり評価が他者の見積もり評価にできるだけ引きづられないような手法をとる
　　- 見積もりをする人間は必ずその作業をする人間がする。
　　- ある人の見積もり評価が他者の見積もり評価にできるだけ引きづられないような手法をとる
・人間は文化や国籍に関わらず、他者が先に下した考えに引きづられる絶対的な傾向がある。
・それぞれのタスクをリストアップする際には、そのタスクにストーリーが備わっていることが欠かせない。
・例えば、「AとしてBをしたい。それはCによるためである」のようにである。
・そのためにはそれぞれのタスクがINVESTであるか否かでチェックできる。

- I：Independent
- N：negotiatable
- V：valuable
- E：estimatable
- S：small
- T：testable

・ひとつのスクラム区分（一週間など）が終わったときに、最初に見積もった構成要素の労力サイズの数値がどれくらいまでできたか確認すると、そのチームが１スプリントでこなすことのできる労力サイズがわかる。
これを一般的にベロシティと呼んでいる。

・仕事は見える化したほうが生産性がより高い。

3.感想

スクラムでは一定期間ごとに何らかの成果物が求められているけども、ルーティン業務が業務全体のそれなりの割合を占める管理部門では、すべからく導入できるものではない気がした。

ただし、人事考課集計や賞与計算、年末調整や春闘などのように一定期間で何らかのゴールが設けられているような業務もあり、そういった業務では活用できそうだと感じた。

あと自分の会社はインタラプトを生じさせることん弊害をあまりに軽く見ている気がすると再認識した。