NEW ENTRY
(01/06)
(07/05)
(07/02)
(06/26)
(06/26)
[PR]
バリューストリームマップとTOC。
リーンソフトウェア開発が定義する7つの原則の1つに、
「ムダを省く」があります。開発作業の中で、ムダになっている部分を
削ぎ落とし、俊敏な開発スタイルを目指すことが狙いです。
具体的には、バリューストリームマップという図を書いて
ムダの見える化を行います。
まず、開発上の作業を洗い出し、それを線上にマッピングしていきます。
その際、各作業間あるいは作業内に発生する待ち時間も
漏れなく記載していきます。
ドキュメントの顧客承認待ちやレビュー待ち等がありますね。
これにより、実作業時間と待ち時間の割合がはっきりとわかるようになります。
（もちろん、実際のプロジェクトではできるだけ待ち時間が発生しないよう
タスクの組み換えを行う工夫が必要でしょう。）
さて、このマップを俯瞰すると、全体の工程の中で
どこがボトルネックになっているかが見える化されるはずです。
TOCの5つのステップの最初のステップとして、この
バリューストリームマップが活用できます。
例えば、レビューアの時間確保がボトルネックとなって
顧客レビュー待ちに大量の時間を費やしているケースが
見えてくるかもしれません。
私が、バリューストリームマップの記述を本で読んで
気がついたのは、TOCのステップに活用できるという点の
他に、アジャイル開発とTOCの親和性が高いのではないか
という点です。
アジャイル開発を行うためのマインド(考え方/心構え)と
TOCのマインドがかなり近いのではと感じました。
この点については別途、書いていくことに致します。
「ムダを省く」があります。開発作業の中で、ムダになっている部分を
削ぎ落とし、俊敏な開発スタイルを目指すことが狙いです。
具体的には、バリューストリームマップという図を書いて
ムダの見える化を行います。
まず、開発上の作業を洗い出し、それを線上にマッピングしていきます。
その際、各作業間あるいは作業内に発生する待ち時間も
漏れなく記載していきます。
ドキュメントの顧客承認待ちやレビュー待ち等がありますね。
これにより、実作業時間と待ち時間の割合がはっきりとわかるようになります。
（もちろん、実際のプロジェクトではできるだけ待ち時間が発生しないよう
タスクの組み換えを行う工夫が必要でしょう。）
さて、このマップを俯瞰すると、全体の工程の中で
どこがボトルネックになっているかが見える化されるはずです。
TOCの5つのステップの最初のステップとして、この
バリューストリームマップが活用できます。
例えば、レビューアの時間確保がボトルネックとなって
顧客レビュー待ちに大量の時間を費やしているケースが
見えてくるかもしれません。
私が、バリューストリームマップの記述を本で読んで
気がついたのは、TOCのステップに活用できるという点の
他に、アジャイル開発とTOCの親和性が高いのではないか
という点です。
アジャイル開発を行うためのマインド(考え方/心構え)と
TOCのマインドがかなり近いのではと感じました。
この点については別途、書いていくことに致します。
PR
TOCの5つのステップ。
ソフトウェア開発へのTOC適用を考え始める前に、基礎を振り返ります。
まずは基礎中の基礎。TOCの5つのステップについて。
TOCの5ステップ
1.制約条件を見つける。
2.制約条件の活用を考える。
3.制約条件に他の条件を従属させる。
4.制約条件を強化する。
5.再び制約条件を探す。
制約条件というのは、ボトルネックのこと。
まずは、一連の仕事の中で、進行を妨げているボトルネックを探すことから
はじめる。
これは、業務フローや工程表を使い、所要時間を割り出すと
見えてきます。
次に、ボトルネック自体の活用を検討します。
ボトルネックの能力を100%活用していない場合、まずはその
稼働率を上げることを考えるわけですね。
ボトルネックの活用を十分に検討したら、次は、他の諸条件を
ボトルネックのスピードにあわせます。
例えば、ボトルネックがどうやっても時間あたり100個しか加工できない機械
であるならば、それに投入する原材料は、加工量に見合った量しか
用意しないという考えです。各工程における在庫の量を減らすことに
なります。
依然としてボトルネックが変わらないようであれば、それ自体の
能力強化を検討する。これが4つ目のステップ。
これらのステップを踏みスループットを向上させると、ボトルネックが
別のところに現れることになる。
新手のボトルネックを探し、再び最初からステップを踏む。
これが、TOCの基本的な考え方の流れです。
まずは基礎中の基礎。TOCの5つのステップについて。
TOCの5ステップ
1.制約条件を見つける。
2.制約条件の活用を考える。
3.制約条件に他の条件を従属させる。
4.制約条件を強化する。
5.再び制約条件を探す。
制約条件というのは、ボトルネックのこと。
まずは、一連の仕事の中で、進行を妨げているボトルネックを探すことから
はじめる。
これは、業務フローや工程表を使い、所要時間を割り出すと
見えてきます。
次に、ボトルネック自体の活用を検討します。
ボトルネックの能力を100%活用していない場合、まずはその
稼働率を上げることを考えるわけですね。
ボトルネックの活用を十分に検討したら、次は、他の諸条件を
ボトルネックのスピードにあわせます。
例えば、ボトルネックがどうやっても時間あたり100個しか加工できない機械
であるならば、それに投入する原材料は、加工量に見合った量しか
用意しないという考えです。各工程における在庫の量を減らすことに
なります。
依然としてボトルネックが変わらないようであれば、それ自体の
能力強化を検討する。これが4つ目のステップ。
これらのステップを踏みスループットを向上させると、ボトルネックが
別のところに現れることになる。
新手のボトルネックを探し、再び最初からステップを踏む。
これが、TOCの基本的な考え方の流れです。
Yベース理論に立つTOC
6月25日、日本TOC推進協議会のCCPM分科会を見学してきました。
講師の岸良さんの話がとても勉強になりました。
その中の一つの話として、印象に残ったのが、TOCは、Y理論ベースに
立つものだというもの。
マクレガーのX理論、Y理論というのは有名ですね。
これまでの経営手法というのは、X理論に立脚してきたという説です。
間違いがないか、心配をする、だから細かくチェックする、管理する。
これは、部分最適を加速する行為です。
一方、CCPMを考えたときに、そこにあるのは、
人を信じるということ、バッファを見守る経営になるということ、そして、
謙虚さ（一人でやらない）、敬意（人を大切にする）。
まさに、Y理論に立つものであると。
「人」が重要なファクターとなるのが、TOC/CCPMというわけですね。
講師の岸良さんの話がとても勉強になりました。
その中の一つの話として、印象に残ったのが、TOCは、Y理論ベースに
立つものだというもの。
マクレガーのX理論、Y理論というのは有名ですね。
これまでの経営手法というのは、X理論に立脚してきたという説です。
間違いがないか、心配をする、だから細かくチェックする、管理する。
これは、部分最適を加速する行為です。
一方、CCPMを考えたときに、そこにあるのは、
人を信じるということ、バッファを見守る経営になるということ、そして、
謙虚さ（一人でやらない）、敬意（人を大切にする）。
まさに、Y理論に立つものであると。
「人」が重要なファクターとなるのが、TOC/CCPMというわけですね。
このブログをはじめるにあたり。
TOCに取り付かれたのはいつのことだったろう？
つい最近のことのように思います。事実そうです。
この三ヶ月ほどで、大量のTOC本を買い集め、読み続けました。
読めば読むほど、心を揺さぶられる。そんな感覚でした。
私は、ソフトウェア業界に身をおく、一介のエンジニアです。
中堅とよばれる域に達して、最近強く感じるようになったのが、
単一の開発プロセスの限界でした。
ウォーターフォールと呼ばれる開発手法です。
この手法は、複数の工程から構成され、進捗の把握が行いやすいと
され、業界のデファクトスタンダートな開発手法となっています。
ウォーターフォールには、一つ、大きな前提があります。
それは前工程の後戻りは発生しないというものです。
しかし、現実には、そうはいきません。
現実のユーザのシステムに対する要求はもっと可変的で、複雑だからです。
後戻りは必ずと言っていいほど発生します。
ですから、開発プロセスとして、ウォーターフォールを常に
当てはめることはできないのです。
そのような状況で、では、なにができるのか。
どのような手法や思考であれば、この問題を乗り越えることができるのか、
そこを端に発し、私が行き着いた一つの手がかりが、TOCでした。
このブログでは、TOCをソフトウェア開発にどうすれば適用するかを
考えていきます。
とはいえ、私は、TOCの世界の入り口に立ったばかりの者です。
このブログを私自身の学びの場としたいと思っています。
つい最近のことのように思います。事実そうです。
この三ヶ月ほどで、大量のTOC本を買い集め、読み続けました。
読めば読むほど、心を揺さぶられる。そんな感覚でした。
私は、ソフトウェア業界に身をおく、一介のエンジニアです。
中堅とよばれる域に達して、最近強く感じるようになったのが、
単一の開発プロセスの限界でした。
ウォーターフォールと呼ばれる開発手法です。
この手法は、複数の工程から構成され、進捗の把握が行いやすいと
され、業界のデファクトスタンダートな開発手法となっています。
ウォーターフォールには、一つ、大きな前提があります。
それは前工程の後戻りは発生しないというものです。
しかし、現実には、そうはいきません。
現実のユーザのシステムに対する要求はもっと可変的で、複雑だからです。
後戻りは必ずと言っていいほど発生します。
ですから、開発プロセスとして、ウォーターフォールを常に
当てはめることはできないのです。
そのような状況で、では、なにができるのか。
どのような手法や思考であれば、この問題を乗り越えることができるのか、
そこを端に発し、私が行き着いた一つの手がかりが、TOCでした。
このブログでは、TOCをソフトウェア開発にどうすれば適用するかを
考えていきます。
とはいえ、私は、TOCの世界の入り口に立ったばかりの者です。
このブログを私自身の学びの場としたいと思っています。