製造業やソフトウェア開発における根本問題～在庫とは何か、リードタイムとは何か

3/30に浜松で開催された関西IT勉強会で、佐藤知一さんが話された「製造業のプロジェクトにおけるボトルネック　～BOM/部品表の問題～」の講演が公開されている。
感想をラフなメモ書き。

第22回関西ＩＴ勉強宴会　「製造業のプロジェクトにおけるボトルネック　～BOM/部品表の問題～」 - YouTube

関西ＩＴ勉強宴会のブログです: 2013-03-30（月）第22回関西IT勉強宴会 & スケジューリング学会　合同シンポジュウム

【1】内容は、製造業におけるBOM（部品表）の話なのだが、個人的には「在庫とは何か」「リードタイムとは何か」という問題が隠れているような気がした。
製造指示書や伝票を発行したり、部品表を保守したり、月末にBS・PL・商品有高帳を作るのは、結局、今自社にどれだけのお金があるのか、売上をあげるために必要な商品(製品)はいつまでに作り、必要な部品や原材料はいつまでに納品すべきか、という問題を解決するためにあると思うからだ。

在庫は基本的にはなくてよいもの。
在庫がたくさんあるということは、ムダにたくさん作りすぎていることを意味する。
佐藤知一さんの記事「在庫問題の構造を把握するために（佐藤知一） - BLOGOS（ブロゴス）」に書いてあるように、倉庫に寝かせている仕掛品（在庫）の滞留時間が長いほど、金利がかかってくるために、在庫高以上のコストが無駄に発生しているわけだ。

逆に、必要な時に在庫がなければ、販売機会を失い、本来の売上を失う。
つまり、本来必要な在庫高と失った売上という2倍以上の損失が発生していることを意味する。
だから、必要な時に適正な在庫を持つことはビジネス上重要だし、在庫を管理していくプロセスに普通の会社はかなりの労力を割いている。

貯蓄できない個人が自分の残高を認識していないのと同じように、自社の在庫を把握できない会社は駄目だ。

そのために、売上の元になる商品（製品）の元ネタとなる部品表とそれを作る工程（作業手順）が必要だし、そこには必ず標準リードタイムがセットされているので、必要な製品はいつまでに作るべきか、いつまでに必要な部品を仕入れるべきか、が導き出される。

しかし、この在庫をシステムで見える化するはとても難しい。
まず、作るべき製品の部品をすべて洗い出し、その部品の数量と、いつその部品が必要になるかという納品日といつまでに注文して仕入れるべきかという発注日を計算する必要がある。
普通はその部品の種類は多く、取引先もビジネス環境によって変化する。
そして、一度作った製品製造計画もビジネス環境によって、1か月後には状況が変わってしまう。

そして、必要なリードタイムを計算するロジックは複雑怪奇で開発するのも大変だし、ビジネスの変化で常に変わるため、保守するのはもっと難しい。
1個の部品の発注日が変わると、その部品を使う全ての製造工程に波及するため、影響がとても大きくなるのでリードタイムの再計算で発注日を更新SQLが15分たっても返ってこず、タイムアウトになる場合もある。

在庫の把握とリードタイムの計算は、業務上最重要であるだけでなく、システム上の実装の難易度も一番難しい部類に入ると思う。

【2】TPS（トヨタ生産方式）を元にソフトウェア開発へ応用したリーンソフトウェア開発でも、在庫とリードタイムの概念は自然に現れる。
ソフトウェアはサービス業なので、在庫という概念は本来無いし、在庫としてモノを事前に仕入れるために必要な情報であるリードタイムももちろん無い。

しかし、ソフトウェア開発の各工程で必要となる作業や成果物を在庫として見なせば、そこから必要な成果物はいつまでに必要で、そのためには前工程の成果物はいつから作るべきか、というリードタイムの計算が必要になってくる。
ソフトウェア開発も製造業と同じように考えることができるわけだ。

バリューチェーン分析では、最終的に出荷可能は製品を作る工程と作業内容を洗い出し、価値ある成果物を作るために必要な作業時間を見える化することによって、開発工程のムダな作業を認識する手法。
「リーンソフトウエア開発」や「リーン開発の本質」を読むと、ソフトウェア開発で価値あるモノを作る作業時間は、全体の作業時間の1割ほどしか無い事例もあったりして、いかに無駄な作業が多いか、を明確に説明しているのが分かりやすい。

また、リーンソフトウェア開発では、Velocityとサイクルタイムという概念が現れてくる。
Velocityは1週間に開発した機能の数であり、サイクルタイムは1機能にかかった開発時間を表すのが普通。
つまり、Velocityはある一定のイテレーションにおける開発チームの生産能力を表し、サイクルタイムは一つの機能を開発するためのコストを表す。

単純に考えると、Velocityが大きいほど生産能力が高いわけだから、製品の出荷量を調整しやすい。
つまり、ビジネスの都合上、製品の出荷量の増量が突然必要になったとしても、生産能力に余裕があるので、出荷量の変動に強い。

同様に単純に考えると、サイクルタイムが小さいほど、一つの機能（部品）に関わる作業時間が短いので、製品に必要な各機能（部品）のリードタイムは短くなり、製品の出荷を早めることができる。
つまり、出荷ギリギリまで開発を先延ばしできるので、マーケットの事前調査や選択肢を増やしてリスクを減らすことに注力できるから、マーケットの状況の変化に強くなる。

僕はまだリーンソフトウェア開発というものを全く分かっていないけれども、ソフトウェア開発における在庫とリードタイムという概念はVelocityとサイクルタイムを使えば表現できると直感している。
その方法で表現できれば、Velocityとサイクルタイムを開発プロジェクトで常に計測すればよいし、その2つはソフトウェア開発にとってとても基本的なメトリクスの一つなので、多分そう難しくないはず。

【3】TPSでは「かんばん」という概念もある。
「仕掛かんばん」は製造指図書、「納入かんばん」は外部の仕入先に対する発注書みたいなもの。
必要な時に必要な数量の部品を準備するために、在庫をできるだけ減らすためのアナログなやり方。
かんばんには、インプットとアウトプット原材料や部品の数量と納入日が書かれているので、作業者がどの部品を使って作るのかという作業指示書にもなるし、原価管理にも使える。

工場現場では、かんばんによって現物と情報が常に一致しているからこそ、かんばんが流通することで、工場内の工程が見える化される。
流通するかんばんの数量を故意に減らせば、在庫が減るし、在庫が減ることでボトルネックとなる工程や問題を噴出させ、改善を強要する。

ソフトウェア開発でもソフトウェアかんばんとしてその概念は実現されている。
ソフトウェアかんばんに貼られるストーリーカード、タスクカード（抽象化した概念として「チケット」）は、ソフトウェア開発の各工程で使われる機能や作業指示書に相当する。
それらに、納入日や見積り工数、実績工数を入力すれば、実績集計によって原価管理にも使える。

だが、「実践 反復型ソフトウェア開発」にも書いてあるように、ソフトウェア開発における障害管理票（チケット）と仕掛かんばんは同様に見なせるとしても、大きな違いもある。
ソフトウェア開発の作業や障害は、突然の仕様変更や障害によって増える時が多いために、流通するチケット（障害管理票）の数量を故意に増減させることが難しい。
そして、チケット（障害管理票）には、どのように実装すべきか、という仕様が書かれておらず、まず障害を再現させてから原因を調査して初めて修正方法が分かる時も多い。
だから、製造業のかんばんがそのままソフトウェア開発へ適用できるわけではない。

でも、製造業のかんばんをソフトウェア開発へ適用する手法は沢山の人達が実験中で試行錯誤している。
従来のアジャイル開発を補強する一つの手法と考えているからだろう。
チケット駆動開発も、デジタルかんばんとしてソフトウェア開発の作業を見える化する手法を提示している特徴もある。
まだまだ改善の余地があるので、色々考えてみる。