オフショア開発技術者と品質分析

私がいた会社では、テストが終わると必ず摘出した不良を分析して、品質見解としてまとめていました。
テストでの品質が悪い場合は、分析結果をもとにして品質見直しを実施することが義務付けられていました。
品質が良好な場合でも、弱いところを洗い出し、プロセス改善に役立てていました。

品質分析結果、とくに残存バグの予想は外れることも多く、品質見直しをしながら方向転換を行っていかなければなりません。
そのため、より現場に近いところで分析をまとめる必要があり、作業を外注した場合は、発注先に作ってもらうのが通例でした。
作業をオフショア開発に発注した場合には、発注先のＰＭに作ってもらうわけです。

発注先が日本国内の場合でも、最初に品質見解を作ってもらうのは大変でした。
何度も作り直してもらって、その度に記述内容を指導するのは当たり前だったからです。

でも、オフショア開発の発注先に品質見解を作ってもらうのは、予想以上に骨が折れました。

最初の品質見解は１行だけだった

他のプロジェクトの例を渡して、品質見解の作成を依頼しました。
作業の開始前だったせいか、大して気にしていなかったようで、とくに嫌な顔をされることもなく、快く引き受けてもらえました。

そして、オフショア開発側のＰＭに作業完了間際に改めて品質見解の作成を依頼しました。
すると作業開始前とは打って変わって「そんな話は聞いていない」と言い出しました。

でも、このような対応は慣れていました。
契約書と議事録を見せて「品質見解は納品物に入っていますよね」と言うと、ＰＭは渋々納得しました。
そしてＰＭは「何を書けば良いのですか」と聞いてきましたが、やり取りに少し腹を立てていた私は「例を渡してあるので、まずそれを見てください」と答えました。

翌日、品質見解がメールで送られてきました。
もう少し手間取るものと思っていたので、意外と優秀なのかもしれないと考えながら添付ファイルを開くと、「品質に問題ありません」と１行だけ記述されていました。

早速ＴＶ会議を開きました。

私　「品質に問題がない根拠がまったく書かれていません。」
ＰＭ「どのように書けば良いのか分かりませんでした。」
私　「様式に、種類別の不良の数などを記載する場所があるので、それを記入して問題がないか考えてください。」
ＰＭ「分かりました。」

何度作り直してもらっても改善されない

翌日、修正版が送られてきました。
不良件数などは記載されていますが、その値は分析には何も使われていませんでした。
その旨を指摘すると、すぐに修正版を送ってくるのですが、こちらの意図はまったく伝わっていません。

このままでは埒があかないと考えた私は、ＴＶ会議でひとつひとつ品質見解の作成方法を説明していきました。
それまでにもらった情報から、不良のありそうな箇所まで教えてあげました。

これである程度のものは出てくるかと思っていたのですが、次の修正版もあまり代わり映えがしないものでした。

結局、時間切れとなり、私が作成したものを社内で報告しました。
ただし、品質見直しについては、こちらの指示に全面的に従ってもらいました。

それから別のプロジェクトで、何度も品質見解を作ってもらいましたが、あまり改善は行えませんでした。
自律的に品質改善を行っていく組織になってもらうため、それなりに手間を掛けたつもりでしたが、効果はありませんでした。

品質分析は、自分たちに考えさせるために、社内でもマニュアルや手引きはあえて作っていません。
マニュアルがあると、安易にそれを真似してしまい、考えるのをそこで止めてしまうからです。

そのため、技術の継承が属人的になり、オフショア開発で実施した際にとても苦労することになりました。
実は、同じようなことは程度の差はあれ国内でも起きていることなので、真似だけで留まってしまうリスクはあるにしても、ドキュメント化が必要ではないかと考えています。