【ITニュース解説】The hardest label in our dataset is the one where nothing happened

IT企業が公表する将来の目標や計画、例えば「ある目標マージンを達成する」「新工場を稼働させる」「特定の成長率を維持する」といった「コミットメント」は、通常、決算説明会の場で発表され、記録に残る。しかし、これらのコミットメントが実際にその後どうなったのか、つまり達成されたのか、見送られたのか、あるいは言及されなくなったのかを追跡し、記録している企業はほとんどいないのが現状だ。

この記事は、このような企業の将来への約束を追跡し、その結果を明らかにするシステムを構築する中で直面した、データモデリングやデータ分析における興味深い課題と教訓について述べている。

私たちはインドの上場企業を対象に、数千に及ぶ決算説明会の記録（トランスクリプト）から、約2万4千件の将来のコミットメントを抽出し、データベースに蓄積した。そして、その一つ一つのコミットメントについて、後続の決算説明会で何が語られたかを分析し、その現在の状態を示す「結果（verdict）」を付けている。

このプロジェクトの真のエンジニアリングの難しさは、コミットメントをトランスクリプトから抽出すること自体にはなかった。これは比較的解決済みの問題である。最も興味深く、かつ困難だったのは、コミットメントの結果が「まだ存在しない未来のドキュメント」の中にあり、しかもその結果の最も一般的な失敗パターンが「間違った値」ではなく「何も起こらなかった（＝何も言及されなかった）」という状態だった点である。この特殊な状況が、データモデルの設計やそこから算出されるあらゆる指標に大きな影響を与えた。

まず、当初考えがちなデータモデルは、トランスクリプト（決算説明会1回分）を単位として、そこから複数のコミットメントが生まれるという形だ。しかし、これでは「あの時言われたコミットメントがどうなったか」という最も重要な問いに答えられない。なぜなら、その結果は次の、あるいはさらにその先の決算説明会で判明するからだ。したがって、このシステムの単位は「コミットメント」そのものであり、それは複数の決算説明会にわたる「ライフサイクル」を持つものとして設計する必要があった。

各コミットメントには、ID、どの会社のものか、最初に言及された決算説明会、内容、目標値、期間、そして現在の「結果（verdict）」、最後に評価された決算説明会が記録される。その後、同じ会社の決算説明会が行われるたびに、未解決のコミットメントについて言及がないかを確認し、あればその内容に基づいて「結果」を更新する。このプロセスは、単なる分類ではなく、時間軸に沿った記録の連結作業となる。

この「結果」の定義もまた複雑だった。当初は達成か未達成かの二択で考えがちだが、実際には「新規」「順調」「達成」「未達成」「放置」「危険」「遅延」「下方修正」「上方修正」など、12種類もの状態が存在した。例えば「上方修正」は、会社が目標値を引き上げて、さらにその高い目標を達成した状態だ。これを「達成」と見なすか、「下方修正」された目標を達成した場合はどうか、といった判断は、集計する側の定義に大きく依存する。これらの詳細な結果から「達成率」のような単一の数字を算出する際には、どの結果を「達成」と見なすか、というマッピングのルールを明確に定義し、公開することが不可欠である。定義と実際の計算ロジックが乖離すると、誤解を生む原因となることを私たちは経験から学んだ。私たちのシステムでは、達成率を計算する際に「達成」「目標希薄化後達成」「順調」「上方修正後達成」のコミットメントを「達成」とみなし、約57.8%という数字を算出している。

このプロジェクトで特に興味深く、また危険な側面となったのが「ghosted（放置された）」という結果である。これは、ある決算説明会で発表されたコミットメントが、その後のいかなる決算説明会でも一切言及されなかった状態を指す。「達成」でもなく「未達成」でもなく、単に会社の語りの中から消え去ってしまった状態だ。

この「放置」という不在を示すラベルは、私たちが無意識のうちに持っていた3つの前提を打ち破った。第一に、これは「私たちのデータソース（決算説明会のトランスクリプト）において言及されなかった」という事実を述べているのであって、「世の中でそのコミットメントが全く扱われなかった」ことを意味しない点だ。企業はプレスリリースや他のイベントで言及している可能性があり、私たちのシステムが捕捉できていないだけかもしれない。したがって、このような不在を示すラベルは、その「観察範囲」を明確に記述すべきであり、できれば列名自体にも「後続の決算説明会で言及されなかった（当社のデータソースにおいて）」のように含めるべきである。第二に、「放置」はコミットメントの追跡・連結の「検出失敗」によっても生じる可能性がある点だ。もしシステムが後続の決算説明会で該当するコミットメントを見つけ損ねた場合、それは「放置」と誤って分類されてしまう。これは「値が欠損している」のではなく、「自信満々に間違った結果」を生成するため、非常に厄介なバグとなる。そして第三に、「放置」という結果は、十分な数の後続の決算説明会が存在しないと計算できない点だ。新しく発表されたばかりのコミットメントは、まだ「放置」される機会がないからである。

この「放置」の問題は、数値計算における「分母」の決定にも密接に関わってくる。私たちのデータセットには、まだ新しいコミットメントで、後続の決算説明会が行われていないため「結果が出る機会がなかった」ものが約7千件あった。これらのコミットメントを分母に含めるか否かで「放置率」は大きく変わる。例えば、すべてのコミットメントを分母にすれば放置率は9.3%だが、「結果が出る機会があった」コミットメントのみを分母にすれば13.5%となる。どちらも真実だが、後者が「コミットメントが放置される頻度」という問いに正確に答える。これは統計学の「生存分析」における「右側切断」の概念に似ており、まだ観察中の対象を、イベントが発生しなかった対象としてカウントしてはならないことを示唆している。ビジネスデータセットではこの間違いが頻繁に起こるため、分母から「保留中の行」を明確に除外し、その旨を数字と共に明記することが重要だ。

さらに、集計単位の選び方も結果の解釈に影響を与える。「解決可能なコミットメント全体のうち57.8%が守られた」という数字と、「平均的な企業は解決可能なコミットメントの56.7%を守る」という数字は、一見似ているが、異なる問いに答えている。前者は多くのコミットメントを行う企業に重みづけられ、後者は各企業に等しい重みを与える。数字を提示する際には、その集計単位（全体か、企業ごとかなど）を明確に述べることが必須となる。

また、私たちは同様のシステムを米国企業データでも構築したが、その両者を比較する試みは断念した。なぜなら、二つのデータセット間には「カバレッジの深さ（追跡期間）」「結果の語彙（ラベルの定義）」「抽出仕様（データ取得ルール）」という三つの重要な違いがあり、これらはいずれも比較を無効にするに足る理由だったからだ。このような違いがある状況で数字を比較しても、それは「企業行動の事実」ではなく「データ処理パイプラインの事実」を述べるに過ぎない。この経験から、完成したグラフを削除する決断を下すことは、データプロジェクトにおいて最も不人気な行動だが、多くの場合、それが正しい判断であることを学んだ。

実際の開発過程で遭遇した具体的なバグ事例もある。インドの会計年度の扱いの違いから、決算説明会の四半期ラベルにオフバイワンエラーが発生した。この導出された誤ったラベルをコミットメントの結果を連結する際のキーとして使用したため、「ある四半期に言及されたコミットメントが、別の四半期には放置された」という誤った事実が生成されてしまった。この教訓は、システムが導出したラベルは、そのまま「証拠」として使うべきではないということだ。公に発表する際は、元の文書に照らして再検証するか、あるいは「後の決算説明会で」といった、より弱いながらも確実な表現を用いるべきである。

これらの経験から、四つの重要なルールが導き出される。第一に、行の結果が未来の文書に依存するデータは、単一の出力としてではなく、ライフサイクルを持つエンティティとしてモデル化する。第二に、不在を示すラベル（何もない）は、その観察範囲を常に含め、可能であれば列名にも明記する。第三に、数値計算の際には分母から「まだ結果が出ていない（保留中の）」行を除外し、その旨を数字と共に明確に述べる。そして第四に、数値を提示する際には、その集計単位（全体での集計か、個別の要素の平均かなど）を必ず明記する。

これらの教訓は、私たちの持つ独自データセットの具体的な数字を再計算することはできないが、データモデリング、データ解釈、そしてデータ分析における普遍的な課題と解決策を示しており、システムエンジニアを目指す上で非常に役立つはずだ。