アジャイル開発の長期プロジェクトを遅延させない方法

どうも、プロジェクトが遅延するたびに坊主にするスクラムマスターIwaoです。

今回は長期のプロジェクトが遅延する理由を実体験をもとに分析をしてみたいと思います。アジャイル開発を前提として、再発防止を目的として書いています。専門用語モリモリですので辞書を片手にお読みくださいw

要因ごとなぜなぜ分析をして原因を特定してから対策を書いていますが、今回はnoteに公開するために特定されないようにディテールをぼかしてサラッと書いてます。ただ記事はかな〜り長くなりました…

1 マネージメント要因

先にオチを言ってしまいますが、プロジェクト遅延の責任はほぼマネージャーにあります。スクラムではプロジェクトマネージャーはいないんですが、スクラムマスターがプロジェクトマネージャーに近い役割と言われています。プロダクトマネージャーとかプロダクトオーナーとかプロジェクトマネージャーややこしいですよね。

1-1 長くても3カ月間隔で動く製品をリリースする

アジャイル開発の原則の１つで「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」に沿ってリリースの速度を意識することです。1年や2年かかるプロジェクトだとしても社内リリースでもいいのでデリバリーコストをケチらないで動く状態のプロダクトを出荷することがマストです。3ヶ月あればデプロイしたり動作確認できる環境は作れます。このときの配布する間隔でマイルストーンを設定するとスマートです。

それから製品を関係者に晒してビジネス側にフィードバックをもらいましょう。そのためにユーザストーリーごとに開発を進めていくことが必要です。

色気を出してウォーターフォールのように全画面の骨組みだけ先に着手したり、画面と機能で分業したりすると、動く製品を作る原則から遠回りすることになるので注意が必要です。

1-2 見える化のために全体バーンダウンチャートを用意する

ステークホルダーは長期プロジェクトの予算は大きいので進捗はより気になります。しかしタスクが多すぎるので細かく管理することが難しいです。なのでプロジェクトの長期計画と進捗を要点を抑えて見える化しましょう。

キックオフ前に全てのユーザストーリーを洗い出すことから始まります。そして全てのユーザストーリーをプロダクトバックログに積んでおきます。このときにユーザに影響の出ないリファクタリングやアーキテクチャなどの工数は分離するようにしましょう。ステークホルダーはそういう工数があることが理解できれば問題ありません。

全てのユーザストーリーにストーリーポイントを割り振って、長期的なバーンダウンチャートを作ります。社内リリース、顧客リリースなどの日付もプロットしてください。個別のベロシティを開示するのも人員計画の参考になるので大事な情報です。

1-3 リリーススプリントは効果的ではない

リリーススプリントはアジャイル界隈でも賛否分かれているようですが、個人的にはアンチパターンだと思っています。ウォーターフォールのように最後のリリーススプリントにリリース系タスクを積んでしまいがちになります。そうなるとリリース系タスクに問題が見つかった瞬間にリリースが遅延するからです。致命的なバグやアーキテクチャの欠陥などが考えられます。

アジャイル開発の経験不足の組織にありがちな罠です。リスクは早期に回避するためにプロダクトオーナーは責任を持って歩み寄り、スクラムチームはしっかりとコミュニケーションを取らなければなりません。

1-4 課題は定期的にステークホルダーに共有する

定期的にプロダクトオーナーとスクラムマスターはステークホルダーとプロジェクトの状態を共有してください。そこでスクラムチームのふりかえりで出た課題を全て共有します。その中でも経営資源に影響のある課題を議論して組織のアクションを定義します。例えばチームメンバーの追加・再配置、タスクの削減、リリース日の調整などがあります。

特に長期プロジェクトだとなあなあになりがちです。チームメンバーもふりかえりはアラートを出せるチャンスだと思って、あらかじめ課題感を把握しておくことが求められます。

1-5 スクラムチームの原則・カルチャーを布教する

プロジェクトつまりスクラムチームのルールを言語化しましょう。長期プロジェクトだとだんだんどうでもよくなってきて、ルールが浸透されずに放置されることがあります。

プロジェクトの規則を作るのはマネージャーの仕事です。ルールを厳しくするの、緩くするのもマネージャーの腕です。最低でもアジャイルソフトウェアの12の原則を、可能ならそれをアレンジして徹底的に布教しましょう。壁に当たったときや人員が増えたときに役に立ちます。

2 見積り要因

遅延とは見積工数と実工数を比較して実工数のほうが大きい状態のことです。だから見積りに原因があると思いがちですが、あくまでも要因です。原因はなぜ見積りがズレたのか、なのでその観点で見積りワークの要因を分析しました。原因と要因は違うのって紛らわしいですね。

2-1 画面とか機能とかの単位でプランニングしない

画面や機能ではなくユーザストーリーを意識して見積もりをしたほうが精度が出やすいです。同じ画面をUI側とビジネスロジック層で分担するよりも、ユースケース層で分担するほうが、担当する範囲が明確になり構造上も衝突リスクを減らすことができるためです。

ウォーターフォールの思考だと、画面一覧表と機能一覧表を作って難易度を割り振ってしまいがちですが、ここではアジャイルつまり動くソフトウェアと高速デリバリーを意識することが大切です。

2-2 ユーザストーリーとアーキテクチャのベロシティを分離する

ユーザーストーリーの実現には画面・機能・仕様が必要不可欠ですが、アーキテクチャみたいにプロダクト全体に関わる要素を混ぜて見積るとどうしてもムラが発生しやすくなります。

いっそのことユーザストーリーとアーキテクチャは担当を分けることを推奨します。そしてアーキテクチャはユーザストーリーと切り離して見積りましょう。なぜならアーキテクチャはユーザに見えないけど生産性の高いワークで、それがデリバリーのボトルネックになってはいけないからです。

高い品質を求めるのであればなおさらアーキテクチャにウェイトを置くことが求められると思っています。

2-3 ユーザストーリーとデリバリータスクのベロシティを分離する

長期プロジェクトだとプロジェクトの最初の段階では、デリバリーの準備のためのタスクが多くなるのでベロシティ値の確実性に欠けます。

最初からユーザストーリーとデリバリー系タスクは課題を分けることができれば数値がより正確になるでしょう。なるべくルーティンワークは最初の段階で分離させておき、クリーンなユーザストーリーのベロシティで見積りを立てることが計画の精度を上げることに繋がっていきます。

2-4 新しい技術のリスクヘッジ

新しい技術を導入する場合、ドキュメントが不十分だったり、バグなどが多くてベンダーに問い合わせをしたり、見積りの不確実性は増すことになります。最悪はそれらを使えないということになるかもしれません。

リスクヘッジのためにそこの工数はこれでもかってくらい大きくバッファを取っておきましょう。

2-5 自動テストのリスクヘッジ

自動テストのコストは尋常じゃないほど大きいです。下手に組み込もうとするとビルドなども含めてボトルネックになりがちです。可能なら自動テストは専属の担当を用意するほうがよいでしょう。

それが難しいのであればリリース後にやったほうが良いかもしれません。ただそうだとしても自動テストをアーキテクトなりQAなりにの責任を割り振ることが賢明です。なぜならリリース後に大規模なリファクタリングが発生するリスクヘッジが必要だからです。

2-6 リファクタリングのリスクヘッジ

リファクタリングのコストはサボろうと思えばゼロに出来ますが、可読性を下げ全体的な品質を低下させる技術的負債の大きな要因です。

全体工数の20％を積んでリファクタリングに当てましょう。プロダクトマネージメントの父もそう言っています。

3 チーム内要因

開発体制や役割・責任範囲などチームの構造に起因する要因から分析しました。理想の体制が組めていればとか、個々のスキルが高ければというのは妄想だと思っています。これこそファクトを元に原因を落とし込みました。

3-1 開発体制を固めることを最優先にする

大規模な開発ですから開発体制は最も重要です。ユーザストーリー2名、アーキテクチャ2名みたいに1つのロールに2名以上のアサインは必要です。なぜならクロスレビューを行って品質を上げるためです。

組織的にはシニアとジュニアのバランスを考えられると尚可という感じかなと思います。メンバーは揃ってないけどとりあえず見切り発車することは長期プロジェクトだと命取りです。手戻りリスクが高いので危険ですね。

3-2 全てのメンバーでプランニングをする

最初にリリース日を決めるとかプロダクト全体のプランニングをするわけですが、そこにチームメンバーも含めてプロダクトプランニングに参加してもらうほうがよいです。

全体像を把握してもらうことで、やってもやっても終わらないんじゃないかという不安を払拭するためです。生産性に影響します。ふりかえりのときにもプロダクトプラニングにアップデートはなさそうか、スクラムチームで確認し合いましょう。

3-3 QAとUI/UXデザイナーをスクラムチームに入れる

QAとUI/UXデザイナーはスクラムチームに入れたほうが効果的です。QAには仕様のオーナーシップを持ってもらい、UI/UXデザイナーにはユーザストーリーのオーナーシップを持ってもらい、品質を上げるためにフィードバックをもらうと効果的です。

QAとUI/UXデザイナーは他プロジェクトと兼任することが多いですが、その稼働率は組織側の課題なので出来る限りコミットしてもらいましょう。

4 チーム外要因

チーム外つまり組織に起因する課題になります。本来やるべきではないことをチームでやったために、プロジェクトの遅延に繋がるケースは少なくありません。特に要件定義はかなりのインパクトがあります。

4-1 要件定義はユーザストーリー全パターンを出す

要件定義書みたいなドキュメントが長いだけで質が薄いケースが多く、読んで仕様を理解するだけでチームの工数を食いつぶしてしまいます。アジャイル開発では生産性を重視していますので、要件定義はユーザストーリーないしはユースケースを言語化することになります。

つまり要件定義者は開発を理解していないとダメです。プロダクトオーナーでもプロダクトマネージャーでもいいですが、論理的な思考が出来ることとアジャイル的な思考が出来ることの両軸が求められます。どちらかが欠けるとプロジェクトが失敗する確率は飛躍的に上がる感覚です。

さらに全てのユーザストーリーが出てからストーリーポイントを振って全体の計画とリリース日が決まります。つまり要件定義と見積りはセットです。ゴールを設定してから開発プロジェクトをスタートさせましょう。

4-2 要件定義側のタスクには手を出してはいけない

スクラムチームでは仕様がおかしいとかわからないときに速やかに対応するための仕組みを考えています。しかし要件定義側で仕様書を放置していたり仕様を把握していなかったり、準備不足のケースが結構あります。

もはやアジャイルでも何でもなく仕様は要件定義側で責任を持つわけなので、プロダクトオーナーやスクラムマスターは仕様を考えるとか仕様書を書くことに時間を割かずにチームのことに集中しましょう。

4-3 ビジネス側にもアクティビティに参加してもらう

スクラムチームはプロダクトマネジャーとスクラムマスターが入れば成立しますが、アジャイル開発の原則に「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」と書かれています。これはビジネス側とのコミュニケーションが必要になるためです。

なぜならビジネス側は機能追加や要件変更などマーケットの動向を見て提案する責任があるからです。長期プロジェクトだとその機会は多く、スクラムチームは「要求の変更はたとえ開発の後期であっても歓迎します」と言っているわけです。

ビジネス側のメンバーはスプリントレビューなどのアクティビティにだけ出てもらうことが望ましいです。アジャイル的な思考が出来ることが求められます。

4-4 人員配置・採用を積極的に推進する

マネージメントタスクのうちコーチング・目標設定はスクラムマスターが担当するケースが多いです。しかし人員配置・採用はスクラムチームの責任ではありません。

しかしゴールに影響が出るような体制の不足や不備は課題です。しつこいくらい人員配置・採用をプッシュするようにしましょう。そして候補者にはスクラムチームで面接を行い、一緒に働けそうか見てもらうとミスキャストの確率を減らすことができます。

まとめ

一般的なマネジメント論では人的エラーは許容する必要があると思ってて、プロジェクトの遅延に関わらず原因分析をするときは、WhoではなくWhyを軸に考えることがセオリーですので、誰かのせいにしないように注意してください。個人に起因することはほとんどありません。

また長期プロジェクトはマラソンです。心身の安定がエネルギーでありペースを乱されるのが一番のダメージです。しかし時間がかかる分だけチーム外からのノイズも入りやすくなります。スクラムチームはマラソンをしているわけなので、チーム外の方は沿道で応援をするだけで十分です。

最後にプロジェクト遅延の責任はマネージャーにあると思っているんですが、エッセンシャル思考の名言「自分の失敗を認めたとき、初めて失敗は過去のものになる」とあります。マネージャーは失敗を受けいれるのには抵抗はあると思いますが、その分以前より賢くなったと考えて前進していきましょう。