■開発現場より ６ （進捗管理のマイルストーン） （No.264）
製品開発の現場でのいろいろな問題点について考えてみることにする。（続き）
マイルストーンとは
行程の長いプロジェクトには，マイルストーンなる中間目標が設定される。これは，最終目標には，現状とのギャップが大きく，どのように目標達成するかが不明瞭で，それを解消させる意味で，途中で達成すべき中間目標（もちろん，１カ所でなく，何カ所も）を定め，先ずは最初の中間目標の達成を目指そうとするもので，マイルストーンはこのような形で設定され利用される。
新製品開発などを担当している技術者は，各々の職場に新製品の開発管理規程なるものがあって活用されて居る人も多いと思われる。ただ，中小の企業では，ベテランの技術者が張り付いていて，その人の頭の中に規程のようなものが存在しているようなケースもある。要は，新製品開発をする工程に於いて，最終目標を必達するために，ある時点で，どのような検討を済ませておくべきかを定めたものである。品質確保のためにDR（デザイン・レビュー）との名称が付けられていることも多い。
製品が完成するまでには，企画〜開発〜設計〜量産設計〜製造と云うような工程を経ることが一般的である。製品の特徴や過去の経験から各社によって多少の違いはあるが，上記のような工程，つまり企画段階ではどのような検討を済ませ，次の開発段階に移行し，そこでは開発の検討をするなどと順次完成度を高めながら工程を進む。したがって，企画段階で検討しておくべきことは開発工程に入る前に終えておかなければ，検討項目が後へとズレ，完成日程に影響を及ぼすリスクが発生する。
そうしたことが無いように，企画段階を終えたタイミングにＤＲ（デザイン・レビュー）を設定して，関係者で確認しあう場がある。これがマイルストーンの一つであり，各工程を終えた時点に同様のＤＲが設けられるのである。このマイルストーンのＤＲで何をするかと云えば，やるべきと定められたことのチェックで，抜け漏れがないかどうかを判定する。不十分な場合は，いついつまでに再検討を加える。また，ＤＲには上司を始め，有識者や経験者など衆知の知恵を集めて検討をする場でもある。過去に問題があったことに対して再発防止が図れていつか否かも一つの重要な視点である。
マイルストーンに対する意識
これまでの経験では，マイルストーンに対するリーダの意識に問題があることが多い。つまり，新製品開発管理規程など規則で定められていると，その作られた経緯は知らない人が多く，ただ開発過程の関門で，如何にくぐり抜けるか，要は邪魔なもの（リーダ本人はそうは言わないが）と思っている人が居る。衆知を集める良い機会，先輩から助言を貰える機会だと歓迎するようなリーダは少ない。
それはその企業のＤＲのやり方そのものにも問題があって，要は裁判ではないが，開発しているメンバーを被疑者のような目であら探しをするようなことが横行しているケースである。特に，ＤＲの事務局などかっちりした仕組みのある企業では，計画通りにＤＲを実施することが仕事である人がいて，内容ではなくＤＲをやった実績が評価になるような組織になっている。そうなると開発リーダはＤＲが被告席に立たされているような気持になり，如何その関門をにくぐり抜けるかを考えるようになってしまう。これは本末転倒の事態である。そこまで酷い例は少ないかもしれないが，これまでの経験上では開発リーダに，少なからず上述した意識があることは厳然たる事実である。
なぜこのような事態が起こるのか？それは，最終目標に対してより良い品質の優れた製品を顧客に届けたい気持は誰にもあり，まして開発リーダならば，自分の作った製品が世の中にどれだけ貢献できるか，ヒット商品になるかどうかに関心が無いと云ったらウソである。そのために，いろいろな人の意見を参考にしながら，協力を得ながら開発を進めたいと思っている。ところが，主旨はそのようなＤＲであっても，重箱の隅をつつくような指摘や，形式書類のチェックに明け暮れるような，開発に協力してくれているとは思えない場面を想定すれば，如何に問題なく済ませたいと思うのは人情的にも当然である。
もちろん，開発リーダの意識事態の問題もある。上司や先輩諸氏の暖かい助言も素直に受けとめられず，開発を困難にするだけの指摘に過ぎないと受けとめる未熟な開発リーダも結構多い。そこまで余裕が無いことも事実である。つまり，時間が十分あれば検討できることも，時間の制約の中で頑張っている。それなのに外部から理想論を以て，いろいろ指摘されるとそのこと自体は尤もなことなので反論ができない。だが，実態はそんな理想的なことまでやっている余裕などさらさら無い。指摘された内容のどこまでを取り込み，それ以上を参考に聞く程度に止めるかは，議論の場でその重要性から決めればよいが，最終的には開発リーダの判断である。
また，こんなケースもある。マイルストーンは一つの関門になっている場合，その関門をパスする必要条件として，幾つかのチェック項目をクリアしなければならない。ところが，開発内容によっては，すべてをクリアしようとすると，最終完成品に近い完成度を待たないとクリアできないケースが出てくる。そうするとどういったことが起こるかと云うと，本来実施されるべきタイミングのＤＲが，どんどん後へズレ，後半工程でチェック項目をクリアするためのＤＲになるケースがある。それは拙いと指摘しても，平気な顔でルール上，チェック項目をクリアできないのでＤＲができませんと答える開発リーダが殆どである。
確かにルール上，この時点のＤＲでは，チェック項目をクリアしていることと定められている。クリアしないとＤＲがパスしないことも事実である。これを盾に，ＤＲを先延ばしてしまうのは，本来のＤＲの主旨を曲げた解釈である。もちろん，１，２週間程度の都合の遅れではなく，１，２カ月も遅らせるケースのことである。多分，ＤＲの主旨に規程では開発工程のどのようなタイミングで，どのようなことを吟味するか書かれている。そのために付帯項目として，このようなことができていなければならないとチェック項目などがある。このチェック項目が殆どできていないようであれば無理に予定日が来たから実施するというのはあり得ないが，逆に，１，２項目のみクリアできないが他はクリアできて，ＤＲの主旨は満足できる工程を経ているとあればＤＲは実施すべきである。その方が全体から見れば，より良い結果をもたらすのは明らかである。
技術者は真面目な人が多く，ルール上決められたものがあると，それを確実に遵守しなければならないと考える。それは正しいことである。ただ，本来の主旨がどうかとそれに照らし合わせた判断をする度量まで備わっているかと云うといささか覚束なくなる。不十分で指摘されるより完璧なものを求め，それで以てＤＲを受審する気持はよく判る。しかし，ＤＲでの完成度をとるか，完成品での完成度を取るかと云えば当然後者であることは自明である。開発リーダになった人は，本来のマイルストーンの主旨から判断する意識をもって貰いたいと願っている。
（続く）
マイルストーンの主旨をよく理解して判断しよう！！
[Reported by H.Nishimura 2012.04.02]
Copyright (C)2012 Hitoshi Nishimura
