ＴＯＣの成果

質問

ソフトウェア開発を行っていて、経営を学ぼうと思っているものです。

最近ソフトウェア開発にTOC理論が応用できるという話を聞き、少し興味を持っています。
それで、このサイト等で調べているうちに、かなり成果を上げているとの意見が多いのですが、一部で否定的な意見も少なからずあることがわかりました。
「昨今ＴＯＣを実践してきた企業は破綻など苦境に立たされ」ているとの意見がありますが、これは本当なのでしょうか。また、TOCはすでに古い理論であり、日本の製造業はすでに実践済みで、次の段階に入っているとの意見もあります。これにはうなずけるような気がします。
それとも、TOC自体に問題があるのではなく、TOCにこだわりすぎて、他の重要なことがおろそかになっているということなのでしょうか。

回答No.1

jyamamoto · ベストアンサー

「経営理論」にはいろいろなものがありますが、いずれも一時期、時代の中で「流行」して、次の新しい理論に乗り換えられる運命にあります。

それは、「○○理論」が学問の世界の功績や、経営コンサルのビジネスのツールとして取り扱われる以上、やむを得ないことです。

ただし、いずれの理論にも、その根幹となる部分は「真理」として、時代を超えて正しいものが多いと思います。

例えば、「ＴＯＣ理論」で言うと、生産工程における「ボトルネック」となる部分工程が全体工程の効率を決めるとして、「ボトルネック工程」に焦点を当てて対策を練ると言う考え方は間違っていないと思います。

要は、いろいろな「経営理論」のエキスの部分を自分の知識としておさめて、それを自分で応用できることの方が大切だということです。

人が評価する理論は、ハナから否定するのではなくて、積極的に学んで、自分で使えるところだけをノウハウとして自分の中に残していくように考えておけばいいのではないでしょうか・・・。

お礼

回答ありがとうございます。

> ハナから否定するのではなくて、積極的に学んで、自分で使えるところだけをノウハウとして自分の中に残していく

わかりました。これはとても重要なことですよね。
他の方の意見を拝見し、TOCがいい、悪いではなく、TOC以外の手法との組み合わせなど複雑な問題が絡み合っていて、答えは簡単には出せないと思うようになりました。

回答No.3

Chuck_GOO

No.2のものです、コメント有難うございました。

ソフトウェア開発における定式化は、いろいろな手法で試みられていますよね。
そもそもパッケージを中心に作るのか、カスタマイズを中心に作るのか、という大枠のところから、
・モデリング手法　（UML etc.）
・開発手法　（アジャイル、ウォーターフォールetc.）
といった個別段階での手法まで含めて。。。

パッケージを作るのであれば、通常の工場に近い形で工程化でき、TOC的な考え方がより適用しやすくなります。
一方
カスタマイズ中心であれば、同一のフレームワークを駆使した設計・開発を行ったとしても、project by projectでお客様の要求や工期なども異なることから、TOC的な考えを継続して適用することが難しいかと思います。

まずTOC的な考え方を導入する前に、「いかに同一工程の繰り返しに近い形で、ソフトウェアを作り上げるか」というところがポイントになってくるかもしれません。

ryusei2さんがどういったソフトウェア開発に関係していらっしゃるのかにもよりますが、
もしパッケージ的なものであれば、「ゴール」「ゴール２」などを一読するだけでも、アナロジーで解決できる問題が少なからず発見できるかもしれませんし、
もしカスタマイズ的なものであれば、「工程の繰り返し」を実現するために、どういう手法が必要か
（モデリングの定式化で対応可能？　開発手法の定式化で対応可能？　プログラムの再利用などリソースの有効活用が必要？）
こういったあたりのアプローチがTOC適用以前に必要な感がします。

以上もしご参考いただける部分あれば幸いです。

お礼

回答ありがとうございます。
大筋で同感であり、ソフトウェア開発の定式化などの話も興味があるのですが、今回は工場でTOCを導入した場合の失敗例、またその原因について知りたいと思っています。

回答No.2

Chuck_GOO

ソフトウェア開発にTOCを応用する場合、「何がボトルネックか」を同定するのが一番難しいのではないでしょうか？

つまり
－工程を予めFIXしにくい（走ってみてからの変更／走ってみないと分からないこと　が多い）
がゆえの悩みかと思います。

通常の工場や流通サプライチェーンのように、流れを定式化してしまえるところには応用しやすいですが、
ソフトウェア開発はその定式化そのものが容易でないところが、その開発効率向上の上で大きな課題となっているように思われます。

もしTOCらしきことを応用するならば、ソフトウェア開発における「完全状態」を想定し、そこから何が欠けているか（何がボトルネックとなっているか）を考えると、少しは役立てることが出来るかもしれません。

「完全状態」とは例えば、
・お客さんの要求をメンバ全員が正確に理解していること
・メンバ全員があらゆる言語を駆使でき、またあらゆる開発手法に通じていること。また過去の関連ソフトウェア開発のノウハウを共有できていること
・メンバ全員がハードウェア性能、通信NW性能など関連するものへの性能理解を十分できていること
・メンバ全員が相互の進捗状態をリアルタイムで正しく把握でき、今自分が何をすべきかを正確に理解できていること
ということかもしれません。

と考えると「不完全だらけ＝ボトルネックだらけ」のソフトウェア開発において、何をどううまく進めていくか、が、実は現状置かれている問題、ということが理解できるのではないでしょうか。。。

以上ご参考なる部分あれば幸いです。。。

お礼

回答ありがとうございます。
Chuck_GOO様の見解には共感できる部分が多くありますが、「不完全だらけ＝ボトルネックだらけ」というのはソフトウェア開発だけではなく、他の産業にも当てはまる場合が多いのではないでしょうか。また、ソフトウェア開発においても、ボトルネックを解決し、利益を上げている会社もあると思います。ただし、日本のソフトウェア業界は「ボトルネックだらけ」=混沌とした状況とはよくいわれますし、私もそのように思います。つまり、TOCを導入する以前の問題ということでしょうか。しかし、多くのボトルネックのうちで、一番重要なところから解決していくという考え方もできるのではないでしょうか。