思考のサルベージ(その12)

各工程で心がけたい思想を掘り起こしてみる

今回は開発中の製品で見つけた不具合の過去製品への「フィードバック」について考えてみます。 ここでは、現在開発中の商品をPRODUCT-2、過去製品をPRODUCT-1と呼びましょう。PRODUCT-1はすでに客先リリース済みで、PRODUCT-2は開発も終盤でステム試験による不具合検出も落ち着いてきます。

PRODUCT-1の再リリース

PRODUCT-1をリリースした顧客から、今後の開発を踏まえPRODUCT-1に「機能C」を追加しての再リリースを要求されました。断るという選択肢はなかなかないのが現実で、スケジュールをやりくりして「機能C」を追加してシステム試験をやり直し、再度顧客に再リリースすることになります。

PRODUCT-2で検出した不具合

PRODUCT-2は、PRODUCT-1をベースに作った製品です。PRODUCT-2で検出したバグにはPRODUCT-1にそのまま残っているバグがあるかもしれません。「機能C」を追加するとともにPRODUCT-2で実施したバグ対策もPRODUCT-1にフィードバックできれば品質が向上し後の憂いがなくなります。

PRODUCT-1とPRODUCT-2の差分

フィードバックするにはPRODUCT-1とPRODUCT-2の機能差分を明確にする必要があります。 例えば、以下のような機能差分があるとしましょう。

• PRODUCT-2には新規に「機能A」が追加されている
• PRODUCT-1の「機能B」は「規格ver1.0」準拠
• PRODUCT-2の「機能B」は「規格ver2.0」準拠

「機能A」についてはPRODUCT-2の独自仕様なのでこれに関するバグ対策はPRODUCT-1へのフィードバックは不要と判断できます。「機能B」についてはちょっと注意が必要で、「規格ver2.0」固有の部分についてのバグ対策はフィードバック不要ですが、「規格ver1.0」「規格ver2.0」共通部分のバグ対策については要フィードバックとしなければなりません。 まとめるとフィードバックが必要なのは以下のようにまとめられます。

• 「機能B」の「規格ver1.0」と「規格ver2.0」の共通部分のバグ対策
• 「機能A」を除いたその他のバグ対策

フィードバック

どこの現場でもたいてい便利なバージョン管理システムや不具合管理システムを連携させて使っているので、どのヴァージョンでどんなをバグ対策をしたか履歴を見れば一目でわかるでしょう。要フィードバックの条件に合致する対策をPRODUCT-1に取り込んでいけばよいだけです。

PRODUCT-1に「機能C」を取り込み、要フィードバックな対策もすべて入れました。フィードバック項目はすべてPRODUCT-2のシステム試験で検証済みなので、再リリース向けPRODUCT-1のシステム試験は「機能C」関連以外はすんなり通るはずでしたが、「機能B」の「規格ver1.0」と「規格ver2.0」の共通部分で引っかかってしまいました。

ちゃんと運用できていますか？

こういうことでした。

PRODUCT-2のシステム試験で「規格ver2.0準拠の機能B」で処理速度が遅いという不具合がありました。処理性能の改善ということで、様々なトライアルをして幾度も評価を繰り返していくうちにいくつかバグが見つかりました。これらのバグが全て「「規格ver2.0準拠の機能B」で処理速度が遅い」という不具合として一括でバージョン管理システムにも不具合管理システムにも登録されていました。その中に1件、「規格ver1.0」「規格ver2.0」共通部分のバグが埋もれていました。正しくは、処理速度の不具合とは別に不具合登録され、別バージョンで対応すべきでした。

何か掘り起こせた？

• 運用ルールを明確に。
• 不具合登録、対策は手間がかかっても各事案ごとに。

せっかく便利なツールあるのに、運用が正しくなかったがために余計な工数を費やすという結果を招きました。今かける手間暇は、近い未来の手間暇を省いてくれる投資みたいなもんですね。

おしまい

でも時々あるんですよね、システム試験チームも設計チームも誰一人、正常な判断能力を失ってしまっている時って。