mySCRUMメソドロジー　001続き3（最終回）

自分にとってのSCRUMメソドロジーをわかりやすく文書化して、今後の開発プロジェクトで適用しやすくしておきたい。
思い立ったがそこそこ重たい中身になりそうなのと、実はすっきりと腹落ちしていない考えなどもありそうなので、ブレストしながらその内容を記事にしてみたらいいんじゃないかと思った。

---

SCRUMは気合に頼らない

いよいよ最初のシリーズ最終回。SCRUMが気合に頼らない話。

SCRUMのことが好きな理由の最後は、プロジェクトの成功を、チームやスクラムマスタの気合に頼らないこと。

目標はリーグ優勝、夢は名門クラブにのし上がること

プロジェクトは、サッカーで言えばリーグ戦の様なもので、一戦一戦も大切だが一番大切なゴールはリーグ戦で目標の成績を収めることにある。更に言えば、ワンシーズンを勝つのは短期目標であって、複数のシーズンを通じてチーム力を高めていって長期間に渡ってトップグループの座を維持するほんまもんの実力を手に入れることが目的だったりする。

高いコストをかけて最高の選手を集め、チームとして機能する様練習時間を投資しておいて、今日の試合に勝つためだけにその選手の身体を壊す様な使い方は絶対にしない。本人も、クラブも両方ともだ。

延長戦の時間が短いのには理由がある

しかしこれがソフトウェア開発プロジェクトともなると平気でプレーヤーに延長戦を２ゲーム分も戦うことを許したり強要したりする。もはや何故それが悪いことなのかを長々と説明する必要はないだろう。

気合に頼らないために

予定が崩れた時に誰が何をするかが決まっている
プロのプロダクトオーナーは、スプリント毎に区切られたプロジェクト全体の進捗を鋭い目で俯瞰する。遅延や思いもしない課題が発生した場合にはSCRUMマスタが即座に報告をくれるので、連絡を受けた場合は顧客や経営陣などプロジェクトのステークホルダの期待値を先んじてコントロールする任務を遂行する。

多くの場合は、この時点で既にスクラムマスタがデコミットを申し出るので、現行スプリントが終わった時には、当初完了する予定だったチケットをいくつか後回しにする。そしてそれは間違いなく、プロジェクト全体のスケジュールにインパクトを及ぼすので、そのインパクトを全体計画に反映させる。

この様に、遅延が発生してもどう対処するかをまるで避難訓練の様にプロセス化しておけば、特に焦る必要がなくなる。よって大事として隠したり隠されたりすることもなくなることが期待される。

短い一定のサイクルで計画と実行を行う
スプリントは、長いプロジェクト期間を短く区分け、其々アウトプットの目標を明確に設定して実施されるもので、常に同じ様なサイズのミニプロジェクトである。１スプリントを２週間とするのが一般的。
長さを短くかつ一定化することには以下の様な効果がある。

• 近い将来だけを詳細に計画する（遠い将来はざっくりのみ計画する）ことで、不確定要素が入り込む可能性を減らす

• 短いサイクルで、遅延や前倒しなど、プロジェクトの状況を細かく判断することができる

• 一定のサイクルで何度もプロジェクトを行うことでプロジェクト環境を一定化し、繰り返し乗り越えるうちにチームの練度が上がる。サッカーでも、毎度ゲーム時間が異なればチームのパフォーマンスは最適化できない

６ヶ月ごまかし続けて蓄積した遅延や歪みと、２週間ずつ明確になる遅延や歪みとでは、後者の方が対処しやすい。自分も前者をやってしまったことがある。あー思い出したくもない。

気合に頼らないのは、決して気合で「リカバリ」する武士よりも堕落した文化ではなく、常に有事に備えて鍛錬することを忘れない、より侍なストイックな世界な気がする。