アジャイル開発で「WIP（進行中の作業）数」を制限すべき理由、メリットとは？：多忙な開発業務を効率的にこなす方法

アジャイル開発者は、進行中の作業数を制限することで、プロジェクトの完了を早めることができる。進行中の作業数に制限を加えるとどのような変化が生まれるのか。

[Matt Heusser，TechTarget]

　アジャイル開発チームは、進行中の作業（WIP：Work In Progress）を数多く詰め込むのではなく、1つのプロジェクトを完了させることに専念すれば、多くの機能をより迅速に市場に投入できるようになる。

　マルチタスクはパフォーマンスを低下させる。だが、核となる開発プロジェクト、試験的な補助プロジェクトなど、開発者の日々の業務が不足することはない。そのため、ソフトウェアチームは、開発者の手が空けばすぐさま仕事を詰め込む習慣に陥りがちだ。

　本稿では、アジャイル開発にWIP制限を追加すると、ソフトウェアの納期がどのように変化するのか、アジャイル開発チームのWIPを制限する方法と交えて解説する。

アジャイル開発のタイムライン

　ソフトウェア開発プロジェクトに費やされる時間を理解するために、まず最もシンプルなプロジェクトシナリオを考えてみる。開発者1人で構成される開発チームがあり、必要な開発ソフトウェアは全てそろっているものとする。この開発者が3つのプロジェクトに取り組み、コーディングからテストまでのワークフローを完了するには各プロジェクトで30日かかるとする。開発者が各プロジェクトを1つずつ順番に完了していくと、プロジェクトは30日目、60日目、90日目に完了する。この場合、プロジェクトの平均完了日数は60日間となる。開発者がプロジェクトの切り替えコストが発生しない前提で（1日に1つずつ）並行作業する場合、各プロジェクトがそれぞれ88日目、89日目、90日目に完了する。この場合、プロジェクトの平均完了日数は89日間になる。

　先述したシナリオでの平均完了時間は60日と89日で、プロジェクトを順番に完了していく方が市場投入までの時間が30％以上短くなる。実際には、ほとんどのプロジェクト間には依存関係があり、チームのメンバーも多く、プロジェクトが異なればタスク間で、注意を切り替える必要があるため、生産性は大きく低下する。

　こうした要因を考えると、ソフトウェアチームの効率は理想状態と比べて10％以下に低下する。コンセプトを決めてから製品化まで1日で終わるはずのプロジェクトが数週間から数カ月掛かる可能性がある。

　また開発者の待ち時間は無駄だと考えられ、WIPは増えていく傾向にある。一度に5〜8件のプロジェクトに取り組む1つのソフトウェアチームがあるとする。各プロジェクトはどこかで待機状態が発生する。要件に対する疑問の答えを待つ時間、データベースを使用するのに必要な権限がプログラマーに与えられるのを待つ時間などだ。プログラマー全員が同じ部屋でそろってプロジェクトに取り組み、順番に仕事を完了していけば合計2週間で終わるとしても、こうした待ち時間が多くなれば、2〜3カ月掛かる可能性がある。

　待ち時間はリーン開発でよく起きる問題だ。待ち時間を可視化したら、障害やボトルネックを見つけて解決する時間に割り当てるのが正しい対処方法だ。だが、多くの企業がその待ち時間に、多くの仕事を詰め込んでいる。WIPを増やせば、業務を兼務する時間的余地は改善される。だが、応答性が低下し、優先順位が混乱して、割り当てを変える際にチームの精神的エネルギーが消耗する。

カンバンにおけるWIP制限で生み出される効果

　アジャイル開発での作業は、カンバンボード上のカードで表される。プログラマーはカンバンボード上のカードを左から右へと順番に作業していく。ボード上の各列には複数のスロットがある。スロットの一番下よりも下にはカードを追加できない。チームは、通常、プロジェクト管理ソフトウェアを活用して作業する。だが、そのアプローチは物理カンバンボードでモデル化され、同じ機能性を維持する。

　最新のソフトウェアチームは、以下のようなアジャイルプロジェクト管理ツールを使用して開発プロジェクトを追跡する。オンラインのツールは、標準ビュー、スクラムビュー、カンバンビューを提供するのが一般的だ。大半のカンバンテンプレートでは、WIPの制限が利用できる。

• Atlassianの「Jira」
• Microsoftの「Teams」
• Pivotalの「Pivotal Tracker」
• Planviewの「Planview AgilePlace」

　チームのメンバーがボードの左端の列「バックログ（backlog）」からワークフローに作業を取り込む（プルする）には、メンバーのスロットが空いている必要がある。スロットが満杯状態のメンバーには作業を追加することはできない。その場合は、WIPを行うことで他のメンバーを助けることになる。

　WIP制限付きのアジャイル開発ワークフローの例を示す。例に挙げるカンバンボードの「コードレビュー（Code review）」列には、スロットが1つしかない。プログラマーペアが作業を完了し、コードレビューを希望していても、その前に他のメンバーがコードレビューを実施し、「コードレビュー（Code review）」スロットが埋まっていると、そのプログラマーペアは自身のカードを「コードレビュー（Code review）」列に追加することはできない。このプログラマーペアは新たな開発作業を取り込むのではなく、ここで作業を停止して、コードレビューを提供しなければならない。このアプローチは、次のステージが空き状態の場合に作業を取り込むプルシステムになっている。ほとんどのソフトウェア開発プロジェクトはプッシュシステムで、作業を完了し、次のステージに移行することに重点が置かれる。

WIP制限付きのアジャイル開発ワークフローの例（提供：米TechTarget）

　アジャイル開発にプルシステムを導入する場合は、WIPの制限を設定すべきだ。上記の例では、空きスペースの設定数がWIPの制限数になるように意図されている。列ごとの空きスペース数を変えて、WIPの制限数を変えても構わない。その列のスロットが満杯であれば、新たなカードを追加できなくなるだけだ。

WIP制限数をどう設定すべきか

　WIP制限数の最もシンプルな標準は、作業単位ごとに1つのスロットを用意することだ。

　6人の開発者がペアで作業するチームと3人のメンバーからなるQAチームがあるとすると、カンバンボードに3つの「開発中（In development）」列と4つの「テスト中（In testing）」列を用意しても構わない。このチームでは、「コードレビュー（Code review）」「ストーリーキックオフ（Story kickoff）」や「テストケースの作成（Test case creation）」「デプロイ待機中（Waiting for deploy）」といった列を追加することになるだろう。チームがより多くの作業を取り込む（プルする）ことができるよう、各列のWIP数を制限する。

　緊急作業用にスロットを1つ追加するチームがあっても構わない。このスロットで緊急の解決に対応する。この列を追加することは、主に管理に役立つ。必ず対処しなければならない作業があるチームは、WIP制限を1つ増やすことで柔軟性を確保することができる。この追加スロットにより、緊急作業が目に見えるようになり、追跡や計画が可能になる。緊急作業の量が多すぎることが分かれば、振り返り作業や是正措置を促す必要がある。

　全体的なスループットや遅れの確認を2週間ごとに行い、WIP数を減らしたり増やしたりしながら簡単な実験を行うこともできる。

過剰作業に対処する方法

　一方で、ソフトウェア開発においては仕事の速度を奪う予定外の作業がよく起こる。この問題に対処する1つの方法は、WIPに緊急の例外を設けることだ。パフォーマンスの基準が分かっているチームなら、マイクロ機能や修正作業をエスカレーションする影響を理解し、予測して、モデル化できる。問題はこうした修正作業が大量に発生する場合や、予定外で非公式な場合だ。これを解決するには、組織の文化を変える必要がある。

　予定外の作業の合計時間が、チームが定めた1週間当たりの作業時間を超える場合は、その作業を1つのタスクとして記録し、正式なプロジェクトシステムを経由させなければならない。こうした変化は最初は不快に感じるかもしれない。だが、こうした変化によって、予定外のプロジェクトと実際の優先事項が区別されるようになる。

　WIP制限数を増減しながら機能を市場にリリースするまでの時間を追跡しているチームなら、予定外のプロジェクトやマルチタスクを行う場合にどれだけ負担が起きるのか、定量的に判断できるようにもなる。