bookmeter.com
asanaを使ってみながら、
『カンバン仕事術』や『カンバン ソフトウェア開発の変革』をさらさらっと再読しているのだが、
やっぱ、実際に使いながらだと、具体的にイメージできるせいか、読んでての気づきが違いすぎる、のである。
特に『カンバン ソフトウェア開発の変革』は、初読ではなんだかもや～っとして全然入ってこなかったのだが、
今回再読して気づいたことは大きく２点。
■かんばんによるWIP制限は、TOCの「ドラム・バッファ・ロープ」のこと
カンバンシステムが、最適ペースを可能にする
■TOCと同じく「ひとつずつボトルネックをとり除く」形で、プロセスを進化させる
カンバン手法は、段階的なプロセス改善を起こす
ちなみに、『カンバン ソフトウェア開発の変革』では、
「かんばん」 ・・・かんばんそのもの（またはその役割を果たすもの）
「カンバンシステム」 ・・・かんばんを用いて構築されるプル型システムを指す
「カンバン手法」 ・・・本書に書かれている、進化的段階的なプロセス改善の方法論
というふうに使い分けてある。
「かんばん」いわゆるスクラムボードは、単なる見える化のしくみでしかなく、
仕掛りへの明示的な制限がなく、新しいシステムへ引き取る信号がなければ、
それは「カンバンシステム」ではない、と言っている。
さて、本書にはMicrosoftでの事例が書いてあるのだが、
現状のプロセスを分析し、その上で
まずは、何箇所かにキューを設けてWIPを制限し、
また、優先度の低い（＝要求が停滞している）タスクは破棄する等し、
そういう、段階的なルールやプロセスの変更を行いながら、
最終的には、チームのスループットや品質を向上（＝最適化）するまでのことが描いてある。
ここを読んで、具体的なイメージをふくらませておこう。Chapter４で少し先だけどね。
第Ⅰ部 Chapter２の「カンバンシステムを使用する理由」という項を一部（というかほぼほぼ）引用する。
カンバンシステムを使用する理由は、チームの仕掛りを一定の容量に制限し、チームへの要望とチームが行う作業のスループット（生産率）のバランスを取るためである。このシステムは開発の最適ペースを達成し、全員がワークライフバランスを維持することを可能とする。
（中略）
カンバン手法はパフォーマンスを損なう問題をすばやくあぶりだし、チームにそれらの問題の解決に専念させ、作業の着実な流れが維持されるようにする。
品質とプロセスの問題を見える化することにより、欠陥、ボトルネック、ばらつき、フローとスループットに対する経済的コスの影響が明らかとなる。
カンバンで仕掛りを制限するというシンプルな仕組みで、品質とパフォーマンスの向上が促進される。
フローと品質の改善を組み合わせることで、リードタイムが短くなり、予測可能性と納期パフォーマンスの改善につながる。
カンバン手法は、定期的なリリースのリズムを確立し、デリバリーを一貫して行うことで、顧客との信頼構築と、バリューストリームにおける他部門、サプライヤ、下流のパートナーとの信頼構築に役立つ。
（中略）
さらに、カンバン手法は高度な共同作業を行い、高い信頼で権限委譲が行われ、常に改善が行われる組織の誕生を促進する。
というふうに、「第Ⅰ部」には総括的な大事なことが書いてあるので、
あとから読み直したほうが、この本が何を書こうとしていたのかがよくわかるだろう、と思った。
さて、いまのチームはどうだろうか...。
カンバンでWIP制限、って明確な制御は行っていないけど、
毎日朝会で進捗を確認し、それに合わせて今日何するかを決め、
日々そうやってタスクをコントロールしていることが結果的にWIPの制限になっている、ように思う。
それで、現場に焦りや混乱がなく、なんとかやってけてるのではないか、と思う。
尤も、こういうのを「場当たり的」とか「何も先のこと考えてない」とか
言うのかもしれないけれど（汗）*1。
また読んでて気づきがあれば書き留めておこうと思う。
P.S.
おもしろいことが書いてあったので、引用。
暗黙知は時とともに低下するので、
暗黙知を活用するには、リードタイムを短くすることが不可欠なのである。
（中略）仕掛りの減少がリードタイムの短縮につながる。
したがって、仕掛りが少なければ、暗黙知の低下が抑えられるので、
品質が向上すると推論できる。
*1:フォローしておくと、いちおう全体工程があった上での、日々の作業の割り振りだから。これでいいのだ。
