mySCRUMメソドロジー 001続き2
自分にとってのSCRUMメソドロジーをわかりやすく文書化して、今後の開発プロジェクトで適用しやすくしておきたい。
思い立ったがそこそこ重たい中身になりそうなのと、実はすっきりと腹落ちしていない考えなどもありそうなので、ブレストしながらその内容を記事にしてみたらいいんじゃないかと思った。
人の限界
プロジェクトの計画や実施における人の弱みとは何か、整理する。
数値化または目視しないと、コトやモノの大きさや必要時間などを認識することができない
言葉を使って意思疎通を行い、多様なコト・モノについて解釈を行うことができる高度な知能を持つ一方で、言葉で伝える正確性には限りがあり、伝達先の解釈は頻繁に誤ったものになる
不確実性を計画に読み込むことができない
誤りや失敗を認めるのが苦手
昨日は弱み１と弱み２について書いた。今日は弱み３と弱み４について書く。
弱み３ 『不確実性を計画に読み込むことができない』
についてSCRUMは下記のアプローチを持つ。
予定と異なることが起きた際にすぐさまそれを検知し、チームや会社として認知して計画を更新することをプロセス化している。
不確実性を計画に読み込む方法として、ウォーターフォールなど従来の手法でよく採用されたのは、例えば見積もり工数や日数に一定の係数をかけてバッファを計画に追加する手法だ。不確実性によるネガティブインパクトを小さくするために、長いプロジェクト期間をより短い単位に区切って計画し、その際にはスコープも併せて小分けにする。
不確実性は、プロジェクトを実施する期間やスコープの大きさが増すほどに大きくなり、かつ計画と異なることが発生した場合の全体への影響も大きくなる特徴があるのでこの対策が有効になる。
不確実性について
不確実性についてもう少し具体的に書く。
プロジェクトの計画を策定する際には、内容・コスト・期間・プロジェクトのアウトプットによる効果（売上など）を予測する。そのどれもが将来のことなので、当然不確実性が存在する。
ビジネスにとっての不確実性
ビジネスにおいては不確実性は好ましくないものとされることが多い。
つまり、計画が計画通りに進むことが善であって、計画がブレることは悪であり、それはなんらかの過ちや能力不足、場合によっては天災などによって引き起こされるものであると言う考え方である。
投資計画が大幅にずれたり、納期が大幅に遅れたり、売上計画が大幅に狂ったりすれば会社の経営に悪影響がある。よって、ビジネスが不確実性を嫌うのはごく当たり前のことではある。
現場における、不確実性と予想外の出来事への対処
予定外は日常茶飯事
しかし、実際には将来起きることを読み切ることは人間には出来ないもので、たったの２週間ほどの計画も細かく見れば計画外の出来事や状態が絶え間なく発生する。例えばそれが、作業者が通勤で渋滞に巻き込まれ30分物事が遅延する程度であれば、大体のケースでは現場がなんらかの方法で遅延を帳消しにすることでプロジェクト計画が狂わない様にする。それ自体は悪いことではない。プロジェクト参加者による純粋な努力と建設的な対応だ。
気合だ。責任感だ。リカバれ！
これが４時間の遅延だったらどうなるだろう？しかもそれにより後続タスクを始めることができず時間的には結局倍以上の影響をスケジュール全体に対して与えるとしたら？
もっと別のケースでは、そもそも想定していた設計に誤りが見つかり、もともと見積もった期間と工数では当該の工程を完了できないとしたら？
この様な状況でも最も現場が採択しやすい最初の対処法が、「頑張ってリカバリする」ことだ。特に日本企業においては、「頑張ってリカバリする」と「責任を持って持ち場を守る」ことは同義であると言ってよく、なんなら会社の理念にも書いてありそうなほどだ。一見建設的に見えるこの対処法は、残念ながら実はそのタイミングでの最悪手の一つと言って良い。
僕のチームで遅延は許せまてん！
何故それが最も現場にとって自然な選択肢になってしまうのか？
それは、そもそも遅延や予定外の出来事が「悪」であり、その「悪」の原因は参加メンバーや計画者の個人としての「落ち度」と結び付けられることが多いからである。当然プロジェクトの主幹部署や責任者、ひいては経営陣まで同じ様に不確定要素の発生をマイナスなものと見ていることが多く、それを知っている現場は「できれば大事にしないで、現場でリカバリーする」ことを選んでしまうのである。
報告する頃には大体手遅れ。
厄介なのは、リカバリー可能なものとそうでないものが上記に挙げた二つの例の様に微妙なボリュームの差で別れたり、予想外のことが起きた時にそのインパクト自体も分析・把握するのに時間がかかったりすることだといえる。元々埋め合わせをする方向にバイアスがかかりがちなことと相まって、リカバリー自体が結果的に失敗してプロジェクト計画の実行に大きく又は複雑に影響を及ぼし始めるまでその状況が正確に認識され且つ上層部までエスカレーションがかかるまでにかなりの時間がかかってしまう。
認知 -> 周知 -> 対応 はい次。
この様な状況になると、良いことは一つもない。よって、SCRUMの考え方では、そもそも不確定性には善も悪もなく当たり前のものとして捉え、プロジェクト実施中に計画外のことが発生した場合にはとにかく早く客観的にその情報が認知され且つオープンに現場で議論され、同時にステークホルダに情報が届く様な仕組みを作っているのである。
デイリースタンドアップ、バーンダウンチャート、スプリント内のタスク化粒度、スプリントレトロスペクティブ等は、全てこの大きな問題に対する解決策をそれぞれ内包している。
弱み４ 『誤りや失敗を認めるのが苦手』
この弱みに対応するSCRUMの道具・技に以下がある。
バーンダウンチャート
デコミット。数日前に「やる」って言いましたけど、やっぱ「やりません」宣言
失敗を認めるのは怖い
人は誤りや失敗を認めるのが苦手だ。古き良き日本企業は減点方式だからよりミスを犯すことが嫌われると言われている。
誤りは悪じゃ！
実際そうだ。小学校教育から、教室でのプリントやテストは、マルバツ方式で点数をつけ、100点満点中いくらか？が評価基準であるのが最も一般的だ。間違い把握、間違いは異端児であり悪であると我々日本人は小さな頃から叩き込まれる。この辺りは又別の投稿で扱いたい。
今回だけは許してあげるよ、的な。
話を戻すと、ミスは嫌われる。早く自分達の遅延状況を見つけてリカバリ努力もせずにサラッと報告し、上司から感謝されたと言う経験はあまりないのではないか？あったとしても、一通りお説教された上で「今わかったことが不幸中の幸い」とか「折角だからこの失敗を活かそう。2度としない様に頑張ろう」などと、理解のある上司風を吹かされるのが関の山ではないか？皆さんいかがでしょう？どちらかといえば私は、そんなことはない！という経験談を聞きたいです。
違うの。遅延なんて、ミクロ視点でプロジェクトをみたら当たり前で、いちいち罪悪感なんてもってる暇はないの。そもそも開発に関わる行為って、正確に所要時間を読めるものではない。
それでも事業にはスケジュールや期待値管理は不可欠。なので、進捗は常に把握する必要がある。
進捗可視化はプロジェクトのいち機能。簡単にやろう
スケジュール遅延や課題などが、即座に且つオープンにSCRUMチーム内やプロダクトオーナーと共有される様にするためには、不確実性をニュートラル（善でも悪でもない、当たり前のこと）に捉える文化の醸成と共に、迷わず使えるツールが必要なのだ。
バーンダウンチャート（バーンアップでも良い）
そんなこんなで普通は、「今30分遅れてます！あと2回同じ状況が起きたら２週間後は納品対象から外してください！」なんて報告はあまり聞かない。
でもまさにそれを奨励し、わざわざ報告を受けずともプロジェクトのステータスボード上で一目瞭然にするためにあるのがバーンダウンチャートだ。2〜3日間も予想外の状況が続き、細かい遅延や工数見積り更新が起きていたら大体チャートを一目見ただけで異変が目に飛び込んでくる。
伝家の宝刀デコミット
加えて、SCRUMマスタは伝家の宝刀「デコミット」を持っている。
『現在の２週間で全チケットを完了できないことが判ったので、最も低い優先度のチケットを一つ（又は複数）、２週間後の完了目標スコープから外します。』これが伝家の宝刀デコミット。
もうちょっと２週間ギリギリまで頑張ってみてくれとか、タスク担当者を入れ替えればなんとかなるじゃないかとか、プロダクトオーナーによる真剣白羽どりは許されていない。
岡田以蔵の居合切りの如くSCRUMマスタのデコミットはファイナルなのだ。
報告受けたら速攻アクション。それが嫌ならアジャイル無理よ
いまだに、組織の序列とSCRUM内のフラット且つ明確な責任分担をスパッと分けらていないケースはよくあることだと思う。プロダクトオーナーがSCRUMマスタによる判断と報告を受け入れて即座にプロダクトバックログやステークホルダの期待値管理や調整に走り出さない様であればSCRUMは全く機能しないので、それはつまりそのチームではSCRUMは機能しないことを意味する。その場合は諦めて別のプロジェクトメソッドを検討したほうが良い。
この記事が気に入ったらサポートをしてみませんか？