1. CCPM+(日本語版)ホーム
  2. CCPM+(日本語版)よくある質問
  3. ラリー・リーチのCCPMワークショップ(PM654)での質疑応答

ラリー・リーチのCCPMワークショップ(PM654)での質疑応答

ラリー・リーチのCCPMワークショップ(PM654)での質疑応答です。ご覧になりたい見出しをクリックしてください。

CCPMの導入に関連する質疑応答

このページの先頭へ

伝統的なプロジェクトマネジメントへの、CCPMアプローチのチャレンジ

このページの先頭へ

スケジューリングとプロジェクトチームの動機づけ

このページの先頭へ

マルチタスキングと資源の割当て

このページの先頭へ

CCPMのソフトウェアとその他のプロジェクトマネジメントソフトウェア

このページの先頭へ

CCPMと非営利的な組織、政府組織

このページの先頭へ

新しい事業を対象としたCCPM

このページの先頭へ

Six Sigma、TOC、そしてCCPM

このページの先頭へ

アジャイル・プロジェクトマネジメント

このページの先頭へ

CCPMの導入に関連する質疑応答

ある会社にCCPMが向いているかどうかを、どのようにして判定するのですか。

プロジェクトを行なっている会社なら、それがどのような会社であっても、CCPMはぴったり適合しますよ。まず、PMIのプロジェクトについての定義を読んでみてください。生産にはドラム・バッファ・ロープを、プロジェクトにはCCPMを適用しますが、生産とプロジェクトの間には、グレーゾーンがあります。基本的に、すべてのプロセスとプロジェクトには、アクティビティやプロセスステップ間に順序があり、また、変動性があるので、このことをはっきり認識しているTOCのアプローチは、どのような組織にも適合します。

ラリーさんは、ご本の中で、TOCやCCPMの方法論を見につけるには、すこし、時間が掛かると書いておられます。そこで、お伺いしたいのですが、プログラムマネジャーが、このような基本的な変化を、自分の組織に導入、展開するには、どのような順序で行なったらよいでしょうか。また、時間はどれくらい掛かる、と考えたらよいでしょうか。

まず、最初にやらなければならないことは、評価の尺度と、活動の結果をフィードバックする権限を持っているマネジャーにTOCやCCPMの方法論を売り込み、彼らがその考え方の虜になるように仕向けなければなりません。次に行なうことは、TOCやCCPMの概念を、インプリメンテーションの中核的になるチームに理解させ、教え込まなければなりません。次いで、所属する組織にユニークな実行計画を作成して、計画を実行します。

ラリーさんのお考えでは、CCPMを導入、展開するための一番よい方法はなんでしょうか。多くの会社では、組織全体にCCPMを広げる前に、CCPMを使って、試しに、いくつか、プロジェクトを行なっているのでしょうか。

殆どの会社は、CCPMがどのように機能するかについての、自分たちの理解が正しいかどうかを確かめるために、パイロットプロジェクトをやり、自分たちの組織にユニークな障害を見つけだし、それへの対策を考え出します。このとき、これを行なうプロセスに、例えば、DMAIC(define、 measure、 analyze、improve、control)のような改善方法論を利用します。

プロジェクトを行なうことに不慣れな、また、公式のPM方法論を未導入の組織でクリティカルチェーン/TOCを導入したり、適用したりするにはどうしたらよいでしょうか。

多くの組織では、CCPMを導入、展開するとき、まず、もっとフォーマルなプロジェクトマネジメントの方法論を導入します。こうした方が、今までの悪い習慣を捨てるのが容易だからです。

大きな組織では、このような大きな変化の導入、展開をどのようにして行なったらよいのでしょうか。会社として、ある部門ではCCPMを使い、他の部門では使わない、なんてことをしたりしますか。

上記の質問3を見てください。当然のことですが、組織が大きければ大きいほど、CCPMの導入、展開は、一層、難しくなり、時間も余計に掛かります。「難しさ」は、マネジメントの意見を一致させることが容易か、それとも困難かの関数です。

CCPMを使うには、小さすぎたり、簡単すぎたりするプロジェクトと言うものはありますか。

アクティビティが複数あり、関係する人が複数いたら、このようなプロジェクトは、CCPMを使うには、小さすぎたり、簡単すぎたりするプロジェクトとは言えないですね。これまで、何らかのスケジュールツールを使っていたとするなら、CCPMも使えますよ。

このページの先頭へ

伝統的なプロジェクトマネジメントへの、CCPMアプローチのチャレンジ

上級マネジメントは、多くの場合、残業の多少や資源の追加の有無の状況を通してのみ、プロジェクトがスケジュール通りに進行しているかどうかを判断しています。この方法は、長い間、使われてきているので、マネジメントは、これを規範として受け容れてしまっています。中級マネジメントは、自分の責任部分を管理できないように思われるので、このような管理方式を嫌がっていますが・・・。ところで、これは、政府組織の場合です。

確かにそうですね。私もそのような組織で、たくさん働いたことがあるから、よくわかります。しかし、政府組織の中にも、CCPMを適用して、大成功を収めたところもあります。ただし、それらは、指導力のあるリーダーに統率された場合です。そして、通常、指導力のあるリーダーは、中級マネジャーで、現状にあきたらず、そこから飛び出したひとたちです。しかし、これらのイニシアティブは、容易には、組織全体には広がりません。しかし、勿論、組織全体に広がった例もあります。ご質問のような状況では、中級マネジャーは、多分、嘘のレポートを行なうほかありませんね。

たくさんのプロジェクトマネジャーは、ワークパッケージの期間を「正しく」推定するときに立ち往生してしまいます。TOC/CCPMは、このようなとき、プロジェクトマネジャーを、どのように助けてくれるのですか。

私たちは、プロジェクトマネジャーの皆さんに、変動性を理解させようとしてきています。変動性を理解できれば、プロジェクトマネジャーの皆さんは、自分たちが重視している「タスク期間」への執着、実は、もっと重要なのですが、「完了期日」への執着を打破できるようになります。変動性を理解した人は、一つの数字で表した「正しい」期間の推定値などというものは、この世に存在しないことを理解できます。そんなものは作り事です。皆さんも、人々を、現実の世界に連れ戻してください。

ラリーさんが書かれたCCPMの本やウエブサイトを読むと、ラリーさんは、Stephen Coveyが「高度に効率的で、能力のある人たちの7つの習慣」(Covey, 1990)(和訳:『7つの習慣―成功には原則があった!』)に書いていることに影響された、というようなことが読み取れます。そこで質問ですが、貴方がCCPMの方法論を開発したとき、Coveyに影響されたのでしょうか。

はい。確かに影響を受けたと言えると思います。そして、この影響は、CCPMへの私のアプローチにまで及んでいます。私は、彼が、まだ、有名になっていない頃、ユタ州のサンダンスで、一週間、ともに過ごす、という幸運に恵まれました。彼は、その後、あまりにも有名になってしまったので、最近では、なかなか、近寄るのが難しいですね。私に、彼よりも、もっと影響を与えた唯一の人物は、2500年前に生きていた人です。彼は、「お釈迦様」と呼ばれています。お釈迦様についても、いろいろ、学びました。

「インタンジブルな」制約は、CCPMのアプローチでは、どこに位置づけられているのですか。私が、最近、関係したプロジェクトは新製品開発についてのプロジェクトでした。プロジェクト開始時点での重要な仮定は、市場への販売価格を考えると、カギとなるコンポーネントが、ある一定のコストかそれ以下で生産できる、というものでした。プロジェクトの2/3が完了した頃、この目標コストが実現不能である、と判定されました。このプロジェクトは、この後、さらに、何ヶ月も続き、そして消えて行きました。

私から見れば、貴方のお話した例は、インタンジブルではなくタンジブルだと思いますよ。このような基本的なプロジェクトの仮定は、識別し、あらかじめ、ステークホールダーが認識しているようにしておかないといけません。そして、有効なリスクマネジメントのプロセスを持ち、重要な仮定が満たされないときは、あらかじめ決めておいたリスクについての意思決定のシナリオに従い、プロジェクト変更をトリガーするべきです。

状況: 市販のソフトウェアパッケージへのシステムの置き換え 私のチームに与えられていた課題は、社内で開発され、保守にお金が掛かってしょうがない、非効率な会計システムを、高機能で、技術的に進んでいる市販のソフトウェアパッケージに置き換えることでした。この置き換えには、約9ヶ月かかる予定でした。もともとのスコープに従い、私のチームは、予算内で、予定通りにプロジェクトを完了できるはずでした。不幸なことに、コンピュータベンダーは、このソフトウェアに絶え間なく更新と改善を加え続けました。これらの更新と改善は、その時点のバージョンとのコンパティビリティとサポートを維持するために行なわれるということでした。ソフトウェアはカットオーバーされましたが、プロジェクトは独り歩きし始め、継続的な修正とエンハンスメントで、今日まで続いています。
質問: IT産業では、変化はとどまることを知りませんが、基幹ソフトウェアのインストレーション・プロジェクトでは、「スコープ」をどのようにコントロールしたらよいのですか。これらの変更は、(例えば、人的資源、プログラマー、扱う分野の専門家、エンドユーザへのフィードバックなどの)新しい制約を生み出してしまいがちです。このような状況で、クリティカルチェーンの制約をレビューし、分析するには、それでなくても忙しい資源に参加してもらわなければなりません。

あー、それは「”ミスター要件変更(”scope creep:プロジェクトやシステム開発の要件および仕様が確定し、作業段階に入っているにもかかわらず、予定外の変更や追加があり、コスト増大、スケジュール遅延につながるような重大なもの)」ですね。私は、プログラムの計画作成の仮定を明確にし、併せて、要件変更プロセスを公式なプロセスとして実行して、”ミスター要件変更”が忍び込もうとしてもプロセスに入れないようにしています。私は、小さな変更が溜まってくるときも、それを対象に、プロジェクト変更のプロセスを実行します。小さな変更が溜まると、全体としてのインパクトも大きなものになることがありますからね。それらをうまく料理しないと、逆に、料理されてしまいますよ。

私の会社では、「CMMI(capability maturity model Integrated)」のレベル3と「ITIL(ITインフラストラクチャ・ライブラリ)」の導入に取り組んでいます。これらのプロセスを実行するとき、SDLC (System Development Life Cycle)を一つのシステムとして扱います。要件は、すべてのタスクのインプットになり、したがって、一番早く取り組まれなければなりませんね。また、専門家たちの評価や意見を効果的に使うと全体的な仕事量を減らせます。要件をトレースすると全体的なプロセススケジュールを短縮できます。こうした中で、CCPMをうまく組み込むには、どのようなことに注意したらよいでしょうか。

うまく行っているようですね。私が、貴方に注意したらよいと思うことは、制約を意識して、ワークフローの改善を、常時、行なおうとすることです。適切に使えば、専門家たちの評価や意見は強力ですが、プロセスが、エラーの探知、エラーの訂正ではなく、エラーの防止を目的としたものであるべきだと言うことです。
私は、CCPMを、皆さんが、皆さんの職務、すなわち、プロセスの進捗をマネジメントする方法にしたいということです。

ラリーさんのご経験では、ITプロジェクトの期間短縮は、どの辺りの分野で行なえるとお考えですか。

一言で言えば、肝心なことに焦点を併せることです。私は、「軽い」とか、「しなやかで、機動的な」という枕詞を付けられたアジャイル・アプローチとして分類されているITプロジェクト方法論の中で、いくつか、いいな、と思うものもあります。私が関係した、たくさんのIT組織では、「基本」ができていません。まず、基本をしっかりしたものにしてください。要件の明確化、WBS、責任の割当て、変更管理などなどです。そして、タスクに取り組む人たちにマルチタスクを課さないことです。

このページの先頭へ

スケジューリングとプロジェクトチームの動機づけ

私は、「タスクの遂行時間に余裕を与えると、人々は、その余裕を使い切ってしまう」という概念に同意します。しかし、彼らに、タスクを行なうのに必要なぎりぎりの時間まで、タスク期間を短くするように求め、さらに、ある時点で、一つのタスクに集中し、次のタスクは行なわない、ということを求めることは、人々の活動レベルを高く維持するように仕向けることにつながるように思われます。ラリーさんは、彼らが燃え尽きることなく、この高いレベルの活動を継続的に行なわせるには、どのような動機づけをしたらよいとお考えですか。

CCPMでは、人々を追い立てて働かせるようなことはしません。彼らが上手に働けるように手助けしようとするのです。そして、彼らが、適切なタイミングで、適切な方法で、適切なタスクに取り組み、組織としてのプロジェクトのフローの改善ができるようにします。一番、大きなポイントは、タスクの同期を実現することです。つまり、あるタスクを開始するとき、必要なインプットがない、などということが決して起こらないようにすること、そして、マルチタスキングをしないですむようにすることです。

プロジェクトマネジメントに使われるクリティカルチェーンを実際に適用するとき、これまでの方法では、個々のタスク期間に含まれていた安全余裕を取り上げ、それらをプールして、プロジェクト全体を防護するためのプロジェクトバッファに入れるということでした。人々が、タスク期間が短縮されると知ったとき、これらのタスク期間推定を行なう方法を、期待通りに行なわせるにはどうしたらよいですか。

タスク期間推定値を「個人の推定値」にさせてはいけません。タスク期間推定値は、「プロジェクト計画の推定値」です。彼らがクリティカルチェーンの考え方で働き始め、タスクの「完了までの残り期間」をインプットするようになると、正しい推定を行うようになります。もし、完了までの推定値が計画よりも長いと、チーム全体が、それにより、バッファへの食い込みが起こるということを知ることになります。そして、必要に応じ、アクションが取られます。通常、プロジェクトマネジャーは、その情報を、チームと共有するだけです。

チームメンバーやグループに、特定のタスクが、推定期間内で、上手く終了する確からしさを聞くこと以外に、「大量の水増し」を含まない正直な期間推定値を得るための方法がありますか。

私が推奨する方法は、最初は、まず、彼らが従来行なってきた方法で、推定を行なわせることです。もし、推定値が、資源の利用可能な時間の100%ではなく、その一部を前提としたものであったら、仕事をそのままにして、タスク期間を決める資源の100%がそのタスクに使われるようになるまで、推定値を短くして行きます。そして、こうして得られた「資源の利用可能な時間の100%を前提とした、従来の方法による推定値」の半分をタスク期間推定値とし、残りの半分の半分をプロジェクトバッファに振り向けます。

実績を推定値に比較したものを、ゆっくり時間をかけて、記録して置き、改善データとしてください。決して、直前のプロジェクトの実績に基づいて、毎回、毎回、推定値を変更してはいけません。

ラリーさんは、Herzbergの「・・・、マネジャーの仕事は、部下が課題を達成するように彼らを動機づけるのではなく、マネジャーは、部下に、彼らが課題を達成できる機会を与え、それを通じて動機づけられるようにすることだ」という文章を引用なさいましたね。私の経験によると、課題の達成自体だけでも、部下は動機づけられるようですが、何らかの「ご褒美」がないと長続きしないようです。ラリーさんのCCPMには、そのような部分も含まれているのですか。

まさに、その通りです。私は、「もたらされたもの」と「ご褒美」を対比して考えることをお勧めします。推薦する図書は、AuberyとJames Danielsのかいた本です。

ラリーさんは、「ご褒美」がうまく効かない場合も議論されていますね。ラリーさんが「罰は、関係を裂く」などと書かれていますが、仕事上でのご褒美との関連で、失敗しないで、動機づけられた状態を長続きさせるご褒美の例を挙げてくださいませんか。

そうですね。一番いいのは、ボスが言葉でフィードバックする方法ですね。「ジョーン。あの仕事では、本当によい仕事をしたね。とくに、・・・を高く評価しているよ。」このようなことを、書いたもので渡すのも、とても、効くと思います。図書券みたいなほんのお礼の印」的なものもよいでしょう。しかし、決して、人々が「外発的報酬(extrinsic rewards )」を目的にして働くような状況を作ってはいけません。

このページの先頭へ

マルチタスキングと資源の割当て

いろいろな組織でマルチタスキングが広く行なわれたり、継続的に行なわれたりしています。これは、重大な資源問題の表れなのではないでしょうか。つまり、適切なスキルを持ち、それらの仕事を行える人々が少ないから、マルチタスキングを行なわざるを得ない、と言うことではないでしょうか。

マルチタスキングが、多くの組織で当たり前になっているのは、マネジメントが、マルチタスキングの意味するところを正しく理解していないからです。多くの人々は、「マルチタスキングは、我々が仕事をやり遂げるための唯一の方法だ」と主張します。しかし、マルチタスキングは、物事を悪くしてしまいます。通常、それも、想像以上に。私が関係したすべての組織では、マルチタスキングを大幅に減らしたら、実は、キャパシティに余裕があることが判明しました。

人々がマルチタスキングを行うのは、マネジメントが、彼らにそのような行動を取るように仕向けているからです。

私は、製造業の会社にIT部門で働いています。2005年に、私の会社は、PMIに準拠したプロジェクト方法論を導入しました。したがって、うちの会社は、プロジェクトマネジメントについては、まだまだ、これから、成熟度を高めてゆく段階です。私のITグループは10人前後です。そして、私たちにとっては、マルチタスキングは当たり前のことです。いくつかのプロジェクトに、同時に参加することに加え、運用のサポートも行なわなくてはなりません。つまり、プロジェクトと運用サポートの両方に、責任を持たされているのです。ラリーさんから、なにかよいお考えをお聞きしたいのですが。

貴方は、まず、すべての仕事を同じように扱い、人々が、ある時点で、一つのタスクに専念できるようにして、それをできるだけ早く済ませられるようにしなくてはなりません。そして、例えば、今週、日々の業務運営に影響する運用のタスクの優先順位が高いなら、それはそれで結構です。そして、それが済むまで、プロジェクトのタスクに手をつけてはいけません。このような状況を考慮したとき、有効なことは、キャパシティ制約バッファを考えることです。また、プロジェクトバッファを置いて考えるのも役立つでしょう。

このページの先頭へ

CCPMのソフトウェアとその他のプロジェクトマネジメントソフトウェア

マルチプロジェクト環境にある会社で働いていますが、ラリーさんが開発されたCCPM+(日本語版)を評価しようとしています。ラリーさんのMicrosoft Projectのアドインのソフトウェアは、資源の平準化、クリティカルチェーンの識別を行うとき、共有資源が、すでに、他のプロジェクトに割り当てられているコミットを考慮しますか。

マネジメントは、人々が行なわなければならない「すべて」のタスクを考慮し、組織として望ましいワークフローが得られるように優先順位を決めなければなりません。個々人は、これを行なう情報を持っていません。このソフトウェアは、適切に使えば極めて有効ですが、決して、この目的のための「ザ・ソリューション」ではなく、マネジメントが行なうべきことです。

プログラムマネジャーにとって、スケジュール作成プログラムは必要なスキルです。しかし、私の部下たちは、GanttチャートやPERTチャートを上手に使えず、行き詰まってしまいます。ラリーさんのお考えでは、ご自分のソフトウェアをOutlookやLotus Notesにつなぎ、これらの人々に、日々のTo-Doリストを作成して、「タスクの期日がせまっているよ」というリマインダーを、メールで送らせるようなことになにか利点があるとお考えでしょうか。

人々は、どのタスクに取り組んだらよいかを知らなければなりません。また、自分たちの行なっているタスクの進捗をフィードバックする必要があります。私は、それをどのような方法でやっても構わないと思っています。CCPM+(日本語版)は、MS Project Serverにつながるので、OutlookやProject WEB Serverを使って、仰る方法で行なうことは可能です。しかし、このソフトウェアは、この目的のための「ザ・ソリューション」ではありません。

いろいろな種類の、いろいろな規模の会社でのラリーさんのご経験から見て、プロジェクトマネジメントのソフトウェアが、それらの会社の「プロジェクトマネジメントのアプローチやプロセス」に与えたインパクトは、どのようなものであったかとお考えですか。

わたしは、これまでに、よい例、悪い例の両方を見てきました。そして、どのようにソフトウェアを使うかは、会社によって、また、同一の会社であってさえも、大きく異なるのを見てきました。必要なことは、「適切なタスクが、適切な人によって、適切な順序で行なわれるようにすること」に集中することで、そうすれば、人々は、自分の与えられた仕事に集中できるようになります。ソフトウェアは、決して、この目的のための「ザ・ソリューション」ではありませんが、適切に使えば有効です。

プロジェクトマネジメントのソフトウェアにより、「もっと計画をしっかり作成すれば問題は解決する」という“do more better” philosophyを拡げたり、プロジェクトマネジメントのソフトウェアがいつでも利用可能であるということにより、事前には見えなかった方法で、プロジェクトマネジメントの専門家が光明を得たということを見たことがありますか。

勿論、あります。だからこそ、私の本の中で、このことを強調しているのです。プロジェクトが失敗するのは、計画の中に、計画されていないことによるものです。したがって、計画の中に、必要な詳細を追加することで、多分、プロジェクトの失敗を減らすことができると思います。

PMIのメンバーが増加していますが、これは、確かに、プロジェクトに関係する人たちの間で、PMを「value-adding activity 」として見る人たちが継続して増えていることを示していると思います。しかし、まだまだ、これを「コスト」だとみなす会社もたくさんありますね。

このページの先頭へ

CCPMと非営利的な組織、政府組織

私は、以前、非営利的な組織で働いていました。ラリーさんは、CCPMのご本の中で、非営利的な分野のことについて触れておられます。CCPMは、非営利的な組織にとっても完全に機能するツールだと思いますが、それを使った組織を、あまり、見たことがありません。ラリーさんは、これまでに、非営利組織がCCPMを使った例を知っておられますか。また、そのような事例があるとして、非営利組織へは、CCPMは、どのように導入、展開されたのでしょうか。

私が経験した主な非営利組織は、軍関係のサービスを行なっている政府組織です。私は、米国海軍、空軍のプロジェクトで働きました。これらの組織は、素晴らしい成果を挙げました。また、米国陸軍、海兵隊も、びっくりするような成果を挙げています。また、医療分野でも、素晴らしい成果が報告されています。

非営利組織での事例の文献をご存知でしょうか。私は想像するんですけど、非営利組織では、CCPMを導入して得られる成果が、民間企業とは異なり、収入や生産などに結びつかないので、PMの諸概念を使うことについての大議論が行われるだろうと思います。

このことについてのPMI Special Interest Groupがあるはずですよ。もちろん、CCPMに絞ったものではありませんが・・・。WEBをサーチすると、事例が見られると思います。 残念なことですが、失敗例は、決して報告されません。

特定の資源が、(政府の)スポンサーに、直接、サポートを提供しなければならないことがあります。特定のスポンサーをサポートするタスクは、必要なときに追加されます。しかし、これらのタスクがいつ利用されるかを予測することは困難です。また、予算超過も起こりえます。そこで質問ですが、どんなタイプのバッファが必要なのでしょうか。

多分、貴方がお話になっているのは、いわゆる、スポンサーに提供するLOE(level of effort)でしょう。これは、その性格上、プロジェクトのコストバッファでカバーすればよいことです。

LOEタスクは、チェーンの中で、大きな成果物につながる、「他のタスクのインプットになるアウトプット」を生まないタスクなので、プロジェクトのスケジュールの中に組み込んではいけません。

このページの先頭へ

新しい事業を対象としたCCPM

成長している新しい事業で、ボトルネック資源がある機械設備であって、それが、まだ、使い切られていないような状況に、クリティカルチェーンは、どのように適用されるのでしょうか。また、例えば、二台目の機械を追加するなどしてキャパシティを大きくするタイミングを決めるのに、どのように役立つでしょうか。

どうぞ、ゴールドラットの『ザ・ゴール』をお読みになってください。

このページの先頭へ

Six Sigma、TOC、そしてCCPM

人によっては、Six Sigmaは、他のテクニックと共に、TOCから生れたものであるといっています。CCPMを、Six Sigmaのプロジェクトの中で、どのように適用したら、両方のテクニックのゴールを完全に達成し、成功できるのでしょうか。

私は、Six Sigma は、品質管理の中で進化してきたものだと思います。Six Sigma は、1920年代のWalter Shewhart にまで溯れます。TOCは、確実にスループットを大きくするプロジェクトを選択させるという意味で、Six Sigma に大きな影響を与えました。Six Sigma のプロジェクトで、TOCの考え方を背景に持たないものは、「局所的なコスト削減」にとどまり、労力を空費し、無駄に費やしています。これらのプロジェクトの殆どは、ボトムライン(利益)に貢献しません。私のウエブサイトに要約されているAPIC study を参照してください。

Six Sigmaのカルチャーが強い組織にTOCやCCPMを導入、展開する場合の潜在的な良い点と悪い点を教えてください。組織としての物事の見方を変えるには、どのようなステップを取り、評価尺度をどのようなものにしたらよいでしょうか。

私は、両方には強い相乗効果があると思っています。しかし、現実を見ると、多くの組織でのSix Sigmaで、「システムというもの」を理解せず、局所的なコスト削減の罠に落ちてしまっていると思います。TOCは、システムを通して創造されるスループットに集中することを求めます。このことは、「何がスループットを制限しているか」を、先ず、重視して、識別させる「部門にまたがるプロジェクト」のみが、本当の意味のSix Sigma の成果を引き出せるものと思います。勿論、評価尺度は、スループットです。

また、悪い点は、一切、ありません。

このページの先頭へ

アジャイル・プロジェクトマネジメント

私は、ラリーさんが、ご本の中で、「ローリング・ウエーブ」による計画作成のアプローチに触れられているので、嬉しく思いました。実は、私は、自分の環境で、プロジェクトマネジメントに、このローリング・ウエーブを使っているからです。私は、「芸術家」、「想像的な人たち」に関っており、彼らは、ユニークな製品を生み出しています。これらの製品には、開発期間の標準はありません。私は、「ローリング・ウエーブ」を使うと、チームに、先に何が待ち受けているかについての情報を流し続けながら、かつ、彼らが、非現実的な、そして、究極的には不必要な計画やチャートで行き詰らせてしまうことがないようにできます。済みませんが、特定のプロジェクト、または、特定の産業でのローリング・ウエーブの例をおよび、資源飯いただけませんか。

私は、R&D プロジェクトで、この方法を使いました。これらのプロジェクトは、政府の長期プロジェクトでした。しかし、政府がお金を出すのは、会計年度ごとです。このような状況で、おおまかな目標を設定されている5年のプログラム計画はありがたいことですが、詳細なプロジェクト計画の立案は1年先までだけでした。

1年を越えたプログラムでは、全体的な長期戦略を見えるようにするために、順序付けしたマイルストーンを使いましたが、この中には、計画を見直す「意思決定ポイント」を明示しておきました。

このページの先頭へ