メーカー界隈ではよく、
営業とマーケティングの仲が悪い、
開発と品質保証はもめることが多い、
といった、部署間でのもめごとについて聞こえてくることがあります。
僕は、こういった組織的な構造上の軋轢は仕方がないことだと思っています。(トップマネジメントレベルではなく、担当者レベルにおける業務の現場においては特にです。)
それぞれの部門が それぞれの達成目標に向かって仕事をしているわけですし、品質保証は特に、客観的な視点をもって開発・製造部門を評価することがあるからです。
本日は、品質保証としての実体験から、信用できない製品開発の特徴を挙げていきます。
開発部門は品質保証部門の上位互換だと思っている
開発の人の中には、「自分は製品に関する知識があるから、品質保証の業務もできる。」と思っている人がいます。
確かに、開発・設計プロセスを熟知し、製品の特性のこともよく分かっているのは開発部門です。
ですが、品質保証は安全を保証するだけでなく、安心も提供するのがミッションです。
そのために、いろんな人に動いてもらえるよう働きかけをします。
事実だけを集めるのではなく、品質に関して社内やお客さまが安心だと思ってもらえるようなコミュニケーションを図るのが品質保証の仕事です。
このあたりを勘違いしている開発の人は、問題が起きたときに「問題が起きました。原因は分かっているので、後は何とかしてくださいよ」と投げ出してしまうので信用できません。
別に、品質保証を見下してきてもいいのですが、中途半端に品質に関する案件についても勝手に決めてしまう事があるので、「自分は品質管理・品質保証もできる」と思っているような開発担当者には注意が必要です。
QCDのうち、CDしか見ない
Quality、Cost、DeliveryのQCDのうち、Cost(コスト)とDelivery(納期)しか気にしない開発の人もいます。
もっというと、Qは品証の仕事だろ!、と開き直るタイプの人もいます。
こういうタイプの人は、開発中・開発後の製品に品質上の問題が発生した時には、「設計ルールが完全じゃないから問題が起こった」と主張します。
そして、今問題になっている目の前の事案だけでなく、組織上の問題などのすぐに解決できないような抽象的な課題ばかりを問題提起し周りを疲弊させます。
もちろん、個別事象のトラブルシューティングだけでなく、全体的な仕組みの改善は必要なのですが、まずは起こってしまった事象そのものに目を向けないと、原因究明も再発防止もできません。
「品質保証が良いと言ったから」を理由にする
これは上述の「QCDのうちCDしか見ない」に似ていますが、品質上の確認を品質保証部門に丸投げするタイプの開発担当者です。
こういうタイプは、とりあえず「品質保証が良いと言ったからこのスペックでいきます」「品質保証が良いと言ったので、この試験法を採用します」と思考停止状態です。
どういう懸念があったのか考えもせず、伝えもせず、ただ品質保証部門のOKというお墨付きをもらおうとするタイプは要注意です。
品質保証と品質管理をごっちゃに考える
品質保証と品質管理の区別ができておらず(もしくは確信犯的に)、工程管理や製品・サンプルの検査・測定を品質保証に丸投げしてくるタイプの開発担当者です。
挙句の果てに、測定後に「その方法は違う!」なんて言ってきたりするので、無駄な時間を費やさないためにも距離を置いたほうがいいです。
文書作成を怠る
設計・開発したモノのスペックや工程、その他試験結果など、とにかく文書にまとめるのが下手な開発担当者は信用できません。
「文書にまとめない」という行為は、「自分の頭の中で開発が完了していればそれでいい。」という態度です。他の部署へのリスペクトが無い証拠です。
一緒に働く時には要注意です。
ちゃんと文書にまとめ、適切に社内共有できてこそ一流の開発です。
最後に
開発部門は会社の中では花形です。
ですが、からなずしも優秀な人ばかりが集まっているとも限りません。
品質保証は、開発者の力量を見極め、コミュニケーションに注意する、文書化を促す、といった能動的なアクションを取っていきましょう。
もっと品質保証がリスペクトされる日が来ますように。
コメント