ミルク補充はこれで完璧！カんばん方式で在庫管理を劇的に改善する方法

SimpleHumanのゴミ袋も同じだよ。残り5枚になると、新しいのを注文しろって大きく書いてあるんだ。

犬のうんち袋にも同じようなのあるよね。残り3枚になると「残り3枚」ってステッカーが貼ってある。

＞みんなKanbanって言うと、特定のやり方を思い浮かべるよね。ホワイトボードとか付箋とか（どっちもほぼバーチャルだけど）。
＞ソフトウェア開発者がKanbanって言うと、ホワイトボードを思い浮かべるんだよな。製造業の人は補充を最初に考えると思うけど。どこでも当たり前にあるよね。ERPが注文を見て、あるレベル以下になったら、補充のために購入したり製造したりするんだ。

Kanbanって言葉にすごいイライラするんだよね。最初に見かけたとき、ソフトウェアと何の関係があるんだ？って思ったもん。
Kanbanって、物流のアイテムにプレッシャーをかける方法のことなのに、ソフトウェア開発は全然違うじゃん。各機能をカスタムアイテムとしてモデル化しないといけないし。だから、ソフトウェア開発者が自分たちに合うシステムを作ったのは良いけど、違う名前にしてほしかった。マジで混乱する。

ソフトウェアに合うシステムを作って、製造業のカッコいい名前をパクっただけじゃないよ。
ITの手法は、同じ原則（ある程度は価値観も）に基づいているんだ。ただ、実装が違うだけ。例えば、工場では部品が見えるけど、ソフトウェアのコードは見えない。だから、ソフトウェアでは、インデックスカードを使って作業のキューを表すんだ。
WIP制限のアプローチも同じ。製造業では視覚的なカードで補充をトリガーするけど、ソフトウェアでは数値的なWIP制限を使う。結果は似てるよね。
違いもあるよ。製造業ではバラツキを減らすけど、ソフトウェアでは受け入れる傾向がある。あと、知識労働では無駄の削減を重視しないけど、製造業では重要視するとか。でも、アイデアを見れば、これらのシステムはすごく似てるんだよ。名前が紛らわしいのはしょうがないけどね。

＞ソフトウェア開発者が自分たちに合うシステムを作ったのは良いけど、違う名前にしてほしかった。マジで混乱する。
これ知らなかったけど、ScrumとかKanbanって、工場労働者みたいに扱われてるみたいで嫌だなってずっと思ってたんだよね。やっぱり、Kanbanは工場から来たんだ。

そう思うかもしれないけど、製造と部品物流をユーザーデザインとコンテンツに置き換えてみて。新しい機能がデザインされて、コンテンツが書かれて、実装される。各ステップは前のステップが必要なんだ。

毎回違うから、このメタファーは無理があると思うんだよね。もしソフトウェアシステムを正確にクローンするなら、もっとうまくいくと思うけど。
マネジメントは理解しやすいからこのシステムに飛びつくけど、最近はマネジメントもコードを書いたことがある人が増えてきて、良くなってる面もある。でも、大きい会社だと、大学時代にコードを書いたことがある人がまだいて、”代替可能な開発者”って感じで、工場みたいなプロセスをゴリ押ししてくるんだよね。

プロダクト内なら、このメタファーはうまくいくかもね。例えば、新しいフォームのある新しいページは、既存のフォームの流用であることが多いし。
サービスだと、これはあまり適切じゃないけど、既存のサービスを拡張するのは、アセンブリライン作業にちょっと似てる。

既存のサービスを拡張するのは、アセンブリラインの作業にちょっと似てるかなーって思うんだけど、ほとんどのアセンブリラインを毎回少なくとも部分的に作り直さなきゃいけないなら話は別だよね。基本的なシステム以外、ソフトウェアの機能って単独で存在しないじゃん。LeanとかKanbanのソフトウェアの教えでは考慮されてるけど、マネジメント層は無視しがちだよね。

“The Phoenix Project”って本おすすめだよ。

読み終わった！マジでその通り。

＞Kanbanの文字通りの翻訳は「colored badge」らしいよ。
看板 - 看 “look at; watch”, 板 “board; plank”.
日本語だと、＞https://ejje.weblio.jp/content/%E7%9C%8B%E6%9D%BF　で「看板 - signboard; billboard」（あと「hoarding」、「draw; attraction」、「closing time」）って意味があるね。

Kanbanのソフトウェア開発チームで働いたことあるけど、ホワイトボードは一度も使わなかったな。Scrumとかextreme-agileのチームは好きだったけど。Kanbanはタスクを優先順位順に並べたキューで整理することに重点を置いてる気がする。

＞Kanbanのソフトウェア開発チームで働いたことあるけど、ホワイトボードは一度も使わなかったな。
ほとんどのチームは物理的なホワイトボードじゃなくて、ホワイトボードを表現するソフトウェアを使ってるよ。“Kanban board”で画像検索すると、物理的なホワイトボードと、同じカラム形式を模倣したソフトウェアのダッシュボードが混ざって出てくるはず。ソフトウェア開発って名前が意味不明になってることが多いよね。アジャイルを自慢してた会社で、6-9ヶ月先の計画を要求してたし、スプリントの正確性とか、チケットを時間通りに完了できなかったことを重要視してたよ。

チケットが早すぎるってどういうこと？ソフトウェアの機能は魔法使いみたいなもんじゃん。

使ってた指標は「計画の正確さ」だったんだよね。チケットを次のスプリントに入れる予定だったのに、早く終わらせちゃった場合、プログラムマネージャーが手を揉みながら、次のスプリントにずれ込ませる方法はないかって聞いてくるんだ。計画と違うスプリントで“done”になると、「計画の正確さ」の指標が下がるんだって。

面白い視点だね。Kanbanの最初の2つの（そして重要な）プラクティスは、-ワークフローを視覚化すること、- WIPを制限すること、だよね。これらのKanbanチームは、どのように作業を視覚化してたんだろう？ホワイトボード（仮想または物理）だけが唯一の方法だとは言わないけど、ほとんどどこにでもあるよね。

ソフトウェアのユーザーフローを視覚化する方法を夢見てるんだよね。（ボード上のカードじゃなくて）スパイダーマップみたいな感じで、可能なユーザーフローを表示して、それぞれの段階で色分けされた丸で示すみたいな。そうすれば、フロー全体の状態が一目でわかるし、それに応じて努力を調整できるじゃん。

それマジそう。Kanbanって言葉の解釈は、知識労働（特にソフトウェア開発からの派生）と製造業で違うんだよね。
俺のバックグラウンドはITだから、説明をちょいと単純化しちゃった。原則は同じだけどね。仕事の性質が違うから、重視する点が違ってくる。”ムダの排除”に対する考え方がITと製造業で全然違うのが良い例かな。
まあ、ホワイトボードと付箋は、ソフトウェア開発では定番アイテムだよね。製造業はもっと前からあったから、もっとクリエイティブな視覚的サイン作ってるよ。
あと、知識労働は不確実性とか仕事のばらつきに強い。プロセスが違うからね（クリエイティブで、毎回違う）。

＞On the other hand, knowledge work typically handles uncertainty and variability of work way better.
＞知識労働の方が不確実性とか変動に強いってのはどうかなー。確かに違うけど、どっちが上ってわけじゃないと思うよ。
うちの工場は受注生産で、納期も短いんだ。毎日2500台も作ってて、種類も構成も色々。部品が足りなくて、作りたいものが作れない日もあるし、材料の品質問題で手直ししたり工程変えたり、設計変更とか顧客からの要望もある。400人以上の調整が必要。でも、納期遅れは0.1%以下。10日後の需要なんて全然わかんない。ソフトウェアチームを率いてた時より、ずっと複雑で対応力が必要だと思うけどな。

説明不足だったわ。
製造業の理想は、同じ作業を繰り返して同じものを作ること。
ソフトウェア開発も、開発、レビュー、テストって段階は同じだけど、ワークフローを通るタスクは全部違う。タスクの定義次第で、労力とか依存関係もバラバラ。
もちろん、プロセスの複雑さでバラツキは出るけど、知識労働はさらに次元が違うんだよね。だから、知識労働では、ばらつきをコントロールするんじゃなくて、受け入れるって言うんだ（Lean Manufacturingとは違う）。Don Reinertsenの本おすすめ。難しいけど。

＞ I understand the literal translation of Kanban is ‘coloured badge’ btw
いやいや、”signboard”とか”billboard”だよ。”看板”って意味。

うちの奥さんが製造業で20年働いてるんだけど、Six SigmaとかKanbanとかLean Manufacturingとか、色んな”技術”があるんだって。それってマジでREAL engineeringって感じがする。ソフトウェアの”sprint review”とか”retrospective”とかいうクソとは違うわ。

Leanはソフトウェアにこそ、他のどの方法論よりも合うと思うよ。
すべてのプロセスから徹底的にムダを省くってだけで、他の何よりもメリットがある。結果として、もっとシンプルなKanbanシステムに近づくことが多い。

俺がKanbanって言う時は、ScrumとかSAFeで増えすぎた無駄なプロセスを全部取り払って、WIP制限を設けて、仕事に集中できるようにプロセスをシンプルにするって意味。

ソフトウェア開発で言うと、”残りタスク5つ！新しいタスク考えろ！”って紙を貼るってこと？

従来の製造業（とソフトウェア）は、仕事をシステムにPUSHしようとするのが問題。それが色々な問題を引き起こして、品質とかスループットを犠牲にしちゃう。プレッシャーをかける意味がなくなるし、組織の評判を落とすことさえある。
トヨタ生産方式では、品質を最優先にして、そこから生まれるシステムを観察する。PUSHじゃなくてPULLで仕事を進めることで、ムダなプレッシャーをかけずに改善できる。素材は前のバッチがほとんどなくなってから投入する。初期のアジャイルは、ストーリーを素材のメタファーとして使った。製造業とソフトウェア開発は創造的な作業だけど、ソフトウェア開発の方が創造的な割合が高い。
Kanbanボードは、チームのスループットを見える化して、消化しきれてないのに新しいストーリーを投入するのを防ぐためのもの。”The Goal”おすすめ。

”The Goal”はマジでおすすめ。”The Phoenix Project”にめっちゃ影響与えてる。
あと、うんざりしてるハッカーは、製造業に行ってみるといいよ。Leanの専門家とかプロセスエンジニアが、現実の問題を解決するのを見るのはマジ面白い。Kaizen（継続的改善）が実際に動いてるのを見るとか、ミスが許されない、影響が大きいシステムをどう管理してるかを見るとか、本当に勉強になるよ。

「The Phoenix Project」って、要は「The Goal」をソフトウェア開発の現場向けに書き直したようなもんだよね。みんなが「関係ないじゃん」ってスルーしないようにさ。作者も隠してないし。どっちも読む価値ありだよ。ちなみに、「The Goal」の肝はTOC（Theory of Constraints）ね。KanbanはWIP制限でそこからヒントを得てるけど、ガッツリ被ってるわけじゃないんだ。

できるだけ早く、考えられる機能とかストーリーをみんなが把握しておくべきってのは、確かにそうだよね。そうすれば、後から矛盾するような作業を避けられるし。ストーリーがたくさん”ボード”にあることのデメリットがよくわかんないんだよね。物理的なボードならいっぱいになるかもだけど、今はコンピュータ使ってるし。もちろん、計画ばっかり立てて実装しないのはダメだけど、必要になりそうな機能があるなら、チームに隠すべきじゃないと思うんだ。仕様のミスは設計や実装のミスよりもコストが高いって、ウォーターフォールの頃から言われてるし、それは今でも正しいと思う。Agileは違うかもしれないけど。「将来の計画」みたいなのをプロセス全体で持つべきかもね。まだ確定してない機能でも、意識しておくべきだと思う。

最初からタスクを全部バックログに入れておくのが有効なのは、要件が変わらない、優先順位が変わらない、作業内容をずっと理解できるって場合に限るよね。そうなれば、チケットを順番に引っ張って、必要な時に詳細を書き込めばいいだけ。25年やってるけど、そんなプロジェクト見たことないよ。これからもないと思う。要件は絶対変わるし、優先順位も変わる。クライアントは自分が何を欲しいかわかってるって言うけど、実際に見てみないとわからないんだよね。それに、作ってるうちに色々わかってくるから、要件が変わるんだよ。プロジェクトについて一番知らないのは、開始時点なんだ。そこからどんどん知識が増えていく。だから、変更があるのにチケットをたくさん抱えてると、優先順位の変更とか計画とか、開発への移行とか、全部コストがかかるんだ。それに、もうすでに存在する作業をまた追加しちゃうことだってあり得る。認知負荷が大きすぎるんだよ。それに、全体像を理解するって点でも、チケットが多すぎると覚えきれないから意味がない。チーム全員がビジネスの全体像を理解していれば、設計や実装の判断がしやすくなるってのはその通り。でも、そのためには何十、何百ものチケットはいらないんだ。ちなみに、物理的なボードには100個以上のアイテムを置かないようにしてる。脳みそが処理しきれないから。バーチャルボードならもっと少なくないとね。画面の制約とか、ツールの出来が悪いせいで、視覚的な能力が落ちるからね。

参考までに、俺の経験則だと、3サイクル分以上のものは見ないようにしてるな。
1) 進行中 → 開始 → 完了: これが1サイクル分のWIP。
2) 次の候補: 次のサイクル分のWIP（上位3分の1が最優先、残りはサイクル開始まで優先順位不明、議論の余地あり）。
3) 未定バックログ: 最大数は1サイクル分未満。
小さいチームだと1サイクルで5～10個の”アイテム/ストーリー”を消化できるから、30個以上のアイテムは見ないようにしてる。大きいチームだと1サイクルで30～40個消化できるから、120個くらいまでなら大丈夫。大きいチームほど、タスクを細かく分割する傾向がある。コミュニケーションのオーバーヘッドとか、暗黙の了解によるコストが高いからね。タスクがどれだけ戦術的か、粗いか、目標指向かは、チームや組織の関心事や能力によって大きく変わってくる。

まだコミットしてない”予測タスク”を、”ボード”とは別の場所に置いておくのはアリだと思う。自分たちがどこに向かってるのか、大まかな方向性を示すだけでも意味があると思うんだよね。仕様は絶対変わるってのは同意。だからこそ、どう変わる可能性があるのかを知っておくべきなんだ。そうすれば、今のタスクと矛盾する可能性に気づきやすくなって、結果的に仕様変更の量を減らせるんじゃないかな。

俺が言いたいのは、将来を見据えたアイデアは役に立つけど、具体的な投資をする準備ができるまでは、”タスク”に落とし込むべきじゃないってこと。

将来を見据えるのは素晴らしいことだし、チームは顧客、設計、製品担当者と一緒に未来のアイデアについて話し合うべきだ。自分たちが何を作っているのかを理解することは、何を構築するかの形成に役立つ。ただ、その結果は、目標や成果に焦点を当てた、大まかな物語形式で保持されるべき。何ヶ月もかけてキュレーション、スケジュール、交渉しなければならない具体的なタスクを生成すべきじゃない。工場で言うと、四半期または年間の目標みたいなもの。戦術的な活動よりも一段階上のレベルだ。”ボード上のストーリー”は、リリースされてWIPになった原材料みたいなもの。原材料を投入しすぎてラインを圧倒すると、想像以上に無駄が発生する。バランスを取るのは難しいけど、経験と考慮を重ねれば、限界点は見えてくるはずだ。

＞なんか最近、自分の殻に閉じこもりがちになってるから、それが普通になっちゃってるのかも。
初期の草の根Agileコミュニティってどうなっちゃったんだろうって思うことあるんだよね。俺も自分の世界に引きこもっちゃってるけど、それってよくあることなのかな？昔よりも後退してる気がするんだよね。単なる愚痴かもしれないけど。

チームや組織を良くしたいって本気で思ってる人は消えてないよ。ただ、彼らが活動してた”ラベル”が、資格ビジネスに乗っ取られちゃったんだ。”草の根”の人たちは、ラベルを気にしなくなったか、自分たちで新しいラベルを作ったんだね。今となっては、Agileは中身のないバズワードだよ。誰かが意味を説明しない限り、何の意味もない。Kanbanも同じ。

俺は狂騒から抜け出して、静かで安い場所に引っ越して、没頭できることに取り組んでる。今のところ最高だよ。いつまで続くかわからないけどね！

pull/pushの区別、マジで良いね！ありがとー。

ディスク容量残り10%だって。メモリ使用量も90%とかヤバすぎ。しかも、$CRITICAL_PACKAGEのアップデートが2ヶ月も前からあるじゃん。
こういうパターンに気づけば、いろいろ応用できるよね。メンタル使いたくない作業のために、先回りしてリマインダーを設定するとか。

未来が見えるなら、みんなに教えてあげようよ！牛乳がもうすぐ臭くなるってわかったら、誰かに教えてあげて。:-)

Kasiaの牛乳システムでマジ良いなって思うのは、感情的な負担がゼロなコミュニケーションってこと。チケット取って彼女のデスクに置くだけで、あとは全部やってくれるんだもん。

邪魔にもならないし、新しいTODOが増えるわけでもない。そこがマジでエレガント。
Slackでメッセージが来るのは最悪だよね。

彼女のデスクがどれくらい遠いかにもよるよね。

4人以外は、自分のデスクに行くついでに置けるんだよね。
きっと誰かがキッチンテーブルにカードを置いたら、Kasiaのところに運んでくれると思う。カードが置きっぱなしになったことはないらしいし。
マジでその通り！もしみんなが遠くまで行かないといけないなら、もっと信頼性が低かったかも。良いシステムデザインって、正しいことをするのが一番簡単なことなんだよね。

なるほどねー。俺なら「このカードをリオーダーボックスに入れて」にするかな。

それ、マジでKaizenじゃん！めっちゃスケーラブル。オフィスはまだ気づいてないかもね。

で、毎日リオーダーボックスを確認しないといけないの？

へー、確かにそうだね。近くにRaspberry Pi置いて、箱に向かってカメラ回すのはどうかな？LLM使って箱の中身識別して、毎朝Kasiaにアップデートメッセージ送るんだよ。マジで、なんで誰も思いつかなかったんだろ？

最近NFCタグって結構安いじゃん？だから、お知らせの裏にテープで貼って、底にセンサーがある箱に入れるのはどう？（多分やりすぎだけど）

それって現状と大差ない問題だよね。今のシステムだと、Kasiaは毎日自分のデスクに新しい牛乳を注文する必要があるか確認しなきゃいけない。でも、彼女の仕事内容によっては、オフィスにいない日もあるかも。結局、どこかをポーリングする必要があるわけ。ただ、どこをポーリングするか選べるだけ。例えば、100階建てのビルでKasiaのデスクが1階にある場合、みんなが平均50階移動するより、10階ごとに箱をポーリングする方が全体的に最適かもしれない。

うまくいかなくなるかもしれない問題を考えてくれて感謝するよ。とは言っても、オフィスはワンフロアだし、食料品の注文は数週間に一度。注文には結構時間的な余裕があるんだよね。プランB（同じブロックの食料品店で牛乳パックをいくつか買う）もあるし。このシステムは必要なものに合わせてスケールされてるんだ。もちろん、誰かに盲目的にコピーしろとは言ってないよ。もし、複数階、複数のコーヒーコーナーとかの話だったら、インデックスカードの流れをもっと意識的に考えなければいけなかったかもしれないね。今回のケースでは、何も必要ないんだ。あと、継続的改善(kaizen)って言うけど、最初は単純なものから始めて、それを改善していくのが良いよね。仮説的な問題の解決にシステム設計を持ち込むのは無意味だよ。ほとんどの場合、不必要に解決策を複雑にしてるだけだよ。それこそがソフトウェア開発の歴史の半分って感じだよね。:)

冷蔵庫が1つしかないなら、移動距離を最小限にする解決策は簡単で、Kasiaを冷蔵庫に移動させることだね。冷蔵庫が複数ある場合は、Kasiaは最適なTSPツアーのどこにでも配置できるよ。でも、冷蔵庫が時間とともに動的に出たり入ったりする場合は、Kasiaがすべての冷蔵庫を移動するのは不可能だね。この場合、他の従業員が最後の牛乳パックを見つけたときにKasiaのデスクまで歩く必要がある。もし、冷蔵庫の生成と破壊の密度が均一だと仮定できるなら、期待される移動距離を最小限にする戦略は、Kasiaが中心にいる球形のオフィスビルだね。

うん、これはイベント購読に近いね。スケーラブルだし。

リオーダーボックスがいっぱいになったら、このカードをKasiaのデスクに置くんだね。

＞本来の意味では、Kanbanは視覚的な信号を表していました。それは何かを伝えていたんだ。必要性、オプション、可用性、キャパシティ、リクエストなど。
＞このシステムは一目瞭然だ
これは常に”アフォーダンス”として知られているよ。オブジェクトとそのユーザーの間の利用可能で明白な相互作用のこと。
https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things

それって確かに繋がりはあるよね。でも、アフォーダンスってインタラクションデザイン特有の概念で、物理的に自明な目的（取っ手とかボタン、レバー、つまみとか）を持つものって感じかな。

それ、すごく良いアナロジーだね！
確かにコンテキストは違うけどさ。アフォーダンスは、君が指摘するように、どうやってアイテムを使うべきかを教えてくれる。ある意味、意味を示唆してるんだよね。カンバンの意味は、通常、プロセスが（ほとんど）知られているものとして定義されるし。
Milk Kanbanの話では、インデックスカードは一目瞭然だけど、それはプロセスをより万全にするためのちょっとした追加要素なんだよね。
別の見方をすれば、両方の例を一般化すると、デザイン（物やプロセスの）はどのように行動すべきかを伝えるべきだっていう結論になると思う。オブジェクトとインタラクトするか、プロセス内でアクションを起こすかのどっちかだよね。
ちなみに、『The Design of Everyday Things』もこのスレッドでおすすめされてるよね。

＞しかも、私たちのすごいものをほとんど知らない人が、私たちが思いつきそうもないシステムを設計するときは、健全な警鐘だよね。
著者はカシアにどうやってそのアイデアを思いついたのか聞いたのかな？彼女が夜にMBAに通ってて、日本の自動車産業におけるジャストインタイム生産の歴史に関する論文を書いただけかもしれないじゃん。