最近、技術者の友人数人と食事をした際、話の流れでデータ要素新政策の話題になりました。電子商取引企業でバックエンドを担当している友人が言った一言が非常に印象的でした。「うちの会社のシステムで流れているインターフェースデータは、ラッシュアワーの地下鉄駅みたいなものだ。動いているように見えても、実際はぐちゃぐちゃだ。」
言葉は粗いですが、理にかなっています。新政策の施行により、データは正式に生産要素として管理されることになりました。これは何を意味するのでしょうか？これまでデータベースやログファイル、さらには同僚のデスクトップに適当に置かれていたデータにも、正式な身分が必要になったということです。特にインターフェースデータに関しては、多くの企業がまったく管理しきれていません。
インターフェースデータとは何か？簡単に言えば、システム間でやり取りされるものです。例えば、注文をすると、注文システムが在庫システムに在庫を減らすよう伝え、決済システムに支払いを要求し、物流システムに出荷準備を指示します。伝えるたびに、大量のJSON形式のデータが生成されます。これは一見整然としていて、波括弧が入れ子になり、キーと値のペアがきれいに並んでいます。しかし問題は、インターフェースを書く人が多すぎて、各人のスタイルが異なり、時間が経つとすべてが混乱してしまうことです。
私が見た中で最もひどい事例は、ある企業のユーザーインターフェースが返すJSONで、ユーザーIDが「uid」と呼ばれたり、「userId」と呼ばれたり、「user_id」と呼ばれたりしていました。フロントエンド開発者は毎回連携する前にドキュメントを確認し、確認後も試し、試した結果ドキュメントと実際の戻り値が違うことに気づきます。ましてや7、8層もネストされた構造になると、開いただけで目がくらみます。
ここでJSONフォーマットツールが役立ちます。この機能を軽視してはいけません。多くの人は、圧縮された1行のJSONをインデント付きの複数行に展開するだけだと思い、技術的な価値があるのかと疑問に思います。しかし、実際に作業をしたことのある人なら、使い勝手の良いフォーマットツールがどれだけ手間を省いてくれるか知っています。乱雑な階層関係を整理し、どのフィールドがどのオブジェクトにあるか、どの配列がどのプロパティを含んでいるかを一目でわかるようにしてくれます。特にインターフェースをデバッグするとき、フォーマット前と後ではまったく別世界です。
新政策は、データが管理可能、追跡可能、評価可能であることを求めています。インターフェースデータがどのようなものかさえ見えなければ、どうやって管理し、追跡するのでしょうか？だからこそ第一歩は、データを読みやすくすることです。JSONフォーマットが行うのはまさにこれで、機械は読めても人間には読みにくいものを、人間も楽に理解できる形に変えます。これは高度な技術ではありませんが、すべてのデータガバナンス作業の出発点です。
私の電子商取引の友人は後に会社でルールを導入しました。すべてのインターフェースドキュメントにはフォーマット済みのJSON例を添付すること、コードを提出する前に必ずフォーマットツールで戻り構造を確認すること。最初はみんな面倒がっていましたが、後に連携テストの時間が半分に短縮されたことに気づき、誰も文句を言わなくなりました。ほら、時にはデータ管理はそれほど複雑ではなく、使いやすいフォーマットツールを活用することから始まるのです。