【ITニュース解説】The field that grew with every batch was the wrong one

システム開発において、情報をいかに整理し、構造化するかは非常に重要な課題だ。今回の記事は、バラバラなアイデアを systematize する中で直面した、データ分類の難しさと、そこから得られた貴重な教訓を示している。システムエンジニアを目指す上で、このような経験から学べることは多い。

まず、著者は「作業アイデアのリスト」を「セッションの登録簿（レジストリ）」に変換する作業に着手した。これは、システム開発における初期段階の作業、たとえば「要件定義」で洗い出された大量の情報を、データベースの設計やデータ構造として具体化していくプロセスに似ている。このプロジェクトは、最初から「スプリント」や「ロードマップ」といった厳密な計画を持たず、手探りで進められた。これは、小規模なプロジェクトやプロトタイピング、あるいはアジャイル開発の初期段階ではよくあるアプローチだ。

著者は、この作業を「8つのバッチ」に分けて進めた。バッチとは、複数の処理やデータを一括して扱う単位を指す。例えば、データベースに大量のデータをまとめて登録する際、一度にすべてではなく、区切りの良い固まりに分けて処理するようなものだ。この時、データの分類方法、つまり「分類軸」を事前に厳密に設計しなかった。それぞれのバッチ処理を進める中で、必要に応じて新しい分類軸を追加していったのだ。

ここで重要な概念が「分類軸（axis）」と「クローズドボキャブラリ（closed vocabulary）」だ。分類軸とは、データをグループ化したり、検索したりするための基準となる項目を指す。データベースで言えば、テーブルのカラム（列）に相当し、例えば「トピック」や「プロジェクト」といったものが考えられる。一方、クローズドボキャブラリとは、その分類軸が取り得る値が、あらかじめ決められた限られたリストの中から選ばれる形式を指す。例えば、Webサイトのドロップダウンリストで選択肢が固定されているようなイメージだ。これは、データの種類を統一し、整合性を保つ上で非常に有用である。なぜなら、もし新しいデータが追加されるたびに分類項目が増え続けるようでは、分類としての機能が失われ、単なる自由記述の「説明」になってしまうからだ。本来、クローズドボキャブラリは「増えない」ことがその価値の根源なのだ。

記事の中で問題となった「categoria（カテゴリ）」というフィールドは、まさにこのクローズドボキャブラリであるべきだが、そうではなかったフィールドだった。著者は、「メタ改善パフォーマンススキル？」のような複雑なアイデアを単一のフィールドに収めるのが難しいと感じたとき、「categoria」や「tags」といった新しい分類軸を導入した。最初はこれでうまくいくように見えたかもしれない。例えば、「bloqueada（ブロック済み）」という状態を示すフィールドや、「lote（バッチ）」という処理単位を示すフィールドも、同様に作業を進める中で必要性を感じて追加されたものだ。

この作業において、著者は「ジェネレータ」という仕組みを導入し、効率的にセッションの登録を行った。ジェネレータとは、プログラムでデータを自動生成する機能のことで、これにより手作業で一つ一つデータを修正する手間を省き、大量のセッションを迅速に再分類することが可能になった。これは、システム開発において、スクリプトや自動化ツールがいかに開発効率を高めるかを示す良い例だ。しかし、この効率化の裏で、重要な問題の「兆候（シグナル）」が見過ごされてしまう結果を招いた。

著者は、作業の途中で「categoria」というクローズドボキャブラリのはずのフィールドが、バッチ処理を行うたびに新しい値が2〜3個ずつ増えていることに気づき、それを記録していた。また、その終盤には、「categoria」の値のうち3つが「プロジェクト」という別の分類軸の値と重複していることにも気づいていた。さらに、全体のセッションの約3分の1にはまだカテゴリが設定されていない状況だった。これらは、設計上の問題やデータの整合性に関する「危険信号」だった。しかし著者は、これらの信号を「記録した」ものの、その時点では「読み解かなかった」、つまり深く分析し、対応しなかったのだ。これは、システム開発における「技術的負債」の兆候を見過ごす行為に例えられる。初期の効率を優先した結果、将来的な問題の種を蒔いてしまうケースは少なくない。

一週間後、94セッションが登録された時点で、著者は改めて「categoria」フィールドの問題を深く分析した。その結果、「categoria」が「トピック」「プロジェクト」「作業の種類」という、本来であれば別々に管理されるべき3つの異なる意味を混同していることが判明した。これはデータベース設計における「非正規化」の状態に近く、一つのフィールドに複数の情報が詰め込まれているため、データの検索、更新、管理が複雑になり、整合性を保つのが困難になる。例えば、「スポーツ」というカテゴリがあったとして、それが「スポーツに関するトピック」なのか、「スポーツ関連プロジェクト」なのか、「スポーツに関する作業タイプ」なのかが曖昧では、正確なデータ活用はできない。

この問題に対し、著者は「tipo（タイプ）」という新しいフィールドを導入し、それを「categoria」の代わりに使うことで解決を図った。「categoria」はデータベースのスキーマから「破壊的変更（breaking change）」として削除された。破壊的変更とは、システムの既存の機能やデータ構造に互換性のない変更を加えることを指し、通常は慎重な計画とデータ移行が必要となる。今回のケースでは、「categoria」の持っていた値は「tags」フィールドに適切に移行されたため、情報が失われることはなかった。これは、システム改修において、データ移行計画が非常に重要であることを示している。

現在のシステムには118のセッションが登録されており、その中には「categoria」というフィールドを持つものは一つも存在しない。この経験から得られた教訓は明確だ。つまり、一つの質問、一つの目的を持つ分類軸（フィールド）はシステムを支える強固な基盤となるが、複数の意味や目的を混同している軸は、システムが成長するにつれて破綻を招くということだ。

システムエンジニアとして、私たちはデータ設計の初期段階で、各フィールドが何を意味し、どのような役割を持つべきかを慎重に検討する必要がある。もし「クローズド」であるべき分類フィールドが、新しいデータが追加されるたびに新しい値の追加を求めてくるのであれば、それはそのフィールドが何を混同しているのかを深く問い直し、設計を見直すべきだという明確なサインである。安易にフィールドの定義を広げるのではなく、情報の分離と単一責任の原則に従い、データを適切に構造化すること。これが、長期的に見て堅牢で保守しやすいシステムを構築するための重要な鍵となる。初期の効率を追求しつつも、将来的な問題の兆候を見逃さず、早期に適切な改善を行うことが、システム開発の成功には不可欠なのである。