カンバンにおけるCONWIPとそのメリット。CONWIPとはなんぞや
この記事はFringe81 Advent Calendar 2019の10日目の記事です。前日は@Hase8388さんのthunderbolt⚡ on gokartでパイプラインの出力結果をサクサク確認する - Qiitaでした。
皆さんはじめましてFringe81株式会社でチームファシリテーターをしている @pastelInc と申します。よろしくお願いいたします。
今日はメタプロセスツールのカンバンを取り上げてみようと思います。カンバンの基礎については触れません（ごめんなさい！）。
カンバンにおけるWIP制限の方法
カンバン仕事術という本があります。この本の中でカンバンにおけるWIP制限の方針として2つのアプローチが提案されてます。
チーム全体のWIP制限と列ごとのWIP制限です。
Google等で検索すると列ごとのWIP制限の事例がたくさん見つかるはずです。なので今回はチーム全体のWIP制限のメリットと事例をお伝えできればと思います。この記事ではチーム全体のWIPをCONWIP (Constant Work in Progress)と呼びます。
CONWIPとはなにか
CONWIPというのはWIPと同じく自動車を始めとする製造の分野からの考えをもとにしています。もともとは同じ種類のアイテムを繰り返し生産するシステム用に設計されました。これはスループットをコントロールするためのパラメータです。 例えば、工場で生産する部品Aと部品Bがある場合、Aの需要がBよりも見込まれるときにはAのCONWIPを増加させてBのCONWIPを低下させます。このような単調な例だと結果としてAのスループットが増大します。アイディアの源はこの考えです。 ですが、当然この考えをそのままのシステム開発に適用はできません。
なぜならCONWIPを増やしたからといっても単純にスループットは増大しないからです。これはカンバン仕事術からも明らかですね。全体のWIPが増えるのですから流れが遅くなるためです。ならばこの考え（CONWIP）はどのように利用できるのでしょうか。
CONWIPの制限を利用する
そこでCONWIPを制限に利用してみましょう。CONWIPを制限してみます。
開発チームの担当する開発フローへの入力と出力のメトリクスをとったときに、入力に対して出力が思わしくないことがあります。つまり、価値の提供までのフロー全体を見たときに開発がボトルネックになっている場合です。このとき過剰なまでにカンバンシステム内に作業が追加されていることがあります。こうしたシーンではCONWIPを制限すると、入力と出力のバランスを保ちながらスループットを最大化させることができると考えています。
カンバン仕事術ではプランニングのときにどの程度の作業を追加するべきか特に述べていなかったと思います。イテレーションの開発を行っている場合、イテレーション期間で期待できる出力に対して過剰にならない程度の入力をするべきだと思われます。その目安となるのがCONWIPです。
CONWIPは列ごとのWIP制限のうち最大のものより小さくなることはありません。例えば受け入れ列がWIP3であり、これがカンバンシステム全体で最大に制限されているならば、CONWIPは3以上のはずです。CONWIPが2であれば列にWIP3の制限をする必要がないからです。
列ごとのWIP制限でも可能ですが、開発チームへの入力と出力に着目できる点とプランニング時にどれだけ追加するのか目算をたてる事ができるという点にメリット感じられるのであれば列ごとのWIPと併用してみてはいかがでしょうか？
注意点があります。CONWIPは列ごとのWIP制限よりも調整パラメータが少ないので運用が容易ですが調整パラメータが少ないため、CONWIPの制限だけでは流れの管理が難しいです。よくよくカンバンを見てボトルネックの特定と流れの管理をしっかりやってみてください。
他にもCONWIPはカンバンの工程の変更の影響を受けにくいです。カンバンを導入したてでひっきりなしに工程が変更されるうちはCONWIPで運用するのはいかがでしょうか。
最適なCONWIPは常に更新し続けるしかないと思います。安定した開発を目指すためにCONWIPを制限してチームのスループットを最大化させましょう。
