https://papanda0806.blog.shinobi.jp/ TOCのソフトウェア開発への適用を考察するブログ。 ja 2008-01-06T22:25:45+09:00 https://papanda0806.blog.shinobi.jp/ccpm/ccpm%E3%81%A7%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%96%8B%E7%99%BA%E3%82%92%E8%A1%8C%E3%81%86%E8%A8%B3%EF%BC%881%EF%BC%89 システム開発においては、新規にシステムを構築する場合と 既に構築されたシステムをメンテナンスされる場合とに 大きく分けることができる。 前者を新規開発、後者を保守開発と呼ぶことにする。 新規開発においては、システムを実際利用する現場への 投入をより早く求められることが多い。 開発... 既に構築されたシステムをメンテナンスされる場合とに
大きく分けることができる。
前者を新規開発、後者を保守開発と呼ぶことにする。


新規開発においては、システムを実際利用する現場への
投入をより早く求められることが多い。
開発にはスピードが要求される。
なぜならば、現場では既にそのシステムを必要と
しているからである。一日でも早く新しいシステムを
使うことによって、業務改善が進む可能性がある。


これは企業が利用する業務システムに限ったことではない。
何らかのサービスを開始するにあたって、システムを
利用する場合でも（BtoC）、いち早く、そのサービスを
開始することによって、早期に利益を得ることができるから
である。逆にいえばサービスを開始するまでは一円にも
ならない。


かくして、開発側はこのニーズに応えるために多大なる
苦労を払うことになる。
納期だけ考えていれば良いわけでもない。
当然、品質と、コストのバランスを取りつつ開発を進めなければ
ならない。


この点、新規開発にはCCPMが強力な威力を発揮する。]]> CCPM 2008-01-06T22:25:45+09:00 toichi NINJA BLOG toichi https://papanda0806.blog.shinobi.jp/toc/%E3%83%90%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%A0%E3%83%9E%E3%83%83%E3%83%97%E3%81%A8toc%E3%80%82 リーンソフトウェア開発が定義する7つの原則の1つに、 「ムダを省く」があります。開発作業の中で、ムダになっている部分を 削ぎ落とし、俊敏な開発スタイルを目指すことが狙いです。 具体的には、バリューストリームマップという図を書いて ムダの見える化を行います。 まず、開発上の作業を洗い出し... 「ムダを省く」があります。開発作業の中で、ムダになっている部分を
削ぎ落とし、俊敏な開発スタイルを目指すことが狙いです。

具体的には、バリューストリームマップという図を書いて
ムダの見える化を行います。
まず、開発上の作業を洗い出し、それを線上にマッピングしていきます。

その際、各作業間あるいは作業内に発生する待ち時間も
漏れなく記載していきます。
ドキュメントの顧客承認待ちやレビュー待ち等がありますね。
これにより、実作業時間と待ち時間の割合がはっきりとわかるようになります。
（もちろん、実際のプロジェクトではできるだけ待ち時間が発生しないよう
タスクの組み換えを行う工夫が必要でしょう。）





さて、このマップを俯瞰すると、全体の工程の中で
どこがボトルネックになっているかが見える化されるはずです。
TOCの5つのステップの最初のステップとして、この
バリューストリームマップが活用できます。
例えば、レビューアの時間確保がボトルネックとなって
顧客レビュー待ちに大量の時間を費やしているケースが
見えてくるかもしれません。

私が、バリューストリームマップの記述を本で読んで
気がついたのは、TOCのステップに活用できるという点の
他に、アジャイル開発とTOCの親和性が高いのではないか
という点です。
アジャイル開発を行うためのマインド(考え方/心構え)と
TOCのマインドがかなり近いのではと感じました。
この点については別途、書いていくことに致します。]]> TOC 2007-07-05T22:04:39+09:00 toichi NINJA BLOG toichi https://papanda0806.blog.shinobi.jp/toc/toc%E3%81%AE5%E3%81%A4%E3%81%AE%E3%82%B9%E3%83%86%E3%83%83%E3%83%97%E3%80%82 ソフトウェア開発へのTOC適用を考え始める前に、基礎を振り返ります。 まずは基礎中の基礎。TOCの5つのステップについて。 TOCの5ステップ 1.制約条件を見つける。 2.制約条件の活用を考える。 3.制約条件に他の条件を従属させる。 4.制約条件を強化する。 5.再び制約条...
まずは基礎中の基礎。TOCの5つのステップについて。

TOCの5ステップ
1.制約条件を見つける。
2.制約条件の活用を考える。
3.制約条件に他の条件を従属させる。
4.制約条件を強化する。
5.再び制約条件を探す。

制約条件というのは、ボトルネックのこと。
まずは、一連の仕事の中で、進行を妨げているボトルネックを探すことから
はじめる。
これは、業務フローや工程表を使い、所要時間を割り出すと
見えてきます。
次に、ボトルネック自体の活用を検討します。
ボトルネックの能力を100%活用していない場合、まずはその
稼働率を上げることを考えるわけですね。
ボトルネックの活用を十分に検討したら、次は、他の諸条件を
ボトルネックのスピードにあわせます。
例えば、ボトルネックがどうやっても時間あたり100個しか加工できない機械
であるならば、それに投入する原材料は、加工量に見合った量しか
用意しないという考えです。各工程における在庫の量を減らすことに
なります。
依然としてボトルネックが変わらないようであれば、それ自体の
能力強化を検討する。これが4つ目のステップ。
これらのステップを踏みスループットを向上させると、ボトルネックが
別のところに現れることになる。
新手のボトルネックを探し、再び最初からステップを踏む。
これが、TOCの基本的な考え方の流れです。]]> TOC 2007-07-02T00:54:38+09:00 toichi NINJA BLOG toichi https://papanda0806.blog.shinobi.jp/toc/y%E3%83%99%E3%83%BC%E3%82%B9%E7%90%86%E8%AB%96%E3%81%AB%E7%AB%8B%E3%81%A4toc 6月25日、日本TOC推進協議会のCCPM分科会を見学してきました。 講師の岸良さんの話がとても勉強になりました。 その中の一つの話として、印象に残ったのが、TOCは、Y理論ベースに 立つものだというもの。 マクレガーのX理論、Y理論というのは有名ですね。 これまでの経営手法という... 講師の岸良さんの話がとても勉強になりました。

その中の一つの話として、印象に残ったのが、TOCは、Y理論ベースに
立つものだというもの。

マクレガーのX理論、Y理論というのは有名ですね。
これまでの経営手法というのは、X理論に立脚してきたという説です。

間違いがないか、心配をする、だから細かくチェックする、管理する。
これは、部分最適を加速する行為です。

一方、CCPMを考えたときに、そこにあるのは、
人を信じるということ、バッファを見守る経営になるということ、そして、
謙虚さ（一人でやらない）、敬意（人を大切にする）。

まさに、Y理論に立つものであると。
「人」が重要なファクターとなるのが、TOC/CCPMというわけですね。]]> TOC 2007-06-26T00:10:01+09:00 toichi NINJA BLOG toichi https://papanda0806.blog.shinobi.jp/toc/%E3%81%93%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E3%81%AB%E3%81%82%E3%81%9F%E3%82%8A%E3%80%82 TOCに取り付かれたのはいつのことだったろう？ つい最近のことのように思います。事実そうです。 この三ヶ月ほどで、大量のTOC本を買い集め、読み続けました。 読めば読むほど、心を揺さぶられる。そんな感覚でした。 私は、ソフトウェア業界に身をおく、一介のエンジニアです。 中堅とよばれる域... つい最近のことのように思います。事実そうです。
この三ヶ月ほどで、大量のTOC本を買い集め、読み続けました。
読めば読むほど、心を揺さぶられる。そんな感覚でした。

私は、ソフトウェア業界に身をおく、一介のエンジニアです。
中堅とよばれる域に達して、最近強く感じるようになったのが、
単一の開発プロセスの限界でした。

ウォーターフォールと呼ばれる開発手法です。
この手法は、複数の工程から構成され、進捗の把握が行いやすいと
され、業界のデファクトスタンダートな開発手法となっています。

ウォーターフォールには、一つ、大きな前提があります。
それは前工程の後戻りは発生しないというものです。

しかし、現実には、そうはいきません。
現実のユーザのシステムに対する要求はもっと可変的で、複雑だからです。
後戻りは必ずと言っていいほど発生します。

ですから、開発プロセスとして、ウォーターフォールを常に
当てはめることはできないのです。

そのような状況で、では、なにができるのか。
どのような手法や思考であれば、この問題を乗り越えることができるのか、
そこを端に発し、私が行き着いた一つの手がかりが、TOCでした。

このブログでは、TOCをソフトウェア開発にどうすれば適用するかを
考えていきます。
とはいえ、私は、TOCの世界の入り口に立ったばかりの者です。
このブログを私自身の学びの場としたいと思っています。]]> TOC 2007-06-26T00:02:28+09:00 toichi NINJA BLOG toichi