検索
  • 岡島一樹

巨大な縦割り組織の中のほんの一部でアジャイルやってみた(大事だったこと編)

更新日:11月12日

こんにちは。Agile Studioの岡島一樹です。


前回の続きになります。

前回の記事が気になる方はこちらをご覧ください。

巨大な縦割り組織の中のほんの一部でアジャイルやってみた(導入編)


今回は、巨大なウォーターフォールプロジェクトの中でアジャイルやる上で

とても大切だったことについてお話します。

内容的には当たり前の事なのかもしれませんがお付き合いください。



プロジェクト全体はあくまでウォーターフォール

ウォーターフォールプロジェクトに合ったリズムを作ることが大事!


まず大事なことは、プロジェクト全体はウォーターフォールで動いていることを前提に

考えなければなりません。

ウォーターフォールプロジェクトと言えば進捗定例会はつきものですよね。


今回のプロジェクトでは週一回・月曜日に週次進捗定例会を実施しており、

フロントエンドチーム内の各チーム毎に進捗報告を実施しています。

よって共通部品チームも例外なくこの進捗定例会に出席して毎週進捗を

報告しなければなりません。このチームにとってはとても大事なイベントです!


ということでこのチームでは以下のような感じでスプリントをまわしていました。

進捗定例会を軸に他のイベントの時間割を決めていきました。



大事だったことその1:進捗報告

バーンアップチャートとトレンドの把握


フロントエンドチーム内の各チームはガントチャートを基準にチームの進捗を

報告するのですが、共通部品チームにガントチャートはありません。

というか作れないのです。

Issueの数は目まぐるしく変わっていきます(増えることがほとんどですが)。

優先度も刻々と変化していく中でガントチャートを引くことは現実的ではありません。


そこで共通部品チームではリリースバーンアップチャートを作り、チームの状況を可視化できるようにしました。前述の通りバックログの数は日々増えていくため、バーンダウンではなくバーンアップを選択しました。

ではここで共通部品チームが直面した3つのトレンドについてご紹介します。


パターン①

(参考情報)

  • 青線がバックログの残ポイント数です。

  • オレンジ線がチームが消化したポイントの合計です。


これは理想的な状態のバーンアップですね。

残ポイント、消化ポイントともに増えていっていますが、差が縮まってきています。

残ポイントの増加は減らないにしても、チームの消化が追いついてくれば追加されたバックログも早く対応できそうですね。ゴールも近そうです。


パターン②

次に、こんなバーンアップではいかがでしょうか?


これはかなり厳しいですね。

増加分に対して消化が全く追いついておらず、逆に差が広がっています。 通称「ワニの口」状態と呼んでいました。

トレンドがこのような状態が続くのであれば何か対策を打たなければなりません。


まずチームで対策できそうなことを考えてみます。

  • バックログが増えている原因の究明は必須

  • 障害が原因であればなぜ障害が増えているのかの根本原因を話し合う

  • エンハンス系のバックログであればある程度仕方ないものの、まだIssueとして起票されていないバックログはないか話し合ってみる。

  • ベロシティを上げるためにできることはないか

  • チーム活動の障壁となっている何かがあれば取り除く 例えばこの作業面倒なんだけどなんでやっているのかいまいち分からない →作業の必要性を議論してみて不要であれば思い切って除外してみる

  • スキルが足りなくて難易度が低いIssueしか対応できない →スキルが高い人に属人化しがちな作業を分担してできるようにしていく →チーム内で勉強会を開いてチーム力を上げていく


それでも「ワニの口」が閉じなければマネージャーに相談して開発者を追加してみる

なども考えられます。


パターン③

最後にこんなバーンアップはどうでしょうか?


うーむ。微妙ですね(笑)

良くもなっていないけど悪化もしていない。平行線です。

これをどう見るかはチームによるとは思いますが、私ならパターン②と同じ対策は

講じた方が良いかなぁと思います。

マネージャーからすれば「いつ終わんのこれ?」ですからね。

共通部品チームではこのパターンのトレンドが一番多かった気がします。


大事なのは週次進捗定例会で

  • バーンアップチャートは常に最新化しておき、現在のトレンドをマネージャー含め 誰もが一目で把握できるような状態にしておくこと

  • チームは現状を正確に報告できるようにしておき、アラートは素早く上げること


現状の問題点の見える化ができていればマネージャーも判断が可能です。

開発者が足りなければ追加される可能性もありますし、現状で良しとする判断も可能性としてはあるでしょう。このあたりはアジャイル、ウォーターフォール関係ないですね!



大事だったことその2:リファインメント回数

週一回では全然足りない?


ところでバーンアップチャートの残ポイント数ってどうやって算出していたと思いますか?日々Issueが起票されるのですが、共通部品チームが日々の対応に追われ、起票されたIssueを放置していたらどうなっていたでしょうか?仕様の検討ができないのはもちろんのこと、ポイントがつかないIssueが増え続けてしまいどれぐらいの残作業があるのか誰も把握できなくなってしまいます。つまりIssueの数は増えるけど青線が引けない事態になってしまうんです。


するとチャートはこんな感じになりますね。


一見すると順調そうに見えますね。

ですが、裏にはまだポイントがついていない大量のIssueが・・・


実は共通部品チームも一度このような状況になりかけたときがあります。

当時は週一回リファインメントをやっていましたが、週一回ではとてもバックログをさばききれていませんでした。そこには巨大システムが故の苦労もありました。

一つの共通部品の修正が数百画面にも影響を及ぼす恐れがあるため、リファインメントも慎重にならざるを得ません。ひとつのIssueの検討に相当時間がかかってしまうのです。


そこでリファインメントを週三回に増やして、仕様検討・見積もりのスピードをあげました。最初は苦しかったですが、徐々に上述のような状況は解消していき、最後は起票されたIssueは即リファインメントして見積もれるようになりました。

結果的に青線もしっかり引くことができました。


また、リファインメントをしっかりしていないとプランニング時に苦労しますよね?

いざプランニング始めてみたけど、このIssue何するんでしたっけ?

のような状態ではプランニングが延々に終わりません。


仕様検討・見積もりまでしっかりできてこそIssueは着手可能の状態にあると言える (と思っている)ので、リファインメントを甘くみないようにしましょう。


共通部品チームではリファインメントに時間を割くことでプランニングでは

  • タスクの洗い出し

  • スプリントゴールの設定

など本来やるべきことに集中できるようになりました!


以上、本日はここまでになります。

次回に続きます。


147回の閲覧0件のコメント

最新記事

すべて表示