ID:84978さん

複雑な帳票・非定型ドキュメントを対象とした文書電子化・データ構造化基盤の開発プロジェクトで、5名チームのPMを担当しました。マネジメント対象は、APIチームとモデル開発チームからなる開発体制、要件定義から運用改善までの進捗と品質、そして品質報告をめぐる顧客との合意形成です。

責務は、OCRの精度という数字を上げることそのものではなく、顧客が業務で使える品質と、それを客観的に判断できる状態を作ることでした。具体的には三点です。第一に、複雑な帳票でも抽出データの品質が担保され、人的確認工数の削減という業務価値につながっていること。第二に、誤認識のパターンを分析でき、どの工程で誤差が生まれているかを切り分けられる状態になっていること。第三に、何をもって成功とするのか、どのデータで検収するのかについて、顧客と開発側が同じ前提に立っていることです。あわせて、APIチームとモデル開発チームが、それぞれの立場ではなく同じ問題を解ける状態を保つことも私の責務でした。

前提として、PMとしての自分の役割は、モデルを直接改善することではなく、各チームが同じ問題を解ける状態を作ることだと考えていました。そのため、要件のヒアリングと仕様策定、データ整合性を考慮したバックエンド設計、進捗と品質の管理を担当しながら、判断の基準そのものをチームと顧客の間で揃えることを重視していました。 最も大きな問題は、顧客から「実際の精度が、こちらの報告している数値ほど出ていない」と指摘されたことです。顧客から見ると、これは単なる精度不足ではなく、私たちが不正確な報告をしているようにも映るため、関係はかなり緊張しました。 ここで私が意識したのは、自分たちの数値を守ったり、モデルの限界を理由に説明したりしないことでした。まず確認すべきは、なぜ双方の評価結果がずれているのかです。調べた結果、顧客は私たちが評価に使っていたデータセットとは別に、独自に用意したデータで精度を測っていることが分かりました。つまり双方は同じ精度について議論しているつもりで、実際には異なる評価データ、異なる基準で測っていたのです。この状態では数値の正しさを議論しても意味がないため、まず評価の前提を揃える必要があると判断しました。 そこで顧客に評価用データの共有を依頼しました。そのデータには、私たちの手元のデータでは十分に表現されていないノイズや実運用上のパターンが含まれている可能性が高いと考えたためです。ここで工夫したのは、そのデータを学習には使わないと明確に約束したことです。顧客の評価データを学習に入れれば、精度の数字は短期的に良く見えますが、それは本当の汎化性能ではなくなり、顧客にとって信頼できる指標でもなくなります。「このデータはノイズ分析と原因特定のためだけに使い、学習には入れません」と説明し、最後まで独立した検証用データとして維持しました。 原因の切り分けにあたっては、精度低下を一つの数字として扱わず、誤認識パターンの分析基盤を構築し、どの工程で誤差が生まれているかを分類しました。その結果、ギャップの主因はモデルそのものではなく、前処理、特にノイズ除去の層にあると特定できました。そこで推測でモデルを再学習するのではなく、影響範囲が明確な前処理を改善するという判断をしました。あわせて、大量データ処理を前提としたパフォーマンス改善も行っています。 結果として、顧客側の評価データに対しても改善が確認でき、かつそのデータは独立したテストセットとして維持できました。人的確認工数の削減を判断軸に置いたことで、精度という数字だけでなく業務価値の面でも効果を説明できるようになり、品質報告に対する信頼を回復できました。 この経験から学んだのは、機械学習を用いるプロジェクトでは、モデル改善そのものと同じくらい、評価基準と検収データの合意が重要だということです。何をもって成功とするのか、どのデータで検収するのかは、開発の後ではなく最初に合意しておくべきだと強く感じました。