昨日の荷物詰めの話

昨日の袋に荷物を詰める話で、勘違いしている人がいたようなのでちょいと補足。

• これはKanban的に考える題材にはなる。
• ただし、最終的に出来上がった「袋を詰めるライン」はソフトウェア開発ラインの見本にはならない。あくまでも「考え方」の見本としてとらえるべき。

まず前者。KanbanはAgile開発の発展形として捉えて良いだろう。すなわち

• 大きな手戻りを避けるために、小さな手戻りは許す。
• 一度に行うタスクを増やしすぎることで管理不能になる(==大きな手戻りのタネをまく)ことを避ける。
• リスクの高い作業がプロジェクト後半で見つかる。
• 納期が優先される場合、優先度の低い作業は後回しにすることも辞さない。

昨日の例で言えば

• 袋に荷物を詰め始めてから、入れ忘れがあることに気づく。あるいは同一品を二重に詰め込んでしまうことに気づく。→やってみて、袋の中身を納品物一覧と突き合わせるしかない。
• 協賛企業からの納品物を待ちすぎて作業時間が足らなくなって午後の受付開始に間に合わなくなる。→どこかで見切りつけて、間に合わなかった分は会場配布にするしかない。
• ポスターを丸めるとか、小物を間違えずに詰めていくとか、やってみて初めてわかる作業量の多さ/ボトルネック部分をどうやって見つけるか？→やってみるしかない

等など「やってみるしかない」部分を何回か繰り返しながら最終的な量産ラインを「設計・実装」したあたりがAgile/Kanbanとして学ぶべき部分なのである。

では、みんなが並んでひたすら荷物を詰めていったのは何か?

あれはビルドが終わった動くコードとしてとらえるべきであろう。ソフトウェアの世界で言うCPUやディスク、メモリ、通信カードを作業員が代行していただけなのである。

もし、みんなが並んでかばんに小物を詰めていくラインを「ソフトウェアの設計・開発・テスト」の見本としてとらえているのであれば、その考えは捨てたほうが良い。ソフトウェア開発において「単純な作業の繰り返しを人間が行っている」のであれば、その工程は必ずツール類で置き換えることができるのだから。