トヨタのかんばん方式とバグ追跡システムの密接な関係

「実践 反復型ソフトウェア開発」の6.10節「トヨタのかんばん方式とバグ追跡システム」がとても興味深かった。
チケット駆動開発との関係も含めて、ラフなメモ書き。

【1】BTS(バグ追跡システム)は、本来は障害管理から生まれた。
だが、BTSの開発フローがソフトウェア開発にとても有効であったために、タスク管理やユーザのサポート管理として扱うITSないしチケット駆動開発へ発展した。

BTSのチケットは、PCやサーバーなどの資産管理にも使える。
そのアイデアは下記に書いた。

情報システム部門がTiDDを運用する時の注意点: プログラマの思索

IT資産管理システムi-doIT: プログラマの思索

「実践 反復型ソフトウェア開発」では、BTSチケットをPC資産のようなハードウェアと紐づけて管理するのはとても有効だろう、そこからトヨタのかんばん方式へ発展させるのは自然なアイデアだと書いている。
BTSのチケットに変更履歴が自然に残り、後から全文検索できるし、チケット集計機能によっていくらでも欲しい情報を出力できるからだ。
また、チケットのステータスで資産の状態をワークフローで管理することもできる。

【2】「実践 反復型ソフトウェア開発」にあるトヨタのかんばん方式との関係性の説明はとても面白い。
「実践 反復型ソフトウェア開発」では、「仕掛けかんばん」とBTSチケットが密接に関係していると指摘している。

仕掛けかんばんは生産指示書だ。
つまり、後工程の部門が前工程の部門に対し、必要な部品とその生産内容を書く。
仕掛けかんばんは、Pull方式と密接に関係しており、在庫引き当てで重要な役割を果たす。

かんばんにはいくつか種類があり、ほかに有名なものは引き取りかんばんがあるが、これは納入指示書に相当する。

仕掛けかんばんには特徴がある。

かんばんは必ず現物が付いており、かんばんと在庫部品は1対1で対応付けられている。
これによって、在庫の部品を追跡できる仕組みになっている。

また、かんばんの運用では、枚数が肝心。
枚数が多ければ無駄な在庫が多いし、枚数が少なければ、欲しい時に部品を引き当てできないので、販売ロスにつながる。
だから、「かんばんがなければ部品の生産を開始しない」というルールを守ることが大切になる。

かんばんを紛失すると、本来引き当てるべき部品が分からなくなり、在庫数量を確定できなくなり、会計監査でNGを食らうだろう。
そして、かんばんは安易に枚数を増やしてもいけない。枚数を増やすと、無駄に多い部品が工場内に流通してしまうため、無駄が多くなるからだ。

また、かんばんに書かれた内容で作られた部品に品質不良があれば、後工程の部門の生産ラインを止めてしまう。
そのようなプレッシャーが部品の品質を高めることにもつながったと言われる。

【3】BTSチケットに当てはめてみると、BTSチケットは開発チーム内に流通して、人的リソースに引き当てられる。
つまり、チケットのステータスに応じて、テスター・開発者・ライブラリアンなどのような人的リソースがアサインされる。
そして、チケットに起票されれば、障害の発生から完了までチケット経由で追跡できる。
つまり、BTSでは、チケットの総数やステータスをきちんと管理できれば、かんばんのように物理的存在がないから、どれだけ複雑になろうとも追跡できる仕掛けがある。

すると、チケットを起点として作業を追跡するため、BTSの運用では「バグ報告票がなければ作業を開始しない」ルールを守ることが重要になる。
チケット駆動開発なら「チケットなしの作業不可」「No Ticket, No Work」というプラクティスにつながるだろう。

チケットはかんばんと違って紛失することはないが、放置されると紛失された事とほぼ同義になる。
解決すべきバグ、追跡すべきバグが放置されれば、チーム内に不良在庫がたまっているのと同じ。

完全に修正されていないバグを後工程(テストチーム)に回すと、顧客の信頼を失ったり、社会的信用を落としたりする。
特に、システムを文字通り止めてしまうようなブロッキングバグを放置したまま、テストチームへ回すと、プロジェクトで大きな混乱をもたらす。

TPSの仕掛けかんばんは、物理的存在であるがゆえに、工場内での流通量を直接制御できる利点があるが、BTSチケットはバグが増えれば、いくらでも増えてしまい、チームの開発能力を上回ってしまう時もあるだろう。
つまり、物理的な仕掛けかんばんのおかげで、工場の生産能力に見合った在庫量へ制約条件を故意に課す事ができるのに対し、BTSチケットは電子媒体であるがゆえに、その枚数に制約をかけることは原理的にはできない。

しかし、アジャイル開発におけるイテレーションの考え方を適用すれば、定期的にリリースできる期間内で対処できるようにチケットの枚数に上限を付けることができれば、開発チームは、自分たちの開発ペースで作業していけるだろう。
アジャイル開発で出てくるVelocityや小規模リリースという概念には、チケットの枚数に上限という枠をはめることで、開発チームに自分たちで状況をコントロールできる能力を付与するのだ。

※追記
「かんばんの上限値」という概念が、WIP(Work In Progress)という概念につながる。

【4】仕掛かりかんばんとBTSチケットには、多くの類似点があるが、大きな違いもある。

かんばん方式では、後工程引取り(消費部門が生産部門に必要な部品の生産を指示して引き取る(Pullする))であるのに対し、ソフトウェア開発では、欲しくもないバグは後からいくらでも沸いてくること。
また、かんばんでは解決方法(どの部品を生産していつどこの後工程の部門に送るのか)が明確に書かれているのに対し、BTSチケットが最初に起票された時はその解決方法すら書かれていない。

つまり、TPSのかんばん方式では、かんばんという指示書に作業内容や納期などが明確に書かれていて、その枚数を制限することが容易であるのに対し、BTSを基盤とするチケット駆動開発では、チケットがバグとして起票されたならばすぐに解決方法が分からないので、作業指示書にもなりえない。
バグや課題などのように、どんな作業をすればよいか、あいまいなチケットを起票せざるを得ない場合が結構多いのだ。

そして、システムが使われるほど障害や改善要望があがってくるので、チケットの枚数を制限する事は事実上不可能。
特に、初回の本番リリース後は改善要望という名の障害チケットであふれやすい。
だから、ソフトウェア開発は混乱しやすい状況を既に孕んでいる。

そんな比較内容を読んでみると、チケット駆動開発の肝はやはりチケット管理なのだと痛感する。
チームの開発ペースの上限を超えないように、やるべきチケットを明確にし、チケットに人的リソースを的確に割り当てていくという基本をどれだけ実行できるようにするのか。

TPSのかんばん方式とチケット駆動開発の比較についても調べてみる。