■仕組みで解決できるのか？ ４（No.175）
仕組みやプロセスで再発防止を図るようしたと云うのが一般解であるが，本当にそうなのか？と云う疑問から，課題提起をしている。
事実関係
前回までは仕組みやプロセスの問題ではなく，コミュニケーションの問題としたが，事実関係をもう一度振り返ってみる。
市場問題を再発させないように取り組んだプロジェクトだったが，最後のところで詰めが甘く，市場問題の歯止めが掛かっておらず，出荷を遅らせてしまったことが一つの事実である。その要因として，開発部門と品質保証部門の間でコミュニケーションが不足していたため，市場問題を再発させないようにと新製品を予め評価して，開発にフィードバックしたが，開発はそれどころではなく，他のことに精一杯で，出荷までにそれらの評価結果のフィードバックを十分していなかったことがもう一つの事実である。
振り返り
これらに関して，トップから今回の問題を振り返るように指示が出ていた。これが，最初の課題であり，初回に述べたのは，振り返りとなると，すぐさま仕組みやプロセスに落とし込もうとするやり方そのものを課題提起したのである。
結果的に振り返りで話題になったのは，最初の計画自体の問題や，バグの扱い方のプロセスを遵守しないまま出荷しようとした問題，或いはシステムとしての品質保証が不十分だった問題，などで，それらはよくよく見ると，すべて自分たち目の前の問題ばかりで，中には本当に瑣末な開発者自身の問題も含まれている。これは，振り返り自体のやり方の問題で，トップが振り返りをしろと云われていることと，メンバーの開発者が考えていることに大きなギャップがある。それをメンバー全員で振り返ろうとするからこうしたことになってしまうのである。むしろ，今回の上述した事実に焦点を当てて，責任者もしくは当事者が振り返りをすれば，振り返りの焦点が発散せず，絞られたものになったかも知れない。
それよりも，こうした顧客との接点に近い問題に対して，顧客に対する振り返りが誰一人として一言も出てこなかったことに驚いた。
顧客認識の度合い
今回の事実は上述したように，品質保証部門の評価結果の裁定，及びその対応に時間を取り，出荷が遅れたことである。つまり，最初に振り返りしなければいけないことは，顧客にどれだけ迷惑を掛けたのか，また，出荷を遅らせてまで対応した品質保証部門の評価対応でどれだけ顧客に迷惑を掛けずに済んだのか，である。「顧客重視」「顧客本位」とは，そうしたことではないか？
こうした質問をしてみたところ，関係者全員がキョトンとしている。全く，考えもしなかったことをいきなり言われたと云う感じ方である。つまり，トップから振り返りをと言われたことをすぐさま自分たちの仕組みやプロセスにつなげようとしている思考プロセスが見える。トップの振り返りの思いがどうだったかは知る由もないが，少なくとも私ならば，顧客のことを考えたと云うことである。
また，事実関係をよくよく見てみると，そこには顧客認識の度合いに大きな差が見られる。「顧客重視」「顧客本位」などよく耳にする言葉である。今回の開発の計画を見ても，，前機種の市場問題を振り返って，同じようなことが起こらないようにと開発計画に高々と謳っている。そして，設計する時点ではそうした再発防止の考え方を採り入れて設計をしている。
そのドキュメントだけを見ると顧客認識があるかのように見えるが，実際は全く逆で，開発者に顧客の姿が全く見えていない。腹落ちした「顧客重視」「顧客本位」には全くなっていないのが，リーダ含む関係者全員の意識である。だから，振り返りをしても，市場に迷惑を掛けた感覚の欠如しているので，振り返りに一言も出てこないのは当然である。
また，今回品質保証部門が再発防止をしないように開発とは違った角度で評価をしていたが，正式な評価との意識は薄く，エクストラ的な評価をやっていた程度の意識だったので，その対応の真剣さもなかったと思われる。つまり，今回の問題の根源は，リーダ含む開発関係者全員の「顧客認識の希薄さ」にあるのではないか。
コミュニケーションの問題も，顧客認識が十分だったら，品質保証部門の評価結果を否応でも，気にしなければならなかっただろうし，そうすれば，当然コミュニケーションを図る必要も出ていただろうし，お互いが，出荷までにどうしようかと相談もできていた筈である。今回，開発側と品質保証部門と顧客認識の度合いが違っていた。現に，品質保証部門は前機種で顧客に迷惑を掛けたので，再発防止をしたい思いから評価をしたはずである。一方，開発側は，顧客との距離が遠い。つまり，計画書に再発防止を謳い，設計の部分では盛り込みはされたようだが，常に顧客認識があったかと云えばそうとは見られない行動がある。
「顧客重視」「顧客本位」とは，あなたにとってどんなことですか？
顧客が見えていますか？
[Reported by H.Nishimura 2010.06.28]
Copyright (C)2010 Hitoshi Nishimura
