さてさて、そろそろ何か始めないとな

さいたま市のソフトウェアエンジニアのブログ

TOC(Theory Of Constraints)の考え方は重要だが、誤解したままソフトウェア開発現場に持ち込むな

TOC(Theory Of Constraints)制約理論

うちの職場の人たちは、自分たちの現状分析をしようとしないのです。

TOCが大事だと訴えている担当者がいます。

何をそんな当たり前のことを行っているのだろうかと思います。

本当に面倒です。

そろそろTOC協会が嫌いになりそうです。

japan-toc-association.org

TOC(Theory Of Constraints:「制約理論」または「制約条件の理論」)は、「どんなシステムであれ、常に、ごく少数(たぶん唯一)の要素または因子によって、そのパフォーマンスが制限されている」という仮定から出発した包括的な経営改善の哲学であり手法です。

そして、

「制約にフォーカスして問題解決を行えば、小さな変化と小さな努力で、短時間のうちに、著しい成果が得られる」

実に当たり前です。とても良いことを語ってくれています。

開発工程において、何が制約条件となっているのかを見極めて、制約にフォーカスして問題解決を行うことが一番効果があるということです。

これを正しく解釈するのであれば、自分たちのプロジェクトのどこに制約があるのかを分析し、対策を実施することが一番効果を得られるのであると言っています。

さらに、このTOC協会の「TOCの基本の考え方」の中では、以下についても明記してくれています。

どこもここもと言うのでは、組織としてのパフォーマンスは改善するどころか、むしろ悪化して、リソースと時間を無駄に消費することになります。

それにも関わらず、うちの担当者が

「TOCが大事です」

と言いながら、

「今度のプロジェクトにCCPMを適用します。」

「適用した結果、プロジェクト納期を調整しなければなりません。」

と言った。

 

はっ?上に書いたままの注意点をもう一回読み直すべきだ。

もう一回コンサルしてもらってきてください。

www.goal-consulting.com

コンサルティング会社は、考え方や、やり方は教えてくれます。

しかし、ソフトウェア開発現場の実情を知りません。ましてや我が社のソフトウェア開発プロセスの何が問題で、どのようにしなければいけないのかを知りません。

「それを考えるのは、あなたたちです。」とは言わないと信じています。

自分たちが、どのような開発を行っている状況なのかをコンサルティング会社に伝えて知恵をもらわなければならないはずです。

高いお金を払っているのだから。

残念なことに、自分たちが、どのようなソフトウェアをどのようにして開発してきたかを知らないのか、説明できないのです。

相談の仕方がわからないだけかもしれませんが、とにかく言われとおりに実施しようとする人たちが多いのです。

 

実際にCCPMを適用して、うまく成果を出せていると言っているソフトウェア開発現場も存在します。(本当かどうかは知りませんが)

www.slideshare.net

ここでも随分ありがたい資料を公開してくれています。

重要なことが書かれているのに、どこが重要なのかを理解できていないのが悲しいです。

CCPMの向くもの=外部的な制約の少ないもの

適用範囲を見極める=ソフトウェア開発でCCPMを実施しやすい例:内部設計、コーディング、テスト工程

なぜ、経験者の話をありがたく聞かないのだろうかと思います。

外部的な制約が少ない必要が「なぜ」あるのかを考えていないのです。

設計、コーディング、テスト工程には実施しやすくて、それ以外への適用が「なぜ」難しいのかを理解してくれていないのです。

  • 顧客へのサンプルソフトウェアの出荷日程が何度も決まっている。
  • ハードウェアの検証のためのサンプルソフトウェアの提供日程が決まっている。
  • 外部の委託先のエンジニアへの発注をもとにして、日程の計画を立てた上で、開発を実行するソフトウェア開発である。
  • 共通モジュールを利用した開発対象モジュールが複数発生するような新規開発案件である。

これらは、どれもかしこも、外部的な制約です。

大規模なソフトウェア開発であれば、Critical Chainには、沢山の外部制約が紐付いています。

先行するタスクの遅延の影響範囲が非常に大きく致命的な場合が多々あります。

「必要なモジュールをいつまでに提供するので、開発チームをいつまでに準備してください。」といったら、遅れたらダメなのです。

間に合わせることが基本です。しかし、想定できない事象によって遅延することが予測される場合には、すみやかに調整を行うことが必要です。ソフトウェアなのですから、部分的なリリースをするように調整することだってできます。

できる限り関連するタスクの影響がないように考慮して仕事を進めるべきなのです。

80人エンジニアを揃えたけれど、「遅延したから一週間遅れます」と言ったら、大損害ですね。遅延しないように、遅延する前に全員でカバーしましょう。

最後のバッファで調整しようという発想はありえないです。

 

そうは言っても、プロジェクトの遅延が見えるようになっていないのは問題ですので、まずはそこから改善しましょう。

 

CCPMを適用実施するのは、そういった外部制約の一切ないソフトウェア開発プロジェクトから試してみてください。

 

お願い、ちゃんと理解するまで、私のプロジェクトに関わらないで。