自社の既存製品(機能)の品質不良における現場としての事前の策について
昨日、ボソッとつぶやいたんですわ。
そうしたら、味わい深い流れになったのでちょっと流れを。
@Mentions が返ってくるのはちょっとうれしい。小市民ですねぇ、ワタシ。
「@a0tsukey マジレスすると既存製品とこっちの修正範囲を線引きする→既存製品不良は既存製品調達者が品質コントロール(修正要求等)する、だけど、自社が既存製品提案しているとツライ… 」
質問の前提がわからなかったので既存製品の製品を他社製品と仮定して折り返すことに。
この仮定を設定するまでに逡巡したことは、品質不良の起因はだれがボールを握っているかと言う点です。提案書の役割分担のお客さまと開発側のどっちに○が書かれているか。
表1 開発チームがライセンス調達するケース
作業内容 お客さま 開発チーム 既存製品の調達 − ○
開発チームがライセンスから調達して納入する場合は表1になります。この既存製品が他社製品であれば、製品不良の問題解決のボールは開発チームが握ることになります。
もちろん、不良の改善は他社製品ですから製品ベンダに対応させます。ただ、開発スケジュールに支障が出る場合は、製品不良を回避する設計とするか、運用対処をお客さまと合意するプロセスが必要になります。
表2 お客さまがライセンスを調達するケース
作業内容 お客さま 開発チーム 既存製品の調達 ○ −
ライセンスはお客様が調達する場合は、製品ベンダの窓口はお客さまになります。この場合、問い合わせをしたい開発側と製品ベンダの間にワンクッション入ることなり、タイムリーに問題解決が進まなくなる可能性があるので、課題解決のそれはお客様のライセンスを借用して代行するケースが多いのではないでしょうか。
先のmensionでは、いったん、「既存製品とは開発チームから見て他社製品である」と定義してmensionを返したところ…。
お、おう…。既存製品は他社製品ではなかったのか…。しかも、ゼロベースで、作った人がいない、ドキュメントもないというトリプルコンボ！！！
当然、哀悼の意を述べるほかないわけで。
会話には共感が大切です。以前にみききしたことを抽象化してmensionします。
ここで、mensionはおわります。…のフェードアウト感が哀愁を深くします。「(以前より…)」の括弧書きは現在の状況を受け入れたくない心情を表現されていているようで一層の深みを作っています。
自社の既存製品(機能)の品質不良における現場としての事前の策について
じゃあ、このような「自社」の既存製品の品質不良に直面したときの取れる対処にはどのようなものがあるのでしょうか。
組織としては、「品質を使えるレベルに何とかしろ」としか言わないでしょう。だって、自社の製品だから。対外的に抗弁できないですもん。まぁ、対外的には品質不良を含めて「仕様です」と言うのが常套句でしょうけど。
それで時間を確保して、適当なタイミングで機能改善と言うなのバグフィックスを出すわけで。
で、それをやる現場は荒廃した環境下で何とかしなければならない、というか「なんとなして！」と半ば懇願されるわけです。間違ってここで「わかりました」なんていったら、それまでの「既存製品の品質不良」は負の遺産相続と同じとして引き継がれますのでご了承ください。
じゃあ、「どうすんの」っていう感じですが、そうですね、ゴール設定するほかないですね。ざっくり調査して、見極めて、間違っているかもしれないけれど、ここまで品質レベルを確保するのに必要な時間とコストを。
それを記録に残るように体面で合意するんでしょうねぇ。腹を括って。
ただ、記録に残しても自社のこのなので有耶無耶になっちゃうかもしれませんけど。
