制作会社の手戻り：どの修正から調べるべきか

制作会社の手戻りを測るには、すでに合意した内容を満たすために、やり直しが必要になった修正から始めます。費やした分数を記録し、何が要件を満たさなかったのかで分類し、発生源を調べる手がかりになる証拠を残します。長時間かかる三件の修正は、短い四件の修正より多くの工数を使うかもしれません。レビューをもう一段階増やす前に、この違いを押さえることが大切です。

制作会社では、合意済みの見積書に定めた作業（英語のガイド）が比較の基準になります。

以下の記録は、この判断を練習するためのものです。十五の事例とその証拠はすべて架空であり、実在の顧客、Frihetチームの生産性、業界の標準的な比率を示すものではありません。

不具合を判断するには基準が必要

合意済みの仕様が1200 × 628ピクセルを求めていたなら、1080 × 1080ピクセルの画像は依頼の要件を満たしません。一方、予定されたレビューで、どちらも要件を満たす二つの構成案を試すのは別の活動です。技法を学ぶためにプロトタイプを作り直すことや、新たに依頼された追加フォーマットを用意することも同様です。

この区別により、繰り返しをすべて無駄と見なすのを避けられます。制作前にどの要件が合意されていたのかを特定できない場合は、分類を保留してください。後から生じた好みを、制作した人のミスとして扱ってはいけません。

ASQの品質コストの枠組みは、予防、評価、内部失敗、外部失敗を区別しています。納品前に発見した誤りの手直しは、内部失敗に含まれます。ここでは、その区別を使って分析対象の修正を選びます。この記録は品質コストの総額を計算するものではなく、ASQが制作会社向けに用意した専用の手法でもありません。

十五の社内事例を記録する

各行には、その事例の作業に実際に取り組んだ分数を記録し、待ち時間は含めません。単位は人・分です。二人がそれぞれ十分間作業すれば、合計は二十人・分になります。同じ問題が複数の段階で見つかっても、同じ工数を重複して数えないでください。通常の点検時間と原因調査の時間は別に記録し、修正の分数には加えません。どの事例も、納品前に問題が発見されたもの、または実施が決まった活動です。この記録は学習用に選んだ事例集であり、ある期間に制作会社が行った仕事のすべてを含んではいません。

十件の修正は合計450人・分です。予定されたレビューは105人・分、試行は120人・分、追加フォーマットは90人・分で、記録全体の合計は765人・分になります。不具合の分析から除外した五つの活動は合計315人・分ですが、これらも仕事です。別のラベルをつけても、プロジェクトの実際の作業時間から消えるわけではありません。

450を765で割れば、この選ばれた記録の内訳を表せます。しかし、ほかの制作時間が含まれていないため、会社全体の手戻り率にはなりません。ここには売上、時間当たりのコスト、利益率の情報もありません。結果を金額に換算すれば、存在しない情報を作り出すことになります。

三件の書き出し修正は、四件のバージョン修正より重い

工数を基準に調べる問題を選ぶため、十件の修正だけをグループにまとめます。比率の分母は450人・分です。次の表は工数の多い順に並べてあり、時間を基準とするパレート図の土台になります。

最初の行の計算は 270 / 450 × 100 = 60% です。累積比率は丸める前の作業時間（分）から計算し、百分率は小数点以下二桁で表示しています。結果が80/20の比率に従う必要はありません。

件数を数えるなら、バージョンの誤りが四件で、寸法の誤りの三件を上回ります。分数を合計するなら、寸法の誤りが270人・分で、バージョンの誤りの75人・分より先になります。どちらの順位も原因を説明するものではなく、異なる問いに答えています。ASQのパレート分析の手順では、頻度、時間、その他の尺度を選び、大きい順に並べられます。尺度の選択も判断の一部です。

ここで注目するのは記録された工数ですが、それだけであらゆる問題の優先順位を決めるべきではありません。発生頻度が低くても、納品を妨げる不具合には対応が必要です。修正が短時間で済む場合も同じです。この例では重大さやリスクにさらされる度合いを測っていないため、それらを軽視する根拠には使わないでください。

観察できたことは、まだ原因ではない

E01で分かっているのは、出力の寸法が誤っていることです。「誤ったプリセットを選んだ」は仮説です。また、「納品前のチェックで見つかった」は発見した段階を示すもので、問題がどこで入り込んだかを示すものではありません。

この事例を調べるなら、合意済みの仕様、実際に使った設定、出力ファイル、バージョンの順序を残します。ASQの根本原因分析の説明では、証拠を集め、出来事をたどり直すアプローチが紹介されています。症状を原因のように言い換えるだけでは、その作業を行ったことにはなりません。

E01の架空の検証では、仕様F01は1200 × 628を要求し、設定F02には正しいプリセットが記録されています。それでも出力F03は1080 × 1080です。実行履歴F04は、処理がキャッシュ内の古いテンプレートを使ったことを示しています。F05は、現在のテンプレートを使い、プリセットは変えずに再実行し、予定どおりの寸法になったという場面を表します。

これらの証拠は学習用シナリオの一部であり、実際にアプリケーションを動かした結果や、制作会社で実施した実験ではありません。このシナリオの中では、誰かが手動で誤ったプリセットを選んだという説明を否定し、古いテンプレートの使用を調べる根拠になります。E02とE03にも同じ発生源があると証明したわけではありません。 症状が共通しているだけでは不十分です。両事例の設定と実行履歴は、まだ確認する必要があります。

次の確認を準備する

役立つ記録には、IDと分数に加えて、合意済みの要件、観察された問題、発見した段階、仮説、不足している証拠を残します。そうすれば、具体的な事例に戻って確認できます。検証できる内容を示していないのなら、「不注意」「コミュニケーション不足」といったラベルは避けてください。

この記録から正当化できる判断は、プリセットの研修を勧めたり、工程全体を変えたりする前に、E02とE03の証拠を調べることです。270人・分をすべて取り戻せるという約束ではありません。どの部分を回避できるのか、工程の修正にどれだけ工数がかかるのか、別の不具合が生じるのかは、この記録からは分かりません。

一貫した方法で観察できる期間と成果物の種類を決めて始めてください。まだ分類できない事例も残しておきます。最初に目指す成果は小さく、具体的です。優先して調べる問題、仮説として明示した説明、そしてその仮説を採用するか退けるかを判断するために次に必要な証拠です。