スクラム以前に大切な、毎週やり切るプロジェクトマネジメント

ソフトウェア開発

2023/09/18 03:00

スクラムの導入で問題が生じる場合、それはスクラム以前に存在した課題が影響していることが多いです。プロジェクトを成功に導くための筆者の経験に基づく超基礎的かつ重要なポイントをご紹介します。

スクラムを導入したが全然上手く行かなかったプロジェクトを見聞きするたびに、

「それ、スクラム以前の問題ですよね」

と言いたくなる事が少なくありません。

ストリーポイントがわかりにくい 会議が多くなって時間が取られる スクラムはもはや時代遅れで~~

など色々スクラムに対する難癖をつけたり、手法の良し悪しに終止する意見も散見されたりします。

しかし、うまくいっていないプロジェクトの大半が、

毎週(スプリント)の成果がしょぼいだけ

ということは決して珍しくありません。

• スプリント開始時に計画したチケットが振り返りの時点で全然完了していない。
• 完了していないことに対する追求も弱く、またチーム全体に緊張感がなく弛緩している。
• 仕掛中のチケットが無数に溜まっているのに、誰もそれを異常だと思っていない。
• 振り返りも表面的な問題や関係者に対する不満などが挙げられるだけで、自分の成果がしょぼい原因に切り込む様な発言はない。
• デイリースクラムも、今日やること/昨日やったことをただ各々報告するだけ
• スプリントの終わりに期待される成果に対するギャップはどうか？今日何に集中するべきか？のについては誰も触れないし、ツッコミもない。
• そもそもスプリントプランニングも適当にチケットをバックログからポイポイ入れてるだけで、スプリントのゴールも不明瞭かつ妥当性もない。
• スプリントレビューも延期を繰り返し、大量の仕掛り作業ばかりで論点がないので、スプリントプランニング会議自体がスキップが続くこともある。

こんな状態なのに、多くの人は見積もりの精度が甘いだの、会議体が機能していないだの、元々の計画に無理があったのだと言ったりします。

シンプルに、 毎週(スプリント)の成果がしょぼい という現実に目を向けていないチームが本当に多いのです。

完了だけが進捗

「この作業は50%程度の進捗です」

などという人の話は聞いてはいけません。 完了だけが進捗です。

完了していないものは、1%でも90%でも進捗0と同じこと。同じ仕掛中の作業です。

そりゃ1%と90%を一緒にするのは暴論だと思うかもしれませんが、

プロジェクトオーナーの立場から言えば同じことです。

90%までかけた時間と残り10%の時間が比例するとは限りません。

あくまで自分が90%だと思っているだけで、完了するまでその仕事の本当の大きさは確定しません。

だから、完了以外を進捗としてはいけません。

完了しか進捗として評価されなければ、自ずと定期報告会までになんとしても自分の作業を完了にする動機が生まれます。

自分が担当しているチケットを完了するためには何が必要かを嫌でも考えます。

スクラムのいいところは、プロジェクト中に何度も締め切りが訪れるところです。人は締切がなければ頑張りません。

締め切りというぐらいだから、それまでに作業は完了しなければならないのは当然のことです。

中途半端な仕掛を進捗とみなした瞬間からスプリントの成果がしょぼくなる という現実を受け入れましょう。

完了は厳格に定義する

完了だけが進捗とするならば、完了を厳格に定義する必要があります。

完了が曖昧な状態だと、そもそも作業を完了できないという問題以外にも、

本来の完了条件を満たしていないにもかかわらず完了としてしまう問題が根深いです。

そんなことをしたら、「完了していないのに進捗とする」とやっている事は変わりません。

このチケットが完了するための条件は可能な限り厳密に定義するべきでしょう。

完了条件は、作業状態だけではなく誰がその完了を承認するのかも決まっているべきでしょう。

作業者が完了と思ったら完了など、遊びの余地を作ってはいけません。厳格さが必要です。

もちろん、承認までのリードタイムが長すぎるのは問題です。

承認者は可能な限り固定にせず、複数人で、理想的にはチームメンバーの誰もが承認者になれる状況を作るのが好ましいでしょう。

このように、スプリント内に取り組むチケットの完了条件を精緻化する作業は、PMにとって最重要タスクといっても過言ではありません。

万一定義されていないチケットを担当した人は、完了条件を明確にするための行動を取らなければいけません。

チームの全員が、「この仕事の完了とは・・・？」という哲学的なマインドになるように徹底的な教育が必要です。

スプリント成果にコミットする

スプリント中にやると決めた事は、「チームとステークホルダとの間のコミットメント」としてください。

スクラムの文脈では、「見積もり」は「コミットメント」ではない。という言葉がよく使われます。

確かに、数ヶ月の期間を要するプロジェクトの納期見積もりをコミットメントとするのは暴論です。

見積もりが誤っており、想定外に時間がかかってしまい、結果として約束を果たせないことは十分想定されるべきことです。

しかしごく短期間のスプリント中にやると決めた事を約束できないなら、誰がこのプロジェクトの成功を信頼できるのでしょうか？

誰がこのプロジェクトが着実に前進していることを保証するできるのでしょうか？

スクラムの思想を都合よく解釈して、開発者が自身の成果に対する責任逃れをする様な態度であってはいけません。

スプリント内にやる事は、チームが十分に達成可能だと判断でき、ステークホルダの期待値に応えられる妥当な落とし所でなければいけません。

チームが十分に達成可能だと客観的に判断できるようにするためには、チームの生産性をモニタリングする必要があります。

そのためにストーリーポイントという相対見積もりの手段を使います。

プロジェクトの最初にストーリーポイント見積もりをやっただけで、ベロシティの計測や、継続的なポイントの見直しが伴わないのであれば、

ストーリーポイントによる相対見積もりなどやるだけ無駄です。

また、長期的な見積もりは間違っても、短期的な見積もりを大きく外すことはあまりありません。

もしスプリント計画を大きく外したとしたら、見積もりと計画をサボっているか、そのスプリント内の作業をサボっているか、どちらかでしょう。

スプリントの成果にコミットメントするとなったら、真面目に見積もります。

見積もるだけじゃなくて、成果を上げるための計画も練るはずです。

毎回のスプリントプランニングの精度が、スプリントの成果の大半を決めます。

それほどスプリントプランニングは重要なイベントなのです。

コミットした事はやり切る

コミットしたならやり切りましょう。

やり切る為には、各チケットの完了条件・着手順・TODOなどを可能な限りスプリントの初期段階で精度を上げておきたいです。

チケットの粒度が大きければ、担当者が1日以内に完了できる粒度まで分解しましょう。

誰が何を着手するべきかを各担当者にまかせてはいけません。その瞬間に一番ふさわしい人物が着手できるように調整をするべきです。

デイリーの会議だけではなく、日になんどもこの調整を入れる時もあるかもしれません。

個人の作業が滞る原因は常に取り除く努力をしましょう。

勉強会やペア(モブ)プロなどそのチームや状況にあったやり方はあると思います。

相談し易いコミュニケーションのツールや仕組みも改善余地があるかもしれません。

このスプリントだけやりきればいいわけではありません。

全スプリントやり切る必要があります。100%の力で走り続ける前提は破綻します。

80%の力でも必ず成果を出す為にはどうすればよいかをチーム・個人で知恵を振り絞らなければいけません。

時には短期的な生産性を犠牲にしてでも、後続のスプリントの成果を高める取り組みを選ぶ必要性もあります。

この様にチームやプロジェクトの状況によって、やり切る為に必要なことは異なります。

だからチームで定期的に振り返り、どうやったら約束した成果を挙げられるのか？を真剣に話し合い、改善につなげる必要があるのです。

徹底的に、コミットメントしたことをやりきれない理由を排除してください。

見積もりが悪いとか、納期が厳しいという話をする前に、自分たちのできる限りの最善を尽くす事から始めましょう。

約束を守れない時は早く言う

ここまで努力を積み重ねてもなお、コミットメントした成果に届かないこともあります。

そんな時は、それがわかったらすぐに然るべき人間に報告しましょう。

悪い内容の報告は早ければ早いほど価値があります。直前で間に合わないことを伝えられても無価値です。

毎週やり切るマインドのチームが、できないと判断した事はたいてい本当にできません。

できないことは早く分かれば対処はできるものです。

徹底的に自分たちができることをやり切っているチームは、スプリントで積み重ねた成果によって、自然にステークホルダーから信頼されています。

信頼しているチームからの悪い報告を受けた時、「よく教えてくれた」と感謝をし、建設的な代替策を一緒に考えたくなるものです。

間に合わなくなってから、営業やマーケティング、POなどの悪口を言う様なレベルの低いチームにはなってはいけません。

以上。毎週当たり前の様にやり切るチームになりましょう。