■生産性向上策 ５ （No.164）
開発のプロセスには必ずデザインレビューがある。呼び名は，会社によって違いはあるが，開発プロセスの過程において，この時点ではこれだけのことが出来ていなければ，最終到達点に上手くミートせず，延長になるか，或いは中途半端な品質で市場に投入するハメになってしまうと云う，チェックすべきポイントが必ずある。経験上，開発プロセスの中で，こうしたデザインレビューのチェックポイントが設定されているのが一般的で，ＩＳＯでもこうしたポイントを謳っている。
こうしたデザインレビューでは，一般的には，開発者は上位のマネジャから，或いは経験を積んでいるステークフォルダ（利害関係者）から，いろいろな角度から，ＱＣＤはもちろん，質問を投げかけられる。それらの質問は，最終到達点に上手く到達できる見通しがなかなか立たないときには，かなり厳しい質問，或いは，叱咤激励の文言が投げかけられる。開発者は，こうした質問に，的確に，且つ前向きに応えなければならない。
品質が大丈夫か，計画通りの日程で進んでいるか，などが一番のポイントであり，これらに関しては，開発者も十分意識して，開発を進めているので，計画通りに進んでいない場合でも，事前に十分認識していて，その挽回策や対応策を検討している。もちろん，それでも品質が極端に悪いとか，スケジュールが大幅に遅れているなどプロジェクトとして成り立っていない場合は，上位より手助け，或いは指導がなされる。
ところが，こと生産性に関してはなかなか，開発者，或いはリーダでも関心が，品質や納期ほどシビアではない。効率良く開発を行うことは認識していても，その見方はまだまだ不十分なことが多い。プロジェクトマネジメントがある程度のレベルになってくると，生産性向上策など，経営に貢献する内容の質疑も活発になってくる。
ところが，経営面では不慣れなリーダでは，指摘内容のポイントが十分把握できていないことが良くある。つまり，前述した管理工数が過剰になっている点や，品質などできるだけ前工程で確実な品質確保が出来ている方が，後工程で品質確保するより，工数的に有利で経営的にも全体の工数削減ができるとされている。こうした，やりとりがデザインレビューでなされ，開発側に指摘内容として示されるが，経営に不慣れなリーダなどでは，表現された言葉そのものをすべてと理解してしまっている。
例えば，管理工数を減らせと云われれば，本来やるべきことは何かと云う考えに戻って吟味するのでなく，数字合わせで工数さえ減れば良いのだと理解してしまう。生産性向上とはこうした数値で示すことの重要性はあるが，単に数字の遊びをすることではない。付加価値として十分な成果を付けたかどうか，である。
特に，リーダなどデザインレビューを受ける側は，部長など経営者の言葉尻でなく，なぜこうした指摘をされているのか，その背景は何か，本質的なものは何か，を十分考えることが大切である。少なくとも，経営者は品質，納期など個々の内容は各々違っても，究極的には経営に如何に貢献するかの観点で指摘されているはずである。もう一度，指摘内容を振り返って考えてみることは，経営的な視点を養う上で大切なことである。
デザインレビューの究極の生産性向上策は，ムダなプロジェクトを途中でストップさせることである。一度やりだしたから，折角なので技術蓄積の観点で最後までやりたい，と続けることがよくある。これが一番生産性にとってはマイナスである。デザインレビューには，こうしたプロジェクトを止める，機能も備えておきたいものである。もちろん，開発のリーダが自ら言い出すのは難しいので，これは承認者である経営者の判断，つまり決裁権を持たせておくべきである。
経営者からの指摘内容を十分理解できていますか？
プロジェクトをストップさせる機能が開発プロセスにありますか？
[Reported by H.Nishimura 2010.04.12]
Copyright (C)2010 Hitoshi Nishimura
