プログラマの思索

@daipresentsさんが、ソフトウェア開発における「かんばん」をWikipeidaに記載していたのでリンクしておく。
内容が整理されているので、大変参考になる。

【元ネタ】
Twitter / akipii: @daipresents さんがWikipediaに書いた「かんばん」の説明。これは力作！　アジャイル開発に携わる人は必見かな。かんばん (ソフトウェア開発) - Wikipedia　http://bit.ly/15jvK8O

かんばん (ソフトウェア開発) - Wikipedia

【１】上記の記事では、日本の製造業が生み出した「かんばん」をソフトウェア開発へ適用した「かんばん」として説明している。
「かんばん」の最大の特徴は、上記の記事にあるように、「かんばん」を仕掛品(Work-in-progress)という未完成の中間物とセットで運用することで、仕掛品を減らして在庫を減らし、無駄を省く点にある。

仕掛品がかんばんという製造指示書とセットになるという意味は、製造指示書の紙に仕掛品の品質や製造方法、数量、納期などが全て書かれているがゆえに、工場内のすべての作業工程が見える化されていることだ。

また、製造業にいる人ならば、仕掛品という言葉が「製品(完成品)」の状態の意味だけでなく、工業簿記における資産科目の一つ、原価管理すべき対象として捉えているだろう。
仕掛品という概念を使うことによって、倉庫にどれだけの未完成の中間物が作られて、どれだけの資産価値があり、経費が発生しているか、を計算できる。

【２】「実践 反復型ソフトウェア開発」の6.10節「トヨタのカンバン方式とバグ追跡システム」では、BTSの障害管理票が製造業の仕掛かんばんに似ているというとても意味深い意見を述べている。
製造業とソフトウェア開発の「かんばん」の特徴の対比は以下になる。
(以下、→は僕が理解してイメージしている内容)

【2-1】＜製造業のかんばんの運用ルール＞
・かんばんは必ず現物につけておく
　→かんばんは製造指示書ゆえに、部品という現物とセットにして、いつでも検査できる状態にしておく。

・かんばんと在庫部品を1対1に対応づける
　→在庫の部品を管理しやすくするために、かんばんと部品を1対1にひもづける。

・かんばんがなければ生産を開始しない
　→かんばんという製造手順が書かれた紙がなければ、作業してはいけない。
　　かんばんが届いたら、部品も一緒に届くので、その時点から作業を始める。

・かんばんが到着した順に生産する
　→消費部門や後工程で必要になった部品を補充するタイミングでかんばんが発行されるため、かんばんが到着する順序には意味がある。

・流通しないかんばん(紛失)に注意！
　→かんばんを紛失すると、かんばんとセットになっている部品を検査できないので、後工程の作業者が困る。

・かんばんの枚数を減らしていく
　→工場内で流通するかんばんの枚数を減らすということは、かんばんと1対1にセットになっている在庫部品が減ることを意味する。
　　かんばんにおける改善活動とは、かんばんを意図的に減らすことによって、現場で課題やボトルネックを出現させる点にある。
　　つまり、かんばんを減らしすぎて、準備すべき部品がないために作業できない工程こそがボトルネックになる。
　　逆に、かんばんを減らしても問題が出ないならば、工場内部で無駄な在庫が多かったことを意味する。

・不良品を消費部門に送り込んではいけない
　→後工程へ不良品を送りつけてはいけない。かんばんに書かれた品質基準を満たさないから。

・(かんばんを)生産の微調整に使う
　→例えば、当初は必要な部品が5個だったとするが、あとでよく考えたら7個のように少しだけ増やしたり、逆に3個へ減らしたい時がある。
　　多少の数量の変動は、かんばんを修正して、かんばん内部で吸収してしまう。

【2-2】＜バグ報告票の運用ルール＞
・発見したバグは必ず起票しておく
　→バグはBTSチケットに起票することで、チームで共有できる。
　　いくらバグを発見しても、BTSチケットに書いてくれなければ、開発者同士で、バグを認識できない。
　　また、そのバグを再現させる方法について、開発者同士で共有できないから無駄な議論が生じる。

・バグとバグ報告票を1対1に対応づける
　→バグ1個に対し、BTSチケット1枚を対応付ける。
　　BTSチケットの粒度に関係する。
　　肥大化したBTSチケットにしない。

・バグ報告票がなければ作業を開始しない
　→チケット駆動開発における「チケット無しの作業不可(No Ticket, No Work)」に相当する。
　　BTSチケットに作業者をアサインして、初めて作業が開始される。
　　この運用ルールによって、BTSチケットには作業履歴や実績工数が必ず記録され、リリース後の運用保守で参考にできる。
　　「チケット無しのコミット不可(No Ticket, No commit)」は、運用ルールの対象を作業から成果物の更新へ置き換えたものに相当する。

・バグ報告票の優先度順で作業する
　→バグの重要度(システムへの影響度、深刻度)や優先度(作業の優先順位)の観点で、大量のBTSチケットの作業順序を決める。

・流通しないバグ報告票(放置)に注意！
　→BTSチケットが放置されてしまうと、チケット駆動開発を運用している意味が無い。
　　チケットで開発者同士、チーム内で活発にやり取りしながら、システムをブラッシュアップしていくように運用していくべき。
　　「放置されたチケット」はデスマーチプロジェクトの特徴でもあり、チケット駆動開発の落とし穴でもある。

・オープン(未完了)なバグ報告票の枚数を減らしていく
　→未完了のBTSチケットを減らすことで、開発チームの作業負荷を下げて、開発チームが持続可能な開発ペースで作業できる状態にする。
　　そのために、イテレーションというタイムボックス開発ないし小規模リリースという開発スタイルが有効になる。

・ブロッキングバグをテストチームに送り込んではいけない
　→プロジェクトを文字通りストップ(ブロック)させてしまうバグを放置したまま、テストチームへ回してはいけない。
　　ブロッキングバグのように未完了のチケット、つまり、Doneの基準を満たさないチケットを後工程に回してはいけない。

・(かんばんを)人的リソースの負荷分散に使う
　→開発チームが消化できるBTSチケットの枚数には上限がある。
　　(多分、この上限値がVelocityと一致するのではないか、と直感する)
　　だから、BTSチケットの枚数が、開発チームの生産能力以上にならないように減らし、変動を抑えるようにする。

【３】製造業の「かんばん」とソフトウェア開発のBTSチケットを対応付けてみると、とても似通った性質を持つのが分かるだろう。
この事実は、製造業の「かんばん」というアイデアがソフトウェア開発にも応用可能であり、しかも有効であることを意味していると思う。

しかしながら、ソフトウェア開発特有の事情があるために、有効でない場面も多い。
「実践 反復型ソフトウェア開発」では、製造業の「かんばん」とBTSチケットの性質の違いについて、いくつか述べている。

例えば、かんばんは製造指示書であるがゆえに、どのように作ればよいか、手順が明確に決まっている。
でも、BTSチケットに書かれたバグに対しては、バグの修正方法はすぐに分からない時が多いし、そもそも明確に決まっていない時もある。

あるいは、製造業の工場では、流通する「かんばん」の枚数は人為的にコントロールできるのに対し、ソフトウェア開発ではバグは際限なく見つけることができるから、BTSチケットが際限なく増えてしまう場合がある。
つまり、BTSチケットの枚数を開発チームがコントロールするのは事実上不可能だ。

このように、ソフトウェア開発特有の事情があるが故に、製造業の「かんばん」のアイデアをそのまま適用できない状況も多いし、有効でない。

従って、製造業の「かんばん」から派生する特徴と、製造業とは異なるソフトウェア開発特有の特徴を厳密に区別することが今後の課題になると思う。
少なくとも、ソフトウェア開発で出てくる「かんばん」は、欧米人が日本の製造業が生み出した「かんばん」を理解したものであり、更にソフトウェア開発へ適用することで、その概念を変形させている。
「かんばん」本来の特徴をソフトウェア開発に活かすだけでなく、ソフトウェア開発特有の事情も「かんばん」へ反映させているのだ。

今後、その辺りも考えてみたい。