【アジャイル】たった5分で激的にタスク消化率を向上させる方法

「SIerでもアジャイル開発がやってみたい」ということで、アジャイル開発を始めてから4ヶ月が経ちました。

今後、「自分のプロジェクトでもアジャイル開発をやってみたい」と思われる方が、長い時間をかけて同じような試行錯誤をすることは非常に無駄な時間だと思います。

なので、自分たちが困ったことや悩んだこと、やったことを共有して、少しでも楽しいプロジェクト運営のお手伝いが出来たらと思ってます。

という声が聞こえてきそうですが、そんな方でも、チーム形成やタスク消化をしていくという点ではアジャイル開発と同じです。

そのため、アジャイル開発を採用する予定がない方でも役に立つ情報があると思います。

ということで、アジャイル開発4ヶ月目のチームの歩みを紹介したいと思います。

アジャイル導入したての頃の記事はこちら！

たった5分の会話で激的なタスク消化率向上

現在、座席レイアウトは背中合わせで6人が座っており、クルッと椅子を回すと皆が円となり話せる環境です。

※いちいち回り込まなくても、それぞれのモニターが見えるので、対面よりも背中合わせのレイアウトがオススメです。

一枚のSBL(スプリントバックログ)にかけて良い時間を2時間までと定義しているため、それが終わるだろうというタイミングで一度クルッと椅子を回してお互いの状況を確認します。

多くても5分くらいの会話です。

話す内容は以下のようなものです。

前までは、朝会という形で前日にやったタスクや困ったことを共有していました。

前回までのスプリントの反省点で皆で同じタスクをやりすぎて、必要以上に工数がかかった経験がありました。

しかし、現在では一度少人数でやってみて、ハマりどころや相談事が発生して、もっと人数をかけた方が良いと判断した場合は、適宜ペアプロやモブプロに切り替えたり、会議体を設けたりしています。

皆で共有するタイミングを朝会ではなく、もっとリアルタイムにしたことで、タスクを消化していて、大ハマリではないけれども、やっている内に何かエラーが出た時とか、「報告するまでもないかな」と気持ち的に後ろ向きになることも話しやすくなりました。

その結果、タスク消化率が上がり、進捗率も良くなりました。

朝会は前日の振り返り会ではなく、その日の「タスク完了条件を確認する会」になった

上記のようにその日のうちのタスクは、リアルタイムに確認することになり、朝会で確認することがなくなりました。

スプリントを始める際に、「このスプリントではどんなことをやろうか」ということを決めるスプリント・プランニングという会議があり、そこで実施するタスク内容をSBLとして書き出します。

その際、完了条件も同じく考えるのですが、時間が立つと、それぞれ忘れたり、違う解釈になっていったりしました。

その結果、「あれ、思っていた成果物と違うな」という状況がポツポツと出てきていました。

そのため、朝会では「完了条件を再確認する」ということを話題に上げるようにしました。

SBLの作り方を変えて、計画のズレは許容するようになった

進捗管理について、もう一つ改善したことがありました。

SBLの作り方についてです。

スプリント計画時にそのスプリントで行うタスクをSBLとして作成しますが、どうもSBLを作りすぎてしまう傾向にありました。

スプリント計画時は、不確実性が非常に高いので、後でタスクが不要になったり、最悪の場合はタスクを大幅に追加しなくてはならない事態が発生しました。

また他チームからの開発支援依頼等、割り込みタスクも多く発生していました。

そんな状況に陥っていました。

そのため、KPT(振り返り)の結果、以下のように改善しました。

KPTで振り返り反省をすると、「計画時の見積もりが甘いよね」という話にどうしてもなります。

「じゃあどうやったら見積もり精度が上がるのか」という話をすると、「もう少し計画を入念に練る時間を作ろう」とか、「タスクの内容をもっと詳細に決めて、SBLに書いていこう」とかたくさんのアイデアは出ます。

しかし、こういう議論を繰り返していく内に、どうも「正解のない問題をひたすら解き続けている」という感覚に陥りました。

もちろん、見積もり精度を上げていく努力を諦めたわけではないのですが、「ある程度、見積もりが甘くなるのは許容して、タスクが増えても余裕があるように構えていこう」という考え方に至りました。

「あれ、これってバッファって言うんじゃない？」

と、チーム内でも話になりましたが、アジャイルの世界ではどうもバッファを予め計画しておくことは、スピード感を失うということで、「バッファは積まない」という考え方があるようです。(諸説あり)

その結果、SBL増加は相変わらずあるものの、理論上の上限値である180SBLは超えない程度に調整をしながら、何とかタスク崩壊することを避けてきています。

まとめ

この4ヶ月目は３ヶ月目と同じく、「タスクファースト」でアジャイル開発を進めていました。

まとめると、以下のような感じです。

時間軸	ファースト(優先事項)	やったこと	効果
1ヶ月目まで	アジャイル開発のやり方を理解する	カンバン方式	タスクの見える化
2ヶ月目まで	チーム理解と関係構築	ペアプロ、モブプロ	チームメンバーのやり方と考え方を学習した。 チームの皆が好きになって、仲良くなった
3ヶ月目まで	タスク消化	少数チーム化と効率化	今までの良いところを維持しながら、タスク消化率が上がった
4ヶ月目まで	タスク消化	・リアルタイムな進捗確認 ・朝会では完了条件の確認 ・SBLの上限数を設けて予定外を許容	・タスク消化率のさらなる向上 ・正しいものを作る力の向上 ・計画外の出来事が起きても対応出来るチームに

ここまでの体験談はアジャイル開発をする人にはもちろん、ウォーターフォール開発で頑張っている人たちにも、どこか自分のプロジェクトに組み入れて使うことが出来そうな内容だと思っています。

特に、「改善を日々の業務の一部として取り入れる」という意識が大切です。

特に皆で自分たちの仕事を振り返り、そして、「今後はどうするのか」ということを定期的にプロジェクトメンバーと話し合うことで、改善のサイクルが回っていくと思います。

さて、今回はアジャイル開発4ヶ月目の取り組みをフィードバックさせて頂きました。

またここまでのアジャイル開発については、以下の書籍を参考にしていますので、もし興味を持ったら読んでみて下さい！