進捗管理 Situation：定例報告の場面 20 進捗管理 ☆「発注側の進捗管理」を本当に実効力のあるものにするためには、ベンダからどれだけ（ベンダのマネジャ ーも知らないような）現場の情報を引き出せるかにかかっている。以下のリストはそのためのヒントとなるも のである。 Situation： Situation：定例報告の 定例報告の場面 現在の 現在の進捗状況を 進捗状況をベンダに ベンダに確認する 確認する ☆「表層上の現象、表面に観察される事象から、現場で発生している問題を察知する」という意識をもって、進 捗状況を確認することが肝要である。 ☆定例報告の場面で、ベンダに対して的確な指摘をするためには、事前に報告資料に目を通しておくことが 必要である。ベンダには事前に定例会向けの資料を（メールなどで）送付してもらうように依頼しておく。（プ ロジェクトルールとして決定しておく） ■報告対象のタスクや成果物ごとに、進捗の測定方法、測定基準、完了基準を再確認する。 ▲各タスクの進捗状況を 1 週間単位で追跡できるようなスケジュール／実績値であることを確認する。 ■各タスクの進捗率を確認する。 ▲進捗が遅れているタスクはないかどうかを確認する。 ▲このままでは進捗が遅れることになりそうだ、と思われるタスクがないかどうかを確認する。 ▲計画通りに作業を着手していないタスクがないかどうかを確認する。 ※たとえ 1 日でも遅れているタスクがあれば、きちんと指摘すること。重要なのは遅れの幅ではなく、遅れて いるという事実である。 ■各タスクの進捗の計画と実績の乖離の程度を、詳細かつ具体的な数字で確認する。 ※進捗の状況は、複数のタスクの進捗のプラスマイナスを合計したサマリの情報ではなく、最小のタスク単 位で報告してもらう。 ※乖離の程度は、計画に対して何パーセント進んでいるのか、あるいは遅れているのか、といった具合に、 数値化して報告してもらう。 ♪進捗率がパーセンテージで報告されている場合 ▲工数に換算すると、何人日分遅延しているのか？を確認する。 ▲あと何日で遅れが取り戻せるのか？を確認する。 ▲あと何日で完了するのか？を確認する。 ♪アーンド・バリュー・マネジメントを実施している場合 ▲コストの消化率を確認する。 ■進捗が、きちんとそのタスクの測定基準や完了基準に則って評価・報告されていることを確認する。 △スケジュールに追われているからといって、「ほとんど終了している」タスクを「終了」にしてしまっているこ とはないか？ △基準から逸脱した報告を、ベンダのマネジャーが見逃しているようなことはないか？ www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：定例報告の場面 21 ■進捗度の定義に従っただけの、機械的な報告に陥っていないかどうかを確認する。 △ベンダのマネジャーは、下から上がってくる集計された数字を単に機械的に（棒読みして）報告しているだ けという可能性はないか？ △ベンダのマネジャーは、実際に自らが行動して、数字が集計される前の生の現場に接し、情報の信頼性 を確保しているか？ △ベンダのマネジャーは、その情報の信頼性に問題がないということを、どのような手段で確認している か？ ※情報というものは、階層を一つ通過するたびに、その内容の 4 割が失われるものである。 ■ベンダの進捗管理のマネジャーが、単に現場の報告を鵜呑みにするだけではなく、（隔週でも）現場の成果 物を確認していることを確認する。 ←現物を確認しなければ、報告に誤りがないことを保証できない。 ☆ベンダのマネジャーは、下から上がってくる情報を詳しいチェックもせずにそのまま発注側に流している可 能性もある。進捗報告は儀式ではない。目的に立ち返り、現場はどのような状況になっているか、プロジェ クトにはどのような問題の芽が隠れているか、という視点から報告内容をチェックする必要がある。基本は、 現場の生の声をヒアリングすることである。 進捗状況を 進捗状況を時系列で 時系列で把握する 把握する ☆問題の発生は、状況の時系列的な変化から察知できることが多い。先手先手でプロジェクトをマネジメント していくためには、‘傾向分析’が重要である。 ■前回（前回以前）の進捗報告からの予実の乖離状況の推移を「数字の変化から」確認する。 ※変化を客観的に把握できるように、進捗は数字で報告してもらうことが重要である。 ▲進捗が前回とほとんど変わっていないタスクはないかどうかを確認する。 ▲進捗の遅延が拡大傾向にあるタスクがないかどうかを確認する。 ■前回の進捗報告に対するこちら側の指摘事項が、今回はきちんと対応されているかどうかを確認する。 △スケジュールどおりに着手されていなかったタスクが、きちんと着手されているか？ △遅延していたタスクの遅延が回復されているか？遅延の幅が小さくなっているか？ ※次回に指摘できるように、今回指摘した事項はきちんと記録に取っておくこと。 ※言い訳は何にでもつくものである。前回と状況がほとんど変わっていない場合、理由を尋ねると色々と言 い訳をしてくるだろう。しかし発注側のスタンスとしては、（遅延の原因が発注側にある場合を除いては） その言い訳に納得してはいけない。その言い訳の理由をふまえて、次週までに打つ対策案を聞きださな ければならない。 対応の 対応の必要性についての 必要性についてのベンダ についてのベンダの ベンダの意向を 意向を確認す 確認する ♪遅延しているタスクが存在する場合 ▲現時点の進捗状況をふまえて、何らかの対応の必要性があるか？を確認する。 ▲その判断の根拠を確認する。 ♪遅延しているタスクに対して、対応の必要性がないという回答の場合 △クリティカルパスへの影響がないことは明白か？ ※クリティカルパスは固定ではないことに注意すること。それはプロジェクト期間中に状況の変化によって www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：報告が「問題なし」の場合 22 変動するものである。 △以降のタスクへの進捗への影響がないことは明白か？ △成果物の品質への影響がないことは明白か？ △要員負荷への影響が許容範囲であることは明白か？ ※派生する影響についての詳細な検証は、「進捗管理」「Situation：遅延発生の場面」「Case：「新しい」遅延 の場合」「Step4：派生する影響を検証する」（30頁）を参照のこと。 ☆タスクの遅れは、必ず次のタスクの進捗状況に伝播する。（※ただし、早く終わっても、次のタスクが早く開 始されるとは限らない） ■遅延に偏りがあるかどうか？を確認する。 △特定の担当者やチームのタスクに遅延が偏っているということはないか？ △特定のマネジャー、特定のリーダーのタスクに遅延が偏っているということはないか？ △特定の成果物に遅延が偏っているということはないか？ ※特定の担当者やチームに遅延の偏りがあるならば、早急に対策を検討する必要がある。 ♪進捗が計画より早すぎるタスクが存在する場合 ▲進捗が早すぎる原因を確認する。 △何が想定外で、計画よりも早く進んでいるのか？ △成果物の品質に問題がないか？ △要件の見落としがないか？要件の漏れはないか？ △担当者のアサインにアンマッチがないか？（不必要に高スキル高単価の担当者を割り当てていない か？） △計画に（大きな）問題がないか？ ※進捗が前倒しで進んでいれば全く問題がないというわけではない。成果物の品質も合わせて確認しなけ れば、前倒しがよいとは言えない。 Situation： Situation：報告が 報告が「問題なし 問題なし」 なし」の場合 「問題なし 問題なし」 なし」の言葉の 言葉の意味を 意味を確認する 確認する ■遅延タスクがなくて「問題なし」なのか？それとも遅延タスクがあっても「問題なし」なのか？を確認する。 ♪遅延タスクがあっても「問題なし」の場合 ▲なぜ遅延タスクがあっても「問題なし」なのか？その理由は何か？を確認する。 ☆遅延があっても、そのタスクがクリティカル・パス上にない場合は、リカバリの必要がないこともある。逆にベ ンダのマネジャーが、全ての遅延に対してがリカバリが必要と考えている場合にこそ注意が必要である。そ れはベンダがクリティカル・パスを認識していないことを意味している可能性が高い。マネジャーの力量に対 して「？」マークがつくかもしれない。 本当に 本当に「問題なし 問題なし」 なし」なのかどうかを確認 なのかどうかを確認する 確認する ■ベンダは各タスクの進捗の前倒しや遅れを合計して、進捗を「平均」で判断していないかどうかを確認する。 ※個々の進捗をサマリして、トータルとして計画通りに進んでいるからといって問題を抱えていないとはいえ ない。良い要因と悪い要因が相殺している結果としての「計画通りの進捗」かもしれない。「悪い要因がな ければ本来はもっと良い結果を出せたのではないか」という視点で報告を見ること。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：報告が「問題なし」の場合 23 ♪前倒しタスクの日数と遅延タスクの日数が合計され、トータルで考えて進捗に問題なし、という報告の場合 △遅延タスクがクリティカル・パス上のタスクということはないか？ △多数の小さな前倒しタスクで、少数の大きな遅延タスクが隠されていないか（大きく遅延しているタスクが ないか）？ △担当の代えがきかないタスク、人海戦術では対応できないタスクで遅延が生じていることはないか？ ■進捗の計測方法が単なるページ数やステップ数であり、その計測の結果だけで「問題なし」としていること はないか？を確認する。 △コピーペーストなどの作業で、「見かけ」の進捗を稼いでいることはないか？ △「頭を使う作業」や「時間がかかる調整の作業」がたっぷりと残されていることはないか？ ■成果物の品質が確保された上での進捗なのか？を確認する。 △ベンダのマネジャーは成果物の品質（記述項目、記述の深さ、内容の整合性など）にも気を配っている か？ ※進捗の数字だけが計画通りでもプロジェクトとしての意味はない。 ■「進捗に問題がない」という報告によって、結局は何が保証されることになるのか？を聞いてみる。 △以降のタスクの開始時期が保証されることになるのか？ △進行中のタスクの完了時期が保証されることになるのか？ △「進捗に問題がない」という報告によって、発注側は何に安心してもよいのか？ ※ベンダは目的を何も考えずに惰性で報告をしていないか？とりあえず「問題がない」と言っていることはな いか？ベンダの‘考えの深さ’を確認してみる。 「問題なし 問題なし」 なし」の信頼性を 信頼性を高める ■成果物の作成完了前に、その作りかけの成果物を見せてくれるようにベンダに依頼してみる。 ☆一括請負契約の場合、ベンダの作業を管理するために見せてもらうことはできないので、その場合は「安 心のため」という理由でベンダの善意で見せてもらう。ただし、本来であれば、中間成果物の確認について は、契約書の条項の中であらかじめ取り決めをしておくのがベストである。 ■問題があるのに「問題なし」と報告していることはないか？その可能性を考える。 ♪報告が虚偽と思われる場合（問題があるのに「問題なし」と報告していると思われる場合） ▲発注側は受注側に対して過度のプレッシャーをかけていないか？その可能性を考える。 ☆特にプレッシャーがかかっていない状況でも、受注側には「問題なし」と報告したい心理が働くものである。 ましてや受注側に「計画通り」に進めることのプレッシャーが強ければ強いほど、その傾向は強くなる。ただ し、プレッシャーが強くなれば問題の隠蔽が多くなり、隠蔽された問題は時間が経つとさらに解決困難な問 題に大きくなるものである。 ■ベンダは、仮に「問題あり」と報告した場合の何を恐れているか？まずはストレートに確認してみる。 ☆「問題あり」と報告した場合、発注側から「原因は何か？対策は何か？対策の根拠は何か？いつまでに対 策の効果が出るか？確証はあるのか？」といった、詳細な説明を求められることを、受注側は大いに懸念 するものである。これらの報告をするために、本来の成果物を作成するために割くべきリソースが費やされ www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 24 てしまうことを懸念する。 ☆ベンダは、あえて「問題あり」と報告するよりも、内々で処理した方が効率的であり、それが発注側のためだ と考えがちである。発注側とすれば、「問題あり」との報告に対して詳細な情報を求めるのは当然の要求で あるが、ベンダとすれば（多くの場合）それは現場の改善にはつながらない、単に「報告のための作業」に陥 ってしまう可能性が高く、非常に煩わしいと感じられるものである。 ■ベンダとどのような約束や取り決めをすれば、ベンダが正確な報告をするようになるか？を考える。 ☆本来であれば、問題が発生した場合の報告に関して、報告しなかった場合や報告が遅れた場合の罰則や 免責事項などについて、契約書の条項の中で取り決めをしておくのがベストである。 ☆「問題あり」と報告した場合に発注側から寄せられるであろう様々な要求を恐れて、ベンダがあえて情報を 出さないことについて、心情的には理解できないことはない。しかしもちろん、「だからベンダに任せておい てよい」「問題を隠しておいてもよい」ということにはならない。ベンダが内々で処理するにしても、そして、発 注側が詳細を知らないでいるにしても、当のベンダ自身は、原因も、対策も、その根拠も、いずれもしっかり と検討しなければならないことに変わりはない。発注側に状況を報告するかしないかはともかくとして、ベン ダのチーム内部でしっかりとした検討が必要であることに変わりはない。しかし、発注側の監視がないと、こ の作業がおざなりになってしまう可能性が高い。発注側とすれば、（報告書の作成などの）形式的な作業を ベンダに課して余計なリソースを費やさせることがないように注意しながら、実質的な調査活動と報告を求 めるべきである。 ♪ベンダの報告が疑わしい場合 ▲まずは報告の矛盾点を徹底的に探す。 ☆ベンダの報告が疑わしい場合、本当ならば発注側が自ら現場の担当者にヒアリングして、実態を確かめた いところである。もちろん請負契約であれば、ベンダ内部の現場の担当者に接触することはできない。しか し、具体的な事例や、事実に基づいた根拠があれば、ベンダに強く要求する際の十分な武器となる。仮に 発注側が自らヒアリングすることができなくても、たとえベンダのマネジャー経由でも、信頼性のあるヒアリン グを実施してもらうことができる。そのヒアリング結果の全てを教えてもらうことができなくても、ベンダは内 部で相応の対策を講じる可能性は高い。 ■相手に何を質問すれば、（少なくとも次回の報告からは）信頼性の高い進捗情報を得られるかどうかを考え る。 ☆測定基準や完了基準に則った報告はあくまでも基本中の基本にすぎない。それは報告における十分条件 ではない。報告を受ける側としては、ベンダの報告を漫然と受けるだけ、あるいは形式的な確認だけに終わ ってはいけない。重要なのは、表面上の数字だけからは読み取れない、本当の進捗度合を知ることであ る。 Situation： Situation：遅延発生の 遅延発生の場面 ■ベンダが報告している遅延要因に疑問を感じたときは、週次で更新する課題管理表や、現場で何が起きて いるのかを把握・分析できるような状況報告書を提出してもらう。 ※忘れずに契約書にレビュー権や監査権を謳っておくこと。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 25 ■遅延が生じているにもかかわらず、理由の説明やリカバリの目処の説明など、ベンダからその件について のコメントが一切ないタスクについては、逐一遅延原因についての確認を入れる。 ※発注側は細かすぎるくらいに細かくチェックをしていくべきである。流してはいけない。 ■発注側の協力が必要なタスクについては、ベンダは発注側をきちんと‘急かして’いるか？を顧みてみる。 ☆発注側が原因となって進捗の遅延が発生することは少なくない。発注側が何らかの約束の期限に遅れて、 その結果、プロジェクトの進捗が遅れてしまうようなことはよくある。このようなとき、遠慮して発注側を急か してこないベンダには要注意である。ベンダは「まだ間に合うので急かす必要はなかった」との言い訳をす るかもしれないが、要注意であることに変わりはない。発注側責任の作業に遅れが生じた場合、それをきち んと指摘してくるベンダでなければ発注側としては安心してはいけない。指摘してこないベンダであれば、 指摘することの重要性を説明し、きちんと指摘するように要請すべきである。 「新しい」 しい」遅延か 遅延か「古い」遅延かを 遅延かを判断 かを判断する 判断する ベンダから遅延が報告されてきた場合、それが新しい遅延の発生の報告か、それとも以前から発生している が、まだ解消されていない遅延の報告かによって、発注側の対応は異なってくる。 Case：「 Case：「新 ：「新しい」 しい」遅延の 遅延の場合 Step1： Step1：ベンダの ベンダの報告の 報告の信頼性を 信頼性を確認する 確認する ■遅延の原因については、発注側から問い質すことなく、ベンダが自ら進んで報告しているか？を振り返って 考えてみる。 △発注側からの質問を待つことなく、遅延の原因と対策および回復の見通しを報告してくるか？ ☆発注側から質問しないと遅延の原因を説明してこないようでは、ベンダの姿勢として困ったものである。「要 注意」のベンダと言ってもよいだろう。聞かなくても自ら報告するように依頼しておくべきである。 ■報告は正確には何月何日時点での進捗を表しているのか？を確認する。 △現実には、現時点では報告よりも遅延が拡大している可能性はないか？ ☆報告は何日前の現場の進捗状況を表しているのかを確認すること。情報が取得された日時と報告日時と の乖離が大きければ、当然そこに差異が発生する可能性も高くなる。ベンダが「3 日遅延です」と報告して きたからといって、それが現在の状況とは限らない。 ■遅延は、いつ誰によって初めて認識されたのか？を確認する。 △当のタスクの担当者が遅延を認識したのはいつか？ △チームリーダーが遅延を認識したのはいつか？ △マネジャーが遅延を認識したのはいつか？ ■報告内容は、下記が明確になっているかどうかを確認する。 △誰が誰から取得した情報か？ △いつ取得した情報か？ △どのような手段・手法で取得した情報か？ ■ベンダのマネジャーは、部下からの報告の信頼性を自分の目で確かめているか？を確認する。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 26 ■ベンダのマネジャーは、部下が上司に報告を上げる際の、個人の性向を理解しているか？ ◇報告を上げる際の個人の性向の例 ・大袈裟に報告しがちである ・控えめに報告しがちである ・詳細を省略して報告しがちである ・「問題なし」として報告しがちである など ☆楽観的な報告をするか。悲観的な報告をするか。報告のニュアンスは担当者の性格によって異なる。正確 な報告をするか。それとも大げさな報告をするか。これも人によって違ってくる。定量的な状況の把握が難し いタスクでは、こういった個人の性向を原因とする情報の信頼性の低下は（多かれ少なかれ）避けられない。 マネジャーは担当者の「報告の傾向」を把握しておき、各担当者の報告を「割り引いて」判断する必要があ る。 ■報告スパンと遅延日数の間に矛盾はないかどうかを確認する。 ※例えば、報告スパンが 1 週間単位なのに、急に 5 日遅延などという報告になっていないかを確認する。これ まで遅延の報告のなかったタスクが急に 5 日の遅延になったということは、この 1 週間は何も作業をしてい なかったことになる。報告スパンと遅延日数の関係は常に注視しておく。 Step2： Step2：ベンダに ベンダに遅延の 遅延の原因を 原因を確認する 確認する 遅延の 遅延の原因を 原因を確認する 確認する ☆事務処理の遅れや物の製造の遅れは、遅延箇所も遅延原因も追究は比較的容易である。しかしソフトウェ ア開発の遅れの場合、それは容易ではない。ましてや、請負契約で社外の協力者に頼っている場合などは、 さらにその把握は困難になる。現状を正確に把握するためには、発注側に相応の折衝能力が求められてく ることになる。 ☆遅延が発生すること自体に大きな問題はない。むしろそれがプロジェクトの通常の姿である。全てのタスク について「遅延なし」との報告が続くようであれば、むしろ別の懸念が出てくる。報告の信頼性自体にも疑問 が出てくるし、報告が正しいのであれば、「甘すぎる見積」という問題を検証しなければならなくなる。したが って、遅延の発生自体に神経質になりすぎる必要はない。しかし一旦発生した遅延に対して、その検証もせ ず対策も講じず、その対応に失敗すると、最初は小さかった問題もやがてプロジェクトレベルの大きな問題 に成長してしまうことにもなりかねない。遅延自体に大騒ぎする必要はないが、その後の対応姿勢と実際の 対応状況については、発注側は神経質に‘監視’していく必要がある。ここの対応を誤ると、プロジェクトは 延々と進捗遅延の問題に悩まされることになりかねない。 ■遅延の‘直接の原因’は何か？を確認する。 ☆遅延が発生した場合、ベンダのマネジャーによっては対策を提示するだけで、詳細な原因までは報告しな い場合がある。しかし発注側の管理スタンスとして、「対策を打って遅延が回復するならそれでよい」という 考え方では不足である。遅延の原因を放置しておくということは、再発の可能性を放置しておくことにつなが る。遅延の原因までしっかりと確認し、その対策が講じられているところまで確認すべきである。遅延が生じ るたびに、もぐらたたきをしているようでは、それはリソースの浪費につながり、ひいては必要なタスクに必 要な時間をかけることができなくなってしまう。 ■遅延の‘根本の原因’は何か？を確認する。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 27 ▲それが‘根本の原因’であることは、何を根拠にそう言えるのか？を確認する。 ▲それが‘根本の原因’である場合、同じ状況にある他のタスクも同様に遅延しているか？を確認する。 ※問題がただ一つの原因だけで生じることはまずない。表層的な原因だけでなく、本質的な原因まで深堀 してもらい、その原因間のつながりまで提示してもらうこと。 ※「課題管理」「Situation：解決策策定の場面」「Step3：ベンダによる原因分析を分析する」「ロジックを検証 する」（82頁）を参照のこと。 ■遅延の‘質’を確認する。 △量的な作業が遅れているのか？すなわち人海戦術で対応可能なタスクが遅れているのか？ △質的な作業が遅れているのか？すなわち人海戦術では対応できないタスクが遅れているのか？ ■‘現場の作業’以外のところで遅延が発生しているのか？を確認する。 △しなければならない承認がなされていないのか？ △しなければならない決定がなされていないのか？ △しなければならない調査がなされていないのか？ △しなければならない分析がなされていないのか？ △しなければならない折衝がなされていないのか？ △しなければならない根回しがなされていないのか？ ■遅延には、ベンダがあげる原因以外の原因は存在しないか？を確認する。 ▲遅延の原因と想定される事柄について、自らのこれまでの経験を振り返って、「～といった原因ではない か？」などと、‘突っ込んで’質問していく。 ■発注側が遅延の原因になっていることはないか？を確認する。 ※発注側の承認遅れや確認遅れ、決定遅れが遠因となって遅延が発生することも多い。それを指摘してこ ないベンダもいるが、その上にあぐらをかいてはいけない。発注側も自ら遅延を防止するための「努力」 をしなければならない。 ※発注側の承認遅れや確認遅れ、決定遅れの背景には、解決がなかなか難しい政治的な問題が絡んで いることが少なくない。 ■（過去のプロジェクトなど）これまでの経験上、同じような原因で遅延が発生したことはないか？を確認す る。 △その時は、どのような理由から、どのような対策を打ったか？ △その効果はあったか？ ■ベンダを PUSH してもなかなか原因が出てこない場合は、下記リストなどをヒントに、発注側から引き出して いく。 ※ただし、下記は一般論であり、ベンダに原因分析を実施してもらうための最初のとっかかりにすぎない。 ベンダから回答をもらったら、更に‘突っ込んだ’質問をしていくこと。 ◇‘突っ込んだ’質問の例 ・「力作業のボリュームが想定外に多かったということはありませんか？」 ◎遅延発生の原因の例 遅延発生の原因 タスク内部要因 www.motozono.com 量的原因 ・力作業のボリュームが想定外に多かった ・リソース確保が遅れて作業の開始が遅れた (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 28 タスク外部要因 質的原因 ・作業の難易度に比べて担当者のスキルが低かった ・キーマンが突然離任した ・必要作業の見落としがあった ・担当者のモチベーションに問題があった 品質要因 ・品質基準が変動した ・インプット（前工程）の成果物（情報）の品質が低かった ・各種コミュニケーションの品質が低かった 計画の不備 ・納期から逆算されたスケジュール 待ち状態の発生 ・各種意思決定が遅い ・関連部門との折衝がうまくいかない ・各種承認や決定が遅い ・インプットとなる外部連携タスク、外部成果物が遅延した 想定外作業の発生 ・スコープが拡大した ・スコープの認識の齟齬が発覚した ・スコープの漏れが発覚した 作業時間の縮小 ・頻繁に割り込み作業が発生した ・各種報告作業のオーバーヘッドが大きかった 進捗管理計画と 進捗管理計画と現実の 現実の実施状況乖離を 実施状況乖離を確認する 確認する ■ベンダが作成した進捗管理計画を見直す。 ※計画書は、ベンダから渡された時点では、発注側は（必要とはわかっていても）なかなかしっかりと読み 込むことはしない。イメージが掴めないからである。しかし、実際にプロジェクトが開始されると、計画書に 書かれている内容が具体性を伴って理解・確認できるようになる。計画書の不備や記述が不足している 点、実際のプロジェクトでできている点やできていない点が明確にわかるようになる。 ※進捗管理計画は【計画編】の内容となる。本マニュアル【実践編】では取り扱わない。 ■進捗管理計画通りに管理活動が実施されているか？を確認する。 ▲計画通りに実施されていない管理活動を洗い出す。 ※何が実施されて、何が実施されていないのか、詳細にチェックすること。 ☆計画通りに実施されていればよい、というわけではない。計画通りに実施されていなければ悪い、というわ けではない。計画が事実にそぐわないものであることは、実際にプロジェクトを運営して初めて判明するも のである。ただし、計画に対してどのような判断（変更するか／順守していくか）を下すにしても、まずは現 場が計画通りに活動しているかどうかを確認しなければならない。計画通りにプロジェクトを回しているかど うかさえ明らかでなければ、計画の良し悪しや変更の必要性も判断できない。 ■進捗管理活動が計画通りに実施されていたとしたら、今回の遅延は生じなかったと思われるか？について 考える。 △遅延の原因は、進捗管理計画の不備にあると思われるか？計画の不備か？ △遅延の原因は、進捗管理計画の実施にあると思われるか？実施の問題か？ ▲次プロジェクトの進捗管理計画へのフィードバック方法を考える。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 29 Step3： Step3：ベンダの ベンダの原因分析を 原因分析を検証する 検証する ベンダから遅延の原因を説明されて素直に頷いてはいけない。その原因の説明が正しいかどうかは別問題 である。ベンダから報告されてくる遅延の原因は、多くの場合、それは推測でしかない。 ロジックを ロジックを検証する 検証する 「課題管理」「Situation：解決策策定の場面」「Step3：ベンダの原因分析を分析する」「ロジックを検証する」（82 頁）を参照のこと。 精度を 精度を検証する 検証する 「課題管理」「Situation：解決策策定の場面」「Step3：ベンダの原因分析を分析する」「精度を検証する」（83頁） を参照のこと。 漏れを発見 れを発見する 発見する 「課題管理」「Situation：解決策策定の場面」「Step3：ベンダの原因分析を分析する」「漏れを発見する」（84頁） を参照のこと。 見積ミス 見積ミスを ミスを検証する 検証する ☆先に予定していた作業を前倒しに実施したために発生する遅延もある。例えば、概要設計を行っているとき に、詳細設計の領域まで踏み込む必要が生じることがある。しかし「ここは詳細設計の領域だから」と画一 的に判断して、そのまま概要設計を進めてしまうのは（判断の仕方として）よくない。そもそもプロジェクトと いうものは「概要から詳細へ」といった具合に、きれいに計画通りに進むものではない。大抵の場合は、概 要部分と詳細部分を行き来しつつ完成に向かうものである。その時点でなすべき作業はその時点で行うべ きであり、ここでフェーズの区切りに縛られてはいけない。ベンダのマネジャーがきちんと現場の状況を把 握して、臨機応変に対応するタイプであれば心配はないが、計画からの乖離を画一的に「悪」と考えるタイ プの場合は、発注側としては要注意である。 ■見積ミスの可能性を考えてみる。 △（小さな原因はあるものの）遅延の最大の原因は見積のミスであったということはないか？ ＜見積ミスが原因の場合＞ ■見積ミスは、どの領域の見積ミスか？を特定する。 △作業ボリュームの見積ミスか？ △担当者の生産性の見積ミスか？ △間接作業や割り込み作業の見積ミスか？ ■見積ミスの原因は何か？を検証する。 ☆作業ボリュームの見積は非常に難しい作業である。作業ボリュームの見積が誤っていた場合は、軽々にそ の原因を特定することはできない。様々な要素が複雑に絡み合う領域であり、発注側が深くベンダに切り込 んでいったとしても、今後のプロジェクトに遂行に役立つ情報が得られる保証はない。とは言っても、「どのく らい詳細に見積ミスを分析しているか」という、ベンダの「プロジェクトに臨む姿勢」を判断する有用な情報に www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 30 はなる。参考書に載っているような一般的な原因ではなく、プロジェクト特有の具体的な原因を挙げている ならば、「他の活動」でも「真面目」に行っていると見てよいだろう。 ☆見積ミスの原因について、ベンダが一般的な原因の説明で済ませてしまうようならば、そしてそれを発注側 が受け入れてしまうならば、今後あらゆる報告の場面で、「似たような」対応をされることになる。 ☆担当者のスキルや生産性、あるいは間接作業や割り込み作業を原因とする見積ミスであれば、これらにつ いては、「なぜ見積ミスが発生したのか」について、ベンダに鋭く切り込んでいく価値はある。これらは作業 ボリュームの見積とは違って、事前の調査や計画によって、ある程度は正確に見積もることが可能なもので ある。 ■（当該のタスク以外の）他のタスクについても、同様の見積ミスによって遅延が発生する可能性はないか？ を確認する。 ♪発生の可能性がないという場合 ▲その理由・根拠を明確にする。 前述の「作業ボリュームが誤っていた場合は、軽々にその原因に言及することはできない」とは若干矛盾した 内容になるが、下記もまた真実である。本書では、「使いやすい」マニュアルのように白黒を明確にはできない が、自身のこれまでの経験などを踏まえ、感覚としてその矛盾と「折り合い」をつけていっていただきたい。プ ロジェクト管理に唯一の正解はありませんので。 ☆遅延の原因として、見積ミスをベンダが挙げてきた場合、発注側の基本的な姿勢としては、安易にそれを認 めるべきではない。本当の原因は見積ミスなどではなく、「防止策の検討が可能な」真の原因があるかもし れないからである。それにもかかわらず、原因が見積ミスということになってしまうと、それ以上真の原因を 追究することができなくなってしまう。「タイムマシンを使って再度見積をやり直すことなどできないから、再 発防止策などは立てられない」ということになってしまう。そうなると、「防止策を検討しようとする動き」も不 要のものとなってしまう。見積ミスが原因になってしまうと、検討可能な防止策はせいぜい「見積精度の向 上」くらいのものである。それは別プロジェクトへの応用がきくベンダにとっては意味があっても、今回のプロ ジェクトが重要な発注側にとっては意味がない。 ☆遅延の原因を見積ミスということにすると、対応のためのベンダの負荷は軽くなる。しかしこれがベンダにと っての楽な逃げ道になってはいけない。怠け者のベンダであれば、ことあるごとに「見積ミス」で済まそうと するかもしれない。見積ミスであれば、深く原因を追究されないからである。したがって発注側のスタンスと しては、見積ミスに対しては厳しい態度で臨まなければならない。見積ミスの原因として、ベンダの「時間が なかった」「情報が少なかった」という安易な言い訳を許してはいけない。これを許すと怠け者のベンダは、 真の原因分析のために時間を割くことをやめ、再び「見積ミス」という手を使ってくる。 ☆仮に、本当に遅延原因が見積ミスにある場合でも、「見積ミスの原因追究に厳しく臨む」という姿勢は当然 ながら崩してはいけない。プロジェクトが「本格稼働」に入ってからこのような問題が生じると、「なぜ今さら 見積ミスの原因追究をやらなければならないのか」という声も上がってくるだろう。「昔のことをほじくり返して も、これからがよくなるわけではないだろう」「そんな原因分析よりも、これからのことを考えた方がよほど有 益だろう」という声である。 Step4： Step4：派生する 派生する影響 する影響を 影響を検証する 検証する 別タスクに タスクに遅延が 遅延が発生する 発生する可 する可能性を 能性を検証する 検証する www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 31 遅延の 遅延の玉突きによる 玉突きによる影響 きによる影響を 影響を検証する 検証する ■クリティカル・パスは明らかにしているか？この遅延はマスタースケジュールに影響するか？を確認する。 ※遅延タスクとマスタースケジュールの関係をベンダに示してもらうこと。そのタスクがクリティカル・パス上 にあるタスクであれば、既にマスタースケジュールは遅延していることになる。 ♪「影響ない」との回答の場合 △影響がないという根拠は何か？ △この遅延がマスタースケジュールに影響するまで、どれだけのバッファが残されているか？ ※マスタースケジュールの遅延につながらないという回答であれば、その根拠を確認する必要がある。まず はそのタスクがクリティカル・パス上にないことが条件である。「リカバリするから影響はない」という理由 は、そのリカバリプランがよほどしっかりしたものでない限りは根拠とはならない。 ♪「クリティカル・パスへの影響がある」との回答の場合 △本タスクの完了前に、後続のクリティカル・パス上のタスクを開始することはできないか？ ※依存関係があるタスクにおいて、前のタスクが完了する前に後のタスクに着手することは、手戻りのリス クを冒すことになる。しかしそのリスクよりも、スケジュールに遅延するリスクの方が大きい場合は、「見切 り発車」することも重要である。 ※「進捗管理」「Situation：遅延発生の場面」「Case：「新しい」遅延の場合」「Step4：派生する影響を検証す る」「「見切り」の可能性を検討する」（33頁）を参照のこと。 ■この遅延によって影響を受けるかもしれないタスクを洗い出しているか？を確認する。 △遅延タスクの成果物をインプットとして必要とするタスクを洗い出しているか？ △遅延タスクの成果物をインプットとして必要とするタスクは、どのようなスケジュールになっているか？ ▲楽観的／悲観的の双方の見方と、それを左右する不確定項目を挙げてもらう。 ※遅延の影響を考えるためには、まずはそのタスクでどのような成果物を生み出すのか、そのタスクでどの ような価値を生み出すのか、を考える必要がある。そして、いつ、誰のために、どのような目的で、その成 果物を生み出すのかを考えなければならない。 ■遅延の影響の検証にあたっては、複数のステークホルダーの意見を収集しているか？ ※遅延の影響は一人で考えるだけでは漏れが生じる可能性が極めて高い。そのタスクのアウトプットを利 用する後続タスクの担当者や、関連するステークホルダーの立場で考えることが必要である。当然、その ステークホルダーの意見や見解を直接確認する必要がある。彼らはいつ、何のために、何が必要なのだ ろうか。それは予定していたインプットが多少遅れても問題ないものなのだろうか。ステークホルダーの 見解次第では、大きな問題に発展する可能性もある。 ■遅延タスクと、その遅延の影響を受けるかもしれないタスクの関係を明らかにする。 ※バーチャートやネットワーク図などで、遅延の影響を「なぜ、どのように、影響するのか」ベンダに説明して もらう。 ■遅延の影響を受けるかもしれないタスクの担当者、及び関連するステークホルダーと、遅延の状況や原因 について、情報を共有しているか？を確認する。 △そのタスクに関連するステークホルダー（発注側／ベンダ側）を洗い出しているか？ △そのタスクに関連するステークホルダー（発注側／ベンダ側）と、遅延情報を共有しているか？ △そのタスクに関連するステークホルダー（発注側／ベンダ側）と、対応の必要性やその具体策について話 し合っているか？ ※「共有している」という回答だけで済ませるのではなく、場合によっては、「いつ」「誰と」「どのような内容 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 32 を」共有したのかまで、詳細に確認することが求められる。 ■この遅延によって影響を受けるかもしれないマイルストンを洗い出しているか？を確認する。 ※マイルストンの多くは、発注側の確認作業や承認作業とリンクしているはずである。発注側の作業に関わ るようなマイルストンへの影響を明確にしておいてもらうこと。 ※「この遅延による別のタスクの遅延」など、間接的な影響も考慮に入れること。 同一原因による 同一原因による他 による他のタスクへの タスクへの影響 への影響を 影響を検証する 検証する ■（Step2 及び Step3 で特定した）遅延の原因は、別のタスクへの影響はないものか？を確認する。 △遅延原因は、別のタスクの遅延原因にもなる可能性はないか？ ※（マスタースケジュールへの影響の場合とは異なり）「別のタスクが遅延する可能性がない」ということを ベンダに証明してもらう必要はない。その証明は非常に困難であり、無理に依頼することはベンダに過剰 な負荷を与えることになる。 ＜その原因によって別のタスクでも遅延が発生する可能性がある場合＞ ■どのタスクでどの程度の遅延が発生する可能性があるか？を確認する。 ▲原因と別タスクの遅延の関係をベンダに示してもらう。なぜ、どのように影響するのかを明らかにしても らう。 ▲楽観的／悲観的の双方の見方と、それを左右する不確定項目を挙げてもらう。 ■マスタースケジュールへの影響はどのくらいか？を確認する。 ▲原因とマスタースケジュールの関係をベンダに示してもらう。なぜ、どのように影響するのかを明らか にしてもらう。 ■遅延が発生する可能性があるタスクに関連するステークホルダー（発注側／ベンダ側）を洗い出している か？を確認する。 ▲洗い出していない場合は早急に洗い出してもらい、情報の共有を依頼する。 ■遅延の影響が考えられるステークホルダーと、どのような調整が必要になるのか、見通しは立っている か？を確認する。 ※調整・・・苦情、疑問、問題点、検討事項、要合意事項、要報告事項、などの洗い出し、および今後の 方針の検討など ※見通しは、楽観的／悲観的の両方を確認する。 △そのステークホルダーとは、実際に調整に入っているか？ Step2、Step3 の原因分析は再発防止策の策定に役立つだけではない。他のタスクの「まだ顕在化していない 遅延リスク」に気づかせてくれる可能性がある。例えば、遅延の原因が見積ミスにある場合、他のタスクでも 同様の遅延が発生する可能性は極めて高くなる。特定の要員のスキルに原因がある場合、当然ながらその 要員の担当予定のタスクは要監視タスクになる。 遅延以外の 遅延以外の影響が 影響が発生する 発生する可能性 する可能性を 可能性を検証する 検証する ■この遅延が成果物の品質に影響する可能性はないか？を確認する。 ※楽観的／悲観的の双方の見方と、それを左右する不確定項目を挙げてもらうこと。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 33 ♪「影響ない」という回答の場合 △この遅延が品質に影響しない根拠は何か？ △様々な予定外の会議などが発生して、担当者やマネジャーの実作業の時間が今まで以上に割かれるの ではないか？ △担当者の負荷が高まるのであれば、品質への影響も出るのではないか？ △マネジャーの負荷が高まるのであれば、管理業務への影響も出るのではないか？ ※遅延回復のプレッシャーがかけられた担当者は、どうしても時間不足に陥った場合や、残業続きで疲労 困憊になった場合は、品質確保に必要な作業を省略してしまうかもしれない。無意識にでも品質作業を 飛ばしてしまったり、表面的な対応になってしまったりしてしまうかもしれない。これらはなかなか防ぎにく い問題である。ベンダの回答が「影響ない」というものならば、こうした潜在的なリスクに対して、どのよう な対応策を講じているのかを確認しなければならない。 ■この遅延を引き金として品質問題が発生することを防止するための、何らかの策は検討しているか？を確 認する。 ■この遅延を引き金として、ベンダから追加コストの要求が発生する可能性はないか？を確認する。 ※請負契約であっても追加費用を要求してくるベンダは普通に存在している。はじめに釘を刺しておく必要 がある。 「見切り 見切り」の可能性を 能性を検討する 検討する あるタスクが遅延している場合、そしてその遅延によってプロジェクトが大きなリスクに晒される可能性がある 場合、本来は依存関係にあり、そのタスクの完了を待たなければ開始できない後続のタスクを、「見切り発車」 で開始することも検討しなければならない。 経営陣の時間を確保するのは大変である。‘常務会’など、一旦確保したスケジュールを延期にすると、次は 「一週間後」ではなく「一ヵ月後」になってしまう。遅延には許される遅延と、許されない遅延があることを意識し ておくべきである。「許されない遅延」が生じそうになった場合は、「見切り発車」は重要な選択肢となる。 ■「見切り発車」の可能性やその影響について、ベンダに確認する。 △「見切り発車」ができるのであれば、なぜ最初から並列タスクにしていなかったのか？ ■「見切り発車」をした場合のリスクと、しなかった場合のリスクを明確にする。 ◇明らかにするリスクの例 ・マスタースケジュールが遅延するリスク ・各種マイルストンが達成できないリスク ・承認や決定など、時間がかかるタスクが先延ばしにされるリスク ■「見切る」可能性のある部分について、その詳細な調査をベンダに依頼する。 △その部分は、何を作成・調査・調整する作業か？ △その部分のアウトプットは、後工程のどの作業のインプットになるものか？ △その部分のアウトプットは、何人の担当者の作業のインプットになるものか？その部分のアウトプットに は何人の利用者がいるのか？ ※あまりにそのアウトプットの利用者が多い場合、仮に手戻りが発生したときの影響が大きくなるので注 意が必要である。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 34 Step5： Step5：解決策の 解決策の方向性を 方向性を共有する 共有する 「課題管理」「Situation：解決策策定の場面」「Step2：解決策の方向性を明確にする」（76頁）を参照のこと。 Step6： Step6：ベンダの ベンダの再発防止策を 再発防止策を検証する 検証する 再発防止策を策定する際のインプットとなる情報が「遅延原因」である。その原因を取り除くことで、同じ原因 をきっかけとして今後同様の遅延が発生することを防止する。この、原因を取り除く策が再発防止策となる。 ■ベンダは下記の作業をきっちりとこなしているか？を確認する。 ・「進捗管理」「Situation：遅延発生の場面」「Case：「新しい」遅延の場合」「Step2：ベンダに遅延の原因を確 認する」（26頁） ・「進捗管理」「Situation：遅延発生の場面」「Case：「新しい」遅延の場合」「Step3：ベンダの原因分析を検証 する」（29頁） ☆原因分析は再発防止策を策定するための重要な作業である。原因の分析に誤りがあれば、当然そこから 導かれる再発防止策も誤ったものになる。その重要な作業が上記 2 つのステップである。ベンダに再発防 止策の策定を要請する際には、まずはその前に、Step2 と Step3 の作業をベンダがきっちりとこなしている かを確認する必要がある。 ☆発注者の立場として、この原因分析の作業をベンダに 100 パーセント任せてしまうのはよくない。ベンダの 原因分析を発注側が分析（レビュ）するのはもちろんであるが、できれば発注者自身も独自に原因を分析し、 それをベンダの分析と突き合わせてみる、といった活動をしていくべきである。そこに認識の差異があれば、 さらなる意見交換や分析が必要になる。このダブルチェックによって、原因分析の信頼性は高まっていく。 それはもちろん、再発防止策の品質の向上にもつながる。 ■ベンダが提示する再発防止策の有効性に問題や懸念はないか？を確認する。 ※「課題管理」「Situation：解決策策定の場面」「Step4：解決策の有効性を確認する」（88頁）を参照のこと。 ■ベンダが提示する再発防止策の実行可能性に問題や懸念はないか？を確認する。 ※「課題管理」「Situation：解決策策定の場面」「Step5：解決策の実行可能性を確認する」（93頁）を参照の こと。 ■ベンダが提示する再発防止策の実行計画に問題や懸念はないか？を確認する。 ※「課題管理」「Situation：解決策策定の場面」「Step6：解決策の実行計画を検証する」（95頁）を参照のこ と。 Step7： Step7：ベンダの ベンダの遅延回復策を 遅延回復策を検証する 検証する 一般的な 一般的な検証項目 遅延回復策を 遅延回復策を策定していることを 策定していることを確認 していることを確認する 確認する ■ベンダには、遅延回復策を策定する意図はあるか？を確認する。 ☆単にスケジュール表に則って計画と実態の乖離を把握することだけが進捗管理ではない。進捗状況を確認 することと、判明した遅れを取り戻せることとは全く別のことである。当たり前であるが、実情を把握するだ www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 35 けで進捗通りにプロジェクトが進むわけではない。遅延の実態の把握と、原因の調査と、対策の立案と、対 策の実行は、それぞれ個別に実施し、その実施を管理していくべきものである。単に進捗を確認して、遅延 が見つかれば叱咤激励するだけが進捗管理ではない。 ■ベンダは遅延回復策と再発防止策の違いを区別しているか？を確認する。 ☆遅延の原因に手を打ったとしても、それは再発防止策でしかない。あるいは更なる遅延の拡大を防ぐだけ である。再発防止策を打てば、確かに同じ原因から発生する遅延は防止できるかもしれないが、これだけ では、既に遅延してしまったタスクの進捗を回復させることはできない。既に遅延してしまった進捗を回復す るには、そのための別の策が必要である。ところが、遅延が発生した場合、ベンダから出てくる解決策は、 大抵は一つである。遅延という問題に対しては、ベンダは再発防止策と遅延回復策の 2 つの解決策を示さ なければならない。 ■ベンダが提示しているのは再発防止策か、遅延回復策か？を確認する。 ※ベンダが提示してくる解決策に対しては、それが再発防止策なのか、遅延回復策なのか、それとも両方 の効果をもったものなのかを、確認しなければならない。 ☆ベンダが提示してきた解決策に対しては、まずはそれが単なる再発防止策ではないことを確認する。そこに 現在遅延している進捗を回復させるロジックが存在することを確認する。例えばベンダから「連絡の徹底」と いった策が提示されてくることがある。しかしこれは再発防止策であり、遅延している進捗を回復させるため の策ではない。回復策とは例えば「スキルのある要員と交代する」といったものである。すでに遅れが出て いる進捗を、回復させるものでなければならない。 ■ベンダは複数の遅延回復策を策定しているか？ ※策というものは、ある意味で「それを打てば問題が解決するはずだ」という仮説にすぎない。リソースが限 られている中では、事実確認を 100 パーセント実施してから、その事実に基づいて策を打っていくことは できない。だからこそ、策を打っても効果が出ないことがある。だからこそ、複数の策が必要なのである。 ▲複数の遅延回復策について、それぞれのメリットとデメリット、有効性の確実性の違いなどを明確に説明 してもらう。 遅延回復策の 遅延回復策の有効性を 有効性を確認する 確認する ■遅延回復策はクリティカル・パスを意識しているか？を確認する。 ※遅延回復策は、そのタスクの遅延だけが回復できればよいという問題ではない。他のタスクに波及した 遅延によってクリティカル・パスに影響が出ることがないかどうかを確認すること。 ■その遅延回復策によって、遅延はいつまでに回復できるのか？を確認する。 △その時期までの回復で問題はないか？その理由は何か？ △その時期までの回復ができないと、どのような問題が生じるか？ ■遅延回復策は具体的か？抽象的であることはないか？ △誰が音頭を取って遅延回復策を進めるのか？ △誰がいつ、実際にどのようなアクションを取ることになるのか？ △何について誰のどのような協力が必要になるのか？ ※実際にプロジェクトが始まってから打たれる数々の施策は、非常に具体的であることが求められる。次に 打つアクションが具体的にイメージできるものでなければならない。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 36 ■遅延回復策の実施経過や結果の状況を定量的に測定することは可能か？を確認する。 ※例えば「担当者が 2 時間の残業を 2 週間続けることによって遅延を回復する」といった具体的な説明が必 要である。 ■遅延回復策の「数字」の根拠を確認する。 ※例えば、なぜ「担当者が 2 時間の残業を 2 週間続ける」と遅延が回復されるのかを確認する。事実となる 数字の根拠が出せないのであれば、「担当者の生の声」でもよい。要は策の信頼性を確認できればよい。 100 パーセントの信頼性を求める必要はないが（※そもそも 100 パーセントの信頼性を求めることは無理 である）、そこに説得力のあるロジックは必要である。 ■その遅延回復策によって遅延が回復するロジックおよびその根拠を説明してもらう。 ■ベンダが提示する遅延回復策の有効性に問題や懸念はないか？を確認する。 ※「課題管理」「Situation：解決策策定の場面」「Step4：解決策の有効性を確認する」（88頁）を参照のこと。 ■ベンダが提示する遅延回復策の実行可能性に問題や懸念はないか？を確認する。 ※「課題管理」「Situation：解決策策定の場面」「Step5：解決策の実行可能性を確認する」（93頁）を参照の こと。 ■ベンダが提示する遅延回復策の実行計画に問題や懸念はないか？を確認する。 ※「課題管理」「Situation：解決策策定の場面」「Step6：解決策の実行計画を検証する」（95頁）を参照のこ と。 ■その遅延回復策はプロジェクトにとって必要な策か？を考えてみる。 ※例えば、クリティカル・パスに影響しないタスクの遅延回復に投資するのは無駄な投資である可能性があ る。もともとの期限の設定が誤っていたタスクの遅延、すなわち遅延しても、どのタスクにもどのマイルス トンにも影響しないものならば、わざわざコストをかけて回復策を打つ必要性は小さい。 間違った 間違った遅延回復策 った遅延回復策の 遅延回復策の方向性を 方向性を正す ■ベンダのマネジャーはメンバーを無闇に急かしたりはしていないか？を確認する。 ☆システム開発においてリソースの裏づけもなく無闇にメンバーを急がせることは、「必要な作業を省略させ る」ことにつながる。隠れて、作業の手抜きをさせることにつながる。システム開発は知的活動であり、急い だからといって早く完成するものではない。その反面、‘急いだ結果’だけはしっかりと製品に影響を及ぼす。 品質を犠牲にしてでも進捗を厳守しようとしたり、ギリギリまで遅れを隠そうとしたりするインセンティブが働 く。 ■ベンダが‘聞き慣れない’策を打とうとしていることはないか？を確認する。 ☆遅延回復に本当に効く抜本的な対策は「誰でも知っている当たり前のもの」以外にはない。すなわち実際問 題として、遅延を取り戻す真に有効な手段は、リソースを投入するか機能を削減するかの 2 つの選択肢は ない。ここに手をつけることなく（例えば）プレッシャーだけをかけても、メンバーにできることと言えば品質を 犠牲にすることだけである。何のリソースの裏づけもないまま、ここで「品質だけは確保しろ」と号令だけを かけてもメンバーはしらけてしまう。 ■ベンダが簡単にメンバーの残業に頼ってはいることはないか？を確認する。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 37 ☆メンバーが 30 パーセント余計に働けば、成果物が 30 パーセント多く完成するわけではない。生産性は確実 に低下する。品質問題が生じるリスクも高まる。あるいは、その生産性の低下や品質上のリスクを考慮に入 れてもメンバーを長時間働かせたいと思うかもしれない。しかしそれはトランプのブラックジャックと同じよう なものである。いつリミットを超えて、全てが無になってしまうかの賭けである。 ☆無策のままメンバーに残業を強要しても、往々にして様々な悪影響を及ぼすだけである。士気は低下し、品 質は低下する。燃え尽き症候群や離職率の上昇などの現象を招く原因にもなる。メンバーが時間外作業を 当てにして、通常の勤務時間での作業の効率が落ちることにもつながる。だらだら作業が当たり前のもの になってしまう。「時間内に仕事を終わらせること」へ努力する力が失せてしまい、常に「テンポが遅い」仕事 になってしまう。 ■ベンダは、明らかに回復不可能な遅延を、無理にでも回復させようとはしていないか？を確認する。 ※無理な努力はしばしばプロジェクトを更に悪い状況に導くことになる。 遅延回復への 遅延回復へのアプローチ へのアプローチの アプローチの検証 ■ベンダが提示する遅延回復策は、発注側要求の実現レベルを下げることなく（スコープやスケジュール、品 質基準などの前提事項に一切の変更はなく）、現在の遅延を回復させるものか？を確認する。 ※スコープやスケジュールを変更して遅延を回復するのであれば、それは誰でも考えられる策である。仮に ベンダがこのような、要求の実現レベルを下げて遅延を回復させるような策を持ってきた場合には、（プロ ジェクトが余程の緊急事態にあるのでない限りは）一蹴してもよい。 ■ベンダはどのようなアプローチで遅延を回復させようとしているか？を確認する。 ※スコープやスケジュール、品質基準を変更することなく、またプロジェクトリスクを増加することなく、遅延 を回復するためには、大きく分けて 5 つのアプローチがある。どのアプローチで遅延を回復させようとして いるのかを確認する。 ①作業の量の増加 ・増員 ・残業 ・休日出勤 など ②作業の質の改善 ・組織体制や役割分担の見直し ・負荷バランスの調整 ・要員交代 など ③作業内容の最適化 ・間接作業の縮小 ・プロセスや規約への準拠の緩和 ・ドキュメント記述レベルの簡略化 ・中間成果物の削減 ・中間成果物の品質基準の緩和 ・レビュの最適化（回数、方法、範囲、基準） など ※「作業内容の最適化」は再発防止策に近いものである。プロジェクトの序盤～中盤であれば、工期短 縮のメリットを受けるタスクが後に多く残されているため、この策は有効に働くかもしれない。しかしプロ www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 38 ジェクトが既に中盤まで進んでいる場合には、この策によって既に発生してしまった遅延を回復するの は難しい。 ④作業効率の改善 ・会議の最適化 ・コミュニケーション環境の改善 ・コミュニケーションルールの変更 など ※「作業効率の改善」は再発防止策に近いものである。この策によって工期短縮のメリットを受けるタスク が後に多く残されているプロジェクトの序盤～中盤でなければ、既に発生してしまった遅延を回復する のは難しい。 ⑤リスケジュール ・タスクの並列化 ・タスクの期間短縮 ※確保していたバッファを消化して実現するリスケジュールであれば問題ない。当初の計画の誤りを修 正する意図でのリスケジュールであれば問題ない。しかし、そうでない場合は問題である。ベンダが身 を削らない限り、進捗や品質のリスクを高める方向に影響が及ぶことになる。必ず上記①～④のいず れかの策が必要になる。 ＜上記のいずれにもアプローチしない対策の場合＞ ■上記以外のアプローチで、どのような策で遅延を回復させようとしているのか？を確認する。 ※詳細かつ具体的に確認すること。 ☆（策のリソースがバッファを使用したものでない限りは）「他のタスクに使われるはずだったリソース」が、この 進捗回復策のために使われることになる。その場合、「発注側要求の実現レベルを下げることなく」という前 提条件が崩れてしまうリスクがある。 ☆ベンダが「生産性の向上に努めて」などといった理由をあげている場合、それを鵜呑みにしてはいけない。 その生産性向上策を詳細に具体的に徹底的に検証すべきである。なぜならば、その向上策に偽りがある ならば、それは「他で使うはずだったリソースを遅延回復のために使った」事実を隠ぺいするための言い訳 である可能性があるからだ。 ■（契約を脇に置いておくとすると）発注側にとって、そのタスクの遅延回復には、どの程度の重要性がある か？を顧みてみる。 △スケジュールよりも品質やコストの方が重要ということはないか？ △発注側として、遅延回復のためにベンダにどのような協力・支援を申し出る覚悟があるか？ ※契約を盾にして、本当に困っているベンダに対して何の支援もしないのであれば、その納期が本当に絶 対納期なのかどうかを考え直す必要があるかもしれない。 アプローチ別 アプローチ別の検証 作業の 作業の量で対応する 対応する場合 する場合 遅延に対して作業量で対応しようとする手法は一般にクラッシングと呼ばれている。クラッシングとはクリティカ ル・パス上のタスクにメンバーを追加投入したり、メンバーに時間外作業を課すことでスケジュールの短縮を 図る手法である。新しいツールや機器を導入することもクラッシングに含まれる。したがってクラッシングの際 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 39 には、リソースを追加投入するコストと、短縮される時間のトレードオフを考える必要がある。 ☆クラッシングにはバグの修正を見送ることも含まれる。 ※バグ除去のコストとシステムへの影響とスケジュール短縮のメリットをトレードオフにかけると、バグ修正 がそれに見合わないこともある。 ■ベンダは、クラッシングするタスクの優先順位の決定基準を明確にしているか？を確認する。 ◇検討すべき優先順位の例 ・後続タスクよりも先行タスクを優先する ・所要期間が長いタスクを優先する ・外部との折衝が必要なタスクよりも、チーム内、自社内で完結できるタスクを優先する ・緊急を要するタスクを優先する など ＜増員で 増員で対応する 対応する場合 する場合＞ 場合＞ ■リソースの裏づけがあることを確認する。 ■増員されるメンバーのスキルレベルを確認する。 △増員されるメンバーの経験値はどのくらいか？ ※「プロジェクトのよくある状況の管理」「Situation：新メンバーの参画の場面」「要員調達前の準備」（16頁） を参照のこと。 ■そのタスクは「量」で対応可能なタスクか？すなわち人海戦術でも対応可能なタスクか？を確認する。 △「質」が必要とされるタスク、すなわち専門スキルが必要とされるタスクに「量」で対応しようとはしていな いか？ ※人海戦術で対応できるのは量的作業の遅れである。特定のスキルを持ったメンバーでないと対応できな いような質的作業の遅れは挽回できない。 ☆作業が完全に分断されている場合、メンバー間のコミュニケーションの必要性が全くない場合に限って言え ば、人月は交換可能と言えるだろう。しかし分割不可能な作業については人月の交換は不可である。10 個 のサブ機能に完全分割可能な 10 人月の機能は、10 人に割り振って 1 ヶ月で完了する事ができるかもしれ ない。しかし分割不可能な 10 人月の機能は 100 人増やしても 10 ヶ月以下には短縮できない。 ☆A の作業と B の作業を、作業内容的には並列で実行することができるにもかかわらず、要員不足のために 直列で作業をしているならば、増員して A と B を並列で作業することによって、進捗を回復することができる。 しかし、A の作業が終わらなければ B の作業に取り掛かれない場合は、増員したからといって単純に生産 速度が向上し、遅延回復に貢献するとは言えない。 ■どのようにしたら質的作業を量的作業に変えることができるかを考える。 ※多くの作業を量的作業に還元することができれば管理は楽になる。 ■新メンバーのスキル・マッチングに問題はないか？を確認する。 △その裏付けとなる事実はあるか？それとも単にスキルシートで判断しているだけか？ ■ベンダは新メンバーの「早期立ち上げ」の計画は立てているか？を確認する。 △「立ち上げ」の期間はどのくらいを見積もっているか？ △「立ち上げ」の計画に（既に実施時のデータが存在するなど）裏付けとなる事実はあるか？ www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 40 ※「プロジェクトのよくある状況の管理」「Situation：新メンバーの参画の場面」「要員調達前の準備」（16頁） を参照のこと。 ■既存メンバーが新メンバーの「立ち上げ」支援作業に時間を取られることによって、既存メンバーの本来作 業の作業時間はどの程度削減されることになるか？を確認する。 △その裏付けとなる事実はあるか？それとも単なる希望的観測か？ ■既存メンバーが新メンバーの「立ち上げ」支援作業に携わることによって、既存メンバーの生産性はどの程 度低下することになるか？を確認する。 △その裏付けとなる事実はあるか？それとも単なる希望的観測か？ ☆要員追加はコストに見合った見返りが少ないものである。 ※新規メンバーを追加してプロジェクトの遅延を回復しようとする策は、一般的に行なわれているプロジェク ト制御の方法である。しかしその成果は、要員を追加するコストに比べて著しく小さくなるのが普通である。 場合によっては既存の生産性の高いメンバーの時間を費やしてしまい、かえって進捗が遅れてしまうと いうケースも見られる。 ☆スケジュールを 25 パーセント短縮するためには、必要となる要員は 75 パーセント増やさなければならない ものである。 ※したがってスケジュールが 25 パーセント遅延しているプロジェクトについて、他に効果的な手を何も打て ないのであれば要員を 75 パーセント増員しなければならない。増員によって遅延を回復させようと思うな らば、思い切って要員を投入しなければ目に見える効果を出すのは難しい。 ☆遅延の回復には物理的な限界が存在する。 ※30 キロの荷物しか持てない人は 30 キロ以上の荷物はどう頑張っても持てない。30 キロの荷物しか持て ない人は、2 回に分けて１5 キロずつ 1 時間かけて運べるかもしれないが、30 キロのままで 1 回で運ぼう としたら、10 時間かかっても運べない。どれだけ増員しても回復できない遅延もある。 ＜残業で 残業で対応する 対応する場合 する場合＞ 場合＞ ■ベンダはメンバーの残業時間の管理を行っているか？を確認する。 △月に何時間までの残業ならば許容範囲と考えているか？ △許容範囲は年齢や性別が異なっても同じか？ ※20 代と 40 代、男性と女性では体力（＝集中力＝生産性・品質）が異なってくる。 ■ベンダはメンバーのモチベーション管理を行っているか？を確認する。 △具体的には、どのようにしてモチベーション低下の兆候を把握しているか？ △具体的には、どのようにしてモチベーション低下を防いでいるか？ △具体的には、どのようにしてモチベーション向上をさせようとしているか？ ※「モチベーション管理を行っているから問題はない」という言葉を簡単に信用してはいけない。モチベーシ ョン管理は非常に困難である。策を打ったからといって簡単に効果が出るものではない。個人個人の効 果の出具合にも大きな差が表れる。 ＜休日出勤で 休日出勤で対応する 対応する場合 する場合＞ 場合＞ ■「残業で対応する場合」と同様の確認を行う。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 41 作業の 作業の質で対応する 対応する場合 する場合 ＜組織体制や 組織体制や役割分担の 役割分担の見直しで 見直しで対応 しで対応する 対応する場合 する場合＞ 場合＞ 組織全体としての総合的な生産性向上を目指し、そのコンテキストの中で遅延を回復させようとする策であ る。 ☆組織や役割分担の見直しは、小手先ではない抜本的な対策になる。成功すると劇的な効果を生む。しかし 組織と役割分担の問題は難しい。人の感情が大きく絡むところであり、失敗するとプロジェクトが逆に混乱し てしまうことにもなりかねない。また、一旦見直しを開始したら、うまくいかなかったからといってすぐに再見 直しというわけにはいかない。一般的には時間をかけて慎重に取り組むべき課題であり、性急にコトを進め るべきではない。 ☆組織や役割分担の見直しは慎重に取り組むべき課題ではあるが、重要プロジェクトほど、その見極めと決 断は重要である。決断に時間をかけすぎて手遅れになってしまっては元も子もなくなってしまう。 ■組織体制や役割分担の見直しで遅延が回復するというロジックに疑問点や曖昧な点はないか？を確認す る。 △何がどう作用して遅延が回復するのか、その理屈は明確になっているか？ △現在の組織体制、役割分担では進捗が進まない理由は何か？ △見直した組織体制、役割分担では進捗が進む理由は何か？ ■クリティカル・パス上にあるタスクにスキルの高い要員が割り当てられているか？を確認する。 △遅延タスクをリカバリするために、かえってクリティカル・パスをリスクに晒すことになっていないか？ ＜負荷バランス 負荷バランスの バランスの調整で 調整で対応する 対応する場合 する場合＞ 場合＞ ■ベンダのマネジャーは、チームごと、要員ごとの負荷状況をきちんと把握しているか？を確認する。 △現時点では、どのチームはどのような理由で負荷が重く（軽く）なっているのか？ △負荷バランスの偏りは、もともとの計画通りか？それとも当初の想定外に偏りが生じているのか？ ■想定外にチームや要員の負荷バランスが偏っていた場合、ベンダはその理由をきちんと把握しているか？ を確認する。 △計画が前提としていたもともとの条件に変更があったのか？ △計画作成時、要員の作業内容を正確に把握していなかったのか？ △計画作成時、要員の能力を正確に把握していなかったのか？ △想定外の割り込み作業が発生したのか？ ■クリティカル・パス上のタスクの割り当て状況は明確になっているか？を確認する。 ※定義から言ってクリティカル・パス上のタスクはリソースの使用率が 100％となる。クリティカル・パス上の タスクが全て一つのチームや個人に割り当てられているのは、負荷分散の観点からは好ましくない。 ■負荷バランスを平準化すべきかどうかを検討する際の評価基準は何か？を確認する。 ※負荷バランスを平準化することによって、逆に進捗状況を（一時的にではなく恒常的に）悪化させる場合 もある。負荷バランスの平準化は目的ではない。一ヶ所に負荷が集中することによるリスク回避の一つ の手段である。様々な影響を検討し、慎重に決定すべきである。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 42 ■ベンダは、どのチーム、どの要員のタスクが調整可能か（スケジュールの変更が可能か）を把握している か？を確認する。 △タスクがノン・クリティカル・パス上にあるかどうかを確認しているか？ △タスクのスラック（余裕）を分析しているか？ △タスクの重要度、優先度を確認しているか？ △タスクの前提条件、制約条件を確認しているか？ △タスク同士の依存関係を確認しているか？ △担当者の意思を考慮しているか？ ■ベンダは、負荷の調整方法を検討しているか？を確認する。 △一人の担当者（一つのチーム）が完全にタスクを請け負うか？ △複数の担当者（複数のチーム）でタスクを兼務するか？ △単純作業（ドキュメント作成や試験データ作成等）のみを複数の担当者（複数のチーム）で請け負うか？ ＜要員交代で 要員交代で対応する 対応する場合 する場合＞ 場合＞ 「要員交代での対応」とは、担当者をスキルの高い要員に変更することによって、当該タスクの遅延を回復さ せようとする策である。 ☆作業途中のタスクを引き継ぐのは、どれほど優秀なメンバーでも簡単な仕事ではない。最初からその実力 をフルに発揮することは難しい。しかし、タスクを最初から、一から任せられるのであれば、優秀なメンバー への交代は、成果が最も確実視できる方法でもある。 ■当人のコミットメントは得られているか？を確認する。 ※当人のコミットが得られていない要員交代はうまくいかない場合が多い。 ■メンタル面でのフォローを忘れていないか？を確認する。 ※交代させられたメンバーのフォローを怠ってはいけない。それは交代させられた本人のためだけではな い。実力主義は決して悪いことではないが、それは中長期のスパンで公平な評価がなされた場合の話で ある。短期間の出来不出来で「できなければ交代させられる」「できなければ評価が下がる」といった‘恐 怖心’を植えつけてしまいかねないマネジメントは、周囲のメンバーにもよい影響を与えない。 ■引き継ぎ作業のために費やされるリソース（工数）はきちんと見積もられているか？を確認する。 ※引継ぎ作業の間は、旧メンバーも新メンバーも作業に携わることはできない。引継ぎ作業が終わっても、 新メンバーが「真の実力」を発揮するには一定時間を要する。この間の生産性は、おそらく旧メンバーが そのまま作業をしていた場合よりも低いだろう。要員交代は、この引継ぎにかかるコストを差し置いてもな お、明らかにメリットの方が大きい場合にのみ、有効となる。 ■クリティカル・パス上にあるタスクにスキルの高い要員が割り当てられているか？を確認する。 ※要員交代は重要なタスクにこそ威力を発揮する策である。重要でないタスクは、多少進捗が遅れていて も「重要ではない」のである。 △重要でない遅延タスクをリカバリするために、クリティカル・パスをリスクに晒すことになっていないか？ 作業内容の 作業内容の最適化 最適化で対応する 対応する場合 する場合 「作業内容の最適化」は再発防止策に近いものである。作業内容を最適化することによって、タスク遂行の工 期を短縮させようとするものである。この策が本当に工期短縮につながるものならば、そしてこの策によって www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 43 工期短縮のメリットを受けるタスクが後に多く残されているならば、それは有効な策である。しかし、メリットを 受けるタスクが多く残されているのは、プロジェクトの序盤～中盤である。プロジェクトが既にそれ以上進んで いるのであれば、（遅延の状況にもよるが）既に発生してしまった遅延を回復するのは難しい。 ＜間接作業の 接作業の縮小で 縮小で対応する 対応する場合 する場合＞ 場合＞ ■間接作業の縮小の可能性について確認する。 ※「間接作業の縮小」とは、発注側として深入りしてコメントするような領域ではない。ただし、コメントできる 立場にあるならば、「20 パーセント→15 パーセント」といった数値データを提示してもらいたいところであ る。 ■各種情報収集作業の効率化の可能性について確認する。 ※これも発注側が深入りしてコメントすべき領域ではない。しかし、ベンダ内部で取り決められている各種管 理のための情報収集（見える化のための情報収集）活動が、メンバーの作業や精神面で大きくマイナス の影響を及ぼしている場合も多々ある。 ＜プロセスや プロセスや規約への 規約への準拠 への準拠を 準拠を緩和することで 緩和することで対応 することで対応する 対応する場合 する場合＞ 場合＞ ■プロセスや規約への準拠のそもそもの目的は何か？を確認する。 ※プロセスや規約は、ともするとそれ自体が目的化してしまう。常に意識していないと、「プロセスや規約の そもそもの目的」に資するところがないばかりか、かえって目的から遠ざけてしまうような効果をもたらし てしまう。プロセスや規約に準拠することが、プロセスや規約の目的を達成することに役に立っているか どうかを、常に見張っていなければならない。 ■プロセスや規約への準拠を緩和すると、上記目的の達成にどのような影響があるのか？を確認する。 ※影響が皆無なのであれば、あるいは影響を考慮する必要がないのであれば、これまでプロセスや規約へ の準拠のために無駄なリソースを費やしてきたことになる。同じ目的が、より小さなリソースで実現できる ならば、それに越したことはないはずである。プロセスや規約への準拠を緩和しても、結果には影響がな いのであれば、それは積極的に検討されるべきである。 ＜ドキュメント記述 ドキュメント記述レベル 記述レベルの レベルの簡略化で 簡略化で対応する 対応する場合 する場合＞ 場合＞ ■ドキュメント記述レベルが現在の粒度で書かれている理由（目的）は何か？を確認する。 ※ドキュメントの記述レベルの問題も、プロセスや規約への準拠と同じ問題である。疑問を持たずにただ 「そういうものだ」として作成していると、そこに無駄なリソースを費やしていることにもなりかねない。その 粒度で記述する目的を明確にした上で、その目的を達成するために必要最小限の粒度を見つけ出すべ きである。 ■ドキュメント記述レベルを簡略化すると、上記理由（目的）にどのような影響があるのか？を確認する。 ※影響が皆無なのであれば、あるいは影響を考慮する必要がないのであれば、これまで「その粒度」で記 述することによって、無駄なリソースを費やしてきたことになる。 ＜中間成果物の 中間成果物の削減で 削減で対応する 対応する場合 する場合＞ 場合＞ ■中間成果物のそもそもの目的は何か？を確認する。 △それは誰の、何の作業のために、あるいは何の報告のために、役立つ成果物なのか？ www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 44 ■中間成果物を削減すると、上記目的の達成にどのような影響があるのか？を確認する。 ※影響が皆無なのであれば、あるいは影響を考慮する必要がないのであれば、これまで中間成果物の作 成のために無駄なリソースを費やしてきたことになる。 ■ドキュメント作成に割いていたリソースを開放することを検討してもらう。 ☆CMM などの重量級の方法論を使用した場合、リソースのほとんどをドキュメント作成のために費やしてしま うことになる。往々にして完成するのは、分厚く、内容にほとんど意味がなく、単に作成すること自体が自己 目的化して作成されたようなドキュメントである。最終成果物を作成するために、このようなドキュメントが貢 献することはほとんどない。事実、遅延したプロジェクトでも、無意味なドキュメント作成がなければ遅延せ ずに完成していたであろうプロジェクトは無数にある。 ☆作成するドキュメントを、目的が明確で本当に必要とされているものだけに限る事によって、大きな工数が 節約できる。中間成果物はあくまで中間成果物であって、プロジェクトの目的ではない。納品物でもない。 ☆保守などを考えれば全ての機能について詳細なドキュメントを作成することは無意味ではない。しかし保守 のためのドキュメントを開発の途中で、しかも要求の変更があれば随時修正するといった労力をかけてまで 作成する必要性は薄い。 ＜中間成果物の 中間成果物の品質基準を 品質基準を緩和することで 緩和することで対応 することで対応する 対応する場合 する場合＞ 場合＞ ■中間成果物に品質基準を設けることのそもそもの目的は何か？を確認する。 ※中間成果物であっても、そこに品質基準を設けることは重要なことである。ただし、目的を明確化した上 で、その目的を達成するために必要最小限の基準を設けることが重要である。 ■中間成果物の品質基準を緩和すると、上記目的の達成にどのような影響があるのか？を確認する。 ※影響が皆無なのであれば、あるいは影響を考慮する必要がないのであれば、これまでクリアの必要のな い基準をクリアするために無駄なリソースを費やしてきたことになる。 ＜レビュの レビュの最適化（ 最適化（回数、 回数、方法、 方法、範囲、 範囲、基準） 基準）で対応する 対応する場合 する場合＞ 場合＞ ■現在のレビュ基準のそもそもの目的は何か？を確認する。 ■現在のレビュ基準を緩和すると、上記目的の達成にどのような影響があるのか？を確認する。 ※影響が皆無なのであれば、あるいは影響を考慮する必要がないのであれば、これまでクリアの必要のな い基準をクリアするために無駄なリソースを費やしてきたことになる。 作業効率の 作業効率の改善で 改善で対応する 対応する場合 する場合 ☆作業効率の改善はよく口に出されるアイデアではあるが、実際に効果を出す策を考案し、実施するのは非 常に難しい。何も問題が生じていなくても最大の効率を目指して作業するのが当たり前の姿である。簡単に 実施できる改善策があるならば、とうの昔に実施している。実施されていない改善策とは、実施が困難な改 善策のことである。組織の文化や体制の問題、政治の問題なども絡み、簡単には解決できない。 ☆ベンダから「作業効率を改善することによって遅延を回復する」との提案が出てきた場合は、簡単にその効 果を信じてはいけない。策をじっくり検証するのはもちろんであるが、その実施後の追跡作業も必須である。 何らかの「痛み」を伴った策であれば期待もできるが、誰の「痛み」も伴わない策であれば、効果は期待薄 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 45 である。その策が結局は何の効果も生みださなかった場合に備えて、ベンダに対して事前に別の策の検討 も要請しておいた方がよい。 ■忙中閑あり（どこかに「待ち時間」が発生していないか？）を考えてみる。 ※目が回る忙しさの中でも暇はあるものである。システム開発につきものである「待ち時間」のためである。 効率的に動いていると思われるときでも、どこに「待ち時間」が発生しているかについて常に目を光らせ ておくことである。マネジャーは「待ち時間」の存在を洗い出さなければならない。 ■ベンダは、（作業効率の名目で）タスクの作業手順を安易に省略してはいないか？を確認する。 ※ある手順がタスクに組み込まれているのには、それなりの理由があってのはずである。その理由を明確 にすることなしに手順を省略することは、新たな問題の種を埋め込むようなものである。その手順が、計 画策定時にじっくり検討された結果のものであるならば、省略の際にはその影響もよく考えてみるべきで ある。 ※ただしもちろん、頭を使っていないマネジャーに率いられているプロジェクトでは、何も考えずにこれまで のやり方を踏襲し、理由なく意味もない手順を踏襲しているだけの場合もある。 ■‘セル生産方式’を検討する。 ※9 人のメンバーがいるのであれば、3 人が設計、3 人が実装、3 人が試験、と役割を割り振るのではなく、9 人全てのメンバーが設計、実装、試験を一貫して担当できないかを考える。 ＜会議の 会議の効率化で 効率化で対応する 対応する場合 する場合＞ 場合＞ 作業効率化という難しいテーマの中で、（ほとんど唯一）期待できるのは会議の効率化である。ただし、既に十 分に効率的に会議を運用している組織やチームに対しては、（当然ではあるが）効果は期待できない。 ※会議の効率化はプロジェクト管理でも重要なテーマの一つであるが、本マニュアルのテーマからは逸脱す るので割愛する。 ＜コミュニケーション環境 コミュニケーション環境の 環境の改善で 改善で対応する 対応する場合 する場合＞ 場合＞ ※コミュニケーション環境はプロジェクト管理でも重要なテーマの一つであるが、本マニュアルのテーマからは 逸脱するので割愛する。 ＜コミュニケーションルールの コミュニケーションルールの変更で 変更で対応する 対応する場合 する場合＞ 場合＞ ※コミュニケーションルールはプロジェクト管理でも重要なテーマの一つであるが、本マニュアルのテーマから は逸脱するので割愛する。 リスケジュールで リスケジュールで対応する 対応する場合 する場合 ☆リスケジュールが、事前に確保していたバッファを消化して実現するものであれば問題はない。（当初の見 積が過大であったという意味での）計画の誤りを修正する意図でのリスケジュールであれば、少なくともプロ ジェクト的には問題はない。しかし、そうでない場合は問題をはらんでいる可能性が高い。ベンダが身を削 って持ち出しをする決断をしない限り、ほとんどの場合は進捗や品質のリスクが高まることになる。 ☆ベンダがリスケジュールを提案してきた場合、まずはそれが更なる進捗の遅延や品質低下のリスクを伴うも のではないことを確認する必要がある。リスケジュールの原資が「バッファの切り崩し」でないとすると、取り www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 46 うる策はタスクの並列化（ファスト・トラッキング）かタスクの期間短縮（クラッシング）のいずれかになる。この 提案が進捗や品質低下のリスクとは無関係であることをベンダに説明してもらう必要がある。 ☆ファースト・トラッキングとは順次に予定していた作業を同時並行に行うことによりスケジュールの短縮を図 る手法である。もちろん対価なしでスケジュールの 短縮を実現できるはずはない。ファースト・トラッキング を使用すると、計画時に担保していたリスクの顕在化の可能性を高めることになる。 ☆ファースト・トラッキングはパズルではない。スケジュール表の上でタスクを色々と動かして、ようやく期間内 におさまるパスを見つけたとしても、それはあくまでスケジュール表の上の話でしかない。現実もその通り ‘ピタリとはまる’とは限らない。 ＜タスクの タスクの並列化策を 並列化策を取る場合＞ 場合＞ ■なぜ最初からタスクを並列化させていなかったのか？最初の計画ではタスクを直列でつないでいた理由は 何か？を確認する。 △タスクを並列化させることによる、プロジェクト上のデメリットやリスクは何か？ △一人（単独チーム）で実施予定のタスクを二人（複数チーム）で分担するのであれば、そこに統一性や整 合性のリスク、相互インターフェースのリスクは生じないか？ △タスクを並列化させることのデメリットやリスクに対して、どのような対策を打つつもりか？ ■同時並行作業により、リソースの確保に問題は発生しないか？を確認する。 △リソースの確保に問題があるとき、協力会社の利用は可能か？ ■順次作業として計画されていたタスクのうち、どの部分が同時並行作業が可能なタスクなのか？を確認す る。 △先行タスクの完了を待たずにタスクを開始することにより、どの程度の進捗を稼ぐことができるのか？ △その進捗は、並行作業することによって考えられるデメリットやリスクを考慮しても、価値があるものなの か？ ■タスク同士のつながり（パス）を変更することによって、タスク間の依存関係に矛盾が生じていることはない か？を確認する。 △成果物の依存関係に矛盾はないか？並列化されたタスクは、それぞれ依存関係になく、独立して進めら れるものか？ ＜タスクの タスクの期間短縮策を 期間短縮策を取る場合＞ 場合＞ ■なぜ最初からその期間で計画を立てていなかったのか？最初の計画でその期間を確保していた理由は何 か？を確認する。 △その期間は必要だからその期間で計画が立てられていたのではないのか？ △計画立案時とは何が違っているから期間を短縮しても大丈夫なのか？ △期間短縮のデメリットやリスクを洗い出しているか？ △期間短縮のデメリットやリスクに対して、どのような対策を打つつもりか？ △担当者の残業時間の増加を見込んでいるのか？ △どの作業を省略することによって時間を捻出するのか？ △省略する作業は、そもそも何のために必要だと思われたから計画に含まれていたのか？ △期間を短縮して品質レベルを維持することができるのか？ △期間を短縮しても品質レベルを維持できるのであれば、他のタスクにも展開可能ではないのか？ www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 47 ■新スケジュールと旧スケジュールとで、スケジュール以外に変更された点はないか？を確認する。 △レビュ対象成果物やレビュ要領など、品質関連の作業に変更はないか？ ■新スケジュールの WBS とマスタースケジュールの整合性は取れているか？を確認する。 △各チーム別のスケジュールとマスタースケジュールの整合性は取れているか？スケジュールの合流地 点にバッファは存在するか？ △外部ステークホルダーが関連するタスクと新スケジュールの整合性は取れているか？スケジュールの合 流地点にバッファは存在するか？ △タスク同士の連携の整合性は取れているか？スケジュールの合流地点にバッファは存在するか？ ■新スケジュールは各チームの現場の担当者のコミットメントを得られているか？を確認する。 △新スケジュールに対して、現場の担当者はどのようなリスクを感じているか？ △上記リスクの軽減のために、担当者はどのような策やどのような支援が必要と考えているか？ △上記担当者が感じているリスクについて、マネジャーはどのような判断を下しているか？ △その判断の根拠は何か？ （参考） 参考）開発規模の 開発規模の削減を 削減を検討する 検討する場合 する場合 「製品から機能を完全に削除することは、つまりその機能に関連する仕様作成、設計、テスト、ドキュメンテー ションなどのすべての作業の必要をなくすことになるので、ソフトウェアスケジュールを短縮する最も強力な方 法の一つとなる」（「ラピッドデベロップメント」スティーブ・マコネル） ベンダが提示する遅延回復策は、発注側要求の実現レベルを下げることなく（スコープやスケジュール、品質 基準などの前提事項に一切の変更はなく）、現在の遅延を回復させるものであるべきである。しかし、火の車 に陥ったプロジェクトでは、発注側としてもそうも言ってられない「究極の選択」を迫られることがある。 ■機能の削減で納期を守ることができるか？を確認する。 ※ベンダからの機能の削減の提案（要請）に対しては、その代替案や代替の運用方法を提示してもらうこ と。 ■削減対象の機能はクリティカル・パス上の作業か？を確認する。 ※機能の削減において注意すべきは、それがクリティカル・パス上の作業かどうかということである。クリテ ィカル・パス上にない作業をいくら削減したところで、全体スケジュールの遅延は回復されない。 ■機能削減に対して、ベンダ側はどのような譲歩をするのか？を確認する。 ※プロジェクトを守るためとはいえ、発注側だけが譲歩することは考えられない。 ☆機能を削減するということは、その機能の要件定義、設計、実装、試験、ドキュメント作業、他の機能との連 携の調整、といった作業が不要になると言うことである。発注側とすれば受け入れがたい策であるが、遅延 回復の最も効果的な策と言える。 （参考） 参考）納期の 納期の延期を 延期を検討する 検討する場合 する場合 ■ベンダからの「納期の延期申し入れ」の理由・根拠は何か？を確認する。 △納期延期の原因と対策は明確になっているか？発注側として納得できるものか？ ※品質にも機能にもコストにも手をつけずに遅延を解消することはできない。このような場合には、プロジェ www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 48 クトを守る立場からすれば、再スケジューリングも選択肢として真剣に検討せざるを得ない。しかしもちろ ん、契約問題に発展する可能性はある。 ■ベンダは、遅延した日数分を単純にスケジュールに追加するようなことをしてはいないか？を確認する。 ※遅延が発生したのは元々の計画の信頼性が低かったためである。その信頼性が低い計画をベースにし て単純に遅延日数を追加したところで、新たに作成したスケジュールを本当に守れるのかどうかは疑わ しい。 ■ベンダは、単に上司（発注側）からの圧力に屈したスケジュールを立ててはいないか？を確認する。 ※圧力に屈したスケジュールとは、マネジャー本人も現場の担当者も無理だと思っている‘押しつけられた’ス ケジュールである。そのようなスケジュールがすぐに行き詰まり、再度スケジューリングする羽目になるのは 目に見えている。 ■（発注側にとっての）遅延回復策の投資対効果を検討する。 ※状況によっては計画に固執せず、‘合理的な’判断を下すことも考える必要がある。3 ヶ月の遅れが 3000 万円の機会利益の喪失を招くならば、遅延対策のためにいくらまで費用追加することが可能なのか、計 算によって合理的に判断することができる。時にはこのような合理的な意思決定のあり方も検討すべき である。当初の計画通りに強引に進めることで、さらに損失を大きくしてしまうこともある。中間管理職の 権限では難しいかもしれないが、当初想定していた利益を多少あきらめることによって、より大きな損失 を防ぐという考えも、選択肢の一つとして残しておくべきである。 Step8： Step8：解決策の 解決策の副作用を 副作用を検証する 検証する ☆マネジャーが「急げ」と指示すれば、メンバーはインスペクションや単体テストの時間を削ってでも、マネジャ ーの指示に従おうとする。マネジャーが「急げ。ただし、品質も確保しろ」と指示すれば、形式だけのテスト仕 様書とテスト実施結果は出てくるかもしれないが、その項目の多くは‘コピペ’で意味のないものだろう。頭を 使う時間が削られてしまうのだから、担当者にしてみればそれは仕方のないことである。 ※「課題管理」「Situation：解決策策定の場面」「Step8：解決策の副作用を検証する」（96頁）を参照のこと。 Step9： Step9：遅延の 遅延の兆候を 兆候を識別する 識別する ■遅延が表面化する前に何らかの兆候に気付かなかったか？「今思うと・・・」というようなものはないか？を 確認する。 ■遅延が生じたタスクを担当していた担当者にヒアリングを実施しているか？を確認する。 △遅延の兆候について、マネジャーは気づかなくても、担当者は気づいていたということはないか？ △担当者はどのあたりで危機感を抱いていたか？ △その担当者の意見では、どうすればこの遅延を防止できたと思われるか？ ■遅延が生じたタスクを担当していた担当者の週報を読み返しているか？を確認する。 △担当者からの週報に遅延の兆候は表れてはいないか？ ※実際に遅延が発生したタスクについて、その担当者の週報に兆候が表れていないのは、逆に問題で もある。「悪いニュース」を報告できない空気がある可能性がある。 ■タスクの進捗状況の時系列の変化の中に遅延の兆候は表れてはいないか？を確認する。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 49 ■他のステークホルダーが関係する作業の中に、遅延の兆候は表れてはいないか？を確認する。 ※タスクに関与するステークホルダーが増えれば増えるほど、結果の不確実性が増し、結果として遅延に つながることが多い。 ■今回のような原因の遅延には、どのような兆候が生じると考えられるか？どのような兆候が生じていたと考 えられるか？を考えてみる。 △同じ原因の遅延が次に発生する場合には、その兆候を発見して早期に対応できると思うか？ ベンダ内部 ベンダ内部の 内部の兆候 ■以下について、ベンダ側のマネジャーに確認してみる。 ※越権行為・内政干渉になりかねない質問なので、相互の関係の状況を見ながら、「聞くべきか」「聞かざる べきか」を判断すること。質問の際には、その質問をすることが当然だと思われるような‘証拠’や、発注 側としての意見を持った上で質問すること。 △報告内容や詳細度が当初に比べて大雑把になっているとは感じないか？ △報告の歯切れが悪いとは感じないか？ △スケジュールに対する不満が聞こえてくることはないか？ △仕様に対する不満が聞こえてくることはないか？ △他のメンバーや他のチーム、ユーザ、上司に対する不満が聞こえてくることはないか？ △成果物、中間成果物が品質基準に達していないものが多くなってきていないか？ 発注側の 発注側の兆候 ■以下は発注側が顧みるべき項目である。ベンダに「このようなことはないか」と確認してみる。 △発注側の要求に変化が発生していることはないか？ △発注側の要求に矛盾を感じることはないか？ △要求の優先度に変化が発生していることはないか？ △発注側に意見の不一致が見られることはないか？ △発注側の指示命令系統に疑問や曖昧さを感じることはないか？ △発注側のコミットメントが低下していると感じることはないか？ △予定が変更されたりすることはないか？ △頻繁に「予定外」の支援作業を依頼されることはないか？ Case：「 Case：「古 ：「古い」遅延の 遅延の場合 遅延の 遅延の回復状況を 回復状況を確認する 確認する 「以前からの遅延が解消されないタスク」の場合、そのアプローチの仕方は「初めて遅延報告されたタスク」の 場合とは違ってくる。もちろん、回復策の検証は依然として必要だが、その前にこちらも、「なぜ状況が改善さ れないのか」という、正確な現状認識が大切である。 ■前回、前々回の報告との比較で、遅延は拡大傾向にあるか？縮小傾向にあるか？変化なしか？を確認す る。 ※以前から発生しているが、まだ解消されていない「古い」遅延の場合は、それが前回の報告から縮小傾 向にあるのか、拡大傾向（または持続傾向）にあるのかによって、発注側の対応が違ってくる。まずはこ こを確認するのが最初である。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 50 ☆遅延が縮小傾向にあるのであれば、回復策が効いているのかもしれない。目に見えて縮小しているようで あれば、そのまま状況注視でよいかもしれない。ただし、縮小がほんのわずかであったり、状況が変化なし、 あるいは拡大傾向であったりする場合には、発注側としても放置しておくわけにはいかない。回復策を打っ たにもかかわらず進捗が回復に向かっていない場合は、その理由を検証するとともに、新たな策の策定も 検討に入れなければならない。 ■遅延が報告されたからといって、ベンダに直ちに遅延回復を強要してはいけない。 ※もともと情報不足の中で作成された計画である以上、プロジェクトの進行と共に徐々に現実との乖離が発 生するのは当然である。ここでベンダに対して、あくまで当初計画に沿うように強要すると、進捗の虚偽 報告や成果物の品質低下など様々な悪影響が発生するリスクが高くなる。計画から外れないようにプロ ジェクトを進めていくのは当然ではあるが、乖離が発生したときにどこまでを許容範囲とみなすのか、どこ からが対応策の検討ラインに入るのかといった、対応の幅をもたせることも必要である。 遅延が 遅延が縮小傾向にある 縮小傾向にある場合 にある場合 ♪遅延報告があったタスクについて、その遅延が急激に解消あるいは小さくなった場合 △そもそもマネジャーが現場の状況を正確に把握しきれていない可能性はないか？ △何らかの作業手順が省かれた可能性はないか？ △品質には問題がないか。成果物は検証されているか？ Step1： Step1：策と遅延縮小の 遅延縮小の因果関係を 因果関係を確認する 確認する ■遅延回復策とそのロジックを再確認する。 ※「進捗管理」「Situation：遅延発生の場面」「Case：「新しい」遅延の場合」「Step7：ベンダの遅延回復策を 検証する」（34頁）を参照する。 ■遅延の縮小傾向は遅延回復策の効果によるものと考えられるか？を確認する。 △遅延は策の実施を契機に縮小されてきたか？ △策の実施に管理監督はついていたか？ △策は現場できちんと実施されていたか？実際にはほとんど実施されていなかったということはないか？ △担当者は、策の実施と遅延の回復との間に因果関係を認めているか？因果関係を実感しているか？ △策の実施に問題があった場合、何が影響して遅延が回復してきていると考えられるか？原因の目途を立 てることができるか？ △上記回答の正しさは何によって確認することができるか？ ※因果関係を「立証」する必要はないが、（アンケートなどで）現場の声を吸い上げるなどして、因果関係の 「確からしさ」くらいは明らかにしておきたいところである。 ■遅延回復策の実施以外に、そのタスクを取り巻く外部環境に変化はなかったか？を確認する。 △遅延回復の後押しをするような変化はなかったか？ △逆に、遅延回復を妨げるような変化はなかったか？ ■今、策の実施を中断した場合、遅延縮小の傾向はなくなると言い切れるか？を確認する。 ■策と遅延縮小の因果関係が「確からしい」場合は、その策を組織のナレッジとして蓄積しておくこと。 ※ナレッジとして蓄積する場合には、策が実施された環境情報や前提条件とともに蓄積すること。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 51 Step2： Step2：静観するか 静観するか、 するか、新たな策 たな策を策定するかを 策定するかを検討 するかを検討する 検討する ■遅延縮小のスピードが今後改善されていく見込みはあるか？逆にスピードが鈍る可能性はないか？を確 認する。 △その理由は何か？どのような事実が根拠になっているか？どのような意見が出ているか？ ■タスクの完了予定日以前に、遅延が回復する見込みはあるか？すなわち完了予定日は遵守されるか？を 確認する。 △遅延自体は縮小傾向にあるが、完了予定日は超過する可能性があるか？ △完了予定日を超過した場合、他のタスクの進捗に与える影響は明確になっているか？いつ明確にするつ もりか？ ■策自体は最適化されているか？を確認する。 △もう少し「軽い」策で同じ効果を出すことはできないか？ △同じ負荷のままで、もう少し策の効果（遅延縮小スピード）を上げることはできないか？ ■新たな遅延回復策を検討する場合のトリガは何か？を確認する。 △進捗や周囲の環境がどのような状況になったら新たな策が必要となるか？ △完了予定日の遵守が難しい場合でも、新たな策は検討しないか？ △客観的な基準で判断できるように、新たな策の検討のトリガを定めることが可能か？ 遅延が 遅延が拡大傾向にある 拡大傾向にある場合 にある場合 ♪遅延報告があったタスクについて、その遅延が拡大傾向にある場合 △そもそもマネジャーが現場の状況を正確に把握しきれていない可能性はないか？ △対策は言葉だけであって、何ら実効力がないものである可能性はないか？ ※言葉だけの対策は、無駄に時間が浪費されるという意味で、二重にプロジェクトへの害となる。 Step1： Step1：対応状況を 対応状況を再確認する 再確認する ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「Step1：対応状況 を再確認する」（103頁）を参照のこと。 Step2： Step2：再発防止策を 再発防止策を再検証する 再検証する 策の有効性を 有効性を検証する 検証する ■再発防止策が有効であれば、遅延の回復または少なくとも遅延拡大の防止には効果があると考えられる か？を確認する。 ☆再発防止策は、遅延の根本原因に対策を施すものである。再発防止策は、本来は遅延の再発を防止する ものであり、既に生じてしまった遅延を回復させるための策ではない。しかし多くの場合は、遅延の原因を 排除することによって、既存の遅延がそれ以上拡大するのを防止する効果も期待できるものである。 ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「解決策を再検証 する」「策の有効性を検証する」（104頁）を参照のこと。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 52 実行状況を 実行状況を検証する 検証する ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「解決策を再検証 する」「実行状況を検証する」（106頁）を参照のこと。 新たな策 たな策の必要性を 必要性を検証する 検証する ■（遅延が拡大しているので）新たな再発防止策を打つ必要はないか？を確認する。 ※「問題は遅延回復策にあり、再発防止策には問題はない」というのも一つの解である。 ♪新たな策が必要ないという場合 △その理由は何か？その根拠に事実の裏付けはあるか？ ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「解決策を再検証 する」「新たな策の必要性を検証する」（107頁）を参照のこと。 Step3： Step3：遅延回復策を 遅延回復策を再検証する 再検証する 策の有効性を 有効性を検証する ■遅延回復策が誤っている可能性はないか？を確認する。 ※「進捗管理」「Situation：遅延発生の場面」「Case：新しい遅延の場合」「Step7：ベンダの遅延回復策を検 証する」（34頁）を参照のこと。 ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「解決策を再検 証する」「策の有効性を検証する」（104頁）を参照のこと。 ■回復策が単なる原因への対処であり、再発防止策になっている可能性はないか？を確認する。 実行状況を 実行状況を検証する 検証する ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「解決策を再検証 する」「実行状況を検証する」（106頁）を参照のこと。 新たな策 たな策の必要性を 必要性を検証する 検証する ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「解決策を再検証 する」「新たな策の必要性を検証する」（107頁）を参照のこと。 Step4：「 Step4：「策 ：「策の失敗」 失敗」の再発防止策を 再発防止策を検討する 検討する ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「Step4：「策の失 敗」の再発防止策を検討する」（108頁）を参照のこと。 策の有効性に 有効性に問題があった 問題があった場合 があった場合 ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「Step4：「策の失 敗」の再発防止策を検討する」「策の有効性に問題があった場合」（108頁）を参照のこと。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono) 進捗管理 Situation：遅延発生の場面 53 策の実行に 実行に問題があった 問題があった場合 があった場合 ※「課題管理」「Situation：解決策の実行評価の場面」「解決策が効果をあげていない場合」「Step4：「策の失 敗」の再発防止策を検討する」「策の実行に問題があった場合」（109頁）を参照のこと。 www.motozono.com (Copyright(C) 2010 Toshifumi Motozono)
© Copyright 2024 Paperzz
