Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

カンバンはTOCだったのだ

bookmeter.com
asanaを使ってみながら、
『カンバン仕事術』『カンバン ソフトウェア開発の変革』をさらさらっと再読しているのだが、
やっぱ、実際に使いながらだと、具体的にイメージできるせいか、読んでての気づきが違いすぎる、のである。

特に『カンバン ソフトウェア開発の変革』は、初読ではなんだかもや~っとして全然入ってこなかったのだが、
今回再読して気づいたことは大きく2点。
 
■かんばんによるWIP制限は、TOCの「ドラム・バッファ・ロープ」のこと
 カンバンシステムが、最適ペースを可能にする

TOCと同じく「ひとつずつボトルネックをとり除く」形で、プロセスを進化させる
 カンバン手法は、段階的なプロセス改善を起こす

 
ちなみに、
「かんばん」 ・・・かんばんそのもの(またはその役割を果たすもの)
「カンバンシステム」 ・・・かんばんを用いて構築されるプル型システムを指す
「カンバン手法」 ・・・本書に書かれている、進化的段階的なプロセス改善の方法論
というふうに使い分けてある。
 
「かんばん」いわゆるスクラムボードは、単なる見える化のしくみでしかなく、
仕掛りへの明示的な制限がなく、新しいシステムへ引き取る信号がなければ、
それは「カンバンシステム」ではない、と言っている。
 
さて、本書にはMicrosoftでの事例が書いてあるのだが、
現状のプロセスを分析し、その上で
まずは、何箇所かにキューを設けてWIPを制限し、
また、優先度の低い(=要求が停滞している)タスクは破棄する等し、
そういう、段階的なルールやプロセスの変更を行いながら、
最終的には、チームのスループットや品質を向上(=最適化)するまでのことが描いてある。
ここを読んで、具体的なイメージをふくらませておこう。Chapter4で少し先だけどね。
 
第Ⅰ部 Chapter2の「カンバンシステムを使用する理由」という項を一部(というかほぼほぼ)引用する。

 カンバンシステムを使用する理由は、チームの仕掛りを一定の容量に制限し、チームへの要望とチームが行う作業のスループット(生産率)のバランスを取るためである。このシステムは開発の最適ペースを達成し、全員がワークライフバランスを維持することを可能とする。
(中略)
 カンバン手法はパフォーマンスを損なう問題をすばやくあぶりだし、チームにそれらの問題の解決に専念させ、作業の着実な流れが維持されるようにする。
 品質とプロセスの問題を見える化することにより、欠陥、ボトルネック、ばらつき、フローとスループットに対する経済的コスの影響が明らかとなる。
 カンバンで仕掛りを制限するというシンプルな仕組みで、品質とパフォーマンスの向上が促進される。
 フローと品質の改善を組み合わせることで、リードタイムが短くなり、予測可能性と納期パフォーマンスの改善につながる。
 カンバン手法は、定期的なリリースのリズムを確立し、デリバリーを一貫して行うことで、顧客との信頼構築と、バリューストリームにおける他部門、サプライヤ、下流のパートナーとの信頼構築に役立つ。
(中略)
 さらに、カンバン手法は高度な共同作業を行い、高い信頼で権限委譲が行われ、常に改善が行われる組織の誕生を促進する。

というふうに、「第Ⅰ部」には総括的な大事なことが書いてあるので、
あとから読み直したほうが、この本が何を書こうとしていたのかがよくわかるだろう、と思った。
 
さて、いまのチームはどうだろうか...。

カンバンでWIP制限、って明確な制御は行っていないけど、
毎日朝会で進捗を確認し、それに合わせて今日何するかを決め、
日々そうやってタスクをコントロールしていることが結果的にWIPの制限になっている、ように思う。
それで、現場に焦りや混乱がなく、なんとかやってけてるのではないか、と思う。

尤も、こういうのを「場当たり的」とか「何も先のこと考えてない」とか
言うのかもしれないけれど(汗)*1
 
また読んでて気づきがあれば書き留めておこうと思う。

P.S.
おもしろいことが書いてあったので、引用。

暗黙知は時とともに低下するので、
暗黙知を活用するには、リードタイムを短くすることが不可欠なのである。
(中略)仕掛りの減少がリードタイムの短縮につながる。
したがって、仕掛りが少なければ、暗黙知の低下が抑えられるので、
品質が向上すると推論できる。

*1:フォローしておくと、いちおう全体工程があった上での、日々の作業の割り振りだから。これでいいのだ。