|
イギリスやドイツのことは情報が少なくてよく分からないが、少なくとも米国の、「事業性が優先、品質は後から付いて来る」風の考え方は品質にこだわる日本人には馴染まない。
---
米国ではソフトウェア開発なども、「作業」と考えている風がある。従って、品質を上げるに
(1)作業プロセス
にこだわる。ソフトウェア工学、手法、方法論といった類である。
日本人は昔から体質的に、常識的に取り組んでいるもので、目新しくもない(体系化していないので、無能な経営者はそれに振り回されているが・・・)。
しかし、品質のよいものを作りにはこれではまるで不足している。
日本人が巧くやれていないのは、
(2)まず、信頼できる現場リーダからアサインせよ(不適性事項の排除))
優秀な現場リーダは、レビューや面接で、不適性者、初心者はスグに見抜ける。プロジェクトの危険度はスグに分かる。
しかしながら、多くの場合排除が遅れる。現場リーダは後からアサインされる。従って、プロジェクト計画、人事、営業など殆んどの権限を奪われた状態からスタートしてしまう。
※初期の不具合を上司が「本当に」知りたいのであれば、現場リーダの打合せ議事録、レビュー記録などからサブシステム、モジュールごとに、「くだらない議論」「重たい議論」をカウントして比較すればよい。「くだらない議論」が多い部分は「担当者」を早期に入れ替えるように手を打つこと(しかしを先送りにしたい上司が多いのだから、絶対に実施されないが)。
(3)責任(=権限)明確
日本人は気持ちで頑張るところがある。×を付けられることを神経質に嫌う。その代償として、個人の成果を --- 上司も現場リーダも --- 見えにくくして来た。評価されないことによって、3K現場になってしまった。
米国的ではあるが、ここは上司と「現場リーダ」に契約的センスを持ちこむ必要がある。
例えば、
・あるプロジェクトにおいて「目的、期間、経費」がある一定のズレの範囲である限りは上司は一切現場に口を出さない(人事権、営業権も含めて)こと。
=責任(=権限)のシンプル化、明確化
成功すれば、純粋に「現場リーダ」成果として、プライドを満たす方法で賞賛すればよい。失敗すれば厳しい×成果に不満をいうものはいないはずだ。
・責任と権限の一致化
任せた範囲で巧くやっているのなら、いくら気になっても現場にいって口を出すようなことをするべきでない(そんなら自分で現場リーダをやればいい)。
例えば、上司が「オレが責任を取るからやれ」という。しかし、責任=権限であるから、本当にそうなら現場リーダは自由を奪われてしまう。紛らわしいことを言わず「外部やマスコミ対応はオレがやる」と言えばよい。失敗すればどうせ評価は×にするのだろうから。
|