■デザイン・レビューのあり方 （No.110）
新製品開発のプロセスの中にデザイン・レビュー（以下ＤＲ）があって，広く一般的に行なわれている。つまり，設計を進める中で，最後まで行ってからチェックするのでなく，途中でチェックをしようとするもので，通常一般の機器を製造，或いは自動車や建設機械といったものを製造している会社では必ず行なわれている開発プロセスの一部である。その呼び名は会社によって異なるが，中間段階で設計レビューをしようと云うシステムである。
そもそもこのようなＤＲが行なわれるようになった背景は，製品開発のプロジェクトの状況を確認せずプロジェクト側に一任している状態では，出来不出来が極端となり，組織的な力を発揮できない。そのため，プロジェクトの中間チェックがなされるシステムが出来上がっている。したがって，プロジェクトとして中間目標（マイルストーン）としての位置づけとなっている。この意味は，外部環境の大きな変化など特殊事情を除いて，大きくずらすことはプロジェクト全体のスケジュールに大きく影響するのが一般的である。また，その中間目標までに，何を完了させておかねばならないかが，パスクライテリアとして決められている。プロジェクトの進捗はこうした大きな流れが，順調に進んでいるか，問題が発生して挽回策が必要か，或いは，プロジェクトとして中断した方がよいなどと云った判断がなされる（ＤＣＰ：Decision Check Pointと云った表現もある）。
ところが，プロジェクトによってはなかなかそうしたＤＲのプロセスの背景を無視して，プロジェクト側の一方的な都合で日程を大きくずらすことが行なわれることがある。その理由を調べてみると，一部分だけのパスクライテリア（判定基準）が満足できないために，重要なＤＲを簡単に１カ月も遅延させるといったことが行われる。例えば，ＤＲとして計画の妥当性を審議するものが設定されていたとする。つまり，計画が出来上がった時点で速やかに立てた計画に妥当性があるか，関係者が審議しようというＤＲの場である。しかし，プロジェクト全体を眺めていればすぐ判ることであるが，プロジェクトの半分以上が終わった段階で，プロセスで決まっているのでＤＲ（計画性の妥当を審議するＤＲ）をやると云うのはどう考えても遅すぎることが判るはずである。
しかし，プロジェクト側の考えは，ルールで決められたパスクライテリア（判断基準）の一部が間に合わないことを理由にスケジュールを延ばそうとしている。しかし，本来，プロジェクトを成功に導くために作られたシステムが足枷となって，上手くクリアできないことが出てきたので，それがパスするまで待とうと言う考えである。これは，プロジェクトを上手く成功に導こうとしているならこんなことにはならないはずである。少なくともプロジェクトリーダなるものは，プロジェクトの全貌を把握して，何が重要で，プロジェクトを成功裏に収めるために何を為すべきか，常に考えていなければいけない。そういった観点で見るとそもそものプロセスの目的から逸脱して，パスクライテリアだけを意識して，如何にして監査をパスするかが中心になってしまっている。
これでは，なかなかプロジェクトが上手く行く訳が無い。予め計画された時点までに，決められたパスクライテリアを満足するように努力することが先ず第一であり，それが何かの外部的要因などで，どうしてもクリアできない場合，単にスケジュールを延ばすことを考えるのでなく，状況によってはその一部のパスクライテリアのクリアをこのような形で挽回すると云った計画をもって，ＤＲをやる方法がプロジェクト全体からみるとベターなことも多い。単にルールをがんじがらめに守ることを優先するのでなく，全体から判断することをプロジェクトリーダは少なくとも考えて欲しいものである。
ルールは守らなければならない。簡単に破ることは許されない。しかし，時と場合で何が一番ベターかを考えることも大切である。と同時にそのルールの裏にある背景や元来の目的を良く理解して判断して欲しいのである。誰がどのように決めたか知らないがルールだから守らねばいけないと単純にルール最優先にするとそのときの環境や状況によって無駄なロスを発生させることに成りかねない。プロジェクトを成功に導くためのルールであることを忘れてしまってはならない。またルールは作られてから年月が経つと形骸化することもある。時代，場面に合ったプロジェクトを成功に導くためのルールであり，そのためにプロジェクトリーダなるものは，何をどのように考えるかルールの背景にある思想を含めて検討して欲しいものである。
あなたの利用しているルールは形骸化していませんか？
そのルールが作られた目的・背景が伝承されていますか？
プロジェクトを成功に導くためにルールは役立っていますか？
[Reported by H.Nishimura 2009.03.23]
Copyright (C)2009 Hitoshi Nishimura
